Urchlay

Hm. I had a friend with a 600XL + 1064, years ago, and we never found any software that would run on my 800XL but not his 600XL... granted, this was a long time ago, so maybe the compatibility problems only show up with newer stuff (I assume you mean recent releases, not old stuff from the 1980s). It might be that your friend's 600XL or 1064 has something wrong with it... possibly a dirty/loose connection that's causing it to fail occasionally, so the machine boots up in 16K mode sometimes? (and/or crashes with garbage if it comes disconnected while you're playing a game)

Don't think anything's missing from that, but IIRC it's got quite a few OCR errors (number 1 showing up as letter I, that sort of thing). The new one, when you're reading it in the browser, you're looking at the actual scan, so you don't have to figure out that "Oh, this word IO is supposed to be the number 10" etc etc. On the other hand, the atariarchives.org one is normal HTML (can use standard browser stuff like ctrl-F aka "find within page"), not a limited Flash-driven interface with "you must log in to download this document".

A bit of (hopefully) constructive criticism: For sample code, please please please don't use stuff like "mva" or "pla:tay". Some of us don't use whatever assembler you're using that supports this non-standard syntax (MADS, is it?). I think sample code should be as generic as possible, to make it useful to as many people as possible... Also, I'd say instead of "lda $d300", it makes the code easier to read if you define "PORTA = $d300" at the top, then "lda PORTA" in the code... Actually, if there's going to be a code repository with lots of people contributing to it, it might not be a bad idea to have someone write up some coding style guidelines. Since the sample code is meant mostly for other humans to read and learn from, it'd help if all the code were written in the same style... Just my 2 cents, feel free to ignore, of course. All of this is meant in a friendly way: I'm not trying to be rude or snarky, I just have some experience writing "teaching" code and I'm trying to help...

I thought the Maxflash cart could be loaded with games/whatever using only a PC? Floppy or hard disk images definitely can be created entirely on a PC (or mac, whatever) and served up to the Atari with APE or AtariSIO.

MyPicoDOS from HiasSoft: http://www.horus.com/~hias/atari/#mypdos works with the joystick

Hey, that's not a bug, it's a feature!

The belt problem with the 410 is a design problem: the belt wraps around a spindle at an acute angle, and when the 410 sits too long without the motor moving, the belt develops a kink in that spot... you can assume any 410 found in the wild will require a new belt, so I wouldn't pay much for it if I were you.

All the local Atlanta-area thrifts have a "we don't take computers less than a Pentium or games older than a Super Nintendo" policy. If someone donates such items, they *smash them with a hammer* and toss in the dumpster. No amount of begging or offering money on my part could change their minds

I vaguely remember your original thread about this, but can't remember if this question was asked: Is there any real reason why you couldn't have just torn apart a crappy old $5 PS/2 keyboard and used its encoder, instead of shelling out for the Hagstrom one? Any decent OS should already be able to remap keys without using Hagstrom's add-on software (maybe not as convenient or easy to set up, but should be do-able)... and if you know where to look, you can usually find old PS/2 keyboards for less than $5 even (am referring to the lightweight throwaway ones, not real PS/2 keyboards from IBM). To the original poster: if you get it working as a PS/2 keyboard (with or without a Hagstrom encoder), you should be able to use a cheap PS/2 to USB keyboard adaptor (usually less than 10 bucks at Fry's)

I wore out my 1027 in high school... For whatever reason, back then, high school teachers mostly refused to accept papers/assignments/whatever if they were done on dot-matrix printers (I had one teacher say "you're not allowed to use a computer, but typewriters are OK"). The 1027's output looked typewritten, I never got a complaint. After a couple of years, it developed a glitch, where every once in a while it'd print a garbage character made of the halves of two adjacent characters. This got worse until it became impossible to ever print a whole page without it happening... Does that sound like the printhead wearing out? (Not that it matters, at this late date, but I always wanted to know why my poor 1027 died)

I think it's probably fair to say that *no* original 410s or 1010s are in working condition, regardless of how they were stored, unless the belts have been replaced. I'd even go so far as to say, don't believe any auction for a 410 or 1010 that says "tested & working" unless the seller mentions that the belts have been replaced...

