Kr0tki

A bit late reply, but - your dump is correct, and while it is an overdump, it is otherwise identical to the known 1-20-83 prototype.

The "old" Monty ROM occupies 16KB of memory at $8000-$BFFF (it's actually a 12KB cartridge, so $8000-$8FFF and $9000-$9FFF are duplicated), and the Parker Bros disk release loads into different memory areas, and is different enough to assume that the PB release and the ROM are not directly related. The 5200 version is layed out differently, so it's not directly related either. BTW the 5200 version does not contain the errors of the old 8-bit ROM. The Databyte releases actually load into $8000-$BFFF and, after loading, that memory area is 100% identical to the old ROM. There also exist old DOS file hacks that load to $8000-$BFFF (along with supplementary initialization routines loaded into other areas) and are identical to the old ROM (or differ in a few bytes for unknown reasons). Curiously, none of the hacks are based on the correct PB release. (I'm judging from the contents of the AtariOnline.pl software archive - it is rather comprehensive.) So, in my view two options are possible: a) Source of the old ROM is a leak from PB, that was then hacked to file by pirates (most likely by Steve and Bruce, who famously released their version under the title "Preliminary Monty 16K"); and Databyte later went the lazy route and based their releases on a cracked file (same as what Atari Corp. did when they released "Centipede" on tape - they simply used Glenn's hack from Atari 5200). Maybe the known ROM file itself was re-created back from one of the DOS files at a later date, who knows. b) Source of the old ROM is the Databyte release - maybe they screwed something up and made the releases buggy, and all the hacked DOS files, and the ROM file, originate from the Databyte disk or tape. But this seems unlikely. The Databyte releases are from 1986, the PB release is from 1984, but none of the known file versions are based on the PB release. How would that be possible that no one would make a file version of Monty between 1984 and 1986?

Yes, more or less. Though given that the differences between the new ROM and the old one are significant, it is not possible for the old ROM to be a hack of the new one. I believe that the old ROM is some kind of a WIP leak, on which all the hacked "Preliminary Monty 16K" DOS files are based; and I would not be much surprised if the official Databyte releases turned out to be based on one of those hacked DOS files - we've seen such cases before. Consult the maps for the C-64 version - the uncorrupted Atari version is identical. -------- Now about Gyruss, it's an interesting case again: most if not all known DOS file hacks of Gyruss that are floating around, show the same colours on stage 1 as the 4-23-84 proto, so they are not actually based on the final version.

With Monty the story is much more interesting. The known ROM image of Monty that is available on the Internet, e.g. at Atarimania, has a few bugs that were not present in the final US disk version by Parker Bros: 1. It lacks the sound when the dagger is used, 2. The leftmost room on the 9th level of the pyramid is broken, (as seen on these maps - click the "poziomy 1/3/4" links) 3. The room immediately below the aforementioned room is also different than in the final version. What is interesting, the UK releases by Databyte (both disk and tape) contain the same bugs. Also, all cracked file versions of Monty (known as Preliminary Monty) that I've seen, also contain these bugs. And what is even more interesting, this new proto image of yours does not contain the bugs. It is "more final" than the known ROM image! Now, since you had reviewed the Monty proto on your website years ago, I had always assumed that the known ROM image was dumped from that old prototype and then shared. It is stated in your review that the old proto held the label "Atari 400 Monty 12K.RLS.1 5/30/84". But the new prototype, judging from the filename that you assigned to it, has the same date. This is quite confusing and raises some questions: 1. Is the old known ROM a legitimate prototype at all? 2. Did you base your original review on an actual ROM dump from the prototype cartridge, or was it mistakenly based on this buggy ROM that was obtained from elsewhere? 3. What was first: the supposed old ROM proto or the Databyte releases? Which is based on which?

