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

[Thomas Jentzsch]

On 11/8/2023 at 12:50 PM, Thomas Jentzsch said:

Agreed. I have reopened the issue.

I just added a trace logging option to Stella. You can enable it with via command line ("dbg.logtrace 1") or toggle it inside the debugger ("logtrace").

 

Note: This requires quite a lot of CPU time and thus may slowdown emulation (especially in our case). Also the logging output will become huge soon. So I am not sure if it really helps.

[+Al_Nafuur]

On 11/14/2023 at 3:21 PM, Al_Nafuur said:

I think I found the issue. But not a solution for the RTStella console, only a workaround in the PlusCart firmware for the issue on FE banking:

 

I tried to apply the same workaround to the SuperCharger emulation on the PlusCart, but no luck so far. Maybe it is because the SuperCharger is "looking" 5 cycles ahead in contrast to the 1 cycle that FE is looking ahead.

[+Al_Nafuur]

On 11/14/2023 at 8:31 PM, Al_Nafuur said:

https://www.suse.com/c/cpu-isolation-introduction-part-1/

https://www.stephenwagner.com/2020/03/17/how-to-compile-linux-kernel-raspberry-pi-4-raspbian/

http://comfilewiki.co.kr/en/doku.php?id=comfilepi:improving_real-time_performance:index

 

I tried to improve the RT performance and compiled a new kernel with "nohz_full" enabled, but no difference for FE and SuperCharger

 

The next step would be to compile a kernel patched with the real-time kernel patches:

http://comfilewiki.co.kr/en/doku.php?id=comfilepi:compile_a_real-time_kernel:index

 

But basically this is a very high effort for the simple fact that the RaspberryPi CPU cannot set its GPIOs in one step. And since the Pi also has not enough GPIOs for emulating the IO's of RIOT and TIA, we might rethink using an other CPU..

 

[+Al_Nafuur]

14 hours ago, Al_Nafuur said:

I tried to improve the RT performance and compiled a new kernel with "nohz_full" enabled, but no difference for FE and SuperCharger

 

The next step would be to compile a kernel patched with the real-time kernel patches:

http://comfilewiki.co.kr/en/doku.php?id=comfilepi:compile_a_real-time_kernel:index

 

But basically this is a very high effort for the simple fact that the RaspberryPi CPU cannot set its GPIOs in one step. And since the Pi also has not enough GPIOs for emulating the IO's of RIOT and TIA, we might rethink using an other CPU..

I think a RT kernel will make things more difficult than better. The main issue is that we need 2 steps with the Pi CPU to change the GPIOs, so we should focus on solving this issue.

 

possible solutions I see:

• Using a different CPU that is better available (and has more GPIOs)
• Using extra hardware to make the address bus switch instantaneously (2x 74HC573N latches ?)
• Try to solve the issue in software (turn of pull up/down resistors and shortly switch GPIOs to input to "clear" them)
• Try a RT kernel (unclear if it will solve this issue) 

any other suggestions?

 

 

 

[+MarcoJ]

14 minutes ago, Al_Nafuur said:

The main issue is that we need 2 steps with the Pi CPU to change the GPIOs, so we should focus on solving this issue.

Does 2 steps limit the precision of timing for the bus cycle length? If it were only one change, how would this affect performance?

[+Al_Nafuur]

4 minutes ago, MarcoJ said:

Does 2 steps limit the precision of timing for the bus cycle length? If it were only one change, how would this affect performance?

It has nothing to do with timings, for the cartridges there are only address bus changes and every change is a "cycle".

Any delay/jitter (IRQ, scheduler, clock ticks, ...) between the two steps will look like an "extra" cycle (address $00) for the cartridge. This is fatal for bankings that are "counting" cycles. 

[+MarcoJ]

7 minutes ago, Al_Nafuur said:

It has nothing to do with timings, for the cartridges there are only address bus changes and every change is a "cycle".

Any delay/jitter (IRQ, scheduler, clock ticks, ...) between the two steps will look like an "extra" cycle (address $00) for the cartridge. This is fatal for bankings that are "counting" cycles.

