Urchlay

Yep, that's it, and a better quality picture than I'd be likely to take (I'm no photographer, and this camera is awful...)

I actually have the Nov 1983 issue, so I looked through it... I think you're looking for "Gwendolyn", by Artworx. The ad is on page 103, color photo of a cute girl dressed as a medieval princess, in a jail cell, with some candles. The tagline reads "Gwendolyn: There are some things you keep searching for, beyond reason", and there are screenshots, including what could be a lion on a throne (well, a purple thing with a green head). The ad says "Atari, 40K disk, $27.95", no mention of an Apple version. I haven't got a scanner... but if it'd help, I could try to take a picture of the ad with my crappy little digital camera. The "Would you risk anything to save her?" isn't there... but it sounds familiar to me. Maybe it was a different ad for the same game, in a different issue of the magazine?

Well... it's realtime, and requires strategy to play... but when I used the name "realtime strategy" I was thinking of the genre of games like Warcraft, Starcraft, or Age of Empires: - Gods' eye top-down view of the playing field - Multiple resources that you have to gather, and that your enemy has to gather (so if you secure all the gold on the map, you can starve him out) - Multiple military units and unit types (and for each unit type, there's usually a counter-unit) Basically I was talking about a game where you play the general/commander/whatever of an army, which you must build more-or-less from scratch... In "Last Starfighter", you're a fighter pilot, and there's only one fighter (powerful enough to single-handedly destroy the entire enemy armada and sterilize all of their planets... more like a Death Star than a fighter, really) The game genre I'm talking about probably needs a more specific name ("realtime military simulation" or "realtime war game", maybe), since you need more than being realtime and having strategy to be what people call an RTS... Sim City is realtime, and you have to use strategy, but nobody calls it realtime strategy.

Back in the late 1980s I was really happy to have Turbo BASIC XL. I wrote a ton of stuff in plain BASIC, then learned Pascal and C on PCs... which kind of ruined Atari BASIC for me: no while loops, no if/then/else, no procedure/function arguments or return value, no local variables... Turbo BASIC at least has some of those. I probably would have *loved* Action if I'd been able to afford a copy back then. Instead I learned 6502 assembly, and still use it for the little bit of Atari 8-bit and 2600 code I write these days (DASM cross-assembler; am spoiled by modern machines, wouldn't ever want to actually write/edit code *on* the 8-bit!) On the other hand... writing that bit of BASIC checksum code was kind of fun.

I'm pretty sure nobody ever did a real-time strategy game for the 8-bit (a la Warcraft II or Command & Conquer). I won't say it'd be *impossible*, but it would definitely not be easy...

They're stored in a table in ROM... add one to the COLOR1 location to get COLOR2. That's for the 800 and XL though, no idea whether Omnimon uses a table (though it probably does), or where it's stored (could be the same place, doesn't have to be though). You could always find out the default colors for Omnimon for COLOR0 through COLOR4 (708-712), and search for those 5 bytes in sequence in the Omnimon ROM... could do it in a PC language, reading the omnimon.rom file, or in Atari BASIC or whatever, reading the emulated machine's ROM. According to "Mapping" appendix 12... It doesn't actually say how the calculation is done... but a little experimentation reveals that it's a simple checksum, modulo 65536. You add all the bytes from $C002 to $DFFF, and keep the bottom 16 bits... except if you're doing it on the Atari itself, the ROM at $D000-$D7FF actually appears at $5000-$57FF (only when you enable the self-test bit in PORTB though). For the high half of the ROM, you basically do the same thing for location $E000-$FFFF, except you skip $FFF8 and $FFF9 (the checksum bytes). However... you're doing this for emulator use... but if you've got the SIO patch and/or H: devices enabled, the self-test will fail anyway! The emulator's OS patches don't update the ROM checksums, so even with an unpatched atarixl.rom, the ROM self-test shows red bars in Atari800 unless you disable the emulator's patches and let disk I/O take forever IIRC, you're a BASIC programmer, so here's my attempt to do it in Atari BASIC. Try not to laugh, I haven't used BASIC in many years... 10 POKE 106,80:GRAPHICS 0:REM Set RAMTOP to $5000 so the self-test ROM won't confuse BASIC 20 IF PEEK(54017)>128 THEN POKE 54017,PEEK(54017)-128:REM enable self-test ROM (map $D000-D7FF to $5000-$57FF) 30 ? "Checking $C000-$DFFF..." 40 SUM=0:FIRST=49154:LAST=53247:GOSUB 1000:REM $C000-$CFFF 50 FIRST=20480:LAST=22527:GOSUB 1000:REM $D000-$D7FF (remapped to $5000) 60 FIRST=55296:LAST=57343:GOSUB 1000:REM $D800-$DFFF 70 ROMSUM=PEEK(49152)+256*PEEK(49153) 80 GOSUB 2000 90 ? "Checking $E000-$FFFF..." 100 SUM=0:FIRST=57344:LAST=65527:GOSUB 1000:REM $E000-$FFF7 110 FIRST=65530:LAST=65535:GOSUB 1000:REM $FFFA-$FFFF 120 ROMSUM=PEEK(65528)+256*PEEK(65529) 130 GOSUB 2000 140 ? "Press RETURN to exit...";:GET #16,K 150 POKE 54017,PEEK(54017)+128:GRAPHICS 0:REM disable self-test ROM 160 END 999 REM Checksum an area of memory, from FIRST to LAST, running total in SUM 1000 FOR I=FIRST TO LAST 1010 SUM=SUM+PEEK(I) 1020 IF SUM>65535 THEN SUM=SUM-65536 1030 NEXT I 1040 RETURN 1999 REM Print results 2000 ? " Calculated checksum: ";SUM 2010 ? " Stored checksum: ";ROMSUM 2020 IF SUM=ROMSUM THEN ? " Checksum OK" 2030 IF SUM<>ROMSUM THEN ? " Checksum BAD" 2040 RETURN Hm, that was kind of fun, it's been a while... Guess it's like riding a bicycle, it comes back to you. Might as well include an ATR image too: rom_checksum_atr.zip If you run that on a real 800XL with the stock OS ROM, or in an emulator with SIO and H: patch disabled, you should get "Checksum OK" for both blocks. With the SIO/H: patch, it'll fail, just like the built-in self test. Not sure what happens if you run it with Turbo BASIC (does PEEKing ROM show you the real contents of ROM, or the RAM-under-ROM that Turbo BASIC is using?)

