Rybags

The AUX2 value 128 is for short IRG. So for creating a file it would be like OPEN #1,8,128,"C:" In a lot of cases Basic won't be fast enough to provide data and keep the IRGs at minimum. For reading, Basic will just about always be too slow to keep up. But ML routines in these cases can be helpful.

Not sure PRINT # will work on long strings for output to C : In the case it doesn't, a quick ML routine could be used - pass the ADR of the string and # of bytes to output and have it call CIO PUT CHARACTERS. (could be wrong there, I know you definitely get problems using INPUT # such as truncated records and in any case I'm fairly sure you're limited to the length you can fetch)

Vertically is easy - a custom Display List lets you mix graphics and text modes. Horizontally not so much. Workarounds can be rendering text in bitmap or using PM graphics to add extra elements. For a spreadsheet screenshot lookalike, probably a mix of those two things.

Tape doesn't allow append. Note PRINT #1, doesn't use tab characters, it uses spaces. Though it does text justification as if tab stops were in place. You can change the spacing in location 201. Default value is 10.

My Chrome allowed me in, Vivaldi didn't. Though Firefox is the only browser I bother to keep up to date, Vivaldi I just run Facebook on so it updates once in a while. Chrome I just keep for testing and for websites that don't want to work elsewhere, so chances are it might be months old. All well and good that browsers have features to protect you, but the nanny-state oversteps the mark a lot of the time. Actually - Edge does have a good feature - vertical tabs. But the MS bloatware added onto it tips it into the negative. It's also stupidly slow vs Chrome on lower spec computers.

Firefox used to let you add exceptions for such cases but it seems they took it away. Edge... best usage case is to download a proper browser.

Keyscan is automatic by Pokey if it's enabled (which it normally is) To get it going the OS generally fills D200-D20F with 00. Then set SKCTL to 03 and IRQEN to C0. Note it's not needed to have the keyboard IRQ active for keyscan to work. Although keyscan is automatic there's still some complexity in processing it, mainly due to debounce and auto-repeat. But if you're just doing a game or something that can do without repeat you can process the keys yourself. There's bits in SKSTAT that reflect key down condition which you could test during VBlank. When a key is registered you generally compare it to the previous keypress and ignore it if it's the same code within 3 frames which handles the debounce. But as phaeron says, you're generally better off using an OS. A cartridge image can be a handy way to do a program that gets control early, but autoboot Xex in most emulators will load a binary file without needing a Dos or menu loaded first.

Synapse games often had similar protection attributes - checksum of code to prevent tampering, poll disk drive and not work if drive present/not present depending on original media type. I believe some also used illegal opcodes which is more towards confusing reverse-engineering efforts than efficiency. Some also used undocumented OS calls which made them partially or totally incompatible with XL machines. One game I'd like to see reverse engineered is Spelunker. From what I've seen, it uses encryption for most of the disk which should be easily removed. If new levels could be made it would invigorate that game.

How many DLIs do you have going? If it's in a known location then why worry about looking at VCOUNT? In wide mode there can be 48 bytes of DMA loss for screen, then you have another 3 for the DList and more again for screen refresh. Also the cycle losses can be skewed depending on the HSCROL value. Though your code there does look reasonably tight. But obviously something is amiss since you're getting corruption. Generally HScrol corruption is a result of the store occurring partway thruough a scanline, which you normally don't want to be doing.

Self Test Keyboard test only reads the keycode register. Break isn't covered I don't think in any version. Also, Break keypress only generates an IRQ at key down condition, there's no way to tell if it's held down or when it's released (possibly disable/re-enable keyscan could, not sure on that) Shift/Ctrl only show if in conjunction with a printable key. CTRL on Atari can not be detected when it's the only keypress.

Recent thread with the news

You're better off without using the jump, it leaves a blank line. There's usually operatives or tricks in assemblers to force to a given boundary. If you know the DList will be under a certain size then a 256 or 512 byte boundary can be sufficient.

No sound occurring can often be that Pokey isn't properly initialized. Sound initialization - store 00 in D200 thru D208, store 03 in D20F. The simplest sound, a pure tone. Store E0 in D200 (freq), store A8 in D201 (control/volume) - store 00 in D201 to stop. For a full Pokey Init, store 00 in D200 through D20F. Then 03 in D20F and C0 in D20E (to enable key/Break IRQs)

