Hornpipe2

I'm making ATR images of all my old Atari disks before they die forever. Currently I'm using the MyCopyR 2.1 sector copier from APE_WARP.atr to duplicate disks. It works really well for disks that are still very readable, but it has a few problems: - it seems to make no attempt to retry reads from ? sectors - some of my disks cause it to lock up - it fails to detect 1050 density on some disks, causing the reading to only return the first 3 or 4 segments Can someone recommend a copier that would get around these? I haven't yet tried US Copy but I've read good things - I suppose I'll re-run all my noncopyable disks through that one. Also, are there any tools available for making ATX images of disks? I have a few originals I'd like to preserve properly.

Well, I would prefer a surprise (more meat and less planning in the blog, if that makes sense) - but I would be most interested in your '2600 essentials' and why you chose them as an upcoming entry.

1780 EDIT: 6240 I don't much like this one. Why the heck do the enemies warp around all the time? At least you can use the lasers without firing to take out enemies that get too close...

* Can you provide a link to the image we should be using to ensure we all play the same version? * Can you specify NTSC/PAL so we are on the same video settings?

For anyone interested I completed the schematic and handed it off to e5frog who posted it up on VESWiki's schematics section.

Are the specifications for VAPI's ATX file format available anywhere? I am interested in adding ATX support to my favorite Linux SIO server, atarisio, but this is obviously made much more difficult if I'd have to reverse-engineer anything : ) I saw a post from 2006 stating that the specs would be released 'soon', but I don't know where I would find them.

I love this game - played it for hours on the A8. Something I liked is that the enemies could really wail on you if they got a chance, so you had to be careful especially when facing groups. The short play-time is fine since I felt each screen was nicely detailed and very action-packed.

I've often used dishsoap and water on my CDs to take off fingerprints and dirt. Nothing special there, just make sure to use a very soft cloth or paper towel to avoid scratches when you dry it. (Actually I have even stuck wet CDs in my players and allowed them to 'spin dry' - not recommended!) Also I once put a computer ball mouse in a sink to cure some sticking. After drying it ran fine. Sometimes modern technology is more resilient than you think. I've been especially fascinated with how well my 25-year old Atari 8-bit disks have held up, now that I'm trying to back them all up with SIO2PC.

