EricBall

It's all a matter of perspective and tools. I'm sure that the folks working on cutting edge games for current consoles face similar difficulty levels when they have to "code to the metal" instead of using libraries of tools. A lot of the complexity of programming the 2600 comes down to the display kernel - the code that actually causes stuff to appear onscreen. You have a very small number of CPU cycles to work with each line. And each line you may have to update the GPU/TIA registers to change what is being displayed. And there's no buffering, so you have to carefully time your updates or they may not appear on the line you intended. Repositioning sprites requires even more careful timing. So you spend a lot of time counting instruction cycles and trying to squeeze all your desired functionality into that kernel code. bB makes the process easier by providing you with a set of kernel routines which you then use. A lot less complex, but you are also limitted to the provided functionality. (And I have to disagree with Sheepz - with the 2600 it's easy to get _somthing_ to appear onscreen, even if it's garbage. The problem is making what you want appear onscreen. Programming the 7800 and Propeller I spent many days staring at a completely blank screen - it makes debugging difficult.)

The big advantage of the TiVo is it's search and scheduling capabilities. Although it can record by time of day, you typically either record a given show title from a given channel (season pass) or set up a wishlist which uses a search string (i.e. an actor's name, part of an episode title) to find shows to record.

The other option is a TiVo. (Although the TiVo monthly subscription will be higher.) For analog cable (i.e. you get all channels when you plug directly into your TV), the S2DT will record two channels at once (or record one channel while you watch another "live"). Then there's the TiVo HD. It will also record two analog cable channels at once. It will also record any unencrypted digital cable channels (both standard def and HD), or encrypted channels (SD & HD) with a CableCard (rental) from your cableco. Or, you can see (via tvfool.com) what channels are available in your area via antenna and get your HD TV from there.

Yes, that is certainly true. However, I can't think of any reason to do this instead of just putting the game in a 2600 cart. It's not like the 7880->2600 game will have any advantages over the 2600 cart game once it's forced the 7800 into 2600 mode. I suppose it could alternate between the two (assuming it could keep the memory maps straight), but again I can't think of any reason to do this.

Just to summarize: 1. A 24 pin (4K) cartidge in an unmodified NTSC 7800 will result in the BIOS locking the system into 2600 mode because the RAM test will fail due to cart ROM shadowing. Dual-boot 2600/7800 carts are therefore impossible. 2. All 7800 graphics are generated by MARIA so all games are limitted to just the standard 6 graphics modes. However, the graphics mode can be updated on the fly which might be used to split the screen into 160 & 320 horizontal bands, intermix 4 color and 13 color sprites, or use different palettes for different horizontal bands.

Yesterday I tidied up the corner of the basement where I store all my computer (and other tech) junk. I have no idea how I ended up with a dozen (or more) IEC power cords. I should keep enough of the best looking ones for the working PCs and monitors I currently have and toss the rest. Or figure out how to make them into a modern art exhibit and sell 'em to some gallery. I also have a whack of serial cables which I'm trying to justify keeping. I don't think I have an external modem hiding anywhere - not that I have a big reason to use a modem anymore. I think I used them at one point to LapLink to an old PC to pull stuff off the harddrive. These days I'd just attach the harddrive to a USB adapter. So I guess I'll toss them as well - or add them to the modern art exhibit. However, sometimes that old junk is usefull. Apparently an old 5.25 floppy drive cable can be used as an SD card socket.

Your TV will be as good as an Apple monitor, although 80 column text may be hard to read. There's also an RGB connector ( http://stason.org/TULARC/pc/apple2/faq/16-...GB-monitor.html ), but it's interlaced at TV frequencies; which most VGA monitors won't handle. It looks like the GS had an external floppy drive which connected via a 19 pin D connector. Without that you have a doorstop. (Although it looks like benheck http://benheck.com/04-14-2008/apple-iigs-o...hardware-laptop used one of these http://www.whatisthe2gs.apple2.org.za/cffa-card-review/ to add a CF card interface to a GS.) Personally, I'd go for the Apple //c since it has a built-in floppy. Of course, I didn't keep my collection of Apple ][ software.

