Mega 2560

i'm not familiar with SD2IEC code, but maybe your original code is using interrupts on the pins of PortD ?

if so, you also need to switch the interrupt-source for the ISR routines accordingly.

At least ATN must be on a pin that can trigger an interrupt. If you want to use Dreamload, CLKin must also be on a pin that can trigger an interrupt. The code can use either a dedicated interrupt for both or a common pin change interrupt for the entire port.

There is another problem though: The ATmega2560 is a 22-bit PC device, which means it needs an additional clock cycle for (R)CALL and RET instructions compared to the AVRs supported by sd2iec. The low-level fastloader code is written in cycle-counted AVR assembly, so the timing will be off. I'm not sure if this change is big enough to throw off JiffyDOS, but it will almost certainly cause data corruption with Turbodisk.

Hello,

I've had the same problem when trying to use a RTC and SDCard shield on the Arduino Mega (one of the github repositories you've forked is actually mine). I did not succeed.

The problem is: All pins (ATN, CLOCK, DATA, SRQ) must be on the same port. As Unseen already wrote, you need an interrupt at least for ATN. The Arduino Mega has interrupts only on port D and port E. Port E is already allocated by the serial transmission via USB. So you're stuck on Port D and block the I2C port.

Bye,

Patrick

Zitat von pdaehne

The Arduino Mega has interrupts only on port D and port E

If you use dedicated interrupts for both ATN and CLK, nothing stops you from connecting the signals both to the IEC-dedicated port and to a pin on another port that can trigger a dedicated interrupt. It might need a bit of additional initialization code to set up the interrupt pin as input with pullup though.

Right, I didn't think about that.

Zitat von pdaehne

The Arduino Mega has interrupts only on port D and port E. Port E is already allocated by the serial transmission via USB. So you're stuck on Port D and block the I2C port.

I don't know about the specifics of the shield used, but PCINT lines are plenty. I can't see why you shouldn't be able to use Port B.

Zitat von xlar54

This isnt an i2c application, so Im not sure why it needs to be on the i2c pins.

If you don't need it just don't use any of the CONFIG_REMOTE_DISPLAY, CONFIG_RTC_DSRTC or CONFIG_RTC_PCF8583 flags.

Also, sd2iec doesn't seem to use the AVR's hardware i2c anyway, so you should be free to use other pins for i2c, if you did.

That all said, I doubt a missing ATN interrupt is the reason for the "LOAD ERROR", anyway. I would expect (haven't checked, though) that 1. this would result in a "DEVICE NOT PRESENT" or "FILE NOT FOUND" error and 2. Jiffy-DOS wouldn't have stricter timing requirements in this regard, so it would already fail with standard serial.

Zitat von thierer

I don't know about the specifics of the shield used, but PCINT lines are plenty. I can't see why you shouldn't be able to use Port B.

Yes, but the sd2iec firmware is built around External Interrupts and not Pin Change Interrupts, and I didn't want to mess around with the firmware to get Pin Change Interrupts working (you have to check in the interrupt handler which pin actually changed etc. etc.). Besides the fact that port B is also quite crowded - the SPI pins for the SDCard are on port B, and the LED of the Arduino, which acts like a pull-down resistor. For me it was easier to abstain from using the RTC, which is a pity, because it is available and it would be nice to have correct time stamps on the SDCard.

Yes, that should work. But I would try the approach that Unseen proposed above. Try to find a free port to connect the four IEC pins to (use ports A-G on the 2560, ports H-L won't work without changes to the firmware). Then, additionally connect the ATN and CLK pins to a pin with a free interrupt (i.e. PD2/PD3/PE4/PE5). Seems to be much easier than trying to get software i2c working.