Al_Nafuur

🤔 I think the difference between the firmware hotspots writes and the SC-RAM writes is that the writes in the games are most likely indexed writes..

Yes, all multicarts (PlusCart, Krokodile, Harmony) show exactly the same issue with SC-RAM writes. It looks like the lowest 3 bits on a write are always set. What puzzles me is that the menu on the PlusCart and the Harmony are obviously working correctly, but the PlusCart is relying on hotspots writes for the entries selected, and all seems fine here. Also the PlusROMs I have tested so far seem to send (and write) the correct values..

I just changed the howto for rtstella: to make it really run faster with the rtstella build you need to change some things manually in the CartPort.cxx driver. I'll currently adding the RTSTELLA switch to the driver, but it is not yet pushed to the fork..

Can you test Aardvark Demo (F4SC) on the Harmony? I would like to know if it has the same issue with SC-RAM writes like the PlusCart and the Krokodile Cart. Aardvark (NTSC) (2019) (Oscar Toledo G., Thomas Jentzsch, Nathan Strum).bin

Yes. I would suggest each development team member chooses one or two favorites for the poll.

sorry you need "sudo" before the command: sudo echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor This is quite similar to what real SC-RAM does and different to the approach of the UnoCart/PlusCart. Can you check Aardvark Demo with the Krokodile Cartridge? Aardvark (NTSC) (2019) (Oscar Toledo G., Thomas Jentzsch, Nathan Strum).bin

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor How does the Krokodile Cartridge reads the writes from the 6502? Is it waiting until the address changes again and then take the last value on the data bus like the UnoCart/PlusCart? The much much longer ones are the ones that are "interrupted" by the OS scheduler.

You can open the Stella debugger and step through the code. The cycle timing will be too long, but you still can see the chronology of the things happening. If you want to capture something in "real" emulation speed, you can hit "Run" in the debugger when you are directly before the command you want to capture.

Awesome👍 The writing cycle looks somewhat like I expected. Only the timing with 2500 - 4000ns for the cycles is more than I thought (I expected 1000 - 2000ns). Are you running the Pi in performance mode? Is Defender II on a real cartridge? Or are you using a multicart? Is the game working (apart from the fact that it runs too slow)?

Yes, I am very interested in writes to the Zeropage and SC-RAM. From a real cartridge with SC-RAM would be cool, also writes to multicarts like the Harmony or the UnoCart/PlusCart would be nice to see.

@Thomas Jentzsch, @MarcoJ, @DirtyHairy and I had a long PM conversation for the last two weeks about making Stella run with our hardware and what changes might be needed to the hardware for a "perfect" emulation of a 2600. Since the project has been released now and maybe other might have valuable inputs to this discussion we have decided to continue our discussion here in public. Maybe @Albert can move our PM conversation to this thread?

Nice Setup!👍 I'm almost a little envious of the 34 channel logic analyzer. Something like that can be quite useful when debugging. Does it have 100Mhz resolution on all channels simultaneously? Can you send some screenshots oft the analyzer captures?

Thanks! Basically I am focusing on letting the read/write cycles (transitions) on the bus look like a real 2600 for the cartridges, if we can do this correctly all bankswitchings inside the cartridges will just work. We have tested different timers and techniques to get the delay inside the CartPort driver as close as possible to a 6502 running at ~1.19Mhz. But to me it looks like that at about 1/2 the speed of the 6502 we don't have any more speed gains in Stella increasing the driver to "full" speed. I have not seen any big differences running on an Pi3B at 1200Mhz or an Pi3B+ at 1400Mhz and I think a Pi4 at 1500Mhz will also make no difference. @DirtyHairy already mentioned (here) that Stella's main loop is not optimized for what we are trying to do, and he is currently working on a rework of Stella's main loop and threaded model.

Yes a 3B+ would be best at the moment. But there are a few people starting to test on Pi 4 soon..

Thanks, the fixed link is: https://code.visualstudio.com/docs/setup/raspberry-pi

The real cartridges with RAM are doing the writes (or read from their point of view) different than the PlusCart/UnoCart are doing. The cartridges are waiting (or need) ~500ns before they read the value on the data bus. The 6502 is setting the data ~415ns after he changed the address and holds it for about ~350ns. The PlusCart/UnoCart are constantly reading the data bus until the address bus changes again and then take the last data read before the address change. I am not sure but the real cartridges might have a much better chance to work with our setup. The PlusCart/UnoCart approach works fine with a real 6502, but maybe we should use something like nanosleep or cpu tick counts on the PlusCart firmware to wait ~500ns and read the data bus earlier. https://stackoverflow.com/questions/13379220/generating-nanosecond-delay-in-c-on-stm32

It seems like the first 3 bits are already pulled high when the cart reads the value on the databus. There is a similar pattern on the Video Life (CV banking) game. So we might need a few ns more delay before we switch the data bus back to read, or we have an issue with setting these three GPIO pins.

bankswitching always happens inside the cartridge, here the PlusCart.

Tested F4SC Aardvark Demo on the PlusCart:

Tested F4SC Aardvark Demo on the PlusCart

The PlusCart (and AFAIK the UnoCart) cannot be used headless, only auto start is possible with the PlusCart UCA firmware. Technically headless can be done, there was just no need until now.

As a pun to RealTime: RetroTream26 this will also make the name very unique for web searches!

🤔 RetroDream26

It is too early for production boards, but for testing they will be of great use. Testing on a breadboard is a real pain, you always have to take care for the cables and some cartridges tear out the edge connector when you remove them.

Also (re)tested on the PlusCart with the new build: F8SC: Atari Defender OK F6SC: Atari Dig Dug not working CV: CommaVid Video Life running but half of the RAM is not written correctly? F0: DynaCom Mega Boy OK E0: Parker Bros Super Cobra OK E7: M-Network Burgertime not working