Have you taken it apart yet? 1010s (and 410s and probably the XE-styled Atari tape units) are belt-driven, and the most likely problem with yours is that the belt has degraded most of the way back to crude petroleum... A while back I was trying to get a couple tape drives working, and tried a few different sized belts. If you search this forum, you can probably find the old thread where I posted the belt sizes I used... though I never did get my 1010 working perfectly (about 1 in 3 loads will fail for no reason I could figure out). Better results with the 410 (still not perfect, probably it wasn't perfect when it was new though). As far as the ebay ripoff goes... best you can do is probably leave negative feedback. The dollar amount is too small to make it worth getting on a plane, flying to his house, and kicking the crap out of him (like the end of "Jay & Silent Bob Strike Back"). Eh, and post the seller's account name here. If he's selling lots of broken A8 stuff as "tested/working", well, readers of this forum are his potential victims, so word will get around... (I know you posted the auction link, includes his name, but those things expire)

Not likely to ever happen. The OS, DOS, and game code is still under copyright (we can argue about whether it *should* still be protected by copyright or not, but the law still says it is). Emulator authors historically have avoided including copyrighted ROM/disk/etc images with emulators, to avoid getting sued. Any such lawsuit would affect the whole emulation community (at least indirectly), not just the one author being sued. Atari++ comes pretty close though: Thor actually wrote his own OS ROM and DOS replacements (open source code), so Atari++ will run with no ROM images (and is capable of running a large percentage of games that way, too). Another reason not to include games: there are an awful lot of them. The Holmes archive is 3 CDs (1.8 gigs or so), over half of which is games, and it's outdated (plenty of new games been written since then). Thousands of games... it would be a lot of work to gather them all together, decide which version is the "definitive" version of each, make sure they all work... even just naming them with a consistent naming scheme is a lot of work. Actually, if I'm reading the Atari++ license correctly, there's nothing stopping you from creating your own "emulator + all games" package based on it (other than the copyright status of the games and OS/DOS code), so long as you give credit to the original author. That's how free/opensource software works: someone wants something, so they make it, and give it away in case anyone else also wants it...

I managed to get it running under SDL on Linux actually... here's a diff, meant to be applied to a clean Atari++ 1.55 source tree: atari++-1.55-vbxe-linux.zip After applying the patch, build atari++ with something like "./configure --enable-X11=no"... actually I can't find my notes on this, I seem to remember having to disable something else (curses maybe?). Anyway the VBXE changes only apply to SDL, not the straight X11 frontend. According to the author though, the VBXE code breaks other video-related things (fullscreen maybe, can't remember now), so he wasn't going to ask you to include the code in mainline atari++ until he'd sorted out those issues. The only "win dependency" in the VBXE code is a few MSVC++ specific language features (or misfeatures)... all I did to get it working on Linux was fix the compile errors.

So, no more need for the H: drive? Cool.

Find a utility for your PC that can create the giant ATR image for you, invoke it from your Makefile or batch script (whatever you're using to automate your build process on the PC side). On Linux, you can use "dir2atr" from HiasSoft's AtariSIO package. I don't know of an equivalent tool for Windows or Mac, but possibly you can build just the dir2atr tool for Windows (the actual AtariSIO driver is Linux-specific, but the tools should be portable). There are various Windows tools that can create and/or copy files to an ATR image, but not all of them can handle 16MB images, and not all of them can run non-interactively (e.g. you run it with some command-line arguments from within your build script). You don't want to be dorking around with a mouse, manually dragging the same files to the same place, over & over again... (Note: there's another tool called DIR2ATR.EXE for DOS, but it's not the same thing: It appears to be interactive only, and I'm pretty sure it can't handle large ATR images) Basically, the procedure would be something like... 1. Create a large ATR image that's got a bootable MyDOS, call it "image.atr" 2. Edit and compile your Atari code 3. Copy the Atari executable and data files into "image.atr" (name the executable AUTORUN.SYS if you want) 4. Start up your emulator, with "image.atr" as D1: 5. Exit the emulator, goto step 2 Steps 2 to 5 above should be automated (if you're on Windows, use a batch file) and bound to a keystroke in your text editor, so when you're ready to test your code, you whack F9 or something, and the latest version of the code is running in the emulator within a second or so... I don't know how to set up a Windows environment to do this, but it's definitely possible.

Locations 42161 and 42979 are just RAM, under disk-based Turbo BASIC. You won't always get zero there, especially if your program uses graphics modes 8 or 15... or you might end up using that area of RAM for player/missile graphics or a custom font... Someone mentioned too that there's a cartridge-based Turbo BASIC. In that case, those locations are part of ROM (no idea what's there, but it's almost certainly not a couple of zeroes). Also, the RAMTOP or RAMSIZ methods would fail with cart-based Turbo BASIC. If you're just concerned with the speed of delay loops, replacing them with a timer based on RTCLOK or one of the countdown timers is a better bet (see sample code above). About the only other reason I can think of for a program needing to know which BASIC it's running on, would be if you'd written two versions of the program (one for regular BASIC, and one with extra features that uses Turbo BASIC commands). In that case, you could write a loader program that figures out which version of the real program to load... probably this is more trouble than it's worth, though.

I have a theory on why this doesn't work... The H: device driver is built into the emulator, and it only supports a subset of the CIO operations... and it's the same device driver, no matter what DOS you're running. In Atari DOS 2.0S, when you go to load an executable from DUP.SYS, it does something like: 1. Use the CIO OPEN command to open the file 2. Read the contents of the file using CIO "READ BLOCK" commands 3. Use the CIO CLOSE command to close the file 4. Jump to the start of the loaded code... All the CIO commands DOS 2 uses are the standard ones for open/read/close, which are supported for the D: devices by DOS.SYS, and for the H: device by the emulator itself. Note that Atari DOS does NOT have a CIO call that means "Load and run an executable file" (the menu option exists, but it gets the job done by making several CIO calls for open/read/close). In MyDOS (and also in SpartaDOS), the D: device driver actually supports an extended CIO command that means "Load and run an executable"... I can't remember the command number, but you can even use it from Atari BASIC with the XIO command. When you use the "load binary file" option from the MyDOS menu, it makes a single CIO call (the MyDOS-specific "load/run executable"). MyDOS's D: driver understands that, and loads the file... but the emulator's H: device driver doesn't understand it, so it returns an error... ...or perhaps MyDOS's DUP.SYS is actually checking to see if the filename starts with D: or not, and if not, returns the error immediately without even trying to execute a CIO "load and run" command on the H: device. The only reason I think this might be possible is that, if I remember correctly, error code 168 is MyDOS-specific, not in the set of error numbers DOS 2.0S uses (I may be wrong about that though). The way to fix it: Modify the emulator so that its H: device understands MyDOS's extended CIO call for "load and run". However, if the DUP.SYS code is actually checking for D: in the filename, this won't help (you'd also have to modify MyDOS to remove the check). None of the above has been tested, it's all theoretical (pulled out of my brain), so I might be 100% wrong... but I've now gotten interested enough that I'll go and check, and post my results here

Using the "automatic return key" mode (POKE 842,13), not by embedding a tokenized turbo BASIC command into the program (it'll either fail to load, or else crash, if you try to run it on plain BASIC). The only thing that sucks about just checking RAMTOP is that it won't detect OSS BASIC XL/XE. RAMTOP will be 160 with a cartridge in, but execution speed is closer to Turbo BASIC's speed (if speed is even what he's concerned with). Eh, or am I wrong? I haven't used BXL in years, do the OSS "super cart" languages make the RAM inside the cart available as regular RAM?

PEEK(106) (aka RAMTOP). With Atari BASIC, on a machine with 48K or more, it should return 160... with Turbo, it should be 192. If you get less than 160, you're running on a machine with less than 48K. Turbo won't work on an unexpanded 600XL or a 400/800 anyway, so you can assume plain Atari BASIC in that case. It's possible that someone ran another BASIC program that lowered RAMTOP before running yours (maybe to make room for P/M graphics or something), so the documentation for your program should state that your program needs to be loaded either right after boot, or right after pressing Reset. ...Another way to check: You can look at the OS revision bytes (see Mapping the Atari) to determine whether you're on a 400/800 or an XL/XE. If you're on a 400/800, obviously it's not Turbo. If you're on an XL, check PEEK(54017) (aka PORTB). If it's an odd number (if bit 0 is set), the internal BASIC is enabled, so you must be on that. Otherwise, assume Turbo. Actually both of these methods will get confused if you write a program that uses them, then run it in the OSS BASIC XL cartridge. If your main purpose for knowing which BASIC you're running, is to set delay counters... you might just want to start the program with a loop like: 10 POKE 20,0 :REM low byte of RTCLOK 20 FOR I=1 TO 10:NEXT I 30 DELAY=PEEK(20) DELAY will be the number of jiffies (1/60 sec NTSC, or 1/50 on PAL) that the loop took. You can work out whatever calculations you need to, from there. An even better idea: forget using empty FOR loops for timing. Instead: 993 REM Caveat: Untested code! 994 REM 995 REM Timing subroutine. Call with 996 REM SLEEP set to the number of 997 REM seconds to delay. 998 REM Example: SLEEP=1:GOSUB 1000 999 REM Allowed SLEEP range is 0 to 4 1000 IF PEEK(53268)<>15 THEN DELAY=SLEEP*50:GOTO 1010 1005 DELAY=SLEEP*60 1010 POKE 20,0 1020 IF PEEK(20)<DELAY THEN 1010 1030 RETURN This should let you delay for more-or-less the same length of time, regardless of which BASIC version or TV standard you're using.

Something related: I went to Rat Shack and bought a "solder pen", which turns out to be a magic marker that writes conductive paint instead of ink. Very cool, fixed a sick 1200XL keyboard with it.

Star Raiders II looks like it uses GTIA mode 10 for the planet surface, when you're in orbit.

Not only is it accepted, trying to RUN the program will trigger behaviour just like the infamous revision B lockup bug (RESET gives a READY prompt, but anything you type causes it to freeze until you RESET again). I suppose for the same reason, program memory gets corrupted and the interpreter gets lost in never-never land trying to find line 32768 (the direct statement fake line number). The only trouble I remember having with revision C wasn't caused by the rev. C ROM... I used to run revision C BASIC in RAM, being too poor to buy a cartridge of it. During a GR.0 or clear-screen, the OS had a bug where it would clear the first 64 bytes past the end of screen memory, aka the start of BASIC itself. ROM BASIC of course isn't hurt by this, but mine was in RAM... the symptom this caused was that NEW wouldn't work any more. First time it happened, it was quite a head-scratcher. The fix for it was to lower RAMTOP by 1K (POKE 106,PEEK(106)-4:GR.0) before switching to RAM-based BASIC... or else use Turbo BASIC XL, which was nicer anyway. This one is almost cool: 10 FOR I=1 TO 4<esc>FOR J=1 TO 4<esc>? I;" x ";J;" = ";I*J<esc>NEXT J<esc>NEXT I LIST 10 FOR I=1 TO 4 FOR J=1 TO 4 ? I;" x ";J;" = ";I*J NEXT J NEXT I The code runs fine, and the escapes get printed as carriage returns, making the code a lot more readable... too bad there's no way to edit a line of code like that

http://home.planet.nl/~ernest/atarixle.html Download the wav2cas zip file, have a look at WAV2CAS.TXT inside the archive.

Hey, you actually know what you're talking about, no fair (Actually, if your explanation's not oversimplified, I just learned something too) Bleah. I have too many commercially released VHS tapes and too limited of a budget to re-buy them all on DVD (especially as I'd have to buy them all again on blu-ray in a couple years)... And the BBC is taking *forever* to release some of the old Dr. Who episodes on DVD, so VHS is the only way to legally get them (or was, back when BBC was still doing VHS releases).