Adventures with a floppy drive

[Marco]

This week I build myself the floppy disk controller. While I'm still waiting for delivery of tow TEAC FD-235HG 3.5" drives ordered from Fleabay (hope they're any good) I have substituted them with a single NEC FD-1231H 3.5" drive I had lying around. MITS firmware loaded on the controller card, only J3 on, all DIP switches to off, and using HD floppies.

Basically, it works! Almost, but I can't tell if what doesn't work is related to the NEC floppy drive until I get my hands on the TEAC drives, or I'm doing something else stupid.

I (of course) have removed the floppy disk images in the AD settings, and boot to CP/M on HDISK03 (CP/M 2.2b for Hard Disk).

As I am on Linux, I use picocom to connect to the AD:

sudo picocom -b 9600 -s "sx -b -vv -X" -v "rx -b -vv -X" /dev/ttyACM0

I can format a floppy, and read from and write to it:

Xmodem transfers work, that's how I got PC2FLOP on the HD image in the first place. However, when I use PC2FLOP this happens:

From the moment I type 'C' CP/M freezes. I can still tell picocom to start sending a file but as can be seen nothing happens, it just froze the moment the C drive was selected. The "Give your local XMODEM receive command now" message is I believe a standard message printed by sx (the Xmodem send executable). CP/M only comes back to life with a reset on the AD.

Similar story with the monitor. Connecting to it with this picocom session:

sudo picocom -b 115200 -s "sx -b -vv -X" -v "rx -b -vv -X" /dev/ttyUSB0

Looks fine, I would say:

Checking rotation looks okay too, I guess:

I can start and stop the motor, read and write sectors, etc, no problem. But again copying a floppy disk image fails:

Even before I can tell picocom to start sending the file, the monitor starts printing C's (checksum errors?). And when I give picocom the send command it immediately prints the NAK errors, up to the "exit status" message.

I keep trying, but I'm running out of ideas on how to get a floppy image onto a physical floppy disk. And hoping that once the TEAC drives arrive I can Xmodem to my delight! But it would be nice to understand what actually is wrong here.

[Patrick Linstruth]

Marco, I am not familiar with using the Duino with hard disk images but I am familiar with PC2FLOP. I am assuming Drives A and B and hard disk and C and D are 8” floppy.

PC2FLOP does not use CP/M to read a write to the floppy drive, it communicates directly with the floppy disk controller. If you enter “C” into PC2FLOP, is it going to convert that to physical drive 2. Even though your 8” drive is “C” under CP/M, it is physical drive 0, so you would need to enter “A” into PC2FLOP.

Before doing this, make sure you have a good backup of your CP/M drive A.

Another option is load PC2FLOP as a HEX file and eliminate CP/M. In that mode, your 8” drives will be referenced by physical numbers 0 and 1 instead of A and B.

Patrick

On Jun 8, 2025, at 5:33 AM, Marco <crou...@gmail.com> wrote:

This week I build myself the floppy disk controller. While I'm still waiting for delivery of tow TEAC FD-235HG 3.5" drives ordered from Fleabay (hope they're any good) I have substituted them with a single NEC FD-1231H 3.5" drive I had lying around. MITS firmware loaded on the controller card, only J3 on, all DIP switches to off, and using HD floppies.

Basically, it works! Almost, but I can't tell if what doesn't work is related to the NEC floppy drive until I get my hands on the TEAC drives, or I'm doing something else stupid.

I (of course) have removed the floppy disk images in the AD settings, and boot to CP/M on HDISK03 (CP/M 2.2b for Hard Disk).

As I am on Linux, I use picocom to connect to the AD:

sudo picocom -b 9600 -s "sx -b -vv -X" -v "rx -b -vv -X" /dev/ttyACM0

I can format a floppy, and read from and write to it:

<capture_250608-103519.png>

Xmodem transfers work, that's how I got PC2FLOP on the HD image in the first place. However, when I use PC2FLOP this happens:

<capture_250608-103738.png>

