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

[Kroko]

In the first "line" (in white) you see whatever is on the address bus. At +6us we have $1810 on the bus ...which means something went wrong.
In the line below (in yellow) is what is on the databus at that time (on the Raspberry Pi side of the 345 chip)
Line 3 in green is the "DIR" signal for the SN74 345 chip
The 4th line is also the Databus, but on the "Cartridge Side" of the 345 bus driver chip (should in theory be identical to the yellow line)

So when we see an address on the white line and this addres points to some ROM location we should see the opcode on the databus.
During some write, we first see the address of the opcode that does the write on the adress bus and the opcode of the command that is executed on the databus.
Then if we write something you see on the databus, what appears when ... and by looking at that we should be able to figure out why we jumped to the hotspot.
 

Edited October 3, 2023 by Kroko

[Thomas Jentzsch]

Thanks!

And: Oops, looks like I posted before assembling the latest changes. $1810 should be $1830 -> (pointer),Y.

 

Was that the first loop, or did previous ones succeed?

 

Fixed ROM attached.

SC_RAM_Test_V3a.bin

[Kroko]

This is a glitch for Version V3a:

[Thomas Jentzsch]

Same addressing mode. Are all $1830s?

[Kroko]

1 minute ago, Thomas Jentzsch said:

Are all $1830s?

Currently thats all I get. But the logic analyzer stops after it first sees anything above $1800:

So at least the first problem is currently only $1830

[Thomas Jentzsch]

OK, that due to always identical random number sequence. I can add some initial randomization, which waits for user input. What input would you prefer (switches, button...?)

[Kroko]

43 minutes ago, Thomas Jentzsch said:

What input would you prefer (switches, button...?)

I don't care. Just tell me what to do in Stella to change it. Whatever is convenient for you.

[+MarcoJ]

Did some testing with a PAL Ms PacMan Cart today (a 16k SC game 8K game)

 

It was tested with nop delays of 50,100,200,300,400 and 1000. Surprisingly, the game was stable for all of the settings. At 1000, the gameplay was choppy due to the game slowing down from excess delay, but otherwise ran OK.

 

With "50" nop delay, performance governor, scheduler disabled

 

With "1000" nop delay, performance governor, scheduler disabled

 

 

 

 

 

[Thomas Jentzsch]

19 minutes ago, Kroko said:

I don't care. Just tell me what to do in Stella to change it. Whatever is convenient for you.

OK, press fire.  

SC_RAM_Test_V4.bin

[+MarcoJ]

19 hours ago, Kroko said:

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

It is difficult to get any SC-RAM carts working today. I just posted Ms Pacman, but it's actually only a ROM cart. I previously had Super Football (16k SC-RAM) working with "1000" nop delay, but it's not playing ball (pun intended). 

[Thomas Jentzsch]

1 minute ago, MarcoJ said:

It is difficult to get any SC-RAM carts working today. I just posted Ms Pacman, but it's actually only a ROM cart. I previously had Super Football (16k SC-RAM) working with "1000" nop delay, but it's not playing ball (pun intended). 

Like I said before, we probably need a slower timing for SC access. It looks like we can "overclock" ROM access, but not SC-RAM access.

[Kroko]

18 minutes ago, Thomas Jentzsch said:

OK, press fire.  

SC_RAM_Test_V4.bin 8 kB · 1 download

And still: $1830

[Thomas Jentzsch]

Always?

[Kroko]

2 minutes ago, Thomas Jentzsch said:

Always?

I did not see anything else up to now. Could this mean all works fine except for whatever you do before accessing $1830 ?

[Thomas Jentzsch]

22 minutes ago, Kroko said:

Could this mean all works fine except for whatever you do before accessing $1830 ?

Maybe.

 

This is what the 6507 code is doing:

; ptrW = $f000, ptrR = $f080
  sta (ptrW),y
  cmp (ptrR),y

 

And Stella does:

  uInt8 pointer = peek(PC++, DISASM_CODE);
  const uInt16 low = peek(pointer++, DISASM_DATA);
  const uInt16 high = (static_cast<uInt16>(peek(pointer, DISASM_DATA)) << 8);
  peek(high | static_cast<uInt8>(low + Y), DISASM_NONE);
  operandAddress = (high | low) + Y;
  poke(operandAddress, A, DISASM_WRITE);
  
----------------------------------------------------------------------------------------------

  uInt8 pointer = peek(PC++, DISASM_CODE);
  const uInt16 low = peek(pointer++, DISASM_DATA);
  const uInt16 high = (static_cast<uInt16>(peek(pointer, DISASM_DATA)) << 8);
  intermediateAddress = high | static_cast<uInt8>(low + Y);
  if((low + Y) > 0xFF)
  {
    peek(intermediateAddress, DISASM_NONE);
    intermediateAddress = (high | low) + Y;
    operand = peek(intermediateAddress, DISASM_DATA);
  }
  else // here always else!
  {
    operand = peek(intermediateAddress, DISASM_DATA);
  }
  const uInt16 value = static_cast<uInt16>(A) - static_cast<uInt16>(operand);
  notZ = value;
  N = value & 0x0080;
  C = !(value & 0x0100);

 

