Jump to content

Photo

FPGA Supercharger Programming


6 replies to this topic

#1 kevtris OFFLINE  

kevtris

    Star Raider

  • 86 posts
  • Location:Flyover, USA

Posted Wed Feb 29, 2012 7:42 PM

Hello, everyone. long time viewer, first time poster.

To get right to it, I have some questions about programming the Supercharger. I made an FPGA Atari 2600, and want to add the Supercharger to it. I have disassembled the BIOS for it and read everything I can find on this forum and on google.

I understand most of how it works, except for a few fine points:

To write to the control register (FFF8h) you must first access f0xxh, then FFF8h in the following sequence:

;X = value to write to the control register
lda f000h,x
lda fff8h

So the CPU cycles for this look like so:

(assuming the code is at FF00h)

1 read FF00 (BDh opcode for LDA abs,x)
2 read FF01 (00h address low)
3 read FF02 (F0h address high)
4 read F000,x
5 read FF03 (ADh opcode for LDA)
6 read FF04 (F8h address low)
7 read FF05 (F9h address high)
8 read FFF8

So, to write to the control register, the chip watches for an access to FFxxh, then watches for an access to FFF8h, within N cycles.

The first question is then, what's N? Is it related to the "Delay" value on the control register?

The next question is related to writing data to RAM. It works in a similar fashion to the above, except there's a 5? cycle delay between the two reads. i.e.:

lda f000,x
lda (zeropage),y

The lda(),y instruction takes 5 cycles to execute, so there's at least a 5 cycle delay between reading F0xxh and the read of our desired write location.

I suspect the Supercharger chip actually outputs data at this point to write to the RAM chips themselves, which is somewhat interesting.

While looking through the disassembly, however, I saw some writes to RAM that took 6 cycles, and some that took 5. The writes that take 6 have the following form:

lda f000,x
nop
lda f123

I am trying to figure out how the Supercharger can tell the two apart, and as near as I can tell, it monitors address line transitions. The above code snippet will only have 5 address transitions. The NOP's second cycle reads the NEXT opcode, but throws the byte away, then reads it again for the next LDA. This would result in just 5 bus transitions instead of 6.

How does the delay register affect this? Does it specify a straight transition count? Or is it some kind of delay line that's somewhat analog, relying on an internal RC circuit or something?

Also, how does the Supercharger read the tape audio line? Looking at the code, I'd say it watches FFF9h. They do lots of:

lda fff9
beq offset

So this tells me it returns 0/non-zero depending on the state of the audio input (low/high).

I think that's about it. I understand how to encode the audio so that the Supercharger will eat it and call it good.

Thanks for any help.

#2 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,893 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Thu Mar 1, 2012 3:58 AM

http://www.prismnet..../doc/sctech.txt

And another thing again...:
The cycles, be sure your instructions need more cycles than 3
and less than 7, otherwise no value will be stored.

So N is 4..6.

#3 kevtris OFFLINE  

kevtris

    Star Raider

  • Topic Starter
  • 86 posts
  • Location:Flyover, USA

Posted Thu Mar 1, 2012 8:07 AM

http://www.prismnet..../doc/sctech.txt

And another thing again...:
The cycles, be sure your instructions need more cycles than 3
and less than 7, otherwise no value will be stored.

So N is 4..6.


Thanks for the reply! Yeah I saw this document, but I'm still wondering how the Supercharger "knows" what cycle is the one that makes it store the data.

There's two possible ways I can see it doing this:

* Counting CPU cycles by watching address line transitions after the read of F000-F0FF
* Looking for an "out of order" address to be accessed, within N cycles of the read to F000-F0FF

The problem with the first, is if you do not specifically read from where you wish to write at the proper cycle, it will over-write the code that's executing. Not a huge problem- the code's never supposed to do this.

The second one would watch the address lines. During execution, they should continuously increment as code runs. Within N cycles (3-7) of the read of F0xx, and an out of order access, write to the RAM. This has another problem, but I don't think it is an issue. The problem being that you cannot overwrite the next byte of memory, but I'm pretty sure this isn't an issue. Even with self modifying code it's not going to be a problem, because you don't usually write to the next location you're going to execute.

Thinking from a hardware standpoint, it's a tossup as to which is easier to implement on silicon, though the former might be a bit easier.

In either case, it's the Supercharger chip that actually performs the memory write, which I find highly amusing. It has to stuff data onto the bus and hit /WE on the RAM chips during the read cycle to turn it into a write cycle.

#4 kevtris OFFLINE  

kevtris

    Star Raider

  • Topic Starter
  • 86 posts
  • Location:Flyover, USA

Posted Fri Mar 2, 2012 10:04 AM

Wellll I figured it out. The Supercharger does indeed count bus transitions. I have reproduced the Supercharger now on my FPGA hardware and used the stock BIOS to load games.

So the magic is the Supercharger waits 5 bus transitions after accessing 10xx before it will write data to the RAM. Also, the audio input only is read via bit 0 of 1ff9. The other 7 bits must be 0's or else it will not load anything.

I have written up a comprehensive document on how it all works which I will post a link to after I finish the other parts of it. A long overdue comprehensive 2600 mappers document, because nothing of the sort exists except for my very old one.

#5 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,249 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Fri Mar 2, 2012 10:07 AM

Impressive work - I'm looking forward to reading your document.

Chris

Edited by cd-w, Fri Mar 2, 2012 10:08 AM.


#6 enthusi OFFLINE  

enthusi

    Chopper Commander

  • 216 posts
  • Location:Potsdam, Germany

Posted Mon Feb 25, 2013 6:22 AM

Any news on this? I've been reversing some of the SC BIOS myself but I was mainly interessted in the TAPE loader itself ;-)

#7 kevtris OFFLINE  

kevtris

    Star Raider

  • Topic Starter
  • 86 posts
  • Location:Flyover, USA

Posted Wed Mar 6, 2013 1:43 AM

I finished the project long ago. I ended up writing another Supercharger Demo Unit ROM that actually loads the regular tape games into the simulated supercharger. Figured I already had the supercharger demo unit working, so I could just re-use that part of the project. The regular tape games are simply loaded into the address space where the Demo ROMs went, and I made a new "bios" ROM for the simulated demo unit that can load in the various loads of the multiload game (if needed) and "Rewind" the tape if need be. I thought about being smart about it and snooping the 2600's bus to figure out when the game called the SC BIOS' tape load routine again to auto-load the next load of a multiload tape but didn't get that far yet. I may yet add that. Right now you just get to play the next load or rewind to the first one.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users