Rybags

XE should be at or very near to 100% compatible with all previous official Atari cartridge releases and high 90%ile of carts in general. Some exceptions and notes: Missile Command - for it's keyboard control it directly accesses the system keyboard table in OS Rom, so there are at least 2 incompatible versions. Otherwise the game is still playable, I suspect trackball and pause mode would be missing. Other games - from memory some incompatible 3rd party carts due to OS differences. Gorf is one. In such cases, file versions that have been fixed will usually exist and can be used on any system >=48K.

I found 720s to be more reliable than 1.44s. Though I generally bought 720s in new boxes. 1.44s I usually just obtained from work or reused install disks so they'd probably been knocked around a bit. I doubt I ever threw away more than several 5.25s.

For 1050 ED you don't really need DSDD. The ones to avoid are generally the high/quad density (1.2 / 1.44 Meg and higher) because they use a thinner coating - older drives might write just fine to them but they'll generally fail not long after. For the most part my old floppies are still OK 40+ years down the track - plenty are single sided and a few are single density. Remember with the 5.25, single density was orignally defined as 180K per side. Double was 360K per side, quad density was >= 600K per side (some variations on those due to deviation from standards + formatting tricks)

Modern LCDs tend to be way more sensitive to our not so great video signal than the old CRTs - as such the interference from refresh and even cycle boundaries can show through.

Also looks like an excess of luma which trails off as you go right though it could be the pic angle. Would also be interesting to see it on a normal text display.

Does Sally care when /Halt occurs? That signal acts on Sally in lieu of the old external circuitry that held the CPU clock so that the 6502 released the bus. I should think if it occurs too early it doesnt' matter because the logic dictates that part of the cycle occurs as normal - from the CPU POV at least.

DK should work fine. If the XE game was originally a cartridge release then it should work in 16K. Though looking at the list I linked earlier I'd guess that amounts to under 1/3rd of that lot.

In theory you should be fine with either core type so long as you don't assume a machine with >64K of PORTB accessible Ram has that memory seperate from VBXE - then attempt to use both as if they were seperate entities on a machine where they're shared. There's methods to detect configurations, not sure if there's ready to run routines sitting around though.

A quick look down the Wiki page at https://en.wikipedia.org/wiki/List_of_Atari_XEGS_games Some possibilities that might work given the originals worked in 16K: Blue Max and Eastern Front. Necromancer supposedly had an original cartridge version which mentions 16K so possibly it works also. But all up, I'd not count on many of them working on low memory systems.

I suspect most VBXE owners would follow the path I did. My 800XL initially had just 64K so I installed VBXE and used the R core to emulate the Rambo expansion. Then I got U1Meg and switched to the A core. Unless you're really short on VRam you should be able to fit in 64K and use the VBXE VRam for program use as well regardless if the system is using A or R core.

Somewhat different to my technique though I see you're using the cow (desoldering iron/pump) I was meaning to make a video - my main desoldering case has been harvesting Pokeys from 7800 Ballblazer boards.

Not sure. I think the overall video generation has problems. Isn't the colour signal constant amplitude? Which means low luma gets oversaturated and higher ones get washed out. Then there's the luma issue - certain transitions, esp 7 to 8, can have a black line because the rise time is a fraction of a cycle but fall time is almost instant.

Quality of the XE boards can be a bit dodgy, so be careful not to lift traces or destroy vias. I became good at non destructive (can reuse the IC) desoldering thanks to a technique posted here by candle probably 12 years ago. Use a reasonably fine tip iron. If it's temp controllable then around 260-280C. Have the board vertical so you can easily access both sides. Apply the tip to one IC pin at a time. Have a little solder on the tip to help with heat conduction. Contact the IC pin at an angle to cater for the taper in the iron tip, but avoid having the tip touch the motherboard. After about 8-10 seconds you should be able to use a solder sucker (plunger type best to use) on the bottom of the board to suck the solder out. I generally move around the chip doing different pins to avoid heating one area too much at a time. The ground pin can be annoying as the trace will often act as a heatsink preventing the solder melting. Generally more heat/time might be needed there. If done properly, all that's needed is a quick cleanup with braid afterwards, and the chip should just need leg straightening and maybe a little cleanup then can be reinserted.

