Rybags

I'd love to try one. But better step-by-step instructions and illustrations/pictures are needed. I have about 50 old 30-pin SIMMs and 20+ EDOs kept for the purpose of upgrading old machines like my 800XL, 130XE, and Amiga 500.

Just installed it and worked fine, first go. My system (recently reinstalled Windoze) XP Pro (SP1), DirectX9.0c, VB6 runtime libs, .NET 2.1 Framework installed

1. Possibly the ribbon connector is loose or has oxidation. Clean it with VCR head cleaner. If that doesn't work, it could be anything from broken trace/s to fried resistors or a faulty POKEY chip. 2. I think later models just had boards instead of cartridges. Plus there were heat issues which made it more sensible to do it that way. 3. I'm fairly sure with memory boards that it was either largest ones to the front - or any order. 4. Closest?

I have the feeling that when he says "programs" he is referring to actually modifying the OS inside the disk drive. The "codenames" he refers to are probably extra sectors written to a track. I don't see how anything could survive a formatting though, since Atari drives use soft-formatting, and ignore the timing hole, which means that a track will start in a random place on the disk each time it's formatted. To do his tricks, he is probably just using the write track command, which would should allow things like duplicate or missing sectors.

The Cosmic Balance: http://vjetnam.hopto.org/index.php?frame=lett&dir=t&page=3 Cosmic Balance 2: http://vjetnam.hopto.org/index.php?frame=lett&dir=c&page=5 Atari 800Win+ is the best emulator: http://atariarea.histeria.pl/PLus/index_us.htm You'll probably need OS and BASIC ROMs to go with it, they're pretty easy to find.

I just use a ribbon cable of about 3 feet length and I've had no problems. So, it could well come down to which chip is used in the interface (both mine are home-made).

Yes. If interrupts use too much time, foreground processes suffer. You can get to the point where a keypress takes near a second to echo on the screen. The next stage is where so many interrupts can occur that a point of no-return exists since the stack can only hold entries for <90 IRQ/NMIs. Therefore, a badly programmed set of routines can cause havoc in a very short time.

Doom2D has already been thought of, and done: http://www.microfault.com/doom2d/doom2dus.html

