Al_Nafuur

I can't get the CartPort to run for more than a few seconds. No matter what timer method I use, Stella freezes and I have to kill the process manually with "kill -9". ROMs loaded from the SD-Card also freeze Stella after about a minute. I haven't changed the cabling, but maybe I should check/switch my power supply. 👍 Good Idea. I will check here too.

great! But 700 is not real time even on the Pi4, or is it? I suspect my hardware (Pi3B+) is defect. It crashes even when emulating a ROM from the SD-card. Very rarely the desktop crashes too. I tried a fresh install of 32bit PiOS on a new SD-card, but Stella is still not working. I have ordered a new Pi4 (because they are really cheaper than 3B+). It arrived today, but I am still waiting for my mirco-HDMI cable.

I would buy a MovieCart too, or offer a PlusCart for exchange.

👍 Awesome. AFAIK it will not improve (much) the emulation performance, it is to prevent or reduce the interrupts from the scheduler, the OS and IRQs. 👍 The emulation is continued, because the write cycle is returning right after it has set the address/data bus and started the timer. Waiting for the end of the cycle is done before the next peek/poke. Sorry I don't know more, but I am afraid I will have to look into it

Even at 700 a simple 4K ROM has occasional glitches at my system. My tests showed that most reads are stable with 250, but a few need much more. It looks like sometimes the loop is done much faster by the CPU (cached?). 🤔 Maybe not only the "nop"s need to be volatile, but also the whole function (thread?).🤷‍♂️ The idea is to use a single CPU without interference from the OS scheduler. So our cycle timer thread is using cpu2, RTstella is using the last cpu (cpu3) and the OS uses the rest (cpu0, cpu1) To isolate the cpus from the OS scheduler, you need to add them to "/boot/cmdline.txt": isolcpus=domain,managed_irq,2,3 The performance governor only sets the cpu frequency for all cpus.

Did it run stable and real time on the PlusCart at 400? Yes similar, but it should be real time earlier (with a higher delay), because now Stella emulation is "included" in the write cycle delays.

Just pushed a fix which changed the CPU for the cycle timer thread. Now the emulation works, but again I have trouble getting a stable emulation on my Pi 3.

I have pushed my WIP code for the threaded timer. It is on the branch "feature/cartridgeportThread" and currently works only if Stella is started with "-debug" to the debugger window. Switching to the emulation window freezes the Stella window.

Yes, with the shared memory I also switch to threads. Maybe we don't need a atomic counter, a (atomic) flag in shared memory should be sufficient. 🤔

They both have read/write access to the GPIO pin, but they shouldn't do same kind of access at the same time. While one is writing the other one is only reading, but maybe this is "disturbance" enough? But it occurred to me that instead of a GPIO pin the two processes should use shared memory? I tried some nmap and shmget examples, but I'll have to do further testing tomorrow.

spontaneity needs to be carefully considered!

And when exactly will it be! 🤷‍♂️

That sounds like an interesting solution. We might add one more CPU to isolcpus for this process. I did some tests on this. And it is possible to use a GPIO to communicate between to processes. First I added "isolcpus=domain,managed_irq,2,3" to "/boot/cmdline.txt" to isolate CPU 2 and 3 Then on the terminal: sudo echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor sudo echo -1 > /proc/sys/kernel/sched_rt_runtime_us CycleManager.c (compile: "gcc c++ -Wall -O2 CycleManager.c -o CycleManager"): start with "sudo nice -n -20 ./CycleManger" Here is the test routine (same compiler flags and start as CycleManager): But no matter what delay I choose in Cycle Manger the ROM reading fails mostly after 10 bytes or less

Yes. 🤔 That sounds like an interesting solution. We might add one more CPU to isolcpus for this process.

The ATtiny should work with 2.7v, but unfortunately not at 20Mhz. I thought 3.3v would be enough, but it looks like they need 4.5v above 10Mhz:

I have finally managed to setup my "development environment" for the ATtiny: I had no Arduino so I used a WeMos D1 mini clone as ISP (changes to the ArduinoISP script) For coding/uploading I use the Arduino IDE. The script is C code, for the delay I used ASM: The "digitalWrite" function is already replaced with ASM. The "digitalRead" still has to be replaced by ASM. Also I am not sure if "OSCCAL = 181;PLLCSR = 0<<PCKE;" is enough to set the CPU clock to ~20Mhz. Testing on the flash bread board with a LED (and longer delay) at the 3.3V of the WeMos worked fine. Testing on the Pi doesn't worked so far. I have to check the wiring, the voltage and my Pi test code.

[Deleted]

No. Only the write cycle can return before the end of the cycle and the driver then waits before the next call for the end of the cycle (If we find a sufficient Pi CPU timer or cycle counter to use). The current version that @Kroko and @MarcoJ are working with uses a fixed NOP delay loop that is not taking into account the time consumed by others.

http://www.technoblogy.com/show?1ZIY

Yesterday I have compiled the module for the 32bit kernel here: https://matthewarcus.wordpress.com/2018/01/27/using-the-cycle-counter-registers-on-the-raspberry-pi-3/ But unfortunately it takes 10,000 "cycles" for a stable read of my test cartridge (combat) for hours. 10K cycles would mean ~0.07ns per cycle and a clock speed of ~14Ghz which can't be true. So there is still something wrong in our setup or the counter has occasional "jumps" or glitches that we haven't "turned off" yet?

No thanks, I prefer to ignore the Garfini, everything else is only secondarily ignored by me.

As a non-native English speaker, my question was not precise enough. And I also omitted to give an accurate description of my idea. My idea was not to emulate the 7800 or to recognize 7800 cartridges. My idea was that the 2600 cartridges in the 7800 "survive" the BIOS scan, and that we can do something similar to calculate a signature for the 2600 cartridges. In the meantime I realized that the 7800 BIOS probably only cares about 7800 hotspots and RAM during its scan and not about 2600 hotspots, banking or RAM, since these cartridges won't provide a valid signature for it anyway. This means we will have to come up with an own "scanning" for the 2600 cartridges. Your contribution is most welcome! And the technical part of the discussion helped me come to the above conclusion.

My answer was absolutely not meant to be dismissive. And your contribution is most welcome!

I don't think so, otherwise it would be really easy to make a 7800 cartridge for the competitors, just by copying these 120bytes to its own ROM. The idea of Atari BIT was to prevent others from making cartridges for the 7800. Yes, but 7800 cartridges don't fit in our cartridge connector anyway. So we will never see one with our current setup. Maybe my question or my intention was not precise enough.

The signature is not that relevant for our purpose. Is the BIOS scanning the whole range ($4000 - $FFFF) to generate the signature?