bwmott

After some additional testing, I noticed that SpartaDOS X was enabled on the U1MB while running the RAM checks. After disabling SpartaDOS X all of the memory tests are completing successfully, so it looks my U1MB upgraded 600XL is fully functional. Looking forward to playing around with the upgraded machine some more. -- Brad

I'm installing an Ultimate 1MB upgrade from Lotharek in my Atari 600XL; however, I'm running into a potential issue with checking the system's RAM. The 600Xl has been previously upgraded to 64K RAM (very similar to the 600XL 64K upgrades discussed in various threads on AtariAge). I've successfully tested the 64K RAM using the built in OS memory test, Super SALT, and Shoestring's Atari 8bit RAM test (v1.6) without the U1MB installed. Once I install the Ultimate 1MB everything seems to work fine and the built in OS memory test passes without any issues; however, if I try the Super SALT memory test it reports errors. I flashed Shoestring's Atari 8bit RAM test to one of the OS slots in the U1MB and used it to test the 64K RAM as well. It consistently reports that U11 is bad; however, replacing that chip with another one has no effect (nor swapping U11 with U12). I've also tried multiple power adapters to try to rule that out as an issue. Overall the system seems to function fine with the Ultimate 1MB installed; however, I'm concerned that something isn't quite right since some RAM tests are failing. In looking at the 600XL schematics, it seems like most of the signals for U11 and U12 are shared (except for the data lines), so it isn't clear where the fault might be. Any thoughts on what might be causing the Super SALT RAM check (and Shoestring's Atari 8bit RAM) to report failures when the U1MB is installed? Thanks for any pointers! -- Brad

There are no plans for doing any sound emulation changes for the next release, however, I'll add this to the list of items to look into for later releases. -- Brad

Could you say more about this issue? Is this when the debugger is open or during normal execution? Thanks, -- Brad

I'll look into this while I'm working on the TIA code for Stella. -- Brad

OK, I will look into these. FYI, I've seen this bug in Pitfall II as well. The playfield renders on the left-hand side of the screen, where-ever sprites are. In addition, just disabling the playfield fails to make waves go away. Instead, the playfield and (I think it was missiles) have to be disabled to stop the waves. The TIA object enable and disable functions were added after the original TIA code was developed. Inside the TIA code the state of the TIA object flags are "cached" in pointers to precomputed tables for drawing the frame. I'm guessing these table pointers are not being updated when the enable/disable methods are invoked. I'm making a number of changes to the TIA code for the next release and will attempt to address this issue during that work. -- Brad

I believe the problem is with the default bank. Stella starts 32K F4 and F4SC games in bank 7 not bank 0. I think the code assumes it starts in bank 0, however, I could be wrong. I modified Stella to start in bank 0 and the game begins as expected. Since it looks like that's the default for CC and Z26 I'll check those changes in to CVS so they'll be in the next release. Do 32K bankswitching carts always start in bank 0 or is it random?

One problem with frame skip is hardware collision detection. Unless you emulate the hardware (= do the frame) you will miss some collisions (e.g. fast shots vs. players) . And this is even worse for games that flicker already, where some objects might temporary disappear completely. As Thomas has mentioned full frame skipping with 2600 emulation can't alway be used because of hardware collision detection. For example in the PS1 Activision Classics I'm pretty sure they skip ever other frame in River Raid which allows your shots to pass through the tail of the helicopters because it misses the collision. It depends on how the programmer wrote the 2600 game as to whether you can use frame skipping or not. In HERO if you enable frame skipping your player will fall through the ground and be able to walk through walls

This was my first experience with ARM/GBA programming. I’ve had experience with other RISC architectures before which helped out and I consulted the ARM Architecture Reference Manual a lot The emulator uses every “trick” I could think of to get things running as fast as possible in the development time we had. Some of these are standard things that every GBA program does like placing time critical routines in IWRAM, taking advantage of hardware scaling, and using Thumb/ARM code where needed. Others are more 2600 specific and I can’t go into the details of these. It was a lot of fun working on the project with Chris and the team at Aspyr. I hope everyone enjoys it!