Rybags

The audio mix with SIO audio in and the PBI/ECI audio in occurs after Pokey. So, in conjunction with the GTIA CONSOL bit, we have 3 extra audio sources that get added. If that circuit is replaced then obviously those things have to be picked off and added to the new output circuit.

The key repeat rate is hard-coded so if the Antic from another system is present the key repeat will seem wrong. Properly converting any machine NTSC to PAL is usually a non-trivial thing since a proper PAL signal needs the 4.43 MHz crystal and extra circuitry that's usually not present on NTSC machines. ? PEEK(53268) should return 1 for a PAL GTIA, 15 for an NTSC one. Telling which Antic is present isn't quite as easy. In Basic the easiest way might be to just use the frame counter updated in VBlank. 10 POKE 20,0:POKE19,0 20 S=PEEK(20)+PEEK(19)*256 30 POS. 0,0 : ? S/50 ; " " ; 40 GOTO 20 Run that and compare against a watch after about 30 seconds. If it's running apparently too fast then it's got an NTSC Antic.

Those switches tend to get a fair bit of free play in them when aged. They're pretty good quality to begin with and likely there's still off-the-shelf replacements or near matches around.

Have to say that's a pretty good effort for the size of program.

Well the obvious thing now is to throw RC at it (would probably go well with some prep like making the background a uniform luma so colours don't go to waste)

The speedup is deliberate. Handy on lower difficulties since the speed is a bit slow by default.

I never got real far as I got sick of trying to work out what the upgrades did, and didn't much enjoy the gameplay, especially having your arse handed to you because you replaced an OK module with a crappy one. To me it's more of an impressive tech demo than a good videogame. Eidelon and RoF being much better games to play.

Do any upgrades affect cursor or rotation speed though? The most noticable thing I used to experience was the recharge delay when firing.

The 320 pixel modes including default text Gr. 0 don't allow independent colour from the background (unless you have VBXE or Sophia but that's sort of irrelevant). There's a trick using PM graphics to overlay the pixels at least partially to allow more colour but generally not used a lot and with limitations given that you can only cover 1/4 of the screen without extra trickery.

As clunky as the controls can be, that's the game mechanic they chose. To allow what you request would probably make the game too easy.

The other trap in Shamus is that once you clear a room you speed up. Handy on lower settings but can be an easy and annoying way to die on higher ones. I notice Savetz has interviewed Cathryn though it looks like the subject matter was Shamus II and Zeppelin. Liked Zeppelin a lot. Shamus II was OK but tedious to the point where I gave up on it.

Back in the day I looped through it fairly easily. On the following black level the speed bumps up as if you'd increased the difficulty setting. Not sure where it tops out. The thing I want to know is the so-called Pod Rooms (as mentioned in the original instructions). Did anyone find out about these? Has Cathryn Mataga been interviewed in the modern day about it?

The wait is due to disabling DMACTL. If you do that partway down the screen you get a dirty transition, like half a displayed frame then black. Atari programs for the most part are good in that display transitions are usually clean. Once you're done with needing interrupts disabled you should probably enable them again. If IRQs are left masked by SEI, the stage 2 VBlank won't execute (assuming the VBlank NMI is enabled again to begin with)

I remember a game in Compute! that generated a maze in Basic. It was only in a low-res mode (probably 5) but likely it could easily be adapted for other sizes. No idea what it was called though, we're probably talking sometime between late 1982 to mid 1984.

From what I can gather (try image search) the board orients such that it's towards the front of the case, not cartridge. The Antic adaptor board should be covered by the VBXE. Check the second image on the bottom of Lotharek's page here https://lotharek.pl/productdetail.php?id=53 I think the XE with 14 MHz crystal allows just leaving it in place. Mine's on a mainstream 800XL with 3.5 MHz PAL so was a somewhat different install + over 10 years ago now.

He's commented out the NMI disable so it's not going to work properly because of that. As you're disabling the display, I'd suggest to do that offscreen so there's no unwanted glitches. Insert before all of the other stuff: wait_offscr lda vcount cmp #$10 bcs wait_offscr (using VCOUNT as RTCLOK won't work if NMI already inactive)

Disable interrupts before doing shadow register stuff. sei lda pactl and #$fe sta pactl lda pbctl and #$fe sta pbctl lda porta lda portb ; clear any pending PIA IRQs lda #0 sta nmien sta irqen sta sdmctl sta dmactl

I don't think so. 5200 has no PIA so that rules out the digital outputs it provides. Stick axes are analog by means of 2 paddle (pot) inputs per port. Keypads are by means of the Pokey keyboard scanning. And fairly sure there's a fire button connected to GTIA STRIG input per stick. I seem to recall a method being described that uses fast pot scan mode to be able to do digital output on a pot line but unsure how and if it can be done on the 5200. A better solution for what you describe for the 5200 would probably need D->A converters to provide the variable stick X/Y values. Keys... you'd probably need to monitor the keyscan and return relevant outputs at the right times.

Can't say I've had the same problem. I've had reasonable picture from every device I've used which would include several PCI cards and a recently bought USB capture device with the usual composite and S-Video inputs. See if VirtualDub from phaeron's site http://virtualdub.org works better. It should give you access to all the available driver dialogs. Often there's stuff like brightness and contrast overrides which might help.

VBXE is probably the only integrated upgrade that can to an extent do Ram banking in similar fashion to what a cart can do for Rom or flash. But it's limited to 512K worth, and the banking registers are different to anything that's cartridge based. And yeah, game looking good. Will there be the usual assortment of moving enemies though? And somewhat agree on the music, it is on the annoying side.

Lunar Lander is on Atarimania http://www.atarimania.com/game-atari-400-800-xl-xe-lunar-lander_13848.html

800XL? Maybe the PS senses no load and goes into some sort of sleep mode? Can you measure it's voltage in load/no load situations?

The flags as such just control user input, not output to E: or S: The C= computers have a code that sets Rvs Off or Rvs On but we don't. Atari stores the characters as they'd be printed. Possible solutions - a subroutine that takes a string then sets each character and prints the results (in Basic would be somewhat slow). An assembly routine could do likewise. Since you can pass string addresses to them, it could make it easier. e.g. Z=USR(<convert routine>,ADR(A$),ADR(B$),LEN(A$)) Then the routine could walk through copying A$ to B$ and set the high bit to 1. A more sophisticated variant might see you using an embedded character or command sequence that sets inverse to on, off or toggle existing.

Can't remember what my first useful program or game was. Early ones I did on multiple computers were variants of Surround (the 2600 game) and the Lunar Lander types. And Escape which I later redid and renamed as Moon Shuttle (not really related to the arcade of the same name). The best Lunar Lander game was on the 800XL, I did that in Basic + asm with a bunch of DLIs for plenty of orbiting rocks.

Yep. C64 colours remind me of the crappy 1-bit RGB component that 1970s terminals had. Immersion in PoP is an important thing, and good graphics + speed of gameplay are big contributors to that.