supercat

Atari Climber was a homebrew. Arcade Pong, Caverns of Mars, and Lunar Lander are original creations that were produced for the FB2; Arcade Pong and Lunar Lander are based upon the corresponding arcade games; Caverns of Mars is based upon an A8 game. I believe Space Duel and Yar's Return are hacks; the other games not mentioned definitely are.

A few bits of advice from the author: (1) Until you get to the point that you can consistently play through December 24, I would suggest that you may want to make use of practice mode. You may practice any level up to the last one you've reached in normal play. The game will exit when a level is cleared in practice mode, but you can practice each level as many times as you like until you feel that you've mastered it, rather than having to play through e.g. the first twelve levels every time you want to try level 13. (2) In the first level that uses any particular toy, the toy-selection logic is guaranteed to choose lots of that toy. It is thus useful to run immediately to a color that can be used on that toy, even before any toys appear on the screen. You will nearly always benefit by doing so. If the new toy is a two-color either-order one, chose the color that will work best with other toys (e.g. on the first ship level, run immediately to the white since it will be useful to paint the first ship that comes out, but may also be useful if a candy cane or NIMROD appears). (3) Many of the two-color fixed-sequence toys have the same second color; it may be useful to do the first color of each of them, and then do a run of black or white to hit everything that needs it. (4) The conveyor belts will speed up each time a correctly-painted toy is cleared, and slow down every time a toy has to be wrapped around. If some conveyors are ignored for too long, they may become quite slow and it may take awhile for them to get up to speed again. (5) I tend to find it useful to pick one of the left-side colors, zig-zag to the right painting whatever toys need that color, then pick a right-side color and zig-zag to the left. (6) It's possible to paint a toy even if all but one pixel has scrolled off the screen. Chasing after a toy to catch it before it wraps will often be successful. (7) There is enough clearance between rows of toys to run between them without hitting any, but in some cases it may be easier to release the fire button just before passing over a toy that should not be painted. The elf does have some inertia, so this need not waste much time. ( Have fun!

Why should aliens care what we do with the planet? If they like dolphins and don't want them to become extinct, why don't they simply borrow some dolphins and raise them themselves? In the original movie, there was a mechanism offered by which mankind's weapons could disrupt other planets; even Plan Nine from Outer Space offered up something similar as a logical premise (the particulars in the latter were absurd, involving particles of sunlight composed of many atoms, but the overall premise was reasonable). The aliens care about the earth, uh, why exactly?

That would be my interpretation.

Suppose I have a game where the player is supposed to push a button as soon as the game shows a certain object on the screen or makes a certain noise. Someone who is playing the game on real hardware would likely have about a 1/60 second advantage over someone who is playing on emulation. In some types of 'twitcher' games, a 1/60 difference can have a noticeable effect on gameplay.