It depends on the TV/converter box. My Toshiba 52XF550U has the ability to add / remove a channel without doing a full channel scan. (Necessary because the scan deletes all of the custom channel names!) It also has a detailed signal meter giving all kinds of details like signal power & SNR. In general, ASTC is like FM radio - you either get a perfect picture or nothing at all. There is a small range of "marginal" where you will get video glitching (macroblocking), loss of audio, and the intermittent or partial frames. But analog distortions like ghosting and noise don't show up. Also, unlike analog, what makes or breaks ATSC is not signal power but signal to noise ratio (SNR). So things like a low-noise preamplifier and high quality antenna cable can make a big difference. ATSC also has some problems with multi-path (ghosting), especially if the second path is a strong signal.

When I developed Skeleton a bankswitched cartridge wasn't an realistic option if I wanted cartridges made as the circuit boards didn't exist. (Just recycled commons with a 7404 hacked on.) These days, that's not an excuse. However, there is something ... satisfying ... about managing to fit your dreams into 4K. Places to look for space savings: #1 Lookup tables can consume significant ROM. See if there is a way to replace them programatically. In Skeleton I had a lookup table which was used to cycle the color of the skeleton when it was killed. In Skeleton+ I replaced that lookup table with calls to the random number routine. The final effect wasn't the same, but was close enough. #2 Sometimes the reverse is also true - long & clumsy code can be replaced with a smaller lookup table - especially if the number of input values is small. #3 Don't be afraid to ask for help from the community - there are some really good coders out there who are willing to share their tricks. #4 Never lose sight of the end objective - create a game that is fun to play. 4K is a great objective, but if the game will be twice as fun if you go bankswitched...

The SPI interface for SD/MMC cards is well known and the cards are widely and cheaply available (especially in the smaller sizes). It might even be possible for the 7800 to read & write the SD card directly (via a CPLD for address decoding / latching, and some other logic to handle the voltage changes). Check with Chad Schell (Cuttle Card creator) as he's used them in his designs. (Although with more sophisticated hardware to handle dynamic bankswitching.)

90% of what everyone knows about MARIA is from the 7800 SOFTWARE GUIDE. However, here's an extract of some stuff I wrote for the 7800 Programming Wiki (RIP): An overview of how the 7800 produces graphics. On the 7800 a "display list list" contains a series of 3 byte entries which contain the address of a "display list" and the number of scanlines (typically 8 or 16) to draw using the display list. Each "display list" contains a series of 4 or 5 byte entries which contain the base address of a sprite or a character map along with the palette to use for the sprite/characters, the number of bytes, and the horizontal position. MARIA has the ability to cause an NMI when it completes a DLL entry ("display list interrupt"). The different 7800 graphics modes are defined outside of the display list by a combination of the MARIA CTRL register (horizontal resolution) and a flag in a 5 byte display list entry (colors per sprite). On the 7800 the screen is broken up into "zones" of 1-16 scanlines (typically 8 or 16), based on the 3 byte DLL header. The DLL header contains a 16 bit address pointer to the display list for the zone. The display list is made up of a sequence of 4 or 5 byte sprite headers ended by a 2 byte null header. Each direct sprite header contains a 16 bit address pointer to the graphics data drawn on the last scanline of the zone. (Indirect sprites, or tiles, are a little different.) Graphics data is laid out "upside down" with the last scanline on the lowest address and each scanline on a separate page. e.g. for a 2 byte x 16 line sprite $e000-$e001 bottom line $e100-$e101 2nd last line ... $ee00-$ee01 2nd line $ef00-$ef01 top line Horizontal motion on the 7800 is easy 'cause each sprite header contains a 1 byte horizontal position (though this means only 160 onscreen positions even in 320 modes). Vertical motion requires a little more work. Assume we are using 16 line sprites and zones. If the sprite is "on grid" then we have the following line 0-15 DLL -> sprite header -> $e000 Now say that the sprite moves down one scanline, then the sprite is overlaps two zones and we need the following line 0-15 DLL -> sprite header -> $e100 line 16-31 DLL -> sprite header -> $d100 Some of this seems counter-intuitive, but remember that the sprite header points to the bottom of the sprite. So the top scanline of the second zone will draw the graphics stored at $d100 + 15*256 = $e000 or the last scanline of the sprite. So the sprite has moved down one scanline. This is also where "Holey DMA" comes into play. In the above example the top scanline of the first zone will draw the graphics stored at $e100 + 15*256 = $f000. In the DLL there are two flags, one which treats odd 4K segment of ROM as full of zeros. So when that flag is set, graphics reads from $dxxx and $fxxx will be treated as zeros. Thus we can store code and non-graphics data in those segments.

