1982 British built LSI M-THREE computer restoration project

[SteveH]

I’ve been slowly renovating an early 1980s British built computer that I acquired this year and thought it’s high time I posted a few pics here. The system in question is an LSI M-THREE/250 computer - it’s a bit of an ugly duckling, but it’s also one of the first business class machines I used whilst on an IT based youth training scheme.

When I got it, it was in poor condition after being stored in a loft (attic) for 20+ years.

Here’s a close up of LSI M-THREE screen showing the breakdown of the bonding material between the CRT and safety lens. Fortunately, it wasn’t difficult to remove the safety lens.

This is the inside of LSI M-THREE fascia, prior to cleaning. A date stamp of 11 March 1982 can be seen on the drive zero bay - unfortunately, this washed off during the cleaning process

This is the main board prior to cleaning. Most chips appear to be date coded 1981. The EPROM labelled 033 holds the MC6845P CRT controller character font and the one labelled 034 holds the bootstrap loader prom. The empty socket is where the hard disk drive handler prom would reside in a Winchester model machine. As I later discovered, it turns out that the hard disk drive handler prom socket is a handy place to install a monitor prom

Five's the limit, so more pics in the next post...

 

[SteveH]

Here we have the massive keyboard uncovered. It’s basically as wide as the system unit and connects via a 25way cable. Also of note is the piezo buzzer on the keyboard PCB - the only source of sound from this machine (other than the fan and the two floppy drive motors constantly running).

This is the system cleaned, power supply repaired (cleaned and all paper capacitors replaced) and re-assembled. The dark shadow around the left and top of the screen is due to the safety lens not yet being fitted.

As I’ve already mentioned, the machine has a socket for a hard drive prom. From disassembling and commenting the boot/bios prom I found that if it detects the presence of a hard drive handler prom it prompts to boot from floppy rather than just booting directly from floppy. Any response other than ‘Y’ causes it to jump to the hard disk prom. So that’s where I placed my monitor.

Reachedthe limit again, just a couple more pics to come...

 

[SteveH]

I’ve also noted the mainboard component layout and chip/socket identification details.

I've also got the operators manual which lists all models in the LSI M-THREE range including their specifications. I've scanned it and will look at getting it uploaded somewhere (I'll check with Al over at Bitsavers),togetherwith the EPROM dumps and my monitor prom source.

Next steps, write my own flavour of CP/M for this machine. Also thought of adding a hard drive, based on something like James’ lo-tech TRS-80 adapter, but plugging directly into the Z80 socket via a shim wire wrap socket/board.

 

[pearce_jj]

What is the unpopulated part of the PCB? Perhaps you could hook in there.

 

[Moonferret]

Great work with the restoration! When I saw the first photo I thought it was a luggable like the Osborne/Kaypro. Didn't realise they were 8" drives!!

 

[SteveH]

The unpopulated section is for an optional IEEE 488 GPIB circuit. As the silkscreen lists the missing components, I was contemplating whether to add them or not, hence my thought of attaching a hard disk adapter (using a CF card) directly to the CPU socket.

 

[SteveH]

Yeah, you could say it's a bit bigger than an Osborne or Kaypro - The width is just over 25 inches and it weighs around 78 lbs (most of the weight is down to the SA-851 drives).

 

[Rick Ethridge]

Very classy!

 

[jharre]

That is a good looking beast of a machine now that you've done some cleaning. Have you put it on a scale? Just looking at it, I'd guess 50-60 pounds.

Jim

 

[SteveH]

Have you put it on a scale? Just looking at it, I'd guess 50-60 pounds.

No, I've not weighed it, but I've just double checked the operators manual and it states this model with keyboard as coming in at 77 pounds.

 

[tingo]

A nice restoration of a classy machine. Well done!

 

[soviet9922]

Impressive work.

 

[SteveH]

Impressive work.

Thanks.

Since this was first posted, I've written a CP/M 2.2 CBIOS for it that makes use of the 36 programmable function keys, patched CP/M to use the ZCPR CCP replacement and have it running with a HxC floppy emulator (which is much quieter than the two Shugart 8" drives). Next steps are to add a simple 8 bit IDE interface and patch my monitor prom to allow booting directly from IDE HD or SD card and re-writing the LSI utilities mentioned in the LSI M3 Operations manual.

Booted into CP/M 2.2 with ZCPR:


Programming the function keys:


And why not, playing Aliens

 

[roberttx]

That's a fantastic job, well done! I had forgotten about LSI - didn't they have an OS called Elsie, or something?

A date stamp of 11 March 1982 can be seen on the drive zero bay - unfortunately, this washed off during the cleaning process

This is just me and others may disagree but, as you have photographic proof of the original date stamp, I don't think that it would be unethical to replicate it. That looks like it was done with a bog standard date stamp, so it should be easy to do. You could tape a piece of paper next to it that read "Replica of original stamp which was lost during cleaning" if you had any concerns.

 

[startaq]

I took a stab at emulating this machine in MAME:

It mostly works, however the floppy hookup isn't finished since I don't have any disks. The import of files over the RS232 port works too:

Would be great if any software for this machine shows up.

 

[SteveH]

Wow, I never thought anyone would emulate this machine. I'd love to get a copy when you've finished.

I generated a later version of the monitor prom that caters for booting from an IDE (Disk-On-Module) hard drive. It uses the uIDE HD interface created by user JonB on this forum.

We moved house 12 months ago and the M3 is currently still boxed up. It'll take me a few days, but I'll get back to you with a copy of the updated monitor prom and my disk images.

Cheers,
Steve

 

[JonB]

Hi Steve

I'm interested in your ZCPR implementation. As you know I am a bit of a Superbrain buff, and I would like to extend the uIDE functionality to offer a boot choice from multiple partitions. On a CP/M machine this really means "with different BIOSes" but could also mean "different BDOS/CCP". Z80 machines like the TRS80 Model II or III/IV have alternative DOSes to choose from: TRS-DOS, LDOS, CP/M so it makes sense on those machines (only, there's no boot from IDE option yet). There is a thing called USCD p-System for machines like these, that appears to be a sort of Pascal programming environment that you boot into. This might be a good candidate for a multi booting IDE drive.

