Community-Built Unnamed 1970's Video Game Console-Compatible System (WIP)

[Kroko]

1 hour ago, Kroko said:

Luckly most likely this has nothing to do with our bus timing ...

It had to do with my breadboad setup   After looking at the "garbage" a bit closer it became obvious that the garbage came from a bad dataline connection (Bit 5). It is running with no glitch now ...

[Thomas Jentzsch]

33 minutes ago, Al_Nafuur said:

CartridgePort.bin 20 B · 14 downloads

For the detection..

 

IMO we should find a way to live without it.

[+MarcoJ]

4 hours ago, Al_Nafuur said:

I don't think we should pursue the NOP delay solution any further! A reliable internal or external timer will be a game changer for the write cycles (this includes all RIOT/TIA peeks!) 

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.

4 hours ago, Al_Nafuur said:

A reliable internal or external timer

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? 

 

 

 

 

[Kroko]

What is currently causing these long interruptions ?

[+Al_Nafuur]

29 minutes ago, Kroko said:

What is currently causing these long interruptions ?

100us looks like the OS scheduler..

But the emulation shouldn't crash, or did it?

[Kroko]

Just now, Al_Nafuur said:

100us looks like the OS scheduler..

But the emulation shouldn't crash, or did it?

It didn't crash. Runs just normal. If we cannot control when the delay happens, are you confident this will not break any bankswitching ? And 92 us are hard to get back, right ?

[+Al_Nafuur]

9 minutes ago, Kroko said:

It didn't crash. Runs just normal. If we cannot control when the delay happens, are you confident this will not break any bankswitching ?

I am not sure if it can, but i can't imagine how. 

You can test with a F8 cart and set a breakpoint before the switch and then step thru in the debugger..

9 minutes ago, Kroko said:

And 92 us are hard to get back, right ?

Yes, but there are ways to make them shorter or maybe even prevent them for this thread/CPU

[+MarcoJ]

21 minutes ago, Al_Nafuur said:

100us looks like the OS scheduler..

@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.

[Kroko]

31 minutes ago, MarcoJ said:

echo -1 > /proc/sys/kernel/sched_rt_runtime_us

no will try that tomorrow ...

[+Al_Nafuur]

14 hours ago, Thomas Jentzsch said:

IMO we should find a way to live without it.

If we want to offer the user to also run "normal" bin files from an external storage like a SD-Card or USB storage, then we need the file selection anyway.

 

I thought of using the file as a configuration for the hardware (CPU, GPIOs etc. 🤷‍♂️). However, I have not yet thought of anything we really should configure there. For the setting of the TV format for example, one must insert only in the file name "NTSC" or "PAL50".

 

On the other hand we could also remove all other bankings and the file selector from Stella and only start/stop the emulation of the cartridge port via a switch.

 

What are your suggestions on this?

 

[+MarcoJ]

55 minutes ago, Al_Nafuur said:

For the setting of the TV format for example, one must insert only in the file name "NTSC" or "PAL50"

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? 

[DirtyHairy]

1 hour ago, Al_Nafuur said:

If we want to offer the user to also run "normal" bin files from an external storage like a SD-Card or USB storage, then we need the file selection anyway.

 

I thought of using the file as a configuration for the hardware (CPU, GPIOs etc. 🤷‍♂️). However, I have not yet thought of anything we really should configure there. For the setting of the TV format for example, one must insert only in the file name "NTSC" or "PAL50".

 

On the other hand we could also remove all other bankings and the file selector from Stella and only start/stop the emulation of the cartridge port via a switch.

 

What are your suggestions on this?

 

Ship two builds of Stella, one rtstella for bitbanging, and a regular build. Run a daemon that watches the port. Once a cartridge is inserted the daemon kills the running Stella instance and starts rtstella, once a cartridge is removed rtstella is killed and ordinary Stella runs again (displaying the dialog).

 

Why do you want to encode configuration in a "dummy cartridge"? Just use a configuration file 😏For the TV format: just add a hardware switch and wire it to a GPIO.

[+Al_Nafuur]

36 minutes ago, MarcoJ said:

Ah this will be handy.

Yes with multiple CartridgePort.bin files you can easily switch your console between all TV formats.

 

38 minutes ago, MarcoJ said:

It is irritating having to set that manually currently, each time a different cart is used.

I think the last state is stored for the bin file, so if you switch to PAL50 during the emulation of a "CartridgPort.bin" file without a TV format in the name it is PAL50 at the next startup.

41 minutes ago, MarcoJ said:

Does this mean the heuristic scan is skipped using the cartridgeport? 

I think this is only run once per bin file (the real bin file, not the ROM data).

 

[Thomas Jentzsch]

1 hour ago, DirtyHairy said:

For the TV format: just add a hardware switch and wire it to a GPIO.

Or set the property once. 

 

BUT: Properties for bankswitched ROMs with hotspots in the ROM area (most classic bankswitched ROMs) will (most likely) not be identified, because the hotspots return random values (right?). So the MD5 checksums will not match. And as long as we do not detect bankswitching, there is no way to fix this problem by ignoring these values.

 

