There may be a way to slightly speed up peek/poke access in the System class. What kind of budget do we have here? EDIT: Also, the debugger causes some runtime slowdowns. If you relax the requirement for the debugger (which admittedly, is giving up a lot), then the emulation can run faster.

Thanks! Do all SC carts you have require the same amount of NOP delay? It seems that, while the original carts are quite fast (~1/3..1/2 of 6507 CPU clock), we need a delay which is quite close to 6507 CPU speed for the PlusCart. Thus leaving us only little headroom for other parts of emulation. Questions: Has anyone tried to eliminate the ghost peeks like I suggested above? This would increase our headroom. Could the PlusCart be improved to work with a shorter delay? What could cause the startup problems? I had the idea that the game might start in the wrong bank, but the game's code is prepared for this.

Testing - Desert Falcon (16k SC-RAM game), Cart Vs PlusCart, determining stability of game with changes to nop delay. Running on a pi 4 with RTStella, with performance governor and Linux scheduler disabled. 1. PAL Desert Falcon Cartridge nop Delay - 100 Result: Game loads up, but gitches in-game and returns to main menu occasionally. nop Delay - 200,300,400,500 Result: Game is stable and runs at real time, no glitches noticed. nop Delay - 600 (and up) Result: Game is stable but has slowdown from the nop delay being too large 2. Desert Falcon (PAL) run from PlusCart nop Delay - 100,200,300 Result: Could not get game to load nop Delay - 400 Result: Game loads, but glitches similarly to a real cart at nop delay of 100 nop Delay - 500 Result: Game loads and appears stable, runs at real time. nop Delay - 600 Result: Game loads and appears to be stable, but slows down from nop delay being too long Overall Notes - In all cases, RTStella needed to be started up to 5 times before successfully starting the cart. If it failed, it would go straight into the debugger. This occurred on all nop settings and when using on PlusCart/Real cartridge. - When RTStella was restarted the cart was left powered in all cases. - The nop delays affected the game's speed the same whether a real cart or the PlusCart was used. The difference is whether the game could function at all (yes or no) at the given nop delay for the given cart type. - At least on the pi4, it seems that somewhere around 500 nop delay is a sweet spot. This is where the game runs at real time, and has the highest chance of running without glitches whether on a flash cart or on a real cart. 600 is too high, slows down the game. 200 is stable for real carts, but the PlusCart could not work at this delay, even if the game was already bootstrapped at a higher nop delay and subsequently set to a lower nop delay for testing(without unpowering the cart). The PlusCart needed around 500 to be stable with this game. Videos 1. 400 nop delay (tested on Real cart). nop 400_x264.mp4 2. 100 nop delay (tested on Real cart) nop 100_x264.mp4 3. 500 nop delay (tested on PlusCart) nop 500 pluscart.mp4 4. 700 nop delay (tested on PlusCart, although same result on real cart). 700 nop_x264.mp4

OK, thanks for the info.

+ Crystal Castles, and running at nop delay of 200.

Are you using 64bit or 32bit PiOS ?

I suppose it can't hurt Those 8 bits would be changed soon after from the read operation from the cart?

The 3 bits only affected the data bus when we were in "write" mode. In read mode the 8 data bits GPIOs shouldn't care if we are trying to change them. 🤔 But maybe we should bitmask here aswell: https://github.com/Al-Nafuur/stella/blob/feature/cartridgeport/src/emucore/CartPort.cxx#L165C5-L165C14

Cartridges are doing strange things (like banking) with the data they spot outside of their "originally planned" address area.

OK, I'm getting somewhere now. My SC-RAM carts are working now with RTStella. No changes to code. Embarrassing as it is, the angle the cartridge was inserted at in my rig was not optimal and caused the carts to crash at startup. Strangely, it was not affectinting ROM carts. Already have Desert Falcon and Digdug working with a delay of 400. Results will come up soon.

The other thing that is different is the signalling voltages. Carts are almost exclusively expecting/giving 5V signals at the cart, whereas flash devices such as Uno and Plus are 3.3V. I'm not sure about Melody or Harmony if they are 3.3V or 5V. 3.3V and 5V signalling are meant to be compatible. I don't see why this factor should cause a problem. Especially given that 5 volt to 3.3v conversion is happening flawlessly on cart reads.

As far as I know this is fixed. Previously 16 bit addresses being cobbled into the GPIO bit bang operation were nobbling 3 data bus bits. Masking address to 12 bits fixed it. Typically happened on carts using "$F000" instead of "$1000" as its reset vector, or carts using other look up ROM table addresses and using them onto the address bus. The former crashed on startup, the latter had odd bugs (such as Aardvark).

@Al_Nafuur Is the Aardvark video that you posted on Sept 19th, typical of what is happening currently, or have things moved on?

Yes, but why does that trigger a wait? Or do we have to care for that data on the bus? I mean, the addresses are outside any cart's RAM address range, so the data will get lost anyway. Only the address is relevant, no?

For a cartridge connected to a 2600 there are no read and writes, just addresses and data appearing "magically" on the bus. Who has put them there is totally unknown to the cartridge.

My thoughts exactly. I am not sure what happens on a read from a write location on a real VCS, either. No one is driving the bus, and I would assume that most of the time the bus holds the last value. I guess the driver chip behaves differently than a real 6502 bus. Electronics is not my strong side, but would an array of pulldowns help? That would put the bus in a well-defined state if noone is driving it.

That't the one that I saw initially and that I couldn't find yesterday evening. It gives the corresponding instructions for arm32. However, there is a small flaw: the function on the post only reads the lower 32bit word. The counter is 64 bit wide, and you can use MRRC to transfer both words.

Why would a read from TIA/RIOT become a write to the cartridge?

🤔 https://matthewarcus.wordpress.com/2018/01/27/using-the-cycle-counter-registers-on-the-raspberry-pi-3/

The driver writes peeks from TIA/RIOT and all pokes to TIA/RIOT on the bus (address & data).

It just occurred to me that some bankswitching schemes write to the TIA space to change banks, such as 3E+. @Al_Nafuur I’m not in front of the code but does the driver currently write TIA requests onto the bus, or does it just write them into Stella’s internal TIA?

This would be my second guess to why writes sometimes get corrupted. I tried rewriting the Poke function to include the nop delay inline with the write function, rather than waiting for the next time it’s called. It seemed to make no difference. If there is unstable data on the cart side of the driver IC this could explain why data gets corrupted. I wonder if some light termination on the cart bus side could help or shortening of data bus wiring.

This is a fascinating discussion going on here - well done everyone for your contributions 👌

If it is a read/write to the TIA or RIOT it is on the cartridge port a "write" to the cartridge too. The "lastAccessWasWrite" flag is only to exit early and let Stella do its thing and then check at the next peek/poke if we may have to wait for the cart to read/peek the data (e.g. for banking). That's why a timer is better than a delay, because with a time we would only wait the remaining time before the next cycle.

What's the oscillating mess on the purple line at the beginning of the write cycle on the cart side of the SN74?? Seems it takes almost 0.5us until the data bus is stable after DIR has changed.