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 :)