Reported that one for removal - I pulled an old cart apart and was viewing it the wrong way around.

Cyborg - would be interesting to see it with a plain background and not dithered.

Some carts can bank the Rom out. Possibly the INIT section could do that and return but much of it would need to run from Ram, although the sequence could be as little as STA $D5xx / RTS. That code could be pushed to the stack, then stack adjusted and jumped to. For the trouble you'd be better off just doing a custom OS that defaults to Basic off.

I suspect the jumper was on the 1200XL for factory testing purposes to begin with - it probably would have helped with automating the process. Was the OS portion removed on later OS revisions? They never bothered removing the F-key handler from the keyboard IRQ, so wouldn't surprise me if other unused remnants stuck around.

AsmEd cart is OK for playing around or small projects. In the day it was the only option for a lot of us for a long time. Mac 65 is a quantum leap above it. Cross-platform and emulation is another leap after that. What used to be a 20 minute wait - assemble, create your loadable file then load and test then reboot to get back to source editing (with all the media swaps) now can be well under 20 seconds.

As with normal SBC you have to use SEC before the operation. If you were just doing 1 or 2 digits then adding 99 would be equivalent to subtracting 1, but the carry would be invalid. So, you will need an extra code section to do subtracts.

Narrow mode would likely introduce the disadvantage that masking COLBAK changes would be less effective. Use more PMs and it takes away with what extra can be in the picture. Wide mode - if you have HSCROL with value 0E then the playfield DMA should only fetch 44 bytes which is 4 more than normal. PM objects could be omitted for masking and dedicated for the display since a 4:3 display should have overscan areas.

Rolling is usually when you try to get a video. In still pic cases unwanted artifacts can be due to camera settings. With phone cameras generally a lot of it is automated, so if you take a CRT pic where it's in a not well lit room it will often use a longer exposure which should give an even picture. For video of a CRT it can be made worse since you get shutter roll from the camera combined with the CRT pixels losing brightness after being scanned.

Something I should have mentioned - if you monitor a pure tone on the audio out pin it should be a square wave. But the resultant output once it's gone through the external audio circuit - you'll see attack/decay phases in the waveform which probably softens the tone a bit. Though this is external to Pokey itself (and probably much the same on all computer models)

If you intend to distribute then Basic XL and XE aren't very good options due to not being widespread. Although I'm fairly sure both have been ported to Atarimax and probably other banked flashcarts. For typeins you're usually best to stick with whatever it's target is, a faster Basic variant could mean the program runs too fast and would need downtuning.

Pokey doesn't use complex waveforms. Ignoring forced volume (sample by software) playback, each voice will only output 0 or 1. At higher frequencies there can be interaction among voices to produce perceived waveforms such as triangle or sawtooth. In general usage, there's square wave and "poly noise" output. Poly noise is actually output selection using LFSR. The longer (17 and 9 bit) ones are perceived as noise. The shorter ones and combinations of those can resemble waveforms such as sawtooth but are in fact they are all predictable repeating sequences.

You might get away with using K: and S: The problem with S: though with Gr. 0 is that it will still do line insertions when your output exceeds column 39. A potential fix but then your program will be XL only - set the screen mode to 12 which is the same architecture but doesn't do the unwanted line inserts. Quick example: 10 CLOSE #16 20 OPEN #6,12,0,"S" 25 POKE 87,12 30 POSITION 8,1:? #6;"ABCD"; 40 POSITION 38,0:? #6;"12345"; 999 GOTO 999 Try changing line 25 - value 12 or 0. With 0 it will do line insertion, with 12 it won't. You have to press Reset once the program finishes.