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

[+MarcoJ]

4 hours ago, Al_Nafuur said:

M-Network "Burgertime" (E7)

I have a copy somewhere. When I find it I will try it out. I had some success with E7 on PlusCart, but typically it would crash on startup, but worked after restarting RTStella after initial bootstrapping.

[+Al_Nafuur]

35 minutes ago, MarcoJ said:

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

 

Are you still using a NOP delay counter of 300 on the Pi4? Maybe real SC-RAM is not fast enough?

 

[Thomas Jentzsch]

5 minutes ago, Al_Nafuur said:

Are you still using a NOP delay counter of 300 on the Pi4? Maybe real SC-RAM is not fast enough?

SC RAM is too slow for running code in it.

[+Al_Nafuur]

42 minutes ago, Thomas Jentzsch said:

SC RAM is too slow for running code in it.

I mean too slow for a write cycle of 300 Pi4 NOPs

 

[+MarcoJ]

2 hours ago, Al_Nafuur said:

Are you still using a NOP delay counter of 300 on the Pi4? Maybe real SC-RAM is not fast enough?

 

I think it was about 380 last I checked. I’ll try bump it later.

[+Al_Nafuur]

2 hours ago, DirtyHairy said:

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.

I think I first need the 64 bit Pi OS:

t@raspberrypi:~/Dokumente $ git clone https://github.com/jerinjacobk/armv8_pmu_cycle_counter_el0
Klone nach 'armv8_pmu_cycle_counter_el0' ...
remote: Enumerating objects: 54, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 54 (delta 4), reused 12 (delta 3), pack-reused 36
Empfange Objekte: 100% (54/54), 23.36 KiB | 1.56 MiB/s, fertig.
Löse Unterschiede auf: 100% (14/14), fertig.
t@raspberrypi:~/Dokumente $ cd armv8_pmu_cycle_counter_el0/
t@raspberrypi:~/Dokumente/armv8_pmu_cycle_counter_el0 $ make
make -C /lib/modules/6.1.21-v7+/build M=/home/t/Dokumente/armv8_pmu_cycle_counter_el0 modules
make[1]: Verzeichnis „/usr/src/linux-headers-6.1.21-v7+“ wird betreten
  CC [M]  /home/t/Dokumente/armv8_pmu_cycle_counter_el0/armv8_pmu_el0_cycle_counter.o
/home/t/Dokumente/armv8_pmu_cycle_counter_el0/armv8_pmu_el0_cycle_counter.c:18:2: error: #error Module can only be compiled on ARM64 machines.
   18 | #error Module can only be compiled on ARM64 machines.
      |  ^~~~~
make[2]: *** [scripts/Makefile.build:250: /home/t/Dokumente/armv8_pmu_cycle_counter_el0/armv8_pmu_el0_cycle_counter.o] Fehler 1
make[1]: *** [Makefile:2012: /home/t/Dokumente/armv8_pmu_cycle_counter_el0] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-6.1.21-v7+“ wird verlassen
make: *** [Makefile:7: all] Fehler 2
t@raspberrypi:~/Dokumente/armv8_pmu_cycle_counter_el0 $ uname -a
Linux raspberrypi 6.1.21-v7+ #1642 SMP Mon Apr  3 17:20:52 BST 2023 armv7l GNU/Linux

 

[DirtyHairy]

5 hours ago, Al_Nafuur said:

I think I first need the 64 bit Pi OS:

The same functionality is available in 32bit mode and exposed via CP15, so you need slightly different instruction sequences there. There is also example code on the web for this (both for reading and for the setup in kernel space), but I think switching to 64bit would be a good idea anyway and give better performance.

[Thomas Jentzsch]

8 hours ago, Al_Nafuur said:

I mean too slow for a write cycle of 300 Pi4 NOPs

I thought the slowness of the RAM might affect the minimum write cycle length. But then, I have no idea about hardware.  

[+MarcoJ]

13 hours ago, Al_Nafuur said:

Are you still using a NOP delay counter of 300 on the Pi4? Maybe real SC-RAM is not fast enough?

Ok, here’s some results. I set the delay to 1000 to see what would happen.

 

Results:

- Super Football runs, but not Desert Falcon.(SC games)

- Harmony runs, and Ms Pacman ran off that (SC emulated in Harmony)

- Emulation is way below real time. It is probably a bit faster than the original non rtstella source. 

One thing that may help us gauge real time performance is the Stella fps readout. For some reason with CartPort it’s always at 0.0fps. Is it an easy fix?

 

 

 

[+MarcoJ]

18 hours ago, DirtyHairy said:

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

I can try this. I have some USB rubber duckie PCBs that have the ATTIny85 microcontroller. This can be used to make an accurate interrupt timer. I need to order an ISP cable.

[+Al_Nafuur]

21 minutes ago, MarcoJ said:

I can try this. I have some USB rubber duckie PCBs that have the ATTIny85 microcontroller. This can be used to make an accurate interrupt timer. I need to order an ISP cable.

I thought of an ATTiny25/.. too. They have a clock speed of 20Mhz, so the delay timer can be set in 50ns "accuracies". For the "cycle" length the RaspberryPi CPU cycle counter supposed by @DirtyHairy would be more accurate. But because of the OS scheduler we wouldn't be able to "shape" the cycles for write delays with the software driver alone. A external MCU would be more secure if shaping the write cycle becomes necessary.

 

 

