Kroko

The chip on the right is a Xilinx CPLD and most likely it realizes the bankswitching that is needed by the ROM that is stored on the flash chip. The free U2 footprint may be a placeholder for a RAM chip, in case extra RAM is needed.

I also like the idea of using MAX-II for RIOT/TIA. It is a better solution for any complex time critical logic. Of course also a bit harder to handle, development wise. The implementation of this "Transceiver with Lock" fills up 29 command of the 32 that are available per PIO. So first PIO is already full with only this little function. Also PIO is not super well documented. I had difficuties to connect the same GPIOs to two different PIOs ... so it may get ugly soon, when we need to do more complex things.

There has been a lot of discussion about this ... not only in this thread. This is what I found on RaspberryPi Forums: GPIO pins that aren't shared with the ADC can accept a maximum of 3.6v without IOVDD being powered. GPIO pins that aren't shared with the ADC and have IOVDD at 3.3v can accept a maximum of 5v ( not 5v tolerant as this typically means up to 5.5v) Remember during powerup in typical designs 3.3v usually comes up after a 5v rail so applying 5v to a GPIO will end up over stressing the RP2040 during powerup. If you exceed the one of the specifications the internals may not fail immediately, but over time if the silicon is stressed it may fail. Remember noise and overshoots can all add to stressing the silicon. I would recommend designing to the datasheet as this is what is what the parts are tested to. Or as someone else stated: everything is 5V tolerant for a while 🤣

I attached the code that I build and download to the Pico. What is necessary as input is the DIR line from the Pi 4B and also a new line that I called ADR_CHANGED. Maybe we can replace the dedicated ADR_CHANGED line by the LE for the address latches... However it needs to be set to "1" together with the address lines and LE (not before and not after, in the same command) Then it needs to be kept on "1" until the Pico had the time to detect it, I think I have it on "1" roughly 200ns now. Then it must go down to 0. Every address change needs to trigger one puls on the ADR_CHANGED line. Next rising edge of the ADR_CHANGED is also reseting the LOCK of the databus. This is how I connected the BUS: ; Pico GPIO16 = DIR (Input : from PI-4B) ; Pico GPIO17 = ADR_CHANGED (Input : from PI-4B) ; Pico GPIO18 = LOCK (Output: just for DEBUG to watch when the transceiver is LOCKED) ; Pico GPIO0-GPIO7 = DS (Databus connected to Stella ) (DIR=0: Output DIR=1: Input ) ; Pico GPIO8-GPIO15 = DC (Databus connected to Cartridge) (DIR=0: Input DIR=1: Output) It is important to note that I have resistors on all GPIO both (PI4B and also for Pico) for protection. The Pico is not 5V tolerant and it can also not be made 5V tolerant by resistors. But its probably giving me more time before the setup fails. In the final design we will need level shifters so no 5V is seen on Pico GPIO. This is how this looks like in the logic analyzer: I don't have a SuperCharger ... I also am still having trouble with extra RAM cartridges ... but I did not look into this lately. Something still does not work for these, because for example my copy of BoulderDash is unable to enter the game screen. Also I am having trouble with the Stella Emulator code. I only partly understand which place in the code corresponds to which time in the time slice. Need to look more into it to find out where the problem might be ... PicoLockableTransceiver.rar

Meanwhile I replaced the 245 Bus transceiver with a Raspberry Pi Pico and implemented the databus handling as PIO state machine. Freezing the data that the cartridge is sending some time after the address bus changed is enough to get the real decathlon cartridge running. So however we finally do it... with MAX-2 or Pi-Pico ... locking the bus is the only missing piece for decathlon to run: 2024-01-13.mp4

Its worth a try. Data is unlocked every time we set the address and locked by the uC 700ns after we started. When selecting this little controller, maybe it can also help with our "missing GPIO" problems ?

This one is really 100MHz: (I peeked address 0x0298 on an illegal instruction to trigger the error signal in the cartridge port to set the debug port from there) Decathlon_RealCart_Emulated_100MHz_ERROR4.CSV

These should be 2 good logs: (name is wrong this is 10Mhz) Decathlon_RealCart_Emulated_100MHz_ERROR3.CSV Decathlon_RealCart_Emulated_100MHz_ERROR2.CSV

Sorry this one is possibly wrong. I used the wrong trigger. I need an address that is never to be seen on the bus in normal operation, I used a wrong one ... WHat would be a save address that we never expect to appear on the address bus ?

this is a 100Mhz log from the illegal instruction back to whatever the logic analyzer is able to do: Decathlon_RealCart_Emulated_100KHz_ERROR.CSV

I think I found it: switch(IR) { // 6502 instruction emulation is generated by an M4 macro file #include "M6502.ins" default: FatalEmulationError::raise("invalid instruction"); } I will try to set a GPIO from here ...

@Thomas: It would help much if I could identify the point of code in stella shortly before this is happening: Can you help here ? I want to set a debug GPIO and monitor the bus 400us before this is happening.

This is the region around RTS @ $d04a: (Bank 1) Not sure if it will help much, but at least here we should see how the cartridge does a RTS. Unfortunately I think this specific RTS is working fine. it returns to Bank 0 Decathlon_RealCart_Emulated_100MHz.CSV

The trigger is difficult to choose. $1F0-$1FF ? But we would see all Stack hits, also the ones that work fine. So how do we find a good section of the code that we would like to see ? It would help me if you could identify some address that I can trigger on, so you see the behavior of the cart at or after that piece of code... I only see about 400us at 50 Mz or even less at 100 MHz ...

Are you sure ? maybe no "real" clocks but RC circuitry for delays connected to pins. To measure the time from a stabilized address and/or databus or some event and by that determine when they would like to read. I have no proof for that statement, but I think there are people who are conviced that these carts doit like that. But lets see...maybe this assumption is incorrect.