The keyboard matrix diagram gives a clue. Often if keys are on the same row or column, a fault in one can be present on the others. Break, Ctrl and Shift share a column. Also, there's no way to distinguish between the Shift keys.

Just a quick look, but going on experience with video capture and consumer recording devices etc in the past. Sometimes they don't like the non interlaced slightly non standard signal from old computers. Sometimes you get a resultant picture that is frame blended with each subsequent frame treated as odd/even interlaced fields. In some cases there's options to overcome such things. In some cases it's just a bit of a turd sandwich and you have to use something else. Evidence of how it might work could be gotten if you could find an existing device that uses the IC. Bottom line though - the picture quality probably wouldn't have huge advantage over existing external video converters, though an inbuilt device that involves modifying the computer and taking video feeds further up the line in theory should give it a bit of an edge at the least.

You can't save/restore most HW registers with software alone since they generally have different functions between read/write. In theory a hardware device could shadow register writes to it's own external Ram which could aid in a restore process. I did a similar program in the day though it worked by just doing a warmstart to get the game going. In the modern day this sort of thing isn't very relevant since emulation allows us to do easy cycle by cycle debug and writing memory out for later restore to emulated or real machine is pretty simple as well.

I think this might have been investigated in a thread elsewhere a fair long time back, and found to be deliberate.

I would suspect - PBI it could be part OS resident and/or banked Rom in high memory area. SIO based - fairly sure the entire handler is downloaded from peripheral to computer as one Ram-based chunk. There's also the facility for relocatable handlers in the XL OS, I believe there's some sort of relocation directory that has to be part of the download which tells the OS which parts of the code need adjusting.

You'd probably just do well to search the program area for the hex sequence AC 06. Likely there's instructions that set it, increment it, compare it. Match found at: 0DCB Match found at: 0F8D Match found at: 2F26 Match found at: 3E2C Match found at: 3E4C Match found at: 3E74 Match found at: 3F4F Match found at: 3FDD Match found at: 437E Match found at: 45C4 Match found at: 45DA Match found at: 4C94 That's looking from $600 to end of 48K Ram. You'd also do better to leave the ATR alone - Blue Max has been available as an XEX for a long time. The done thing is to just append a cheat menu to such programs, it would probably be worthwhile doing Lives and maybe having some disable collision options as well though you'd probably not want to disable ground collisions. Atari800Win+ has trainer (A8T) files for some games though I've only got a few and Blue Max isn't one of the ones I have.

Sticker I think says "GameMaster" - isn't that a producer of 2600 products? Orange box - looks a little like 2600 Asteroids though isn't it's box usually more reddish?

Fairly sure it's an image which you can flash to an Atarimax 8 mbit cart. I don't think many games at all have been modified to operate from a single disk/image. Some Infocom adventures use 2 disks. 7 Cities of Gold requires a disk flip. The whole thing isn't really straightforward - most disk games either don't use a filing system, have a simplified one of their own or just load blocks of sectors into a memory region. Reverse engineering programs that load multiple code/data segments into same memory areas can be a pretty hard process.

How do you mean "anywhere" - they're in constant locations and seem to use the same values in the XL OSes that I've looked at. $3DC - $3DF with values $5C $93 $25

The magic numbers are 3 contiguous bytes so I'm guessing the row or column would be same for all. Maybe better success can be had by using locations that are more spread out. Or maybe different values in the used addresses. The only other way I can think of for the OS to distinguish between a warm reset and a powerup might be through Pokey, though I'm not sure if it's powerup state is in init mode or some random/indeterminate state. A quick look/compare of the OS - 1200XL Rev 10 vs later XL - the Rev 10 doesn't seem to have the delay loop right at the start, otherwise the initial powerup seems the same.

Another point though not relevant and not something that could have been changed easily - the number of refresh cycles. C64 and Plus4 generally use the same RAM technology as XL/XE and only needed 5 cycles refresh per scanline vs our 9. Potentially that could have equated to a worthwhile performace boost though you'd have wanted it switchable to remain compatible with older software.

Why would the OS being changed or being on Eprom matter? As long as the magic number algorithm is used (which I believe every XL/later OS and 3rd part derivatives would use) the behaviour of the Ram chips should be the deciding factor with incorrect powerups.