MrFish

I think part of the difficulty with this image is that the area where the flame is creates an ambient effect that results in a lot of colors. The target image actually looks good. Your output image is pretty good too; but I'm guessing you'd need to leave this one run for quite a while to get a lot of the details from the destination image. I might make an attempt at this one; but I'll probably severely downsample the colors (as I normally do) and lose quite a bit of the ambient flame effect (hopefully not too much). Might be interesting to see what else can be done with it, though.

I just had another look at Missile Command+, and it only uses 9,821 bytes of the 16KB cartridge.

Colors aren't all what makes a game. Just having less colors doesn't necessarily make it easier to replicate in software. For an 8KB cartridge release in 1981, I find it to be very good. You don't have the 3 missile silos; but that was patched in with Missile Command+, in a 16KB cart that doesn't even use most of the extra space.

Yeah, otherwise it would be called Spy Helps Spy, and that's just wrong!

mrfish - einstein laughs.xex

Yeah, it just uses the joystick trigger register. VBI is typically used and sufficient in most cases. I think this post is the beginning talk about the last iteration of the GUI's mouse driver. GOS Mouse Driver During SIO

Yes, I would have gone that route if I'd taken a few more minutes to think about it first. I just coded it the way I did to get it done fast so I could get to the info about the bits. I was actually gonna write and post something using bitwise operators after I came home from work tonight; but I was busy chatting with a female when I got home. Yeah, same here. It's common practice to program mouse code for port 2, so port 1 is open to use with joysticks and other controllers. Like I said, all what I coded was really quick, so I could give a quick response to the posts about using an ST Mouse here.

Here's the little piece of TBXL code I wrote to figure out how that works again. It just reads and displays the first 4 bits of joystick port 0 register. It would probably be a faster routine if using bitwise operators; but it works well enough to see what's going on. 100 GRAPHICS 0 110 DIM A$(4):POKE 752,1 115 ------------------------------ 120 DO 130 X=PEEK(632) 140 A$="0000" 150 IF X>7 160 A$(1,1)="1" 170 X=X-8 180 ENDIF 190 IF X>3 200 A$(2,2)="1" 210 X=X-4 220 ENDIF 230 IF X>1 240 A$(3,3)="1" 250 X=X-2 260 ENDIF 270 IF X>0 280 A$(4,4)="1" 290 ENDIF 300 POSITION 10,10 310 PRINT A$ 320 LOOP

Worth mentioning here too, is that a stock ST Mouse can only have it's left button read on the Atari 8-bit computers. There is a fairly simple mod for the ST Mouse that will allow the second button to be read, though.

I just had a quick look at what's happening again... It uses the first two nibbles of the register, giving one nibble to each axis. The x-axis uses the first nibble, the y-axis uses the second nibble. As the mouse is moved on a given axis, the nibble will rotate through the 4 values; not in numerical order, but as follows. 00 -> 01 -> 11 -> 10... and then in the opposite order when it's moving in the opposite direction on the same axis.

Right, so it wouldn't even require a real ST Mouse for emulation; it could just emulate it by plugging in a modern USB PC mouse, as all (or certainly most) emulators can.

It's just seen through the normal joystick registers as gray code. Any drivers written for it need to therefore be written in machine language in order to keep up with movement, to any practical usage. You can write a routine in BASIC (or even TBXL, etc.) to see how it works, and then move the mouse faster to see how it doesn't work.

I didn't have Missile Command back in the day. So, it was a good find (among so many others) when I returned to the hobby. I've also had a few CX80's (and ST Mice) for playing it. I have quite a few hacks (often unfinished) strewn all over this forum (and a few for the 2600), which basically target various graphic weaknesses of the originals. For instance, this fix of Parker Brothers' Q*bert for the 8-bit computers, in which the original has this mixed-up thing going on with his feet and legs. It just seems like someone was in a hurry creating the graphics for it. I like playing Q*bert a lot; so, it was partly a sanity hack, to allow me to play without seeing the stupidity every time. After I hacked his legs, I continued on with various other graphic shortcomings in the game. Here's the thread. There are quite a few versions posted along the way; so, you'll need to go towards the end to find the most-recent one. Q-Bert - Fixed Feet/legs I should probably consolidate links and/or files for all my hacks into one thread. Never heard of that one. I've used Atari-native tools for hacking in recent years, but I mostly use PC-based tools for everything at this point.

Yeah, more arcade-like doesn't necessarily always mean easier, or even more fun, for that matter. I was messing around to hack the airplane into something that looks a little more like the arcade (never liked how Atari rendered it on the 8-bit computers). Nothing difficult, but I think I just need to locate the playfield graphic of it (for when it gets shot); I already hacked the player-missile graphic graphic of it in the game.

BTW... has anyone tried Missile Command+ yet? It's the superior version of Missile Command (3 missile silos, various visual additions). Missile Command+.rom Missile Command+.xex