External 1541, no sdcard

[rufreaknnuts]

Remove sdcard, connect 1541.. Computer hangs at bytes free banner. Unplug drive and I get the READY prompt. Why?

[JimmyDansbo]

I am not 100% sure, but I think that the SD card slot is hard coded to device 8
Even without an SD card inserted, your 1541 still needs to be set at another ID to function.

[voidstar]

It runs in my memory that if the SD card is removed, and "something" is connected to the IEC port, the system KERNAL ROM expects that something to be set as device 8?

I could be wrong or mis-remembering though.

[rufreaknnuts]

The user guide states serial device 8 is available on the IEC bus if no sdcard is present.

[ahenry3068]

The user guide states serial device 8 is available on the IEC bus if no sdcard is present.

I forwarded your post over to Discord. 1 user over there seems to think that your main problem is that the 1541 is in General a P.O.S. In more technical terms there's often Bulk Capicitance Issues with Random 1541's

[DragWx]

I can confirm via the Kernal ROM's source code that device 8 is the SD card if and only if an SD card is inserted, and goes to the IEC port if not.

It's probably already clear, but the Kernal is trying to load "AUTOBOOT.X16" from device 8 when the computer boots, and it clearly seems to be accessing the 1541, but the 1541 is supposed to "time out" when you try to read a file that wasn't successfully opened (the system proceeding to the ready prompt the moment you disconnect the 1541 is proof), so I wonder what's going on?

[DragWx]

Is it possible that the X16 is booting faster than the 1541 can initialize?


The starting handshake for communications is usually something like this:

1. Host (C64 or X16) pulls CLK low.
2. Devices pull DATA low.
3. Host takes as long as it needs, then releases CLK when ready.
4. Devices take as long as they need, then release DATA when ready.
5. ......

Step 4 doesn't have a time limit, and that makes sense because printers and disk drives have to perform lengthy mechanical operations, and the host needs to be patient.

This handshake is the same both for data and for "attention" byte transfers.

According to some random literature I found while searching, during an "attention" signal, some devices will automatically pull the DATA line using hardware, because this is time-sensitive ("device not present" happens otherwise) and the device's CPU may be busy at the time.


This is my hypothesis, which someone else would need to check:

1. During boot, X16 tries to address device 8 by pulling ATN and CLK low. (because it wants to load AUTOBOOT.X16 from it)
2. If 1541 is a device that automatically acknowledges ATN with circuitry, it reflexively pulls DATA low while the CPU is running initialization code.
3. X16 is ready to send the "device 8, LISTEN" command, and releases CLK.
4. 1541 completely missed the signal that "attention" is happening, so now it idles without ever resetting the circuitry that automatically pulled DATA, so it just holds it indefinitely.
5. X16 stalls because it's waiting for DATA to go high and it never will.
6. User turns off 1541, which causes it to release DATA, allowing the X16 to finally continue with the handshake, which times out because the 1541 isn't present anymore. X16 boot routine finishes.

[kelli217]

If that were the case, hitting RESET on the X16 would fix it, wouldn't it?

[DragWx]

It depends, the IEC port has a RST line so when the host is reset, all of the devices are reset too. I'd imagine the X16 passes its reset signal through to the IEC port as well (I know the C128 does), but I haven't checked so I don't know for sure.