Jump to content
IGNORED

2600 Flash Cart / Multi-Cart Comparison Matrix


bigmessowires

Recommended Posts

2 minutes ago, Thomas Jentzsch said:

Got you.

 

I figure if the ARM code should take longer than 4096*2 6502 cycles (~450,000 ARM cycles), one could split this execution into multiple slices, right?

Yes, this is what I do.  I use the ARM timer to figure out how many cycles of ARM have been used, and abort back to servicing the BUS if the VB or OS time are close to expiring. It's not as nice as having a separate CPU to do ARM stuff, but it's functional enough if you structure your systems to work in discrete chunks like we did in BD.

Link to comment
Share on other sites

3 minutes ago, Thomas Jentzsch said:

Got you.

 

I figure if the ARM code should take longer than 4096*2 6502 cycles (~450,000 ARM cycles), one could split this execution into multiple slices, right?

Yes. Or set the 6507 to execute from VCS RAM and take as long a slice as you want.

  • Like 1
Link to comment
Share on other sites

4 minutes ago, Thomas Jentzsch said:

Got you.

 

I figure if the ARM code should take longer than 4096*2 6502 cycles (~450,000 ARM cycles), one could split this execution into multiple slices, right?

And technically it's not 4096 -- it's 0xFFFF - the 6507 address where you switched to the EA-halt. In other words, this is why you put the EA-halt as early in the 6507 address space as you comfortably can. It gives your ARM code more time to do stuff.

Link to comment
Share on other sites

2 minutes ago, Andrew Davie said:

And technically it's not 4096 -- it's 0xFFFF - the 6507 address where you switched to the EA-halt. In other words, this is why you put the EA-halt as early in the 6507 address space as you comfortably can. It gives your ARM code more time to do stuff.

But you only have 4096 addresses before you hit non-cartridge addresses, no matter where you position the PC. Place it at 0x1000 and you hit a TIA address at 0x2000

Link to comment
Share on other sites

Just now, JetSetIlly said:

But you only have 4096 addresses before you hit non-cartridge addresses, no matter where you position the PC. Place it at 0x1000 and you hit a TIA address at 0x2000

I'm saying that if your PC is very close to the end of the address space when you trigger the EA-wait (say, at 0xFF00 equivalent) then you have bugger-all time to do ARM stuff. Effectively only 256 "nops" before you wrap and hit address 0 and "carnage".  If your PC is close to the start of address space (0xF000 equivalent) then you have 4096 before carnage. So it does matter where you are (in PC terms) when you trigger the EA-wait.

  • Like 1
Link to comment
Share on other sites

8 minutes ago, Thomas Jentzsch said:

I figure if the ARM code should take longer than 4096*2 6502 cycles (~450,000 ARM cycles), one could split this execution into multiple slices, right?

 

2 minutes ago, JetSetIlly said:

But you only have 4096 addresses before you hit non-cartridge addresses, no matter where you position the PC. Place it at 0x1000 and you hit a TIA address at 0x2000

If my calcs are correct, that's around 7 milliseconds, about half a frame. Should be enough time to process during a full Vblank or Overscan cycle. Assuming normal game operation that should be fine, right? 

Link to comment
Share on other sites

1 minute ago, Andrew Davie said:

I'm saying that if your PC is very close to the end of the address space when you trigger the EA-wait (say, at 0xFF00 equivalent) then you have bugger-all time to do ARM stuff. Effectively only 256 "nops" before you wrap and hit address 0 and "carnage".  If your PC is close to the start of address space (0xF000 equivalent) then you have 4096 before carnage. So it does matter where you are (in PC terms) when you trigger the EA-wait.

Oh I see what you mean. Yes. CALLFN should ideally be triggered close to the start of the cartridge mirror addresses.

  • Like 1
Link to comment
Share on other sites

5 minutes ago, MarcoJ said:

 

If my calcs are correct, that's around 7 milliseconds, about half a frame. Should be enough time to process during a full Vblank or Overscan cycle. Assuming normal game operation that should be fine, right? 

Mostly. Depends on how busy you keep the ARM in that side of the code :).  For reference, I use a timer on each of VB and OS to let me know exactly how many cycles I have available before I need to return and service the BUS.  For me (262 scanlines), keeping in mind I have a bit of slack in there just to make it easier to manage I have VB with about 120K ARM cycles, and OS with about 100K ARM cycles.

 

EDIT: you can do an awful lot in that amount of time :)

 

  • Like 1
Link to comment
Share on other sites

8 minutes ago, Andrew Davie said:

Yes, I expect most ARM games are basically 6507 display kernels and calls to ARM code.

Yes. One thing i'd like to do is get the sprite positioning, key scanning and other overhead functions to be done in RIOT RAM whilst ARM code is executing; another maybe 8 scanlines worth of bulk processing time. 

Link to comment
Share on other sites

Just now, MarcoJ said:

Yes. One thing i'd like to do is get the sprite positioning, key scanning and other overhead functions to be done in RIOT RAM whilst ARM code is executing; another maybe 8 scanlines worth of bulk processing time. 

Sounds like you need to write more efficient C-code ;)

  • Haha 1
Link to comment
Share on other sites

On 1/26/2023 at 4:15 AM, Thomas Jentzsch said:

I figure if the ARM code should take longer than 4096*2 6502 cycles (~450,000 ARM cycles), one could split this execution into multiple slices, right?

 

I suggested something to @tschak909 a while back to idle the 6502 while his ESP32 starts up when the 2600 was turned on. Don't know if he tried it, but it was basically to immediately put $11 on the bus to idle the 6507. The 6507 start up sequence of JMP (RESET) would set the PC to $1111. From then on it would execute ORA($11),y until the ESP32 finished its init sequence, at which point the ESP32 would put NOP, JMP(RESET) on the bus so the 6507 could do a proper power-on sequence.

 

