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

[+Al_Nafuur]

3 minutes ago, MarcoJ said:

It just occurred to me that some bankswitching schemes write to the TIA space to change banks, such as 3E+. @Al_Nafuur I’m not in front of the code but does the driver currently write TIA requests onto the bus, or does it just write them into Stella’s internal TIA?

The driver writes peeks from TIA/RIOT and all pokes to TIA/RIOT on the bus (address & data).

[+Al_Nafuur]

🤔

https://matthewarcus.wordpress.com/2018/01/27/using-the-cycle-counter-registers-on-the-raspberry-pi-3/

 

[Thomas Jentzsch]

8 hours ago, Al_Nafuur said:

If it is a read/write to the TIA or RIOT it is on the cartridge port a "write" to the cartridge too.

Why would a read from TIA/RIOT become a write to the cartridge?

[DirtyHairy]

5 hours ago, Al_Nafuur said:

https://matthewarcus.wordpress.com/2018/01/27/using-the-cycle-counter-registers-on-the-raspberry-pi-3/

That't the one that I saw initially and that I couldn't find yesterday evening. It gives the corresponding instructions for arm32. However, there is a small flaw: the function on the post only reads the lower 32bit word. The counter is 64 bit wide, and you can use MRRC to transfer both words.

[DirtyHairy]

6 hours ago, MarcoJ said:

This would be my second guess to why writes sometimes get corrupted. I tried rewriting the Poke function to include the nop delay inline with the write function, rather than waiting for the next time it’s called. It seemed to make no difference. If there is unstable data on the cart side of the driver IC this could explain why data gets corrupted. I wonder if some light termination on the cart bus side could help or shortening of data bus wiring.

My thoughts exactly. I am not sure what happens on a read from a write location on a real VCS, either. No one is driving the bus, and I would assume that most of the time the bus holds the last value. I guess the driver chip behaves differently than a real 6502 bus. Electronics is not my strong side, but would an array of pulldowns help? That would put the bus in a well-defined state if noone is driving it.

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

Why would a read from TIA/RIOT become a write to the cartridge?

For a cartridge connected to a 2600 there are no read and writes, just addresses and data appearing "magically" on the bus. Who has put them there is totally unknown to the cartridge.

[Thomas Jentzsch]

12 minutes ago, Al_Nafuur said:

For a cartridge connected to a 2600 there are no read and writes, just addresses and data appearing "magically" on the bus. Who has put them there is totally unknown to the cartridge.

Yes, but why does that trigger a wait? Or do we have to care for that data on the bus? I mean, the addresses are outside any cart's RAM address range, so the data will get lost anyway. Only the address is relevant, no?

[JetSetIlly]

@Al_Nafuur Is the Aardvark video that you posted on Sept 19th, typical of what is happening currently, or have things moved on?

[+MarcoJ]

45 minutes ago, JetSetIlly said:

Is the Aardvark video that you posted on Sept 19th, typical of what is happening currently, or have things moved on?

As far as I know this is fixed. Previously 16 bit addresses being cobbled into the GPIO bit bang operation were nobbling 3 data bus bits. Masking address to 12 bits fixed it. Typically happened on carts using "$F000" instead of "$1000" as its reset vector, or carts using other look up ROM table addresses and using them onto the address bus. The former crashed on startup, the latter had odd bugs (such as Aardvark).

[+MarcoJ]

3 hours ago, DirtyHairy said:

My thoughts exactly. I am not sure what happens on a read from a write location on a real VCS, either. No one is driving the bus, and I would assume that most of the time the bus holds the last value. I guess the driver chip behaves differently than a real 6502 bus. Electronics is not my strong side, but would an array of pulldowns help? That would put the bus in a well-defined state if noone is driving it.

The other thing that is different is the signalling voltages. Carts are almost exclusively expecting/giving 5V signals at the cart, whereas flash devices such as Uno and Plus are 3.3V. I'm not sure about Melody or Harmony if they are 3.3V or 5V. 3.3V and 5V signalling are meant to be compatible. I don't see why this factor should cause a problem. Especially given that 5 volt to 3.3v conversion is happening flawlessly on cart reads. 

[+MarcoJ]