Matt, the ROM image of Mr.Do!'s Castle that you are comparing the proto to, is in fact a cracked ROM - that's why you are seeing the 3-byte difference. deathtrappomegranate uploaded a dump of his original Mr. Do!'s Castle cartridge back in 2012, and it was discovered at this time that the popular ROM of Mr. Do floating on the net was a crack. So grab the correct ROM image from deathtrappomegranate's post and compare the proto with it - you will discover that a) the proto ROM is an overdump with first 8KB empty; and b) it is identical to the final version.

Release rate in "Tommingi" is implemented inversely compared to the Amiga original, in that the minus button increases the rate; so "0" means the highest release rate.

I doubt any music work has been ever started, but let's ask @jhusak anyway.

There was never a full version of "Tommingi", only a WIP demo with 7 levels. The most complete version is the two-sided disk release at Atarimania, which contains an actual ending screen, whereas the versions at Fandal and Homesoft simply loop the levels indefinitely. When "Tommingi" was being previewed in the 1/1994 issue of "Świat Atari", it was supposed to be released in that year's November, with more levels, colour graphics (still 4 colours though) and digitized music by Jakub Husak.

That's because the popular cracked disk image of Mr. Dig contains some additional, unrelated, files: ANDRU.BAS (unreadable, but can be found elsewhere) and QB.OBJ (Andrew's game).

The only one with a helicopter, tunnels and water that comes to my mind is "Buried Bucks" aka. "Chopper Hunt".

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

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!

Well, it is listed as "Surround" in Atari's Item Master List.

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.)

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.

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!

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.

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.

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.

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.

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.

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?

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?

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

I once investigated software that behaves differently on NTSC and PAL machines, so I figured out, let's see if the 5200 cartridges behave the same as their 8-bit counterparts in this regard. I know the planned PAL version of the 5200 was cancelled, but it is possible to make a "PAL 5200" in an emulator. Turns out, there are a few additional differences in this area: - Dig Dug 800: uses different palettes on NTSC/PAL 5200: NTSC palette only - Joust 800: uses different palette on PAL (apparently only the colour of the title and player 1 is changed though) 5200: the feature to switch the palette is implemented, but the palette itself is missing. The game displays a completely black screen on PAL, but the player can still launch the game and hear gameplay sounds. - Missile Command 800: does not change vertical space 5200: Uses more vertical space on PAL Notably, the supposed PAL 5200 prototype might actually be not a PAL prototype at all, since it lacks this behaviour - it uses the "NTSC" screen space in both NTSC and PAL modes. Maybe it is simply an earlier version with the PAL geometry not yet implemented? - Star Raiders 800: NTSC palette only 5200: uses different palette on PAL (e.g. long range scan, shields) - Super Breakout 800: does not change vertical space 5200: Uses more vertical space on PAL - Track and Field 800: Displays a different title on PAL 5200: Has only one title As a side note, here are titles that behave the same on both the 8-bits and the 5200: - Galaxian uses more vertical space on PAL (player ship and score row moved down). - Jr. Pac-Man uses different palettes on NTSC/PAL - Kangaroo uses different palettes on NTSC/PAL - Keystone Kapers uses more vertical space on PAL (the credits row is moved a few pixels down) - Ms. Pac-Man uses different palette on NTSC/PAL Note: the PAL palette has wrong colour for the cherry (green). On the 8-bits there was a second cartridge release that had the PAL cherry colour fixed to red. - Pitfall II uses more vertical space on PAL (the credits row is moved a few pixels down) - River Raid uses more vertical space on PAL (the status bar is larger) - Pole Position uses different palettes on NTSC/PAL Note: the colour differences in the 5200 prototype are caused by this feature being not yet implemented in that version - the prototype only contains the NTSC palette, and that is how it would look on a PAL machine. When run on an NTSC 5200, the prototype displays the same colours as the final version, with the exception of the blue roadway and a different shade of red in the banks. Also, the 5200-only Qix and Vanguard also use different palettes for NTSC and PAL.