Frequent LOAD ERRORs with JiffyDOS

[jpcompton]

On release 59 I'm getting a lot of LOAD ERRORs on uIEC 3 (both my 3.0 and 3.2 models, with different SD cards). It's happening both with straight PRG loads and activity inside disk containers. Please let me know how you'd like me to help track this down.

Unlike previous issues it's not dropping me to EEPROMFS, I still see the expected directory/container. But it's extremely unstable for generic disk activity.

[jpcompton]

(I guess the place to start looking would be any changes made between the last test build sent to me and the release?)

[thierer]

(I guess the place to start looking would be any changes made between the last test build sent to me and the release?)

So what you're saying is that you don't have these errors with the firmware I sent you on Oct 8th, but you do with the firmware from sd2iec-1.0.0atentdead0-59-g5f6521d-binaries.zip? That shouldn't happen, as both files are identical (md5 e8c0c9bf2d78ad78d531d8617e9c489f).

[jpcompton]

I now see that you're right, of course.

Digging into what's changed on my desk since that testing wave, the issue seems to be with JiffyDOS. When JiffyDOS is enabled, I get the LOAD ERROR issues. With JDOS disabled, loading behaves as expected.

I was testing with various compatible carts on KFF during our earlier waves, on a machine which only had the stock kernal installed. This morning I switched to a JDOS-equipped machine and thought I needed to install the Release 59 edition, which caused me to notice these issues.

[thierer]

When JiffyDOS is enabled, I get the LOAD ERROR issues. With JDOS disabled, loading behaves as expected.

I can't reproduce that with JD 6.01. Which version are you using?

Could you please test the attached version? It's basically -59 with 5e8757a1 reverted, which is the only Jiffy-related change I can think of right now.

sd2iec-1.0.0atentdead0-62-ge130417-m1281-uIEC3.zip

[jpcompton]

Also 6.01.

That 62 build seems stable on this JiffyDOS setup, no unexpected issues.

[thierer]

That 62 build seems stable on this JiffyDOS setup, no unexpected issues.

Ok, thanks! Unfortunately that delay is needed with a 16 MHz clock, that's why I made the change in the first place. But less than 11us might work, too. I'll have to check. Hopefully we can find a sweet spot that still works for you.

[thierer]

What's strange is that with my setup I have to increase the hold time all the way up to 14 us before I start seeing (rare) "LOAD ERROR"s. That's quite a difference.

Anyway, I now reduced it to 6 us, which still seems to work with a 16 MHz clock. Could you please test the attached firmware, if this works for you, too?

sd2iec-1.0.0atentdead0-62-gf4e598b-m1281-uIEC3.zip

[jpcompton]

Works here, yes, no LOAD ERRORs.

I hesitate to mention but since it's not going away: I've also been noticing in these recent test builds (which also means it may be in your last RELEASE) that sometimes the filesystem is in EEPROMFS after a startup (usually a warm reset via cartridge reset.)

Unlike the previous issues of this nature,

• I haven't yet affirmatively spotted it dropping to EEPROMFS during a normal user session,
• @CP always seems to change me into the "real" filesystem, unlike the past issues where we would sometimes need to hit it multiple times to escape the EEPROMFS.

[thierer]

Works here, yes, no LOAD ERRORs.

Thanks for the confirmation! I just pushed 2d5792b2, which includes this fix. I won't prepare a release for that, but it will be in the next release. Until then, you can keep using the test firmware.

Regarding your other issue: I'll keep it in mind, but right now don't have a good idea what could cause it (and it never happens for me). Is this strange "ARTD - CHAR 0" entry real or some artifact of dropping to the eepromfs? If the latter: Is it always this text or is it random?

[jpcompton]

ARTD is a real file: it's an attempt to save a character during a play session of Alternate Reality: The Dungeon but (because of these issues we've been working on) the uIEC was in EEPROMFS instead of my SD card at the time of my game save!

[thierer]

sometimes the filesystem is in EEPROMFS after a startup (usually a warm reset via cartridge reset.)

Does that mean it works before the reset? I haven't found the schematics of the uIEC, but imho a soft host reset (that is, without power to the uIEC getting cut) shouldn't affect the uIEC at all. And if it does, the reason might be a problem with power during reset, which could explain the behavior (voltage drops -> uIEC resets -> power isn't enough to properly initialize the sd card -> falls back to eepromfs). If so, this should happen with the official firmware, too, though.

[jpcompton]

The uIEC appears to reset when Kung Fu Flash is disabled with F7:

https://user-images.githubusercontent.com/51372049/199306943-673bfb69-815f-4b66-80da-7bbcaa3be6a8.MOV

So I can change testbeds for a different result, but, hey, more data for you!

[jpcompton]

Simpler and more "directly electrical" demonstration of reset, with a Freeload (Fastload clone w/disable switch and reset button) cart installed:

https://user-images.githubusercontent.com/51372049/199504074-4eeca4e7-4bcc-466d-86c6-c18195e6d258.MOV

[thierer]

What happens if you unplug the serial cable from the uIEC? Does it still reset when you reset the computer?

[jpcompton]

No, no uIEC reset (tested on both Freeload reset button and KFF kill) if IEC cable disconnected but power still coming from cassette port.

[thierer]

Ok, so the IEC reset line is apparently connected to the MCU reset of the uIEC.

I still don't understand why it would cause problems with detecting the SD card, though. Are you sure this doesn't happen with the mainline firmware?

[jpcompton]

I can try. I usually wasn't on the bleeding edge of Korb's releases, for some reason I can't quite remember. You want me to just run with -29 for a while and see if it shows up?

[thierer]

You want me to just run with -29 for a while and see if if shows up?

Yes, I think that would be helpful. My thinking is: If my theory is correct that the sd2iec not being able to mount the card is caused by the external reset, you probably wouldn't notice if you were running a firmware without eepromfs, because in this case the firmware would not fall back to it and just silently again try to mount the SD card the next time you try to access it.

Looks like eepromfs was added with 7f7590148 back in 2014, so your previous firmware probably did include it. If you never upgraded the firmware the device came with, though (and it therefore maybe lacked eepromfs), this might be an explanation why you never noticed the problem before. This is pure speculation, though.