Binary Dinosaurs Computer Museum
button1Museum History button2Museum Updates button4Adverts&Reviews spaaaaace button5Moan, Bitch, Gripe scroll1
button6Inhabitants button7Reviews button8WOW! button9Contact button10Recursion 2017 scroll2
button11Links button17Floppy Recreation button13BDonFacebook button14CGE-UK 2004 button15WROCC 2006 scroll2
button16DECBOX button12Retro2017 button18Floppy Recreation spaaaaace spaaaaace scroll3
base blank_textbox

Research Machines 380Z
Originally touted as a kit-built 280Z this is the machine that started a lot of schoolkids, me included, on the road to 'proper' programming. At home I had a ZX81 that I was using to play amazing games like 3D Monster Maze and large blocky versions of Asteroids and this brought me into a totally different world. The original 380Z came in a blue and white case with blue keyboard and loaded BASIC from cassette as did the original one we had at school. Initially I tried converting BASIC listings from magazines but TinyBASIC didn't have a lot of the functions required so instead I ended up doing what a lot of people did and wrote a database application that stored blocks of records on tape.
Then we got a dual drive disk version with CP/M and BASIC4, my first introduction to it - tapes could be consigned to history! My database application suddenly became dual drive and very workable, I wish I still had a printout of it. Our machines were mono only but the platform was very expandable thanks to a 50-way interconnecting ribbon cable that linked all the options together, cards available were colour, hi-res graphics, TV modulator, RAM expansions, a Host Interface Board for connecting SASI "Winchester" disks and a high speed serial network interface called CHAIN.
This machine came to me via quite a route. Originally it was at Brunel College in Bristol where it was acquired by Peter, a very long-term friend of mine via the b3ta messageboard. He gave it to a lad in Dartford called Mick who'd stored it at work for 18 months before I drove down from Cambs to collect it.
It was a non-runner and frankly the PSU scared me :) I wasn't too au fait with PSU testing back in 2011 so restoration was shelved.
2011 Pictures
2017 Update
Fast forward 6 years and both my stock of test equipment and knowledge have expanded substantially. Having recently repaired my Link 480Z I thought it was time to tackle the machine again. Stripping it down to remove the PSU lump I discovered the wet HAD had an effect in that most of the RAM chips on the colour VDU board had rotted. Fortunately they're MK4116 DRAMs so they were easily replaced.
One of the glass fuses in the PSU was popped so it was time to tackle the dismantling job and testing the various output components - getting this PSU out of the case is no mean feat. However, I quickly found a dead short so decided to use one of my triple-output T60B PSUs for board testing. A base machine only needs the CPU and video board so I removed everything else and looked at power input. The power connector to the CPU board is a 10-way ribbon cable so armed with the PSU schematic and a DMM I traced out the connector and made up 2 new harnesses (hi-res video board needs one too), checked and triple checked everything and POP! Magic Smoke.
All the power capacitors are tantalums which can fail dead short and this is what had happened here. Normally the tant will explode but unfortunately a 12V rail trace took the brunt of the damage and failed. I replaced the dead one and retested all the others, repaired the damaged trace and this time not only did I get a steady 12V but I also got a COS prompt, first time I'd seen that since school :D
Keyboard was fine so I tested the tantalums on the 32K RAM board and floppy controller and installed them. Cleaned up the floppy drives and just for safety used another T60B PSU for power and not only did I get a COS prompt but after a few goes with a head cleaning disk it booted a CP/M disk and reported 56K RAM. Happy days. Next up is repairing the damaged colour video board and testing the PAL output board.
Update, after completely dismantling the PSU I discovered it wasn't the 12V filter capacitor that had a short, it was the (you guessed it) tantalum cap feeding the main 12V regulator. After replacing ALL the tantalums on the board and retesting the massive filter caps I hooked up an old hard drive for load and.... power up!
After putting it all back together with no pocket screws left over it was an absolute joy to see it run under its own power since the 80s.
2017 Pictures
2018 Update
The 380Z saga continues. Drive A will read the new images I'm writing from my imaging PC but B won't. B will read the disks I got with the machine as will A, but B will only write to disks it's formatted. A useful shareware utility called 22DISK can read/write CP/M disks on a DOS PC as long as you have a floppy definition built for it. The definition comes from the DPB or Disk Parameter Block of each type of floppy supported by a particular machine. Handily they provide a small 8080 Assembly routine to get this for you but not so handily is that RM only provided a Z80 assembler called ZASM with the 380Z and the mnemonics for both are completely different.
After hand-translating and assembling I massaged the DPB out of it only for it to bear no resemblance to every other DPB I looked at. So it's time for serial comms and KERMIT which is the only reliable serial comms program I've used, back in the 80s it enabled me to move things from VAX to PDP and vice versa. It was originally written at Columbia University and their kermit page still lists all the available downloads. There's 2 versions for the 380Z so I downloaded the 5.25" floppy HEX file and set about a serial transfer.
Thankfully the 380Z Service Manual details patching PIP.COM to allow use of SIO4 (the high speed serial line) and equally thankfully I had all the files needed on a floppy marked 'utilities'. After patching I had a PPIP.COM that should, in theory, talk to my XP machine. Much cable wrangling later (even the manual says this will be difficult) I got transmitting from the 380Z to work, shortly afterwards receive too so I sent over the kermit HEX file and LOADed it. Success! Only I hadn't read the instructions correctly and missed that I needed the non-machine-specific HEX lump too which is 68Kb and too big to transfer in one go.
PuTTY won't allow to insert a delay in between character sending so I downloaded RealTerm, a serial terminal emulator that allows this and a few other things. Splitting the lump into 4x 20-ish Kb sections got them all sent down and much disk wrangling later I was ready to PIP them all together. Only this PIP can't concatenate files. Attempt to merge 2x 22Kb files and you end up with a single 6Kb file that's corrupt. So! Write a BASIC program. I quickly coded up a small routine to transfer the 4 files into one big file 100 lines at a time with an ON EOF command moving over to the next input file. Trouble is BASIC 4 doesn't honour that command at all and the program crashes at the end of the first file.
BASIC 5 then. Nope. It can only have two files open on channel #10, one for input and one for output. The output file *must* be CREATED. They MUST both be closed together. BASIC 6 supports up to 179 channels AND random access files, so modern! I altered the code to create the output file on channel #21 and the inputs on channel #20 but it fails on the necessary CLOSE INPUT #20 which is the only supported command for an open input channel. *sigh*. BASIC6 was really for the 480Z and networks so I guess folk were all about the random access files onto a file server at this point.
After pondering if RAM was faulty resulting in weird disk behaviour I ruled that out with the TSTSYS command. Also I can't compile the source locally using LASM because the floppies aren't big enough.
2018 Update update
Thanks to the Abit K8V Athlon64 motherboard I can read/write SSSD floppies, and amongst various experiments I realised I was using CP/M 1.4 for everything when really I should've been using 2.2. After rectifying this 'mistake' the DPB program gave me the correct information but it didn't really help. Being able to image all my 380Z disks was a relief, though Kermit and XMODEM still elude me however :)
RML380Z Service Manual

All images and text © Adrian Graham 1999-2023 unless otherwise noted using words. Also on