RiscPC update Aug2014

No – but it is interesting what the values equate too.

probably be able to use the same tactic I used with the Podule modules.

I now have a copy of PCSleep – 1.4 24-Jun97 – any later version?

A case of using !ARMalyser – and 32 bitting plus sorting out the memory pokes.

Probably re-stubbing with StubsG – see if can find the old card – and refitting it.

If anyone else would like to recompile the ‘C’ stuff – they are most welcome :-)

What did Acorn call the 2nd Processor?

It’s doesn’t seem to classed with the Podules.
and their SWI calls.

Any ideas of how to find the base address?
Thanks

What did Acorn call the 2nd Processor?

“OPEN Bus”.

It’s doesn’t seem to classed with the Podules and their SWI calls.

It isn’t a podule or I/O. You talk to the hardware directly…

Any ideas of how to find the base address?

So try seeing what the addresses used to match up to in your system.
&03600000 to &037FFFFF (RPC TRM p1-11).

Here is a bit of code to find out it !PC is running.

OSCLI"Unset Diva$Running":DIM b%16,code%640,L%-1:i%=0
REPEAT:SYS"TaskManager_EnumerateTasks",i%,b%,16TOi%
IF FNs(b%!4)=“PC Card Software”ORFNs(b%!4)=“PCPro 3” OSCLI"Set Diva$Running The PC card software is already loaded. To use a new configuration, you must quit and restart it.":END
UNTIL i%<0

