Who has RISCiX sources?

@ Stuart (thanks for the clarification! I was starting to get confused)

shows that RA2 was used for the bank select (there were four 256KB banks on the A310), with RA8 being used as a DRAM address line – I think if a 4KB page size had been selected, you might have only got 256KB memory or, worse, indeterminate results

Haaa that makes more sense, I definitely think this is more like it! Thanks.

@ Sarah

I did some digging on MEMC1 vs MEMC1a performance last year

Very nice work and very interesting, thanks a lot!

The 4.3BSD sources are freely available: https://www.tuhs.org/Archive/Distributions/UCB/4.3BSD/

It would, in theory, be possible to reconstruct the kernel source. If someone was so inclined, that is.

The RISC iX kernel is based on 4.3BSD, and the kernel is distributed as object files so it can be modified and relinked (e.g. to add new drivers). Headers are included free. :)

The idea is, you’d compile one source file at a time from 4.3BSD, then compare it with the iX object file. If it’s identical, that source hasn’t changed and you move onto the next. If it differs, you change the C code to match what the disassembled iX code does. Repeat until all the new object files match the old ones.

Of course, if it’s missing (say, a device driver) then the code will need to be reconstructed from scratch.

It’s a long job, but as I said — if someone was inclined, it could be done.

You’d need to figure out which version of the compiler was originally used too, as different versions may compile to slightly different binaries. And compiler flags probably matter too, now that I’m thinking about it!

@ Phil

The 4.3BSD sources are freely available

Thanks and will have a look, although I am pretty sure that to run RISCiX on an ARM/MEMC there definitely were quite few changes compared to the standard BSD. Memory management on the Archie IS different than old 386/MIPS/Sparks.

Although people have been really nice here sharing their knowledge, none of the answers provided, for example, explains how the MEMC would work with 512KB of RAM and 8KB page size. The reason is simple: 512KB of RAM using 8KB pages gives 64 entries for the MEMC, so did Acorn used only 64 of the 128 entries? If so a virtual page 0 could have multiple matches in the “unset” 64 other entries and in which case the MEMC should have returned an “Invalid page number”. So, as far as I understand, with 512KB using 8K page size there probably was some trickery involved. not that it was used also on RISCiX, BUT surely RISCiX had to deal with some of these quirkiness of the old ARM/Acorn Architecture.

Another example is the 26bit address space (the OS has to be aware) because the PC does contains the status code as well, but it’s possible that RISCiX only worked in 32bit mode on the ARM3 in which case this would not apply. But need to be sure, because AFAIK RISCiX only runs on ARM2/ARM3.

People reported that RISCiX could run only on the Rxxx series because of a problem with the backplane on the Archimedes series, this is actually not quite correct. The IRQ masking problem was found only on the EARLY Archimedes backplane, fixed for the Rxxx series and ALSO for the later backplane series for all the Archimedes rage. In fact RISCiX can actually run on even an A310 as long as it has been upgraded with 4MB RAM (which IIRC is the minimum amount of memory to run RISCiX, but it works better with 8MB or 16MB and 16MB are possible only on the A540)

Someone has reported also that RISCiX supports only SCSI controller, however this doesn’t seems to be correct either, it seems that it was bootable from ST506 as well. So I think we should say “it only supported Acorn Disc Controller (ST506 and Acorn SCSI)”. I am not aware it supports any other brand, but if it does and someone has managed to use them on RISCiX then please let me know.

Also by looking at the binaries, I think RISCiX does supports Econet as well and not sure if it support any 3rd party network cards, so probably also on this one it’s going to be Acorn stuff.

So far it seems that pure 4.3BSD would need quite a few drivers/changes to actually run as a RISCiX Kernel replacement, BUT, I am pretty sure we could actually run RISCiX binaries inside an Emulator like ArchiEmu that supports ST506, Archimedes 540 emulation and up to 16MB RAM, so it might as well runs nicely in ArchiEmu. It also runs on Arculator AFAIR.

