Rybags

It'll depend on the OS revision but the code path is a simple LDA #$02 / STA $52 - $C363 in XL OS Rev 2. To be seen as an authentic OS by software that checks for one, you'd want to recalculate the OS ROM checksums as well.

What's the deal with overvoltage tolerance for NMOS vs CMOS? From what I've heard CMOS is way more sensitive to static but does the same apply for the general power supplied to the chip?

I'd say it depends how the external solution works. If it doesn't supply the base 64K then you'd need the 130XE to supply it. When 320XL was in dev, I requested a compatibility fix for VBXE - it has a jumper to allow either overriding the base 64K or leaving it be (which VBXE needs for it's memory windows to work) If your external does supply the base 64K then obviously you should be able to remove the existing upgrade but obviously the computer won't work at all without the external one plugged in.

Even the power supply is compatible (though I suspect the 400 PS is probably insufficient for the 1050)

A big saving could be had by just embedding it in the program rather than having it as a sub... though seeing it's used with C that mightn't be possible. Also, the position variables - if one or both could be used directly instead of copying.

Cool. Was that video by some old tape based camera or is it modern day VHS emulation post-effects?

Those command frames - I don't think there should be a leading 00. Possibly there's a start bit being assumed when the level should be at 1? Could you volt-test Data Out on the serial port? Normally it should be +5V. Also you can issue a Basic command to set it to zero: POKE 562 ,131 : POKE 53775,131 Set things back to normal, just press Reset or change the 131 to 3.

I was thinking "Hey, he's just posted the original image, not the actual." But no. That's a pretty good result, looks like virtually no unwanted artifacting.

You can buy USB capture devices on eBay for next to nothing - like 6 bucks. The trick is though - find out what chipset yours uses and make sure you don't buy one with the same type otherwise you'll probably just get the same results.

If there's no interlace mode setting and knocking resolution down doesn't work then that's probably about it. Atari is nonstandard like most computers and consoles of that era. Some modern devices just can't handle the signal properly. Aside from not doing the fields with .5 of a scanline, the Atari also doesn't provide the short sync pulses halfway through the VSync scanlines, and also uses the same luma level for black and "blacker than black".

I'm fairly sure that any Atari peripherals that have the 2 SIO ports for passthrough don't actually supply power to them. Generally the +5V is a low current supply from the computer that tells the peripherals that the computer is "Ready" and can be used for low draw situations. Most legacy peripherals AFAIK don't use it though the tape drives do for part of the FSK decode circuit (?)

In the modern day the next Glenn the 5200 man would only serve to kill off development on that system. It's all well and good to distribute 35 year old software assuming it's "abandonware" (even though the term has no legal grounding) knowing full well that if the software company still exists, it's hardly going to care or be hurt by it. But for modern day developments, they are anything but abandonware, and it's up to the IP owner to decide what platforms it will be ported to. I converted 2 games from the C= Plus/4 to the Atari. One was from ~ 1985 and I just went ahead with it. The other was a modern day homebrew with source available, but I still contacted the author to get his OK for it.

It's not up to us. It's up to the program author. I think if he'd wanted to have it ported it would have been so by now.

Fairly sure I've not played it. What's with the guy's face? It's like the graphics guy went "Oh shit, I have to fit the head within this certain number of pixels, so I'll have to flatten the front of his profile!

If a game only uses left/right, then you can often save a bunch of time using the PTRIG( function. That gives the 0/1 values and you can invert them by using e.g. A=NOT PTRIG(0)

The usual with digital at least is left/right is preferred and up/down occurs accidentally. Implementation would be easy enough - just do the l/r processing first and if there is movement, increase the required threshold to detect u/d. Of course it'd be nice to have user options for deadzones, thresholds etc but I can't recall any 5200 games that allow such things.

It's never used on 8-bit 6502s but the bit pair is used in native mode on the 65816.

I don't see how it could work unless it's got switchable Rom to cater for the Atari - and it'd very likely need to have the hardware IO remapped as well. But they seem to have adapted it to the Vic-20 which in itself is sufficiently different, so maybe that's what they've done.

I've not had much to do with the 5200 other than using it via emulation. Likely you'd want a dead zone in the middle and possibly also assume that some of the extreme values aren't available. The dead zone I should think would probably cover at least 20 values.

That looks not far off the first family colour TV we got in 1975. For my computer it was 1984 when I bought the 34cm Rank Arena (made by NEC) pushbutton tuner, which I still have today though not powered on for probably 4 years.

The resolution is limited by the hardware that reads the pots. Pokey gives values 0-227. Example of another computer is C64 where it gives the full 0-255 range. But the paddles on the 2 machines aren't 100% compatible since C64 uses 500K pots and Atari uses 1M. So Atari paddles on C64 will only use a fraction of the turning range and C64 paddles on Atari will only return a subset of the possible values.

I don't quite get it - you just want to play each tune on a single Pokey? So you'd just call your player routine for each one, ensuring tune 2 is addressing the second Pokey. I had a quick look at the first one- looks like you just JSR to a play routine in defferred VBlank. I suppose the other modification to the playback routine would be to ensure each one is using it's own work variables.

Likely Atari did their usual trick and ordered 10,000 mask Roms while it was still in Beta, then someone found the bug before (?) the instructions were printed (though that looks like an inserted card and I'm fairly sure Asteroids had a nice A4 sized printed colour manual). Early cartridges had either no or very simple copy protection, I'm fairly sure Star Raiders has something similar. Most were fairly easy to defeat. But some later carts, especially 3rd party were much trickier. I don't think I ever got a Thorn-EMI game to crack and work.

I can recall having the issue when programming when I had my 400, though it was lower memory config and probably related to PMG data and asm routines being overwritten. A flashing screen - probably indicates GTIA registers being overwritten. In default Gr. 0 it'd likely recover but if stuff like PM graphics were in use the configuration would likely be corrupted.

52K ends just before $D000 which is the GTIA registers.