Rybags

Load Xex will usually work fine in emulators because that option typically injects the segments into Ram without there being any loader needed or present beforehand. Real hardware doesn't do this - about the closest you can get for such a "protected" situation is from the likes of IDE+ which have Rom based loaders that only need a little bit of Ram workspace to survive.

Unsure. Generally full ATR demo disks just do raw sector reads with no regard to a standard Dos structure. Even if it is a Dos structure, the problem can become the fact that most of memory gets used and a loader or Dos gets overwritten. An alternative can be systems that load an entire disk image into Ram then emulate a disk drive, though in the case of this demo you'd likely want a 128K Ram machine.

You don't really need hardware type scrolling in the bitmap modes. Firstly since it's a byte per pixel there's no fractional value to worry about. Secondly, the XDL allows you to specify start address of the bitmap and increment value per scanline with little limitation. So without too much work you could implement scrolling as a measure to free up blit cycles.

Pic 1 looks like the Self Test background colour. Pic 2 looks like the distortion you can get by building a 320 mode screen that's too tall. But anyway... without proper display you'd want to rely on sounds. Like do you get a click when it powers on or if you press Reset? And what does the screen do.

Yeah, as impressive as it would be to DIY one and get it to work, there's affordable and less frustrating alternatives around these days. Ultimate 1 Meg for 65 US dollars - and it includes built in SpartaDos and extra OS and cart Roms.

Stock drives don't allow running user code like the C= 1541. Many aftermarket upgrades such as Happy do though. Dos is irrelevant here - it's just the filing system and copy protection is at a lower level. Additionally most Atari games don't use a Dos file structure. There's plenty of stuff that upgrades can't copy. In the modern day the likes of Kryoflux and Catweasel have been used, which is generally copying disks without regard to format by just keeping a record of the flux transitions at a high resolution to allow later recreation.

True double sided doesn't help with "flippies" since turning the disk over means it's written in the opposite direction - though it was never a recommended by OEMs method to get more data on a disk.

Good question. I would assume the next valid point where an NMI could be accepted would be fairly early - the mechanism for NMI is near identical to IRQ and we have documented the interaction and interference that can occur there. Of course the Atari only generates NMI at a specfic part of the scanline and also the "bug" in that the line isn't held low long enough resulting in occasional missed NMIs if an IRQ is coincident at the right time. On the C64, retaining the NMI line low is actually performed by some games as (the only actual possible way) means of disabling the Restore key - which is functionally equivalent to System Reset on the 400/800 (though needing the user to hold Run/Stop as well to cause the warmstart) There's multiple scenarios of NMI repetition and mixed IRQ/NMI that would do well to be properly documented though our machine by default wouldn't be able to recreate many of them. Not sure if the C64 could either, I think their only NMI sources are the Restore key and one of the CIA's Timer interrupts (the other one only generating an IRQ) - and in any case the Timer NMI there needs CPU intervention to acknowledge and enable a subsequent one. Unsure if relevant here but I seem to remember there being some trick they can use to speed up some interrupt acks by vectoring the service routine to hit the hardware, saving having to execute an instruction to do it. Also there's a sometimes used trick to disable the Restore key by generating a timer NMI, then not clearing it so keeping the line low. Though it's probably not documented, the common sense approach to NMIs would be that you don't have them more often than every 30-40 CPU cycles anyway since you'd have a high chance of stack wraparound and a crashed machine.

I think Claus has nailed it... so the solution might be as simple as replacing a single Ram chip (U11). Desoldering equipment isn't really needed. Just hold the iron against the pin (keep off the board) and use a solder pump on the other side (putting the board in a vice would help there). Generally pretty easy to do though the GND pins can be tricky if they have thicker traces which will act as heatsinks. Once removed then do cleanup with braid.

I think Antic is probably OK unless it's a refresh issue. The corruption is all on Ram based graphics - the last line of text is in the self test Rom area and seems fine. The fact it's going to the memory test would indicate there's some issue with Ram. Though it does seem good enough to be able to run the test. But I'd also first go with the reseat on chips like Antic, MMU, Rams and select logic ICs.

http://plus4world.powweb.com/software/Dizzy_II_-_Treasure_Island_Dizzy It looks like the Plus4 Dizzy games use hires + colour attributes for single foreground colour per cell. PM overlays could go some way to retaining that look. The games would be very good VBXE candidates. I didn't consider 64K Plus4 games much for VBXE since there's a fair chance of memory usage in our IO area that would need to be changed (Plus4 can access it's full 64K better than most). The other sticking point (and a big one) for conversion to stock hardware is that we can only do 128 characters.

