Rybags

An Atari conversion would be fairly straight forward provided the source code is neat and documented. An Atari running in multi-color text mode (or GR. 0) runs about 40% faster net speed over the C-64. The fact that colour memory scrolling isn't needed, plus the fact that vertical scrolling can be done in BASIC thanks to the versatility of Display Lists means lots of cycles are free, which can be devoted to "harder" tasks like rendering a ball using multiple players (as opposed to just having to overlay a few sprites), and DLIs for colour-changing.

Uprights: Rygar Space Invaders Black Dragon Defender Gauntlet 2 Cocktails: Frogger Galaga Asteroids Dig Dug Robotron Sit-downs: Pole Position 2 Daytona USA Road Blasters Pinballs: Terminator 2 Getaway: High Speed 2 The Simpsons Pinbot Cyclone Space Shuttle Cue Ball Wizard

There aren't really any restrictions when creating a DOS executable, but you would just have to ensure not to overwrite disk I/O buffers (which normally reside at the top of memory that DOS uses). Another consideration is the fact that many DOSes have the DUP.SYS program which uses more memory again, and could possibly be overlayed by your program.

I've not experienced lag using any of my tuner cards (I have 4, including the VIVO in my AGP card). Lag would only be an issue if the software has a selectable FPS, or overlay/preview mode. Just playing with those options should help. A bonus with some tuner cards is that you can display the overscan area. I have a Compro DVB-T300, it's a hybrid card ie - it does analog and digital TV, as well as S-Video and composite input. It works great with the S-Video output I added to the 130XE. Just a pity the drivers and software tend to be so unstable, but it's an issue with lots of tuner cards. Regardless of what you go for, I'd recommend doing 3.5mm audio plug and the S-Video mods to your machine, or at the very least use an adaptor plug for the Atari's monitor output. VirtualDub is also a handy piece of software to get, as are the Windows Media Capture tools (free from MS). 50/60Hz should be selectable with all cards. Some software omits it (strangely), but WMVCap is able to use the WDM Driver dialog to select PAL/NTSC. Finally, DirectX 9.0b has some issues which can affect tuner/capture cards, so updating to 9.0c might resolve some problems.

The RAM at $D000-$D7FF is not available. The C-64's processor is able to access the RAM and character ROM under it's hardware registers thanks to the I/O registers built into it's 6510.

It is dependant on whether you have DOS loaded, and whether you intend on running the program while the source code is in memory. And, the highest address will depend on RAM size, if a cartridge is present, and which screen mode you intend on using. $600 is fine but is only a 256 byte area if DOS is loaded. And even if there is no DOS present, LOMEM will be at $700 (although you can change it if you want). A seldom used area is the cassette buffer. 128 bytes which can come in handy for variable storage, or short subroutines.

Developing on the emulator would be fine. The only real issue might be exact cycle emulation, but Atari800Win+ claims to do it, and version 4.0 seems to correctly emulate switching GTIA modes via GPRIOR mid-scanline (as used in some demos). If you're running short on cycles for time-critical DLI routines, there are some workarounds: - you can use z-page to store A,X,Y instead of the stack. It saves some cycles but a subsequent DLI before the first one returns would corrupt the registers. - instead of using the WSYNC register you can pad out with NOPs to create the delay you need. - you can use self-modifying code. - use multiple DLI routines if similar code is used in multiple DLIs. - as a last resort, copy the OS into the underlying RAM and use your own NMI handler. But that will make the software incompatable on 400/800 and XL/Es with < 64K. Cycle counting: The trickiest part (which I don't really understand totally) is memory refresh. ANTIC supposedly does less refresh cycles in widescreen mode (or normal width with scrolling). Other than that confusing part, the Hardware Manual has the correct info.

Much faster loading speed than cassette. But then again, punched cards would be faster than a 410/1010.

Lots of computer peripherals and electrical appliances have no on/off switch. Best solution: get a powerboard with individual switches (and preferably surge protection) and run stuff off it. Lots of "wall warts" use power even if nothings plugged into them anyway.

Many years ago I found that when playing samples, using wide-screen with a bigger display height actually sounds better than on a standard screen. Undoubtedly because the extra DMA cycles help to smooth out timing inconsistencies if you're just using simple short delay loops.

