Who has RISCiX sources?

Hi everyone, probably this question has already been answered before…

Does anyone know who has/own RISCiX sources and if it’s possible to have a look at them?

Thanks

No, and it* was licensed to Acorn for a huge sum, probably when it still had AT&T licensed code, so it ought not to be made freely available

[Edit: the 4.3BSD source, not RISCiX!]

[Just looked on Wiki and BSD themselves ended up in court with AT&T]

[Edit2: I have a horrible feeling that – prior to this – Acorn had licensed SVR3 as well!]

Thanks Stuart!

Bit of a shame, RISCiX kernel would have been interesting…

Wasn’t there a BSD port to the A-series machines? I know there was Linux. I ran it on an A5000.. I say ran.. it wasn’t fast.

Yes, RISCiX was based on 4.3BSD

We used it on an A440 as our email gateway at Colton Software

There was also RiscBSD, a (large for the time) free project which I ran on my RiscPC as an alternate boot. I don’t know if it was StrongARM or Kinetic safe – I recall /something/ stopped me using it later on.

At the time, it was an interesting learning gateway into unix-esque operating systems, and it ran x windows with a few simple window managers (twm?). However, I never had any real use for it, and it reinforced how fast RISC OS was! For may needs, RISC OS did everything I wanted (except RPGs which I ran on the PC card), so BSD was simply a curiosity.

IIRC it was mainly developed by two guys, Mark something (Brinicombe) was one of them, and I’m sorry but I forget the others.

(Later) It is still mentioned on the NetBSD site here… http://www.uk.netbsd.org/ports/acorn32/history.html

The Acorn32 port which covers RiscPC era hardware seems to be up-to-date with NetBSD 8.1, believe it or not. The older Acorn26 version was dropped in 2018 though. There seems to have also been an iyonix port, although it doesn’t seem to have had many commits.

RISCiX, RiscBSD and later ARMLunux could run on the Archimedes class machines, but really exposed the weaknesses of a 32KB page granularity, slow memory and even slower IO. It was like treacle compared to RISC OS on those machines. Although they did serve to be able to prototype unix stuff, when access to much tastier hardware was limited.

Ironically these days on the same hardware Linux is far quicker than RISC OS for most things, thanks to being able to use multiple cores, and file system caching in memory.

I do remember – even before RISCiX came out – Steve Furber commenting in an electronics weekly that ARM was unsuitable for Unices because of the 32KB page size.

I recall somebody saying that the TLB was back to front. Never quite understood what they meant by that.

So there were actually quite a few:

NetBSD (the NetBSD community maintained the code for RiscPC/ A7000 for very long time), their classification was Acorn26 and Acorn32. Acorn26 was abandoned years ago. Acorn32 is still maintained: http://wiki.netbsd.org/ports/acorn32/

NetBSD does run on both StrongARM and Kinetic. While NetBSD Acorn26 should run on all the Archimedes and A series, but honestly I would not recommend to even try it if the Archie has less than 8MB RAM.

RiscBSD was a “somewhat packaged” NetBSD for RiscPC (never tried it on an Archie since all my Archies had max 4MB RAM and that was a little too few for ARMLinux/NetBSD if wanted to be used with X11 Windows protocol and a DM like TWN)

ARMLinux in CLI mode runs “ok” on Archie, I did compile and installed it, but with X11 + a DM was no go for me really.

RISCiX was the “most viable” of them all (at least of the ones I have tested), indeed the X11 + a DM was usable on RISCiX. IMHO it was the only one usable with X11 of them all.

I did manage to run NetBSD fine on my StrongARM 233 RiscPC and my kinetic RiscPC. It was definitely usable in CLI and I managed to build and run X11, but I remember it taking forever to actually start X11. I still have a RiscPC with NetBSD and I try to keep it up-to-date (when I have time).

Anyway thanks everyone for all the good info, very much appreciated! Yes the 32KB has always been a big problem, but the biggest problem with Linux is actually that Linux makes a lot of assumptions that are based on the x86 architecture, so (especially at the beginning) it was just very slow.

