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

[Thomas Jentzsch]

4 minutes ago, Kroko said:

This is new to me. Where do you have this info from ? As far as I can tell, the SARA Ram provides a valid output 400ns after stabilization of the address bus.
I came a cross this statement several times now, but I doubt that the SARA Ram is really that slow. Has anybody done measurements on RAM response time in Superchip Cartridges ?

It has been discussed (e.g. IIRC @SvOlli) that SC-RAM is too slow for code execution. IMO that means that single cycle access does not work. Or am I wrong here?

[Kroko]

4 hours ago, Al_Nafuur said:

5 hours ago, Thomas Jentzsch said:

Who cares? We are not executing anything.

But the cartridge..

I think the cartridge wouldn't care, too. It could have had the same state directly after power up. Whatever state we may create by peeking its memory ..its not a state that it may not possibly have after power on anyway.
So Thoma's point is, that whatever we do before we jump to the reset vector is not relevat, because the cart needs to recover from everything we may have done to it before that time.

[Kroko]

10 minutes ago, Thomas Jentzsch said:

Or am I wrong here?

We need to ask the guy who told you that it is too slow What kind of crappy RAM should this be ... that can not set its output within 400ns ? Maybe the statement that it is impossible to run code in SC Ram is correct, but probably not because of slow response times, but because of som RC-circuitry that is not charged or discharged fast enough to handle several RAM accesses in a row... I would love to talk to the guy who measured SC-RAM repsonse time to sort this out.

Edited October 2, 2023 by Kroko

[+Al_Nafuur]

23 minutes ago, Kroko said:

This is new to me. Where do you have this info from ? As far as I can tell, the SARA Ram provides a valid output 400ns after stabilization of the address bus.
I came a cross this statement several times now, but I doubt that the SARA Ram is really that slow. Has anybody done measurements on RAM response time in Superchip Cartridges ?

We haven't done any real measurements, but @MarcoJ had to increase the NOP delay loop to get a real SC-RAM cartridge to work. I don't have a real SC-RAM cartridge here to test, but I am currently in contact with a local seller to buy a PAL Pitfall-II and a Millipede cartridge.

[Kroko]

10 hours ago, Al_Nafuur said:

So if SC-RAM and some bankings (FA?) need these ghost writes

I think to be 100% compatible to everything (which might be our goal I guess) we do need to emulate the bus lines 100% correctly. If you look at some 6502 instruction only from the consoles point of view and what it intends to achieve, you might not be interested so much in what the 6502 actually does during a multi cycle instruction. All you care for is the result. But even though you don't really care what the 6502 does on the bus, it is still important to the cartridge. All existing real bankswitching carts have to deal with that bus action. Most of the time the cartridge does not "need" to see all the intermediate stuff that is happening on the bus during an instruction, but it has to be tolerant to it. And thank god there are very few bankswitching schemes that actively need the whole bus action to work properly. My suspicion is still that FE Bankswitching is one of them, but we can sort that out later. Another thing that most real cartridges can not ignore is that in an indexed write across a page boundary, the wrong page appears on the bus for one cycle and may corrupt the data in that page, because this might be accidentally hitting the write port. Now if we don't emulate that, it would only be a problem if someone decided in a real cartridge to use that incorrect intermediate address for something. I am not aware that this is the case. But I fear that there might be some cartridges out there where some hotspot is only seen on the bus, because of the "intermediate" addresses that appear on the bus. In that case we will not be able to run them correctly if we don't do the same on the bus as the 6502 is doing in the real console.

We could just learn by try and error what we need to emulate to get all existing stuff to work. I hope it won't be too much ... certainly not all bus action. The rest we could happily ignore until we find a way to emulate all of it.

[+MarcoJ]

2 hours ago, Al_Nafuur said:

We haven't done any real measurements, but @MarcoJ had to increase the NOP delay loop to get a real SC-RAM cartridge to work

This has been true also for SC games when run through a flash cart(eg Aardvark). I will compare apples for apples later today, real cart vs flash cart. I have a feeling the console-cart write cycle causes this rather than the RAM inside. 

[+MarcoJ]

16 minutes ago, Kroko said:

We could just learn by try and error what we need to emulate to get all existing stuff to work.

It’s close. I’ve had StrategyX running for a day now without crashes (non RAM cart). I suspect there is a small nuance we are missing for RAM cart games. I can get them running but with nop delays much greater, however they glitch or crash for me within minutes no matter the delay. 

[Kroko]

44 minutes ago, MarcoJ said:

I can get them running but with nop delays much greater, however they glitch or crash for me within minutes no matter the delay.

Is it also glitching for RAM carts programmed on Flash Cartridges or only for the real ones ? Or ... no difference ? If the glitch is also happening on flash carts, then we could watch what has happened before or at the glitch. So we know what exactly caused the issue ...

[+MarcoJ]

5 minutes ago, Kroko said:

Is it also glitching for RAM carts programmed on Flash Cartridges or only for the real ones ?

Happening for both flash and real carts. I’ll do some testing later today for real and flash emulated carts. 

[Kroko]

1 minute ago, MarcoJ said:

Happening for both flash and real carts.

Then we could display what happened on the bus (timing wise) whenever a glitch happens, right ? We "just" need a .bin that can write and read RAM cells and then checks if the write or read was ok or not. In case it was ok => do nothing. If it glitched: write to a hotspot. That way I could let the logic analyser trigger on that hotspot and show the bus for the cycles that are close to the glitch. Or do you know a better way to find the reason for the glitch ?

[Thomas Jentzsch]

If you give me the hotspot, I can write something.

[Kroko]

5 hours ago, Thomas Jentzsch said:

If you give me the hotspot, I can write something.

I was hoping you would say that . But lets wait until we really need it. I feel it may be the only way to debug the bus. How much effort is this for you ?

Actually you could choose any hotspot you like that is not seen on the bus in "Normal operation"... anything that you would not jump to as long as the memory operation is fine would be ok. You could jump to different hotspots if different things go wrong: like to $1A00 on "read error after normal write" and $1AF0 on "read error after indexed write" etc.

There is another difficulty: It is interesting to follow all the things you try to make stella cart driver better, but I won't be able to reproduce any of your stella versions unless you put them to a branch for me (or give me some commit) that I can fetch and build. (preferably 32 bit PiOS)

As long as the guys working on the cartridge driver don't need it, I would not invest the time. But it is certainly a way to actually see what is going wrong instead of guessing or "assuming" that something goes wrong that may actually be perfectly fine.

[Thomas Jentzsch]

1 hour ago, Kroko said:

I was hoping you would say that . But lets wait until we really need it. I feel it may be the only way to debug the bus. How much effort is this for you ?

Not much, 1h or so.

1 hour ago, Kroko said:

Actually you could choose any hotspot you like that is not seen on the bus in "Normal operation"... anything that you would not jump to as long as the memory operation is fine would be ok. You could jump to different hotspots if different things go wrong: like to $1A00 on "read error after normal write" and $1AF0 on "read error after indexed write" etc.

OK. So you want an F8SC ROM which operates from $1000..$10ff and peeks(?)/pokes(?) (depending on the result) somewhere at $1100..$1fff?

1 hour ago, Kroko said:

There is another difficulty: It is interesting to follow all the things you try to make stella cart driver better, but I won't be able to reproduce any of your stella versions unless you put them to a branch for me (or give me some commit) that I can fetch and build. (preferably 32 bit PiOS)

As long as the guys working on the cartridge driver don't need it, I would not invest the time. But it is certainly a way to actually see what is going wrong instead of guessing or "assuming" that something goes wrong that may actually be perfectly fine.

That something for @Al_Nafuur or @DirtyHairy I suppose.

Edited October 3, 2023 by Thomas Jentzsch

[Thomas Jentzsch]

The attached F8SC ROM writes random values to random SC addresses and then compares the written value with what gets read. If the values differ, it writes to $f800,y where Y is the offset into SC RAM. 

 

The test code is dead simple:

.loop
    jsr     NextRandom
    and     #$7f
    tay
    jsr     NextRandom
    sta     $f000,y
    cmp     $f080,y
    beq     .loop
    sta     $f800,y		; error!
    sta	    COLUBK		; some visible output
    bne     .loop

@Kroko Please let me know if that's what you are looking for.

 

SC_RAM_Test V1.bin

[+Al_Nafuur]

2 hours ago, Kroko said:

There is another difficulty: It is interesting to follow all the things you try to make stella cart driver better, but I won't be able to reproduce any of your stella versions unless you put them to a branch for me (or give me some commit) that I can fetch and build. (preferably 32 bit PiOS)

As long as the guys working on the cartridge driver don't need it, I would not invest the time. But it is certainly a way to actually see what is going wrong instead of guessing or "assuming" that something goes wrong that may actually be perfectly fine.

I think 64 bit is the better choice, but currently I can't get the 64bit version CartPort running on my setup. Even installing on a fresh SD-Card didn't worked. I tested the 32bit SD-Card and it still works.

 