So, does the write and/or the read fail?

Edited October 3, 2023 by Thomas Jentzsch

[+MarcoJ]

35 minutes ago, Thomas Jentzsch said:

It looks like we can "overclock" ROM access, but not SC-RAM access.

Have tried settings like 2000 and 3000 with no success. I question CartridgePort::poke function's efficacy. With E7 games, at least on PlusCart with optimal RAM write timing, games I test eventually glitch out, no matter the nop delay. I'm currently trying some changes to the function and testing them out.

[DirtyHairy]

Sorry, I was mostly afk the last few days. Regarding 64bit vs. 32bit: after looking at some benchmarks, I am not as convinced as I was before that 64bit is a good idea. Sticking with aarch32 is definitely an option, and the performance counter can be used there just as well, with minor differences in setup. I'll order another SD card and set it up for 32bit.

 

[Kroko]

2 hours ago, Thomas Jentzsch said:

So, does the write and/or the read fail?

What happened is this:

                                              (sta     (ptrW),y)
$11AA   : $91 (STA ind y opcode)              PC        (fetch opcode , increment PC)
$11AB   : $82                                 PC        (fetch pointer address, increment PC)
$0082   : $00                                 pointer   (fetch effective address low)
$0083   : $F0                                 pointer+1 (fetch effective address high, add Y to low byte of effective address) Y = 33/$21
$1021   : $0F                                 address+Y (read from effective address, fix high byte of effective address)
$1021   : $21                                 address+Y (write to effective address)
                                              (cmp     (ptrR),y)
$F1AC   : $D1 (CMP ind y opcode)              PC        (fetch opcode , increment PC)
$F1AD   : $84 (read target address from here) PC        (fetch pointer address, increment PC)
$0084   : $80 (Hi-Byte of $F080)              pointer   (fetch effective address low)
$0085   : $F0 (Lo-Byte of $F080)              pointer+1 (fetch effective address high, add Y to low byte of effective address) Y = 33/$21
$F0A1   : first $4C after 330ns $0F           address+Y (read from effective address, fix high byte of effective address) (The high byte of the effective address may be invalid at this time, i.e. it may be smaller by $100)
                                              (beq     .loop)
$F1AE   : $F0 (BEQ)                           PC        (fetch opcode , increment PC )
$F1AF   : $8C ??                              PC        (fetch operand, increment PC)
$F1B0   : $8D (STA Opcode)                    PC        (Fetch opcode of next instruction, if branch is taken ...) ((sta     $f830))
$F1B1   : $30 (Lo-Byte of address)
$F1B2   : $F8 (Hi-Byte of address)    

 

The Cart does in this case write $0F into RAM but should have written $21. Thats why you jump to the glitch hotspot.

I need to understand why the cycle at $1021 looks like this ... maybe its more a problem of the cart than the console. Need to think about it, because the write cycle looks correct to me.

[Thomas Jentzsch]

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

 

[Thomas Jentzsch]

@Al_Nafuur At the end of CartPort.peek() there is "lastAccessWasWrite = true;". Shouldn't that be a "false"?

 

[DirtyHairy]

18 minutes ago, Kroko said:

Need to think about it, because the write cycle looks correct to me.

What's the oscillating mess on the purple line at the beginning of the write cycle on the cart side of the SN74?? Seems it takes almost 0.5us until the data bus is stable after DIR has changed.

[+Al_Nafuur]

24 minutes ago, Thomas Jentzsch said:

@Al_Nafuur At the end of CartPort.peek() there is "lastAccessWasWrite = true;". Shouldn't that be a "false"?

 

If it is a read/write to the TIA or RIOT it is on the cartridge port a "write" to the cartridge too. The "lastAccessWasWrite" flag is only to exit early and let Stella do its thing and then check at the next peek/poke if we may have to wait for the cart to read/peek the data (e.g. for banking). That's why a timer is better than a delay, because with a time we would only wait the remaining time before the next cycle.  

[+mksmith]

This is a fascinating discussion going on here - well done everyone for your contributions 👌

[+MarcoJ]

1 hour ago, DirtyHairy said:

What's the oscillating mess on the purple line at the beginning of the write cycle on the cart side of the SN74?? Seems it takes almost 0.5us until the data bus is stable after DIR has changed.

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.

Edited October 3, 2023 by MarcoJ

[+MarcoJ]

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?