[Thomas Jentzsch]

2 hours ago, MarcoJ said:

One thing that may help us gauge real time performance is the Stella fps readout. For some reason with CartPort it’s always at 0.0fps. Is it an easy fix?

 

@DirtyHairy I suppose that's a side effect of the adapted scheduling, right?

[DirtyHairy]

5 hours ago, Thomas Jentzsch said:

@DirtyHairy I suppose that's a side effect of the adapted scheduling, right?

Yeah, that’s just a bug, I’ll take a look.

[+stephena]

7 minutes ago, DirtyHairy said:

Yeah, that’s just a bug, I’ll take a look.

I think the FPS shown is the virtual one (close to NTSC or PAL), and not the physical one.  So fixing it may be more like adding support for a physical FPS counter.  That's if I'm remembering correctly, that is.

[DirtyHairy]

23 minutes ago, stephena said:

I think the FPS shown is the virtual one (close to NTSC or PAL), and not the physical one.  So fixing it may be more like adding support for a physical FPS counter.  That's if I'm remembering correctly, that is.

Hm, you may be right, I am not sure whether I am remembering it correctly either 😏

[+Al_Nafuur]

On 9/27/2023 at 7:22 AM, DirtyHairy said:

The same functionality is available in 32bit mode and exposed via CP15, so you need slightly different instruction sequences there. There is also example code on the web for this (both for reading and for the setup in kernel space), but I think switching to 64bit would be a good idea anyway and give better performance.

I switched to the 64bit PiOS and tried a clean build. But the build process always gets stucked when building the AboutDialog.

 

I tried building as normal pi user and as root. The Pi gets very unresponsive and is unusable at this point. I have to power it off/on to get it working again.

 

Has anyone build rtstella on the 64bit PiOS so far?

 

[+Al_Nafuur]

On 9/13/2023 at 9:34 AM, JetSetIlly said:

 It'll be interesting to get Gopher2600 working in a similar manner.

Do you already have a plan when you want to start the development? Or have you already started?
Do you think Gopher2600 is fast enough for the delays caused by reading and writing from the cartridge?

 

 

 

[JetSetIlly]

3 minutes ago, Al_Nafuur said:

Do you already have a plan when you want to start the development? Or have you already started?
Do you think Gopher2600 is fast enough for the delays caused by reading and writing from the cartridge?

Great question. The program as it is now will have too much overhead but I should be able to use the core of the emulation to create something that would work. Compiling with TinyGo rather than the regular Go compiler would yield better results for a hardware based application but I've no experience with TinyGo and can't really predict the results. So to answer the question, it may be fast enough, I'm not sure.

 

I suspect I can get 80% of the way there but by the sounds of it, some cartridge types require exceedingly rigid timing. Go isn't really designed for that kind of thing so it would be a challenge. Put it this way, if turns out that 100% compatibility is not possible with Stella, it's definitely not possible with Gopher2600

 

The other question to ask is whether it would be worth doing at all. Without the debugger and all that other stuff, the core of the Gopher2600 emulation would bring absolutely nothing new to the table. It would do the same job as Stella but very probably worse, due to the implementation language.

 

All that said, this hardware talk has inspired me and I have a couple of ideas I want to explore. But whatever I do, it probably won't look like what's being done with rtStella.

[+Al_Nafuur]

2.4 GHz !!

Maybe we should wait for the Pi5 🤣

 

[+MarcoJ]

21 hours ago, Al_Nafuur said:

Has anyone build rtstella on the 64bit PiOS so far?

I’ll make a new card for my pi4. 64bit would be preferable given some boards come with 8gb ram now. I’ll report back with results.

[+MarcoJ]

Interesting. My 64bit build didn’t get the hangups with the about dialogue, however it had some errors in CartPort.cxx

 

 

Since then I commented out those printfs, and it has continued to compile and succeeded.

[+Al_Nafuur]

1 minute ago, MarcoJ said:

Interesting. My 64bit build didn’t get the hangups with the about dialogue, however it had some errors in CartPort.cxx

 

long

 

 

[+MarcoJ]

17 minutes ago, Al_Nafuur said:

long

Ah I see, you tried building without RTStella to get it working. Apologies, I did my own thing. I commented out the printf statements in CartPort.cxx. It compiled OK and RTStella is working similarly to 32 bit. I have kept the 32-bit OS if needing to roll back.

[+Al_Nafuur]

4 minutes ago, MarcoJ said:

Ah I see, you tried building without RTStella to get it working. Apologies, I did my own thing. I commented out the printf statements in CartPort.cxx. It compiled OK and RTStella is working similarly to 32 bit. I have kept the 32-bit OS if needing to roll back.

I also build with rtstella. But the compile error has nothing to do with rtstella. In 64bit os pointer are 64bit (long) and int is 32bit.

[+MarcoJ]

12 minutes ago, Al_Nafuur said:

In 64bit os pointer are 64bit (long) and int is 32bit.

OK, converted those ints to longs in the code. Compiled without errors, just warnings this time.