Hacking RS-232 communications between my Altair 8800 and a PC app

SolidWorksMagi

Senior Member
Hi,

I want to figure out how the hardware on my Altair 8800 computer communicates with a Serial Drive Server app running on my Windows 10 PC.

Essentially, I need to see how to select one of four .DSK files and read/write to a .DSK file on my PC from CP/M running on my Altair 8800 computer.

I do have RS-232 to TTL adapters, but to see the full communications I need a way to capture each command and response live talking between the Altair 8800 and the Serial Drive Server app running on my Windows 10 PC.

I figure a PICAXE chip (20M2 or maybe 28X2) could be the in-between of the conversations, but although one way might be fairly easy, a two way conversation between the two computers seems like it might not work. ???
 

PhilHornby

Senior Member
I do have RS-232 to TTL adapters, but to see the full communications I need a way to capture each command and response ...

...but although one way might be fairly easy, a two way conversation between the two computers seems like it might not work. ???
You used to be able to buy a device to do this, "back-in-the-day"; it was dedicated piece of hardware, called a Datascope. It had a screen, keyboard and plug-in analysers and cost £many. The modern equivalent is something like this (and is still not cheap).

For a DIY approach, you're going to need two RS-232 to TTL adaptors, i.e. across the TX and RX lines. Each will have its own comm port on the PC.

I would suggest using something like Realterm to monitor the comms., rather than writing your own for the Picaxe - at least initially. Realterm is not my favourite Terminal Emulator, but it's quite good at the that job.

