Al_Nafuur

I switched to the 64bit PiOS and tried a clean build. But the build process always gets stucked when building the AboutDialog. I tried building as normal pi user and as root. The Pi gets very unresponsive and is unusable at this point. I have to power it off/on to get it working again. Has anyone build rtstella on the 64bit PiOS so far?

Bus stuffing is only happening on 6502 writes, correct? how important is the (write) cycle length for bus stuffing? At what point in the cycle is the cartridge stuffing the bus, and how does the cart detects this moment (timer or changes on the data bus)? How long is the cart stuffing the bus (till the next address bus changes or timer)? Yes I briefly thought about bus stuffing, but I didn't considered it relevant at this point of the project. This would basically be the route to go. But it will make every write outside the ROM area to a read from the cart, and the reads are affecting the emulation speed the most. Currently we are using 22 of the 32 Pi3 GPIOs, so there are enough left to double the data bus. But I thought of maybe using 5 GPIOs for the console switches. For the controller ports we would need 16 additional GPIOs which the Pi3 has not. The Pi4 CPU has 32 additional GPIO ports, but I don't know if there is an additional pin header for them on the board.

Sorry, I cleaned up the mess and the instructions. No need to rebase the rtstella branch.

I thought of an ATTiny25/.. too. They have a clock speed of 20Mhz, so the delay timer can be set in 50ns "accuracies". For the "cycle" length the RaspberryPi CPU cycle counter supposed by @DirtyHairy would be more accurate. But because of the OS scheduler we wouldn't be able to "shape" the cycles for write delays with the software driver alone. A external MCU would be more secure if shaping the write cycle becomes necessary.

merge conflicts? Do you have any local changes made? You might start a clean download/build in a new folder. I think it makes no sense to merge the two branches yet. @DirtyHairy

I think I first need the 64 bit Pi OS: t@raspberrypi:~/Dokumente $ git clone https://github.com/jerinjacobk/armv8_pmu_cycle_counter_el0 Klone nach 'armv8_pmu_cycle_counter_el0' ... remote: Enumerating objects: 54, done. remote: Counting objects: 100% (18/18), done. remote: Compressing objects: 100% (15/15), done. remote: Total 54 (delta 4), reused 12 (delta 3), pack-reused 36 Empfange Objekte: 100% (54/54), 23.36 KiB | 1.56 MiB/s, fertig. Löse Unterschiede auf: 100% (14/14), fertig. t@raspberrypi:~/Dokumente $ cd armv8_pmu_cycle_counter_el0/ t@raspberrypi:~/Dokumente/armv8_pmu_cycle_counter_el0 $ make make -C /lib/modules/6.1.21-v7+/build M=/home/t/Dokumente/armv8_pmu_cycle_counter_el0 modules make[1]: Verzeichnis „/usr/src/linux-headers-6.1.21-v7+“ wird betreten CC [M] /home/t/Dokumente/armv8_pmu_cycle_counter_el0/armv8_pmu_el0_cycle_counter.o /home/t/Dokumente/armv8_pmu_cycle_counter_el0/armv8_pmu_el0_cycle_counter.c:18:2: error: #error Module can only be compiled on ARM64 machines. 18 | #error Module can only be compiled on ARM64 machines. | ^~~~~ make[2]: *** [scripts/Makefile.build:250: /home/t/Dokumente/armv8_pmu_cycle_counter_el0/armv8_pmu_el0_cycle_counter.o] Fehler 1 make[1]: *** [Makefile:2012: /home/t/Dokumente/armv8_pmu_cycle_counter_el0] Fehler 2 make[1]: Verzeichnis „/usr/src/linux-headers-6.1.21-v7+“ wird verlassen make: *** [Makefile:7: all] Fehler 2 t@raspberrypi:~/Dokumente/armv8_pmu_cycle_counter_el0 $ uname -a Linux raspberrypi 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux

I mean too slow for a write cycle of 300 Pi4 NOPs

