+MarcoJ Posted November 5, 2023 Share Posted November 5, 2023 10 hours ago, Al_Nafuur said: New parallel interface expansion I/O chips seem to be rare. Yes they are old hat. 10 hours ago, Al_Nafuur said: Alternatively we could use a MCU like the ATmega1284P with 4x 8 Bit GPIOs to emulate the IO parts of TIA and RIOT on the bus. But i am not sure if it is fast enough (20Mhz) I think it could work, though it would be operating more like a GAL or CPLD, just a logic controller. Perhaps a programmable logic device would suffice better. Depends also if the full 6532 / RIOT function is needed including the zeropage ram, or just input interfacing. Something like this could work for the former ,just input interfacing. I like this approach more than bitbanging I/O expanders or big clusters of logic chips, it's more harmonious to the 2600's original style of interfacing. https://www.microchip.com/en-us/product/atf2500c 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 5, 2023 Author Share Posted November 5, 2023 A lot of (solder) work, but no change in the results. Decathlon and SuperCharger still not working: 1 Link to comment Share on other sites More sharing options...
+MarcoJ Posted November 5, 2023 Share Posted November 5, 2023 1 minute ago, Al_Nafuur said: A lot of (solder) work Nice one. Should be hopefully easier to maintain it now. 2 minutes ago, Al_Nafuur said: Decathlon and SuperCharger still not working: I can get Decathlon's screen to show for an instant if running through PlusCart, but nothing for the original cart. In other news, I've had the Desire demo running for about 5 days on my rig. Still stable. 1 Link to comment Share on other sites More sharing options...
+MarcoJ Posted November 6, 2023 Share Posted November 6, 2023 https://www.intel.com/content/www/us/en/products/sku/210264/max-ii-epm240-cpld/specifications.html Something like this is cheap and cheerful. Commonly available for about $10. Could attach this to the Atari 2600's bus and do all the I/O tasks. Can program it with a $10 usb blaster lead. With the 3 extra GPIO pins needed, interfacing can be simple. It over-engineered for the job, but that gives it potential for future expansion. I wonder if it could also become a TIA and a 6532 chip too, who knows. 2 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 Here are some thoughts about the not working banking issues. SuperCharger: First I thought it might be a voltage issue with the SuperCharger (RAM?). But the banking is not working on the PlusCart too and since the PlusCart is 3.3V there should be no issues with the RAM there. FE: It is strange that the FE banking is not working on the PlusCart too, because it is a rather simple banking and the code is not doing anything more "special" than the working bankings. Except for listening to a RIOT address (0x1FE), but other working bankings are listening for RIOT addresses/data too. 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 7 hours ago, Al_Nafuur said: FE: It is strange that the FE banking is not working on the PlusCart too, because it is a rather simple banking and the code is not doing anything more "special" than the working bankings. Except for listening to a RIOT address (0x1FE), but other working bankings are listening for RIOT addresses/data too. I am pretty sure it is a timing issue. Someone had posted the FE schematics somewhere at AA and I remember a 1 cycle delay. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 1 minute ago, Thomas Jentzsch said: I am pretty sure it is a timing issue. Someone had posted the FE schematics somewhere at AA and I remember a 1 cycle delay. For the PlusCart (and probably for the real FE cartridge) a cycle is when the address-bus changes. They both don't have the 2600 clock, and having a internal clock that is "syncing" with the 2600 is very complex (e.g. Gameline) Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 (edited) 16 minutes ago, Al_Nafuur said: For the PlusCart (and probably for the real FE cartridge) a cycle is when the address-bus changes. They both don't have the 2600 clock, and having a internal clock that is "syncing" with the 2600 is very complex (e.g. Gameline) Maybe, and maybe it is complex. But I remember it very well. Maybe it is the automatic result of the code execution, so the 2600 would be the clock. Found it. Edited November 6, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
JetSetIlly Posted November 6, 2023 Share Posted November 6, 2023 2 minutes ago, Thomas Jentzsch said: Maybe, and maybe it is complex. But I remember it very well. Maybe it is the automatic result of the code execution, so the 2600 would be the clock. Full patent here https://worldwide.espacenet.com/patent/search/family/023848640/publication/EP0116455A2?q=84300730.3 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 2 minutes ago, Thomas Jentzsch said: Maybe, and maybe it is complex. It is not complex on the PlusCart (address-bus changes = next cycle) no matter how long (ns, ms, hours or days) the change takes! But still the banking is not working on the PlusCart with RTStella. 5 minutes ago, Thomas Jentzsch said: But I remember it very well. Your recollection is correct, see lastAccessWasFE here: https://github.com/Al-Nafuur/United-Carts-of-Atari/blob/main/source/STM32firmware/PlusCart/Src/cartridge_emulation.c#L346 9 minutes ago, Thomas Jentzsch said: Maybe it is the automatic result of the code execution, so the 2600 would be the clock. 🤔 how? Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 (edited) 2 hours ago, Al_Nafuur said: 🤔 how? I meant that the order of the address and data bus accesses (peeks and pokes in Stella) automatically introduces a 1 cycle delay. From Stella: // JSR case 0x20: { const uInt8 low = peek(PC++, DISASM_CODE); peek(0x0100 + SP, DISASM_NONE); // It seems that the 650x does not push the address of the next instruction // on the stack it actually pushes the address of the next instruction // minus one. This is compensated for in the RTS instruction poke(0x0100 + SP--, PC >> 8, DISASM_WRITE); poke(0x0100 + SP--, PC & 0xff, DISASM_WRITE); PC = (low | (static_cast<uInt16>(peek(PC, DISASM_CODE)) << 8)); } I am no expert here by far, but if the bankswitching happens 1 cycle after the peek to 0x1xx, then the final peek would read from the wrong (already switched) bank. No? Here is the RTS code: Quote // RTS case 0x60: { peek(PC, DISASM_NONE); } { peek(0x0100 + SP++, DISASM_NONE); PC = peek(0x0100 + SP++, DISASM_DATA); PC |= (static_cast<uInt16>(peek(0x0100 + SP, DISASM_DATA)) << 8); peek(PC++, DISASM_NONE); } Maybe one DISASM_NONE step is at the wrong position? No clue. Edited November 6, 2023 by Thomas Jentzsch 2 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 2 hours ago, Thomas Jentzsch said: From Stella: define(M6502_JSR, `{ const uInt8 low = peek(PC++, DISASM_CODE); peek(0x0100 + SP, DISASM_NONE); // It seems that the 650x does not push the address of the next instruction // on the stack it actually pushes the address of the next instruction // minus one. This is compensated for in the RTS instruction poke(0x0100 + SP--, PC >> 8, DISASM_WRITE); poke(0x0100 + SP--, PC & 0xff, DISASM_WRITE); PC = (low | (static_cast<uInt16>(peek(PC, DISASM_CODE)) << 8)); }') Does the comment in the code means that Stella is pushing a different value on the stack than the 6502? 2 hours ago, Thomas Jentzsch said: I am no expert here by far, but if the bankswitching happens 1 cycle after the peek to 0x1xx, then the final peek would read from the wrong (already switched) bank. No? I am no expert here too, but if Stella is doing things differently for JSR and RTS on the bus than the 6502 then it most probably will not work with the real cartridge and the PlusCart! The value pushed to 0x1FE defines which bank is being used. 2 hours ago, Thomas Jentzsch said: Here is the RTS code: Maybe one DISASM_NONE step is at the wrong position? No clue. is the last peek in the define to compensate for the "wrong" value being on the stack? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 According to (https://www.nesdev.org/6502_cpu.txt) the JSR cycles do: # address R/W description --- ------- --- ------------------------------------------------- 1 PC R fetch opcode, increment PC 2 PC R fetch low address byte, increment PC 3 $0100,S R internal operation (predecrement S?) 4 $0100,S W push PCH on stack, decrement S 5 $0100,S W push PCL on stack, decrement S 6 PC R copy low address byte to PCL, fetch high address byte to PCH and RTS: # address R/W description --- ------- --- ----------------------------------------------- 1 PC R fetch opcode, increment PC 2 PC R read next instruction byte (and throw it away) 3 $0100,S R increment S 4 $0100,S R pull PCL from stack, increment S 5 $0100,S R pull PCH from stack 6 PC R increment PC Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 18 minutes ago, Al_Nafuur said: Does the comment in the code means that Stella is pushing a different value on the stack than the 6502? Nope. 18 minutes ago, Al_Nafuur said: I am no expert here too, but if Stella is doing things differently for JSR and RTS on the bus than the 6502 then it most probably will not work with the real cartridge and the PlusCart! The value pushed to 0x1FE defines which bank is being used. That's something we should verify. I don't think it is the case, but better safe than sorry. 18 minutes ago, Al_Nafuur said: is the last peek in the define to compensate for the "wrong" value being on the stack? Nope #2. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 21 minutes ago, Al_Nafuur said: According to (https://www.nesdev.org/6502_cpu.txt) the JSR cycles do: # address R/W description --- ------- --- ------------------------------------------------- 1 PC R fetch opcode, increment PC 2 PC R fetch low address byte, increment PC 3 $0100,S R internal operation (predecrement S?) 4 $0100,S W push PCH on stack, decrement S 5 $0100,S W push PCL on stack, decrement S 6 PC R copy low address byte to PCL, fetch high address byte to PCH and RTS: # address R/W description --- ------- --- ----------------------------------------------- 1 PC R fetch opcode, increment PC 2 PC R read next instruction byte (and throw it away) 3 $0100,S R increment S 4 $0100,S R pull PCL from stack, increment S 5 $0100,S R pull PCH from stack 6 PC R increment PC I think Stella is doing the same, no? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 Just now, Thomas Jentzsch said: I think Stella is doing the same, no? It looks like this to me too. Hopefully the 6507 sees it the same way. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 20 minutes ago, Al_Nafuur said: It looks like this to me too. Hopefully the 6507 sees it the same way. I think we might be too fast here. If the delay after the comparator takes exactly one 650x CPU cycle (not sure if that's the case) we are always a bit faster, then we are slightly too fast. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 24 minutes ago, Thomas Jentzsch said: I think we might be too fast here. If the delay after the comparator takes exactly one 650x CPU cycle (not sure if that's the case) we are always a bit faster, then we are slightly too fast. it is after the next cycle (address change) that the bank is being switched: https://github.com/Al-Nafuur/United-Carts-of-Atari/blob/main/source/STM32firmware/PlusCart/Src/cartridge_emulation.c#L346 So the next (last) peek for the PCH in JSR should still be from the same bank. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 I added a log print to the CartPort driver everytime a R/W access to 0x1FE happens. Here is the log when tested Decathlon NTSC on the PlusCart: Spoiler poke 0x1FE 13 peek 0x1FE 13 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 53 poke 0x1FE 78 poke 0x1FE 205 poke 0x1FE 13 peek 0x1FE 13 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 poke 0x1FE 78 poke 0x1FE 205 poke 0x1FE 13 peek 0x1FE 13 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 127 poke 0x1FE 13 poke 0x1FE 78 poke 0x1FE 205 poke 0x1FE 13 poke 0x1FE 78 poke 0x1FE 205 poke 0x1FE 13 peek 0x1FE 13 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 poke 0x1FE 78 poke 0x1FE 205 poke 0x1FE 13 peek 0x1FE 13 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 252 poke 0x1FE 13 peek 0x1FE 13 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 peek 0x1FE 104 poke 0x1FE 136 peek 0x1FE 136 poke 0x1FE 105 peek 0x1FE 105 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 220 peek 0x1FE 220 poke 0x1FE 244 peek 0x1FE 244 poke 0x1FE 5 peek 0x1FE 5 poke 0x1FE 65 peek 0x1FE 65 poke 0x1FE 68 peek 0x1FE 68 poke 0x1FE 118 peek 0x1FE 118 poke 0x1FE 23 peek 0x1FE 23 poke 0x1FE 26 peek 0x1FE 26 poke 0x1FE 40 peek 0x1FE 40 poke 0x1FE 104 It seems that the bankswitching mostly happens, but sometimes the RTS doesn't seem to happen. e.g the first poke with the value 118 has no peek (RTS) in the log. I tested the NTSC bin file with Stella and trapped $1FE there it can be seen that the RTS happens and there should have been a peek for the value too! Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 (edited) Good catch. 👍 So RTS is the culprit. (see below!) Let's compare: # address R/W description --- ------- --- ----------------------------------------------- 1 PC R fetch opcode, increment PC 2 PC R read next instruction byte (and throw it away) 3 $0100,S R increment S 4 $0100,S R pull PCL from stack, increment S 5 $0100,S R pull PCH from stack 6 PC R increment PC // RTS case 0x60: { peek(PC, DISASM_NONE); // #2 peek(0x0100 + SP++, DISASM_NONE); // #3 PC = peek(0x0100 + SP++, DISASM_DATA); // #4, 0x1FE access here PC |= (static_cast<uInt16>(peek(0x0100 + SP, DISASM_DATA)) << 8); // #5 peek(PC++, DISASM_NONE); // #6, AFTER bank got switched? Anyway, should make no difference } Looks OK to me. Are peeks and pokes handled any different in your CartPort code? Edited November 6, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 (edited) Nope, JSR is the culprit. I stepped through the code and found that a missing bankswitch following JSR results into 105 next. Let's compare these: # address R/W description --- ------- --- ------------------------------------------------- 1 PC R fetch opcode, increment PC 2 PC R fetch low address byte, increment PC 3 $0100,S R internal operation (predecrement S?) 4 $0100,S W push PCH on stack, decrement S 5 $0100,S W push PCL on stack, decrement S 6 PC R copy low address byte to PCL, fetch high address byte to PCH // JSR case 0x20: { const uInt8 low = peek(PC++, DISASM_CODE); // #2 peek(0x0100 + SP, DISASM_NONE); // #3 poke(0x0100 + SP--, PC >> 8, DISASM_WRITE); // #4 poke(0x0100 + SP--, PC & 0xff, DISASM_WRITE); // #5, 0x1FE access PC = (low | (static_cast<uInt16>(peek(PC, DISASM_CODE)) << 8)); // #6 } BUT is it a missing bankswitch or something else? What if the bankswitch happens too early, so #6 is reading from the other bank? Or if it happens too late and the next opcode is still from the current bank? And how can we find out? @Al_Nafuur Can you add an extra delay to pokes at 0x1FE and test if that helps? Edited November 6, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 It really looks like the JSR didn't trigger the bank switching. I tried the bin file in Stella and switched the bank manually back to bank0 when the JSR with the value 118 for stack $1FE happened. And I got the same next values in the stack (log: 105,105,53,78,205,..) Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 43 minutes ago, Thomas Jentzsch said: @Al_Nafuur Can you add an extra delay to pokes at 0x1FE and test if that helps? We tried nearly every delay (faster and slower than the 2600), but no difference (PlusCart and cartridge). This is to be expected since the PlusCart is waiting for address bus changes and I think the Decathlon cartridge "1 cycle delay"-blackbox is also based on the bus changes. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 6, 2023 Share Posted November 6, 2023 17 minutes ago, Al_Nafuur said: It really looks like the JSR didn't trigger the bank switching. So, what could cause this? Maybe the address is not long enough on the bus for the comperator to trigger? Or maybe it triggers but then the cart is switching to the wrong bank? Can you log all peeks and pokes? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 6, 2023 Author Share Posted November 6, 2023 4 minutes ago, Thomas Jentzsch said: So, what could cause this? Maybe the address is not long enough on the bus for the comperator to trigger? Or maybe it triggers but then the cart is switching to the wrong bank? Can you log all peeks and pokes? It is the next cycles value on the data bus that determines which bank to switch to.. So we have to log the cycle after the poke to $1FE 1 Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts