Altair 8" Disk and Error 31

[deltecent]

I am trying to use OpenFlops/FlashFloppy to emulate an Altair 8" Floppy.

I created an IMG.CFG file and loaded a CP/M disk image CPM.ALTAIR8.IMG on the USB drive. What I am getting is an Error 31. Is there any way to determine what is causing the error 31?

My IMG.CFG looks like this:

# [altair8] Altair 88-DCDD floppy drive
# matches images of the form *.altair8.img and *.altair8.ima
[altair8]
cyls = 77
heads = 1
secs = 32
bps = 137
id = 1
mode = fm
interleave = 1
cskew = 0
hskew = 0
rpm = 360
gap3 = 0
iam = yes
rate = 125
file-layout = sequential

[keirf]

You can't have 137 bytes per sector. A power of two multiple of 128 only (128, 256, 512, ...).

[keirf]

Specifically IMG.CFG is for defining variants of IBM track format. Altair is a hard-sectored non-IBM format. Usually non-IBM can be dealt with using HFE image format, but there's no support currently for hard sectors in FlashFloppy. It would need a suitable image format or format extension, or native support for Altair logical images.

[deltecent]

That's a shame. I'm using an FDC+ in an Altair. It emulates the hard sectors that the controller is looking for. So, for example, the FDC+ can connect to a Teac 55-GFR, and the Altair thinks it talking to an Altair 8" disk. I'm trying to use the OpenFlops in place of a Teac 55-GFR (5.25" 96tpi 360rpm). I'm not familiar with how things work at the hardware level, I just know that the Altair is expecting to see 137 byte sectors, where byte 0 is 0x80 + track number, byte 1 is sector number, 7-134 is data, 135 is 0xff and 136 is 0x00. There's some CRC data in there too.

The TEAC 55-GFR series of 5.25” drives can be configured to run at 360 RPM to match the rotation rate of 8” drives. The drives provide 80 tracks (there are 77 tracks on 8” drives), and the motor speed is very stable, so generating 32 virtual hard sectors for soft sectored media is reliable. Use high-density (HD) floppy disks designed for used with HD drives. The diskettes are soft sectored. The FDC+ creates virtual hard-sector pulses as required by Altair software.

[keirf]

Then you should be able to use HFE image files. At least to format and write new images. I don't know if you can convert existing Altair images (whatever format they're in) to HFE?

[deltecent]

The Altair files are just raw images, the first 137 bytes of the file is track 0, sector 1, followed by another 137 bytes of track 0, sector 2, etc. The files are 337,568 bytes (77 * 32 * 137). I am having a difficult time finding any information on what the HFE file format looks like, but I'm sure it's out there. I suppose I can dig into the code on this site and reverse engineer. That is how I was assuming this OpenFlops device would work with its "Flexible track layout for Raw Sector Images"; that it would emulate a floppy spinning at 360rpm, send the data that's flying under the head, and let the host computer figure it out. I was rather surprised that it was so format specific. But then again, I have a very rudimentary understanding of how floppy drives work.

[drdpj]

I have a sneaking suspicion that what's written to the disk will be 128bytes and the rest is just the sector header. If you use the HxC floppy emulator software to create an empty high density 1.2MB PC disk image, and export it as "HFE", then try formatting it in the Altair, and using the software you normally use to write disk images out, you'll probably find it works?

…

On Wed, 30 Sep 2020 at 15:54, Deltec Enterprises ***@***.***> wrote: The Altair files are just raw images, the first 137 bytes of the file is track 0, sector 1, followed by another 137 bytes of track 0, sector 2, etc. The files are 337,568 bytes (77 * 32 * 137). I am having a difficult time finding any information on what the HFE file format looks like, but I'm sure it's out there. I suppose I can dig into the code on this site and reverse engineer. That is how I was assuming this OpenFlops device would work with its "Flexible track layout for Raw Sector Images"; that it would emulate a floppy spinning at 360rpm, send the data that's flying under the head, and let the host computer figure it out. I was rather surprised that it was so format specific. But then again, I have a very rudimentary understanding of how floppy drives work. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATU2PHEQUBVUTCJ6RFKAW3SINBBFANCNFSM4R6NLF7Q> .

[deltecent]