@ Rick

I recall somebody saying that the TLB was back to front.

Yes the “TLB” on the MEMC worked “up-side-down” compared to how other MMU TLBs work, which is probably why you heard people saying that the MEMC TLB was back-to-front.

Given that the MEMC had a fixed number of entries (128 IIRC) to map the virtual pages to physical pages, when a virtual page number was matched in the look up table, the correspondent physical page number (which was the number of the entry who matched, IIRC) was sent to the DRAM which then had to contain the address (sorry for the bad explanation, but it’s 3:00am). Someone said it was the page that “had to declare that the virtual address was its own” instead of having a TLB matching virtual addresses to physical ones like it happens on most MMU.

This (as we all know) was also the origin of the feared 32K page size: 4096KB RAM / 128 entries = 32k and the MEMC obviously had 512KB RAM / 128 entries = 4K page, 1024KB RAM / 128 entries = 8K page size and 2048KB / 128 = 16KB page size.

The other thing I remember about RISCiX is that it would only run on the R-series machines, as it needed a specially modified backplane (something to do with interrupts) and a SCSI controller. There were rumours someone had hacked it to run on the A540, but I can’t remember any details.

I think that the first Ethernet podule designed for RISCiX couldn’t have interrupts turned off on the board, hence the need to have GALs on the backplane to mask them off.

MEMC is very straightforward, 128 entry content-addressable memory to do immediate virtual-to-physical translation. No page tables in memory or the like. And not even connected to the data bus.

I think that the A305’s memory system was that of a half-populated A310, and actually still ran with an 8KB page size

4096MB RAM / 128 entries

be helpful to edit those MB to KB for future reference!

Apologies if this is slightly off topic. At the school of Mathematical and Physical Sciences at Sussex University in the 80s we had a RISCix server at some point. I seem to remember it had rather a nice GUI by Gnome. Each directory could have a hidden file that specified the user-action bindings of the GUI local to itself. This was on top of X11. I do not know how efficient that was, but it was more flexible than the RISC OS GUI.

It would be interesting to know how RISC iX was used at Acorn. Did RISC iX workstations take over from other “enterprise” systems when it became ready for use? And why did Acorn give up on it – a lack of resources or just focus on core markets? I suppose this has at least some bearing on what happened to the sources. ;-)

The sources, and build instructions, would have been lodged in the Drawing Office at Acorn i.e. they are lost!

Given that the R140 was launched in January 1989, was that the first time that RISC OS 2.00 made it out into the wild? (other than to devs with A500s). Must have been on EPROMs.

@ Stuart

be helpful to edit those MB to KB for future reference!

duh! Sorry, 3:00am factor! loool :D

I think that the A305’s memory system was that of a half-populated A310, and actually still ran with an 8KB page size

Hummm interesting, so the MEMC does 4K pages, so does anyone knows how the 305 (which yes had only 512KB RAM) managed to have 8K pages?

I think that Arthur only supported 8KB and 32KB page sizes

With RISC OS 2.00 we supported 16KB page size as well for the upcoming A420/1

@ Stuart

Thanks, I think I see what was going on back then on RISC OS 2 with 512K

Basically probably Acorn simply programmed the “TLB” using the 8K page size map also for the 512K, so my understanding is that both the 305 and the 310 had the MMU programmed in the same way using 4096 logical Pages:

25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
 1  1  1| L  L  L  L  L  L  L  L  L  L| -| L  L| S  S| -| P  P  P  P  P  P  P

Where:
L = Logical Page Number
P = Physical Page Number
S = (Security) Protection mode bit
- = Unused (or I don’t know what it was for)

Now, if I got this right, the only difference between the 305 and the 310 would have been that the MEMC could rise ABRT signal when the requested physical page did not exists (so pretty much like in a not found situation or in a not accessible), but I am guessing…

