supercat

I need to get my Atari stuff unpacked (moved it to a new house after I got married) so I can get back to working on that stuff. I'm a fan of bank-switch addresses in the 0x400-0x0FFF range. There are lots of them, so one can switch directly among many banks. I'm also a fan of being able to access RAM via multiple methods (e.g. for E7-style banking, allow the same parts of RAM to be banked in at $1000/$1400 or at $1800/$1900, or allow 2K of contiguous RAM to be banked read-only at $1000-$17FF). Do the extended E7 formats allow for any of those things?

Out of curiosity, how hard would it be to produce a graphical rendering of STELLA with transistor-level resolution? I'd be curious to see how the physical layout of the chip compares with the schematics.

Most products are manufactured in batches. An assembly line will be set up, a bunch of product will be produced, and then the assembly line will be taken down and the equipment rearranged to produce something else. Given that the majority of people who would ever buy an FB2 would likely do so within a year of its becoming easily available, Legacy Engineering probably planned their most recent production run be their last. Setting up the assembly line again to produce more FB2 machines most likely wouldn't make sense, so it was better to simply produce enough to meet all expected future demand.

It probably wouldn't be overly difficult to interface a WII-style "light gun" to older machines, though calibration might be a little tricky. Actually, I'm rather disappointed that the WII doesn't seem to make any effort at calibration, since it should be possible to get pretty accurate aiming of the sensor bar and screen are in the same plane or close to it.

Translation from NMOS to VHDL is apt to be tricky. There are a variety of tricks one can use in NMOS which aren't practical in CMOS; I don't think such tricks would translate into VHDL either. BTW, I wonder if anyone ever constructed a two-transistor-plus-one-resistor XOR gate in NMOS. The input load will be variable, but even adding inverters on the inputs one would still come out ahead of a normal three-gates implementation.

Are these chips NMOS? Can modern chip fabs and processes handle that acceptably? Most chips today use static CMOS logic and are designed to minimize resistance and capacitance of internal nodes. The 6502 and TIA both use dynamic NMOS logic, and I would expect the other chips would as well. I would be very happy to see a successful build of chips based upon the old designs, but I would worry about whether they'd actually work the same as the old ones. The TIA has at least two race conditions I know about where the results aren't the same on every chip. There may be some others as well.

