PDA

View Full Version : IBM Cassette interface with DOS



ABraveLittleToaster
November 3rd, 2016, 06:16 PM
Hello everyone!

Does anyone know if there's a way to access the IBM 5150's cassette interface from DOS? I doubt there's a command, of course, but I didn't know if it could be accessed by clever programming. Perhaps the use of interrupts?


Many thanks!

~James

Plasma
November 3rd, 2016, 06:50 PM
Interrupt 15h, ah=0/1/2/3. (http://www.ctyme.com/intr/int-15.htm)

krebizfan
November 3rd, 2016, 06:51 PM
INT 15h functions 0 - 3. Functions 0 and 1 turn the motor on and off while functions 3 and 4 read and write from cassette.

Shadow Lord
November 6th, 2016, 09:53 PM
So knowing this could some, infinitely more talented then I, write a device driver to allow a cassette tape to be used and access via DOS (e.g. through a drive letter)?

modem7
November 6th, 2016, 10:11 PM
So knowing this could some, infinitely more talented then I, write a device driver to allow a cassette tape to be used and access via DOS (e.g. through a drive letter)?
Wouldn't that be somewhat slow?

F:>type fred.txt

Tape advances. 5 minutes later, the tape reaches the point where FRED.TXT starts.

Scali
November 6th, 2016, 11:02 PM
Wouldn't that be somewhat slow?

F:>type fred.txt

Tape advances. 5 minutes later, the tape reaches the point where FRED.TXT starts.

That's how the Commodore 64 works, actually.
It has a filename record at the start of each file.
So you can in theory just do: LOAD "MY PROGRAM" (wildcards are also possible).
Then if you go from the start of the tape, it will keep scanning filename records until it finds the one that matches the name you specified.

However, in practice, you'd write down the counter value before you record a file, so you can cue up the tape to just before the file you want.
Since this is what you do anyway, the general use-case became to just do LOAD, with no filename, which will load the first file it finds.

But yes, if you want to simulate a directory listing, that would imply running the tape from start to end :)
This was always a problem on C64. You'd often get a copied tape filled with stuff, but no description of what's on there, or where.
Back in the day, my brother and I had to manually 'catalog' each tape we got. So we'd just do LOAD, and write down every filename it got, and the counter value, and then we'd check out the software.
It took ages... but well, there was no internet anyway, so what else was there to do? :)

Shadow Lord
November 7th, 2016, 01:41 AM
Wouldn't that be somewhat slow?

F:>type fred.txt

Tape advances. 5 minutes later, the tape reaches the point where FRED.TXT starts.

Yes, but that is not the point in any case, right? :D We do this for the cool factor not because it is efficient or even effective. IMHO it would be cool to be able to use the cassette port on the 5150 even if it is super slow.

Although, there could be ways to improve the speed and usability of a tape. There were commercial programs that allowed SCSI DATs and QIC drives to be used as mass storage devices. One I used was called TapeDisk. It would "format" a blank tape by creating a file at the beginning that served as a FAT. This way once a tape was "loaded" you would have quick access to the content. Of course accessing that content required the sequential accessing you described above.

One could create such a situation on the cassette tape as well. A FAT table of sorts could be loaded as the first record and it could even contain info on the counter values for each of the files (I am thinking these values would have to be manually entered). Only if I was talented enough to write something of the sorts....

mbbrutman
November 7th, 2016, 06:20 AM
You can't really implement the cassette interface as a DOS drive letter. That implies a block mode device, which also implies random access. Even though the cassette interface writes blocks at a time, it's clearly not random access. So the standard block mode device driver approach will not work.

You can hook INT21h and try to do your best, but without random access that's going to be pretty tough too for the same reasons. There is no motor control that lets you go in reverse.

You can write a character mode device driver, which makes more sense. Using it would be like reading from CON: or printing to LPT1: . The device driver could include a record of meta data at the start of each operation/command to indicate what was being stored.

Shadow Lord
November 7th, 2016, 07:58 AM
You can't really implement the cassette interface as a DOS drive letter. That implies a block mode device, which also implies random access. Even though the cassette interface writes blocks at a time, it's clearly not random access. So the standard block mode device driver approach will not work.

Yes, I think the reason programs like TapeDisk could simulate random access on the SCSI tape drive was because of the better motor control.

HoJoPo
November 7th, 2016, 12:22 PM
Yes, I think the reason programs like TapeDisk could simulate random access on the SCSI tape drive was because of the better motor control.

I'd imagine TapeDisk and similar programs kept a virtual FAT / directory in memory, stored at the beginning of the tape (or possibly multiple copies), to speed things up. And the ability to seek to a block on the tape was likely a huge difference... which a cassette wouldn't have.

Shadow Lord
November 7th, 2016, 12:43 PM
I'd imagine TapeDisk and similar programs kept a virtual FAT / directory in memory, stored at the beginning of the tape (or possibly multiple copies), to speed things up. And the ability to seek to a block on the tape was likely a huge difference... which a cassette wouldn't have.

Yes, you would imagine right :D:


There were commercial programs that allowed SCSI DATs and QIC drives to be used as mass storage devices. One I used was called TapeDisk. It would "format" a blank tape by creating a file at the beginning that served as a FAT. This way once a tape was "loaded" you would have quick access to the content.

Great Hierophant
November 7th, 2016, 10:16 PM
With a single head tape deck, it does not look like a disk because the tape ends and you can't go back unless you rewind the tape. But what about a dual head tape deck? With a dual head system, once the tape finishes side A, it goes directly to the beginning of side B without user intervention. Then once it finishes side B, it goes back to the beginning of side A. At that point it looks like a disk, just one that may take an extremely long time to get to the data you want :p

mR_Slug
November 13th, 2016, 12:14 PM
But what about a dual head tape deck?

Or 8-track? (continuous loop tape)

--

This sounds interesting, I would write something myself if only i knew how. Is there an Idiots guide to hooking into DOS? Like if you wanted to make a device driver for the tape or ram disk etc, it would give example code. My only real knowledge is that this is more difficult under DOS 1.x.

krebizfan
November 13th, 2016, 12:49 PM
Or 8-track? (continuous loop tape)

--

This sounds interesting, I would write something myself if only i knew how. Is there an Idiots guide to hooking into DOS? Like if you wanted to make a device driver for the tape or ram disk etc, it would give example code. My only real knowledge is that this is more difficult under DOS 1.x.

You could track down a serial StringyFloppy. That would provide a continuous loop tape drive that has drivers for many computers other than the IBM PC. Should be easier to adapt than Sinclair Microdrives.

One quick explanation of how to do it with DOS 3 is at http://www.drdobbs.com/writing-ms-dos-device-drivers/184402277

I don't think creating a cassette tape format that can't be used with a cassette only system would be useful.