It sounds like it should work... possibly you were off by one position, in the hex editor? Try running one of those 256-color simultaneous demos with the original palette and again with your modified one, should be able to spot which color(s) you actually changed. I'd sooner edit the OS ROM and change the default color there... modifying the emulator's palette would mess up anything (game, demo, etc) that happened to use color value 202. Changing the ROM default probably wouldn't affect any games/demos, since they pretty much all set the color registers to something other than the defaults. For the XL ROM, the default COLOR1 value is at $FB09 (offset $3B09 if you're using a hex editor on "atarixl.rom"). On the 800, it's at $FEC2 (offset $1EC2 in atari800.rom). Whatever you put in this location is what the OS will set COLOR1 (aka GR.0 text luminance) to, at boot, or whenever the GRAPHICS command is executed. One minor fly in the ointment is that the XL self-test will think the ROM is bad, if you change it without changing the stored checksum... but this won't hurt anything (you'll just see red bars in the memory test, if you should decide to run it). I just tried editing byte $3B09 of atarixl.rom (changed it to $CF) and ran it with the Atari800 emu, and BASIC comes up fine, with nice bright text.

Photoshop stores more than 8 bits per color, but most (all?) PC video cards only actually display 8 bits per color (RGB, 24-bit, or 32-bit with an alpha channel). The extra precision in Photoshop is used to avoid roundoff errors, and possibly for very expensive printers that can do more than 8 bits per color (assuming they exist, I don't know). Making an emulator use more than 8 bits per color wouldn't help because unlike Photoshop, the emulator isn't doing math on the colors, it's just displaying them. The thing about emulator palettes is that there are so many other factors that can affect the perceived colors: - Monitor make/model and type (CRT vs LCD, analog vs digital video) - Monitor brightness/contrast/gamma/color-temperature settings - For some video cards, color calibration and gamma settings in the driver - Even the cabling might make a difference, for analog SVGA Also, when you're comparing the emulator's video to the Atari's, you're seeing the Atari displayed on some sort of monitor/TV, which also has its own set of color/brightness/tint/etc controls... not to mention, the different A8 models have wildly different video output (800, 1200XL, early/late model 800XL, XE all have different displays, compare them & see). Then there's RF vs composite vs s-video... and the fact that the Atari has a color adjustment that can get out of whack... even the Atari power supply voltage can affect the colors. What looks like a "real Atari" depends on what you're used to. I guess what I'm saying is that you'll never design the One True Palette that will make everyone's emulator look like the real thing. The best you can do is build a palette that makes your emulator (running on your PC setup) look like your Atari... but give that palette to someone else, and it will look wrong to him unless he's got exactly the same Atari and PC hardware, with all the settings set the same way. It doesn't mean you should stop trying, it just means your solution will probably only work for you (which is why the emulators support user-defined color palettes in the first place). Forgive me if I'm telling you what you already know... I spent much time beating this particular horse before I found out it was dead

Steve, aka Classics... atarimax.com. I'm a satisfied customer. As to the "prohibatively expensive" bit, well, it depends on what you consider expensive. I did my own video mod for maybe $10 worth of parts plus a day of my own labor (would take less time if I were better at soldering), and paid Steve $250 for the rest: 32-in-1 OS, internal MyIDE, 256K RAM, and internal SIO2PC. $250 might be expensive or not, depends on your income. At the time, I could afford it, and now my 1200XL is like a Cadillac Steve's in the US... if you're in Europe, talk to Beetle. His work is famous on this forum...

Hm, it won't work with the "load xex" menu option, but if you copy the .xex to a DOS disk and boot it, it'll run fine... Apparently Atari800win's XEX loader hates something about my "loading" intro screen. Were you getting a brief flash of a "loading atari artist" screen, then a black screen, then BOOT ERROR? Anyway, here's an ATR image that works with Atari800win. It's DOS 2.0, with the same xex file, named AUTORUN.SYS. atari_artist_atr.zip Now that I think of it... you don't want to use the xex by itself anyway. If you do, you won't have DOS loaded, so you won't be able to save your drawings.

Quickie conversion from cart to xex: AtariArtist_xex.zip Only tested with Atari800 emulator... I don't have a real touch tablet anyway

You probably got a syntax error... I posted a non-working version Easy enough to fix: line 98 ends with "$DEBUG;"... either change it to "if $DEBUG;", or get rid of the $DEBUG, or just delete the line entirely. Sorry about that

No, but now that I think of it, I'd love a version of Asteroids Deluxe for the A8... preferably one with graphics like the 2600 Asteroids (multicolor, no attempt to simulate the arcade vector display), but with the extra enemies (cube, wedge) behaving as they do in the arcade game. Maybe I'll get off my lazy ass and code it one day...

I've always preferred Atari 2600 Asteroids to the arcade version... but I never liked the 800/XL/XE Asteroids much. I'm not sure it's *better*, but the 8-bit Space Invaders is a lot prettier than the arcade version (colors, smoother animation). If only they hadn't left out the shields... The 8-bit Defender is definitely a lot easier to play than the arcade version. The arcade game has (slightly) better graphics and sound IMHO, but the control scheme means the only way to get good at it is to spent $lots of quarters, or own the cabinet yourself. If I'm allowed to stretch reality a bit and consider Dropzone to be a port of Defender, then I'll say I like Dropzone better than the original... Most of the arcade game ports on the 8-bit were good enough that I didn't feel like I was missing out on anything. Centipede, Millipede, Pac-Man, Joust, Zaxxon, Donkey Kong, Pole Position, Gyruss, Qix were damn fine ports... but I never thought they were better than the arcade versions. Actually I might like Pac-Man better on the 8-bit, just because you can start the game on the fast "key" level instead of having to play through the first 5 or so glacially-slow fruit levels.

Yes No, you need a PC with a serial port... Good idea! You've got a pretty good "starter kit" of software already... if you're planning to open the boxes, that is. I'd be surprised if the boxes don't say whether they're disk, tape, or cartridge. The "States and Capitals" is definitely cassette: it plays audio from the tape while the program runs, which is a pretty neat "multimedia" thing that AFAIK is unique to the Atari. If you decide to get an Atari tape drive, don't buy one (not even a NIB one) and expect it to actually work, unless it's from someone who's restored it. The drive belts are usually dry-rotted or stretched out of shape after all these years... gory details here: http://www.atariage.com/forums/index.php?showtopic=105976 Also, if I'm not mistaken, "Pool 1.5" won't load on an XL/XE machine without the Translator disk.

That's an interesting idea, but if I think of a practical way of doing it I can't come up with a solution (if there are three duplicates, the script would link what to what?)... if you have something on your mind, I'd appreciate your feedback on this. You could just have the script pick one at random, more or less (first one found, really). Arrange things so that, for each duplicate, you end up with a list of them (array, or a text file with one filename per line, or whatever). Once you have them in a list, just keep the first file in the list, and replace all the others with links to the first one. Actually, a while back, I wrote perl script that does this... attached: find_dups_pl.zip If you want to load a single executable, just choose it from the AtariSIO menu as though it were a disk image. AtariSIO will create a disk image containing the file, a MyPicoDOS bootloader, and a PICONAME.TXT containing the long filename mapping... when you boot from it, MyPicoDOS will display the long filename, and automatically load the executable (because it's the only file on the disk). To create an ATR image with lots of files, possibly having long filenames, use the dir2atr command (ships with AtariSIO, run with no arguments for help). Example ATR image attached, I created this with "dir2atr -b MyPicoDos404B -p test.atr mydirname/". When you boot it, you'll get a MyPicoDOS menu with long filenames. Example disk image with long filenames: test_atr.zip Talk to Hias (user HiasSoft on atariage), I'm sure he can think of something for you to do

I think you've hit the nail on the head... Without hardware mods, none of them is perfect.

Next time, instead of deleting the duplicates completely, replace them with symlinks or hard links back to the original file. Your script could keep the file with the longest name, and replace any shorter-named dups with a link. AtariSIO handles long filenames pretty well, actually, if you're using a recent snapshot instead of the ancient version on the main page... Snapshot directory here: http://www.horus.at/~hias/atari/atarisio/

41256s won't work. If you can find a place that has a large pile of old PC parts (computer junkyard, or a friend who's a packrat), look for ISA video cards. I found some 4464s on one, and they work fine for my 64K upgraded 600XL. I didn't even have to desolder them: they were in sockets on the old vid card...