Here's another way of looking at it. MARIA has two internal 160x5 bit LineRAMs. The Write Mode bit controls how the palette & sprite bits are written to LineRAM. The Read Mode bits control how the LineRAM bits are changed into 320H pixels. (160H being two 320H pixels of the same color.) write mode = palette+sprite bits to LineRAM entries: WM=0: P2|P1|P0|S7|S6 P2|P1|P0|S5|S4 P2|P1|P0|S3|S2 P2|P1|P0|S1|S0 WM=1: P2|S3|S2|S7|S6 P2|S1|S0|S5|S4 read mode = LineRAM entries to CLUT indexes (pixels): RM=00: X4|X3|X2|X1|X0 X4|X3|X2|X1|X0 RM=10: X4|0 |0 |X1|X3 X4|0 |0 |X0|X2 RM=11: X4|X3|X2|X1|0 X4|X3|X2|X0|0 (Note: there's an error in my previous entry for 160B. See WM=1 for the correct mapping.)

Some stations are transmitting a "night light" signal like the one you described. Others "flash cut", using the same frequency and changing from analog to digital. (In some cases one station turned off their analog transmitter and another powered up their digital transmitter on the same frequency.) And yet others simply powered off their analog transmitter completely. The biggest source of confusion, IMHO, is the use of virtual channel numbering. Although you now may be watching ABC 7-1 instead of ABC 7, the actual signal might be on channel 22 - i.e. on UHF rather than VHF. This is why people have to hit the "channel rescan" button on their converter, so it can sniff the channels and figure out the virtual channel number for each physical channel, instead of just entering 22 on the remote. Plus, as part of the transition, there's been a big move away from VHF to UHF. So people who only have a VHF antenna (since that's where the big 3 typically were) can't pick 'em up anymore because they've moved up to UHF. All so stations can preserve their "channel identity". I'm one of the lucky ones. I get 11 HD stations (plus subchannels) from Buffalo & Toronto via antenna. All of them were live before the February deadline, so the final shutdown made no difference to me (other than some of them bumped up their power). There are still a few in the area I don't get (although a couple of them are because I'd need to rotate the antenna), but I'm hoping to build a better antenna this summer and put it outside.

I wonder if this is more an artifact of the assembler than anything intentional. The assembler uses a 4K block of memory for the final output which previously contained the ASM code (post some kind of pre-assembler which explains the lack of comments and constants).

Nice, but can you turn it into a hackintosh? I considered buying a netbook for the explicit purpose of turning it into a hackintosh, but I eventually convinced myself I'd be more annoyed by the things which didn't Just Work than any pleasure of having an ultra-portable Mac.

2 days? It seems like the PSAs have been on for the past 2 years. And how difficult would it have been to supply different feeds for the different providers - one for OTA ATSC saying "You are currently watching digital TV - you won't be impacted (unless the station changes frequencies).", one for cable / satellite: "You are watching cable or satellite - you won't be impacted." and one for OTA NTSC: "You are watching analog TV using an antenna - you will be impacted. Go buy a new TV."