From the moment I type 'C' CP/M freezes. I can still tell picocom to start sending a file but as can be seen nothing happens, it just froze the moment the C drive was selected. The "Give your local XMODEM receive command now" message is I believe a standard message printed by sx (the Xmodem send executable). CP/M only comes back to life with a reset on the AD.

Similar story with the monitor. Connecting to it with this picocom session:

sudo picocom -b 115200 -s "sx -b -vv -X" -v "rx -b -vv -X" /dev/ttyUSB0

Looks fine, I would say:

<capture_250608-104034.png>

Checking rotation looks okay too, I guess:

<capture_250608-104136.png>

I can start and stop the motor, read and write sectors, etc, no problem. But again copying a floppy disk image fails:

<capture_250608-104249.png>

Even before I can tell picocom to start sending the file, the monitor starts printing C's (checksum errors?). And when I give picocom the send command it immediately prints the NAK errors, up to the "exit status" message.

I keep trying, but I'm running out of ideas on how to get a floppy image onto a physical floppy disk. And hoping that once the TEAC drives arrive I can Xmodem to my delight! But it would be nice to understand what actually is wrong here.

--
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/22e965e5-67c5-485f-ae2d-47d500437c35n%40googlegroups.com.
<capture_250608-104034.png><capture_250608-104249.png><capture_250608-103738.png><capture_250608-103519.png><capture_250608-104136.png>

[Marco]

Ahaa, that explains it. And yes PC2FLOP now works! Copied DISK01.DSK to a floppy and that one boots. Still not sure why the Monitor fails but in my case 115200 baud is probably just too much for Xmodem. It doesn't matter, I prefer PC2FLOP and FLOP2PC anyway.

Thanks!

Op zondag 8 juni 2025 om 12:30:07 UTC+2 schreef delt...@gmail.com:

[Marco]

So...next issue :-D

In the mean time I dusted off (actually thoroughly cleaned) the second NEC FD-1231H and added it as drive 1. That one works too s I think it is safe to say this type of 3.5" floppy drive works with controller card.

Then I thought I'd give ROM auto start a try so that the CP/M floppy in drive 0 automatically boots at Altair start, instead of SW3 up and AUX1 down to load the Disk Boot Loader ROM.

So I downloaded DBL.HEX from deramp.com, went to the settings, memory configuration, add ROM, and pasted the content of the hex file in the terminal, and gave it a simple name.

I then set the imported ROM to auto start. Finally I saved the configuration where I had made the changes. So far so good I thought.

However, it doesn't work. Not only does drive 0 not start spinning, but the whole configuration refuses to load. I tries the whole process several times, and each time I had to go in via another configuration and remove the ROM.

I am most likely doing something stupid again, but it would be nice to know what. Am I copying the wrong hex file, too little or too much, or in the wrong way? Hmmm....

Op maandag 9 juni 2025 om 09:32:19 UTC+2 schreef Marco:

[Patrick Linstruth]

Is there a problem if you specify 64K of RAM while having the top 256 bytes be ROM? Does RAM take priority over ROM, or does the Duino just drop the HEX file into RAM?

For a quick test, can you tell it that you have 63K of RAM and see if that makes a difference?

On Jun 9, 2025, at 1:26 PM, Marco <crou...@gmail.com> wrote:

So...next issue :-D

In the mean time I dusted off (actually thoroughly cleaned) the second NEC FD-1231H and added it as drive 1. That one works too s I think it is safe to say this type of 3.5" floppy drive works with controller card.

Then I thought I'd give ROM auto start a try so that the CP/M floppy in drive 0 automatically boots at Altair start, instead of SW3 up and AUX1 down to load the Disk Boot Loader ROM.

So I downloaded DBL.HEX from deramp.com, went to the settings, memory configuration, add ROM, and pasted the content of the hex file in the terminal, and gave it a simple name.

<capture_250609-180125.png>

I then set the imported ROM to auto start. Finally I saved the configuration where I had made the changes. So far so good I thought.

