MarcoJ

Tonight i've been reading the Stella source. From where are the calls to the Cart class functions Peek and Poke originated from in general? I'm a bit lost. Trying to find the main loop. I see a main loop in OSystem.cxx and OSystemRTStella.cxx but am not sure where it translates to peeks and pokes.

I have also found this. Some more complex schemes are on the knife's edge of working. Especially during the beginning transition of the cycle, delaying the presentation of address can be fatal.

I thought this might be the case. Is it possible that Stella processes the TIA and RIOT emulation of the last read cycle it just successfully read whilst the next transfer is waiting from the Timer? Could the Stella emulation thread be forked at that point to leave the CartPort driver to spin waiting for the next Timer transition?

I had a think about this. PlusCart should have the fastest response time compared to real carts. But we found out that carts can be "overclocked" better (run with reduced read/write times to compensate for emulation time required by Stella) and that PlusCart typically needed 2x the nop delay to be stable. Apart from providing a regular cart driver, PlusCart also provides the support for PlusROM. The PlusROM code tries to make use of extra time left over in the read and write cycles to execute code to fulful the menutia of PlusROM functions. This is also the case with my ACE programs, it assumes a real Atari is allowing the complete hardware read and write cycle. If a read request happens before that, a crash or corruption occurs. With the NOP delay system, there is hardly time left for Stella's emulation, the CPU is busy with nop delays. It would be interesting to try running SC and E7 games with a driver in PlusCart that does not attempt to fulful the PlusROM functions and see how it performs. I expect it would rival that of the real carts.

This is my understanding of how the NOP delay system works, VS the External Timer system we are seeking to move towards:

I have just realised that by adding an external timer to Stella's read operation, this quite possibly triggers a redesign of the Stella's read/write cycle methodology. Normally, Stella's Peek function is an instantaneous operation. The function is called with an address argument and a data value is returned straight away. With the nop delay method in use currently, this form is still followed, except a delay is added inside the function. Now, given we want to take advantage of Stella processing concurrently while the Timer delay is operation, the Peek function almost needs two parts now. 1. Function to set up address and start timer for the peek. Stella then returns to do processing. 2. When Stella has done just under a cycle's worth of processing, enter another function to collect the data that has been peeked. @stephena@Thomas JentzschHow much work would it be to support this disjointed read operation? If bus stuffing is implemented, this same set, and collect methodology could be used collect a overriden value of data, and to then send it to the TIA etc.

Update on the hardware timer idea. - Have been able to compile AVR assembly programs on the pi4 into hex files. It uses a tool called "avra" to compile AVR assembly into HEX files. - Micronucleus connects to the ATTINY85 and adds the user program to the flash. - The user program so far is a flashing LED on the timer board. This is to be modified to instead match the 2600 cycle length. (The LED shows the Timer signal is logic LOW). LED test code. (This is not the final timer code, but a template to develop the timer code). The plan for the pi interface: GPIO22: Set as Output, this is the signal from the PI to start the Timer. On the Timer this if PB0, set as input. (ATTINY85 Pin 5) GPIO23: Set as Input, this is the Signal from the Timer that the read/write cycle is complete. On the Timer this is PB1, set as output (ATTINY85 Pin 6) Plan for Protocol: 1. Stella can trigger the timer to start by changing GPIO22 from HIGH to LOW. This is an interrupt on the ATTINY85 which restarts the timer, this will make GPIO23 go LOW. This is part of the Stella CartridgePort's normal bit bang operation to set address/data. Then, straight afterwards, GPIO22 is set back to be HIGH, to ready for the next time the timer needs to be started. 2. Stella then returns from the peek/poke operation and does some processing. It no longer executes the nop delay. 3. When it is time to enter the next peek/poke operation, Stella waits until GPIO23 is HIGH. When the Timer reaches the right timing it will transition from LOW to HIGH. If GPIO23 is still low, Stella waits. When it goes HIGH, Stella can then begin the bit bang operation to set address/data in Step 1. Uploading program to the ATTiny85 IMG_6859_x264_001.mp4

That is a much better method. I get 1800000 for my pi4.

@Al_Nafuur are you planning to write in AVR assembly or c? I'm starting with assembly. Looks like there's quite a few single clock instructions to form the delay. Seems like registerwise, there's PortB and DDRB (both 6 bits) for setting data direction.