OK, I'm getting somewhere now. My SC-RAM carts are working now with RTStella. No changes to code. Embarrassing as it is, the angle the cartridge was inserted at in my rig was not optimal and caused the carts to crash at startup. Strangely, it was not affectinting ROM carts. Already have Desert Falcon and Digdug working with a delay of 400. Results will come up soon. 

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

Yes, but why does that trigger a wait? Or do we have to care for that data on the bus? I mean, the addresses are outside any cart's RAM address range, so the data will get lost anyway. Only the address is relevant, no?

Cartridges are doing strange things (like banking) with the data they spot outside of their "originally planned" address area.

[+Al_Nafuur]

1 hour ago, JetSetIlly said:

@Al_Nafuur Is the Aardvark video that you posted on Sept 19th, typical of what is happening currently, or have things moved on?

38 minutes ago, MarcoJ said:

As far as I know this is fixed. Previously 16 bit addresses being cobbled into the GPIO bit bang operation were nobbling 3 data bus bits. Masking address to 12 bits fixed it. Typically happened on carts using "$F000" instead of "$1000" as its reset vector, or carts using other look up ROM table addresses and using them onto the address bus. The former crashed on startup, the latter had odd bugs (such as Aardvark).

The 3 bits only affected the data bus when we were in "write" mode. In read mode the 8 data bits GPIOs shouldn't care if we are trying to change them. 

🤔 But maybe we should bitmask here aswell:

https://github.com/Al-Nafuur/stella/blob/feature/cartridgeport/src/emucore/CartPort.cxx#L165C5-L165C14

 

 

[+MarcoJ]

 

3 minutes ago, Al_Nafuur said:

But maybe we should bitmask here aswell

I suppose it can't hurt  Those 8 bits would be changed soon after from the read operation from the cart?

[+Al_Nafuur]

26 minutes ago, MarcoJ said:

OK, I'm getting somewhere now. My SC-RAM carts are working now with RTStella. No changes to code. Embarrassing as it is, the angle the cartridge was inserted at in my rig was not optimal and caused the carts to crash at startup. Strangely, it was not affectinting ROM carts. Already have Desert Falcon and Digdug working with a delay of 400. Results will come up soon. 

Are you using 64bit or 32bit PiOS ?

 

[+MarcoJ]

2 minutes ago, Al_Nafuur said:

64bit

+ Crystal Castles, and running at nop delay of 200. 

[Thomas Jentzsch]

1 hour ago, Al_Nafuur said:

Cartridges are doing strange things (like banking) with the data they spot outside of their "originally planned" address area.

OK, thanks for the info.

[+MarcoJ]

Testing - Desert Falcon (16k SC-RAM game), Cart Vs PlusCart, determining stability of game with changes to nop delay. Running on a pi 4 with RTStella, with performance governor and Linux scheduler disabled.

 

 

1. PAL Desert Falcon Cartridge

 

nop Delay - 100

Result: Game loads up, but gitches in-game and returns to main menu occasionally. 

 

nop Delay - 200,300,400,500

Result: Game is stable and runs at real time, no glitches noticed.

 

nop Delay - 600 (and up)

Result: Game is stable but has slowdown from the nop delay being too large

 

 

 

2. Desert Falcon (PAL) run from PlusCart

 

nop Delay - 100,200,300

Result: Could not get game to load

 

nop Delay - 400

Result: Game loads, but glitches similarly to a real cart at nop delay of 100

 

nop Delay - 500

Result: Game loads and appears stable, runs at real time.

 

nop Delay - 600

Result: Game loads and appears to be stable, but slows down from nop delay being too long

 

Overall Notes

- In all cases, RTStella needed to be started up to 5 times before successfully starting the cart. If it failed, it would go straight into the debugger. This occurred on all nop settings and when using on PlusCart/Real cartridge.

- When RTStella was restarted the cart was left powered in all cases.

- The nop delays affected the game's speed the same whether a real cart or the PlusCart was used. The difference is whether the game could function at all (yes or no) at the given nop delay for the given cart type.

- At least on the pi4, it seems that somewhere around 500 nop delay is a sweet spot. This is where the game runs at real time, and has the highest chance of running without glitches whether on a flash cart or on a real cart. 600 is too high, slows down the game. 200 is stable for real carts, but the PlusCart could not work at this delay, even if the game was already bootstrapped at a higher nop delay and subsequently set to a lower nop delay for testing(without unpowering the cart). The PlusCart needed around 500 to be stable with this game.

 

