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

[DirtyHairy]

23 hours ago, MarcoJ said:

ooray! Mine is working. It is using a pi 4B and the cart Berzerk is under test. Sound is working through the pi headphone port. The source code needs a one-liner change to support the pi 4B.

🎉 Are you using rtstella? How is performance? Is audio OK (can only be if it runs at 100% speed), do you get underruns?

[MarcoJ]

2 minutes ago, DirtyHairy said:

Are you using rtstella? How is performance? Is audio OK (can only be if it runs at 100% speed), do you get underruns?

I am about to redirect the sources now. 

[+Al_Nafuur]

9 minutes ago, MarcoJ said:

I am about to redirect the sources now. 

I changed the howto for rtstella:

You will have to use "make clean" after the ./configure and build the whole thing again. ☕

 

As a Pi4 user you should take a look at line 281 of CartPort.cxx you most certainly will have to increase the delay counter "i" until all bankings of the PlusCart/Harmony are stable.

 

We really need to find an other clock source for the delay:

https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf

 

I am testing the ARM clock mentioned in chapter 12 again today, but I can not get the free running counter (~4ns ticks) to run.

 

 

[MarcoJ]

39 minutes ago, Al_Nafuur said:

I changed the howto for rtstella:

the rtstella build needs: "sudo ./configure --host=RTSTELLA && sudo make j2 all"
 

 

I tried this, and it says "Cross compiling to unknown target, please add your target to configure"

 

When running ./configure by itself, it doesn't need this option set.

[MarcoJ]

I think the RTSTELLA needs to be lowercase. This worked for me:

 

sudo ./configure --host=rtstella && sudo make j2 all

[+Al_Nafuur]

8 minutes ago, MarcoJ said:

I think the RTSTELLA needs to be lowercase. This worked for me:

 

sudo ./configure --host=rtstella && sudo make j2 all

👍

yes, fixed

[DirtyHairy]

Just now, Al_Nafuur said:

sudo ./configure --host=rtstella && sudo make j2 all

Small correction: should me "make -j2 all" . And no "sudo" --- the build (none of the steps) doesn't need to be done as root 😏

[MarcoJ]

OK, it compiles and runs. However, the cart isn't reading right. I think I need to tinker with those speed settings you mentioned.

 

Edit: Real carts reading well, flash carts having difficulty starting.

[MarcoJ]

RTStella ran OK with a real cart, with the standard setting of “300”. Could not get Harmony or Pluscart to start without Stella ducking into the debugger with errors. I tried Berzerk, seems to be running in real time. Pluscart seems to recover after an initial error.
 

 

 

Edited September 26, 2023 by MarcoJ
new discoveries

[DirtyHairy]

2 hours ago, MarcoJ said:

RTStella ran OK with a real cart, with the standard setting of “300”. Could not get Harmony or Pluscart to start without Stella ducking into the debugger with errors. I tried Berzerk, seems to be running in real time. 

Awesome! Sound seems OK, too, that's a good start. The flash carts may be harder to get running. We have to make the bus cycles shorter than a real VCS in order to keep up, and at least some Uno drivers barely fit into the ordinary cycle budget. I guess if you increase the 300 you'll get them running, but at slower-than-realtime speed.

Edited September 25, 2023 by DirtyHairy

[+Al_Nafuur]

2 hours ago, MarcoJ said:

RTStella ran OK with a real cart, with the standard setting of “300”. Could not get Harmony or Pluscart to start without Stella ducking into the debugger with errors. I tried Berzerk, seems to be running in real time. 
 

 

33 minutes ago, DirtyHairy said:

Awesome! Sound seems OK, too, that's a good start. The flash carts may be harder to get running. We have to make the bus cycles shorter than a real VCS in order to keep up, and at least some Uno drivers barely fit into the ordinary cycle budget. I guess if you increase the 300 you'll get them running, but at slower-than-realtime speed.

The problem is that the NOP loop is just a delay not a real timer. For the write cycles this means we are currently adding this delay on top to the execution time before the next bus access. This also includes the read/write accesses to the RIOT/TIA where we set the bus to "inform" the cartridge about whats going on!

 

With a real timer we would only wait the remaining time after Stella has done its thing between two bus accesses.

 

 

[DirtyHairy]

37 minutes ago, Al_Nafuur said:

With a real timer we would only wait the remaining time after Stella has done its thing between two bus accesses.

Good point. It might be with a try to spawn a realtime thread that continuously increments a shared variable. We can use std::atomic to make sure that the increment happens in one instruction and the proper barriers are inserted.

[+Al_Nafuur]

3 hours ago, DirtyHairy said:

