Hornpipe2

Your solution won't work, at least not for the conditions you describe. It will turn 01 into 10 and vice-versa, but will turn 11 into 00 and keep 00 unchanged. You only have 16 possible values there, so why not just use a lookup table? Sorry I wasn't clear... the lookup table is exactly the solution I will be using. However after thinking about it the AND is unnecessary, I'll save a couple bytes without it.

Simple 6502 challenge: I have joystick code that is dependent on the player's facing, so when they turn around, I need to swap the L and R inputs. Can you think of an easy way to swap the position of two bits? E.g. this sample: 00001011 would become 00001101 and 00001110 would become 00001110 EDIT: You can do this as an exercise if you like, but I think a better solution for me is just to AND with 00001100 and then XOR the result with the original value. This flips L/R and turns 00 into 11, which in my movement table will be the same effect.

Could you make the explosion much quicker? The downtime after running into something is very long!

And here's an old thread where we talked about the idea of using joystick ports to set up a little null modem type thing. http://www.atariage.com/forums/index.php?showtopic=62988

Never mind, I got it working. Must have gotten a corrupt ZIP the first time around or something.

Yeah, I figured all-0 would be the result. I mostly want my tool to find problems where: * sectors are marked as "unused" but contain data (deleted or lost files - could be recovered) * sectors are marked as "used" but contain all 0 data * filename table appears to be damaged (e.g. is empty, points to blank sectors, etc) * files are damaged (following the chain of offsets lands in a blank sector) - it may be possible to 'reconstruct' files where a sector was bad by rewriting the offset to continue the chain, but there would be a sector with no data present. Could still make some files salvageable (not object code though) Thanks for the info on 1050 density! My disks are either in standard or enhanced so this would be enough to audit my backups.

Sorry to dredge this up, but: Does S.A.M. work on any emulators? Atari800Win 4.0 and 4.1 are both crashing when I try to boot the disk image.

I'm looking for information on the Atari 8-bit disk structure. (I used a sector copier to duplicate a bunch of old disks to my PC, and several had bad sectors, so I'm wanting to make a chkatr tool that reports and fixes missing sectors, damaged files, etc) De Re Atari pretty much gives me everything I need to know for Single Density here: http://www.atariarchives.org/dere/chapt09.php#H9_5 However, I am wondering about the structure for other file formats, especially 1050 density. Is there some generic method for figuring this out? I don't know how atarisio generates arbitrary-sized ATR files, but if I did then maybe I could use that as a starting point.

I played this game years ago (late 1980s) from a disk containing lots of games. No idea where it came from originally, as this disk was a copy. Researching it today I find that this was a prototype cartridge... so I don't know how I got it in disk format. Nevertheless, see attached .obj file if you want to try it out. LASTSTAR.zip

That's fine, and unfortunately I won't be able to help you there. I was mostly just curious if anyone knew of bugs fixed (or other changes) in these different revisions, so that we could tell the difference in ROMs apart by simply playing on the emulator. I hope at least that my comments provide a 'testable hypothesis'...

Right now I am very interested in what is the difference in versions of Commando, Dig Dug, Jr. Pac-Man and River Raid II (all 16k NTSC games with [a] versions) - does anyone know about bugfix releases of these games? EDIT: Judging by all the 0xFFs in the Dig Dug [a], I think someone playing it long enough might run across a difference... is this the prototype? http://www.atariprotos.com/2600/software/digdug/digdug.htm EDIT2: The only difference between Jr. PacMan and Jr. PacMan [a] is that in [a] unused ROM spaces are 0x00 while in the base they are 0xFF. Thus, I believe Jr. Pac Man is actually the Final NTSC version prototype: http://www.atariprotos.com/2600/software/j...an/jrpacman.htm while Jr. PacMan [a] is the real-deal ROM cart version. EDIT3: There are (at least) differences in some of the startup vectors of the River Raid II versions. No idea which is correct, or if both are right.

I thought the LoTR were just two different versions from Atariprotos: http://www.atariprotos.com/2600/software/lotr/lotr.htm EDIT: Never mind, you said PAL ?

Understood. I don't have a problem with the setup as it stands, just was curious about the procedure you'd follow for things like e.g. the 2-in-1 dipswitch games. In that case, I think it is probably best to leave them in (assuming you know the company or year of release) even if they don't work outside a special cart, because they are still historically significant.

