Floppy Disk Formatting Issue

351 views
Skip to first unread message

Murray Johnson

unread,
Dec 13, 2025, 4:44:19 PM12/13/25
to Altair-Duino
I have built David Hansel's Disk Controller for the Altair-Duino and am running into an issue when I try to format a floppy disk with AFORMAT, using Mike Douglas' CP/M hard disk image .  Each track retries and fails at the fourth attempt, all the way through the disk.

The drive is a Teac FD-55GFR and the disks are MD2HD floppies.  Each tested out good on a Windows/DOS system, with no issues found by Scandisk after a full format.

The drive appears to be communicating properly with the Disk Controller; the Monitor function can do the head movements and measure rotation.  In CP/M I can address the drive with C: but of course there is a BDOS error as the floppy has not been formatted.  Reading the buffer for the first track returns all 00's.

The controller has the MITS firmware loaded and the header jumpers J2 - J7 are all at 1&2 except for J3, which is set to 2&3.  The four mode switches are all set to off.  I believe these to be the correct settings for CP/M, but I'm a newbie with this stuff.

Is there something that I'm missing?  Searching through the group didn't bring anything to light for me.  Thanks for any guidance.
Message has been deleted

Murray Johnson

unread,
Dec 14, 2025, 4:19:55 AM12/14/25
to Altair-Duino
Yes, all floppies set to none.  Only the hard disk image is set in the configuration.  I think I will try programming another Atmega328P to see if there is something wrong there.  As the AFORMAT progresses the drive steps the heads as we would expect.  For some reason data isn't flowing as it should.

On Sunday, December 14, 2025 at 12:44:05 AM UTC-5 John Galt wrote:
you have all floppies unmounted in the configuration menu? under (D) for disk drives make sure Drive 0,1,2,3 all set to none.

Patrick Linstruth

unread,
Dec 14, 2025, 6:00:42 AM12/14/25
to Altair-Duino
You can also try using Mike's AFEXER tool for debugging your floppy drive and controller. It can verify if anything is being written to the disk.

-- 
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/altair-duino/b23e9cd5-f9fc-40df-a66a-f92452acd8acn%40googlegroups.com.

da...@hansels.net

unread,
Dec 14, 2025, 8:51:51 AM12/14/25
to Altair-Duino
Make sure to turn off the "Throttle delay" setting in the AltairDuino config menu.
The AFORMAT (and ACOPY) programs send data to the drive using a very time-constrained protocol, so any tiny pause by the AltairDuino (such as for throttling the CPU to exactly match the 2MHz 8080 speed) will cause it to fail.
I would also suggest using either AFTEXER or the Monitor function to test writing to and reading from the drive. 

Note that since the Altair uses a hard-sectored disk format, you do NOT need to format a floppy before writing to it. You can just plop in a disk and start writing and reading sectors using the Monitor. AFORMAT (and regular FORMAT) just writes known data to each sector, it doesn't set up the sector structure itself as we are used to from soft-sectored drives. The sector structure on each track is defined by the sector index holes (when using hard-sectored disks that have an index hole for each sector).  For soft-sectored disks (only one start-of-track index hole) , the controller uses timing (time since it last saw the start-of-track hole) to define where the sectors are.
That's one other possibility why things may be going wrong: if the drive doesn't spin with a consistent enough speed then the controller may not be able to compensate for that.
Try writing and reading sectors within the monitor and see if you can get read the data back correctly.

David

On Saturday, December 13, 2025 at 4:44:19 PM UTC-5 ve3...@gmail.com wrote:

Murray Johnson

unread,
Dec 14, 2025, 10:15:07 AM12/14/25
to Altair-Duino
Thanks for the suggestions, everyone.  I very much appreciate the help.  I tried a new Atmega328P with the same result, rechecked all my soldering, and confirmed continuity on the ribbon cable.  The throttling is turned off in the configuration menu.  I will proceed with testing using the monitor function.  That will at least point in a direction for further troubleshooting.

Murray

Murray Johnson

unread,
Dec 14, 2025, 12:27:22 PM12/14/25
to Altair-Duino
Using Monitor I can confirm that the floppy disk is being written to by the AFORMAT command.  I wrote a buffer of 19h to track 6,0, was able to read it back - then tried the AFORMAT command.  Each track retried 4 times and failed as before, but Monitor shows that track 6,0 changed from 19h to E5h. So the Monitor can write and read the floppy disk.  AFORMAT is writing okay but appears to not be receiving track data back.