I ran RISCiX on an 8MB A540 at one point although don’t recall how I installed it. I also installed ArmLinux on an A5000 at uni via floppy disc. I had fewer discs than were needed so it was a long process of head down to the lab and copy the first 10 discs. Go back to flat and install them then when it asked for 11 take the discs back and copy 11-20 onto them.. only to find it wanted disc 8 again. Or couldn’t read one of the discs ..

I think that Arthur only supported 8KB and 32KB page sizes

I think it depends upon version – Arthur 0.30 failed with a 4MiB emulated machine (screenshot: http://heyrick.eu/random/pics/arcem_arthur_fail.png) whereas Arthur 1.20 worked.

Acorn simply programmed the “TLB” using the 8K page size map also for the 512K,

It was probably for simplicity. If you read the MEMC manual, it says: When less than 512KBytes of DRAM is connected to MEMC, a page size of 4KBytes should be used, but note that two or more Physical pages will now map onto the same address in the DRAM.

would have been that the MEMC could rise ABRT signal when the requested physical page did not exists

Mightn’t that be a difference between the MEMC1 and the MEMC1a?

@ Rick (thanks for the thoughts!)

It was probably for simplicity. If you read the MEMC manual, it says: When less than 512KBytes of DRAM is connected to MEMC, a page size of 4KBytes should be used, but note that two or more Physical pages will now map onto the same address in the DRAM.

But that is not necessarily a bad thing, in the sense that with 512KB you do want to have an exception anyway for physical pages beyond that, so to have such an exception you can either trigger a “not found” OR (on the MEMC) you could map the next 64 entries to the same page. The MEMC would throw an exception also when two entries would mach the same virtual page (AFAIR). However the “not found” is probably a better approach hence the 8K page size… (again I am guessing in the sense that this is what I would do, but that doesn’t mean that’s what Acorn developers did lol)

Mightn’t that be a difference between the MEMC1 and the MEMC1a?

Good point, but didn’t the MEMC1a fixed the bug on allowing Podules that used PIO for data to use LDMIA/STMIA to IO space? and yes it’s a question, because I don’t remember this well, but I do remember that MEMC1a “effect” was all about computer performances on both general memory access and some IO, so does anyone has details on the difference between the MEMC and the MEMC1a?

BTW thanks a lot guys! :)

MEMC has no idea whether there is any physical memory connected – it raises an abort if there is no mapping in the CAM for the virtual address accessed

I have this vague memory that the PAL on the A310/A440 was used to slow down some accesses on early Archimedes (not A500s!) due to a problem with MEMC1 on those boards. MEMC1a came with a new PAL, and did indeed speed general memory access:

"At Thu,17 Nov 1988.14:38:13 mail was sent to ***,***
About New 400 series better than ever
Text:
I just repeated my timing test code on the new 400 series board, results expressed relative to my a500:

    a500  8MHz 100%
    a500 12MHz  89%
old a440  8MHz  91%
new a400  8MHz 107%

I believe that the PAL fix for 2 micron ARM and MEMC 1 delays IO cycles less than that in the old a440; removing this PAL for MEMC 1a improves matters greatly. The 12MHz a500 slowdown is due to the synchronisation delays between the memory and IO systems."

A quick look at the A310 circuit (https://www.retro-kit.co.uk/page.cfm/content/A310-RAM-control-line-repairs/) 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 – see the RAM address bus values for different page sizes table in the MEMC doc where RA8 appears indeterminate when the row address is presented to the DRAM. Anyways, I don’t think that Arthur ever considered using 4KB or 16KB page sizes. RISC OS didn’t support 4KB either if I remember.

I did some digging on MEMC1 vs MEMC1a performance last year – see https://stardot.org.uk/forums/viewtopic.php?f=16&t=15865&p=247851#p247851

I’m guessing that item 1 in the linked post only applies to A3xx/A440 (as it’s implemented in the aforementioned PAL), but the other two should apply to A500 as well.