Anyway, any ZCPR pointers appreciated..

 

[SteveH]

Hi Jon,

You will find there are several different replacement CCPs available for CP/M, some quite closely related or having forked off one another, such as CCPZ, ZCPR, NZCPR, etc. It can get confusing. I simply went for ZCPR 1.0 as it included some of the features I wanted, plus didn’t require any other changes (later versions need CBIOS changes) and fits in place of DRI’s CCP without requiring additional memory.

The installation steps are something like this.

1. Compile and run the supplied BDLOC program to determine your BDOS base address
2. Modify ZCPR.ASM, changing the CPRLOC equate to be your BDOS base address
3. Use DDT to integrate ZCPR.HEX into your machines version of SYSGEN
4. SYSGEN a new bootable CPM ZCPR disk

As I haven’t got a SYSGEN for the M3, I used DDT to load the HEX file into RAM then called my monitor prom to write directly to the sectors where the CCP was. This worked for both floppy disks and the uIDE.

ZCPR does come with a DOC file details all of the steps, but you would need to tailor them for the SB.

Not sure how you’d go about making the SB actually boot from different uIDE partitions though. I suppose one way would be to reserve some space at the start of the uIDE for a multiboot cold start loader and then have the actual drive partitions offset to start after the cold start loader. Another way, would be to have the cold start loader load the required CPM system from a file, much the way CPM+ works. Although for CP/M 2, you’d also have to modify your CBIOS to handle warm boots from the relevant CPM file. Needs some more thought?

 

[JonB]

Hi Steve

If the ZCP is the same size as the DRI CCP then it is a pice of cake to build it into my code. I have the whole of CP/M plus BIOS with uIDE drivers as source, so it's be a simple cut/paste job then a rebuild. Easy peasy. You didn'r explain how you impleneted your IDE drivers for the LSI, but I'd assumed you'd dumped / disassembled the whole of CCP/BDOS/BIOS to generate a working set of source code, then amended that. If you patched with DDT than SYSGENed it, well done, that was pretty good going.

I surmise that the ZCP makes space for extra features by dropping built in commands like DIR and TYPE. Is that so?