On a real machine, use the built in debug in the Atari AsmEdit cartridge, DDT in MAC65, or an OS replacement with monitor like Omnimon. On an emulator it's a bit easier as it has a built-in debugger (Atari800Win, that is). Plus if you want, it's easy to take snapshots of memory. In any case, 6502 is a very simple language with only 3 main registers and limited number of addressing modes. The simplest way I've found is to debug routines before incorporating them into your main program. Use test data, and keep the thing documented and it usually falls together nicely.

Can't be done. Cartridges only have enough address lines to allow 16K of addresses. Aside from that, bank selecting would be the only option. And even then, as a minimum you have to use $B000-BFFF for ROM. I imagine their might be some way to have RAM there, but don't know if a method exists. Early bank select schemes used the address range $D500-D5FF, and output a signal on a line called CARTCTL (I think) which bank-select hardware can use to employ bank-switching on the cartridge. I've heard of systems which allow a small ROM at $5000, but don't know if they existed on production 800s.

It's not really necessary to modify display lists. PAL equally distributes the extra blank lines each end of the playfield. The only real issue is that Display Lists in NTSC are more likely to fall into overscan areas at the top/bottom. I suppose the best method to quickly examine a carts region would be a quick program which reads the byte at the proper offset in the file.

That description sounds good. Almost every game out there constantly checks the console buttons in VBlank, and often START, OPTION or SELECT will terminate the game in progress. But with the 8-bit, the OS never scans the console keys, other than during the cold start (or when Self-test is running). With IBM mainframes, "console" refers to a 3270 type terminal which can issue OS commands, so the origin could well coincide with the first CRT terminals.

The PAL speed is wrong there. PAL runs at 1.7784 MHz. 114 machine cycles/line (same as NTSC) x 312 lines x 50 Hz. PAL systems have black displayed in the areas outside the normal 240 lines which a display list can generate. In my experience on TVs, this normally equates to about the height of a GRAPHICS 0 line, top and bottom. Programs written for NTSC are usually fine for PAL, except for the well-known slowdown because of 50 vs 60 Hz. The reverse isn't always true, since PAL has a greater number of cycles between VBlanks. But in the Atari 800's case, I've rarely heard of there being cross-standard problems other than with some Demos. Interesting about the PAL flag on 5200 carts though, I never knew they had them.

Add De Re Atari to that list of books. It's been scanned in you should fairly easily locate a download. Playing with existing programs is a good way to learn too. Start out with BASIC games, then move on to BASIC+ASM games. http://www.atarimania.com has quite a few BASIC games.

Well, someone who knows would probably be Nolan Bushnell, or a manager or engineer working for the original Atari around the late 1970's. Or, Jay Miner who could be regarded as the father of the machine, but he's been dead for some time now. Or, maybe someones scanned in the owners manuals from the 400 or 800 system. I only have the printed version, for the 800XL.

Most likely because in the early days they were almost exclusively used by game cartridges. Also, most computers had fairly basic keyboards. And most consoles of the era had buttons with similar functions. And, from a programmers point of view, Start/Select/Option are scanned via different means to the main keys.

If you're having problems LISTing after ASM/running I'd suspect your source is getting overwritten somehow. Type "SIZE". It tells you the start and end of memory currently in use. You can also use "LOMEM xxxx" to set the LOMEM pointer, which would normally be at the top of RAM that DOS uses (or $700 if not using DOS). But, you are putting code in a relatively safe area, and the source code would only overwrite it if it became fairly large. Also, doing an ASM would use more memory (temporarily). I would suspect that having your object at $4000 might cause problems, but it depends how much free memory you had to start with. Also, if you are using the OS to OPEN a hi-res graphics mode, it allocates memory from top of RAM ($9FFF downwards in your case). I would recommend: - develop using the emulator. I find using 2 emu windows is good. One to assemble direct to an executable file, then just load in the second. - assemble from disk, ie - LIST your program, NEW, then run an assembly on the disk file. - assemble to disk, then load later. - use MAC65