I measured the rotation period with Monitor's M command, and results were consistent over about 45 seconds: 166.896 msec (360 RPM) with Min: 166.892 -0.002% and Max: 166.928  +0.019%.  I think that looks okay?

Perhaps I should check the expansion bus.

Murray

Murray Johnson

unread,
Dec 14, 2025, 1:35:51 PM12/14/25
to Altair-Duino
So, until recently I had been proceeding under the (false) assumption that the floppy disk HAD to be formatted before it could be used.  Thanks to David for setting me straight.  I have been able to copy a file from the hard disk image to the floppy disk using PIP, and the program executed properly from the floppy drive.  After that I tried another AFORMAT on the floppy disk, but the result was still failure on each track.  The file I had copied was written over.  So, it's just AFORMAT that isn't happy with what it's reading back from the the disk (even though the data checks out okay (E5h)).

I guess I'm not going to worry about it :).

Cheers - and thanks again for the help!

Murray

Patrick Linstruth

unread,
Dec 14, 2025, 2:37:27 PM12/14/25
to Altair-Duino
Even the hard sector disks have a format, but the format works different than a soft sector format.

Each sector within a track has information in addition to the data, such as the track number, sector number, and checksum. The AFORMAT program writes this information and fills the data with E5. It then reads back the sectors and verifies the data read from the disk is the same as the data that was written. AFORMAT will fail if data read from the disk does not match what was allegedly written.

It would seem that if everything is working correctly, AFORMAT should work too.

;---------------------------
; Altair 8" Diskette Format
;---------------------------
;  Raw Bytes/sector: 137
;     Sectors/Track: 32, numbered 0-31
;   Tracks/Diskette: 77, numbered 0-76
;
; Tracks 0-5 are "System Tracks" (regardless of how they
; are actually used). Sectors on these tracks are
; formatted as follows:
;
;     Byte    Value
;      0      Track number and 80h
;     1-2     Number of bytes in boot file
;    3-130    Data
;     131     0FFh (Stop Byte)
;     132     Checksum of 3-130
;    133-136  Not used
;
; Tracks 6-76 (except track 70) are "Data Tracks." Sectors
; on these tracks are formatted as follows:
;
;  Byte    Value
;     0      Track number and 80h
;     1      Skewed sector = (Sector number * 17) MOD 32
;     2      File number in directory
;     3      Data byte count
;     4      Checksum of 2-3 & 5-134
;    5-6     Pointer to next data group
;   7-134    Data
;    135     0FFh (Stop Byte)
;    136     Not used
-- 
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.

Murray Johnson

unread,
Dec 14, 2025, 7:12:15 PM12/14/25
to Altair-Duino
Yes, AFORMAT should work.  I've tried a different drive, a 3.5 Teac FD-235HG and saw the exact same behavior.  I've also tried the combinations of F flags in the Monitor setup (Sync After Step & Relative Sector Timing) with no change.  There is data being recorded on the disk and it's being read back.  The rotation appears to be correct and stable.  Unless there is some kind of timing issue that AFORMAT is exposing I really don't know what to try next.  That being said, I do appreciate the suggestions.

Murray
Message has been deleted

Murray Johnson

unread,
Dec 15, 2025, 3:54:11 PM12/15/25
to Altair-Duino
Some good points there.  I rechecked the Floppy card, the expansion bus and the backplane.  Continuity looks good, no shorts.  I put a scope on the ribbon cable to the drive and found that the Side Select (pin 32) was not changing while running AFORMAT.  With Monitor I can change sides from 1 to 2 and back again - the scope shows HI when set to side 1, LO when set to 2 and the drive is jumpered accordingly (default).  When running AFORMAT pin 32 just stays high as the drive steps inward from the outside.  I expect that it should be toggling to each side with every step.  Like you John, I've swapped some chips around.  The output enable and direction pins on the 74LVC245 show lots of activity and swapping that chip made no difference.  It's probably time to study the firmware to see if I can gain some insight.

On Sunday, December 14, 2025 at 10:22:40 PM UTC-5 John Galt wrote:
don't rule out that your card is not 100% right....