Modifying CDFJ to idle the 6507 with $11 instead of $EA while the custom ARM code runs would give you more ARM time before the PC advances past $FFFF because ORA($11),y takes 5+ cycles instead of 4 cycles for every 2 bytes the PC advances. I think that'd be ~562,000 ARM cycles.

 

It does make the 6507 recovery 1 byte longer, instead of putting JMP xxxx on the bus to restore the PC you'd need to put NOP, JMP xxxx. It would also modify the value of A, which using $EA does not.

Link to comment
Share on other sites

14 minutes ago, Thomas Jentzsch said:

While stop at 5+ cycles? Illegal opcodes can take up to 8 cycles (e.g. SLO(zp),y or SLO(zp,x)).

 

Great idea.  

 

My idea of $11 for the ESP32 was because it would make the 6507's initial JMP (RESET) end up as early in the cartridge address space as possible. $10 would be a page earlier, but BPL would not be useful; while $0x would put the 6507 outside of the cartridge address space, most likely crashing the console.

 

 

 

Link to comment
Share on other sites

4 minutes ago, SpiceWare said:

My idea of $11 for the ESP32 was because it would make the 6507's initial JMP (RESET) end up as early in the cartridge address space as possible. $10 would be a page earlier, but BPL would not be useful; while $0x would put the 6507 outside of the cartridge address space, most likely crashing the console.

Then SLO (zp),y ($13) would be the best option here.

  • Like 1
Link to comment
Share on other sites

10 minutes ago, Thomas Jentzsch said:

Then SLO (zp),y ($13) would be the best option here.

Note that for either of these options to work, you’ll have to weakly drive the bus with pull-up/pull-down resistors because otherwise the accesses outside of cartridge space will cause bus contention. 

  • Like 1
Link to comment
Share on other sites

1 hour ago, SpiceWare said:

 

I suggested something to @tschak909 a while back to idle the 6502 while his ESP32 starts up when the 2600 was turned on. Don't know if he tried it, but it was basically to immediately put $11 on the bus to idle the 6507. The 6507 start up sequence of JMP (RESET) would set the PC to $1111. From then on it would execute ORA($11),y until the ESP32 finished its init sequence, at which point the ESP32 would put NOP, JMP(RESET) on the bus so the 6507 could do a proper power-on sequence.

 

Modifying CDFJ to idle the 6507 with $11 instead of $EA while the custom ARM code runs would give you more ARM time before the PC advances past $FFFF because ORA($11),y takes 5+ cycles instead of 4 cycles for every 2 bytes the PC advances. I think that'd be ~562,000 ARM cycles.

 

It does make the 6507 recovery 1 byte longer, instead of putting JMP xxxx on the bus to restore the PC you'd need to put NOP, JMP xxxx. It would also modify the value of A, which using $EA does not.

Also there is talk of having a Piccolo handle the startup. I need to clean up schematics and send them to the team but haven’t gotten to that yet. But if the Fuji has a piccolo board then it would also natively support the same games. 

Link to comment
Share on other sites

1 hour ago, batari said:

Note that for either of these options to work, you’ll have to weakly drive the bus with pull-up/pull-down resistors because otherwise the accesses outside of cartridge space will cause bus contention. 

How is that different to using $ea?

Link to comment
Share on other sites

12 minutes ago, splendidnut said:

In both cases, ARM is outputting data onto the cartridge data bus.  With $EA, the processor is only reading from the cartridge area.  If you use an instruction that attempts to read from RAM/TIA space, you'll have bus contention between that and the ARM.

I figure this is a problem. Unfortunately the probably more feasible alternatives like e.g. SLO abs,y ($1B, 7 cycles) all have a pretty high low nibble. Using $ea seems to make sense to me now. :) 

Link to comment
Share on other sites

1 hour ago, splendidnut said:

In both cases, ARM is outputting data onto the cartridge data bus.  With $EA, the processor is only reading from the cartridge area.  If you use an instruction that attempts to read from RAM/TIA space, you'll have bus contention between that and the ARM.

I've probably been staring at old arcade schematics for too long but it seems like something like this might be solvable in hardware by tying an address line to a bus transceiver to disconnect the ARM when the 6507 is accessing RAM/TIA space.

 

I'm not even sure if we're talking about existing hardware or new hardware at this point, though. ;)

Edited by Ben_Larson
Link to comment
Share on other sites

OR together A0 and A1 using a couple of transistors, then connect the result through a resistor to D4 to drive it weakly. Have the MCU drive 010z1100 onto the data bus, leaving D4 to be driven by the OR. At reset, the 6507 will fetch the reset vector from $FFFC and find a vector of $5C4C which is in the cartridge space. At $5C4C it will read the instruction JMP $5C5C. At $5C5C it will read the instruction JMP $5C5C, so it will be stuck in a loop forever until the MCU changes the data bus. The 6507 will never drive the data bus or access any address outside of cartridge address space.

  • Like 1
Link to comment
Share on other sites

1 hour ago, bigmessowires said:

OR together A0 and A1 using a couple of transistors, then connect the result through a resistor to D4 to drive it weakly. Have the MCU drive 010z1100 onto the data bus, leaving D4 to be driven by the OR. At reset, the 6507 will fetch the reset vector from $FFFC and find a vector of $5C4C which is in the cartridge space. At $5C4C it will read the instruction JMP $5C5C. At $5C5C it will read the instruction JMP $5C5C, so it will be stuck in a loop forever until the MCU changes the data bus. The 6507 will never drive the data bus or access any address outside of cartridge address space.

The JMP instruction is $4C (or $6C for indirect) but both addresses $4C4C or $6C6C are not in the ROM mirror area..

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...