Jump to content


  • Content Count

  • Joined

Community Reputation

447 Excellent


About Kr0tki

  • Rank

Contact / Social Media

Profile Information

  • Gender
    Not Telling
  • Location
    Warszawa, Poland

Recent Profile Visitors

16,973 profile views
  1. The only one with a helicopter, tunnels and water that comes to my mind is "Buried Bucks" aka. "Chopper Hunt".
  2. Your 5-21 prototype is an overdump, containing the same 16 KB twice. I'm attaching the correctly-sized one. When compared against the 5-8 proto, the only differences are in the $0264..$0292 range. This is a routine that clears the playfield and the player/missile graphics, and it is called at every screen change, such as before displaying the title screen, at game start, when switching between the cockpit view and the map view, or when going into or out of hyperspace. In the 5-8 proto this routine clears the playfield first and then the PMG, which results in a graphical glitch at the moment of switching from the cockpit view to the map view: sprites remain visible on the map view for a brief moment. In the 5-21 proto this routine is modified to clear the PMG before the playfield, so that the glitch does not occur anymore. There are no other differences between these two protos. Last Starfighter, The (1984-05-21)(Atari)(proto).bin
  3. Well, there's one difference between your description of 2-13 and this 1-18 proto. The 2-13 version "starts up on the main title screen instead of the cockpit screen" (which is the same behaviour as in the well-known Atari 8-bit leaked beta), while the 1-18 proto starts on the cockpit screen. That seems chronologically confusing though - the 1-18 proto and the final version start on the cockpit screen, while the version inbetween does not. EDIT: I've found another independent review of the 2-13 prototype at Digital Press, where it is mentioned that it did not contain the Lucasfilm splash screen, it allowed to select any level up to 99, and it did not allow skip ahead levels after completing a mission (again, same behaviour as in the 8-bit leaked beta). But the 1-18 prototype contains the Lucasfilm screen, only allows to select levels up to 16, and allows to skip up to 3 levels after a mission (though it still does not contain Ace pilots). So if the Digital Press description is correct, then the 1-18 prototype is closer to the final version than the 2-13 one!
  4. Well, it is listed as "Surround" in Atari's Item Master List.
  5. This ROM is/was being sold on reproduction cartridges by Best Electronics. Best claims that it comes from a prototype cartridge in their possession. (Search for "CB103022" on this page.) Glenn the 5200 Man converted the game to the 8-bits back in the day, and it is evident when you compare the 5200 proto with Glenn's file version. The file version basically contains the straight dump of the 5200 ROM, with some minor modifications to handle the differences between the two platforms, and some additional loader routines. But if you compare the 5200 proto with the 8-bit cartridge ROM, there is a lot of differences - the two ROMs are not directly comparable at all. I believe the 8-bit ROM is a legitimate prototype. (That, of course, does not rule out the possibility of Best modifying it before they released it.)
  6. Well, the 8-bit version was copyrighted 1981, and this one is based on the former, so that's one possible reason. In any case, I have binary-compared the PAL proto to both the 5200 and 8-bit retail versions, to see if the PAL proto is "close" to either of them, to determine "lineage", to no avail - there is a lot of changes in the layout between all three versions. The 5200 shipped in October 1982, with MC as a launch title. The PAL proto is from April 4, presumably 1982. It seems that the PAL 5200 was being worked on way before the NTSC version shipped. So my presumption is that this PAL proto was created while MC was still in development, only for the purpose of testing region locking. That would explain why the PAL proto has less features than the retail version.
  7. You are right! Typically, games run on PAL are slower that in NTSC, because the gameplay is synchronized with the screen refresh rate. This is not the case with the retail MC - it seems to be running roughly at the same speed in both NTSC and PAL. But the PAL proto seems to be synchronized with screen refresh rate! On an NTSC 5200 it will run at the same speed as the retail version, but on a PAL 5200 it is noticeably slower! That just does not make sense. The retail version seems to be better-suited for PAL systems (both in the screen size and speed) than the PAL-specific one!
  8. Exactly. No - when you run either the retail MC or the PAL MC on an NTSC 5200, both will look the same. But if you run both on a non-existing PAL 5200, then the retail version will cover more vertical screen estate, while the PAL proto will look squashed.
  9. Oookay, I think I've skewed the definition of "later today" far enough. So, modern emulators (talking about Altirra and Atari800 here) accurately emulate NTSC/PAL palette differences and NTSC/PAL aspect ratio differences. But that means, when a game implements its own palette- or aspect ratio adjustment, it tends to be difficult to notice because of these emulator features! So for the purpose of investigating differences in a game's behaviour it's best to disable these features. As an example, GATO title screen in NTSC and PAL. GATO is known to not make any system-specific adjustments by software, so the differences in colours and aspect ratio are purely the result of the emulator being accurate. In Atari800, to disable NTSC/PAL aspect ratio correction: 1. Go to "Display settings -> Video mode settings". 2. Ensure that "Host display aspect ratio" is set to your monitor's aspect ratio (typically 16:9). 3. Ensure that "Hardware acceleration" is set to "yes". 4. Ensure that "Stretch image" is set to "fit screen - full" and "Fit screen method" is set to "fit both". 5. Set "Image aspect ratio" to "square pixels". 6. Set "Vertical view area" to "full overscan". In Atari800 we also need to disable artifacting, because it interferes with aspect ratio settings. 1. In "System settings" switch "Video system" to NTSC. 2. In "Display settings" set "Video artifacts" to "off". 3. In "System settings" switch "Video system" to PAL. 4. In "Display settings" set "Video artifacts" to "off". To disable NTSC/PAL palette correction, we will apply the NTSC palette to the PAL TV system. In Atari800: 1. In "System settings" switch "Video system" to NTSC. 2. In "Display settings" select "Save current palette". (The option in on the "2nd page" of the menu, just go all the way down in "Display settings" and then down once more.) 3. Enter path to file of your choice, e.g. "C:\atari\ntsc-palette" - the palette will be saved to a file. 4. In "System settings" switch "Video system" to PAL. 5. In "Display settings" select "External palette". 6. Navigate to the palette file created in step 3 and select it - the colours should immediately change. Now it is way more convenient to notice if a game adjusts screen or colours between PAL and NTSC. As an example, the retail version of 5200 Missile Command in NTSC and PAL. It is immediately visible that when run in PAL, the game uses more screen vertically. Another example, the retail version of 5200 Star Raiders with shields enabled, in NTSC and PAL. It is immediately visible that the game in PAL mode uses a different colour for the shields. It was done because the colour from the NTSC version would look green on real PAL machines. (And it would also look green in emulation, if you were to re-enable proper NTSC/PAL colour emulation in Display settings.) As for the specific differences in the PAL prototypes of MC and SR: As you may know, most 2-port 5200s contain the newer version of the BIOS - and the only change introduced in that BIOS is regional locking for PAL cartridges. If a 2-port 5200 console was a PAL version, the BIOS would check if the inserted cartridge was a PAL version, and halt if it isn't. Specifically, the BIOS checks: 1. if the cartridge is diagnostic, i.e. contains $FF in $BFFD -> if it is, runs it. 2. if the cartridge contains a specific value in $BFE7 -> if it equals $15 or $30 or if its bit 1 is set, then the BIOS runs the cartridge; otherwise it halts. Apparently Atari's intent was to lock US cartridges from being used in PAL 5200s. If you use the 2-port BIOS in the emulator, switch to PAL, and try to run any of the ROMs made by Atari, in most cases they won't run. Now when it comes to PAL Missile Command and Star Raiders ROMs, they both have the value in $BFE7 set to $02 (MC) and #03 (SR) in order to pass this regional check. In fact, in the case of SR, the only difference between the NTSC and PAL versions is in the three bytes between $BFE5..$BFE7 - so we should not expect any differences in gameplay. With PAL MC the ROM is different overall. The only gameplay difference I noticed is that the PAL proto does not adjust the screen area differently between NTSC and PAL - it uses the "NTSC height" in both TV systems, which is, to be frank, inexplicable.
  10. I compared this ROM with the 6-18-83 prototype (which is close enough to still make sense to compare) and it seems that this is a bad dump - it contains incorrect bytes in locations $0800..$0802, $1800..$1802, &2800..$2802, etc. I would suggest to follow Mitch's advice, and see if we get anything different in the second dump.
  11. I would recommend you to download the No-Intro Atari 5200 ROM set - it contains the ROMS in their pristine, non-overdumped form (except for Zaxxon, which should be 16KB, but the two 16KB copies within the existing 32KB ROM dump differ on two bytes, indicating that it might be a bad dump; and several 12KB, 20KB and 24KB ROMs that need to be padded to 16KB/32KB anyway because emulators do not support these ROM sizes). Investigating PAL vs. NTSC differences requires proper setting up of the emulator - some "modern" features such as accurate emulation of colour palette and aspect ratio correction need to be disabled, as they tend to hide whatever the differences are implemented in software. I'm gonna help you out on this later today.
  12. Not necessarily - it depends on the wiring of the cartridge PCB. I suppose that for prototyping they might have been using PCB's that are universal, i.e. accept either 4K or 8K chips in the sockets.
  13. I am having the same issue - I cannot find an option to delete attachments. It was there in a previous version of the forum. I used it routinely in this thread every time I wanted to update the attached source code archive - I would just delete the old attachment and make a new post with an updated archive attached. Is deletion of attachments now restricted only to forum subscribers, or removed completely?
  14. I don't know much about ROM reading, but is it possible that LO-MID is in fact an 8K chip that was dumped as a 4K one?
  15. This is unlikely to work. The dumps seem to be correct, but there is a lot of unused space in them. The 8-bit version is 8K in size. These 3 chips contain only about 4K of data. The HI chip is mostly empty, except for the init vectors at the end, so it should be mapped to $B000-$BFFF. The LO-MID chip is fully filled, while the HI-MID chip only contains data in the first $50 bytes. I believe this is correct though - when joined together, LO-MID and HI-MID matchthe last ca. 4K of the 8-bit version. It seems that LO-MID should be mapped to$7000-$7FFF and HI-MID to $8000-$8FFF. The issue is, there is no data on the chips that would match the first 4K of the 8-bit version. The init vector points to $6047, which means that the missing 4K should be mapped to $6000-$6FFF. Overall, this cartridge seems to use the "Two chip 16 KB 5200 cartridge" mapping. The ROM image should be formed by joining the missing 4K, LO-MID, HI-MID and HI in that order, to form the following memory mapping: ??? -> $4000-$4FFF, $6000-$6FFF LO_MID -> $5000-$5FFF, $7000-$7FFF HI_MID -> $8000-$8FFF, $9000-$9FFF HI -> $A000-$AFFF, $B000-$BFFF
  • Create New...