The PBI specification insofar as the logical interface was versatile in that it allowed some sharing of $D1xx addresses as well as selectively banking into the FP Rom space. Of course it wasn't really utilized since the 1090 never went beyond proto and no machines were released with slot based expansion. Additionally - some flash cartridges I believe the Atarimax ones at least - use specific addresses within the $Axxx-$Bxxx range for doing flash operations like erase and writing blocks.

I doubt anything would map to $D4xx - that's Antic which self-decodes and can't be altered. Same with most of the other default IO space though in some cases there's extra functionality piggybacked to existing space e.g. for VBXE (GTIA addresses) or Ultimate 1 Meg (PIA addresses) - usually done in a way where accesses won't affect normal operations. The $D5xx area is usually reserved for cartridge and 800 expansion board use but is "borrowed" by some peripherals and addons. VBXE gives the option ot use $D6xx if conflict exists. The PBI specification has $D1xx as IO space for such devices and also allows the FP ROM ($D800-$DFFF) to be switched out and replaced by whatever the peripheral wants to put there, like RAM, IO space, ROM. Additionally the PBI hardware allows external override to most addresses (except IO space $D000-$D7FF ?) - an example of use there is 320XL which can replace all of system RAM in 64K and under machines.

I used to know most of the common ones off by heart - sort of easy, the Ax are mostly loads, 8x mostly stores, all the branches have 0 as the second nybble. 60/20 for JSR/RTS, 4C for JMP. I've done some hand assembly in that fashion but not really more than a few dozen instructions. The hardest part IMO is dealing with the branches, the rest isn't too hard.

Maybe throw in some of the usual paranoia as well. C= only used 35 tracks on their drives though I think the reason was the mechs as much as the media. Though by 1983 floppies were pretty good. The "have to use excess obsolete stock" reason sounds really feasible... it's still widespread today. I've seen desktops from the brand names that are just built using excess laptop components including charger then housed in ridiculously oversized cases. The only reasoning I can see is they just wanted to get rid of stuff.

XL/XE you just disable interrupts then switch out the OS. A successful test of addresses $C000 and $E000 would probably be sufficient to assume a 64K or better system.

I don't have install instructions or even a pic of an installed Sophia but I'd say there should be no problem other than physical space within the machine. VBXE also does partial cloning of GTIA but isn't dependent on the genuine part being present to function other than the CSync output being required.

The OS tests for RAM on 4K boundaries which is more than sufficient. The only exception I can think of there would be the rare case where you might replace the FP Rom with an SRAM (or possibly some mods exist that put switchable Ram in that little 2K hole) So really all you'd need to do is check locations $xFF0 (staying away from $CFFF which I'm fairly sure can be a banking register). Generally all you need to do is save what's there, then do a test store of 2 different values and verify if they read back. Then restore original contents if it's found to be Ram. The 40 and 48K thing is no great mystery. What can hinder you there is if a cartridge is inserted since it can mask part or all of the area. In theory a Right Cartridge could mask the 32-40K area and leave 40-48K as RAM. But in practice the Monkey Wrench is generally used with the factory Basic cart in the other slot.

There's multiple >48K upgrades for 400/800. I don't have the definitive information but AFAIK, one of them uses a 16K window at $4000 in similar fashion to the 130XE (don't know how banking is done) The one presenting 52K - possibly there's a 52K only one but I've read of a 64K one that presents the 4K window at $C000 and uses $CFFF as the banking register. So for testing 52K, probably a good idea to try location $C000. You probably already know but to test for RAM it's a good idea to store 2 distinct values and test for them in the one location - noting some "non RAM" addresses can return 00, FF or an address reflection depending on machine.

This is a shock. RIP Curt. A big part of the Atari community and probably the biggest insofar as bringing the old history to light and preserving it.

I don't know a lot about the Happy hardware, but what about the delay of generating the code? Generating bit-bang instructions for about 1300 transitions per sector might potentially cause sufficient delay that rotational latency screws up any speed gains?

10 Quid headed your way. I'm not sure what the percentage thing is, I guess to keep their site running? I only gave them 10% for that. You've done more than most to help keep the Atari 8-bit scene alive - probably more active promoting Altirra than anyone out there and always with valuable input and opinions. Whatever happens, try and keep your Atari gear.

A few hours ago I had the page refresh timing out as if the site was down (which I think it was). Seems OK now. Not sure if we've gone back to that daily restart that was happening a few years ago when the site had issues.

Touch tablet is just POT inputs for X/Y which could be divided into zones. Programatically probably easier than the keypads which require scanning each row then potentially processing multiple keypresses.

Ah... even though I've got this game for the 2600 along with the keypads (the reason I bought it), I've not played it. But, it has modal use of the keypad which is a good idea - that can double the number of functions. So, maybe a good idea to do it similar to the 2600 which would also allow using their controller+overlay. IMO game abort should probably remain off, the 2600 doesn't seem to have a pause button.