ah ic, this relates more to the Decathlon effect you were studying. So in theory, with the latch ICs, even though the Pi is taking multiple GPIO writes to set up the address, from the cart's perspective it's an atomic operation.

[+Al_Nafuur]

1 hour ago, Al_Nafuur said:

possible solutions I see:

• Using a different CPU that is better available (and has more GPIOs)
• Using extra hardware to make the address bus switch instantaneously (2x 74HC573N latches ?)
• Try to solve the issue in software (turn of pull up/down resistors and shortly switch GPIOs to input to "clear" them)
• Try a RT kernel (unclear if it will solve this issue) 

After studying the docs again I am sure the software/driver solution is impossible.

 

[+Al_Nafuur]

23 hours ago, Al_Nafuur said:

possible solutions I see:

• Using a different CPU that is better available (and has more GPIOs)
• Using extra hardware to make the address bus switch instantaneously (2x 74HC573N latches ?)
• Try to solve the issue in software (turn of pull up/down resistors and shortly switch GPIOs to input to "clear" them)
• Try a RT kernel (unclear if it will solve this issue) 

I looked at the docs of the Rockchip RK3566 and it looks like it can only set 16bit of GPIOs at once. So we would need two steps to setup address and data, which could lead to timing issues too.

 

I have ordered a few 74HC573N latches to test that route.

[+MarcoJ]

5 hours ago, Al_Nafuur said:

I have ordered a few 74HC573N latches to test that route.

Could have a separate I/O pin for the Output enable (OE), that only outputs when all are setup. But if there's one section that needs to sustain values from before , then perhaps two layers of latches can be used for one of the sections.

[+Al_Nafuur]

33 minutes ago, MarcoJ said:

Could have a separate I/O pin for the Output enable (OE), that only outputs when all are setup. But if there's one section that needs to sustain values from before , then perhaps two layers of latches can be used for one of the sections.

I thought of trying the latches only for the address bus. OE permanent enabled and LE to one GPIO

[Kroko]

@Al_Nafuur, I am looking at your new branch and I would like to understand how in the current code I can control

* the length of the time slice
* the delay between setting the address and reading the bus

With that new branch I am sometimes getting illegal instruction crashes, even though these shouldn't happen in a non bankswitched cart, right ?

Also the plus cart doesn't want to start up at all ...

Another question ... are you debouncing the reads ? Do you read one time and thats it ... or are you doing two reads and repeat until the two reads are equal ?

Edited November 17, 2023 by Kroko

[Kroko]

... and is there any chance we could set some GPIO when the console enters the debugger with some invalid instruction ?

[+Al_Nafuur]

31 minutes ago, Kroko said:

@Al_Nafuur, I am looking at your new branch and I would like to understand how in the current code I can control

* the length of the time slice

which time slice?

 

32 minutes ago, Kroko said:

* the delay between setting the address and reading the bus

the waitloop is defined in the "cycleManagerThread()"

https://github.com/Al-Nafuur/stella/blob/feature/cartridgeportThread/src/emucore/CartPort.cxx#L264

on the Raspberry Pi3B+  you might set g = 450; to get to real time emulation. 700 was a bit too high in my commit.

 

36 minutes ago, Kroko said:

Another question ... are you debouncing the reads ? Do you read one time and thats it ... or are you doing two reads and repeat until the two reads are equal ?

No de-bounce, we are reading what is on the bus at the end of the cycle. We might read a few ns earlier like the 6502 does and use a shorter delay loop for our reads.

 

41 minutes ago, Kroko said:

With that new branch I am sometimes getting illegal instruction crashes, even though these shouldn't happen in a non bankswitched cart, right ?

Also the plus cart doesn't want to start up at all ...

This shouldn't happen. I switched to a Raspberry Pi4. I will test with my Pi3 tomorrow.

 

28 minutes ago, Kroko said:

... and is there any chance we could set some GPIO when the console enters the debugger with some invalid instruction ?

This might be possible, what information do you want to set on the GPIOs?

You can also press "continue" when the invalid instruction pop up occurs and investigate the state of the 2600 in the debugger.

 

[Kroko]

6 minutes ago, Al_Nafuur said:

which time slice?

