0xDE read/write after reset

[robin-raymond]

while (ss.available()) {
    uint8_t data = ss.read();
    if (data==0xde) {
      delay(1);
      if (ss.available()) {
        rom=(ss.read());
        flashcounter=0;
        set_ledcolor(rom);
      }
    }
  }

I have a question regarding this code, and it's probably my lack of understanding. From what I see the loop enters and continues to look for 0xDE from the serial bus (which is sent after a remote side sends during a rom switch). I understand the IEC does a transmit/receive handshake which effectively isn't being monitored by the code and instead the code defaults to listen except when the "RESTORE" line changes the ROMs (so a temporary Tx happens then the state machine goes back to listen).

What I don't understand is why 0xDE is being monitored forever (or if somehow the monitoring is disabled). If a transmitted data chunk contains the sequence 0xDE in it, wouldn't this be interpreted as a ROM switch?

What I checked for:

• I don't see an exit to loop() [AFAIK the loop goes on forever in the code]
• I don't see ss.ignore(); [which would ignore all the received bytes]
• I don't see ss.end(); [which would end the listener]
• I don't see going back into Tx mode which would cause contention (and that doesn't appear to be the case)
• I don't see a goto label; from the loop that would skip the receive
• I don't see logic which would only look for 0xDE at the start of a serial command sequence [which in theory should never have a 0xDE as the first byte in the control codes] (but maybe I'm missing some subtleness in the code)
• I don't see control flow logic which would skip the ss.read(); if it had data available
• AFAIK the 1541 ROM isn't shadowed to RAM after reset which would have the side effect of a switch to effectively be ignored (which I couldn't see happening anyway given that the 1541 only has 2K of RAM anyway).

Yes, I saw clearly in your video that a game loaded and I can't imagine it didn't contain a single 0xDE value sequence followed by a random byte that would not cause some issue, or that someone else using your switcher hasn't hit an issue.

So how is this magic happening where a 0xDE byte in the serial protocol doesn't cause all sorts of random issues?

[bwack]

They are listening and sending on the reset line.

[bwack]

Maybe you missed the first video https://youtu.be/BPDDgQBmcGY?si=ZJ5OWkKWSvlbuMEU

[robin-raymond]

I watched that video twice. I understand they read/write on the same pin as this a half duplex IEC serial line. The concern was not with the listening/sending. The concern was with the continuous / forever monitoring for 0xDE byte in the listened serial stream.

[bwack]

No its not the serial line, it's the reset line in the serial cable.

[robin-raymond]

Ah, sorry, that’s an important distinction. Not sure why my brain glossed over that super important detail. Likely because I didn’t think anyone would use this line doubled as a Tx/Rx even though you did show it in the video. Do we know how all IEC devices will respond to a pulse of high/lows prior to a full reset, including devices like the printers, SD2IEC and Ultimate II? I presume they would be ok because in early commodores the IEC was directly connected to the CPU which means it would receive the same reset as the expansion port (I think), and I could see that port potentially having button debouncing issues when a reset button was in use by a button connected in an expansion cartridge. Although Ultimate II might never expect a reset to happen given its in control of the reset line being plugged into the expansion port at the time of use. I don’t know its internal circuitry. Do you anticipate any issues with other non disk devices or other virtualized ones? Obviously the Ultimate II wouldn’t detect this and switch roms, I get that. I know virtually nobody will connect a printer anymore but there are other potential IEC devices.

[bwack]

No worries. I haven't tested with printers, SD2IEC or ulitmate II. I also presume they will be ok since the will be held in reset after the pulsetrian of serial data is transfered. I don't know, and I don't think it will be a problem.

[robin-raymond]

I too think it will be fine. It might be that some IEC + cartridges may have compatibility issues on older C64s where the RESET is directly wired into the CPU along with the external port RESET (because that might do something strange) but if we do a long enough RESET low pull after a bank switch then it shouldn't be a problem (which you'd have to do to clean out active running assembly programs anyway). The expansion port pin is "in" not "out" so I don't know if any cartridge ever reads that RESET pin (at least they shouldn't) where the IEC RESET and expansion RESET are linked together in older boards. Even then I think any possible problems will be rare and obscure. I'll be sure to test with Ultimate II / SD2IEC and see how they behave as soon as I get my boards and have some time to test. Thanks!