RiscPC update Aug2014

Just updated to RO5.21 24Aug2014 on my RPC- from one about year ago.

Try to keep it possible to dual boot between RO4.02 and 5.21.
Noticed on boot up – get msg “No keyboard present – Autobooting” but keyboard still seems to work ok.

I tend to use “system” font – but Hermes – version 2.00 doesn’t now like it – no writing is shown – using the option “System.Fixed” seems to work ok.

Is there a updated version of !Phoenix around? have v2.13 here – seems a lot quicker than NetSurf v3.3 for some sites.

64 thou colours is nice :-)

Is there anyway of getting around the 2Mb screen limit with the RPC?

Could clicking with adjust on the ‘Cog’ be made to bring up a ‘Task Window’?

Thanks for all the work done on RO five.

I tend to use “system” font – but Hermes – version 2.00 doesn’t now like it – no writing is shown – using the option “System.Fixed” seems to work ok.

I seem to recall discussion out on comp.sys.acorn.* where the author of Hermes was involved. The final conclusion was that they had made certain assumptions which were not quite accurate. IIRC a revised version is available where the issue is fixed.

Isn’t the 2MB limit a hardware restriction?
You can certainly ‘bodge’ a RPC !Boot to allow screen modes that use more than 2MB on RPCEmu (and probably other emulators), but it’ll probably do some harm to a real machine.

Havn’t tried it – but if the VRAM card was removed the RPC should be able to use upto 16MB of memory for screen memory – would be nice if the Viewfinder card could be used with RO5.

With ref to !Phoenix – where is it available to download? Tks

Havn’t tried it – but if the VRAM card was removed the RPC should be able to use upto 16MB of memory for screen memory

I was of the impression that your screen modes without VRAM were quite limited (no 16M for example) as the higher bandwidth modes could have the ARM and VIDC fighting over who accesses it when. It’s just a shame there was never capability for ~4MB VRAM, at least, enough to fully push the VIDC’s abilities.

Noticed on boot up – get msg “No keyboard present – Autobooting” but keyboard still seems to work ok.

I’ve seen that with softloads too, something to look into.

Is there a updated version of !Phoenix around? have v2.13 here

Other than 2 build fixes nothing’s changed since 2.13 back in 2006.

Havn’t tried it – but if the VRAM card was removed the RPC should be able to use upto 16MB of memory for screen memory

Er, no, removing VRAM doesn’t magically upgrade your video system! The VRAM is useful because it’s a separate data path to the system RAM so the machine doesn’t slow down when in higher bandwidth modes, instead getting the display data from the VRAM.

The VRAM is arranged in a square array with 9 address bits, so there’s 2 ⁽⁹⁺⁹⁾ x 64 bits = 2MB.
Looking at the Risc PC schematic it looks like somebody had future seeing goggles on as they wired up 10 address lines to the socket, which would give a possible 2 ^(10+10) x 64 bits = 8MB.
Indeed, RISC OS 5 even supports 8MB VRAM on IOMD, since the RPCEmu emulator can emulate this.

All that’s needed is for someone to knock up an 8MB VRAM module, though I expect the weird dual port DRAM chips to only be available from rocking horse poop vendors, and a more practical solution now would be to use a single higher speed 8MB RAM with an FPGA to deal with the dual port arbitration.

The extra VRAM will help you get bigger deep colour modes, but the VIDC20 silicon top clock rate is a fixed constant so you’d have to trade pixel rates to avoid melting the chip.

would be nice if the Viewfinder card could be used with RO5.

No technical blockers to that, just need someone to write a GraphicsV module. In many ways it ought to be easier than the original implementation since there’s no need to patch anything and the interfaces are all well exercised. John Kortink would be best placed to help presumably, though if the podules are no longer for sale there’s probably no commercial impetus to do so.

Is there a updated version of !Phoenix around? have v2.13 here – seems a lot quicker than NetSurf v3.3 for some sites.

Which sites? Ones with a lot of CSS? Without CSS support a browser doesn’t have to download and parse (often several hundred KB of) CSS, and doesn’t need to perform style selection, which is an expensive operation.

http://www.motorcycle-usa.com/ is one site – not woried about fancy layout – just the stories :-) (using a usb mobile/dongle Internet connection)

Also !Phoenix has the option of loading the sprites – when I want.