Are you still using a NOP delay counter of 300 on the Pi4? Maybe real SC-RAM is not fast enough?

Do you have any documentation or a code example on that?

👍 Yes, but they are mostly using the Melody board. AFAIK it has the same RAM emulation code and MCU as the Harmony, so if the ROMs have been tested on the Harmony I suspect they will work with Melody too. @vcsrocks has sent me two interesting prototype boards last year, which are implementing FxSC and Fx banking with EPROMs or EEPROMs. Unfortunately I can't find the FxSC one in my parts bin😠

Do you have any FxSC (SC-RAM) cartridges or any other cartridge with RAM. e.g. CommaVid "Video Life" (CV) or M-Network "Burgertime" (E7)

Tunnel Runner is CBS FA banking? I have tested working Omega Race (FA) on the PlusCart, but a real FA cartridge hasn't been tested yet:

Good idea! When the driver is in "powered off" mode Stella might show White Noise 🤣. Or just the boring file selector

Yes powering on the cartridge is another issue we have to solve (later). The cartridge port should only supply the 5V after a cartridge has been inserted, but it is a bad idea to always reboot the whole system (like the 2600), because there is a bit more to boot on the Pi. So we need some sort of switch or detection when a cartridge has been inserted.

The cartridge (even the multicarts like the PlusCart) should be powered on (long) before Stella and the driver! Starting the driver before powering on the cart will not work! Between Stella restarts you should power off/on the (multi)cartridge (just like a real 2600). Without the reboot the PlusCart starts with the game previously loaded.

nice! Does someone has a real Pitfall II cartridge to test? I would really like to know if it works..

rebase the feature/cartridgeport branch?

We are using GPIO 0-12 for the address and 13-20 for the data bus. When Stella wants to write (poke) a value to a address I had set the GPIOs like this: uInt32 gpio_value = (uInt32) address | (((uInt32)value)<<13 ); the correct way to do this is: uInt32 gpio_value = (uInt32) (address & 0x1fff) | (((uInt32)value)<<13 ); The cartridges with RAM or other hotspots. In the ROM code?

Not necessarily. If we manage to do all emulation stuff during tADS (30ns) of the 6502 and all the 6502 cycles that don't do bus access, we can do realtime without shortening the bus cycles.

The problem is that the NOP loop is just a delay not a real timer. For the write cycles this means we are currently adding this delay on top to the execution time before the next bus access. This also includes the read/write accesses to the RIOT/TIA where we set the bus to "inform" the cartridge about whats going on! With a real timer we would only wait the remaining time after Stella has done its thing between two bus accesses.

👍 yes, fixed

I changed the howto for rtstella: You will have to use "make clean" after the ./configure and build the whole thing again. ☕ As a Pi4 user you should take a look at line 281 of CartPort.cxx you most certainly will have to increase the delay counter "i" until all bankings of the PlusCart/Harmony are stable. We really need to find an other clock source for the delay: https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf I am testing the ARM clock mentioned in chapter 12 again today, but I can not get the free running counter (~4ns ticks) to run.

After fixing a bug in the drivers write cycle I have retested a few bankings with RAM on the PlusCart: F6SC: Atari Dig Dug OK CV: CommaVid Video Life OK E7: M-Network Burgertime OK FA: CBS Omega Race OK F4SC: Homebrew Aardvark Demo OK FE: Activision Decathlon Still crashes at startup AR: Starpath The Official Frogger Still crash after load screen I also tested 2 cartridges: Starpath SuperCharger Now crashes at startup Activision Decathlon Now crashes at startup

And they are only messing things up when one of these 3 bits is set (-> when ROM mirrors are used) this explains also why some hotspots worked. I tested Aardvark on the PlusCart and it worked. Fix has been pushed to the repo.

I think I found the SC-RAM bug (and it was a real stupid one!) The address given to poke is 16 bit! But we only have 13 address lines to the cartridge!