@ Chris Mahoney

You’d need to figure out which version of the compiler was originally used too

Totally and yes also compilers flags matters a lot, so I don’t think a binary comparison would help.

My intention/hypothesis is:
a) Manage to run it on ArchiEmu
b) When a) is done and stable, eventually, use ArchiEmu debugger to understand how it worked
c) Try to re-patch 4.3BSD and get back a suitable source to then use for eventually modern platforms

But, for now, just to get RISCiX back would be already a big achievement, so not trying to run too fast lol

I recall that we (Arthur/RISC OS) had a single page of virtual address space allocated for the purposes of parking currently-unmapped physical pages – the Wimp used this and it’s likely that the kernel set up any unused CAM entries to this value too. RO2 kernel is out there…

MEMC didn’t care if multiple CAM entries matched the same virtual address!

explains how the MEMC would work with 512KB of RAM and 8KB page size.

The top of the MemSize part of the RISC OS 2 kernel might shed some light on what was happening:

; Set MEMC for 32-k page then analyse signature of possible
; external RAM configurations...
; The configurations are:
;
; Ram Size    Page Size    Configuration    (Phys RAM) Signature
;--------------------------------------------------------------------
;   4Mbyte      32k          32*1Mx1         A13,A21,A20 distinct
;   4Mbyte      32k         4*8*256kx4       A13,A21,A20 distinct
;
;   2Mbyte      32k    expandable 2*8*256kx4 A13,A20 distinct, A21 fails
;   2Mbyte      16k      fixed 2*8*256kx4    A13,A21 distinct, A20 fails
;   
;   1Mbyte       8k          32*256kx1       A13,A20 fail, A19,A18,A12 distinct
;   1Mbyte       8k           8*256kx1       A13,A20 fail, A19,A18,A12 distinct
;   1Mbyte       8k          4*8*64kx4       A13,A20 fail, A19,A18,A12 distinct
;
; 512Kbyte       8k    expandable 2*8*64kx4  A13,A20,A19 fail, A12,A18 distinct
; 512Kbyte       4k      fixed 2*8*64kx4     A13,A21,A12 fail, A21,A19 distinct
;
; 256Kbyte       4K           8*64kx4        A13,A20,A12,A18 fail, A21,A19 ok  
; 256Kbyte       4K          32*64kx1        A13,A20,A12,A18 fail, A21,A19 ok  
;

So it looks like whether 4K or 8K was used depends upon memory arrangement for the A305, and there appears to have been either something (devboard? tube co-pro?) or abandoned plans for a 256K machine.

512KB of RAM using 8KB pages gives 64 entries for the MEMC, so did Acorn used only 64 of the 128 entries?

Possibly. NewReset makes references to #CamEntries and #NoOfCamEntries, along with the comment:

; now add all the NaffEntries to CamEntries
; R2 highest CAM entry used

I’ve not delved into the code (would need to be done in tandem with the MEMC datasheet, and life’s too short…) but a cursory glance suggests that it would indeed only fill up 64 entries on a half megabyte machine using 8K pages.
[well, logically, what are the other 64 pages going to be used for?]

I don’t have the Hdr files, so don’t know where the (NoOf)CamEntries is defined. Probably some place in page zero…

So, as far as I understand, with 512KB using 8K page size there probably was some trickery involved.

Not really. The OS knows that there are 0 to n pages. If the page size is larger, n is smaller. End of discussion.
It’s not as if the MEMC is going to poke the processor and say “oi! what about the rest?”. They’re probably all set up on init to point to DuffEntry and then just ignored.

but it’s possible that RISCiX only worked in 32bit mode on the ARM3

The ARM2/250/3 do not have a 26 bit mode. That didn’t turn up until the RiscPC and didn’t properly get used until post-Acorn. ;-)
[I think ARMLinux uses it too, but that’s nothing to do with Acorn]

I think RISCiX does supports Econet as well

I believe so.

