Open JMarlin opened 1 week ago
Making the steps explicit here:
Updated everything and started testing -- looks like I probably have a bug somewhere because I'm back to getting that disk corruption again. Time to start debugging.
As a note to self: Is there really a problem with stashing this issue for later and just moving forward with a memory map of 16k RAM, 4k slot, 8k RAM, 4k bios/switches? Jam BASIC and the floppy write routines in the high 8k and call it a day.
Um. Hmm. Did a double-check on this after lunch and it's totally possible that I just forgot to copy the new NOS image to the ADT directory because I did that and wrote a new floppy and it looks like it works well.
Whelp, NVM. Tried to launch DONKEY, but apparently the switches aren't working because after loading it booted right back into the BIOS.
Gonna need to give this a thorough clean-out and retry in the AM.
Did some harnessing, and the switches aren't getting toggled. So I suppose that's good. I think now I'll move on to setting breakpoints to debug NOS boot to try and figure out where it's going wrong.
Ah. Right. The issue I saw last time is that the switches AREN'T working. Right.
Today I'm back to boot being completely inconsistent, can barely bring up NOS. I've managed to rule out the RAM (I think) by hard-wiring it to always get selected with A14 = 0, same exact behavior. I feel like this HAS to be a software issue, because pretty universally the NOS first stage gets picked up and runs and it seems like the issue only kicks in when we try to load and run SHELL, but I have no thoughts on what it could actually be. Or, for that matter, why if that is the case it seems to work intermittently rather than just always failing.
No great progress today. Ended up rolling everything back to current master just to rule out a hardware issue/do a general sanity check.
Weird result from the day was that NOS and SHELL booted up just fine, but when I ran DONKEY while all of the FS stuff seemed fine the switches didn't switch and I ended up with the machine just rebooting, just like I had on Friday with (what I thought?) was the floppy-at-e000 version of the code.
Maybe I do have a hardware issue that's just not manifesting itself fully until I update the slot mapping? Next time, I should start by just switching to a nice new PAL just in case before I try and come up with any further debugging steps.
New PAL, same behavior. At least that weeds that out as a point of failure.
Requires prior completion of #36 so that new slot location doesn't conflict with switches Intent is to slide up the slot area to provide more room for cart RAM