To view this discussion visit https://groups.google.com/d/msgid/altair-duino/acd1d60b-21c6-4fba-80de-e0d27904b43dn%40googlegroups.com.
<capture_250609-180217.png><capture_250609-180125.png>

[Marco]

Tested it just now, but doesn't make a difference.

Op maandag 9 juni 2025 om 19:52:14 UTC+2 schreef delt...@gmail.com:

[Marco]

Tried CDBL.HEX also, no change. The ROM is there (or at least there is data in the address space) and if I do not set auto start the AD starts, but with auto start set starting the configuration hangs the AD.

Op maandag 9 juni 2025 om 20:30:33 UTC+2 schreef Marco:

[John Galt]

what about MDBL?

[Marco]

No luck either with MDBL.

Op maandag 9 juni 2025 om 23:21:17 UTC+2 schreef John Galt:

[John Galt]

a lot of these roms are setup that you need to flip the SW0 switch to select what primary drive boots.(1 or 0) 

what i did is in my Configuration menu i reversed the primary and secondary drives so that the default was SW0 off

i realized this because i had reused disk formats and basically had every disk bootable. then i noticed my A and B were reversed.

if you have setup 0 as a bootable disk and 1 is non-bootable then it would default to the incorrect drive and not boot.

try flipping what you have mounted 0 and 1 and see if something changes.

[Marco]

I'll give that a try later today. However even if the wrong drive was accessed by the boot ROM, I don't see any activity on either floppy drive at startup. While on normal boot, then SW3 up AUX1 down drive 0 boots CP/M every time (it's originally DISK01.DSK copied with PC2FLOP).

Here's what I plan to try and see what happens:

• SW1 up and boot with CDBL auto-start.
• Swap floppy drives. Is that a physical swap, a configuration change (in AD settings or the disk controller monitor? can't say I've notices such an option in either, only for disk images) ?
• Check actual memory content at FF00-FFFF with ROM loaded (but not on auto start).
• Load another (non disk related) ROM to see if is related to the disk devices.
  

Op dinsdag 10 juni 2025 om 01:34:30 UTC+2 schreef John Galt:

[Marco]

Correction, I meant to say "SW0 up and boot with CDBL auto-start."

Op dinsdag 10 juni 2025 om 08:30:26 UTC+2 schreef Marco:

[John Galt]

does it work without the autostart?

when i use the harddrive rom i set FC00 on the switches, stop, reset, examine check the leds look correct then hit run and the hard drive boots.

if i set FF00, stop reset, examine check leds and then the floppy boots.

if the roms are not working at all then they could be corrupted with your method of transfer. i used Xmodem to transfer the roms using the tools provided by the configuration menu tools for the SD.

i'm using the MITS roms 

[Marco]

Yes, the ROMs do work without auto start. I have CDBL loaded in the configuration. I checked the memory starting from FF00 and it is byte per byte identical with the hex file. I can also run it in DDT with Gff00. It's just the autostart. I even made a new configuration with autostart, the rest default, but no luck.

Anyway, it's more annoying that something doesn't work and I'd really like to know what the cause is, but besides that it is not a problem. I have now set the Disk Boot Loader as the preferred AUX1-UP option in my configurations, that works fine for me.

Op dinsdag 10 juni 2025 om 16:21:16 UTC+2 schreef John Galt:

[John Galt]

interesting. 

i wish i could help more. i had mine setup using the Aux up shortcut for a long time i just got sick the front panel. loaded my rom and selected autostart and it worked(had that flipping drives issue)

what else would get in the way of autostart when it works manually?

[Marco]

Maybe one of the experts can shine a light on it, I don't know. What I still will try though is start with a fresh SD card and see it that makes a different somehow, but for the rest I don't know what else I could try or change.

The AUX1-up won't be a problem for me, maybe it even adds a bit of "authenticity" to my setup (yes I know the real Altair worked differently). I will never use my AD without the front panel. I plan to have the two floppy drives in an enclosure on top of the Altair. Then it's just Altair switch ON, floppy drives switch ON, AUX1 UP. I think I can manage that ;-)