It should be easy for the ARM to provide some hardware assistance while maintaining the 'feel' of raw 6502 coding. For example, a cart could provide a bank-switch mode in which fetching a byte from RAM would stuff a 0 into the RAM while putting A9 on the data bus (the hardware to do that on a real cart wouldn't be hard; my 4A50 cart CPLD could provide such a mode if I went to the next larger CPLD). To clear a range of memory, one would simply bank it into an area which was followed by the code one wanted to execute after the "clear". Voila--memory cleared at a rate of one cycle per byte. Incidentally, my 4A50 cart supports some rather nice put-pixel abilities. To set a pixel whose coordinates are in X and Y: lda $1F00,x ora $1E00,y sta $1E00,y Nice and quick and easy. Incidentally, you could use a 108-pixel-wide bitmap.

Suppose one has a painful condition and a choice of treatments; one costs $100 and the other costs $10,000. The $10,000 treatment will cure all the pain perfectly (but will cost $10,000). The $100 treatment will do a pretty good job, but not a perfect one. Suppose the $100 treatment would be good enough that a Given a choice between (a) receiving the $100 treatment plus $5,000 cash, or (b) receiving the $10,000 treatment and no cash, a person would take the cheaper treatment plus the cash. Would there be any logical reason why such a person should be given the more expensive treatment? On the other hand, is there any reason to expect that someone who wasn't affected financially by his treatment choice wouldn't pick the more expensive one?

It's possible for a government-run system to cut costs in the short term by capping doctors' pay at a level high enough that someone who has medical training may as well remain a doctor rather than abandon his field, but at a level below that required to attract people into the field. This will work "nicely" as long as the existing supply of doctors holds out. Once too many doctors retire, however, the systems start to have severe problems. In England, elderly people are denied certain types of treatments because they're not "cost-effective". Realistically, there is no way that all such treatments could be provided to everyone, but that does not mean they should be denied even to people who would have the means to pay for them and who would rather spend their own money on treatment than on something else or leave it to their heirs. How would you suggest treatments should be prioritized? Indeed. Too bad there isn't any real insurance available to cover conditions which take more than a year to treat. That's a subject of a future entry.

Imagine that a restaurant were to announce to 100 diners--all strangers--that they would be splitting the tab. If a diner wanted to buy a $50 glass of wine, it would only cost him $0.50; on the other hand, it would also cost the other 99 diners $0.50. If the diner decided instead to have a $2 soda or a $5 glass of wine, he (and everyone else) would pay $0.02 or $0.05, respectively. What would people under such circumstances end up ordering, and what would they pay for it? Many people would dislike being in that situation, particularly with strangers. While some groups of coworkers will routinely agree to split restaurant checks without niggling over whether everyone's food cost the same, they generally don't want to be seen as unfair by their fellow workers. They will thus either seek to avoid spending substantially more than everyone else, or else offer to pick up a larger share of the total tab. In a group of strangers, however, such pressures will often not apply. If it seems as though many diners are going to have to pay $10 for other people's wine, they'll likely order wines costing around that much themselves, thus pushing the total up higher. Given a choice, most people would rather dine in a restaurant which allowed them to simply pay for their own meals, than dine in one in which they are required to pay for everyone else's. While there are some all-you-can-eat smorgasbord restaurants, the variety and quality of food is nowhere near what could be found at many pay-for-what-you-eat ones, and for good reason. Customers who are allowed to select expensive food and drink without having to pay for it are apt to do so, even if they wouldn't be willing to pay for the cost of such food and drink themselves. On the other hand, if some restauranteurs could get the government to require all restaurants to engage in "cost sharing", they'd make out like bandits. They'd be free to put whatever expensive and profitable items on the menu they wanted, secure in the knowledge that some people would buy them and everyone would have to pay for them. At first they might be limited by some restaurants' ability to limit their selections to only cheap ones, but if they could convince the government to require that all restaurants carry expensive foods and beverages, they'd be rolling in gold. A couple more observations: (1) customers of a cost-sharing business will often find the price to be much greater than what they would want to pay for the goods or services they expect to receive; (2) the quality of goods and services will often be higher than what customers would have wanted to pay for. Presently, much of what is called "health insurance" is in large measure really cost sharing. A single-payer health system would represent an even more severe form of cost sharing. Fundamentally the only way to get prices under control without restricting people's choices is going to be to increase the extent to which people pay for their own choices. Otherwise prices are guaranteed to increase exponentially until there is no choice but to ration services; rationing services will limit prices, but the variety of affordable choices will be far below what it would have been without cost sharing.

Did the kernel provide any support for the tow bar? I would think integrating that into the kernel would be essential from the get-go, since the success of that would be crucial to the success of the overall project.

Each sprite (player/missile/ball) has a circuit which will trigger a horizontal start signal whenever its horizontal counter hits 160. The players and missiles can also be triggered by count values of 16, 32, or 64, and the ball can also be triggered by a reset signal. The horizontal counters will be reset by RESxx, or whenever they reach 160. The logic to display players adds additional delay after the start signal is triggered. Each sprite's horizontal counter is hit with one pulse per pixel during the visible part of the scan line, and has an associated "supplemental pulse" circuit which can hit it once every four pixels. Normally supplemental pulses are only added during horizontal blank; pulses generated during the displayed portion of the line will not bump the counter, but will cause objects to be displayed oddly. The TIA has one four-bit HMOVE counter which is shared among all five sprites. Normally it sits at a value of 8. It is incremented once every four pixels if its value is not 8, or on the cycle following a write to HMOVE. A write to HMOVE has three effects: -1- It allows the HMOVE counter to advance once even if its value is 8. -2- It turns on all five sprites' pulser circuits. -3- If it occurs within the horizontal blanking interval, it will delay the end of the blanking interval by 8 pixels, thus depriving all five sprites of eight clock pulses they would otherwise have received (and generating an "HMOVE bar") Each sprite's pulser circuit will switch off as soon as its HMxx register matches the HMOVE counter. Note that if the HMxx register is not $80, it's possible that this may never occur. There are 68 non-displayed pixels per line, so the maximum number of supplemental pulses that can be generated is 17 for a line without an HMOVE bar, or 19 for a line with the bar (note that the bar itself will effectively subtract eight motion pulses, so the net effect in that case would be 11 pixels' worth of motion). The HMOVE circuitry is tricky, but if one understands it one can do some tricks which would otherwise not be possible.

If one doesn't mind using 16-bit maths for things, one can rather easily detect card combinations with minimal RAM by using a bitmask table (0,0,0,0,0,0,0,0,1,2,4,8,16,32,64,128,0,0,0,0,0) and then doing something like: ; Initialization lda #0 sta oddL sta oddH sta evenL sta evenH ; Assume following code is run once for each card; the card number in X register ; is in the range 0..12 (for A-K). lda mask+8,x and oddL eor evenL sta evenL lda mask+8,x eor oddL sta oddL lda mask,x and oddH eor evenH sta evenH lda mask,x eor oddH sta oddH ; Then run the following code to normalize things ; (may loop forever if there were a odd number of ; cards). lp: lda oddL ora evenL lsr beq done lsr oddH ror oddL lsr evenH ror evenL jmp lp Now if oddH:oddL are $1E:01 the player has a royal; if oddL is $1F the player has a straight. If oddL is 1 and all other bytes are zero, player has four of a kind. I'll post the other card combinations later if you need.

When the Atari 2600 came out, a real analog-to-digital converter would have been horrendously expensive, so Atari used resistor-capacitor timing circuits to measure the paddle positions. For such measurements, the wiper resistance will be part of the measured value. Thus, using a large resistor means that the wiper resistance (which can vary, leading to jitter) forms a much smaller percentage of the total than it would if one were using a lower resistance. Nowadays, ADC's are cheap but often require a moderately-low-impedance input for optimal results. Connecting a 1 meg potentiometer to a cheap ADC would yield results that would vary with temperature and have other annoying problems. A 10K pot will work better. Since the circuit measures the ratio of the resistances on either side of the wiper, rather than the combined resistance of one side and the wiper, wiper resistance is a relative non-factor.

Stellar Track is an interesting cart from a historical perspective, and it almost manages to put Star Trek into 4K, which is quite an accomplishment. A few points not yet noted: -1- The joystick entry routine defaults to the last value selected, whether it was a command number or a digit. So command #4 will always default to "4" as its first numeric entry; command #3 will default to "3", etc. -2- The game's final rankings seem to bear no regard for the difficulty of the original mission. Playing very well and barely winning a nearly-impossible scenario gives a lower ranking than playing leisurely through a much easier scenario. That IMHO is the biggest defect in the cartridge. -3- People not familiar with the computer game probably wouldn't have been terribly interested in the cart, but I would expect those who'd had exposure to it back in the day would have thought it the greatest thing since sliced Cheez-Wiz. Incidentally, I'd played the computer game BITD (on an HP-2000 with printing terminals), but not known of Stellar Trak until recently.

The double-shot feature is a rather interesting quirk, which may have been unintentional. Essentially what happens is that the game manages two players and two shots, and a control byte determines when the players or shots are controlled by each joystick. If this byte has a value of $00, both shots (and perhaps both players) are controlled by the left joystick. It's not possible for both shots to be fired simultaneously, even in the simultaneous two-player mode; there is a minimum vertical separation requirement. Thus, pushing the fire button will trigger one of the shots and try (but fail) to trigger the other one. The other shot can thus be triggered later even though the first shot is still on screen. The main control byte gets loaded every frame while the game is in demo mode, but this occurs after the machine checks the RESET button. If RESET is held on startup, the control byte never gets loaded. Since the cart clears all RAM to $00 on startup, the game will use a control byte value of $00. Incidentally, it would be very easy to edit the game so that a group of 16 variations would feature single player double shots. Editing it to allow both players in a two-player non-simultaneous game to have double shots would be more complex.

The 2600 was powered by magic to an extent unmatched by any other system. Look at the specs of that thing. Then look at Solaris, Thrust+, Toyshop Trouble, or Stella's Stocking. Or even many of the M-Network games. It's completely impossible for a system with such rudimentary specs to do anything near what some of those carts do. Four sprites in a row, independently colored on a per-line basis, with one of them being freely movable? No way. Four-voice music with limited amplitude control? Impossible. But squeeze in enough magic and the impossible can happen.

For an 8x8 (or thereabouts) sprite, there's really no alternative to simply drawing the rotated forms yourself. Some tools may be able to do a vaguely-recognizable version of your shape automatically, but getting 90% of the pixels right isn't the hard or time consuming part. What's hard is getting the details to look right.

Do any television sets provide a means of scanning a specific physical channel to see what it is? It's annoying having to do a long slow re-scan every time something changes. At least some sets allow one to do a "scan and add". Not sure what people with rotary antennas should do with sets that don't. Also, another one thing I've wished for--allocate a tiny portion of the bandwidth to an analog 'test pulse' (say, one scan line every 1/30 second) which nicer sets could capture and display, so as to allow a technically-inclined viewer to judge the trade-offs between signal strength, noise, and ghosting while adjusting his antenna. Otherwise it's had to distinguish between a signal that's barely adequate and one which has lots of 'headroom'.

Or else of using a 6502. Actually, 13 address lines would be plenty if the system did a couple other things to ease cartridge design: -1- Run the phi2 and r/w signals to the cartridge port. -2- Add some gates so the TIA and RIOT would only be mapped in pages 0-3 (or maybe 0-1, or 0-7). Possibly send a couple decodes out to the cartridge port. Combined with the above, phi2-qualified decode signals that would go low on any access to $0400-$07FF and $0800-$0FFF, would make it very easy to make a bank-switched cartridge with 2K RAM, using only 3 chips. Or an unbanked cart with 2K RAM with two chips (the RAM and the ROM). All nice and easy.

If you can use $DA, $EA, or $FA for the address, you could try: bne *+3 lda $FA That will take a constant five cycles, assuming the branch doesn't straddle a page boundary. Otherwise, the traditional approach would take six: beq *+3 byte $2C lda $80; Or wherever Note that accessing $80A9 (as the BIT will do) is guaranteed not to have side-effects in any existing banking scheme. If the $80 address were different, it could trigger a bank switch in some obscure schemes.

One difference is that on the Atari machines output 228 color clocks per line and 262 lines/frame, while the TI outputs 227.5 color clocks per line and 263 lines/frame. This may not sound like much of a difference, but it means that certain patterns of colors on the Atari will produce consistent color artifacts (for better or for worse); on the CV and other machines with similar chips, such chroma artifacts are so effectively reduced as to be all but non-existent.

The standard VGA scan rate for 640x480 is almost precisely twice the standard NTSC horizontal scan rate. Some of the cheaper VGA-to-NTSC converter boxes from decades back would rely upon this, so they only had to buffer about a scan line of display. Basically, they would output a line, skip a line, output a line, skip a line, etc. If the total number of lines was programmed to 525, the resulting signal would work reasonably well for NTSC. Some VGA cards could be programmed to operate at vaguely-NTSC'ish scan rates using interlacing. I did that with one of ATI's display cards in the early 1990's. That particular application drove an RGB display at NTSC'ish rates, but I would expect a chroma encoder would have allowed use of a composite monitor.

I would second that recommendation. There's only a certain level of sweetness one can perceive; doubling the concentration of a sweetener beyond that point will double the other tastes without improving sweetness.

Many more people would buy the units at $10 than at $40. Of course, Niles would probably not want to hand make as many units as he'd sell for $10, if he was only going to get $10 for them. There are many things I would like to have, but which cost more than I'd be willing to spend. I may think a particular artwork is pretty, and recognize that it took hundreds of hours to produce, and yet not be willing to spend more than $50 for it. Not because I don't appreciate the artistry, but because I couldn't afford to spend a huge amount for decoration.