If it's an immediate VBlank routine ($222), it runs with IRQs disabled, so it should be kept reasonably short. As an example, SIO at the normal speed (19,200 bps) means that 38.4 IRQs occur per PAL frame, which equates to one every 926 cycles. So, to avoid an overrun, you would have to use less than that while IRQs are disabled. If it's deferred ($224), it doesn't really matter how long. Just as long as you don't get too many going into the next VBlank period, else you'll get a lockup and/or stack overflow. But, you have to leave some cycles for the machine to do keyboard, screen I/O etc. The disadvantage of deferred routines is that if an IRQ was being serviced or if the CRITIC flag ($42) is set, then the routine won't be called. Possibly your best bet might be to use an immediate routine (vector $222) and use some of the logic that the OS uses (ie - re-enable IRQs after a while, so that I/O doesn't get disrupted). Also, you have the PAL vs NTSC consideration. PAL has almost 6000 more cycles available per frame and it's possible to create incompatibilities if your routine is too long.

The speed of your machine, and what you have running in the background can make a difference. For example, I had it running on a Celeron 500, it had that same problem at high-speed and was 95% reliable in standard speed in Win98. But the DOS-only version worked 100% well at any speed. I now use it on my XP-2400 in WinXP, no problems at any speed. You might want to try downloading PowerMenu. You can right-click windows and change their priority, it might help.

There was an article/interview in Creative Computing magazine, way back in Vol. 8 No. 8 - August 1982 with Chris Crawford, about his experiences in programming Eastern Front for the Atari 800 (article name "Eastern Front: a narrative history"). Worth a read. He explains how he included features like different seasonal conditions, and influence on units due to terrain and supply lines. http://www3.sympatico.ca/maury/other_stuff...tern_front.html http://en.wikipedia.org/wiki/Eastern_Front_(computer_game)

I was co-author of "Games for the Atari 600XL". Glad to see someone bought it (sales were nowhere near expected, thanks to crappy publishers and distributors).

It is possible to mix hires (gr. 8 ) and GTIA graphics (GR. 9, 10 or 11) on a scanline, but the hires has to be on the left hand side. The alternative is to use a multicolour mode, but 40 column text looks crap when done on a 4x8 matrix.

DIS6502 is one program which does it. You can grab it from Sourceforge: http://sourceforge.net/projects/dis6502 It can't be a fully automatic process. Disassemblers can't readily distinguish between code and data, so some intervention is required. It has the system equates for the Atari OS and hardware built in, so it cuts down on a lot of the manual work.

Why not just get some of the cheap clones that seem to be sold anywhere PS2 gear is sold?

In almost all cases, a utility can convert a single stage cassette to disk file. Multi-stage is entirely different, as the loader program can do what it wants so far as encryption, file format, and what addresses it loads into. The upside is that very few programs, once run, will load extra data from cassette, which means that it's easy to just dump out the RAM using a monitor or from an emulator. Assuming the program still works when you press Reset, and that it works on a 48K machine, all you would need to do is use the WRITE command to dump the following memory regions into 2 files: 0002 - 000D (so that the CASINI, DOSINI, DOSVEC and BOOT flags are saved) 480 - BC1F (all program memory) WRITE 02 0D DUMP1.DAT WRITE 480 BC1F DUMP2.DAT Then write a simple BASIC program which joins the files together, along with the appropriate binary file headers: 10 OPEN #1,8,0,"H:MYGAME.XEX":REM FINAL OUTPUT FILE 20 PUT #1,255:PUT #1,255:PUT #1,2:PUT #1,0:PUT #1,13:PUT#1,0:REM LOAD ADDRESS 0002 - 000D 30 OPEN #2,4,0,"H:DUMP1.DAT":REM FILE CONTAINING 0002 - 000D 40 FOR A=1 TO 12:GET #2,D:PUT #1,D:NEXT A:CLOSE #2 50 OPEN #2,4,0,"H:DUMP2.DAT:REM FILE CONTAINING 0480 - BC1F 60 PUT #1,128:PUT #1,4:PUT #1,31:PUT #1,191:REM LOAD ADDRESS 0480 - BC1F 70 TRAP 90 80 GET #2,D:PUT #1,D:GOTO 80 90 CLOSE #2:PUT #1,226:PUT #1,2:PUT #1,227:PUT #1,2:PUT #1,100:PUT #1,228:REM RUN ADDRESS $E474 (WARMSTART) 100 CLOSE #1 Just 2 slight disadvantages to this method: The file will be fairly big, and it won't work with most binary loader menus (including DOS).

Every cassette game should have an .XEX or .ATR equivalent for the emulators by now. Try Wav2Cas on this site: http://home.planet.nl/~ernest/atarixle.html Then, you can load the .CAS file quickly on the emulator. There are countless utilities to convert single-stage boot cassettes to disk. Although, it would probably be easier to write out the relevant sections of memory and create a binary load file.

It looks like a BNC connector (like network cards used to have, and what some monitors with seperate R,G,B use). They're still available, should be found anywhere you buy electronics supplies. Or better still, modernise the mod and convert the plugs to RCA.

2. The manual says MAC-65 uses part of page 6 - which part? Is it best to just avoid page 6 with this one? I read over the sample program for using page 6, but it left me a little confused. Probably the lower half. In fact, with BASIC there is a chance of the bottom half of page 6 being overwritten. If you use shorthand statements and they expand a line over 128 characters, then LIST and ENTER the program, it will overwrite page 6. 3. Are there any page zero bytes available for the user? It seems that the ones usable from BASIC and the Assembler Editor cart are used by MAC-65 It's usually safe to use the floating point routine's areas. Plus, there are some locations which are just temporary variables, and the locations used by CIO and SIO are usually OK. One technique is to have a routine to save and restore an area of page 0. Then have the program check for a certain key, which restores then executes a BRK, RTS (or whatever returns to the assembler).

No. They're both simple square wave generators which were common in the late 70's to mid 80's. The NES used a simple Texas Instruments PSG which according to http://www.old-computers.com/museum/computer.asp?st=2&c=866 could generate 2 channels of square wave, 1 of triangle, and 1 of white noise. Lots of computers and consoles used "off the shelf" sound generators. The Atari ST, Acorn BBC, and MSX were just a few. Since simple square waves sound much the same, and noise generators which don't use filters also sound similar, music on such machines can sound very similar.

The OS is only different between PAL/NTSC on the 400/800 (unsure about 1200XL). The XL/XE OS is the same in both cases. The only major things which are different anyway are the cassette I/O routines, since they use VCOUNT to determine the bitrate; the key repeat rate; and the cassette beep prompts. Really, they should have used the same OS when they went to Revision B in the 400/800, but chances are it might not have fit within 8K.

Most commercial games use a custom multi-stage boot loader, plus they don't usually adhere to DOS standards. So, it would be unfeasible in most cases. But, most games, even many which access the disk after running, have been converted to files anyway, and will work with most DOSes and formats.

Don't forget IK+. Never officially made for the A8 for some reason, but is slowly being converted: http://uce.pl/ikplus/

POKEY is the most famous of Atari's sound chips. It is resident in every 8-bit computer and 5200 console, and onboard some 7800 cartridges. It's also in many Atari arcade games from the early-mid 1980's. TIA generates the sound (and video) inside the 2600, and is also in the 7800. The sound from TIA is much like a primative version of POKEY. POKEY doesn't natively generate waveforms, only square waves, but has "distortion" and "noise" features. Waveforms can be done by software by directly forcing an amplitude level for a voice. The Atari 400/800 Hardware Manual contains detailed descriptions of POKEYs functions.

A shot in the dark here: try running it through a VCR first. Most have automatic gain circuitry which might alter the signal to the TV's liking.