Al_Nafuur

Yes , but we would have to keep this database updated and make tests with new devices (Pi6B+/- etc.) to know how many NOPs every model/variant needs, whereas CPU cycles will always be measured in hz: cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

@DirtyHairy has made a similar proposal, but using a cpu cycle counter instead of a nop loop. Both approaches are dependent on the CPU clock, but the cycle counter would be better, because we can compute the amount of cycles to wait if we have the clock speed of the current cpu. For the NOPs this is not that easy and we would have to test for different CPU/Pi versions.

Yes RAM/flash/eeprom sizes are different. The 25 is the smallest, but should be sufficient for our purpose.

Does anyone know what the 7800 is doing at startup to generate the checksum of the ROM? I would think it is omitting RAM and hotspots?

The second one is $02 (WSYNC), so this should be normal. The first one is $0284 (INTIM) but looks to me like a WSYNC too 🤷‍♂️

I ordered a few ATtiny25s, but I got ATtiny85 🤷‍♂️ Waiting for the programmer, it should arrive today.

Cool! Does it have a external (20Mhz) clock? AFAIK the internal one is only 8Mhz. The internal timers can be up-scaled to 8x clock (64Mhz). Which would be fine, but the internal clock seems to have a precision of +/-10% so the up-scaled timers will be not very precise!

Yes banked cartridges would have multiple md5sums depending which bank was active during start up, but it would be a finite amount of md5sums per cartridge.

It has to use peek from the driver, otherwise he would have only the data from the bin file. you can check it by starting the emulation directly to the debug window by adding the "-debug" switch to the command line. Even though Stella hasn't even emulated anything you can see the whole data in the debugger.

That was the idea anyways.

Dumping the PlusCart means dumping half the internet 🤣 But currently the debugger is doing a scan of what he thinks is the "first bank" anyway. So maybe the md5sum of this scan is enough to distinguish the cartridges? The 7800 is doing a "checksum" read of the cartridge at startup to determine if it is a legit 7800 cartridge. Most 2600 cartridges should be OK with this startup, so maybe we could do the same and use the generated checksum?

I think the sequence can be much shorter. But to know it we have to write a Script to test for the shortest sequence to distinguish all known ROMs.

I like that idea, but what if the first 2000 instructions depend on user input/settings (console switches!)

Maybe the users want to switch the TV format? Before inserting a cart and ideally even during the emulation without restart. the md5sum is from the bin file not from the ROM data.

Yes with multiple CartridgePort.bin files you can easily switch your console between all TV formats. I think the last state is stored for the bin file, so if you switch to PAL50 during the emulation of a "CartridgPort.bin" file without a TV format in the name it is PAL50 at the next startup. I think this is only run once per bin file (the real bin file, not the ROM data).

If we want to offer the user to also run "normal" bin files from an external storage like a SD-Card or USB storage, then we need the file selection anyway. I thought of using the file as a configuration for the hardware (CPU, GPIOs etc. 🤷‍♂️). However, I have not yet thought of anything we really should configure there. For the setting of the TV format for example, one must insert only in the file name "NTSC" or "PAL50". On the other hand we could also remove all other bankings and the file selector from Stella and only start/stop the emulation of the cartridge port via a switch. What are your suggestions on this?

I am not sure if it can, but i can't imagine how. You can test with a F8 cart and set a breakpoint before the switch and then step thru in the debugger.. Yes, but there are ways to make them shorter or maybe even prevent them for this thread/CPU

100us looks like the OS scheduler.. But the emulation shouldn't crash, or did it?

CartridgePort.bin For the detection..

I don't think we should pursue the NOP delay solution any further! A reliable internal or external timer will be a game changer for the write cycles (this includes all RIOT/TIA peeks!) Not me Yes, especially the standard ROM emulation is full of switches for bankings, SC-RAM and other hotspots (PlusROM, exit function..). But I don't think we should aim for a cycle length that is much shorter than the 6502 cycle. Other cartridges and bankings might be affected too. (Harmony, melody, DPC+, CDFJ, CDFJ+, and future bankings that rely on the cycle length of the 6502) I suspect the startup memory errors are because the dummy bin file is much smaller than 4K and maybe the debugger tries to access some of it..

Are you using 64bit or 32bit PiOS ?

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.

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.

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