This probably won't help you with your current situation, but you reminded me of something from the olden times... A *long* time ago, this happened to a friend of mine. He wasn't typing code from a magazine, he had written a fractal generator (Koch curve plotter), and would have lost many hours' work... If he'd had a tape drive, it wouldn't have been a problem (CSAVE), but all he had was a 1050 with no DOS booted. Fortunately he had a formatted blank disk handy... He called me, and I came up with a short routine that worked something like this: S=1 FOR I=0 TO 29999 ? CHR$(125) [clear screen] LIST I ? "CONT" POKE 842,13 [turn on "automatic return key mode"] POSITION 0,0 INPUT A$ [now A$ is empty if the line didn't exist, or else contains a line of code] POKE 842,12 [turn off auto-return mode] IF(A$<>"") THEN [add an EOL, write the line of code to disk sector S using SIO, then S=S+1] NEXT I (this is from memory, was almost 20 years ago and I don't have the code any more) I had him add the code to his program, starting at line 30000... which meant I had to *read* it to him over the phone while he typed it in, then have it read it back to check for typos. Finally I had him run "GOTO 30000", and the program chugged away for a few minutes, writing to the disk... After it finished, I had him boot DOS, and type in another program that read and "entered" one line of code from each disk sector (also using POKE 842,13)... amazingly, it worked perfectly! Lucky for him, he had fewer lines of code in his program than there were sectors on a DOS 2.5 enhanced density disk, so the whole program was recovered. But you tell that to the kids today, and they won't believe you... Now get off my lawn!

A couple of thoughts... The resolution (sensitivity) on the Atari tablet might be too low to be useful for a modern PC. Unlike a mouse, tablets report an absolute position, which is then divided by the screen resolution. If you're using a 1280x1024 display, the tablet needs to be able to detect at least 1280 distinct horizontal postions and 1024 vertical. The Atari tablet acts as a paddle, which on the Atari only has a resolution of 228 positions on each axis, due to the way the Atari paddle-decoding hardware works. So... the Atari tablet might or might not be sensitive enough to work as a PC tablet. It wouldn't have to be that sensitive, since it only was designed to work with the Atari paddle circuit, but it might happen to be anyway. You might also experience lots of jitter (though that could be corrected in software). If you had a way to hook it up, you could just try it & see. If you've got a PC with an old-style game port, it wouldn't be hard to wire up an adaptor that connects the left and right paddle lines to the gameport's analog joystick X and Y axis inputs... but then you've got a PC joystick device, not a mouse. Your OS might support using an analog joystick as a mouse, though. Linux can do it, not sure about Mac, I've seen it done on Windows but don't know if it took a special driver or just what came with the OS. BTW, if you don't have a gameport, you can get a gameport-to-USB adaptor. Radio Shack used to sell them, probably still does. I have one I bought 4-5 years ago and it works pretty well for things like flight sticks and the Gravis Gamepad Pro (though it only supports 2 of the buttons, not a problem for the Atari touch tablet). If you could find a modern tablet that's about the same size & shape as the Atari one, you could replace the Atari tablet's innards, which would be guaranteed to work... but then it won't work on an Atari, of course. If you were just wanting to use the tablet with an Atari emulator, you could use a Stelladaptor. Easy, no special hardware or software needed, but it'd only have 228x228 resolution, not useful for general-purpose PC mouse use.

Rev A has an editor lockup bug that triggers when lines of code are deleted... rev B fixed that, but added a new lockup bug that triggers when lines of code are added (happens more often, because you tend to add lines to your program more often than you delete them). You're right about the other thing though: programs grow by 16 bytes every time you save them in rev B... but AFAIK, it's only the on-disk copy that gets the 16 bytes of junk. Running SAVE over & over again won't make the current program in memory grow (each SAVEd copy will have 16 bytes extra though).

BASIC Rev C vs. Rev B isn't really an issue unless you're planning to write lots of BASIC code. The rev B lockup bug only occurs when editing programs, not running them. And if you *are* planning to write lots of BASIC code, you'd be better off using Turbo BASIC or maybe OSS BASIC XL or XE.

You're right, that's strange... Probably I'd try swapping keyboards with one of the other 1200XLs, see if the problem follows the keyboard, or stays on the same machine with the new keyboard. Also, maybe your new 1200XL has some mod(s) in it that are causing it to act weird...? Maybe the OS ROM has been replaced with the 800XL version? (not sure whether the 800XL OS supports the 1200XL ctrl-F1/F2 functions, though it *does* support the F1-F4 keys on the keyboard, for sure).

Best software to use for Linux + SIO2PC is AtariSIO: http://www.horus.com/~hias/atari/atarisio/ Get the version with the most recent date (071014 at the moment) Unless things have changed drastically in the past year, Linux can't read SD cards... doesn't stop you from using the SIO2SD though: it and Linux both support the older MMC cards. Just something to be aware of...