The Altair 88-DCDD floppy controller and drives provide very little hardware support for data error checking, sector positioning and track positioning. The Altair floppy has 137 bytes per sector, leaving nine "unused" bytes assuming a typical 128 byte payload. It is up to software to effectively use the remaining bytes to provide data validation in support of the hardware. For example, it is up to software to set the MSBit of the 1st byte of each sector to act as a hardware sync bit. It is up to software to reduce head current for tracks 43-76. It is up to software to determine how data is verified and where to store the verification data in each sector (if stored or checked at all!). The MITS (Altair) "standard", as used for various versions of "Disk BASIC" and "Altair DOS", actually uses the 137 byte sector in one manner for tracks 0-5 and in a different manner for tracks 6-76.

Because the content of the entire physical sector, and how that content is used, is laid open to the application software, the Altair 88-DCDD is a difficult drive to code for and uses significant host computer resources. This is one reason the Altair computer and floppy combination was not an ideal platform for CP/M.

So I'm starting to gather that FlashFloppy may be too "smart" to emulate an Altair disk, where the host computer has to do everything that a typical floppy controller does, as the host computer essentially is the floppy controller. Again, I was hoping that it would be possible to provide a raw image of 77 tracks of 32 sectors with 137 bytes, tell the OpenFlops to seek to track n, and have it have it start sending that track's bit stream as if the disk was spinning at 360rpm. The same with writing data.

I'll dig into the source here and see if I can get a better understanding of how this all actually works.

[omikron88]

It's strange really, if sector length is not 2^n. Dne st 30. 9. 2020 17:03 uživatel DanielJ <notifications@github.com> napsal:

…

I have a sneaking suspicion that what's written to the disk will be 128bytes and the rest is just the sector header. If you use the HxC floppy emulator software to create an empty high density 1.2MB PC disk image, and export it as "HFE", then try formatting it in the Altair, and using the software you normally use to write disk images out, you'll probably find it works? On Wed, 30 Sep 2020 at 15:54, Deltec Enterprises ***@***.*** > wrote: > The Altair files are just raw images, the first 137 bytes of the file is > track 0, sector 1, followed by another 137 bytes of track 0, sector 2, etc. > The files are 337,568 bytes (77 * 32 * 137). I am having a difficult time > finding any information on what the HFE file format looks like, but I'm > sure it's out there. I suppose I can dig into the code on this site and > reverse engineer. That is how I was assuming this OpenFlops device would > work with its "Flexible track layout for Raw Sector Images"; that it would > emulate a floppy spinning at 360rpm, send the data that's flying under the > head, and let the host computer figure it out. I was rather surprised that > it was so format specific. But then again, I have a very rudimentary > understanding of how floppy drives work. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#375 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AATU2PHEQUBVUTCJ6RFKAW3SINBBFANCNFSM4R6NLF7Q > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXMWBDAJ3WJKPOZCLZ6LTDSINCFDANCNFSM4R6NLF7Q> .

[drdpj]