I put together a few batches of cards for the Disk controller and one card just refused to work right couldn't figure it out,, tossed it in a box and just soldered another one together.

I had one RTC card that just refused to work right in that case i figured out that half the Clock chips i purchased appear to have been statically damaged and i kept replacing them until i found one chip that worked right.

on the one controller card that refused to work, the monitor on that card works fine and i can copy and burn disks with the monitor when i try to access the card from the altair-duino side it just refused to see the disks similar you the issue you have... i gave up on it and soldered another one together and it worked, i could not find if one of the chips was marginal or if it was an issue with a VIA or something i tried swapping ICs and it still didn't work... not worth the effort, just start over and get a good one and don't waste your time...

if you keep having cards not working then start to look at your backplane. i had a backplane that i hacked into an older revision and worked great until i opened the box to make a change inside and when i put it back together the backplane acted all flaky took forever finally found some wires that looked as if they were connected to my 25 pin adapter but turned out they fell out of the retention plates it was weird but what can you do.

da...@hansels.net

unread,
Dec 15, 2025, 3:56:50 PM12/15/25
to Altair-Duino
The original Altair disk drive is single-sided so that is what is emulated. 
The monitor function allows to select both sides of modern disk drives but the Altair will only use one.

Murray Johnson

unread,
Dec 15, 2025, 6:31:38 PM12/15/25
to Altair-Duino
Thanks David - That's what confused me.  I'm guilty of making assumptions based upon MS-DOS...  Going through the firmware I see now the only place that disk sides show up is in the Monitor.  BTW I tried to copy a DSK image to a floppy using the Monitor and it reported success in validation mode.  When I try to read it I get a BDOS Bad Sector error, although the directory looks okay.  I think I'll take John's advice and just build another card.  This particular one just doesn't want to work.
Message has been deleted

da...@hansels.net

unread,
Dec 15, 2025, 9:32:26 PM12/15/25
to Altair-Duino
One other question: did you compile the firmware for the Arduino Due yourself or did you use Chris' pre-compiled firmware?
If you compiled the firmware yourself and didn't set the optimization mode to "performance" then the AltairDuino runs too slow
to reliably communicate with the disk controller. Chris has the procedure in the "install software" instructions on his site.

David
On Monday, December 15, 2025 at 7:32:52 PM UTC-5 John Galt wrote:
reminds me i have to get around to assembling another disk card myself it has been sitting on my workbench for months.

Murray Johnson

unread,
Dec 16, 2025, 2:22:15 AM12/16/25
to Altair-Duino
I bought the Experimenter Kit from Chris - the Due came pre-programmed with firmware and with a microSD card.  I assume it was his pre-compiled firmware?

Murray Johnson

unread,
Dec 16, 2025, 2:21:44 PM12/16/25
to Altair-Duino
Well, I tried a different approach that seems to work.  Instead of using AFORMAT on the HDSK image, I created a blank floppy image with phatchman's Altair tools utility and used Monitor to install the image on real floppy disks, verifying each one.  That was successful for 10 physical disks.  I then exited Monitor and transferred some really large ASM files to a floppy and then TYPEd them to the screen.  I checked the disk with AFEXER and was able to move around and arrive at the expected tracks.  No issues whatsoever.

I am still mystified as to why AFORMAT won't work, but I now have 10 floppies that I can apparently use and trust.  Perhaps it has something to do with the tolerance of the 16 MHz crystal that is installed on the ATMEGA328P.  It's +/- 30 ppm, so who knows?  David says the timing is critical for that program.

I want to thank the group here for their suggestions and guidance.  I continue to be amazed at the technical skills and willingness to help exhibited by the folks in this community.

Cheers -

Murray
Message has been deleted

Murray Johnson

unread,
Dec 17, 2025, 2:06:08 PM12/17/25
to Altair-Duino
No, I've got that straight.  A> AFORMAT C: and the physical floppy drive steps through all 77 tracks with retries and failure on each one.  I had mounted Mike Douglas' CP/M HDSK as drive A, where I ran the command.  It looks like reading back the track is where the issue lies as examining a previously MS-DOS formatted floppy shows E5h has been laid down by AFORMAT.  Even unformatted floppies show the same behavior.

Mysteries of time and space...



