Rybags

.XEX is a binary load file, exactly the same structure as .COM or .EXE on the Atari. .XEX is the recommended standard, since Windows/DOS uses .COM and .EXE for it's command files. So, just do a bulk rename of your files to meet that standard.

These days, such a program is not needed anyway. Even a '386 running a sound card can capture audio just fine. The Atari can only play 4-bit samples, but you can save memory and use 2-bit samples which are still distinguishable. There are also tricks to use multiple voices to get better than 4-bit samples. Writing a player program is fairly simple, just a couple of dozen lines of Assembler.

Most TVs made over the last 10 years or so will do PAL and NTSC. It's just the audio that can cause problems, since there are so many small variations of the 2 standards. For example, audio sits about 7 MHz above the base frequency in Australia, where in the UK I think it's closer to about 4 MHz. One of the major advantages of modern console hardware is that most of them do away with RF and just use A/V plugs, which will work on almost any modern VCR or TV.

Australian TV uses a different frequency spread from European PAL for video/audio. I would say it is also different from NTSC. Might be an idea to mod it to add a seperate audio out, which could be run through a stereo or computer speakers. Or, just run it through a PC capture card.

I did the Super Video (1) mod on my 800XL. The results weren't any good, so I reversed most of it. IMO, just adding a S-Video port is sufficient. I did that on my 130XE (which is renowned as having among the worst TV quality of the 8-bits), and it looks fine both on a TV and through my capture card.

Just put a double X in the game name. We're having similar crap in Australia. Since Virgin expanded and started an airline, credit card and mobile phone services here, they've been chasing down any small business with Virgin in it's name... even some 20+ years old.

A "Cease and Desist" is usually a semi-formal letter sent to a business or individual if it is using a business name, product name, trademark, or is infringing a patent which is already registered by another company. It's usually the last step before taking more formal legal action.

Is your WinZip version up to date? And, are the files WinZip or 7-Zip. Both possibilities are opportunities for version incompatibilities. Multiple compression is no problem, so long as you have the right archiver versions to uncompress. It could just be that the DVD media is at fault anyway. In any case, I don't know if MAME supports self-extracting zip .EXEs. I always just use basic .ZIP files.

The drive should at least do a seek when it powers up (I think). I'm fairly sure the 810 service manual has been scanned and uploaded but I can't remember what site it's on.

The Atari has audio-in via the SIO port (which the cassette drive supplies an output to). The only problem is that the sound is just mixed with what POKEY/GTIA generates and there is no way to either sample or alter that sound. I'm fairly sure though that there are simple electonics projects around which hook up to the paddle input of a joystick port. It would be a simple case of scanning the paddles in fast POTGO mode, but the sample rate would not be so great since it takes 2 scanlines for the hardware to generate a value.

Can the 2600 do output to the j1-j4 lines like the computers? If so, a multijoy interface could be attached, but would need 2 or more plugs connected to a custom-wired gamepad.

A broken trace or poorly seated POKEY chip?

That would indicate that one or more of the contacts on either the ribbon cable or socket are dirty. Try giving the cable a wipe with some VCR head cleaning fluid.

Not really. Most old Atari games were cracked and converted to binary files decades ago. And there was probably a higher proportion of cartridge games made for the Atari. Also, the C-64 has the "advantage" of having it's DOS resident in the disk drive.

They are unique to Atari. So, Best Electronics and eBay, or someone here with a spare would be your best chance. Alternatively, just build an APE/SIO2PC interface into your machine, but that still means you can't use your disk/tape drives. Another possibility could be to wire something like a DB9 interface into the Atari, and the peripheral - then use a standard PC RS-232 cable.

Can it boot a disk? Can you get the keyclick sound? If not, it will indicate that it's not just a simple modulator problem.

The 1 chip SIO2PC (APE) interface is a must-have. http://www.geocities.com/atarimods/index.html It uses about $8 worth of parts - you can get the 1489 interface chip from DSE, Tandy or Jaycar. I've built 2 already, the first was an external one in a project box. The second one I built into my 130XE. I'm no expert on electronics or soldering, but the second one I built took about 5 hours work (with practice I could probably get it down to 2 or 3).

3:30 in the morning here... time for zzZZZ.

The graphics would suffer enormously if resolution was decreased. I feel the memory saved wouldn't be worth the sacrifice. The Atari only suffers 2 memory penalties vs the C-64: - PMGs require 1280 bytes + original copy of sprites, vs 63 bytes per sprite on the C-64 - the Atari can't touch the 2K RAM under the hardware register address region ** venetian blind effect = equivalent to putting GR. 7, 2 blank, GR. 7, 2 blank etc...

It might be the case that every cycle is needed. Doing DLIs will be taxing, although clever coding can save time. Stuff like using NOPs instead of WSYNC. Ditch the OS VBI stuff and only do what's needed. Since the game may well need 64K, ditch the OS and use custom NMI handlers. Disabling PMGs where not needed could potentially save 350+ cycles per frame. A GR. 7 or similar scoreboard would be good, but the small DMA saving is offset by having to render characters. Maybe we could be tricky and use the PMGs overlayed to generate the venetian blinds effect?

Cycle counting exercise (PAL systems - assumes Atari with 25 text lines) C-64 Atari cycles/frame 19656 35568 DMA loss: character code fetch 1000 1000 character bitmap fetch 0 8000 DLIST fetch (approx) 0 35 Sprite/PMGs (approx) 92 1280 (#1) TOTAL DMA loss 1092 10315 NET CYCLES / frame 18564 25253 (#1) assumes C-64 has 3 sprites enabled Those calcs are probably somewhat off, but the Atari should have nearly 7000 cycles/frame free above the C-64. More cycles could be freed up by: - turn off ANTIC DMA for PMGs outside the pinball playfield. - use a chunky bitmap mode, or GR. 2 for the scoreboard.

I meant a DLI each text line, ie - each 8 scanlines. The 5th player option could be viable - the two tables both contain similar colours to the ball. PMGs as "underlays" might be the best option since we wouldn't really want square lights.

Another possibility could be to use the missiles in 5th player mode (COLPF3) for the ball, which would allow more independant overlay colours. In any case, I would suspect most playfield lines would need a DLI due to colour change and player X position changes. The easiest way to cope with PMs for lights etc. would be to have the entire player filled with $FF data, then set the PPOSPn register to 00 or whatever onscreen position the light is required. The downside to such a method though is that we then have to use a PFn colour as the table background, and COLBK for unlit lights.

I'd be interested if anyone could point me to the C-64 "free scrolling" trick. As emkay pointed out, vertical scrolling is easy on the Atari. It's only really with hscrolling that things get trickier. A good old trick with PMGs is to just initialize the whole area to zeros at the game start, then render each PMG starting several bytes before the sprite and ending several bytes after the bottom of it (have the sprite definitions padded either end with zeros). But, it only works if there aren't significant vertical position changes each frame. DLIs are adjusted for you automatically with VSCROL enabled, unlike the C-64 where you have to adjust your raster IRQs according to the fine-scrolling value.

How do you get "scrolling for free" on the C-64? Character modes start on a 1K boundary and there's no trick I know of to do otherwise. Another thing: The ball is hires, therefore 16 pixels becomes 8 pixels in PMGs. If memory permitted, some sort of animation could compensate for the lower resolution to make it look better. 128 characters could definately be an issue if the program logic depends on character values. I still reckon the Atari easily has the speed to render PMGs and execute DLIs and run faster. Plus, it could display a much larger portion of the playfield as well.