MarcoJ

I think it has to do with timing of the access cycles. If I vary the nop counter, Decathlon lasts slightly longer or shorter without crashing. It appears that the results are repeatable, though this is not conclusive. The best I found so far is g=580, and it ran for 8 seconds before it crashed. With g=650, it crashed much quicker, within 3 seconds.

ah. it's to do with the genesis controller, which I happen to use in all my consoles. That makes sense. Therefore, there's no adverse bug when being used in the RTStella build.

Wasn't for me. Not sure about others. I can get it working fine on my Atari 7800 and 2600 JR consoles.

The Zelda 3E+ game runs but goes into the menu continuously (via PlusCart). IMG_7132_x264.mp4

My 3E+ RPG demo works OK (via PlusCart). Worked OK on the nop delay system too. The scheme's writes to the unused TIA addresses are supported fine with the CartridgePort driver. 16CHAR_NTSC_20210603.bin

https://www.intel.com/content/www/us/en/products/sku/210264/max-ii-epm240-cpld/specifications.html Something like this is cheap and cheerful. Commonly available for about $10. Could attach this to the Atari 2600's bus and do all the I/O tasks. Can program it with a $10 usb blaster lead. With the 3 extra GPIO pins needed, interfacing can be simple. It over-engineered for the job, but that gives it potential for future expansion. I wonder if it could also become a TIA and a 6532 chip too, who knows.

Nice one. Should be hopefully easier to maintain it now. I can get Decathlon's screen to show for an instant if running through PlusCart, but nothing for the original cart. In other news, I've had the Desire demo running for about 5 days on my rig. Still stable.

Yes they are old hat. I think it could work, though it would be operating more like a GAL or CPLD, just a logic controller. Perhaps a programmable logic device would suffice better. Depends also if the full 6532 / RIOT function is needed including the zeropage ram, or just input interfacing. Something like this could work for the former ,just input interfacing. I like this approach more than bitbanging I/O expanders or big clusters of logic chips, it's more harmonious to the 2600's original style of interfacing. https://www.microchip.com/en-us/product/atf2500c

Looks like only 3 outputs needed from the PI to support both the RIOT and TIA . 6507 R/W pin (GPIO output, direct to chip(s)). Read write strobe. 6507 O (GPIO output, direct to chip(s)). Emulated clock signal. 6507 O2 (GPIO output, direct to chip(s)). Emulated clock signal. The rest of chip select lines are actually address pins, so we get them for free. The RDY signal is probably not needed - it is used to stop the microprocessor executing for STA WSTNC - that function is done internally between the emulated 6507 and emulated TIA. The RST signal is only for reset purposes, not connected to either TIA or RIOT. Not needed.

That is thinking outside the box. (pun intended) That would also save on poking the emulated RIOT chip. As long as Stella is disciplined with its approach on emulating the RIOT chip, it should work. It's an optional accessory too, not everyone has fit a RIOT chip. I have bought them too from China on Ehay before so they are out there. Stella might lose the ability to manage RIOT RAM in house though. Could also try make a substitute TIA chip interface for the specific inputs address range that related to paddle controllers, and let the emulated TIA do the rest of the address range. Probably just need a few GPIO read/write,chip select lines to complete the interface. And for users who want the minimal cartridgeport interface, there is that too.

Looks like Pine make compute modules too. Much smaller than the A64 https://pine64.com/product/soquartz-2gb-compute-module-w/ Supposedly 100 pin expansion

https://wiki.pine64.org/wiki/PINE_A64-LTS - Quad Core - 42 IO pins - $39

There is also the Dual core Beaglebone AI. It has the same form factor. https://www.beagleboard.org/boards/beaglebone-ai

Agreed, expandability is quite poor. The beaglebone black seems to have plentiful I/O and can potentially signal at 2.9MHz. It's quad core 1GHz. https://codeandlife.com/2016/04/18/beaglebone-black-gpio-benchmark/ However, I do feel optimistic the pi project could be completed with just the Cartridgeport being stable. The codebase could be shared between projects too.

Oh wow, is that how they work. Apologies, I haven't used them before. In that case, a replication of the levels, thresholds, resistances and capacitances of the TIA circuit should be all that's needed. The Vblank handle in the TIA emulation would need its own dedicated driver to control the inputs, and reset them when in read mode. I recall the Quadtari using this same system to switch which controller is being read. The minutia of this interfacing does sound like fun to do. Although at this time I'm more inclined to focus on being able to support the full 6507 cycle length and sustaining real time emulation. To start a thread that updates the emulation whilst gathering/actioning the next CPU instruction might need a frozen set of state variables while this is occurring. Or not, possibly, since on a real 2600 the TIA is updating in real time alongside the CPU in parallel. Have you had further thoughts on how this will be possible?

Happy Halloween

They are some kind of sensing pin rather than digital . For the purposes of us, it would need to be an analog to digital converter. I guess it depends how far one wants to go. Being able to facilitate i/o to an external plugin device is the most important, whereas reset/select etc can be done with a keyboard in USB.

Yes, there's quite a few, probably a 16 bit I/O expander could do it. Some bits would need to be able to output too with the DDRD register. The 4 paddle inputs are analog to digital type too, haven't looked if the GPIO can do that.

Can the Pi4 write that many times within a 6502 cycle? I.e. could it actually bit bang the IO expander at 26MHz, roughly 26 times per 6502 cycle?

Looks like they only make them for customers who used the older Compute Module 3. Both look difficult and expensive to obtain. It's a shame really, all that lovely GPIO. With a common cart connector chosen, it should be quite simple to produce and design. It would optimise the lead lengths. The PI does have some mounting holes for standoffs which could help support the cart during insertion and removal from the connector. I see. Yes, they only have 28 GPIOs. Odd choice, with those micro connectors being able to support dense arrays of I/O. This would probably be a better choice for the basic project if it was PCB based, as it's cheaper and smaller. The standard pi4 is more commonly available

Hey, excellent. Have you noticed if the emulation is lasting longer without glitches as compared to your Pi3 setup? I am guessing you're using the same breadboard setup. I have tried this out, I could only ever get it working for a few hundred milliseconds on PlusCart. A real cart didn't work. How long did it run on your rig? I looked into this last month. The I/O expander chips run at max 10Mhz clock, when the bit bang is executed it would be sub 1 MHz, our target to work. Also, the SPI and I2C ports are not available as the cartridge bus uses parts of them. Hmm, this is a good idea! It should work well to bit bang the ports in parallel, perfectly in sync with the execution. Such a design would need at the very least a breakout board of some type. Such as this: https://www.raspberrypi.com/products/compute-module-io-board-v3/ This would have enough I/O to interface to bidirectional joystick ports. This does give some hope to extend and expand the project. Also, it gives the hobbyist options to build the basic cartport driver or the full emulated ports. In other news, I've had the "Back to the future" demo rom on Harmony I posted before running for about a week without crashing. The CartridgePort driver is very stable. OK, Are you hoping to have have a direct cart connector to your PCB, or wires? If the latter, this design could be used:

Haha, love this analogy. It really is, and it's mind boggling sometimes. But when it works out, the feels are strong! It's also a bit of this:

Better to learn assembly for 8 bit MCUs. You get the best speed and flexibility, and you're talking directly to the CPU.