The HFE file option is completely agnostic about what's on the disk - it'll just behave as a blank surface (it's very unsmart!) - it's up to the computer or FDC to deal with the pulses that come back. That will, I'm 99% sure, see you right. I've attached one to this post.

…

On Wed, 30 Sep 2020 at 16:24, Deltec Enterprises ***@***.***> wrote: The Altair 88-DCDD floppy controller and drives provide very little hardware support for data error checking, sector positioning and track positioning. The Altair floppy has 137 bytes per sector, leaving nine "unused" bytes assuming a typical 128 byte payload. It is up to software to effectively use the remaining bytes to provide data validation in support of the hardware. For example, it is up to software to set the MSBit of the 1st byte of each sector to act as a hardware sync bit. It is up to software to reduce head current for tracks 43-76. It is up to software to determine how data is verified and where to store the verification data in each sector (if stored or checked at all!). The MITS (Altair) "standard", as used for various versions of "Disk BASIC" and "Altair DOS", actually uses the 137 byte sector in one manner for tracks 0-5 and in a different manner for tracks 6-76. Because the content of the entire physical sector, and how that content is used, is laid open to the application software, the Altair 88-DCDD is a difficult drive to code for and uses significant host computer resources. This is one reason the Altair computer and floppy combination was not an ideal platform for CP/M. So I'm starting to gather that FlashFloppy may be too "smart" to emulate an Altair disk, where the host computer has to do everything that a typical floppy controller does, as the host computer essentially is the floppy controller. Again, I was hoping that it would be possible to provide a raw image of 77 tracks of 32 sectors with 137 bytes, tell the OpenFlops to seek to track n, and have it have it start sending that track's bit stream as if the disk was spinning at 360rpm. The same with writing data. I'll dig into the source here and see if I can get a better understanding of how this all actually works. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATU2PGWHJUIW5LLJUFESQTSINEUHANCNFSM4R6NLF7Q> .

[keirf]

You may need the correct hfe data rate. The rpm and data rate are baked into the hfe. You probably need one with rate 250kbit/s and 360 rpm. I can supply one and if that's not right, I can provide debug firmware so we can work out the correct data rate.

I'm afk at the moment but can send an hfe later or tomorrow for you to try writing to (then you can send back to me to take a look)

[deltecent]

The HFE file option is completely agnostic about what's on the disk - it'll
just behave as a blank surface (it's very unsmart!) - it's up to the
computer or FDC to deal with the pulses that come back. That will, I'm 99%
sure, see you right. I've attached one to this post.

That sounds hopeful! I found a document on the HFE file format. Looks straight forward to convert a current Altair image to HFE. Thank for the hint.

It's strange really, if sector length is not 2^n.

I don't think many physical sectors are 2^n. The sector's payload is more than likely 2^n, but not the sector itself. The payload is just part of the bit stream.

[deltecent]

Ok, now that I feel this may work, I'll start work on getting the hardware connected to the FDC+. I'll first have to go from 50 pin Shugart to 34 pin, but I have an adapter I can build for that.

[deltecent]

Let me know if I have proper understanding of what's going on here. I was under the assumption the image provided on the USB would be converted on the fly to FM or MFM encoding based on the encoding, data rate, rpm, tracks, sectors, bytes per sector, and stuff like that in the IMG.CFG file. It appears that the HFE file is already in the specified FM/MFM format, so I can't just copy my data into the HFE track data. So what I've done is created what I think is a blank 5.25" HD floppy (1.2MB). It is true that when I examine that file, the RPM is set to 0, so I'm going to change those 0x00 0x00 bytes to 0x68 0x01 for 360. I should then be able to load a format program into the Altair and tell it format drive 0, then move a CP/M image over to it using our PC2FLOP tool. Am I in the ballpark? I guess I'm still confused...if a 128 byte sector is selected, where doesn't the room for the soft sector format come into play? The custom gap lengths?

[deltecent]

Ok, making a little progress. I can step the head with the Altair, but do not seem to be able to write data. Time to try loading some of the debug images.

[deltecent]

Ok, a little update. I can get the Altair to write, and the "W" starts blinking on the OLED screen. Then, the OpenFlops device stops sending index pulses, so the Altair loops waiting for the index status. Resetting the OpenFlops doesn't seem to fix it. I'm not sure how to get it send index pulses again. I guess I'll trying loading another blank image and see if that gets it started again.

[drdpj]

https://github.com/keirf/FlashFloppy/wiki/FF.CFG-Configuration-File Index-suppression=no option in your ff.cfg file:)

…

On Thu, 1 Oct 2020, 00:16 Deltec Enterprises, ***@***.***> wrote: Ok, a little update. I can get the Altair to write, and the "W" starts blinking on the OLED screen. Then, the OpenFlops device stops sending index pulses, so the Altair loops waiting for the index status. Resetting the OpenFlops doesn't seem to fix it. I'm not sure how to get it send index pulses again. I guess I'll trying loading another blank image and see if that gets it started again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATU2PBESR2UO24G46K3TS3SIO35HANCNFSM4R6NLF7Q> .

[deltecent]

This looks right:

Measuring Spindle Revs. Press any key to abort.
166.709 mS/rev
166.709 mS/rev
166.713 mS/rev
166.709 mS/rev
166.713 mS/rev
166.709 mS/rev
166.709 mS/rev

One thing I'm noticing is when I write data, the index timing changes. Shouldn't the index pulse be a constant 166.7ms regardless of data being written? The way this FDC+ works is it uses the single index pulse from the soft sector media to generate the other hard sector pulses that the Altair is expecting. I'm thinking the inconsistent index pulses may be an issue.

Index pulses when idle:

Index pulses when writing:

[keirf]

Unfortunately Flashfloppy needs time to flush new data to usb stick. During this time it cannot serve up read data. So it also delays index signal for this time. So yes it will get out of sync with your hard index generator.

I'm going to suggest index-suppression = yes (as with no I generate weird extra pulses which will get super confusing). Also write-drain = eot as this will cause jump to end of track and thus almost immediate index pulse after writing. Perhaps the index generator will resync with that pulse?

Beyond this you might really require hard sector support within Flashfloppy. It can't really be that hard.

The question would be after stretching/stopping rotation on track changes and writes, can we just recommence where we we were with next sector's pulse or better to restart at whole track start and double pulse?

[keirf]

By the way what is the timing of the track start double index pulse? Does the first or second pulse sit "on the mark", and what is the time between the pulses exactly?

[deltecent]

So here's the official word:

The disk emulator doesn't need to do anything special for hard sector generation for mode 4. The FDC+ takes care of that. He should simply generate the single index pulse at the 360rpm rate (every 166.67ms). The data is written in FM at the same rate as an 8" drive (2us and 4us pulse intervals). If his firmware is trying to interpret data as MFM and/or looking for soft sector address marks, missing clock pulse flags, etc., that could be causing some of the problems. Just record and play back the FM data with the same timing it was written and it should work fine. This implies the drive emulator knows when a particular burst of data was written relative to the index pulse so that each burst of data can be played back at the right time offset relative to the index pulse.

I'm not sure what is meant by "track start double index pulse." The HD drives output a single index pulse every 166.67ms as you measured when running in HD mode (360 rpm). This matches the timing of 8" drives.

"Modern" 5.25" drives had the option to stop sending index pulses while seeking, during head settle, motor spin-up, etc. The disk controller and/or driver in the PC then required index pulses before reading or writing, essentially making the index line a "ready for I/O" signal as well as the index pulse. To work with hard sector controllers (any of them, including the FDC+), index pulses cannot stop. On the Teac 55-GFR drive, the E2 jumper is installed to force index pulses to continue. If the drive emulator does not have this ability, then yes, that will be a problem.

Parameters like Sector ID start, Interleave, Pre-Gap Length, GAP3 Length, etc., are all specific to a soft sector disk format, so most likely the firmware won't know what to do with the data stream from the FDC+ (or any hard sector controller), that has none of the data these parameters account for.

[keirf]

Unfortunately the FlashFloppy index-suppression=no option is a bit BBC specific and chucks in extra index pulses to keep the Beeb happy. It is also basically impossible to guarantee consistent index pulses in the presence of writes to USB sticks as the write latency on some sticks can be large (like occasional writes of 100-200ms, or more in some cases).

Do we need to solve the write problem, or are you mainly interested in reading existing images? As the latter is a lot easier. Just need to play dumb as the FDC+ guy says :)

I'm interested in the track start double pulse (which I think all hard sectored disks have, via a double index hole?) because I would like to make sure my Greaseweazle project is compatible with hard sectored disks in future, and I'd like to make sure I accept index pulses suitably close together without filtering them out as noise.

[deltecent]

Do we need to solve the write problem, or are you mainly interested in reading existing images? As the latter is a lot easier.

I am interested in reading and writing, as I don't think any compatible images exist, so I won't have anything to read unless I can write something.

I'm interested in the track start double pulse (which I think all hard sectored disks have, via a double index hole?) because I would like to make sure my Greaseweazle project is compatible with hard sectored disks in future, and I'd like to make sure I accept index pulses suitably close together without filtering them out as noise.

I'll see if I can get that information.

The guy that made the FDC+ is coming out with a solid state drive emulator that

emulates a typical 8" or 5.25" drive at the lowest level. It is a drop-in replacement for a drive and the solid state aspect merely records and plays back flux transitions. No attempt is made to interpret the pulse stream or convert pulses to data. It doesn't matter whether the controller that uses the drive is hard or soft sector, how the data is encoded, the order the bits are written, etc. It literally replaces the magnetic disk surface with solid state storage."

I think this is what I was hoping OpenFlops did, that it just looked like a disk drive and didn't care too much about what was being written to it or read from it.

[deltecent]

If I can't get the hard sector information from a reputable source, I'll load a hard sector floppy into my Shugart 801 and measure the pulses.

[keirf]

It's entirely possible that getting flashfloppy to generate the sector pulses might end up being easier as it gives FF control over when it declares it can serve up sector data. Rather than being yoked to autogenerated strict sector pulses.

Assuming that the FDC is prepared to accept some oddly timed (eg late, or surprise skip to end of track and track index mark) index pulses in this case.

Ultimately if the requirement is hard realtime then a dedicated solid state solution is surely going to be best of all. The FDC+ looks like a great bit of hardware I must say.

[deltecent]

It's entirely possible that getting flashfloppy to generate the sector pulses might end up being easier as it gives FF control over when it declares it can serve up sector data. Rather than being yoked to autogenerated strict sector pulses.

The FDC+ does support hooking up a real Altair drive, which probably means the index/sector pulses are just passed through, so yes, that probably would have a better chance of working. In looking at the source code to the disk drivers, it looks like it just waits on a sector pulse and then initiates a read or write.

The FDC+ looks like a great bit of hardware I must say.

For S-100 computer users, such as Altair, it is great. While I have some 8" drives, they are old, so I don't like to use them. In addition to being very flexible with connecting 8" and 5.25" drives, the FDC+ also has a serial port that can connect to a serial server. I can "mount" disk images to the serial server and the FDC+ reads/writes tracks over the serial cable. I wrote a server for Linux and Mac. I typically run my server on a Raspberry Pi. It all ties together because the same disk images can be used on the AltairZ80 simulator. I can do a bunch of work on the simulator, mount the same disk images on the serial server, and then boot my Altair using that image to make sure what I did runs on real hardware, or I can then take that disk image and write it out to an 8" floppy.

[keirf]

Is there a particular reason then to want to get the gotek/openflops hardware working instead of your pi solution? Because that does sound pretty neat, though obviously dependent on the FDC+ magic.

[deltecent]

Is there a particular reason then to want to get the gotek/openflops hardware working instead of your pi solution? Because that does sound pretty neat, though obviously dependent on the FDC+ magic.

No other reason than to see if it would work as another option, and people on the Altair Facebook group seemed interested. Of course, the ultimate goal was to get it to emulate various 8" drives and use with Tarbell, Jade, or CompuPro controllers too. These are all soft sector, mostly using the Shugart interface and IBM 3740 format for single density mode.

[omikron88]

Gotek works well with IBM 3740 format for single density 8'' drives. Tested with multiple computers. But it needs to set the correct bit rate and rpm in config file. Dne čt 1. 10. 2020 21:17 uživatel Deltec Enterprises < notifications@github.com> napsal:

…

Is there a particular reason then to want to get the gotek/openflops hardware working instead of your pi solution? Because that does sound pretty neat, though obviously dependent on the FDC+ magic. No other reason than to see if it would work as another option, and people on the Altair Facebook group seemed interested. Of course, the ultimate goal was to get it to emulate various 8" drives and use with Tarbell, Jade, or CompuPro controllers too. These are all soft sector, mostly using the Shugart interface and IBM 3740 format for single density mode. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXMWBGEVUHK6BBUPDEZBJ3SITIVBANCNFSM4R6NLF7Q> .

[deltecent]

Gotek works well with IBM 3740 format for single density 8'' drives. Tested
with multiple computers. But it needs to set the correct bit rate and rpm in config file.

That would be great if you could post a config file and/or image. No sense in reinventing the wheel.

[keirf]

@deltecent you can either do it with an appropriate rate HFE image (which you can make using the distributed scripts/mk_hfe.py script) or you can use an IMG sector file of the appropriate size, with geometry defined in an IMG.CFG file (see examples/IMG.CFG for the config file format). For example I guess an 8" FM disk is probably (this is for DEC RX01, it could of course vary by manufacturer):

[8inch]
cyls = 77
heads = 1
secs = 26
bps = 128
mode = fm
rpm = 360
rate = 250

And this would need an IMG file of size 77126*128 bytes.

[keirf]

I think broadly, for this ticket, the conclusion should be FlashFloppy works fine for soft sectored disks but is not really suitable for hard sectored disks. They may be best left to the hard-sector domain experts, as half the battle is testing and I'm never going to have suitable hardware!