This raises interesting questions about what should and should not go in the Collection. Now I'm obviously not the one compiling everything here, so I'll of course defer to Rom's wishes, but if I was doing this: * I would have only unique BIN files in the collection. No overdumps, no 2-in-1 where both Roms are identical, not even pirate (or legit) re-releases with no differences, etc. The only binary present would be the first known release of each revision of the ROM. * I would have a text file that indicates later releases where an identical ROM was matched. That way no historical information is lost, but no BINs are duplicated. (e.g. if I had a dump of "PirateCo's 2-in-1" but both halves were just Atari's Combat and Air-Sea Battle, I would not include the 2-in-1 dump itself but would note it in the history file so that future generations would see it had been dumped and the result - this is enough information for any interested party to re-create it as needed) However, I definitely understand the value of leaving identical ROMs under different names too, so it's really up to you.

I split the Stargate. Attached are both halves. Differences are solely in the Interrupt vectors on Bank 0. star1.bin is really buggy and the aliens move in funky ways. star2.bin matches 100% with our known-good ROM. I'd say: Bad dump... star1.bin star2.bin

Near as I can tell that Omega Race was supposed to be 12k, as the last 4k is mostly just 0xEA: 0000000 eaea eaea eaea eaea eaea eaea eaea eaea * 0000200 01a9 fa8d ea1f eaea eaea eaea eaea eaea 0000210 eaea eaea eaea eaea eaea eaea eaea eaea * 0000ff0 eaea eaea eaea eaea eaea eaea 1200 eaea 0001000 Is this maybe an attempt at reading 16k from a 12k ROM and not factoring in proper CBS bankswitching? I don't know much about CBS carts... In any case the first 12k of this is identical to Omega Race (Booster Grip) (1983) (CBS Electronics) (4L 2737 0000).bin. I call overdump.

Already removed. D'oh!

yuk yuk yuk

Found another one: H.E.R.O. (1984) (Activision, John Van Ryzin) (AZ-036-04) (4K).bin

There are some TIA differences in the FB2 (e.g. Cosmic Ark starfield won't work), but there are also some unsupported opcodes that batari found: http://www.atariage.com/forums/index.php?s...st&p=954273 ARR and SBX (at least) don't work, and possibly more. For the 2600 Jr you're probably right about it being just TIA differences, though.

Almost, but not quite - the CPU in the FB2 is a prime example, and I believe the 2600 Jr has some issues with illegal opcodes too...? It's not about chip design at all, really. Illegal opcodes arose from holes in the instruction set on the chip, and happen to work purely by chance thanks to the internal layout of the processor. Any implementation of a 6502 is NOT guaranteed to support any undefined opcodes, and certainly not in any consistent manner.

I have to respectfully disagree with this position - overdumps are the result of a problem with the cart reader, and have nothing really to do with the ROM itself. So they have no real historical significance, and only clutter up the collection. As far as Crystal Castles: After thinking about it I think this may be the "Crystal Castle COZ5010" proto listed on AtariProtos - probably the final version of the NTSC before it went to production.

Omegamatrix: You saw this list before, right? I want to make sure you don't go chasing overdumps without seeing what's already been identified... http://www.atariage.com/forums/index.php?s...t&p=1446910 EDIT: There are three versions of Crystal Castles. Crystal Castles (1984) (Atari, Michael Kosaka, Peter C. Niday, Robert Vieira) (CX26110).bin Crystal Castles (1984) (Atari, Michael Kosaka, Peter C. Niday, Robert Vieira) (CX26110) [a].bin Crystal Castles (1984) (Atari, Michael Kosaka, Peter C. Niday, Robert Vieira) (CX26110) (Prototype).bin First on that list is the real deal. The second won't let you past the title screen, and is the base version with some changed bytes. Could be a bad dump. The third is exactly like the first, except all unused bytes in the ROM have been changed from 00 to FF (in other words, probably was read from an EPROM as it is faster to program FF than 00 for unused bytes). Are we sure this is a proto, and if so from where? Interestingly none of these versions fit the description of the Crystal Castles prototype described here: http://www.atariprotos.com/2600/software/c...astles/1484.htm Who owns this now? It would be nice to have a real ROM image of it, as I can't find this in your collection.

Is the N64 jumper just a jumper or is is the 4 MB RAM jumper? Happy bump! BU It's just a jumper, not the RAM.

EDIT: Nobody bought my stuff last time, so I listed Mapping the Atari, and then I lumped ALL my remaining games together into one big lot just to see what happens. Also threw in some PC games including You Don't Know Jack vol.2 and Star Wars: Rebel Assault II. Take a look. http://www.chasethechuckwagon.com/display....eller=hornpipe2