Op dinsdag 10 juni 2025 om 19:40:19 UTC+2 schreef John Galt:

[Patrick Linstruth]

My guess is the code path for auto start is different than starting manually and something isn’t being initialized during auto start causing it to fail.

If I have time this weekend, I will set up my Duino and dig through the source to see if there is a difference.

Have you tried single stepping the boot code to see what it is doing or press STOP when it is in the weeds and see what code it is executing?

To view this discussion visit https://groups.google.com/d/msgid/altair-duino/c5c6fd1a-ad21-43a3-98a3-1be604712e2fn%40googlegroups.com.

[Marco]

When the AD is started with the configuration where the ROM auto start is set, the AD almost immediately halts at address 0909. Initially data bits D0, D1 and D2 are lit, but after a second or two first D2 dims and then D1. Furthermore WAIT, MEMR, INP and WO are lit. And the AD completely hangs, only a power off/on brings it back to life.

Op woensdag 11 juni 2025 om 12:38:52 UTC+2 schreef delt...@gmail.com:

[John Galt]

maybe there is a difference in the method of upload of the ROM to the profile? if using Xmodem in place of the HEX would change something.

 

i used Xmodem transfer.

[da...@hansels.net]

That light pattern means the AD is stuck trying to read from I/O address 9, which is in the FDC's I/O space.

What is likely happening here (and I do have some vague recollection of encountering this at some point) is that the Arduino Due in the AD starts up faster than the ATmega on the floppy disk controller card. So the controller is not ready yet when the AD is trying to read I/O address 9 so it misses the request and never releases the WAIT line, leaving the AD stuck.

If you manually start the ROM then of course there is enough time for the FDC to start up and everything works fine.

You could test this by temporarily connecting the Due's RESET line (the actual RESET pin on the Due, not the AD's RESET switch) to ground, then powering on the AD and then after a while releasing the RESET line. That should give the FDC enough time to boot up.

You should be able to fix this either in software by putting a delay within the "if" block here

https://github.com/dhansel/Altair8800/blob/51c7c175d88249388c8aa70648b44af81390864f/Altair8800.ino#L1736-L1741

or in hardware by pulling the Due's RESET line low for longer during powerup using a resistor+capacitor.

David

On Wednesday, June 11, 2025 at 1:48:53 PM UTC-4 crou...@gmail.com wrote:

[Marco]

Yes, the Due / ATmega timing is what caused it. Keeping the Due reset line low for a second makes the AD boot from floppy drive 0.

Good to have found the cause. However I'm not sure if I'm going to pursue booting from a physical floppy. Yes it works (now if I want even automatically) but I have seen some weird things happening in the mean time. When I start the boot loader BEFORE I have connected a terminal via the esp-01 (connected to the rtx/rts lines on the Due) then drive 0 keeps trying to load until I connect the terminal. Doesn't seem to happen if I connect the terminal via USB. Weird. After that on the next floppy boot it fails to load and spits out C's on the terminal. The disk is however still readable from HD CP/M. So yeah, fun to play with at the moment, but at one point it might get frustrating. Maybe better to boot from a HDISK image and use the floppies for programs and user data. I'm not sure yet. First I'm going to build a floppy disk(s) cabinet.

Thanks for the effort!

Op woensdag 11 juni 2025 om 20:16:18 UTC+2 schreef da...@hansels.net:

[John Galt]

awesome David :D

[Marco]

Next project finished, I'm happy with the result:

I got my two TEAC drives, but not going to bother with swapping the NEC's out for these, as the NEC's seem to work fine. One thing I did to them was changing the green LED's for a red one, much nicer looking.

Op woensdag 11 juni 2025 om 22:11:10 UTC+2 schreef John Galt:

[John Galt]

nice. 

[Walt Perko]

Hi, 

Well done!  

.