Just out of interest, did anybody ever manage to port Minix? Back in the day, I heard some stuff about a set of patch files (this would be Minix 1 or 2, not sure which) aimed at… something. An A5000? A RiscPC? I never knew of anybody who actually had a working Minix.

Official Minix3 is available as an image for the Beagleboard xM (and Beaglebone if you don’t mind no framebuffer!) with, strangely, the Pi port being third party (and possibly incomplete?).

Also by looking at the binaries,

Wow, what’s with the endless (~25MiB) of boot blocks in the image? The “QUANTUM LPS270S S59.0000 182415397166 GENERIC” stuff. Over and over and over and…

Looking at the image dump, it appears that there are Ethernet drivers for the Acorn EthernetI and EthernetII cards.

That’ll be this: http://chrisacorns.computinghistory.org.uk/Network/Pics/Acorn_AKA25_Ethernet.html
And this: http://chrisacorns.computinghistory.org.uk/Network/Pics/Acorn_AEH50_Ethernet.html

[what’s 10base5? never come across that before – am I lucky?]

@ Rick

Just out of interest, did anybody ever manage to port Minix?

Yes there is a Minix for RISC OS based computers and beside, GCC 4 in GCCSDK can recompile Minix for RISC OS systems. I have never tried it TBH, because his creator seems to be against the use of Minix out of the learning environment, so not in my sphere.

10base5 : “Thick” Ethernet = 500m max length coax cable (“5” in the name). You “plug” your station with a vampire plug. Never saw it either, I think it was used at the very beginning of Ethernet.

10base2 was more common (185m max length thin coaxial cable, say 200m, hence the “2”). But to connect your station, you had to unplug the connectors, and hence stop the trafic.
Both had 10 Mbis/s theoretical max throughput.

Of course, there was the much more convenient 10baseT (“Telephone” cable).

what’s 10base5? never come across that before – am I lucky?

Also known as “Thick Ethernet”. The bane of my life from 1986 until 1993 or thereabouts.

So yes, you were lucky.

@ Rick

So it looks like whether 4K or 8K was used depends upon memory arrangement for the A305, and there appears to have been either something (devboard? tube co-pro?) or abandoned plans for a 256K machine.

Absolutely correct and yes confusing lol (which is why I was confused), however Stuward clarified the situation with the 512KB using 8K pages. Basically 64 entries used and 64 pointing at the same page, so MEMC was not complaining.

While MEMC would complain if the same logic page would be mapped to multiple physical pages, this would generate an invalid physical page number according to VLSI documentation.

> You’d need to figure out which version of the compiler was originally used too, as different versions may compile to slightly different binaries. And compiler flags probably matter too, now that I’m thinking about it!

Probably the compiler included with RISC iX ;)

Compiler flags will be in the Makefiles. They’d have to be consistent with the other source files, or the object files may be incompatible with each other.

@ Phil

Probably the compiler included with RISC iX ;)

That’s not an absolute truth, before RISCiX existed it was compiled from something else, maybe Norcroft C? Or maybe also something different I am not aware of. However it is possible that on subsequent versions it was compiled from itself.

Compiler flags will be in the Makefiles.

That would be true if we had the RISCiX sources, but given that we do not have them the story is a bit different… If instead you are referring to the original 4.3BSD, it’s most likely that 4.3BSD had not even an idea of the existence of Acorn, ARM and the Archimedes, so those Makefile won’t help…

Or am I not understanding what you mean?

So yes, you were lucky.

Some times you have to help the luck.
Early in my career we were moving the store room and I needed to sort out¹ a few² bits so we didn’t have unwanted clutter at the new location.

I also had to deal with a combination of a token ring network and a collection of semi-resident “IBMers”³. I managed to get rid of the former while the latter were still around

¹ Hey, I recognised the stuff as rubbish :)

