I'll just re-iterate my question as it seems to have been lost in the conversation. Can the recent improvements that almost make Frantic work on a modded FB2 eventually allow it to fully work?
Since you don't seem to understand the problem
, I'm going to try to explain in simpler terms why Frantic, Space Rocks and other games will never work on the Flashback 2. First though, Space Rocks and Star Castle were not
written using batari Basic.
Now to address the Flashback 2's A12 problem
that you don't comprehend.
The 6507 CPU in the Atari 2600 can address 8K of memory. The lower 4K (addresses 0-4095) are things that are internal to the Atari: RAM, controller input, video chip, timers, etc. The upper 4K (addresses 4096-8191) is the cartridge port.
When the CPU needs to access something it puts the address on the A lines, which are A0-A12. That's 13 address lines, 2^13 = 8192, the number of distinct memory locations that the CPU can address. Address line A12 is what determines which 4K (lower or upper) is being accessed.
The problem with the Flashback 2 is the A12 line that goes to the cartridge port is always ON. Because of this, the cartridge thinks a memory access to 0 is an access to 4096, an access for 1 is for 4097 and so on. For ROM only cartridges this isn't a problem.
For cartridges that add extra hardware, be it RAM, DPC (used in Pitfall) or DPC+ (used in Frantic, Space Rocks, and some batari Basic games) this causes a major problem. Some examples of these problems for DPC+ are:
Changing the color of the playfield is done by updating COLUPF which is located at address 8. When the color is updated, the DPC+ cartridge thinks that 4104 (4096+8 ) has been accessed, which is DF0DATA. DF0DATA is used to read from a stream of data (such as sprite graphics). When the DF0DATA is erroneously accessed by the Flashback2, because of the always ON A12 line, the data gets out of sync. This can cause corrupted graphics, misaligned colors, or even a program crash depending upon how the data stream is being used in the program.
Whenever sprites, missiles or the ball are repositioned you must do an HMOVE to "fine tune" of the position of the sprite. This is done by accessing address 42. In DPC+, address 4138 (4096+42) is DF2FRACLOW, which sets the lower part of the address for the second Fractional datastream. What this means is that every time sprites are moved that this datastream gets redirected to the wrong location.
You bemoan "that a whole lot of these problems would be removed if people would just program homebrews like Ed Fries"
because "it annoys me when a new awesome homebrew like Space Rocks comes out, I put it on my Harmony cart, slap that into my modded FB2 and get garbage onscreen."
The thing is, games like Space Rocks could not be done
without using DPC+'s datastreams as they are significantly faster
than traditional 2600 code. To update a sprite using traditional methods takes 18 cycles of processing time. Updating both sprites takes 36, which is 47% of the 76 cycles of processing time on every scanline. Using DPC+ datastreams drops this down to a mere 5 cycles per sprite (or 10 for both, which is 13% of the processing time). Without that freed up processing time, the routines needed for Space Rocks could never have been written.
Edited by SpiceWare, Wed Mar 27, 2013 9:52 AM.