Rybags

Good job there. BTW, you don't need to Zip any more... you can now upload XEX, ATR and all sorts of other stuff that used to be not allowed by the Forum engine.

AFAIK there's no way at this stage to know what Firmware you have, other than the obvious "new features missing or present" method. There was a thread a little while back... a few of us put in requests and one from me was to have a means of enquiring Firmware Rev. by SIO command. Of course, it'd be nice too if it just displayed the FW Rev info on powerup.

Why not just use a bit of plastic fashioned to hold the switch closed instead?

Clock is used by peripheral makers if they "feel the need" to use it. In the cases of 1050 and SIO2PC/APE at the least, there is no need. So long as a peripheral can keep it's timing within +- 5% or so of what Pokey is using, then you don't get problems. You could probably work out what peripherals (if any) use the Clock by checking out the schematics.

You could probably get away without having it for a while. APE and 1050s at the least shouldn't need it.

No flags although some parts of the OS check for non-zero, others for bit 7 set. I was about to say it shouldn't crash, but if you happen to change that location while scrolling is occuring you might get strange behaviour. One way to do that is by entering the Poke command at the bottom of screen, such that it causes a scroll action. The actual fine scroll count is kept in location 622, so you can get a jumping effect by putting large values in there.

Candle has done a 30 KHz RGB version that works on modern monitors, but needs a ~ 28 Mhz crystal rather than the 14. Not sure about Component... by default VBXE doesn't actually have anything to do with the CSync signal, you tap it yourself elsewhere off the motherboard and run it to whatever monitor port you're using. But in theory VBXE could deduce where the Sync signals are required anyway since it reads the AN0-2 bus signals.

The E: device checks it when a screen is opened - if enabled it will construct a Display List with vertical fine-scrolling enabled. Also, there is code in the Stage 2 VBlank routine that checks it and will perform the actual scrolling if new text has been added and scrolling is required. The screen is also actually 25 lines high, and differs slightly from normal v-scrolling in that you don't ever have partially hidden stuff at the bottom. It also uses a DLI to change the text colour to same as background. This is because the screen origin is still the same - the 25th line will actually wrap around the 4K window and fetch data from $9000 in a normal setup. The 25th line is only used so that new text is always visible straight up, so doesn't need to display anyhow - but you still get a 193 scanline window instead of 192.

The other thing is that you're somewhat tied to their release date. If you've got something ready in January, you don't really want to be holding out for the best part of a year.

In general, EDO won't work at all with older systems. But, the early 72-pin SIMMs (Fast-Page) do have a chance, there are projects around to interface them with the older gear. Problem is, Fast-Page mode 72's are somewhat rare - I think they were superseded fairly early in the piece. Alternatively, 30 pin SIMMs larger than 1 meg are also somewhat rare. AFAIK, all the common RAM module systems from 30 pin and since use a RAS/CAS arrangement to address the DRAMs themselves, so at least that part of interfacing is common, although as mentioned of course since they went to the 184+ pin arrangements the voltage requirements have progressively dropped dramatically.

Driving controllers don't have Pots. They're like a single-axis mouse, they send various values on 2 of the joystick directional bits. Software can then interpret the changes in values to deduce what movement is occurring.

The cassette recorder is "stereo" in that it reads 2 tracks. The audio mixed in the computer isn't. AFAIK, no emulator yet supports playing "audio" as if it was part of a cassette. No great demand for it really, about all you'd want it for is the old language learning systems and the odd bit of other educational software that used it.

What is K7 in relation to Atari? K7 is what AMD called the Athlon CPUs. Cassettes have audio track too, so don't forget that. Yes you can turn off the I/O noise (mostly). With tapes that use audio backing track while loading you have to do so.

Another thing - you have to weight cost vs benefit. For cassette, it's kinda pointless having e.g. a 4K intro + loadscreen with animation/whatever because it's just going to add about 90 seconds to the load time. With disk, an 8K intro etc etc. adds 8 seconds loadtime assuming non-turbo. If you're dealing with program that's only 30K long and takes only 30 seconds to load, then what's the point anyway?

C64 has the advantage with disk in that a custom loader can just have the drive send bytes down the line as the computer dictates. So you could have a massive burst of data during offscreen and slow to a crawl or just stop during the visible part of the frame. I don't have a Happy drive but in theory maybe it could do something similar... but then again it'd be a case of doing so to prove you can - the user-base that have them makes it not worth doing such a system. The other thing "against" doing stuff during loads is the deficiencies built into the OS SIO to begin with. The 400/800 OS by default would disable DLIs during loading. And regardless of OS, the default IRQ handlers are somewhat generic and not efficient. The philosophy of the time was that during loading the computer wouldn't do anything else other than the bare essential housekeeping, so they didn't really worry about making the routines sparing on their CPU use.

Disk and tape load is generally byte oriented and "semi automated" since Pokey shifts in the bits and IRQs the system. Really, for tape loads you could get away with a lot, although the header bytes used for speed measurement in each block require precision measurement which ties the CPU up a reasonable amount. But in theory you could just use massive blocks to minimise any slowdowns. Then again, nobody cares for tapes other than those wanting to relive the torture of the past, so it's unlikely any software would be released for that media in the future. Disk is a different matter. These days with turbo-loading, the amount you can get away with is somewhat reduced. Most people would prefer a fast loading game that will load quickly with their custom hardware setups, rather than a constrained load at default speed with some pretty animation. But look at the Yoomp! loader - fairly sure it works with turbo-loaders, although it's only a simple bouncing animation.

Possible, of course. Just look to Alternate Reality, Seven Cities of Gold (loads during gameplay) and animations + sound during load for games like Ballblazer and Rescue on Fractalus.

I could probably whip something up although it'd probably be a day or so until ready.

You'd find them easier by just following the traces back from the controller port. Before doing anything though - maybe test those paddles on Joystick Port 2. Use that Basic program from before, but change the PADDLE function to use 2 and 3 instead of 0 and 1.

If you're up to it, you could put a socket in for Pokey then try another one. Or you might just identify the resistors and caps relating to the paddle inputs and replace them first to see if that fixes it.

800XL is 64K and effectively the same as an XEGS except no builtin game and the keyboard is integrated. 600XL is only 16K but can be easily upgraded internally to 64K.

Did you build the mod inside the computer or is it just inside a shell and in no way connected when you use paddles?

LCD should be a bit better, but the problem with LCDs running analog inputs is that the pixels don't map 1:1. The best display is by DVI/HDMI, which of course no old computer can supply. The hires on ST is effectively something like 900 pixels on a 4:3 monitor, so if your LCD has a decent resolution above that, it should look at least reasonable.

There are resistors and capacitors used on the Pot inputs. Could be that the somehow your lightgun mod has inadvertantly fried something. Or it might have even damaged the Pokey chip.

Should be fine I'd think... aren't TT and Falcon VGA type modes interlaced? In that case they're fine on a normal TV. Of course, most TVs have pretty poor resolution compared to a monitor, so 80 column text won't be as readable as on a monitor.