CP/M on the TEI Processor Terminal

[C//D]

Hello all,

I am seeking advice on a project of mine, the long and short of it is as follows; I have been restoring a Tei PT S-100 machine and, after a power supply fix and one new RAM chip it is fully functional as far as I can tell. This machine wouldve orignally shipped with CP/M 1.4 but of course no software disks are available, so I have taken it upon myself to port CP/M to this beastie. This is where the problems start. While I understand the process, and have even typed up the CBIOS from documentation provided to me by a fellow enthusiast. Ive found a few (almost) tutorials, and of course have read the CP/M 2.2 system alteration guide, and i have downloaded a copy of CP/M in assembly from this site, but really I am a hardware guy and understanding all this assembly language stuff is making my mind boggle. Therefore I am seeking a little help from the community.

My documentation bundle on this machine is located here which contains all the information I should need for generating a system disk (in theory). I've also attached the ROM to this post along with a picture of the machine itself before i received it. (note, you will need to change the extension of the .txt back to .bin).

Really i'd appreciate any pointers you can give me on how to progress from this point onwards and what tools I will need to use. Many thanks.

 

[durgadas311]

Usually vendors wishing to support multiple memory sizes would ship a MOVCPM.COM which contains the entire OS (CCP, BDOS, BIOS, and bootstrap) in a relocatable form and is used to generate a copy in memory for the desired memory size. After that, SYSGEN.COM is used to write that image onto a floppy for booting. But there's always an issue for creating the first boot disk for a given system, which usually requires being able to run all that on some other CP/M system with compatible floppy disks. If you are going to create the first floppy on a modern PC, using some sort of program for writing a custom floppy image, then it is a bit easier. If you are not concerned with supporting multiple memory sizes, it is a bit easier as you just compile the BIOS for the target RAM address. Reading a little of the documentation you referenced seems to imply that their "sysgen" procedure is different (less flexible). I'm not yet sure exactly how they did all that. The good news is that if you can find a neutral enough copy of MOVCPM.COM from some other system (CCP and BDOS should be the same most everywhere), you can probably splice your BIOS and bootstrap into that. But SYSGEN needs to do the right thing with the bootstrap.

Traditionally, the boot tracks of the floppy contain the following, starting at track 0 first sector: bootstrap (one or more sectors - depends on the ROM code), CCP, BDOS, then BIOS. I'll see what I can tell from the ROM about how that is read off the floppy.

 

[durgadas311]

So I got some info from disassembling the ROM. First off (this might be already known), it looks like the 8" drive version is single density (IBM3740, 26x128-byte sectors/track). And the 5.25" drive(s) use double-density at 18x128-byte sectors/track. I guess you got the version with two 5.25" floppies.

The BIOS source listing in the document you referenced looks to be correct, and seems to match the ROM disassembly. So that seems like a good starting point.

The first sector on the disk (track 0 sector 1) has the following (no bootstrap code):

0000:    dw    load_addr
0002:    db    'boot message...',0

Then starting with (track 0) sector 2 the ROM loads sectors into memory starting at the load_addr. It loads the remainder of track 0, the for the 5.25" disks it loads all of track 1, and the last track it loads the number of sectors required to total the system size (overall, 16 for CCP, 26 for BDOS, and 4 for BIOS). Fortunately, the BIOS can call the ROM for most functions, and so you should be able to keep it under 0200H bytes.

 

[C//D]

So I got some info from disassembling the ROM. First off (this might be already known), it looks like the 8" drive version is single density (IBM3740, 26x128-byte sectors/track). And the 5.25" drive(s) use double-density at 18x128-byte sectors/track. I guess you got the version with two 5.25" floppies.

The BIOS source listing in the document you referenced looks to be correct, and seems to match the ROM disassembly. So that seems like a good starting point.

The first sector on the disk (track 0 sector 1) has the following (no bootstrap code):

0000:    dw    load_addr
0002:    db    'boot message...',0

Then starting with (track 0) sector 2 the ROM loads sectors into memory starting at the load_addr. It loads the remainder of track 0, the for the 5.25" disks it loads all of track 1, and the last track it loads the number of sectors required to total the system size (overall, 16 for CCP, 26 for BDOS, and 4 for BIOS). Fortunately, the BIOS can call the ROM for most functions, and so you should be able to keep it under 0200H bytes.

So just to check I am understanding you, as long as I don't use an address that clashes with video RAM or the ROM (or any address below E000) as 'load_addr', whatever text I put in the first sector should appear on screen as the next line of text, no questions asked?

 

[durgadas311]

Right. There was a special case for what I think are "diagnostics" disks, where a fixed size image is loaded at a fixed address, this should work as long as the load does' not overrun anything. But, the size of the load is fixed and hard-coded into the ROM, so the load address just needs to be low enough to avoid overrun.

 

[SteveH]

Right. There was a special case for what I think are "diagnostics" disks, where a fixed size image is loaded at a fixed address, this should work as long as the load does' not overrun anything. But, the size of the load is fixed and hard-coded into the ROM, so the load address just needs to be low enough to avoid overrun.

I agree. It appears that if the first byte of the load address on track zero sector 1 is the value 99H, then it will load 600H bytes (12 x 128 byte sectors) into memory starting at the fixed address EA00H. This could be some diagnostic tool or anything you like.

FYI, if any read or write instruction fails, it outputs the status byte to port 255. As far as I can tell, this will light up the 8 LED lights on the keyboard, thus indicating what the status bits are.

I've disassembled C//D's disk system prom (just F000H to F3FFH) as it differs from the listing in the PDF documentation - copy attached. I used Zilog mnemonics simply because I personally find it easier to read than Intel mnemonics. I did however, use the comments from the PDF documentation. I've added my own comments, prefixed **, in a similar style to the original source.