Regarding multiboot.
The "native" uIDE disk format reserves boot tracks on every partition. If you used the diskdef I gave you, you'll have this too. So, yes, the first stage boot loader (lives on the very first sector of the DOM) would have to be modified to add an offset to the start of the CP/M load routine; that offset being the start of the selected boot partition. However, we're not out of the woods yet, as we need to implement a sort of "user selection" in the case of multiple boot partitions.

I can think of two ways of achieving this:

1) use XMAP.COM to specify the partition for next boot. Only works if your driver has a mapping table, and you'll need to hack it up to match your map format / location; and
2) detect bootable partitions in the boot ROM or first stage boot loader and present a boot menu. The main problem with that is the ROM has zero space, not even a single byte free, and the first stage loader doesn't have any of the screen handling code so can't display anything (on the SB it needs an ISR to load the screen data into the VDP when the CPU isn't looking). Not impossible, but quite complicated as you'd need a sort of cut down BIOS just to present a menu. Another problem with this is usability, because the SB already asks for input on boot up (F for floppy, any other key for uIDE) and presenting another option after that is klunky.

It might be nice to remove the boot prompt and get the thing to try a floppy boot first, then fall back to IDE boot if no boot disk is found, as an older PC does. For me, though, that would be a pian on the SB II as it has a Gotek with bootable image fitted to A:

Cheers
JonB

 

[SteveH]

Hi Jon

If the ZCP is the same size as the DRI CCP then it is a pice of cake to build it into my code. I have the whole of CP/M plus BIOS with uIDE drivers as source, so it's be a simple cut/paste job then a rebuild. Easy peasy. You didn'r explain how you impleneted your IDE drivers for the LSI, but I'd assumed you'd dumped / disassembled the whole of CCP/BDOS/BIOS to generate a working set of source code, then amended that. If you patched with DDT than SYSGENed it, well done, that was pretty good going.

ZCPR 1.0 is a simple replacement as it's the same size as the DRI CCP. IIRC ZCPR 2.0 and 3.0 are both larger, plus as I mentioned they also require additional BIOS changes.

The LSI M3 didn't have any software when I restored her, so I rolled my own BIOS, linked it to DRI's CCP and BDOS, all on a laptop, and sent the resulting hex file to the M3 over RS232. Then manually saved that via calls to the prom (as I didn't have a SYSGEN). The uIDE driver I later built into the hard disk driver prom and then updated my BIOS to handle floppy and hard drives. It was around this time that I also hand patched in ZCPR 1.0 - I'd located the sectors where the CCP resided, so just loaded ZCPR into memory then called the prom routine to write that memory over the CCP sectors. A warm boot and she was running ZCPR CPM!

I must really get around to knocking up a SYSGEN some day

I surmise that the ZCP makes space for extra features by dropping built in commands like DIR and TYPE. Is that so?

In fact it's the complete opposite - they added extra commands! ZCPR was a complete rewrite using the z80 bells n whistles to fit it all in.

Regarding multiboot.
The "native" uIDE disk format reserves boot tracks on every partition. If you used the diskdef I gave you, you'll have this too. So, yes, the first stage boot loader (lives on the very first sector of the DOM) would have to be modified to add an offset to the start of the CP/M load routine; that offset being the start of the selected boot partition. However, we're not out of the woods yet, as we need to implement a sort of "user selection" in the case of multiple boot partitions.

I can think of two ways of achieving this:

1) use XMAP.COM to specify the partition for next boot. Only works if your driver has a mapping table, and you'll need to hack it up to match your map format / location; and
2) detect bootable partitions in the boot ROM or first stage boot loader and present a boot menu. The main problem with that is the ROM has zero space, not even a single byte free, and the first stage loader doesn't have any of the screen handling code so can't display anything (on the SB it needs an ISR to load the screen data into the VDP when the CPU isn't looking). Not impossible, but quite complicated as you'd need a sort of cut down BIOS just to present a menu. Another problem with this is usability, because the SB already asks for input on boot up (F for floppy, any other key for uIDE) and presenting another option after that is klunky.

In order to maximise the M3's CPM TPA space I only cater for 2 floppy drives and 2 hard drives. The other hard drive partitions are still present and I did something similar to your XMAP to map in the other partitions. I added a simple logical-to-physical table into memory above the BIOS and an extra BIOS call that returns the address of that table (just so I don't have to hard code it into programs). Then my equivalent of XMAP updates that table and performs a BDOS drive reset function.

Cheers,
Steve