Flashback2 bus behaviour vs 2600

[+rbairos]

Diving deep into a hardware project that I intend to be compatible with FB2 as well as stock 2600, but came across an issue:

In  the stock 2600, if you  execute lda swcha for example, the RIOT will present the joystick results on the bus data lines for a cycle.
Similarly if I STA into an address, the bus data contain the contents of A for a cycle on real hardware for a cycle.

Is it not the same for the FB2 ?
Before I dig deeper into it, anybody know the answer?

My backup plan for sniffing out the input values is encoding them into the address lines the 6507 fetches, which is slow and a pain to be honest.

Thanks.
 

[Thomas Jentzsch]

Why do you want to be compatible with incompatible hardware?

[+rbairos]

37 minutes ago, Thomas Jentzsch said:

Why do you want to be compatible with incompatible hardware?

I love developing on it, as it takes up a small footprint on my desk and connects to a mini LCD easily.
Many people on this forum also have modded FB2s which still accept a wide selection of carts, so all things equal the more systems I make MovieCart2 work on, the better.



 

[+rbairos]

Also I'm now extreeeemely curious how/if UnoCart / Harmony / PlusCart etc communicate joystick data back to the cart microcontroller on an FB2.
I'm suspecting its something like:

LDX swcha
STA reservered_memory, X       

Then it monitors for address requests in a 256 address range in reserved_memory.

 But if FB2 data-lines are write-only, it means extended RAM chips and even bus stuffing wouldn't work I'm guessing.

Just very curious of the tech setup.

 

Edited May 25, 2022 by rbairos

[+Al_Nafuur]

8 hours ago, rbairos said:

Also I'm now extreeeemely curious how/if UnoCart / Harmony / PlusCart etc communicate joystick data back to the cart microcontroller on an FB2.
I'm suspecting its something like:

LDX swcha
STA reservered_memory, X       

Then it monitors for address requests in a 256 address range in reserved_memory.

 But if FB2 data-lines are write-only, it means extended RAM chips and even bus stuffing wouldn't work I'm guessing.

Just very curious of the tech setup.

 

The UnoCart is using something like this.

The PlusCart is using a ROM hotspot to communicate with the cartridge firmware and the byte at the data bus is read by the cartridge.

 

 

There had been tests on the modded FB2 with multicarts:

 

[+batari]

9 hours ago, rbairos said:

Also I'm now extreeeemely curious how/if UnoCart / Harmony / PlusCart etc communicate joystick data back to the cart microcontroller on an FB2.
I'm suspecting its something like:

LDX swcha
STA reservered_memory, X       

Then it monitors for address requests in a 256 address range in reserved_memory.

 But if FB2 data-lines are write-only, it means extended RAM chips and even bus stuffing wouldn't work I'm guessing.

Just very curious of the tech setup.

 

FB2 seems to do all of the normal bus things, but A12 is always 1 on the cart port so you can't tell whether the CPU is accessing TIA/RIOT or cartridge space. When A12=0 internally (not on the cart port, you can't see A12), it does float the bus.

 

The problem with cartridge RAM is typically due to cartridge writes (A7=0) conflicting with TIA because the cartridge can't tell the difference between a write to RAM and a TIA access, so it corrupts cart RAM.

 

What we did on the Harmony is we simply put the read port first (overlapping the first 256 bytes of memory) and the write port second, so reads occur normally and writes will not get clobbered (in most cases, that is: you still have stack space in page 1 but as long as you are careful with the stack, you are good.)

 

It would be possible to create a 100% compatible cartridge RAM scheme for FB2 as long as the RAM write region was in a page of memory with no other accesses.

 

EDIT: OK, so let me correct myself a bit. It's actually a bit more complex than that.

 

The Harmony cart's cart RAM scheme is *not* symmetrical. It's 256 bytes, and the read port is $F000-$F0FF. The write port does NOT use the entirety of page 1, but only a portion in the range $F180-$F1FF. Any stack accesses will corrupt RAM, but if you stay off the stack, the rest can be used as a write port.

 

You *could* create a scheme with several write ports that conflict with stack mirrors, as long as you stay off the stack.

[+rbairos]

So what I gather is that FB2 *should* present the TIA/RIOT data on the bus when the correct address is setup?
If so, it must be something in my circuit setup then, as the bus seems to just be holding the last value I presented to it, even when A12/A11 fall.

For MovieCart 1, I used A11 as my rom select line, as the kernel was only 1K.
I used A10 as a serial line to pulse back swch status to the firmware (1 bit per scan line, simply pulsing back the full count: 0 to 255 pulses).
It was slow and somewhat finicky (had to confirm same value twice before accepting), but it worked in the end.

For MovieCart 2, I'm hoping to just read swch* directly and peek at the data lines, but having the aforementioned problem.
If that fails, Ill do LDX swcha ; STA reservered_memory, X 
 

