Treating floppy disk as a byte-stream (aka paper tape)

[pbirkel@gmail.com]

I wasn't sure where to place this topic, but as the broader context is a CNC mill controller using a Data General Nova-family controller <Minis and Mainframes> seemed as appropriate as any other forum.

I'm working to reverse-engineer a BostoMatic CNC controller from the early-mid 80's that uses a Fairchild F9445 VLSI implementation of the DG Nova 3 ISP. Documentation is non-existent, including even marketing literature, so it's slow going and early days. I believe that earlier controllers from the same OEM likely used actual DG Nova 3 processors, so my general approach is to treat a normal Nova 3 as my technology-baseline and then work to understand the differences in this OEM custom implementation. For starters it's pretty clear that the OEM wasn't interested in a DG-compliant backplane. There's some pretty (IMO) novel stuff going on with the backplane signals, although perhaps no more unusual than some of the pre-Nova 3 implementations.

It appears that the base installation boot-loaded from a paper tape (which appears to have been a serial-interface device, not parallel), but could be upgraded to instead boot-load from a 3.5" FDD if a controller was installed; that controller is based on a Western Digital FD1791. It appears that a single boot-loader serviced both devices, which determined by front panel switch positions. FWIW there was a further upgrade possible to a Winchester HD that appears to have has a real file system (of some sort; format unknown).

Because of the simple transition from paper tape to floppy disk I infer that the boot-loader simply treated the FDD as a series of sectors, incrementing from track 0 until encountering an end-of-file indication of some form, perhaps a null-containing sector. I also believe that both the tape and the FDD had the possibility of continuing to load additional content "from the same stream" under operator control (in effect a simple "continue" switch).

It appears that the floppy disk could be written on a standard PC, but IMO it's extremely unlikely that anything like FAT16 was supported. Instead the PC FDD controller would have been called upon to write a sector-by-sector binary byte-stream that the CNC controller could then serially read. AFAIK there's nothing preventing a standard PC FDD controller being used in this manner by a specialized application.

I'm completely unfamiliar with this sort of primitive use of a FDD as a byte-stream device, but I assume that it wasn't a completely novel usage.

Has anyone seen (or heard) of this sort of use? If so then where, when, how ...

Thank you for your thoughts!

 

[djg]

I'm completely unfamiliar with this sort of primitive use of a FDD as a byte-stream device, but I assume that it wasn't a completely novel usage.

Has anyone seen (or heard) of this sort of use? If so then where, when, how ...

Thats the standard abstraction of a disk by an operating system so wouldn't be unusual for firmware to implement that. Normally its on a file basis but for Linux you can open /dev/fd0 and read floppy as a byte stream. Do you have floppy disks from the system and have you tried dumping the contents?

 

[durgadas311]

By the early-mid 1980's, Floppy OSes like CP/M were well-established. These OSes typically booted by reading the first track (or more) off the floppy into memory, and then executing it. What happened next was entirely the responsibility of the code written to the first track(s). It could be a CP/M image, or an MS-DOS image, or whatever. Bottom line, it is entirely possible that the floppy boot loaded something that could organize the rest of the floppy into formal files. The paper tape probably did not have that - the user just mounted a new tape and told the machine what to do with it (i.e. "load as data"). The floppy almost certainly did not present a simple "byte stream" the way paper tape did, especially if it used a floppy controller chip.

 

[pbirkel@gmail.com]

Thats the standard abstraction of a disk by an operating system so wouldn't be unusual for firmware to implement that. Normally its on a file basis but for Linux you can open /dev/fd0 and read floppy as a byte stream. Do you have floppy disks from the system and have you tried dumping the contents?

Good point; I should think in terms of a Unix raw device. However in this embedded controller environment there's just a single all-encompassing application so the raw device is all that there is. Still, it would be worth-my-while to take a look at a Linux driver for /dev/fd0 to see how it goes about presenting the FDD content as a byte stream given a sector/block oriented device.

 

[pbirkel@gmail.com]

By the early-mid 1980's, Floppy OSes like CP/M were well-established. These OSes typically booted by reading the first track (or more) off the floppy into memory, and then executing it. What happened next was entirely the responsibility of the code written to the first track(s). It could be a CP/M image, or an MS-DOS image, or whatever. Bottom line, it is entirely possible that the floppy boot loaded something that could organize the rest of the floppy into formal files.

