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

[+MarcoJ]

1 hour ago, Al_Nafuur said:

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

I tried with my copy. Couldn't get it to work. Tried over and over and eventually it worked once (race conditions?). I wonder if an automated mosfet switch could help turn on the cart when the driver is ready for it.

@Al_Nafuur updated.

 

 

[+Al_Nafuur]

3 minutes ago, MarcoJ said:

I tried with my copy. Couldn't get it to work. I wonder if an automated mosfet switch could help turn on the cart when the driver is ready for it.

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.

 

[+MarcoJ]

1 minute ago, Al_Nafuur said:

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!

Yeah, was thinking of a scheme that when the cartport rom is opened, it then powers up the cart with a mosfet and delays as much as it needs before attempting to access the cartridge. It could be a similar specification to the 2600's initial power on delay.

[+Al_Nafuur]

4 minutes ago, MarcoJ said:

Yeah, was thinking of a scheme that when the cartport rom is opened, it then powers up the cart with a mosfet and delays as much as it needs before attempting to access the cartridge. It could be a similar specification to the 2600's initial power on delay.

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.

 

[+MarcoJ]

2 minutes ago, Al_Nafuur said:

So we need some sort of switch or detection when a cartridge has been inserted.

This would be handy. I think there could be a master switch that turns the pi on, and it always stays on regardless of carts inserted. And the Atari's power switch could instead be a signal to Stella to start/stop the driver.

[+Al_Nafuur]

3 minutes ago, MarcoJ said:

This would be handy. I think there could be a master switch that turns the pi on, and it always stays on regardless of carts inserted. And the Atari's power switch could instead be a signal to Stella to start/stop the driver.

Good idea!

 

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

[+MarcoJ]

@Al_Nafuur can you think of further "technically challenging" games I could test out? I just tried Tunnel Runner on the PlusCart and it worked. 

[+Al_Nafuur]

7 minutes ago, MarcoJ said:

@Al_Nafuur can you think of further "technically challenging" games I could test out? I just tried Tunnel Runner on the PlusCart and it worked. 

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:

 

[+MarcoJ]

Ok, that’s a cart I have. Worked ok with RTStella.

[+MarcoJ]

…as does Tunnel Runner

[+Al_Nafuur]

2 hours ago, MarcoJ said:

@Al_Nafuur can you think of further "technically challenging" games I could test out? I just tried Tunnel Runner on the PlusCart and it worked. 

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)

[Thomas Jentzsch]

2 hours ago, Al_Nafuur said:

Tunnel Runner is CBS FA banking?

Yup.

[Thomas Jentzsch]

Dig Dug is probably the most common SC game. Others more common ones:

• Crystal Castles
• Millipede
• Stargate/Defender 2
• Desert Falcon
• Jr. Pac-Man

E7 alternatives:

• Bump'n Jump
• Power of He-Man

Some modern homebrews use extra RAM too.

[DirtyHairy]

3 hours ago, MarcoJ said:

I tried with my copy. Couldn't get it to work. Tried over and over and eventually it worked once (race conditions?). I wonder if an automated mosfet switch could help turn on the cart when the driver is ready for it.

Nice, interesting. The speed seems to be good, but the pitch of the oscillator seems to be seriously off. According to Kevtris' reverse engineering this is a simple oscillator circuit with a cap and resistor. It seems the way the cart is wired up influences this circuit.

[DirtyHairy]

@Al_Nafuur @MarcoJ @Kroko and anybody else involved 😏 How do we plan to continue? I see several possible things to try next

 

1. Improve rtstella: make emulation cycles more deterministic by eliminating caching and batching optimisations. Originally, that was my next step.
2. Classify reads in relevant and irrelevant reads und use that to eliminate bad writes due to dummy reads to the same address before writing (as in absolute indirect addressing)
3. Try to find a working hardware timer and use that to get a lower bound on cycle time
4. Use a RT thread on another core to get a monotonic counter and use that to get a reliable lower bound on cycle time
5. Use an external circuit to make sure that there is sufficient delay before putting the value on the bus
6. ...?

1., 2. 3. and 4. are pure software tasks, and 2. and 4. should improve compatibility. I could work on any of them, but I don't know what your plans are, and I cannot test myself (still have to order the necessary components). I would prefer 3 and 4, but what are your preferences?

[Thomas Jentzsch]

I could do 2.

[Thomas Jentzsch]

25 minutes ago, DirtyHairy said:

Nice, interesting. The speed seems to be good, but the pitch of the oscillator seems to be seriously off. According to Kevtris' reverse engineering this is a simple oscillator circuit with a cap and resistor. It seems the way the cart is wired up influences this circuit.