RISCiX 1.21c runs perfectly on my A540, though better with 8Meg of RAM.
It has drivers for Ether 1, Ether 2 and the Acorn SCSI card.
It will boot on a 4M A3000 if you plug the SCSI card & drive in, though you can’t get Ethernet at the same time. It will do tcpip over Econet.
It does require a MEMC 1a chip.
The backplane PAL business is not a show stopper it just complains that its missing at boot.
It will boot on an A5000 but lacks drivers for the PC IO chip so the keyboard doesn’t work.
I suspect that the kernel is mostly from the 4.3BSD source with Acorn drivers, memory management,& compress executable support. The userland heritage is a more complicated as it has binaries for many common commands in both BSD and system 5 flavours. Setting the path determines which you get.

I have used the BSD source to that to try to recompile some userland stuff.

To add device drivers you need the kernel binaries kit. You can write new ones, and then link with their kernel binary objects to produce a new kernel with your driver.

I probably still have the instructions on how you copy it from disk to disk and get it to boot but I have never been able to produce bootable floppy disk set that would enable reinstallation without having a running system already.

I too would love the source to it and also to RISCiXFS the RISC OS module that can mount the RISCiX filesystem read only and execute RISCiX binaries out of water.

I may have some discs called ‘Petrol pump’ this is an broadcast disk duplicator which copies one machine to many target machines.

Here is a picture I took recently. I thought afterwards there may be reasons that it might not be quite right but its pretty close anyway. Not sure if you can upload pictures here but I could not see a way.
http://riscix.info/riscixbootscreen.jpg

Okay, I’ve done some more digging.

The CAM entries are in memory from address &164. There are 256 of them.
Not sure why there are 256 entries when the MEMC supports 128. It’s not for >4MiB as RISC OS 2 doesn’t.
RISC OS 3, on the other hand, supports up to 16MiB, so it’ll be different too.

I threw this together:

base% = &0 : REM Here be dragons and unpronouncable Welsh names!

REM This address is correct for RISC OS 3.10
PRINT "Detected memory is "+STR$(base%!&160)+" bytes."'

REM This address is correct for RISC OS 2.00
PRINT "MEMC page size is "+STR$(base%!&C28)+" bytes."'

REM I don't have time to poke around in page zero to work
REM out where the data "for the other one" is.

REM This, luckily, is the same in both OS versions.
PRINT "CAM map:"
REM 256 entries in RISC OS 2; RISC OS 3 unknown.
FOR l% = 0 TO 255
  offset% = &164 + (l% * 4)
  value% = base%!offset%
  prot% = (value% >> 28) : REM Highest nibble is PPL
  addr% = (value% AND &FFFFFFF) : REM Rest is address
  PRINT RIGHT$("  "+STR$(l%),3)+" = ";
  PRINT "&"+RIGHT$("000000"+STR$~(addr%), 7)+" (";
  CASE prot% OF
    WHEN 0 : PRINT "User Read/Write)"
    WHEN 1 : PRINT "User Read Only)"
    WHEN 2 : PRINT "User Inaccessible)"
    WHEN 3 : PRINT "User Inaccessible)"
  ENDCASE
NEXT

PRINT '"End."
END

Running it on RISC OS 3 (in ArchiEmu) with the emulator set to 512K, the result was as follows (detected memory will be wrong):

*CAMdump
Detected memory is 58796164 bytes.

MEMC page size is 8192 bytes.