Real-world waves will not be square, but that does not imply the existence of ringing. A square wave which is overdamped or critically damped will not have ringing (for a given amount of bandwidth, one can get 'squarer' waves if ringing is acceptable than if it isn't, but if waves are sufficiently 'rounded' they need not ring at all).

But it's wired IIRC to appear in 4K of address space; each 512 bytes of address space has two mirrors of one 256-byte page.

I don't think it's a 2600 game.

Special-purpose solutions are usually better than general-purpose ones for this sort of thing. If you want to select one of 16 angles, start by taking the absolute value of dx and dy. Then note whether dx>=dy (assuming they're scaled to comparable units). If dx>=dy, note whether dx/2>=dy; otherwise note whether dy/2>=dx. That will get you to one of sixteen angles, though the centers of each angular range will be offset by 1/32 of a revolution from the compass points. So you could add a check for dx/4<dy or dy/4<dx and select a perfect compass point in the appropriate cases. If your goal is to make bullets travel toward a target, your best bet may be to scale dx and dy so that at least one is >= 128, and then have a loop something like this: lda #16; Total adjusted distance to travel sta distance lp: clc lda dx adc dx_acc sta dx_acc bcc no_x_bump inc xpos ; Or decrement it no_x_bump: lda #64 rol sta temp lda dy adc dy_acc sta dy_acc bcc no_y_bump inc xpos ; Or decrement it no_y_bump: lda temp rol ; Carry will be set tax lda distance sbc dist_adjx sta distance bcs lp The dist_adj table should indicate how much to adjust the 'distance' variable in the cases where the object isn't moved, where it's moved in the X direction only, in the Y direction only, or both. If dx or dy (or both) is >= 128, the loop will have to run no more than twice for each pixel of motion.

Shhh... don't give eBay any more idea for required seller surcharges. They're perfectly capable of adding surcharges for things whether or not they add real value, so what's wrong with suggesting something which would at least add some value for the money? Under the present system, it would be pretty easy for someone to show a picture of a high-quality item, wait until they'd gotten a good bid, and then replace it with a picture of a crummy item. I'm unaware of any means by which the buyer could prove that when the bid was placed the seller's site showed a quality item. I don't know if any scammers presently play that game, but it would be easy for them to do so. IMHO, any material change to an item's description or pictures should constitute a legitimate basis for a prospective purchaser to withdraw a bid; a seller who changes his listing should be able to demand that within a specified time a buyer must either reaffirm his bid (after having noted the changes) or have the bid canceled, but a bidder should not be forced to buy something whose description is materially different from what he bid on.

It would probably require more effort than it would be worth, but what would be particularly amusing would be if you kept a cache of which IP addresses had accessed pictures from which eBay items, such that the first IP address to access a picture from a particular eBay item would always see it correctly, while others would see some other arbitrarily-selected picture (what would be most cool, IMHO, would be a picture of a common cart or box with a post-it note bearing the name of the game, using the same general concept as the Church Sign Generator, etc.) Give the impression of "I'm selling this rare game, mint with box. The mint box happens to be from some other common game, but it's a mint box." If reloads from the first IP to post the item keep showing the good picture, sellers may not realize what buyers are talking about when they ask questions. (incidentally, I think any good auction site should insist upon hosting pictures themselves, so as to maintain a record of what pictures were associated with what items).

I have a very nice text display engine which should allow a practical amount of text to be stored on a 32K cart. The text must be pre-formatted onto lines of 26 characters, each of which must be divided into 13 character-pairs. The lines of text must then be subdivided into groups such that the lines in each group can be drawn with common set of about 248 character pairs. Somewhat irksome as restrictions go, but 26x20 display is nothing to sneeze at.

On the Apple II, a scan line consists of 64 cycles of 3.5 colorburst cycles each and one of 4.0 colorburst cycles. On the early-model NTSC C64's, a scan line consisted of 64 cycles of 3.5 colorburst cycles each; on the newer ones, it consists of 65 cycles of 3.5 colorburst cycles each (no funny extra half-cycle). On the Apple II, there is a pixel clock which runs at 2x colorburst, and that is divided by seven to get the CPU clock (with an extra cycle added between scan lines). On the C64, a colorburst/7 signal is generated and that is then multiplied by 16 to yield the pixel clock. The CPU clock is then derived from pixel clock/8. Note that for optimal color performance if one isn't planning to use artifacting, it's best that the pixel clock not be even remotely close to a multiple of colorburst. On the C64, it's colorburst * 16/7, which is a ways off from 2.0, but still close enough to get some artifacting in some cases. On newer C64's, however, the artifacting is minimized by the fact that the color phase will reverse on alternate scan lines and on alternate frames. The TI-99/4a, Colecovision, and Nintendo all use a pixel frequency which is about 1.5x colorburst, which is as far from an integer multiple as one can get, so color artifacts aren't the slightest bit noticeable on those machines.

The Klystron pod and reactor will both flicker at 30Hz if they're in the same horizontal 'zone'. Thus, they won't be on screen at the same time and won't collide. As the author noted, the tow bar does not flicker, though I don't remember collisions with it being checked (note that on half the frames, collisions between the tow bar and both sprites would be expected).

My favorite pet theory (no evidence to support it, and most likely wrong, but amusing nonetheless) is that IM had a problem similar to TEMPEST in the Arcade--the game was designed so that unauthorized changes to part of the binary would cause slight malfunction, but the game was released with such 'unauthorized changes' in place that hadn't been adjusted to work properly; in this case, my pet theory would suggest that 'converted by' string was used in a random generator.

Unless someone is on an amazingly tight budget, I see no reason to make single-sided boards. Double-sided with plated through-holes are the way to go. I'd also recommend solder mask, though some cheap proto services don't support it.

Changing a few gates on the C-128 would have made it a much better computer. IMHO, the biggest problem was that there was no way to create an "enhanced" C64 mode which would allow the use of the C128 features. Given that the C128 left some extended goodies enabled (e.g. the display chip at $D600) I see no reason they couldn't have included a mode that left the MMU at $D500 but was otherwise C64-compatible. Such a mode could have made it easy to have programs that would run on either a C64 or C128, but would benefit from the extra features of the latter.

From what I've read, the Jaguar has a limited total memory bandwidth, and executing an instruction on the 68000 uses twice as much bandwidth as executing an instruction on one of the other processors; in very few situations will one gain any performance by having the 68000 execute any significant amount of code.

In Stellar Doomsday Interceptor (mini-game) pushing left and right simultaneously will cause the aiming cursor to move sideways, but will not move the actual point of aim. Shots will thus explode in a spot completely independent of where they were aimed.

Has anyone analyzed the failure modes, and whether a suitably-designed reader might be able to recover 'difficult' disks?

I don't know if you've ever tried to pick up a hardwood desk. They're a lot lighter than pressboard ones.

There are some programs on the C64 whose protection-scheme loaders were much slower than the normal loader, as though that wasn't bad enough. I think the normal loader was about 800 bytes/second, but there were some games whose loaders couldn't even manage 300 bytes/second. For a program to take 20 minutes to load, however, would require a load speed of only 54 bytes per second (assuming a full 64K needed to be loaded). Tape might be that slow if the program was subdivided into 192-byte blocks, but were any programs that size subdivided in such a fashion?

Many business machines had good keyboards. Given its price, I don't think I'd classify the Kaypro II as a home computer.

I would expect that after 2009, many sets' coaxial RF inputs will no longer accept analog signals. Stock up now on old VCRs with analog tuners. Thrift stores and such should have them cheap. Don't expect they'll all work, but I bought two for $2 and one of them worked, so I figure $4 for a VCR is doing okay.

The VIC-20 and C64 keyboards were bad by today's standards, but they were good by the standards of the time. I never used the Atari 800 significantly, but I can't think of any other home computer which was on the market when the C64 debuted that had a better keyboard. The C64 keyboard was far better than the Apple ][+ keyboard, for example (the Apple //e didn't debut until the next year). Were there any other systems marketed for home use when the C64 debuted whose keyboards were anywhere near as good as that of the C64 and A800? Some business machines had good keyboards, but I can't think of any other home computers with even halfway-decent keyboards. Are there any I'm missing?