Also !Phoenix can give an error at &9CEC0 – looks like it is poking zero page :-( – thats why I was asking about the latest update.

Ref the RPC bit – RedSquirrel emulator RO 5.19 – 1920 × 1200 16M 9000k memory – using Tasks-Screen memory – it can be dragged out to 16384k.

A jump from 2M to 8M would be nice for the RPC – some monitors can drop down to about 30Hz refresh rate – have to run !MakeModes to see what can be achieved.

Anyone want to try and contact the Viewfinder author/creator – for a RO5 update?

Anyone want to try and contact the Viewfinder author/creator – for a RO5 update?

Perhaps you could try getting in touch with John, since you both own a Viewfinder and are interested in seeing RISC OS 5 support?

A similar topic from 2009 reveals that he hasn’t flat-out refused the possibility of a RISC OS 5 driver. If enough Viewfinder owners declared their interest then he might be tempted to produce the driver himself, or maybe work out a way of open-sourcing various bits so that the community can manage it themselves (e.g. split the driver into two modules so that all the card drivers, AGP interface, x86 emulator, etc. can remain closed-source while the bit which interfaces with the OS video APIs can be open-sourced, or at least replaced with a GraphicsV version)

Reply from John

Sorry, but ViewFinder is dead (long live ViewFinder !). I haven’t even
tried RISC OS 5. I have that much interest in it …

Regards,

John Kortink
******

Second question – would he consider releasing the source code so somebody else could update it?

You can but ask John!!

With ref to the Program ‘PCSleep’ if it was 32bitted – is there anyway of testing it out – to see if it works ok?

Perhaps the RPC’s current demand drops – can it be read with a meter!!

With running RO 5.21 (24 Aug 2014) the Configuration/Screen/Display settings.

On my RPC machine – the Resolution menu seems to be incorrect/corrupted.

The same seems to apply to RSquirrel running softloaded RO 5.21 (24 Aug 2014) 1280×800 16M 18Hz – RO5.19 seems to be ok.

Also of note – RO5.19 12 Feb 2012 – works from a rom directory – but later versions of RO5.19/21 don’t – they need to softloaded.

Just for interest – can *save rom xxx be used to save the working version of RO5.21?

Thanks

With ref to the Program ‘PCSleep’ if it was 32bitted – is there anyway of testing it out – to see if it works ok?

Are we talking about the PCSleep module included in !PC for the X86 co-processor card?

The source files on riscos.info don’t appear to contain the source for that module. This is true for a few items, although a rummage through the v235 archive turns up part of the missing source, albeit older.

My version is a FF8 file – PCSleep 1.1 17-Aug-95.

Looks like it probably pokes memory -ie &3000000 +xxx

Does the source say what it is doing?

The last time I poked around PCSleep (over a decade ago!), it appeared to be setting up a very minimal environment on the x86 card’s ASIC. It appears as if the ASIC communicates with the machine using “mailboxes” in a manner not unlike the Pi’s GPU. A block of memory is set up (perhaps 64K for x86 Tiny map?) and some code to halt the processor is poked into this area. The x86 is pointed to it and told to execute it. [note – these are guesstimates]
I did start to take the program apart, to understand how it works and write my own copy from that (this far predating the source release) but I never finished…

My version is a FF8 file – PCSleep 1.1 17-Aug-95

Sorry, absolute not module.

Mind you, going back to the original question – why 32 bit the PCSleep binary if the system is in 26 bit mode and the rest of the PC Pro build is still 26 bit?
OK, some bits are relatively easy to convert and some are simple recompiles.

Mind you, going back to the original question –why 32 bit the PCSleep binary if the system is in 26 bit mode and the rest of the PC Pro build is still 26 bit?

He wants to dual boot, so it would need a 32 bit version to put the co pro to sleep under RISC OS 5.

He wants to dual boot, so it would need a 32 bit version to put the co pro to sleep under RISC OS 5.

Ah, forgot that bit.¹ But a 32 bit version would be handy.

¹ Can I plead overload? Came back from 2 weeks at the Great British Beer Festival² to a large and growing pile.

² Hard (physical) work – honest

Having had a quick look at the Binary – very little in there that is 26bit – and of course it needs restubbing.

Since the memory map is changed with RO5 – a swi is needed to be use to get the current memory address correct.

With ref to patched modules – can anyone here talk to Justin?

Dave Pilling has a util freshen – that can be used to update code – like FF8 and modules.

Do any of these numbers mean anything to you?
Is there a swi I could call when the program is run – to act as a offset?

Is there a program like !Zap – that would decode – the PCSleep file as x86 code – to see if I could find any code that makes the x86 co-proc go to sleep?

&3730000
&3750000
&3760000
&3790004
&37F0000

Is there a program like !Zap – that would decode – the PCSleep file as x86 code – to see if I could find any code that makes the x86 co-proc go to sleep?

If you look on riscos.info and look in the release 235 zip file. Look for the BiosSrc.zip and in there is the PCSleep.asm x86 source.I don’t think anything changed on that side. I think the issue is sending the instruction through from the ARM side to the x86 to run that PCSleep.exe file – that’s what the PCSleep file on the ARM side does.

Aleph1 sent me partial sources ages ago (circa 2001), but following a disc crash I lost a lot of them (the entire RISC OS side) so this never got finished…
http://heyrick.co.uk/assembler/80×86.html

so this never got finished…
http://heyrick.co.uk/assembler/80×86.html

Is that assuming the memory map hasn’t changed?

Dated 2002, so probably…

Not 32bit safe either but that’s minor.