the length of one 6507 bus cycle (should be 840 ns but I see more

 

7 minutes ago, Al_Nafuur said:

on the Raspberry Pi3B+

I am using a Pi4 now, since on my Pi3 for some reason GPIO3 was no longer working

 

12 minutes ago, Al_Nafuur said:

This might be possible, what information do you want to set on the GPIOs?

I would like to use a new currently unused pin that I can trigger the logic analyzer on, so I can see the bus at the time of the invalid instruction.

[+Al_Nafuur]

18 hours ago, Kroko said:

the length of one 6507 bus cycle (should be 840 ns but I see more

Yes g=700 is to much, on the Pi4 500 to 550 should be better

 

18 hours ago, Kroko said:

I am using a Pi4 now, since on my Pi3 for some reason GPIO3 was no longer working

I think my Pi3 has failed too. Have you changed BCM2708_PERI_BASE to the base (0xFE000000) of the Pi4 ?

 

 

18 hours ago, Kroko said:

I would like to use a new currently unused pin that I can trigger the logic analyzer on, so I can see the bus at the time of the invalid instruction.

Maybe @Thomas Jentzsch knows if/how the driver gets informed when the debugger is started.

[Kroko]

9 minutes ago, Al_Nafuur said:

I think my Pi3 has failed too. Have you changed BCM2708_PERI_BASE to the base (0xFE000000) of the Pi4 ?

I changed that. Most of the ROMs are working stable again. I think my main issue was that I missed a loose ground connection.
But I do not get the PlusCart to run. It immediately enters the debugger

[+MarcoJ]

2 hours ago, Kroko said:

It immediately enters the debugger

This is common for me too. But it usually clears up after continuing execution. Having said that, once the PlusCart gets a rom loaded into memory, each time RTStella is restarted it does not go into debugger.

[+Al_Nafuur]

2 hours ago, Kroko said:

I changed that. Most of the ROMs are working stable again. I think my main issue was that I missed a loose ground connection.
But I do not get the PlusCart to run. It immediately enters the debugger

11 minutes ago, MarcoJ said:

This is common for me too. But it usually clears up after continuing execution. Having said that, once the PlusCart gets a rom loaded into memory, each time RTStella is restarted it does not go into debugger.

can you post a short video of the issue with the PlusCart ?

[Kroko]

One question, I got this bus recording:

the "DIR" of the databus was surprising for me, because when I look at the address bus, I can not see why it should reverse the databus direction while $1002 or $1FF9 is on the address bus ...

Video will follow, after recompile is finished

[+Al_Nafuur]

24 minutes ago, Kroko said:

One question, I got this bus recording:

the "DIR" of the databus was surprising for me, because when I look at the address bus, I can not see why it should reverse the databus direction while $1002 or $1FF9 is on the address bus ...

What ROM is it?

[Kroko]

1 hour ago, MarcoJ said:

This is common for me too. But it usually clears up after continuing execution.

Wow, so easy. I just didn't continue because i thought it is broken. But after I continue it works Thanks!

[Kroko]

7 minutes ago, Al_Nafuur said:

What ROM is it?

I think it was some real PacMan cart ...But that shouldn't matter, right ? when the address bus has A12 set, the direction of the data should always be from cart to console, or ?

[+Al_Nafuur]

6 minutes ago, Kroko said:

I think it was some real PacMan cart ...But that shouldn't matter, right ? when the address bus has A12 set, the direction of the data should always be from cart to console, or ?

$1FF9 might be a banking hotspot here and it might be touched with STA? 🤷‍♂️

 

But anyway DIR is set with the address and the data to be written, so they should change all at the same time (data with ~7ns delay because of the LS)

[+Al_Nafuur]

1 hour ago, Kroko said:

One question, I got this bus recording:

the "DIR" of the databus was surprising for me, because when I look at the address bus, I can not see why it should reverse the databus direction while $1002 or $1FF9 is on the address bus ...

12 minutes ago, Al_Nafuur said:

$1FF9 might be a banking hotspot here and it might be touched with STA? 🤷‍♂️

It is indeed a "STA $FFF9" at $1000 there is a $8d -> STA, $1001 and $1002 are the address ($FFF9)