kevtris

Oh yeah, I knew I forgot something!

Well I finally finished my "mega" document on mappers (bankswitching) and various pieces of peripheral hardware. In it is all the mappers I know about, and the Supercharger, Supercharger demo unit, the tape format for same, and the Compumate. If there's anything I missed lemme know and I will add it. http://blog.kevtris....0%20Mappers.txt

I don't know, but it's probably around 200-300ish. The black plastic box it is in was just a stock project box with a white label stuck on the top. I have only seen two personally. One was broken, and one was working. I fixed the broken one. The problem was one of the EPROMs was bad (something was loose under the window banging around which broke a few of the bond wires). Replaced the EPROM and it worked good.

I noticed that there's not much information on the internet about the Supercharger demo unit. There's an old thread about it and a few pictures floating around, but not much else. Kind of a shame since it's a slightly insane feat of coding. The demo's around 8.5 minutes long and shows off half of the Supercharger game library or so, and even lets you play two of the games for a short time. I posted a video of it running on my FPGA Atari 2600 (the demo unit, 2600, and Supercharger are all inside the same FPGA). The entire video's here: http://www.youtube.com/watch?v=MKEQ0aaYXWQ A bit of technical background for those that like that sort of thing... The demo unit's composed of no less than 9 EPROMs (8x 2764 and a 2732), a 6805 CPU (motorola?! heresy!!), and some other miscellanious hardware. It plugs into the joystick port and the 'charger's audio cable plugs into the device. It first loads a bootstrap through the audio cable, then it uses the joystick port to transfer data 4 bits at a time. It can load an entire 6K block of data in about 1/4th of a second.

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.

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.

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.