It is possible to find the Pi in use by running: cat /proc/cpuinfo | grep Model It could be possible to have a database of board types to select an appropriate delay

https://s3.amazonaws.com/digistump-resources/files/97a1bb28_DigisparkSchematic.pdf This is the schematic of the Digispark with it's ATTINY85. The external crystal option is possible with pins 2 and 3. However, these pins are already used for the USB interface. Thus, it looks a bit much to mod to have the external crystal for this module. It would suit the bare DIP-8 packages though like what you have.

I see what you mean by the 8MHz thing. If our goal is to emulate a 6507 cycle, that gives us only a few instructions to implement this timer. Back to software solution for a second. How difficult would it be to have a separate CPU core in Stella that implements the nop delay only and then send CPU flags/semaphores when the timer is ready?

No, it would be currently using the internal one. Given the program on the chip is essentially doing nop delays, it's precision would only be a multiple of 1/20Mhz anyway. Perhaps 50 ns steps, or something like that. I'll look into it more tonight.

I could be wrong, but the difference is just the flash size?

The bootloader went on fine using the AVRDude utility and zadig windows driver utility. With the micronucleus inserted, linux on the pi detects it as a USB device. It is now primed to have Timer program changes through Linux. The routing of timer I/O lines are marked up in the photo below.

Does it use the GPIO peek/poke driver to do this? If so, I imagine that would be fine for heuristics like a normal rom.

Hmm, that's a shame. The scheduler is evil kneivel. I suppose polling is OK if Stella was able to do some useful work before making it to the Timer polling. The Timer chip would just enforce waiting "enough" time rather than the exact time.

I've started getting the ATTiny85 going. It's an 8 pin Microcontroller that we would use as a Timer to generate interrupts to the Raspberry pi pins, and also to possibly change the state of the 245 IO chip without needing the Pi. The chip can be set up with a bootloader to receive updates via a Linux USB commandline tool. The most popular bootloader is called "micronucleus", which is 2K overhead and allows 6K AVR hex files to be uploaded. It is possible to use an AVR programmer to flash the micronucleus, once it's on then the pi's USB can program new timer programs onto it. https://github.com/micronucleus/micronucleus I imagine our timer program would be tiny, but could be as flexible as needed. There are 4 available I/O pins on the ATTiny that could be used back and forth to the RTStella interface, 2 are used by USB (6 total). It could also be possible to not need USB connection once the timer program is mature (if we go through with a hardware interrupt timer). Interfacing interrupts on the Pi are used here: https://github.com/phil-lavin/raspberry-pi-gpio-interrupt @Al_Nafuur does the interrupt look feasible? I imagine, the way we would use the timer, is instead of using the pi nop delay in RTStella, to instead signal the Timer IC with a GPIO to start timing once the bit bang is set, and then allow Stella's emulation to process for a while. Once the Timer IC's read/write timing cycle is complete it will provide an edge triggered GPIO interrupt and Stella's emulation processing will yield to the GPIO driver where it will again change the state of the GPIO pins, and start timing again. This should improve performance of the CPU to allow Stella to process more and not need to waste time with nops. I imagine what will be tricky is how to stop and start stella's processing with the interrupt. The AVR ATTINyY85 board i'm using is called a DigiSpark: http://digistump.com/products/1 I'm planning to leave it permanently plugged into one of the Pi's USB ports for power and USB connectivity and have some wires proceed to the GPIO pins for the timer start and interrupt line.

Ah this will be handy. It is irritating having to set that manually currently, each time a different cart is used. Does this mean the heuristic scan is skipped using the cartridgeport?

@Kroko are you running this command too? echo -1 > /proc/sys/kernel/sched_rt_runtime_us this ironed out the 1 second periodic interruption for my setup. Although it breaks Stella’s debugger.

As good and reliable as it has been for carts, it probably sails too close to the edge of working for flash carts. Desert Falcon survived till the morning running with a 200 nop delay. It's stable. I'm guessing you're already looking into a software solution. My USBAsp programmer arrived, will lash up a USBTiny to my rig tonight. Does it need two timer channels, or just the one?

Have tested Crystal Castles, Off the Wall, Dig Dug and Desert Falcon and they all work at 200 nop delay. I will leave Desert Falcon overnight in its demo mode and see if it survives.

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

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

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