EricBall

If you haven't played Occarina on the N64, you're in for a treat. It's still my favorite 3-D Zelda (of Occarina, Mask and Wind Waker). The story just works.

Exactly. Unlike the 2600 where the TIA gets hammered during the kernel, the MARIA registers are rarely updated. But for the NES the VPU access registers are not mapped to zero-page even though they get used almost as much as the TIA registers. You're probably right that the display list entry coding could have been done better. Again, it seems like things like indirect & write mode were added on after the original design was completed. I haven't spent lots of time in the 320 modes, so I can't comment on a those design suggestions. But, my guess is 160A was the original design point, with 320A added next and 320B added after. The other modes are just "free" side-effects of those three.

Hmm.. lot of work for 5 bucks. And I wonder how you write down that you watched off Tivo something which was taped two months ago. And then there's the porn...

Ouch. I feel your pain. My shower drain is backed up (again), so I'm taking showers with my feet covered in water until I work up the nerve to call the plumber. (This time I want them to scope it before they power snake it.) A couple of autumns ago I discovered the furnace wouldn't kick in after the summer of being turned off. The repair guy finally determined there was a wasp nest in the exhaust pipe. (I'm going to try to remember to put a cover on it this year.) At least the recent windstorm which hit the area recently didn't do any damage to my house. Other people lost shingles, siding, fences and even mature trees.

Yes/no. I think the biggest problem is the CPU load caused by the display list and shared memory architectures. Putting MARIA on a separate bus would have freed up a huge number of CPU cycles but would have significantly increased the system cost and the CPU cost to create the display lists across the split bus. Given the display list architecture, I don't think there's many questionable design decisions beyond using the TIA for sound. (And that was an Atari cost decision.) On a related note, I find it interesting that Nintendo (which did go with separate CPU & GPU buses and a fixed-function architecture versus the flexible display list) didn't map the CPU to GPU ports to zero page memory. I agree. I think 320 modes happened after GCC went with the 7.16MHz MARIA clock, which probably made it relatively easy to support 320 output. But then they didn't have the transistor budget to double the line RAM, so they had to figure out ways to translate 5 bits into 10 bits of color lookups.

Smooth horizontal scrolling is trivial (in 160 res) on the 7800 as each sprite has it's own horizontal position in it's display list entry. It's trickier in 320 res modes both due to the color issues supercat mentions and because the horizontal positioning is only on even pixel boundaries. Vertical scrolling is more difficult, especially with a background. (Though not impossible.) The number of sprites per line is limitted by the number of bytes fetched from RAM/ROM and the space allocated to each display list. My bouncing ball demo can handle 29 sprites (2 bytes each) per line (with no background).

Haven't checked out Wormy, RL has been a little busy.

The big disadvantage of using something other than TIA/POKEY sound is the lack of emulator & CC2 support. So you'll need to have the ability to make your own PCBs and burn PROMs during your development cycle.

See EDIT and new attachment in the first post. The demo isn't perfect. You will notice the balls slow down once a number of them get onscreen. This is because the display list builder plus the position updates are taking longer than a screen to complete. I also noticed some graphics glitches when playing on real hardware which I believe are caused by MARIA using a display list entry which is in the middle of being updated. Unfortunately, I can't think of an easy way to prevent this. The ball graphics are a quick conversion from Puzzle Bobble. I'm sure some hand tweaking would improve the look. There also may be some value in changing the code to cycle the animation differently than just basing it on the horizontal position.

I don't recall gopher or archie being that popular outside of the occasional university site. FTP/email/news was the big thing before http took things on. And I did many web pages (simple text, links & images) by hand.

Ahh, WSYNC + 7 would logically put you at the end of the DMA for the line. Then update the display list entries to fiddle the start address. Neat. And safe with a fixed display list since you can determine the number of cycles you have. Oh... do you use the same display list for _every_ visible display? That would be even more cool. (And makes the ZP/SP hole even more annoying I imagine.) I suspect the emulators don't handle DMA cycle stealing so that's why there's a difference. From the emulator perspective, it's only counting WSYNCs.

Although The A8/5200 have "display lists" they bear little resemblence to the 7800 version. That's not to say that using the A8 to learn 6502 is a bad idea.

Have you tested your pseudo kernel out on actual hardware? Are you updating the display list entry or the DLL entry? How do you sync with MARIA? (Since you're probably using more than 7 CPU cycles per line.)

Hmm... If there's one thing I've learned about the 7800 is it is CPU limitted. At least with a virtual bitmap you're not having to contantly rebuilt the display lists. The DMA cycle stealing should also be a little easier to predict. Note: there's no 2LK for the 7800, so you're limitting yourself to the only half of the screen height with 128x96.

Our neighbourhood has an annual garage sale. The local rate-payers association does some advertising and we get a lot of traffic. A side bonus is we have very few other garage sales during the rest of the year. (Other than the occasional moving sale.) As always, the challenge is to clean more stuff out than picking up other's junk. Well, that and figuring out how to sell off the toys my son has outgrown without him kicking up too much of a fuss.

This weekend I picked up Purr Pals out of the Walmart bargain bit for my 6 year old son. He's not really old enough for Pokemon yet. I figure I'll start him on the original Pokemon Blue via the Super Game Boy SNES adapter at some point.

It depends on your background. If you've never coded in any form of assembler then you'll probably find it tough going. And even then it's tough getting accustomed to the lack of only 8 bit address registers and other restrictions of the ISA. C (not C++) is closer to ASM than most languages depending on what you use it for and how much you depend on external libraries. The 2600 is also a challenge in itself. Coding your first complex kernel is definitely an exercise in frustration and cycle counting.

check out 6502.out

Check out 6502.org

My High School Physics teacher called this "the greater fool principle" - an item is worth what a greater fool (than you) is willing to pay for it. :-) And this is a very real question. For example, there are only a handful of Hozer Video Skeleton cartridges with unique artwork versus the larger number of AtariAge versions. (Not to mention the Skeleton+ carts available from AA & PackRat.) Are they worth any more than the AA version? Is Skeleton (or older versions of Thrust) worth more or less than the current version? I also know that there have been a few "limited edition" homebrews. (I can't remember the one which came in a wood box.) But I do know there a completist collectors out there who are willing to pay big bucks to have one of everything. (I once recieved an email from someone looking for a interim development release of something I did.)

I've been toying with an idea for a 2600/7800 TIA music player for a while. The design point is to minimize the space required, near 1 byte per note. A single byte would contain both frequency and period (4 possible). Plus, there's 34 codes for notes which would be played for a single frame for percussion sounds. Anyway, I'm wondering if anyone has a suggestion for AUDC/AUDF values for the single frame codes. e.g. AUDC = 8 AUDF = 0 high hat AUDC = 8 AUDF = 8 snare AUDC = 15 AUDF =6 snare AUDC = 15 AUDF = 30 kick drum

Yeah, but even though they are in orange, I have to scroll through 10 pages to find them. As a temporary workaround I've created a "draft" private category.

One of the classic complaints against the 7800 is it uses the 2600's TIA for sound. Maybe that could be used as an advantage. Imagine a TIA music editor which uses the 7800's graphical capabilities to display notes on a scale and to scroll in realtime during playback. My only question is how to get compositions out of the 7800 and back to a PC so the creations could be added to 2600/7800 homebrews. Maybe via a SaveKey <-> serial interface?

I've made some draft entries in the past, but never got back to them. Now they're tough to find.

The first Pokemon games were Red & Green (Japan only), with Blue & Yellow coming later. That was followed by Silver & Gold for the GBC, followed by Crystal and finally Ruby, Saphire and Emerald for the GBA.