CAM map:
  0 = &1FEC000 (User Read/Write)
  1 = &1FEE000 (User Read/Write)
  2 = &1FF0000 (User Read/Write)
  3 = &1FF2000 (User Read/Write)
  4 = &1FF4000 (User Read/Write)
  5 = &1FF6000 (User Read/Write)
  6 = &1FF8000 (User Read/Write)
  7 = &1FFA000 (User Read/Write)
  8 = &1FFC000 (User Read/Write)
  9 = &1FFE000 (User Read/Write)
 10 = &1800000 (User Read/Write)
 11 = &1E00000 (User Inaccessible)
 12 = &1E02000 (User Inaccessible)
 13 = &1E04000 (User Inaccessible)
 14 = &1E06000 (User Inaccessible)
 15 = &1818000 (User Read/Write)
 16 = &1F08000 (User Inaccessible)
 17 = &1F08000 (User Inaccessible)
 18 = &0008000 (User Read/Write)
 19 = &181E000 (User Read/Write)
 20 = &1F08000 (User Inaccessible)
 21 = &1F08000 (User Inaccessible)
 22 = &000C000 (User Read/Write)
 23 = &000A000 (User Read/Write)
 24 = &181C000 (User Read/Write)
 25 = &1820000 (User Read/Write)
 26 = &0020000 (User Read/Write)
 27 = &001E000 (User Read/Write)
 28 = &000E000 (User Read/Write)
 29 = &0010000 (User Read/Write)
 30 = &0012000 (User Read/Write)
 31 = &0014000 (User Read/Write)
 32 = &0016000 (User Read/Write)
 33 = &0018000 (User Read/Write)
 34 = &001A000 (User Read/Write)
 35 = &001C000 (User Read/Write)
 36 = &181A000 (User Read/Write)
 37 = &1F08000 (User Inaccessible)
 38 = &1F08000 (User Inaccessible)
 39 = &1F08000 (User Inaccessible)
 40 = &1F08000 (User Inaccessible)
 41 = &1816000 (User Read/Write)
 42 = &1814000 (User Read/Write)
 43 = &1812000 (User Read/Write)
 44 = &1810000 (User Read/Write)
 45 = &180E000 (User Read/Write)
 46 = &180C000 (User Read/Write)
 47 = &180A000 (User Read/Write)
 48 = &1808000 (User Read/Write)
 49 = &1806000 (User Read/Write)
 50 = &1804000 (User Read/Write)
 51 = &1802000 (User Read/Write)
 52 = &1C00000 (User Read/Write)
 53 = &1C02000 (User Read/Write)
 54 = &1C04000 (User Read/Write)
 55 = &1C06000 (User Read/Write)
 56 = &0000000 (User Read/Write)
 57 = &0002000 (User Read/Write)
 58 = &0004000 (User Read/Write)
 59 = &0006000 (User Read/Write)
 60 = &1F00000 (User Read Only)
 61 = &1F02000 (User Read Only)
 62 = &1F04000 (User Read Only)
 63 = &1F06000 (User Read Only)
 64 = &1F08000 (User Inaccessible)
 65 = &1F08000 (User Inaccessible)
 66 = &1F08000 (User Inaccessible)
 67 = &1F08000 (User Inaccessible)
 68 = &1F08000 (User Inaccessible)
 69 = &1F08000 (User Inaccessible)
 70 = &1F08000 (User Inaccessible)
 71 = &1F08000 (User Inaccessible)
 72 = &1F08000 (User Inaccessible)
 73 = &1F08000 (User Inaccessible)
 74 = &1F08000 (User Inaccessible)
 75 = &1F08000 (User Inaccessible)
 76 = &1F08000 (User Inaccessible)
 77 = &1F08000 (User Inaccessible)
 78 = &1F08000 (User Inaccessible)
 79 = &1F08000 (User Inaccessible)
 80 = &1F08000 (User Inaccessible)
 81 = &1F08000 (User Inaccessible)
 82 = &1F08000 (User Inaccessible)
 83 = &1F08000 (User Inaccessible)
 84 = &1F08000 (User Inaccessible)
 85 = &1F08000 (User Inaccessible)
 86 = &1F08000 (User Inaccessible)
 87 = &1F08000 (User Inaccessible)
 88 = &1F08000 (User Inaccessible)
 89 = &1F08000 (User Inaccessible)
 90 = &1F08000 (User Inaccessible)
 91 = &1F08000 (User Inaccessible)
 92 = &1F08000 (User Inaccessible)
 93 = &1F08000 (User Inaccessible)
 94 = &1F08000 (User Inaccessible)
 95 = &1F08000 (User Inaccessible)
 96 = &1F08000 (User Inaccessible)
 97 = &1F08000 (User Inaccessible)
 98 = &1F08000 (User Inaccessible)
 99 = &1F08000 (User Inaccessible)