Quote

The problem with cartridge RAM is typically due to cartridge writes (A7=0) conflicting with TIA because the cartridge can't tell the difference between a write to RAM and a TIA access, so it corrupts cart RAM

Do you mean on the FB2 only?  since A12 is unavailable?

 

Quote

The Harmony cart's cart RAM scheme is *not* symmetrical. It's 256 bytes, and the read port is $F000-$F0FF. The write port does NOT use the entirety of page 1, but only a portion in the range $F180-$F1FF. Any stack accesses will corrupt RAM, but if you stay off the stack, the rest can be used as a write port.

So, the 6507 code can write to one of 127 harmony ram bytes in $F180-$F1FF,   and read them back from:  $F080-$F0FF ?
And bytes $F000 - $F080  return what, the regular built in ram?

Thanks for all the help,

Rob.

Edited May 26, 2022 by rbairos

[+batari]

36 minutes ago, rbairos said:

So what I gather is that FB2 *should* present the TIA/RIOT data on the bus when the correct address is setup?
If so, it must be something in my circuit setup then, as the bus seems to just be holding the last value I presented to it, even when A12/A11 fall.

No, you will not see any TIA/RIOT data on the bus, nor can you stuff it. Anytime A12=0 internally, the data bus floats and there is no activity on it. The address bus changes during A12=0 internally, except A12 reads as 1 on the cart port no matter what.

 

37 minutes ago, rbairos said:

For MovieCart 1, I used A11 as my rom select line, as the kernel was only 1K.
I used A10 as a serial line to pulse back swch status to the firmware (1 bit per scan line, simply pulsing back the full count: 0 to 255 pulses).
It was slow and somewhat finicky (had to confirm same value twice before accepting), but it worked in the end.

For MovieCart 2, I'm hoping to just read swch* directly and peek at the data lines, but having the aforementioned problem.
If that fails, Ill do LDX swcha ; STA reservered_memory, X

I am not sure what you are doing with SWCHA, as that goes through the joystick ports? Does the movie cart connect to them? For what it's worth, you can do full I/O through the FB2 joystick ports, read and writes both work. That was how we were able to dump the FB2 games. I am surprised the ports can operate at a fast enough speed to stream a movie. I personally got 57600 bps but I would doubt that is fast enough.

 

Unfortunately, though, you cannot pull the SWCHA value directly from the bus on the FB2 as the bus is floated below $1000.

37 minutes ago, rbairos said:

Do you mean on the FB2 only?  since A12 is unavailable?

 

So, the 6507 code can write to one of 127 harmony ram bytes in $F180-$F1FF,   and read them back from:  $F080-$F0FF ?
And bytes $F000 - $F080  return what, the regular built in ram?

Thanks for all the help,

Rob.

Yes, SARA RAM is only a problem on the FB2 because the memory is being used for other things.

 

Now that I think of this, I might be slightly wrong (it's been a long time since I messed with this.) I think you can put 1k of contiguous RAM on the FB2.

 

Put the read port at $1000-$13FF and the write port at $1400-$17FF. Any zero page, stack or RIOT timer accesses will be interpreted by the cart as RAM reads, and it will happily place the values on the floated bus without consequence. Any access to $1400-17FF will be a write. This means that your program cannot access memory from $400-$7FF but that is easy enough to do.

[+rbairos]

Quote

No, you will not see any TIA/RIOT data on the bus, nor can you stuff it. Anytime A12=0 internally, the data bus floats and there is no activity on it. The address bus changes during A12=0 internally, except A12 reads as 1 on the cart port no matter what.

Ahhhhhhh. Thank you!!  I had also briefly tested my circuit on a heavy sixer tonight and had the same visual results. Probably two different bugs at once.
I've started rewriting the kernel to work through address lines.

 

Quote

I am not sure what you are doing with SWCHA, as that goes through the joystick ports? Does the movie cart connect to them? For what it's worth, you can do full I/O through the FB2 joystick ports, read and writes both work. That was how we were able to dump the FB2 games. I am surprised the ports can operate at a fast enough speed to stream a movie. I personally got 57600 bps but I would doubt that is fast enough.

No it was much simpler than that.  The 6507 did a LDA swcha, then addressed a specific location each scan line, corresponding to A.  (0..255 times)
The microcontroller just counted the total hits on that address line each frame.
I sent one byte per frame:  swcha on frame1,  swchb on frame2, etc..
That version of the circuit worked through an intermediate (obsolete) dual-port ram, so I didn't have real-time access to the bus address lines, like I do know.
 

Quote

"Now that I think of this, I might be slightly wrong (it's been a long time since I messed with this.) I think you can put 1k of contiguous RAM on the FB2."

That's an interesting approach.  But for the MovieCart Kernel, I don't have the cycles to read RAM like that.
All values are immediate zero page reads, where the values change each scanline.

Cheers.