Edit: But since we do not have a complete dump, we need a different approach here anyway. Maybe we could use e.g. the first N read bytes? And then load the properties and restart emulation? But even these might be different depending on which bank the cart starts. Hm...? Ideas?

Edited October 5, 2023 by Thomas Jentzsch

[+Al_Nafuur]

4 minutes ago, Thomas Jentzsch said:

Or set the property once. 

Maybe the users want to switch the TV format? Before inserting a cart and ideally even during the emulation without restart.

 

4 minutes ago, Thomas Jentzsch said:

BUT: Properties for bankswitched ROMs with hotspots in the ROM area (most classic bankswitched ROMs) will (most likely) not be identified, because the hotspots return random values (right?). So the MD5 checksums will not match. And as long as we do not detect bankswitching, there is no way to fix this problem by ignoring these values.

the md5sum is from the bin file not from the ROM data.

 

 

[Thomas Jentzsch]

6 minutes ago, Al_Nafuur said:

Maybe the users want to switch the TV format? Before inserting a cart and ideally even during the emulation without restart.

While the TV format is most relevant, there are many other options the user might want to change. E.g. without the bin file, Stella cannot auto detect the controllers used. IMO we definitely need: 

1. Access to the Stella UI
2. AND properties to save user settings per game

6 minutes ago, Al_Nafuur said:

the md5sum is from the bin file not from the ROM data.

I know, that's why we need an alternative.

[Thomas Jentzsch]

I think we could reuse the dialogs designed for the RetroN 77:

We just need a switch for opening the the Command Menu. From then on the user can navigate with a joystick (does that work?).

[Thomas Jentzsch]

Sooo, how can we identify a ROM at runtime? We have the addresses and the peeked data, which usually form a static sequence after inserting a cart. However there are at least two problems:

1. Bankswitched carts can start with a random start bank. Usually the first thing such carts do, is to switch to a defined bank which then executed the initialization code. So the initial code is executed in different banks and maybe different addresses.
2. Bankswitching requires access to hotspots, which can return random values.

IMO we somehow have to identify the begin of the initialization code and thus skipping the initial bankswitching. From then on we can generate a checksum, based on the the first e.g. 2000 instructions (using addresses and maybe(!, hotspots again) data). This still is not bulletproof, but probably sufficient for most carts

[+Al_Nafuur]

4 minutes ago, Thomas Jentzsch said:

Sooo, how can we identify a ROM at runtime? We have the addresses and the peeked data, which usually form a static sequence after inserting a cart. However there are at least two problems:

1. Bankswitched carts can start with a random start bank. Usually the first thing such carts do, is to switch to a defined bank which then executed the initialization code. So the initial code is executed in different banks and maybe different addresses.
2. Bankswitching requires access to hotspots, which can return random values.

IMO we somehow have to identify the begin of the initialization code and thus skipping the initial bankswitching. From then on we can generate a checksum, based on the the first e.g. 2000 instructions (using addresses and maybe(!, hotspots again) data). This still is not bulletproof, but probably sufficient for most carts

I like that idea, but what if the first 2000 instructions depend on user input/settings (console switches!)

 

[Thomas Jentzsch]

Just now, Al_Nafuur said:

I like that idea, but what if the first 2000 instructions depend on user input/settings (console switches!)

Yes, that's a problem. The longer the sequence, the more likely such an influence becomes.

But what else can we do?

[+Al_Nafuur]

13 minutes ago, Thomas Jentzsch said:

Yes, that's a problem. The longer the sequence, the more likely such an influence becomes.

But what else can we do?

I think the sequence can be much shorter. But to know it we have to write a Script to test for the shortest sequence to distinguish all known ROMs. 

[+MarcoJ]

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. 

 

 

[Thomas Jentzsch]

15 minutes ago, Al_Nafuur said:

I think the sequence can be much shorter.

Depends on how we define the length. Almost all ROMs have an initial loop, which clears the zeropage. Since that code is not very specific, we have to get past it to get good data. I used 2000 instruction to include that loop. But we better use the address range length instead of the executed instructions.

15 minutes ago, Al_Nafuur said:

But to know it we have to write a Script to test for the shortest sequence to distinguish all known ROMs. 

Good idea.

Edited October 5, 2023 by Thomas Jentzsch

[+splendidnut]

What about doing the evil 'dump the ROM' for the checksum and then 'reset/reboot' the cartridge either via hardware or software (making sure to randomize the starting bank)?

[DirtyHairy]

37 minutes ago, MarcoJ said:

@Al_Nafuur does the interrupt look feasible?

Nope. No way to use interrupts from userspace. Afaik the closest you can get is the the in-kernel GPIO driver, which lets you do a select on a fd that returns if an interrupt was triggered --- this is what libpigpio does. But that means yielding to the scheduler, and then we're talking microseconds again. I think polling is the only way here.