100 = &1F08000 (User Inaccessible)
101 = &1F08000 (User Inaccessible)
102 = &1F08000 (User Inaccessible)
103 = &1F08000 (User Inaccessible)
104 = &1F08000 (User Inaccessible)
105 = &1F08000 (User Inaccessible)
106 = &1F08000 (User Inaccessible)
107 = &1F08000 (User Inaccessible)
108 = &1F08000 (User Inaccessible)
109 = &1F08000 (User Inaccessible)
110 = &1F08000 (User Inaccessible)
111 = &1F08000 (User Inaccessible)
112 = &1F08000 (User Inaccessible)
113 = &1F08000 (User Inaccessible)
114 = &1F08000 (User Inaccessible)
115 = &1F08000 (User Inaccessible)
116 = &1F08000 (User Inaccessible)
117 = &1F08000 (User Inaccessible)
118 = &1F08000 (User Inaccessible)
119 = &1F08000 (User Inaccessible)
120 = &1F08000 (User Inaccessible)
121 = &1F08000 (User Inaccessible)
122 = &1F08000 (User Inaccessible)
123 = &1F08000 (User Inaccessible)
124 = &1F08000 (User Inaccessible)
125 = &1F08000 (User Inaccessible)
126 = &1F08000 (User Inaccessible)
127 = &1F08000 (User Inaccessible)
128 = &0000000 (User Read/Write)
129 = &0000000 (User Read/Write)
[130->253 clipped, they're all zero]
254 = &0000000 (User Read/Write)
255 = &0000000 (User Read/Write)

End.

So there’s the obvious answer to your question. It only uses 64 entries, and maps all of the rest to DuffEntry (the 1F08000 where there’s never anything). You’ll notice that it turns up in a few of the other mappings too. Perhaps “expansion” for stuff like RAMdisc and System Sprite Area that exist but are usually unallocated? Whatever, the question has been answered. Half a meg with RISC OS and an 8K page size uses 64 of the MEMC’s 128 entries.

Why 256 CAM entries and not 128? We already had a couple of dual-MEMC systems in-house when doing RISC OS 2.00.

There are another 256 CAM entries in a separate table on RISC OS 2.01 to handle quad-MEMC A540s.

@ Rick

nice job and yes come to that conclusion, interesting the extra bit for the 64 entries, non user accessible, I did not have that detail, thanks for doing this, I could only play with it on the weekend man!

There are 256 of them.

So, first off, I am aware of memory expansions for RISC OS 2 (beyond 4MB), I am pretty sure that the Atomwide 8MB did support RISC OS 2 because it has the switches specific for RISC OS 2. With that said I have no other details, mostly forgot stuff on RISC OS 2 due too many years passed.

I agree with Stuart 256 entries is something RISC OS had to have in order to be able to use two MEMC. So even if the system has one installed the logic should still be so.

@ Stuart

There are another 256 CAM entries in a separate table on RISC OS 2.01 to handle quad-MEMC A540s.

This is interesting, always wanted to dig in how the A540 handled 4 MEMC for the 16MB, but never had time and that explains how they did it, thanks man! :)

@ Rick, Sarah and Stuart

Guys is it ok if I put all these info/details on an article on my blog to have all MEMC related info on one article searchable via google?

Obviously mentioning all of you as sources!

@Paolo – Happy to dredge the memory bank, fine by me!

I agree with Stuart 256 entries is something RISC OS has to have in order to be able to use two MEMC.

What about the four MEMCs in an A540?

Stuart said earlier:

There are another 256 CAM entries in a separate table on RISC OS 2.01 to handle quad-MEMC A540s.

;-)

@ Stuart

Happy to dredge the memory bank, fine by me!

Thanks a lot sir!