Mass storage options

[Dr_Acula]

From time to time the chicken and egg problem arises - how do you get the first file onto an old computer in order to start copying other files?

I've been experimenting with the uDrive http://www.instructables.com/id/Simple-mass-storage-for-your-microcontroller-proje/

In theory, if a vintage computer has a spare serial port then this little device could not only give you access to one file, but it could give you access to the entire Walnut Creek archive and every CP/M program ever written. And still only be half full!

The trick is getting software working, and at the simplest level one would need a program that can send and receive bytes to and from a serial port in a specific order. So you might need the minimum of Assembly or C or Basic working on a vintage machine.

Then, just read files over and save them on a disk. That would require a program similar to the vb.net one on the Instructable, which is perhaps an evening of coding in your favourite language. I've got similar software written in CP/M that turns a PCs directory into a new drive on a CP/M computer. But that requires a PC to be on all the time. I like the idea of getting the PC out of the loop and having a standalone CP/M computer with access to its own library of files.

My first computer was a CP/M board and it had two serial ports - one for the keyboard/monitor, and one was for I/O. I did all sorts of clever things with that second port. Did other vintage CP/M computers have a serial port?

 

[GADFRAN]

Sure - some Kaypros even had two [2]

Sure - some Kaypros even had two [2]

More specific details if needed.

I would be most interested in further specific implementation details, when you can eventually give them. Could be incredibly useful for vintage computers like Kaypros.

Web site says device is only $30 USA, so certainly reasonably priced.

Keep up your good work. It is much appreciated.

Frank

 

[MikeS]

Did other vintage CP/M computers have a serial port?

Are you kidding? At least a modem, and often the printer used a serial interface as well. Some systems (like my Vector Graphic MZ for example) had primitive comm routines built into the system monitor ROM, and there were numerous multi-port cards available for S-100 systems.

 

[Dr_Acula]

Brilliant! With a serial port we can do all sorts of clever things. Someone over at the N8VEM forum has suggested taking the 1mb or 8mb file images the altair simh uses, and accessing these from within CP/M with some custom BIOS code. So you could create drive C, D, E etc each with an 8mb "hard drive". And access files via a small C or Sbasic program as well. Some intriguing possibilities there. There are some people on the Propeller forum who are doing just that with their CP/M emulation on the Propeller.

 

[tezza]

This sounds quite interesting. Certainly my two luggable CP/M machines (Osborne 1 and Kaypro II) have serial ports as standard, either for use with printers or modem communication.

Tez

 

[nige the hippy]

There was some work done on this for the sirius1/victor 9000 as the boot disks are completely unwriteable by any normal means.

This is only one of one of the roms, I haven't been able to trace a copy of the other. but it might give some people a start...

 

[GADFRAN]

More on serial ports on early computers.

More on serial ports on early computers.

Monday, May 04, 2009


On your request if other vintage computers had serial ports for your project, some further information is as follows – many did have serial ports !

I found my copy of Michael Nadeau’s book on “Collectible Microcomputers” and found the following – a friend or your local library may have a copy – I think it is still available on Amazon or the publisher Schiffer]

Kaypro II - 1982 – one

Kaypro 4 - 1983 – one

[Kaypro Technical Manual says Kaypro 4 / 84 had two]

Kaypro 2X – no year given – two

Kaypro 10 - 1983 – two

Kaypro 16 - 1985 – none noted

Kaypro Robie desktop - 1984 – none noted

[Kaypro Technical Manual says had two]

Kaypro 286i desktop - 1985 – one

Kaypro PC - 1985 – one

Kaypro 2000 - 1985 one

Osborne 1 - 1981 – one

Osborne Executive / Executive II – two

Osborne 4 Vixen - 1984 – one

Osborne 3 [a.k.a. “Encore”] - 1985 – one

Compaq Portable II - 1986 – one

Compaq Portable III – 1987 – one

Compaq Portable 386 – no year given – one

Compaq Portable / Compaq Plus – 1983 – one – option

Compaq Portable 286 – 1985 – one

IBM PC 5150 – 1981 – one

IBM Portable PC 5155 – 1984 – one

You can check his book for others, but these are the ones I am interested in for my STS research and my books.

Michael and I have corresponded by email on a variety of vintage computer issues.

He was very meticulous in his research and what he put in his book, so it can be considered very reliable. Of course, there will always be issues and even some manufacturer’s publications are in error. In addition, there may be many computer variations both documented and not documented in those hectic times of “hypergrowth” as Adam Osborne noted.

Of course the serial port was used for an external modem before internal modems became more popular. In addition, some early printers could make use of serial ports, besides the more standard parallel port.

Both of these items are noted in above posts also, but I wanted to emphasize them for those who may not know of the "early years"

Assuming RS-232C = serial port

There were also some serial interfaces and did not some game ports make use of serial connections?

Hope this is of some assistance and interest in your projects.

All the best in all your projects!

Frank

 

[Dr_Acula]

That is a very helpful list.

I'm thinking of scenarios where you have a computer and maybe a few disks. If you have no disks at all it might be complicated, but say you have a disk with any sort of programming language - eg basic or assembler or C. And you want to get some software over to the computer.

If you can send a byte to the serial port, and you can get one back, how simple could a program be to get a file off a udrive? In assembler, it might be as simple as OUT (Portnumber),A and IN (Portnumber), A and basic and C would be very similar. Or use CP/M calls, which may already be in the BIOS.