I was wondering why the PMC graphics wouldn't be page separated - that's a characteristic of the way MARIA works. Here's how to translate the sprite data to CLUT entries for the various graphics modes: P2-P0 = palette bits from header S7-S0 = sprite data from ROM 160A: P2|P1|P0|S7|S6 P2|P1|P0|S5|S4 P2|P1|P0|S3|S2 P2|P1|P0|S1|S0 160B: P2|S3|S2|S7|S6 P2|S3|S2|S7|S6 320A: P2|P1|P0|S7|0 P2|P1|P0|S6|0 P2|P1|P0|S5|0 P2|P1|P0|S4|0 P2|P1|P0|S3|0 P2|P1|P0|S2|0 P2|P1|P0|S1|0 P2|P1|P0|S0|0 320B: P2|0 |0 |S7|S3 P2|0 |0 |S6|S2 P2|0 |0 |S5|S1 P2|0 |0 |S4|S0 320C: P2|S3|S2|S7|0 P2|S3|S2|S6|0 P2|S1|S0|S5|0 P2|S1|S0|S4|0 320D: P2|0 |0 |S7|P1 P2|0 |0 |S6|P0 P2|0 |0 |S5|P1 P2|0 |0 |S4|P0 P2|0 |0 |S3|P1 P2|0 |0 |S2|P0 P2|0 |0 |S1|P1 P2|0 |0 |S0|P0 160A is 4 colors (well . . . 3+transparent/background) per pixel from 8 palettes, 160B is 12 colors per pixel from 2 palettes, 320A is 1 color+background/transparent from 8 palettes, 320B is 4 colors (different bit order than 160A) from 2 palettes. 320C and 320D are seriously warped as they mix the sprite and palette bits.

P2-P0 = palette bits from header S7-S0 = sprite data from ROM 160A: P2|P1|P0|S7|S6 P2|P1|P0|S5|S4 P2|P1|P0|S3|S2 P2|P1|P0|S1|S0 160B: P2|S3|S2|S7|S6 P2|S3|S2|S7|S6 320A: P2|P1|P0|S7|0 P2|P1|P0|S6|0 P2|P1|P0|S5|0 P2|P1|P0|S4|0 P2|P1|P0|S3|0 P2|P1|P0|S2|0 P2|P1|P0|S1|0 P2|P1|P0|S0|0 320B: P2|0 |0 |S7|S3 P2|0 |0 |S6|S2 P2|0 |0 |S5|S1 P2|0 |0 |S4|S0 320C: P2|S3|S2|S7|0 P2|S3|S2|S6|0 P2|S1|S0|S5|0 P2|S1|S0|S4|0 320D: P2|0 |0 |S7|P1 P2|0 |0 |S6|P0 P2|0 |0 |S5|P1 P2|0 |0 |S4|P0 P2|0 |0 |S3|P1 P2|0 |0 |S2|P0 P2|0 |0 |S1|P1 P2|0 |0 |S0|P0

Go to tvfool.com and see what stations you should be getting, what physical channel they are, and the direction they are in. Digital TV is all about SNR. The best ways to increase SNR are: 1. Height - even a second floor window or balcony may let you get more stations. However, the longer the cable the more signal loss & noise gain, and therefore the lower the signal to noise ratio. 2. Bigger / better antenna. I use a homemade Gray-Hoverman out a second floor window. The only drawback for high-gain antennas is they are highly directional. So if you have transmitters in multiple directions you may want a rotor or multiple antennas and a switch box. 3. Low noise pre-amplifier. A Channel Master 7777 or similar boosts the signal at the antenna to preserve the signal through long cable runs and splitters. The one big quirk of digital TV is channel remapping. The channel frequency used to transmit the signal (physical channel) is probably not the channel used to select the channel at the TV (logical/virtual channel). But it's a chicken & egg problem. You can't tell the TV to tune to a particular virtual channel until it's picked up that data from the physical channel signal. Therefore, you will need to tell your TV to scan for channels. Or you need to determine how to tell you TV to tune to a particular physical channel.

IIRC some of the other artificial sweeteners (like saccharine) have a pretty harsh taste if eaten raw. Maybe it's a matter of dosage? It's supposed to be 300 times sweeter, so you need to make sure you only taste the smallest amount or the pleasure turns to pain. Try putting just a little bit in a glass of water. Hmm.. Wikipedia mentions "some of its extracts may have a bitter or licorice-like aftertaste at high concentrations", so maybe it's what you got or how it was processed.