(Depending on the speed of the comms. link, you may find that a Picaxe can't keep up anyway :( )
 
Last edited:

Buzby

Senior Member
'Back-in-the-day', I had a freeware version of something similar.
It read two-way coms by using a PC with two serial inputs, one to monitor each direction between the two target devices.
I used it a lot, until Windows stopped supporting the dual-serial card I used.

To use a PICAXE should not be too difficult.
If the baud rates are slow enough, and the devices 'take turns' nicely, then some SERIN instructions should manage OK.
If the rates are too fast, or comms overlap, then I would use HSERIN on two PICAXE chips, with I2C comms between them to syncronise the data flows.

However, as one of your devices is a fast Win10 machine, I think there is a software package that can 'snoop' both directions of a COM port which is being used by a seperate app.

A bit of Googling will find the app I'm thinking of.

Cheers,

Buzby
 

Goeytex

Senior Member
One of those cheap 8 channel logic analyzers might be a good solution. With either Sigrock Or Saleae software the serial data can be decoded and analyzed rather easily. Both supports both Inverted and True data polarity at just about any baud rate. I prefer the Saleae software Ver 1.2.29. Others might prefer the Sigrock.
 
Last edited:

erco

Senior Member
Please figure it out, I have my Dad's IMSAI 8080 in several pieces and am still wondering what to do with it. BTW the front LED panels in these are worth a small fortune.
 

SolidWorksMagi

Senior Member
Please figure it out, I have my Dad's IMSAI 8080 in several pieces and am still wondering what to do with it. BTW the front LED panels in these are worth a small fortune.
Hi,

I am in a couple of vintage computing groups, the value of 1975 to about 1980 computers has crashed over the last year because pretty much all the big-buck collectors have everything and several of the museums have closed and flooded the marked with machines and parts. There still are some extremely hard to find chips, but OTOH, now there are reproduction boards for almost everything to make it more affordable to repair machines.

I have a small stash of boards that I trade with others to get boards I need as I am trying to build an IMSAI 8080 ... too poor to just go blow $1,000 on one.
 

SolidWorksMagi

Senior Member
I installed the RealTerm software, I'm going to try that first to see if I can "tap into" the COM port as my Altair 8800 talks to the PC software. I just have to get it figured out for the console port first to know how to get it setup for the odd BAUD speed of the other serial port on the Altair 8800 computer.
I've used PuTTY a little, but don't like it so much and have used TeraTerm a lot, but now I have external dumb terminals on my computer other than one app that serves the Altair 8800 with disk files.
 

SolidWorksMagi

Senior Member
Hi,

I've been screwing around with RealTerm ... it's very comprehensive, but it will not let me tap into the COM port that my app is using. I just want to capture the data going back 'n forth with my Altair 8800, but that doesn't seem to be allowed.
 

Flenser

Senior Member
I want to figure out how the hardware on my Altair 8800 computer communicates with a Serial Drive Server app running on my Windows 10 PC
I don't think that you can connect a serial terminal to a COM port that is already in use by some other app. i.e. I don't think that you will be able to use a serial terminal to "listen in" on the comms between your Altair 8800 and the Serial Drive Server app.

It sounds like you are after a "serial port monitor" app rather than just a serial terminal app like RealTerm.

Will one of the free apps in this post enable you to find out how the 8800 comms works?
 

Buzby

Senior Member
I must learn to read the posts properly, and do a bit of research before commenting.

It looks like you have the FDC+ board in your Altair, and are using it to connect serially to a PC acting as a Disk Drive, with a .dsk image acting as the actual disk.

Looking at the protocol for the comms, it looks simple but very low level. The 'highest' functions you can perform are read and write tracks.
I cannot see how you could use the protocol to change the .dsk image that the drive is using, or have I missed something ?.
 

hippy

Technical Support
Staff member
Looking at the protocol for the comms, it looks simple but very low level. The 'highest' functions you can perform are read and write tracks.
I cannot see how you could use the protocol to change the .dsk image that the drive is using, or have I missed something ?.
It seems to me the PC-side Server app holds an image of a complete virtual floppy disk which the Altair perceives as a real one, the track-by-track contents of what would be on a real floppy being the same on the PC making up that virtual floppy. The Altair wants to read a floppy track, does so, and doesn't know that track came from the PC rather than a real drive. CP/M sees what's on a disk, directories, files, data, exactly the same, whether on real or virtual floppy.

Beyond that it's a question of what "I need to see how to select one of four .DSK files and read/write to a .DSK file on my PC from CP/M running on my Altair 8800 computer" means.

And key there is; what is a .DSK file ?

As best I can tell it's that complete virtual floppy image when stored as a file on the PC disk. I expect it gets read and sent by the Server app when the Altair asks for a track, updated whenever the Altair writes a track.

It seems the Server app could load multiple .DSK files and present them as separate drives, 16 in total, A: through P:

So, to select any one of those drives for reading or writing one would presumably just specify it in a CP/M command -

PIP B:BACKUP.TXT=A:TEST.TXT

Which would copy TEST.TXT from Dive A: to BACKUP.TXT on Drive B:

It doesn't seem there would be any need to know what the protocol was to achieve that. Maybe SolidWorksMagi could detail what they are actually wanting to achieve ?
 

SolidWorksMagi

Senior Member
I must learn to read the posts properly, and do a bit of research before commenting.

It looks like you have the FDC+ board in your Altair, and are using it to connect serially to a PC acting as a Disk Drive, with a .dsk image acting as the actual disk.

Looking at the protocol for the comms, it looks simple but very low level. The 'highest' functions you can perform are read and write tracks.
I cannot see how you could use the protocol to change the .dsk image that the drive is using, or have I missed something ?.
Hi,

You are correct. But it's that reading and writing protocol that I want to capture so I can try it from my Altair-Duino Pro computer. I want my Altair-Duino Pro computer to use the FDC+ (on another COM port) just like the Altair 8800 does. That would make life so much nicer with the Altair-Duino Pro computer ... eliminating much of the PCGET/PCPUT I have to do.
 

SolidWorksMagi

Senior Member
It seems to me the PC-side Server app holds an image of a complete virtual floppy disk which the Altair perceives as a real one, the track-by-track contents of what would be on a real floppy being the same on the PC making up that virtual floppy. The Altair wants to read a floppy track, does so, and doesn't know that track came from the PC rather than a real drive. CP/M sees what's on a disk, directories, files, data, exactly the same, whether on real or virtual floppy.

Beyond that it's a question of what "I need to see how to select one of four .DSK files and read/write to a .DSK file on my PC from CP/M running on my Altair 8800 computer" means.

And key there is; what is a .DSK file ?

As best I can tell it's that complete virtual floppy image when stored as a file on the PC disk. I expect it gets read and sent by the Server app when the Altair asks for a track, updated whenever the Altair writes a track.

It seems the Server app could load multiple .DSK files and present them as separate drives, 16 in total, A: through P:

So, to select any one of those drives for reading or writing one would presumably just specify it in a CP/M command -

PIP B:BACKUP.TXT=A:TEST.TXT

Which would copy TEST.TXT from Dive A: to BACKUP.TXT on Drive B:

It doesn't seem there would be any need to know what the protocol was to achieve that. Maybe SolidWorksMagi could detail what they are actually wanting to achieve ?
Hi,

Actually, on these old vintage 1975 computers, CP/M can only manage 2 HDDs and 2 FDDs. A:, B:, C: and D:

I think it's a moot attempt now ... I forgot that the FDC+ Serial Drive Server talks to the Altair 8800 at 403.2K BAUD ... I guess that must be a disk drive data speed.
 

hippy

Technical Support
Staff member
I forgot that the FDC+ Serial Drive Server talks to the Altair 8800 at 403.2K BAUD ... I guess that must be a disk drive data speed.
I would guess it's merely "fast", presumably some odd crystal frequency divided down by some number. FDC+ also supports 230.4K and 460.0K which are both multiples of the standard 115.2K which I would expect is what the PC server is using.

Baud rate matters for the FDC+ because the server has to match what the FDC+ board expects. If you are running an emulator you won't be using FDC+ hardware so can use whatever baud rate you want, so long as the PC server supports it.

There are open source servers for FDC+ for non-PC systems and they should of course work on a PC as well. So, if the server you have doesn't support the baud rate your emulator uses you can replace the existing server with one which does but I would have thought the emulator could use 230.4K and 460.0K and not require that - https://github.com/deltecent/fdc-sds

So it would seem all you need to do is find where the emulator reads and writes tracks etc and convert those routines to communicate with the server rather than access the SD Card.

If the server is using 403.2K you could perhaps use a PICAXE or something else to convert whatever baud rate the emulator uses to and from that.
 

SolidWorksMagi

Senior Member
I would guess it's merely "fast", presumably some odd crystal frequency divided down by some number. FDC+ also supports 230.4K and 460.0K which are both multiples of the standard 115.2K which I would expect is what the PC server is using.

Baud rate matters for the FDC+ because the server has to match what the FDC+ board expects. If you are running an emulator you won't be using FDC+ hardware so can use whatever baud rate you want, so long as the PC server supports it.

There are open source servers for FDC+ for non-PC systems and they should of course work on a PC as well. So, if the server you have doesn't support the baud rate your emulator uses you can replace the existing server with one which does but I would have thought the emulator could use 230.4K and 460.0K and not require that - https://github.com/deltecent/fdc-sds

So it would seem all you need to do is find where the emulator reads and writes tracks etc and convert those routines to communicate with the server rather than access the SD Card.

If the server is using 403.2K you could perhaps use a PICAXE or something else to convert whatever baud rate the emulator uses to and from that.

Hi,

The FDC+ Serial Drive Server app on my PC connects to my Altair 8800 just fine.

What I want to do is connect my Altair-Duino Pro computer to the FDC+ Serial Drive Server app on my PC so my Altair-Duino Pro can a copy of the FDC+ Serial Drive Server app on my PC too.

IF I can get my Altair-Duino Pro ... perhaps with a PICAXE in between to match speeds and protocols I thought it might work, but I don't know how to capture the read and write requests just to get started.
 

hippy

Technical Support
Staff member
IF I can get my Altair-Duino Pro ... perhaps with a PICAXE in between to match speeds and protocols I thought it might work, but I don't know how to capture the read and write requests just to get started.
The protocol appears to be well documented, in its own right and by way of alternative server apps which interface to an FDC+ board. So there's no need to capture anything to know what can be done and how that is done.

What you need to work out is how to make CP/M when emulated on the Altair-Duino Pro communicate via serial using that protocol to access the PC server instead of its SD Card or internal Flash.

Just as you plug real FDC+ hardware into a real Altair 8800 you need to plug a virtual FDC+ into the virtual Altair-Duino Pro. Because the Altair-Duino Pro is mostly just an 8080 CPU emulator, I guess you would trap reads and writes to the addresses an actual FDC/FDC+ would be located at, suspend operations until the FDC+ emulation has done its thing via serial according to what was read or written.

So the key here is in hacking the Altair-Duino Pro emulator code to support this virtual FDC+. You probably need to talk to the developer (David Hansell, Chris Davis ?) or the Altair-Duino Pro community to figure out how to do that. I am a little surprised no one has already done that.
 
Top