It's certainly possible that the embedded controller application was equipped to build and manage a file system. Certainly that is the case by the time that Winchester support was added. I'm unsure whether that was likely in the case of a FDD. @djg: I did confirm that there isn't a FAT16 directory structure present (not recognized format) but am not to the point that I'm set up to extract the raw FDD sectors. Recall that this a 16-bit CPU; I presume that byte-ordering will be the same on the floppy disk as for the paper tape. I don't have a paper tape sample.

As this is a two floppy FDD controller, with the first reportedly dedicated to boot-time and the second to transferring a CNC part-program (a sequence of mill operations) from a PC application to the CNC controller, it's possible that the second drive is managed based on an implementation of FAT16. And only the first drive is treated as a raw device.

Unfortunately I don't have a sample disk for a CNC part-program to investigate the behavior of second-drive handling. Nor is the PC application extant :-<.

The paper tape probably did not have that - the user just mounted a new tape and told the machine what to do with it (i.e. "load as data"). The floppy almost certainly did not present a simple "byte stream" the way paper tape did, especially if it used a floppy controller chip.

Well, there is a non-trivial loader involved. The ROM is 256x8, which I assume is being double-clocked into battery-backed low-power SRAM when booted as that's the basic approach of the Nova. So 128 16-bit words are available. The Nova paper tape boot loader is just 32 words, so that appears to leave 96 words for the floppy loader, which IMO is well-enough to index sectors and then tracks into an ordered sequence of sector reads-writes into memory with a suitable amount of FD1791 control oversight. I should take a look at some multi-sector/track CP/M boot-loader code.

Perhaps I can find the DG Nova 8" FDD boot ROM ... and the BostoMatic implementation just reuses that for its boot FDD. I've been assuming that to be pretty much the case for the BostoMatic paper tape boot loader although the DG implementation is for a parallel interface and I believe that the BostoMatic is using a serial interface, so "pretty much" is likely more in theory than in practice.

I do expect this to be a "fair sized" load as it's the entire application and the implementation is furnished with 64Kw of SRAM. The drives are FD-235F, so 360Kw-equivalent if formatted as FAT16 ... plenty of opportunity to fill that SRAM space at boot-time, if needed.

Given the large memory space I've wondered just how detailed the CNC part-program actually is, and to what degree it's just control points for curves and shapes that the CNC controller is responsible to take as the boundary conditions for detailed planning and then feedback-control during path execution.

 

[Chuck(G)]

Embroidery machines (the commecial kind) have used little floppy units as a replacement for paper tape for decades. CNC has first used cassette tape units (I had a 2-deck Techtran one), then floppy units.

Nothing new under the sun.

 

[pbirkel@gmail.com]

Embroidery machines (the commecial kind) have used little floppy units as a replacement for paper tape for decades. CNC has first used cassette tape units (I had a 2-deck Techtran one), then floppy units.

Nothing new under the sun.

Given early-mid 80's being "for decades" ago, that would be the same sun presumably :->. Any specific literature that you can cite in either case?

 

[Chuck(G)]

As regards cassette as a replacement for paper tape, my Techtran unit was from the early 70s. I have sample floppies from several units.
Here's a single deck Techtran unit: https://www.ebay.com/itm/TECHTRAN-817-DATACASSETTE-120-VAC-/361614367791
And one at CHM: https://www.computerhistory.org/collections/catalog/102681311
The more advanced ones could be programmed to search for a given record.

Take a look at this: https://www.aliexpress.com/i/2251832654329037.html--a USB device to replace a paper tape reader on an embroidery machine.

Also this: https://legacy.wilcom.com/Help/e4/es/en/MainHelp/Production/output/Using_embroidery_disks.htm

It's all evolution.

 

[pbirkel@gmail.com]

It's all evolution.

Thank you Chuck. In my case perhaps it's devolution ...

I have one of those Techtran 817 units, but other than opening it up to marvel at the amount of internal circuitry (a COSMAC no less!) I've been waiting/hoping to find technical documentation for the serial protocol and maybe even technical documentation as well. If you have any of either that you can share, I'd appreciate that.

 

[jplr]