They pitches vary between carts (Stella has a setting for that). Marco should compare with how it behaves in a real console. If that's possible.

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

Dig Dug is probably the most common SC game. Others more common ones:

• Crystal Castles
• Millipede
• Stargate/Defender 2
• Desert Falcon
• Jr. Pac-Man

E7 alternatives:

• Bump'n Jump
• Power of He-Man

👍

1 hour ago, Thomas Jentzsch said:

Some modern homebrews use extra RAM too.

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😠

 

[DirtyHairy]

2 hours ago, DirtyHairy said:

Try to find a working hardware timer and use that to get a lower bound on cycle time

To iterate on that, I think I have found a good solution --- the ARM performance counter. Once enabled it counts CPU cycles (so sub-nanosecond, and at a fixed rate if scaling is disabled), and reading it is a single MRS instruction to access a special register. The access is usually blocked from userspace, but access for unprivileged code can be enabled from within a small kernel module that configures the relevant special registers.

Edited September 26, 2023 by DirtyHairy

[+Al_Nafuur]

1 minute ago, DirtyHairy said:

To iterate on that, I think I have found a good solution --- the ARM performance counter. Once enabled it counts CPU cycles (so sub-nanosecond, and at a fixed rate if scaling is disabled), and reading it is a single MRS instruction to access a special register. The access is usually blocked from userspace, but access to unprivileged code can be enabled from within a small kernel module that configures the relevant special registers.

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

 

[DirtyHairy]

https://github.com/jerinjacobk/armv8_pmu_cycle_counter_el0

 

That's a kernel module that enables this (and a few other counter) and gives permission to unprivileged code (on aarch64). The relevant register is pmccntr_el0 . You can find more information in the ARM v8 reference manual, section D12 (performance monitor extensions). The following code for reading the counter is quoted from the readme of this module:

 

static inline uint64_t
read_pmccntr(void)
{
	uint64_t val;
	asm volatile("mrs %0, pmccntr_el0" : "=r"(val));
	return val;
}

Edited September 26, 2023 by DirtyHairy

[+5-11under]

9 minutes ago, DirtyHairy said:

To iterate on that, I think I have found a good solution --- the ARM performance counter. Once enabled it counts CPU cycles (so sub-nanosecond, and at a fixed rate if scaling is disabled), and reading it is a single MRS instruction to access a special register. The access is usually blocked from userspace, but access to unprivileged code can be enabled from within a small kernel module that configures the relevant special registers.

So... running unprivileged code to run illegal opcodes. I hope nobody finds out.

[DirtyHairy]

3 minutes ago, 5-11under said:

So... running unprivileged code to run illegal opcodes. I hope nobody finds out.

😛 I think the only reason why this is not usually enabled is to make side-channel attacks that require precise timers more difficult.

Edited September 26, 2023 by DirtyHairy

[+MarcoJ]

4 hours ago, Al_Nafuur said:

Do you have any FxSC (SC-RAM) cartridges or any other cartridge with RAM.

I just tried out Super Football and Desert Falcon. Neither were able to start up.

 

[DirtyHairy]

Well, the performance counter works. After building and inserting the kernel module that I linked I can run the following sample:

 

#include <iostream>
#include <cstdint>

using namespace std;

static inline uint64_t read_pmccntr(void) {
    uint64_t val;
    asm volatile("mrs %0, pmccntr_el0" : "=r"(val));
    return val;
}

int main() {
    uint64_t samples[32];

    for (auto& sample: samples) sample = read_pmccntr();

    for (int i = 0; i < 32; i++) {
        cout << samples[i];
        if (i > 0) cout << " : " << samples[i] - samples[i-1];

        cout << endl;
    }
}

 

and the output at "-O2" is

 

13553396869
13553396888 : 19
13553396901 : 13
13553396914 : 13
13553396920 : 6
13553396926 : 6
13553396932 : 6
13553396938 : 6
13553396944 : 6
13553396950 : 6
13553396956 : 6
13553396962 : 6
13553396968 : 6
13553396974 : 6
13553396980 : 6
13553396986 : 6
13553396992 : 6
13553396998 : 6
13553397004 : 6
13553397010 : 6
13553397016 : 6
13553397022 : 6
13553397028 : 6
13553397034 : 6
13553397040 : 6
13553397046 : 6
13553397052 : 6
13553397058 : 6
13553397064 : 6
13553397070 : 6
13553397076 : 6
13553397082 : 6

 

🎉

@Al_Nafuur This should do the trick.