SKS64 in 1541C is not working

[synattack]

I have a short and longboard C64 both with your SKS64 solution, and both are working fine (ATTINY85, Firmware 1.6 in combination with an RGB LED).

Because I also own a 1541C drive I tried installing the SKS64 board for a 1541C/1541-II so it switches between stock and Jiffy ROM automatically.

Unfortunately, I still didn't succeed in getting this to work. The RGB LED and/or the kernel in the 1541C isn't changing when I do a SKS64 reset on my C64 (tried both the shortboard and longboard C64).

The board for the 1541C is build as described in your manual (shortboard version, no U2 and bridged JP1 JP2 and JP4). The RST is connected to R12

As EEPROM I used a W27C512 (could this be the issue?) which has the following 16K ROMs: 1541C.251968-02.bin (http://www.zimmers.net/) + JiffyDOS_C1541.bin (since I'm using a 27C512 I copied them twice).

Do you have any tips on how to troubleshoot this?

[bwack]

Have you seen my videos ? https://www.youtube.com/watch?v=BPDDgQBmcGY&list=PLtQOf_JULmrQTB7486X5pXG1Aaxbl_RdE&index=13

[synattack]

I watched the 1541C video, but missed the other one ("Commodore 1541 drive with kernal switcher controlled by the C64"). If I understand correctly there is a difference in how the RST signal works between the different boards... But I also have a 250407 board so coming weekend I will test with this board.

[synattack]

When using a 250407 board everything is working fine. Maybe it's an idea to add a comment in the manual about the different RST signals in the different C64 boards?

[bwack]

Ok I can add that to the manual. The reset signalling is experimental, and i know it doesnt work over all the numerous models of motherboards and disk drives.

[bwack]

Thanks for finding this out.

[bwack]

It's not clear what is the cause of this, and I'm trying to resonate to a solution.

I notice that the 250469 (shortboard)

1. has a split reset on the motherboard. INTRST resets the C64, EXTRST resets the drive.
2. only one of them is driven by an open collector driver, and the other a push pull driver (74LS14).
3. The SKS64 reset cannot work if it is connected to a push pull driver.
4. The suggested connection point on the motherboard, as shown on the readme (and below here), is then false because of 1., we only reset the C64 (INTRST).

Connecting the reset the other side of U22 will drive both EXTRST and INRST, but will not work because of 2., the mcu would then fight with the driver of U23. However connecting it to U23 pin 5 (input) could work, though notice this connection is a slow rise (power on reset) thing where a capacitor is slowly charged. So the mcu would need to both push and pull to be quicker when it communicates over RST.

The C64C reset (U23 is 74LS14, and U22 is 74LS06):

When it comes to the firmware, moving the SKS64 reset connection to U23 pin5, i have a few conserns: the reset routine:

      ss.ignore();
      ss.write(0xde);
      ss.write(rom);
      pinMode(INTRST, OUTPUT);
      digitalWrite(INTRST, LOW);
      delay(300);
      pinMode(INTRST, INPUT);
      ss.listen();

• The time for the reset line to go high after pinMode(INTRST, INPUT) might be too long before ss.listen(). Not sure if ss (software serial) will interpreat this as a transmission.. Though the consern in 4. regarding "mcu would need to both push and pull when it communicates over RST", yes this is done already by the software serial routine.

[bwack]

I had think about this 250469 reset serial comms issue. serial transfer on a 220uF capacitor line isn't such a great idea lol. Though, why wouldn't we just connect INRST and EXTRST together?