I have been playing Civilization since version 1 although I haven't played version IV or any of the version III expansions. Nor did I play on deity level. So I guess I'm not a hard-core Civ player. But that's a good thing, 'cause Civilization Revolutions isn't for the hard-core Civ players. Unlike the rest of the Civ seies which added complexity with each version increase, Civ Rev tries to make the game more fun by removing complexity. This isn't to say the game is easy (although experienced Civ players shouldn't have much trouble) but I bet you won't be missing what was removed. So, what has been removed? Terrain improvements to start with. No more micro-managing your settlers or engineers to irrigate, mine, road etc. Instead, terrain improvements are tied to building a city improvement. For example, building an iron mine automatically gets you the equivalent of a mine in any mountain squares. Roads are simply bought and provide only one step movement between cities. You can still micro-manage what squares your city population works or use the resource type presets. Cities also only require food for growth, not size - so no starvation. (Although settlers still consume population.). No pollution either. A lot of negative effects have been dropped. The size of the world is small, especially compared to the largest maps in the previous Civs. Oceans are much smaller, but this makes galleys (triremes) capable of exploring more than the coastline of the island you start on - especially since they come with a crew which can explore inland. However, ships can't attack land targets directly, but they can support land attacks - adding half of their attack strength. The tech tree has been stripped down to about half the size as other versions. But the important technologies like gunpowder and combustion are still there. Being the first civ to complete a tech often gives a nice bonus - like one of the unit you can now build. On the flip side there are some additions from the earlier versions or Civ. The big one is the concept of culture. Temples and cathedrals now add to your culture rather than making happy citizens. The more culture you have, the farther your borders extend from your cities. (Other civs can't enter your borders without declaring war.) And if your culture is high enough you can cause cities to join your empire. (The converse is also true - you can lose a city due to insufficient culture.) My biggest complaint with Civ Rev is diplomacy. You can buy and sell techs with the other civs, but more often the other leaders will be demanding techs, gold or great people; then declaring war when you say no or offer them something less. So even if you're trying for one of the peaceful victory conditions, you'll probably still be at war much of the time. Doublely annoying, you're rarely given the opportunity to make your own demands. So, in conclusion, Civilization Revolutions isn't as complex as Civ on the PC. However, it is still the Civ we know and love and is fun to play. Plus, it looks very pretty on a 52" 1080p HDTV.

In university I coded a trivial RTOS for the 68K in ASM. The demo app worked fine except it leaked memory. I finally found the problem by stepping through the code in debug mode and discovering the JSR free() was missing. It turns out I'd managed to hit backspace at the begining of the line, moving the JSR into the comment field for the previous line. Then there was the C code I did which worked fine but crashed on exit. Finally tracked that down to a negative array index. The Parallax Propeller has a really cool combo JSR+RET instruction (it modifies the RET to JMP PC+1 'cause it has no stack). The only problem is if you want a simple JMP, you have to code it as JMP #label (i.e. immediate valute). Otherwise you end up with an indirect JMP [label] which will then go off to never-never land. And although I've never killed anyone with a coding error, the first cartridge release of Skeleton+ had a bug and the "You Won" screen would roll.

IIRC Maria slows down the clock cycles when accessing the TIA & RIOT. So the RIOT timer isn't a stable clock and the number of cycles per line may depend upon whether the 7800 is doing DMA / normal code or accessing TIA & RIOT registers (i.e. sound, joystick and paddle I/O). I don't know if emulators have improved, but when I was developing I would have loved an emulator which actually modeled MARIA cycles and cycle stealing halfway properly. It was far too easy to create something using the emulator as a reference which had cycle budgets beyond what the hardware could provide. I remember that someone did an Elite 3-D demo which flat out wouldn't work on anything other than an emulator.

Whoops, I jinxed myself there. catseye.z3 isn't working correctly. That's weird 'cause HitchHiker's and MiniZork worked fine.

z3c.zip It works! I found the bug in the parsing routine (dumb error on my part). I'm going to call this chapter complete. The next chapter is to create z3.spin based on this code. I/O will probably be based on a serial terminal interface. And it will run catseye.z3, which is small enough to fit in HUB RAM (hopefully), so no SD I/O. The objective is to do as little as possible other than porting the code from C to SPIN.