I forgot to mention. I also did a project + programs to transfer from the C-64 to Atari 800XL. I'm fairly sure it used the C-64 serial port (the disk drive one), and linked to joystick port 2 on the Atari. As far as I remember, the comms was one way only - c64 to Atari. I just wanted to transfer some pictures and digital audio. There was programming involved on both sides, and I interfaced direct to hardware, so there was no adherance to existing convention, no emulation of peripheral devices on either side. But it got me prepared for the SIO to ST project - in addition to that I wrote a 6502 disassembler on the ST, complete with an 80x50 display routine which actually used the 8-bit character set.

I got my first 8-bitter in 1983 (400 with 16K and "real" keyboard). Bought a 600XL the year after with the intention of getting a 64K upgrade, but instead bought an 800XL as it worked out cheaper (after selling the 600XL). Commercial software experience: More Games for Your Atari 600XL (1983/4) published by Virgin books. I co-authored that book, it had about 16 games. Astounding Arcade Games for the Commodore 64 (1984). 3 games in a book, released to the UK market. Due to rather dud distribution and packaging, both books fell way short of sales targets. But, for the hours put into programming I did well financially. I worked for an educational software comany for about 5 months in 1985 - they did stuff on the C-64 which was distributed by McGraw-Hill. But, they ceased operations shortly after - distribution problems. The software was widely available in Australia, limited release in UK, and they were on the verge of penetrating the American market just before shutting down. Almost all of my paid work in computing since has been on IBM and compatible mainframes (I'm qualified as an MVS, OS/390 Systems Programmer). I mothballed the 800XL and ST probably around 1994 when I bought an Amiga. Did a little programming on the ST, the main project of worth I did was an interface which went from SIO to parallel (on the ST) and allowed emulating 4 1050 disk drives (very much like APE). It never got to the stage where it was commercially releasable, but worked very well. I never did any programming on the Amiga (other than startup scripts and stuff), and it got mothballed around 1998 when I bought a PS1 console. I properly got into PCs (Wintel/AMD) around 2000, but other than a little VB and VC++ programming, have never bothered to get into it properly. Most of the playing about I've done is building systems.

Didn't Avalon Hill do one well before the official port came out? From memory, gravestones substituted for mushrooms, and I think it was left-right movement only.

MAC/65 was available both as a SuperCartridge (bank-select) and on disk. The disk version lacks DDT (the debugger), and a few other features. The disk version also suffers a RAM penalty, since the cartridge version resides in 8K of memory space. Not to mention the extra stability you always get with ROM-based software.

1. As well as my own 520 STFM I also have a broken one, is there any way I can 'steal' the memory from the broken one to make mine a 1040? There were many variants of the ST motherboard. From memory, some 520s just had vacant spots where you could solder in chips. Probably best to pull the machine apart and have a look. 3. My ST only seems to boot if a disc is in the drive, this isn't right is it? The STs with OS based GEM (ie almost all of them) will attempt to boot, then to load from the AUTO folder. If no disk is in the drive, you typically have a 20 second or so wait, then just get a default desktop. 4. Want to get back to machine code/ assembler and would like some programs/ guides on 'how to'. Any tips? I learned 68000 from other peoples code, by reading "Programming the 68000" (Zaks?), and by using the fairly primitive Assembler in DBASIC. But there should be plenty of references and tutorials on the 'net. 5. Who do you all recommend to get ST stuff from? eBay, Marketplace here, 2nd hand stores, Best Electronics. Plus, the ST is compatible with many legacy devices that use RS-232 or centronics ports.

I agree that starting a program at $A000 then just having another .ORG to set the vectors would make sense. I just suggested the other way because I've heard so many stories of people doing EPROMs and them not working because the vectors weren't in place. I still stick by the idea of developing binary-load files. You can run your favourite cross-assembler to build the files, then just load EXE into the emulator. Once you're ready for production, just reassemble the whole deal to fit into a ROM. Another thing about ROMs. About every one I've seen is compatible with 16K RAM systems, which means tight programming is in order. It may well be worth using such areas as the Cassette buffer for working storage. And (in almost every case), it's a good idea to do your own memory management so far as allocation as screen memory, PMGs etc.