That's great! My only remaining question is, what's a good value for the pull-up resistor? I will probably buy a SIL package since that seems like the easiest way to solder up 8 resistors - just need to know an appropriate value. (I'm going to plug this into an FB2, not a 2600, if that makes any difference...)

Just note that it says EEPROM programmer and not EPROM programmer Good catch! This looks like a similar tool for EPROM (2764 to 27040): http://www.larwe.com/zws/products/epromr2/index.html and here's one for 27C801 / 27C080 - exactly what I need: http://www.mikeg2.freeserve.co.uk/eprom/eprom.html also Linux code, and a modification to cut the programming time down to 2 minutes instead of 20: http://outflux.net/software/pkgs/EPROM/

I'm looking at building my own 2600 multicart and am trying to choose a big (8 MB) EPROM to store 256 4kb games, selectable by DIP switch. A few questions: * How reliable are reused PCBs from existing 2600 games? I am thinking of popping the ROM off an old E.T. or Combat or something and wedging my new one in... somehow. * Are there any access time requirements on the ROM? I have my choice of anywhere between 90 and 150 ns. * Any information out there on using SPST DIP switches in a 'pull-down' or 'pull-up' setup to rig up the top address lines? I can't seem to figure out a circuit that would work without a bunch of diodes. * Anything else I should know? This seems like a pretty straightforward procedure for 4kb and doubled 2kb games.

Can anyone vouch for this? http://www.miranda.org/~jkominek/hardware/eeprom/ Since I have $15 to go to make my minimum on my Digi-key order, I think I'll try building it. It looks like it would work, but it would probably be slooooow.

Check out http://www.atariage.com/forums/index.php?showtopic=101921 for other AA member's EPROM programmer suggestions.

FPGA Arcade has a working Adventurevision-on-a-chip. It can drive the LED display, or optionally instead output to a TV or monitor. I thought about building one but there are only 4 games, don't know if it would be worthwhile. Would have been fun to build it in a handheld with tiny LCD and lump all 4 games together onto one chip, selected by switch. The cost of LCD screens is prohibitive, though.

Plugging away at this slowly. My diagram above works perfectly for the power light. However, I stuck a multimeter on the difficulty switches and now I'm a little worried about how I'd add lights to those. The way it works is, a pin from the CPU provides 3.3V to the switch, which is then either left hanging or grounded. Somewhere inside the blob, the CPU is checking to see if that pin carries 3.3V or 0. Can someone tell me if this is the 'proper' way to fix this: * Cut the trace going from switch contact to ground and insert a 68ohm resistor-LED series. This essentially turns that GND connection into a 68ohm (plus LED resistance) pulldown. e.g. convert the current setup: contact o------------GND to contact o------------/\/\/\---->|-----GND I would be worried that doing this would cause the CPU to somehow read the voltage wrong and my difficulty switch would be permanently broken. This looks right to me, but I'm no expert...

A few have asked before ( http://www.atariage.com/forums/index.php?showtopic=76204 and http://www.atariage.com/forums/index.php?showtopic=74717 ) but I don't think anyone's done it - aside from Curt, who had a cart port on one while developing it. You might look at the links on the bottom of my post on that first topic - you can find the pinout of the chip, and that of an NES cart connector. Wire those two up, disable the on-board ROM, and it might just work.

Big thanks to jsoper for trying all the games, and especially for identifying the titles I didn't know in his picture. This list should now be complete. Again, keep those comments and corrections coming - especially for games listed as "Conflicting Reports". I am curious if some of these are not really issues but actually replicate flawed 2600 behavior...

It could be that I really do have BAD MEMORY AT A000.

Is there any way to get Ultima I to run on a 130XE? I keep getting a message "ROM CARTRIDGE PRESENT or MACHINE LESS THAN 48K or BAD MEMORY AT A000"... I tried a translator disk too, no dice.

I definitely played Dunzhin - I remember those graphics! How cool to find it again, thanks! However I think the one I was originally thinking of was one of those Dunjonquest series games. I distinctly recall the 'magic ar.' text... it's funny the things we remember after so many years.

When I was a kid I had an Atari 800 and some pirated game which I believe was called "Dungeon Quest". It was a graphical game if I remember right - some kind of top view RPG. About all I remember is I think you bought or chose weapons at the beginning. The disk died before I got much of a chance to play with it, but it seemed interesting at the time. I can't seem to find any reference to this game online - does anyone have any idea what I may be talking about? It may have been called something different, although I am pretty certain there was a Dungeon in the title... EDIT: Maybe it was Dunjonquest! I always thought I had misspelled Dungeon... perhaps I am thinking of one of those Apshai games?

I just built a cable with audio, composite, and S-Video plugs on it. Brief writeup here: http://greg-kennedy.livejournal.com/22137.html Pinout: http://www.faqs.org/faqs/atari-8-bit/faq/ (section 1.14)

Managing saving in games was an article in the most recent Game Developer magazine. The author essentially made the case for a combination of points 1 and 10 - essentially, saving should be as transparent as possible to the player and should not hinder their usability in the game. How many times have you played through a significant portion of a game, forgotten to save, died, and had to restore from an hour-old save point? Think about this for a second: I enjoyed the game so much that I was completely absorbed by what was going on, so of course I didn't remember to interrupt my gaming experience to bring up the menu and hit 'save' every five minutes. Essentially I got punished for having a good time playing the game by being forced to restore from an hour ago. ARGH. I get enough of that crap from my graphics editor crashing and losing all my unsaved work. Keep in mind that this in no way precludes making a 'hard game', or even a save system that can't be abused to gain player advantage. Nethack, arguably one of the most difficult games ever made, allows you to save your progress at any point. But you can only 'save and quit', and when you restore your savegame is erased. In short, this makes a save system that is easy to understand and in no way interferes with the player, but isn't immediately exploitable. The article gave a really good example of a bad save system, too: one of the recent Mario offerings for Nintendo DS only lets the player save when beating the boss at the halfway point or at the end of each 'world'. That could be up to five levels away, and the player feels like they're not free to put the game down because they haven't been given the opportunity to save. The worst part is that beating the game unlocks the ability to save anywhere on the world map. Surely there must be a reason that developers make gamers go out of their way to be able to save their game, but I can't think of one at the moment. If I can't save I either turn it off and am disinclined to come back, or I leave the system on until I can come back to it. All that effort of forcing me to work for my ability to save has gone to waste. Also, point number 8 in that article doesn't fit in any way. I thought we were talking about usability here - this is just a personal gripe about a tough game or two. Nobody makes an unbeatable boss. The design decision here is to get the player to be more aggressive in play style, and to make the 'life meter' take on a much more important role.

I started compiling the results from http://www.atariage.com/forums/index.php?showtopic=75267 and http://www.atariage.com/forums/index.php?showtopic=83072 as well as http://www.digitpress.com/eastereggs/pnpflashback2.htm into one big table. The result: http://kennedy.greg.googlepages.com/fb2compat.html Comments and corrections welcome - especially for games listed as "Conflicting Reports". I am curious if some of these are not really issues but actually replicate flawed 2600 behavior...

Following that line of thinking, I've already made the next Atari computer then. No, I'm not giving out the parts supplier list. That's awesome! Tell me more about it! Is it a Linux box running an emulator? Nathan Looks like it. Although there are some truly fantastic Atari 8-bit laptop creations which you have undoubtedly already seen: http://www.benheck.com/Games/Atari_800/Ata...00_laptop_1.htm (Ben Heck's first attempt) http://www.benheck.com/Games/Atari_800/Ata...0_laptop2_1.htm (Ben Heck's second try) http://www.atariage.com/forums/index.php?s...1&hl=1500xl (our own Beetle's laptop!)