Rybags

It depends on mode, DMA width and what graphics/character data Antic needs to fetch. On a hires/multicolour text mode "badline" there's no free cycles until about the second last character or so. In a mode such as OS Graphics 7 on the second scanline, you only have the Refresh cycles lost. Speed - by preloading A/X/Y, you get the quickest situation, so if stored in succession that's 12 cycles = 6 character cells. But of course Antic will often get in the way. Extra changes are quicker if you LDA etc in Immediate mode, only 2 cycles instead of 4 or 5 if you do a LDA table,Y type of thing. Of course doing it that way can mean you end up with a huge block of code if the changes needed are different on each scanline. In theory, in OS Graphics 10 (GTIA paletted mode) you have 114 - 9 Ref - 40 bitmap fetches - 1 DList = 64 cycles free. That would allow for every single colour register to change each scanline with a little left over. Of course, the changes all occur in different places so doing a picture would be complex work. It's one of those things that we need to automate, some pretty colourful pics would be possible using this method.

Shouldn't INC WSYNC behaviour depend on whether the next cycle is DMA after the initial writeback?

The OS also has a loop where it does nothing for most of that duration of colour flash, before it clears the hardware registers. Only does so on XL/later, probably as a kind of debounce for the Reset key.

Yes. Even occasional PMG stripes on powerup is normal. GTIA seems to default to $F0 (sometimes) for some colour registers and at times other registers will have random data on powerup.

There's plenty about... I bought 16 of them off jaybird last year.

Might grab it if it makes it over here... 3 months behind and usually over double the UK price.

They're all low value caps, so won't be of the can type, likely some or all will be the pressed round brown types. Since they're smaller and can't hold much printed text, they'll use codes to show the values. These links should help: http://www.kpsec.freeuk.com/components/capac.htm http://wiki.xtronics.com/index.php/Capacitor_Codes

5/9 are the paddle inputs. The 7800 routes the controller inputs slightly differently depending if in 2600 or 7800 mode. I'm just about sure there's a mod around that just lets the computer read MB2 via a Pot input, and still work on the ST. It involves changing a resistor value.

It was a while back but I think a demo version did come out. As much as you and others would pay for an XEX, you'd probably be outnumbered 20:1 by others that wouldn't. Also, I think there's some arrangement with Atari that gave them permission to use the name - it could be that it came with the proviso of a 5200 only release.

If they'd intended for everyone to be able to play it, they'd have released a ROM image. By copying it against the programmer's wishes, all you'd accomplish is helping to kill new program development.

Not that I know of... some people doing stuff on 5200 just want nothing to do with the computer scene. But on the other hand, witholding from the computer makes the chance of the game being pirated somewhat less.

GTIA isn't a ROM, it's a custom logic-based IC. On second thoughts, keeping it as is will affect some software but probably not a great percentage. Even though so many games these days will work on PAL only, our programmers don't seem to bother actually checking for it, the game will work or just crash generally.

The usual way for software to determine which type of system it's on is to check the PAL register on GTIA. Although there's strictly not really a need to, it's a good idea also to change GTIA over to the "other" system. Also note of course the system will run slightly faster (NTSC -> PAL) or slower (PAL -> NTSC) than a factory system of the other region due to the master clocks being different. With software it should be barely noticable though.

Mouse button 1 uses the joystick trigger line. The ball x/y goes through the 4 joystick directional lines. There aren't "unused" pins on the 8-bit controller ports, the unused ones with a joystick correspond to the 2 paddle inputs.

Standard Atari ports have 4 directions, fire, 2 paddles, +5V, GND. ST doesn't have Pot inputs on the 9-pin ports so they can use the spare line for second mouse button. IIRC, there's a project around that allows modifying an ST mouse so you can also detect the right button on 8-bit computers.

I had a quick look at the listing. There are parts that seem to be valid code but are just represented as data blocks. There doesn't seem to be any OS calls - not unique but kinda strange. Do you know if this thing handles all the serial I/O itself? IMO the key to the whole thing would be to work out the serial stuff... in all probability the serial routines will have fixed block lengths that might be dependant on individual commands, working that out would go a long way to reverse-engineering the system. Also, do you have the hardware that sends data over to the Atari, or are you working out all this based on the cartridge software alone?

The better option is usually to make a Batch File, which takes your supplied paramaters and executes the command. Actually, the best option is to integrate the entire thing into your editor, e.g. EditPlus. Then you just have to remember to save the file before assembling it.

http://www.best-electronics-ca.com/custom-i.htm Easiest way is to go by the part numbers. Schematics show relationships between components but not their actual positions. There was a thread here not so long ago with the various 800XL revisions and I think the ICs were labelled. But checking the part number yourself would be best.

All keyboards have the same matrix - Pokey handles everything except Start/Select/Option, those should have their own traces that ultimately go to GTIA. As you can see, the keys you've mentioned share common row or columns which could mean a severed trace rather than a dodgy contact.

Not a 2600 programmer here, but the critical thing would be 3 VSYNC lines. Second most important would be 262 (NTSC) or 312 scanlines (PAL) although supposedly some games deviate slightly from that. The "displayable visible lines" thing though comes up a lot - it's generally safe to use about 232 lines (PAL), but NTSC probably closer to 216. These days it's a lot less critical though because newer TVs tend to be more "precise" and generally have less overscan area than older ones.

I've still got a drawing program from 1985 that never got finished, but if I was to start such a thing again I doubt I'd use any of it anyhow.

You're buying 10 of them? I've got one of these RGB -> SVideo convertors and so has one or two others http://www.amigamaniac.com/RGB_to_PAL_NTSC_adapter.html I've not tried mine yet, you have to use a 7 Volt or higher DC power supply to it. Plus you'll probably need to put voltage dividers on the RGB inputs to lower the voltages slightly. Component isn't RGB, plus the RGB from VBXE is at a slower scanrate so TVs and monitors that accept VGA won't necessarily work with VBXE. You're easiest way out is to get a colour monitor to suit an ST or Amiga because the signals used are virtually the same. There are also boxed RGB convertors around that can do conversion to S-Video, as well as scandoublers that would allow you to use a modern monitor, but they're $80 upwards.

WinXP 64-bit isn't all that great to begin with. And it's pretty pointless running a 64-bit OS unlesss for some reason you have over 3.5 Gig of RAM installed, and need to use it all.

Bank Street Music Writer, although it's not really a tracker. RMT stuff will work on older machines.

As Adam Savage would say "Thar's yer problem!"