36 minutes ago, Thomas Jentzsch said:

The attached F8SC ROM writes random values to random SC addresses and then compares the written value with what gets read. If the values differ, it writes to $f800,y where Y is the offset into SC RAM. 

 

The test code is dead simple:

.loop
    jsr     NextRandom
    and     #$7f
    tay
    jsr     NextRandom
    sta     $f000,y
    cmp     $f080,y
    beq     .loop
    sta     $f800,y		; error!
    sta	    COLUBK		; some visible output
    bne     .loop

@Kroko Please let me know if that's what you are looking for.

 

SC_RAM_Test V1.bin 8 kB · 0 downloads

maybe using a fixed hotspot is better:

	sta $f800

You can write the failed address to a second hotspot:

	sty $f801

 

To make the thing more visual you also might write the two values to player0 and player1.

 

But we can trap $f800 in Stella and then check A and Y. So we @MarcoJ and I can use this ROM to debug SC RAM with out a logic analyzer.

 

[Thomas Jentzsch]

OK, attached.

SC_RAM_Test V2.bin

[Kroko]

34 minutes ago, Al_Nafuur said:

So we @MarcoJ and I can use this ROM to debug SC RAM with out a logic analyzer.

Hmm... if your code gets interrupted (I assume this is still possible in non RT PiOS), how do you know how the bus looked like for the cartridge ? You would know what address it was and what value you had trouble with, but would you see how the address lines behaved during a glitch ?

[Kroko]

1 hour ago, Thomas Jentzsch said:

@Kroko Please let me know if that's what you are looking for.

Cool ! Thats exactly what I wanted. I think a fixed address like LDA $F800 should be best. So we can just trigger on each error and see what it was.
Currently you are only checking indexed writes, right ? Maybe we should also check normal writes to the write port or in general all different memory writing techniques that we know of.

[Kroko]

2 hours ago, Thomas Jentzsch said:

That something for @Al_Nafuur or @DirtyHairy I suppose.

Any chance I can get a  commit that works out of the box for 32Bit PiOS ? My 64Bit PiOS is a nightmare on the 3B+. Maybe its good for the Pi4 or Pi5 but for me I would rather stick to 32Bit for now.
Can't wait to make a first measurement with Thomas' rom....

[+Al_Nafuur]

25 minutes ago, Kroko said:

Any chance I can get a  commit that works out of the box for 32Bit PiOS ? My 64Bit PiOS is a nightmare on the 3B+. Maybe its good for the Pi4 or Pi5 but for me I would rather stick to 32Bit for now.
Can't wait to make a first measurement with Thomas' rom....

I strongly recommend to increase the swap file. I added a link to the howto yesterday 

[Thomas Jentzsch]

19 minutes ago, Kroko said:

Cool ! Thats exactly what I wanted. I think a fixed address like LDA $F800 should be best. So we can just trigger on each error and see what it was.
Currently you are only checking indexed writes, right ? Maybe we should also check normal writes to the write port or in general all different memory writing techniques that we know of.

Yes, only indexed writes. But I can add more, no big problem.

 

Do we also need combinations? Like an indexed write which is verified with an absolute read? Or would that be overkill for now?

Edited October 3, 2023 by Thomas Jentzsch

[Kroko]

1 hour ago, Thomas Jentzsch said:

Do we also need combinations?

We should test everything that we think is probably failing for the emulated bus cycle. Lets start easy and play with what we have. The point is ... if we know that indexed writes work, then we don't necessarily know that normal writes are working too. And if there are specific tricks to write to or read from SC Ram with
not so obvious instructions (you know better than me if such things are existing) then we should probably test that as well...

I could make a test with Al-Nafuurs last commit on feature/cartridgeport (from 8 days ago). Does that make sense or do we have something else I should test ?

[Thomas Jentzsch]

The attached ROM does:

• absolute,Y write/read with ghost peeks (value: $f800, <address: $f801)
• (pointer),Y  write/read with ghost peeks ($f810, $f811)
• absolute,Y write/read ($f820, $f821)
• (pointer),Y write/read ($f830, $f831)
• absolute write/read ($f840, $f841) 

SC_RAM_Test_V3.bin

Edited October 3, 2023 by Thomas Jentzsch

[Kroko]

First screenshot of a glitch triggering hotspots:

[Thomas Jentzsch]

1 minute ago, Kroko said:

First screenshot of a glitch triggering hotspots:

Can you explain for dummies?