Apologies if this is out of context, but Electuur (the European paper review) published a 6502 system in the 1980' where the floppy stream was read and written through a UART (an ACIA).

 

[daver2]

We did exactly this when we replaced our paper tape readers and punches on our Ferranti Argus 500 plant computer control system with floppy disks.

We had to develop a parallel interface that generated the control and data signals that the Argus was expecting. This consisted of a series of synchronising pulses that emulated a mechanical cam and switches on the original, with the data presented in parallel.

We added a switch, so the floppy disk could be read from or written to - i.e. the unit could act as both a reader or a punch - but not both simultaneously.

Because of the storage capacity of the floppy disk media - we segmented the disk sectors so that we could store and retrieve multiple paper tapes to/from the unit. We just had a simple rotary switch to select the desired segment number, and a 7-segment LED display to indicate what had been selected.

We could then 'rewind' the emulated paper tape (both punch and reader) by pressing a rewind button.

The 'online' switch would then activate the appropriate function under control of the Argus. Of course, the switch would signal to the Argus (via a digital signal) that it was ready for action.

You could also 'punch' leader tape. Basically, we duplicated the button functions of the original paper tape reader and punch units.

I also had a Gemini Z80 system that we could edit paper tapes on originally. I read the paper tapes into a named CP/M file. We could then edit the content and punch them back out again. When we replaced the paper tape readers and punches, I developed a software program to drive the floppy disk in 'raw' mode to be able to create the disks in the first place simply from the library programs stored on the Gemini. The reverse program could then read the floppies back in again.

We did exactly what was stated above - keep reading raw sectors (from the segment start for the specified program) and shovelling the sector data out to the computer until we reached the end of tape marker. If I remember correctly, the 'size' of the program (i.e. length of virtual tape) was actually stored into a header sector for each segment rather than being a character in the data stream.

If you tried to punch more than the allotted segment size, the Argus would get a 'paper out' error of course (to save corrupting the next segment on the disk)...

Just to throw a curved ball into the mix, the Argus was encoded in EBCDIC (or at least a slightly specialised form of EBCDIC). I had to translate from Argus speak into ASCII when reading the floppies into my Gemini and the other way when writing them out. To do this in a way that worked, I created my own conversion tables, and stuck to them religiously.

We did not use an Operating System as such - and the floppy disk layout was very simple (as you can see). We just had a simple embedded program stored in EPROM driving a Z80 CPU with some peripheral devices (PIOs), RAM and buffers.

Because we used a header, I was planning to add some free-form text into the header (from the Gemini) and display that on a multi-digit, 14-segment LED display. But I never got around to that.

Of course, the floppy disks and Gemini editing station has now been replaced. I wish I could still find the Gemini in an old room though one of these days!

Dave

 

[durgadas311]

...
Well, there is a non-trivial loader involved. The ROM is 256x8, which I assume is being double-clocked into battery-backed low-power SRAM when booted as that's the basic approach of the Nova. So 128 16-bit words are available. The Nova paper tape boot loader is just 32 words, so that appears to leave 96 words for the floppy loader, which IMO is well-enough to index sectors and then tracks into an ordered sequence of sector reads-writes into memory with a suitable amount of FD1791 control oversight. I should take a look at some multi-sector/track CP/M boot-loader code.
...

Booting with the FD1791 is pretty simple, doesn't require a lot of code as long as the CPU can keep up with the data stream. You just RESTORE and set sector and data registers and issue a multi-sector READ command. You can read the entire track with that. Assuming that the first track contains some sort of "OS", from there on out it can be any kind of filesystem they want on the floppy. Load more than one track takes more instructions, but may not be necessary. Many systems had multi-step boots as well, where the ROM only loads a "bootloader" which then has more smarts and can do more to load a real OS.

 

[Chuck(G)]

On YT, there's a clip of someone using a Gotek to replace the floppy drive in a Tajima TFD II, which replaced the paper tape reader.

I used to have the booklet that came with my Techran cassette reader, but if I still have it, it's buried under a pile of other documentation.

 

[pbirkel@gmail.com]

I used to have the booklet that came with my Techran cassette reader, but if I still have it, it's buried under a pile of other documentation.

If-when it reappears, please keep me in mind.