On Wednesday, December 17, 2025 at 10:35:35 AM UTC-5 John Galt wrote:
just wondering when you used AFORMAT which disk did you tell it to format? people have gotten confused that Cp/M is MS-DOS where A: and B: are floppies. Cp/M depending on how your setup can be very different where C: and D: are your floppy drives.
Message has been deleted

Mark Episcopo

unread,
Dec 27, 2025, 4:01:09 PM12/27/25
to Altair-Duino
I'm having the same type(ish) of issues as murray.  I mount and run MITS 88-HDSK on A: (SD card). My 3.5" can be found on D: (end of the cable after the twist) ALPS DF354H.  I've tried this with the dip switches in various positions.  When I try AFORMAT, the drive spins up, the  8800 asks if disk is ready and I say Y.  I get a rapid clicking (like in the old days when there was a bad track)  and then it sits there ad infinitum .  I'm using formatted 1.44MB floppies.  Any thoughts.  I just want to write some asm, generate some data and save to the floppy.
Thanks
Mark

On Wednesday, December 17, 2025 at 2:42:28 PM UTC-5 John Galt wrote:
"Mysteries of time and space..."

i really miss flash games....
Message has been deleted

da...@hansels.net

unread,
Dec 28, 2025, 7:15:41 PM12/28/25
to Altair-Duino
This sounds to me like something is wrong with the drive itself. The drive should not make clicking sounds. It is possible that the track 0 sensor is not working correctly. The clicking could be the head bumping against the end of its rail.