We have to make the bus cycles shorter than a real VCS in order to keep up,

Not necessarily. If we manage to do all emulation stuff during tADS (30ns) of the 6502 and all the 6502 cycles that don't do bus access, we can do realtime without shortening the bus cycles.

[+Al_Nafuur]

8 hours ago, rbairos said:

Can you explain why having any of the upper 3 address bits set caused issues?

We are using GPIO 0-12 for the address and 13-20 for the data bus. When Stella wants to write (poke) a value to a address I had set the GPIOs like this:

 uInt32 gpio_value = (uInt32) address | (((uInt32)value)<<13 );

the correct way to do this is:

 uInt32 gpio_value = (uInt32) (address & 0x1fff) | (((uInt32)value)<<13 );

 

8 hours ago, rbairos said:

Who was relying on them specifically?

The cartridges with RAM or other hotspots.

 

8 hours ago, rbairos said:

Where were they being manifest?

In the ROM code?

[DirtyHairy]

1 hour ago, Al_Nafuur said:

Not necessarily. If we manage to do all emulation stuff during tADS (30ns) of the 6502 and all the 6502 cycles that don't do bus access, we can do realtime without shortening the bus cycles.

Every 6502 cycle is a bus access. The only ones that we can likely skip if we aim for high accuracy and compatibility are multiple redundant reads to the same address. Ignoring this small number of cycles that we can safely skip on the bus we have to wait for the end of each cycle before we can do the next, so emulation essentially has to happen in lockstep with the VCS clock.

 

Let's say the VCS' clock is 1MHz for simplicity. Then each bus cycle is 1us. If each bus cycle takes 1us, then we can at most emulate 1000000 cycles per second, which is exactly what we require for full speed. If we loose any of those cycles (and we will due to scheduling) we have absolutely no time left to catch up again, and the emulation will effectively be slower than real time.

 

So we need some leeway to catch up with those cycles missed by scheduling. The only deterministic way of getting those is shortening the bus cycles. We can also try to get away with ignoring more cycles on the bus, but this comes at the price of reduced compatibility, and the mileage will vary from game to game.

Edited September 25, 2023 by DirtyHairy

[MarcoJ]

1 hour ago, Al_Nafuur said:

The cartridges with RAM or other hotspots.

I imagine games that use a reset vector as say 0xF000 rather than 0x1000 would have died off too. This is at least the case for my E7 programs, which would die asap with the previous un-bitmasked code. Since the 2600 has those last 3 address pins unconnected it does its own bitmasking in hardware.

[JetSetIlly]

1 hour ago, DirtyHairy said:

So we need some leeway to catch up with those cycles missed by scheduling.

Have you tried the different Linux schedulers? A soft real-time scheduler like FIFO or Deadline might be good enough.

[DirtyHairy]

4 minutes ago, JetSetIlly said:

Have you tried the different Linux schedulers? A soft real-time scheduler like FIFO or Deadline might be good enough.

Yeah, I am using FIFO at highest priority for rtstella. But still, all of these can and will be preempted.

[JetSetIlly]

3 minutes ago, DirtyHairy said:

Yeah, I am using FIFO at highest priority for rtstella. But still, all of these can and will be preempted.

I've not looked at Deadline but from what I understand it's more predictable than FIFO. I've not kept up with the hard real-time patches. I assume there are some still in development.

[DirtyHairy]

6 minutes ago, JetSetIlly said:

I've not looked at Deadline but from what I understand it's more predictable than FIFO. I've not kept up with the hard real-time patches. I assume there are some still in development.

Neither have I, but so agree Deadline is worth a look 😏. I also have preempt_rt on my list. Still, i think we basically have to (be able to) live with preemption.

[MarcoJ]

Pitfall II running on RTStella in real time with "400" delay using PlusCart.

 

 

 

 

[MarcoJ]

16 hours ago, Al_Nafuur said:

the correct way to do this is:

 uInt32 gpio_value = (uInt32) (address & 0x1fff) | (((uInt32)value)<<13 );

Implemented this on my local branch of RTStella. This allows games such as Aardvark to work.

[+Al_Nafuur]

6 minutes ago, MarcoJ said:

Implemented this on my local branch of RTStella. This allows games such as Aardvark to work.

rebase the feature/cartridgeport branch?

 

[MarcoJ]

1 minute ago, Al_Nafuur said:

rebase the feature/cartridgeport branch?

ahh this must have lapsed. I'll set it up

[+Al_Nafuur]

1 hour ago, MarcoJ said:

Pitfall II running on RTStella in real time with standard “300” delay using PlusCart.

 

 

 

 

 

nice!

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