FOR pass%=4TO5:P%=code%:[OPT pass%<<1
.HDLA
SWI “OS_EnterOS”
MOV R0,#&3740000
MOV R1,#&20
STR R1,[R0,R1,LSL#11]!
MOV R2,#&1000
.delay
SUBS R2,R2,#1
BNE delay
EOR R1,R1,#&02
EQUD &E1001091 ;SWP R1,R1,[R0]
LDR R0,[R0,#0]
msr cpsr_c,#0
MOV R0,R0
MOVS R0,R0,LSL#31
EORMI R0,R0,R1,LSL#31

]:NEXT
PRINT~USR HDLA
IF USR HDLA=0 OSCLI"Set Diva$Running No PC Card found! Please install it before running !PC."
END
DEF FNs(a%):LOCAL n$:WHILE?a%>31:n$=CHR$?a%:a%=1:ENDWHILE:=n$
********

In RO4.02 – with no card fitted gives a answer.

*where at &3750000 – gives “page mapped out”.

IN RO5.21 (24 Aug 2014)
*where at &3750000 – gives “is in the ROM”.

Not sure if msr cpsr_c,#0 is correct – would it put the processor into 26bit mode?

Not sure if msr cpsr_c,#0 is correct – would it put the processor into 26bit mode?

Mmm… Shouldn’t it be #%10000 ?

Mmm… Shouldn’t it be #%10000 ?

Or even msr cpsr_c, USR32_mode if you want to use the Generic32 headers and macros.
that existing zero is rather cryptic don’t you think?

Half of the problem with the code in PCPro is that someone decided that replicating the original compiler headers as a home build with tweaks and embedding of magic numbers nailed in a collection of 26 bit only code.¹

Where that didn’t happen changes are much easier. For example !ChooseCfg is largely clean and my notes read as:
Choose.!ChooseCfg:
* source in 306src.Choosecfg *
* Needs recompile *
+ create new make and MakeAll TaskObey file +
+ s.miscfile changed to make a 26/32 exit thus: +
+ TEQ PC,PC ; Test for 32 bit mode +
+ LDMEQFD R13!,{R1-R6,PC} ; exit here if 32 bit +
+ LDMFD R13!,{R1-R6,PC}^ ; original 26 bit exit +
Cheap and cheerful change…

I suppose if that was in the available macros as ExitNeutral it would be even neater to use and maintain. Alter one macro and recompile rather than shuffle through numerous exit points in some cases.

Regular coders will note the lift of an easy exit from the 32 bit web page.

¹ Nice at the time, total pain down the road in 32 bit era.

Just as easy to save the flags mrs r3,cpsr – and use msr cpsr_c,r3 at the end.

Have you managed to 32bit compile some of the !PC progs?

Is there a SWI call that would return info on where the 2nd processor is mapped in?

Rick’s StrawHelp is handy to have standing by – and the PDF RISCOS manuals.

Pity StrawHelp doesn’t seem to work with Linux-Slitaz/Wine – wouldn’t it been better to have kept all the extra DLLs etc in ‘HeyRick’ – in a ‘common’ directory – bit like RISCOS!

Have you managed to 32bit compile some of the !PC progs?

ChooseCfg,
PCConfig.!RunImage is much the same modification as ChooseCfg in needing that neutral exit in s.misc (oh and a hack for the file elements as o.file has no available source – probably needs to use OSFile these days ut I dredged up old file.h and file.c)
MkDOSDisc will simply recompile if you alter the makefile to include the o.misc dependency build line:
o.misc: s.misc

GuardDD can be modified to do 26 or 32 bit action based on processor mode.
(I first looked at that when Chris Evans mentioned a need for a 32 bit dos file protection)

LoadAuto has no source in the 306 archive – refer back to the 235 version Src235/zip.loadauto/zip and change s.misc in the same fashion as the ChooseCfg exit

ARMASPI and StdSound.PCSound have no source – could be fun reverse engineering.

RunImage needs amendments to s.misc exits and a makefile tweak to point at c.divaserial properly.¹

CheckDiva I haven’t really looked at.

Working through core modules looking at stuff. All largely untested.

It’s a learning exercise for me. I need to do something productive to be able to remember things.

Is there a SWI call that would return info on where the 2nd processor is mapped in?

Not that I know.

¹ Basically I’d like to be able to program in something other than hacking a few bits of BASIC and looking so at someone elses code helps the learning process

PCConfig.!RunImage

Oh, forgot – without a tweak to the Res file the PCConfig seems to fail to display some icons.

Choose.!ChooseCfg:
s.misc changed to make a 26/32 exit thus:
TEQ PC,PC ; Test for 32 bit mode
LDMEQFD R13!,{R1-R6,PC} ; exit here if 32 bit
LDMFD R13!,{R1-R6,PC}^ ; original 26 bit exit

In fact, you can save yourself the bother there. If you’re recompiling the C code (in choosecfg.c) as APCS-32 then when it calls the helper functions in assembler (in misc.s) it’s expecting to have the status flags trashed in both 26 bit configuration and 32 bit configuration.

Having looked at the 3 functions in “misc.s” they don’t even need to be in assembler, the original author could have expressed them in C originally using _swix and _swi.

In fact, you can save yourself the bother there. If you’re recompiling the C code (in choosecfg.c) as APCS-32 then when it calls the helper functions in assembler (in misc.s) it’s expecting to have the status flags trashed in both 26 bit configuration and 32 bit configuration.

I hadn’t looked at that, but the assembler change was an attempt to keep changes bit neutral

Having looked at the 3 functions in “misc.s” they don’t even need to be in assembler, the original author could have expressed them in C originally using _swix and _swi.

I’m very much on baby steps and changing minimal items. Re-writing whole chunks¹ of a complicated application hadn’t actually surfaced in my mind.

¹ OK, altering the assembler is re-writing things a bit.

Having looked at the 3 functions in “misc.s” they don’t even need to be in assembler, the original author could have expressed them in C originally using _swix and _swi.

Ah. I think I see.
After reading around I’m thinking that it was Archimedes style programming and the assembler wrapper was possibly faster. Might have a go at the _swi bit.

Archimedes style programming? Have you seen how much code it takes just to call a SWI? It probably says a lot that one of the labels is “swi_beyond_a_joke”.
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Lib/RISC_OSLib/kernel/s/swiv?rev=4.7

When I am prototyping some code, I tend to use _kernel_swi()¹ and later I usually replace that with custom assembler code. One SWI, two or three instructions (and a branch either side²). Done.

¹ It is more of a pain to use as the register block needs to be set up, unlike swi, however the SWI call code is a lot shorter/saner :-) → https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Lib/RISC_OSLib/kernel/s/kbody?rev=4.27#l2084

² I wonder if the inline assembler could improve upon this? Must try it…

Archimedes style programming? Have you seen how much code it takes just to call a SWI?

I think the point is that it goes under the bonnet and you don’t need to know how much.

When I am prototyping some code, I tend to use _kernel_swi()1 and later I usually replace that with custom assembler code. One SWI, two or three instructions (and a branch either side2). Done.

You have of course always written this code as massively portable and not dependent on particular processor mode behaviour. Yes? No?
I think the point Sprow was leaning toward, although not mentioned here in this thread¹, is that in pure C it’s just a recompile with appropriate compiler settings as opposed to needing new custom assembler.

¹ Elsewhere the suggestion is that custom code is bad in the long term in maintenance terms. I think someone called Rick wrote a 26 to 32 bit migration document somewhere round here that specifically references “pure C” being a simple recompile with correct settings. :-P

Has anyone here a RO5 memory map.

Is it still possible to do a *save xxx of the ro5.21 roms?

Or to make direct access to video memory, for example (would be useful for a kind of directx access :) )

Has anyone here a RO5 memory map.

I suspect the best resource is in here: IOMDHAL.castle.RiscOS.Sources.Kernel.Docs.HAL