I would recommend either using the AFEXER tool (see https://deramp.com/downloads/altair/software/utilities/floppy_disk/
or the monitor function that's built into the disk controller card to test basic functions such as stepping and reading/writing
sectors.

David

Mark Episcopo

unread,
Dec 30, 2025, 12:47:14 PM12/30/25
to Altair-Duino
SUCCESS !!!
Thanks Dave,
I turns out that the drive/card didn't like the connection to the floppy cable AFTER the twist.  I found that out by "ringing" out the cable connected to the board.  Checked the pin at the floppy end with the pins on U10 and U11.  Didn't match the schematic when testing the connector after the twist.    I moved the drive to the first connector and  changed the throttling from auto to off and - voila, it worked.   All tracks are being accessed,  I guess that's from the preformatted disks.  I can do a "a>d:" and the system switches to the d drive. I did a pip d:=a:ls.com and the file transferred.  
But, Aformat still gives the fail error however I can do an "ls" on the d drive and it shows that there is a file structure.  I'm waiting on the 235.  Can you have 2 floppies on this system? 
I'd like to be able to boot from the floppy but if it is now a "d" drive and the boot must be from the "a" drive, how do I do that?
Mark
Message has been deleted

da...@hansels.net

unread,
Dec 31, 2025, 9:50:31 AM12/31/25
to Altair-Duino
The card can definitely support two drives, one before the twist and one after. You can use DIP switch 2 to switch which one is treated as the first and second drive. I suspect your drive has some configuration jumper settings that need to be set properly to support it being after the twist. Or your cable has a problem.

To boot from floppy you need to use the floppy disk boot loader. Sounds like so far you've used the hard drive boot loader which will always configure hard drives as A: and B: and floppy disks as C: and D:

David

Murray Johnson

unread,
Dec 31, 2025, 4:33:23 PM12/31/25
to Altair-Duino
A quick update on AFORMAT failing on FD-55GFR Teac floppy drive - I obtained another FD-55GFR drive and tested it.  Same results.  Different ribbon cable made no difference.  Whatever is the cause appears to be something other than the drive - I even built another controller card and it made no difference.  Arduino Due isn't throttled and I'm using the stock SD image from Adwater & Stir.  Anyway, going forward I'll be content to write blank images using the monitor function on the controller to initialize and test floppies.  That works perfectly :).

Murray

da...@hansels.net

unread,
Dec 31, 2025, 5:15:29 PM12/31/25
to Altair-Duino
It's not clear to me why AFORMAT doesn't work - it works fine for me here. I suspect that for whatever reason your AD is running too slow, but I could be wrong.

Can you do the following as a test: Go into the configuration menu and press "f" to enable profiling. 
Then start MBASIC, type in the program "10 goto 10" and run it. Post here what the profiling line (top of the screen) says. I am seeing 129% here (with throttling disabled).

As an alternative you could use the FORMAT.COM program that comes with CP/M (AFORMAT is a speed-optimized format version written by Mike Douglas).
Note that FORMAT.COM does NOT work if you boot from hard disk. It only works after booting from disk drive.

David

Murray Johnson

unread,
Jan 1, 2026, 8:31:42 AMJan 1
to Altair-Duino
I did the test running Mike Douglas' CP/M hard drive image, MBASIC.  Throttle delay OFF.  The Performance line at the top of the screen reads 2000037 cycles in 1021.13 msec = 1.96 MHz = 98% (d=0).  That is certainly not what you're seeing, David.  I wonder what might cause my Due to be running slow.  I should mention that mine is the Experimenter model from Adwater & Stir and I am using the VGA output and USB keyboard on the rear apron.

Happy New Year -

Murray

da...@hansels.net

unread,
Jan 1, 2026, 12:02:05 PMJan 1
to Altair-Duino
I highly suspect that the firmware you are running was not compiled with the "-O3" compiler optimization setting and therefore runs slower.

I uploaded the firmware from the AD web site ("the easy way" here https://adwaterandstir.com/install ) and with that I see the same performance you are reporting and AFORMAT does not work. The .bin file from that archive is about 400k in size.

I compiled and uploaded the firmware from scratch here with the "-O3" setting  (and the same config settings Chris describes on his site). That results in a ~500k size .bin file with 133% performance in MBASIC and a working AFORMAT.

Just to double-check I re-compiled here again with "-Os" optimization (the Arduino default) and that results in a ~400k .bin file that runs slow.
So I think the firmware on the web site was compiled with size (-Os) optimization instead of speed (-O3).

I have attached the -O3 compiled firmware file to this post. You should be able to upload it using the instructions from the web site, just use altair8800-fast.bin instead of the altair8800.bin in the archive.

David
altair8800-fast.bin

Murray Johnson

unread,
Jan 1, 2026, 1:28:45 PMJan 1
to Altair-Duino
That is great news!  Thank you for digging into that, David.  I will upload the BIN file that you attached and give it a go.

Cheers -

Murray

Chris Davis

unread,
Jan 1, 2026, 1:41:37 PMJan 1
to Altair-Duino
Interesting, I don't know how the -O3 would get changed.  Maybe with a reinstall.  I'll recompile and update the website.

Chris Davis

unread,
Jan 1, 2026, 1:51:58 PMJan 1
to Altair-Duino
I think I found the problem - if the Arduino IDE is installed from the Windows Store. The Microsoft Store version of the Arduino IDE is a UWP (sandboxed) app.
Because of that some files are virtualized and Windows Store updates may overwrite it.  I'll make sure I always use the IDE dowloaded from arduino.cc.

Murray Johnson

unread,
Jan 1, 2026, 2:50:18 PMJan 1
to Altair-Duino
I've confirmed that AFORMAT works as it should with the fast image on my system.

Thanks guys for identifying the problem and helping me correct it.

Happy New Year to all.

Murray

Mark Episcopo

unread,
Jan 1, 2026, 3:11:54 PMJan 1
to Altair-Duino
Thanks Dave and Murray,
The fast compile fixed it. But some interesting things:
Initially the new system didn't recognize the floppy.  Looking at Adwater's reload instructions, I saw that some things needed to change in config.h.  I'm using MITS so I set the NUM_DRIVES, NUM_CDRIVES and NUM_TDRIVES  to 4.  Got all kinds of errors. So I set NUM_DRIVES to 4 and the others to 0.  All seems good, but can I now not use the Tarbell or Cromemco drives?  The screen says "Formatting 8"...." but no big deal.
I set USE_IO_BUS to 1.
This is all with the TEAC drive.
I tried uploading the bin file but all of my computers (W10 and W11) say there is no upload command using the command prompt in admin mode. I'll figure that out later.
Mark

Mark Episcopo

unread,
Jan 1, 2026, 3:13:48 PMJan 1
to Altair-Duino
Never mind the upload thing, I've got it !!!!!

da...@hansels.net

unread,
Jan 1, 2026, 7:58:11 PMJan 1
to Altair-Duino
I just added a compile-time check to make sure performance optimization is selected when USE_IO_BUS is enabled.
Hopefully that should prevent similar problems in the future.

David
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages