• Please review our updated Terms and Rules here

Cassette BASIC and storage

ardent-blue

Experienced Member
Joined
Jan 2, 2015
Messages
479
Folks, some tidbits have arisen on the Cassette BASIC used on PS/2s, not much, but it makes me curious...

The early PS/2s, 8550-8580, use Cassette BIOS C1.0 [32KB in size], I DIMMly remember. The later PS/2s use Cassette BASIC C1.10 [32KB in size], but it is not easily accessible.

Cassette BASIC can interface to the first three parallel ports, but in a crude, one-way fashion. Probably using BIOS calls.

Can we use CBASIC to communicate with parallel-port connected storage? This storage would have to be at a low level, because you can't bit-bash drivers in at the command line to enable booting from it.
 
Cassette BASIC has INP and OUT which reads or writes a byte from a port including the parallel port addresses. That would entail a lot of keyboard entry to have a program that could take advantage of it. What are you planning on doing? A USR could have machine code that simplifies the parallel port interfacing.

http://boginjr.com/it/sw/dev/bootlpt-86/ is an example of a ROM expansion that boots, transfers data from the parallel port, and then can boot from the created RAM disk. In theory, the code could be POKED into memory and then called from BASIC but typing about 9K every boot seems less than efficient.

An absolutely bonkers variation would be to take one of the parallel port to cassette adapters and POKE in cassette routines. Also impractical since even simplified cassette routines would be longer than what is easily entered every time but it does seem hilarious making the PS/2 save files to cassette.
 
> What are you planning on doing?

I'm trying to drink myself into an early grave. This seems to be an excellent way to get there...

BootLPT-86 is interesting, it runs an InterLink style of transfer to another system that has the needed system files. BUT this requires another system to be the host. Huh, I wonder if a System on a Chip can't be fabricobbled onto the parallel port... Raspberry Pi or something...

Gung-Ho on the parallel port cassette adapter... fascinating...

Problem: a PS/2 has a bad floppy. In the glory days, there were plenty of PS/2 floppy drives on Flea-Buy. Cheap shipping... Dead floppy? Buy another, maybe 10 at a time... Nowadays, the floppy era is vanishing in the mists...

Discussion: PS/2s need to run System Programs [aka "Setup"], either from floppy -OR- hard drive in order to configure a system.
A dead/weak battery, conflicting bits in the CMOS [NVRAM...], changing adapters, etc, all can trigger a need to re-configure the system.
This "Setup" is DOS based, so it can't be run on Cassette Basic [anyone wanna prove me wrong?] so we must have enough DOS to run the System Programs.

During Boot, the PS/2 looks for A:, then C: [or RPL].
RPL requires a successfully configured adapter, so if the CMOS is corrupt or blank, that isn't going to work.
If the floppy is kaput, the system looks for C:, if it doesn't find it, you may get the glorious red "circle X", thence dumped into CBASIC.

My dark, twisted desire is to side-step a defective floppy and access a source for refdisk files. Serial is not so great, early systems will do good to hit 19.2Kb/s, but later systems with the Type 3 serial port will do 345Kb/s. BUT if all that is expected is loading enough DOS, then run system programs, it would suffice.

Parallel seems a better choice, I can't remember many PS/2s with a non-working parallel port. The earliest PS/2 support bi-directional at the minimum, the Type 3 parallel port can support to 1MB/s [or better] with a direct connect between two PS/2. Faster = More Gooder...

The external device doesn't have to be faster than a Floppy [but it sure would be nice...]. I want to eliminate the need for a second system to provide files [like BootLPT-86].
 
The author of the parallel port tool also did a variation to move the FREEDOS image to a RAMDISK via the cassette port. http://boginjr.com/it/sw/dev/vinyl-boot/ The FREEDOS image could be altered to include other utilities as long as the entire image fits in 64K and creating a second RAMDISK would require extensive modifications to FREEDOS.

The problem with the PS/2 is the lack of any ROM routines to transfer files by parallel or serial port. What would be ideal would be a short BASIC routine that brings over a longer transfer utility that transfers a complete DOS image into memory in order to run it there. The original IBM PC had a way to transfer 255 bytes over the keyboard port but I have never used it. I don't know if the code to load Manufacturing Test 2 was included in the PS/2 BIOS. 255 bytes might be just enough to do an import routine.

How big do you want the utilities to be? Multiply the byte length by 4 for the approximate length of the BASIC program that would be needed to POKE the entire utility into memory which indicates no utility can exceed 16K. Interfacing and transferring the files seem solvable problems but for the next decade or so buying a modified GOTEK that matches the PS/2 alterations to the floppy interface seems a lot simpler.

Just brainstorming here. I find the amount of work that would be involved daunting.
 
Back
Top