Coding in an entire xmodem protocol would be tedious, though I think this was sometimes done. Interestingly, the uDrive uses a simplified xmodem protocol, eg send a small group of bytes eg 10 bytes, then get a ACK or NAK (ascii &H06 or &H15). But there is no checksum (and probably no need for one) Writing 20 to 30 lines of code to just read a file off a uDrive and with just one file, you can then download something like xmodem and get more files over with a direct serial link. Though if you have one file across, it might be convenient to use the uDrive anyway.

 

[leeb]

From time to time the chicken and egg problem arises - how do you get the first file onto an old computer in order to start copying other files?

I've been experimenting with the uDrive http://www.instructables.com/id/Simple-mass-storage-for-your-microcontroller-proje/

In theory, if a vintage computer has a spare serial port then this little device could not only give you access to one file, but it could give you access to the entire Walnut Creek archive and every CP/M program ever written. And still only be half full!

The trick is getting software working, and at the simplest level one would need a program that can send and receive bytes to and from a serial port in a specific order. So you might need the minimum of Assembly or C or Basic working on a vintage machine.

Then, just read files over and save them on a disk. That would require a program similar to the vb.net one on the Instructable, which is perhaps an evening of coding in your favourite language. I've got similar software written in CP/M that turns a PCs directory into a new drive on a CP/M computer. But that requires a PC to be on all the time. I like the idea of getting the PC out of the loop and having a standalone CP/M computer with access to its own library of files.

My first computer was a CP/M board and it had two serial ports - one for the keyboard/monitor, and one was for I/O. I did all sorts of clever things with that second port. Did other vintage CP/M computers have a serial port?

My Tandy/RS Model 4p has a 'serial boot' mode that will load off the serial port (tho at 19200 max, it wont be fast!) just like reading a 256-byte boot sector from a FD...

Eventually (WAY-long-term goal here) I want to rewrite the boot ROM to recognize an IDE controller and boot from it rather than the original-but-optional MFM controller it expects... Just a bit of pipe-dreaming! :mrgreen:

 

[Dr_Acula]

Maybe not pie in the sky.

I've just finished coding the udrive for the picaxe. It turned out a lot easier in picaxe basic than in vb.net, so I'm very hopeful it will turn out straightforward in 8080/z80 assembly.

Part of this project involves hooking into bios and bdos calls from CP/M. Are there any resident experts here? I've been fiddling round with this stuff for 25 years and posted something on the N8VEM about using function call 2 to print a character to the console. Then someone came back with a suggestion to use function call 9 to print an entire string. Even after all this time I still don't understand the complexities and usefulness of CP/M. I have even more respect for Gary Kildall, who wrote the whole thing in less than 25 years!!

I'm going to be using the bios and bdos calls as part of the udrive interface. In particular, it would be great to know more about opening and closing files. I know the bdos call number, but how, for instance, do you pass the name of the file? I know about the file control block and I think the name goes in there, but do you have to add other things as well?

I'm thinking about some simple little programs that talk via any CP/M computer's serial port. eg UDIR.COM, UPIP.COM etc. You might type something like UPIP A:MYFILE.TXT=U:MYFILE.TXT and this moves the file from the udrive into drive A via the serial port. That is the idea, anyway. Back to coding...

 

[Chuck(G)]

Bootstrapping a comm program onto a CP/M machine often involved using PIP at low (300-1200 bps) speed to suck in a file over the serial link. The most reliable way was to translate it to Intel .HEX format and end the transfer with a 1A character. LOAD could then convert the .HEX file to a .COM file and you were off and running.

Many CP/M machines have serial ports (my Durangos each have 4, in addition to an IEEE-488 port and can do synch in addition to async). But some had none (the Amstrad PCW Joyce is an example).

Perhaps the most extreme case of this was the time I had to get files off a CP/M machine that had no serial or parallel ports and an unfathomable diskette format (I think it was a Multitech, but I can't recall for certain). I found that I could turn an LED on the keyboard on and off using OUT instructions. So I wrote a bit-banger program to blink the LED and stuck a phototransistor over the LED to read it and transmit data to another system. It was very slow, but it worked well enough.

If there wasn't an LED, I suppose that I could have read blinking on the CRT if I had to. Desperation forces you to be original.

 

[MikeS]

<snip>
Perhaps the most extreme case of this was the time I had to get files off a CP/M machine that had no serial or parallel ports and an unfathomable diskette format (I think it was a Multitech, but I can't recall for certain). I found that I could turn an LED on the keyboard on and off using OUT instructions. So I wrote a bit-banger program to blink the LED and stuck a phototransistor over the LED to read it and transmit data to another system. It was very slow, but it worked well enough.

If there wasn't an LED, I suppose that I could have read blinking on the CRT if I had to. Desperation forces you to be original.

-------
Good one! You should have patented it and collected from Timex for their system of transferring data from the CRT screen to the watch!

I still have a system running at a client's where computer A sends data out the serial port, and through an RS-232>PS/2 keyboard converter "types" it into computer B; it receives data by sending a PrintScreen to B which goes back to A via the generic printer on a com port connected back to A's RS-232 port.

Ya gotta do what ya gotta do...

@James: You might consider joining the comp.os.cpm usenet group (also on Google groups like N8VEM); lots of CP/M experts there, although like most places like that if you ask a question you'll likely get 10 different answers, often contradicting each other ;-)

You might also look at Dave Dunfield's site, especially his CPT program:
http://www.dunfield.com/dave/classic.htm