with The “Notes” file being quite informative.
quotey bit:
Memory Map

00000000 16K Kernel workspace
00004000 16K Scratch space
00008000 28M-32K Application memory
01C00000 32K SVC stack
01C08000 2M-32K System heap
01F00000 32K Cursor/System/Sound
01F08000 32K “Nowhere”
02100000 15M Module area
03000000 8M I/O space
03800000 8M ROM
04000000 2G-64M Dynamic areas
80000000 512M Logical copy of physical space
A0000000 1280M Dynamic areas
F0000000 224M I/O space (growing downwards if necessary)
FE000000 1M HAL workspace
FE100000 8K ABT stack
FE200000 8K UND stack
FF000000 4M L2PT + embedded L1PT
FF800000 8M Soft CAM

Which since one bit of probing I did came back with IOMD base in the F0000000 block probably matches a move from 03000000.

Where is the module area in 32 bit systems? [I know I could just look at module addresses, but I don’t have RISC OS running right now]

Is the “nowhere” unaddressable or something?

Where is the module area in 32 bit systems? [I know I could just look at module addresses, but I don’t have RISC OS running right now]

Running Verma in RPCEmu displays soft loaded modules in the block starting with RPCEmuHostFS at 200D23F4 and the highest loaded in this setup is TrapDelete at 201A9B14

Where is the module area in 32 bit systems? [I know I could just look at module addresses, but I don’t have RISC OS running right now]

256MB from &20000000 and up

Is the “nowhere” unaddressable or something?

When the kernel unmaps a page, it updates the CAM (which is a physical → logical map of RAM used by the kernel) to say that the page is mapped to “nowhere”. On MEMC systems I think it also updated MEMC to map the page to “nowhere” (MEMC worked with a physical → logical translation table, so the only way to get rid of pages was to pile them all ontop of each other at one logical address you don’t care about), but on modern systems with an integrated MMU the kernel is able to properly update the page tables to get rid of the page.

Here is some info on a podule – not exectly a PCcard.
To try and find out where the PCcard is plumbed into the memory map.

Would it be possible to add a swi call to the ‘Podule_ReadInfo’? – to return the base address of the PCcard? (podule 9).

00 8 8 Expansion card number.
01 F982B800 302B800 Base address of card.
02 3C 3C CMOS address.
03 4 4 CMOS size.
04 F982B000 302B000 Extension ROM or NIC base address.
05 0 0 Expansion card ID byte.
06 150 150 Product type.
07 F982B03C 302B03C Combined h’ware addr (Sync base OR’d CMOS addr).
08 200006AC 2100590 Pointer to description string, or zero for none.
09 0 0 EASI address, or zero for none
10 0 0 EASI size
11 105 105 Primary DMA channel logical number (or -1 for none)
12 FFFFFFFF FFFFFFF Secondary DMA channel logical number (or -1 for none)
13 F9A00020 3200020 IRQ status register
14 F9A00024 3200024 IRQ request register
15 F9A00028 3200028 IRQ mask register
16 8 8 IRQ bit within the above 3 registers
17 B B IRQ device number for OS_ClaimDeviceVector
18 F9A00020 3200020 FIQ as IRQ status register
19 F9A00024 3200024 FIQ as IRQ request register
20 F9A00028 3200028 FIQ as IRQ mask register
21 8 8 FIQ as IRQ bit within the above 3 registers
22 B B FIQ as IRQ device number for OS_ClaimDeviceVector
23 F9A00030 3200030 FIQ status register
24 F9A00034 3200034 FIQ request register
25 F9A00038 3200038 FIQ mask register
26 2 2 FIQ bit within the above 3 regs
8 NET100 E NET100 Ethernet Interface
*********

to return the base address of the PCcard? (podule 9).

The x86 card isn’t a podule. You’re thinking of the network card.

https://www.riscosopen.org/forum/forums/3/topics/2780?page=2#posts-35371

Or page up a bit.

Or download and read the RiscPC TRM.

It looks like the IOMD HAL will map in the full 8MB of I/O space, but it won’t actually expose the logical address of the area reserved for the OPEN bus. So I think the best way of doing things would be to get the IOMD address (physical addr &03200000) and add on 4MB:

SYS "OS_Memory",9,&400 TO ,addr%
IF addr%=0 THEN ERROR 0,"Not IOMD"
addr% += &400000

IF addr%=0 THEN ERROR 0,“Not IOMD”

Extra benefit, easy rejection of incompatible machines. Win! :-) Edit: Or not? :-(

SYS “OS_Memory”,9,&400 TO ,addr%

When I said “one bit of probing I did came back” that was where I’d been working.
Wasn’t sure I was right.

Shame about the lack of OS_Memory 25 I suppose.