BTW, does anyone know if the forum has 50K membership :-}? (Doing my best to help your stats!)

 

[Al Kossow]

fyi, these were uploaded to IA over the weekend

FDS 100 Minifile Maintenance Manual : G.U.C. Products : Free Download, Borrow, and Streaming : Internet Archive

FDS-100 Minifile Maintenance ManualThe FDS-100 is a device designed to stream data from a floppy disk to an RS-232C equipped machine, such as a CNC machine. ...

archive.org

FDS 100 Minifile Operators Manual : G.U.C. Products : Free Download, Borrow, and Streaming : Internet Archive

FDS-100 Minifile Operator's ManualThe FDS-100 is a device designed to stream data from a floppy disk to an RS-232C equipped machine, such as a CNC machine. ...

archive.org

FDS 100 Minifile Sales Brochure : G.U.C. Products : Free Download, Borrow, and Streaming : Internet Archive

FDS-100 Minifile Sales BrochureThe FDS-100 is a device designed to stream data from a floppy disk to an RS-232C equipped machine, such as a CNC machine. ...

archive.org

 

[Al Kossow]

also, this is how 'floppy tape' drives work. the tape stores bitstreams that look enough like a PC floppy disk sector for the FDC to be able to decode them

 

[shirsch]

I have an Irwin branded tape cartridge drive that interfaced to a PC host through a Compaticard IV floppy controller. I believe it presented a data stream that looked like a 2.88MB 'ED' floppy disk.

 

[Chuck(G)]

The floppytape drives were extremely common (I l have a Cipher 525 here and maybe a dozen other drives) and extended right up through the Travan era. Some vendors offered "accelerator" cards (I have a couple of those as well), which were nothing more than 2.88MB floppy controllers. I'm a bit surprised that this is new to some--it wasn't that long ago that folks were using the Colorado "Jumbo" drives.

 

[pbirkel@gmail.com]

fyi, these were uploaded to IA over the weekend

FDS 100 Minifile Maintenance Manual : G.U.C. Products : Free Download, Borrow, and Streaming : Internet Archive

FDS-100 Minifile Maintenance ManualThe FDS-100 is a device designed to stream data from a floppy disk to an RS-232C equipped machine, such as a CNC machine. ...

archive.org

FDS 100 Minifile Operators Manual : G.U.C. Products : Free Download, Borrow, and Streaming : Internet Archive

FDS-100 Minifile Operator's ManualThe FDS-100 is a device designed to stream data from a floppy disk to an RS-232C equipped machine, such as a CNC machine. ...

archive.org

FDS 100 Minifile Sales Brochure : G.U.C. Products : Free Download, Borrow, and Streaming : Internet Archive

FDS-100 Minifile Sales BrochureThe FDS-100 is a device designed to stream data from a floppy disk to an RS-232C equipped machine, such as a CNC machine. ...

archive.org

Al: Thank you for pointing out those documents. Interesting models:

SKR: 89 KB / 179 KB Parallel Paper tape reader replacement for numerical control machine.
(Options: Signal levels, Signal timing)
GK: 89 KB Parallel Paper tape reader and punch replacement for computers.

Also Model 11K (with keyboard)
Interface: PDP-11 UNIBUS*
Application: Paper tape replacement; PC-11 software compatible

Uses sequential 160 byte blocks on 16 hard sectored media (35 tracks, apparently). It's unclear how partial blocks are handled (null filled, EOF mark, ...). After file deletion, other than the last file on the diskette) the entire diskette must be repacked ("compressed") in order to reclaim file space. Maximum of 26 files per diskette, presumably software-determined as the double-sided diskettes appear to have the same limitation. So an average file size would be ~3.4/6.8 KB. Modest length tapes of ~28 feet in the single-sided case.

 

[pbirkel@gmail.com]

We did exactly what was stated above - keep reading raw sectors (from the segment start for the specified program) and shovelling the sector data out to the computer until we reached the end of tape marker. If I remember correctly, the 'size' of the program (i.e. length of virtual tape) was actually stored into a header sector for each segment rather than being a character in the data stream.

Possibly the FDS 100 Minifile approach as well. It's not clear if the actual diskette sectors are just 160 bytes (the block length) or perhaps 256 bytes with a lot of block overhead? That's a *lot* of overhead ...