Videos

1. 400 nop delay (tested on Real cart).

 

 

 

2. 100 nop delay (tested on Real cart)

 

3. 500 nop delay (tested on PlusCart)

 

 

4. 700 nop delay (tested on PlusCart, although same result on real cart).

 

 

[Thomas Jentzsch]

Thanks! Do all SC carts you have require the same amount of NOP delay?

 

It seems that, while the original carts are quite fast (~1/3..1/2 of 6507 CPU clock), we need a delay which is quite close to 6507 CPU speed for the PlusCart. Thus leaving us only little headroom for other parts of emulation.

 

Questions:

• Has anyone tried to eliminate the ghost peeks like I suggested above? This would increase our headroom.
• Could the PlusCart be improved to work with a shorter delay?
• What could cause the startup problems? I had the idea that the game might start in the wrong bank, but the game's code is prepared for this.

[+stephena]

There may be a way to slightly speed up peek/poke access in the System class.  What kind of budget do we have here?

 

EDIT: Also, the debugger causes some runtime slowdowns.  If you relax the requirement for the debugger (which admittedly, is giving up a lot), then the emulation can run faster.

[+MarcoJ]

1 hour ago, Thomas Jentzsch said:

Do all SC carts you have require the same amount of NOP delay?

Have tested Crystal Castles, Off the Wall, Dig Dug and Desert Falcon and they all work at 200 nop delay. I will leave Desert Falcon overnight in its demo mode and see if it survives.

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

Thanks! Do all SC carts you have require the same amount of NOP delay?

 

It seems that, while the original carts are quite fast (~1/3..1/2 of 6507 CPU clock), we need a delay which is quite close to 6507 CPU speed for the PlusCart. Thus leaving us only little headroom for other parts of emulation.

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!) 

 

1 hour ago, Thomas Jentzsch said:

Questions:

• Has anyone tried to eliminate the ghost peeks like I suggested above? This would increase our headroom.
• Could the PlusCart be improved to work with a shorter delay?
• What could cause the startup problems? I had the idea that the game might start in the wrong bank, but the game's code is prepared for this.

• Not me
• Yes, especially the standard ROM emulation is full of switches for bankings, SC-RAM and other hotspots (PlusROM, exit function..). But I don't think we should aim for a cycle length that is much shorter than the 6502 cycle. Other cartridges and bankings might be affected too. (Harmony, melody, DPC+, CDFJ, CDFJ+, and future bankings that rely on the cycle length of the 6502)
• I suspect the startup memory errors are because the dummy bin file is much smaller than 4K and maybe the debugger tries to access some of it..

[Kroko]

18 hours ago, Thomas Jentzsch said:

Are you sure it writes $0F? Because that's a peek. So how would a peek turn into a poke?

 

I think so because I see $0F read from the cartridge when PC is at the CMP opcode at address $F0A1 so my conclusion is that this is what has been written during the STA when $1021 is on the address bus.
I still need to understand the garbage on the databus during the write cycle ... I guess thats the reason for the glitch. Luckly most likely this has nothing to do with our bus timing ...
 

[Thomas Jentzsch]

2 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!) 

Agreed. Nevertheless Marco's measurements show us how much headroom we will have.

2 hours ago, Al_Nafuur said:

• Not me

Would that work anyway? We would skip one peek to the cart port.

2 hours ago, Al_Nafuur said:

• Yes, especially the standard ROM emulation is full of switches for bankings, SC-RAM and other hotspots (PlusROM, exit function..). But I don't think we should aim for a cycle length that is much shorter than the 6502 cycle. Other cartridges and bankings might be affected too. (Harmony, melody, DPC+, CDFJ, CDFJ+, and future bankings that rely on the cycle length of the 6502)

If they rely on that length and we have to fully comply, this won't work anyway.

2 hours ago, Al_Nafuur said:

• I suspect the startup memory errors are because the dummy bin file is much smaller than 4K and maybe the debugger tries to access some of it..

What dummy bin file?  

[+Al_Nafuur]

26 minutes ago, Thomas Jentzsch said:

 

What dummy bin file?  

CartridgePort.bin

For the detection..