Regnecentralen RC702 reforge

[Thorbjørn Ravn Andersen]

Now I got to the point where I - with the help of the very nice people at the Danish Datamuseum - have flashed the new firmware to a 2716 EPROM and the new, tighter bios to a floppy disk, even though I have had quite a bit of problems with the serial cables where the handshake didn't work (even though they did back with cables I don't have anymore) then but Claude could help making the FTDI adapter work too under Linux (the Macbook Pro is dualboot).

Noisy but fun

 

[cj7hawk]

That looks awesome - What can you tell us about it? ( History, Specifications etc )

 

[Thorbjørn Ravn Andersen]

That looks awesome - What can you tell us about it? ( History, Specifications etc )

It is a Danish CP/M-80 computer which was made into a product after the Danish company "Regnecentralen" (meaning "calculation central" in the sense of computation) went bankrupt in the late 70'es. My guess is that they were already looking at making their own terminals towards the bigger computers they made then and they then found out that it with a few modification could become a nice CP/M machine to sell to businesses and schools.

I learned to program on it in Comal80 (Danish structured basic dialect) and PolyPascal (the older sibling of Turbo Pascal), and was so fortunate I got my own when the local university upgraded their student labs. I used it the first years I went to university for hacking CP/M reverse engineering the BIOS, and dial up to the university until I got a PC around 1994-ish.

It is a 4 MHz Z80A machine with 1-2 floppies (8"/5,25" depending on model) and an optional harddisk for those really needing it. Glass tty (non-vt100 emulation), Z80PIO with their own keyboard connecting to PIO-A, and printer+serial port on Z80SIO. There is a 2 KB boot prom with an optional 2KB extra prom.

I found my old diskettes and a printout of the heavily hacked BIOS a few years and decided I wanted to preserve that, and then borrowed another one trying to get things working but got stuck on getting a serial cable that was working (not many 8" equipped PC's around). With the arrival of modern AI-supported development (Claude does very, very heavy lifting) I got going again and have been using MAME as the emulator for reverse engineering the boot prom and the original bios into C and optimize it with a modern compiler (there is a separate thread in here about that). The other day I decided to break out of emulation and get it up and running on the physical machine. So, new boot prom (with room to spare even) and new BIOS that I got up and running two days ago (serial communication without proper handshake is rather error prone) but yesterday Claude figured out how to program the FDTI USB adapter I have to work with the cable I had so now handshake works. Next step is having claude implement the IOBYTE so console I/O can be redirected to the serial port, so Claude can control it remotely over the serial port speeding up the development process immensely

The ability to use modern compilers for the Z80 (even if it is still embryonic) really helps with tight spaces. llvm-80 generates better code than z88dk/zsdcc!

 

[Thorbjørn Ravn Andersen]

I am still having great fun with this. Reached a point where I also need some user space programs for things like setting serial port properties, and locale translation tables, so I needed a full runtime library for CP/M, and decided that the easiest way to do that was through the platform support in z88dk. Then I saw that there were experimental support for another z80 llvm backend in z88dk and now I got it to support my work as well. I needed a non-trivial testcase and z88dk already had Dhrystone so these are the current numbers:

Dhrystone 2.1, @ 4 MHz Z80, 20000 runs:

• llvmz80 -O2 — 8461 cycles/run, 0.2691 DMIPS (register, z80 16-bit ABI)
• sdcc --sdcccall 1 -SO3 — 11044 cycles/run, 0.2061 DMIPS (register: args HL/DE, ret DE)
• sdcc --sdcccall 0 -SO3 (z88dk default) — 12158 cycles/run, 0.1872 DMIPS (stack, IX frame, callee cleanup)

Key finding: switching sdcc to register-passing (sdcccall 1) buys −9.2% cycles / +10% DMIPS, but llvmz80 is still 30.5% faster than sdcc even with sdcccall 1 — so the calling convention explains only ~a third of the gap; the rest is LLVM's middle-end (inlining, loop deletion) + register allocation.

I do not know what the optimal runtime is, but I think we are catching up on raw assembly