EricBall

That's quite a long throw from the projector to the screen. I'm surprised the projector could focus down that narrow. A 4:3 screen and DVDs, so are the students still shooting standard def? It reminds me of the time I got to see an Academy ratio movie in the theater (Wizard of Oz? I can't remember.) I just remember how big people's heads were and how I got a crick in my neck looking up at the screen. Very different framing than a modern widescreen movie.

Fixed the bug which was causing MiniZork to misfire. Still have the issue with input handling. Unfortunately, I didn't make a backup of Z3.C before I started testing. I'll have to do that in the future so I can see all the fixes.

http://en.wikipedia.org/wiki/List_of_Super_Game_Boy_games

Z3.C is functional, but I'm still bug hunting. It now gets to the first input in HitchHiker's, but doesn't grok the input. MiniZork starts, but misfires printing out the detailed location info. (Which probably means a bug is in the object/property/attribute code somewhere.) What I really want is a PC trace from a known good interpretter, which I could then use to narrow down my bug hunt. Unfortunately, none of the Z-Machine interpretters I've found has this option. I could look at their source code, but I'm not sure that would be any easier. It would be one thing to look at something specific (like how to handle Jump if Equal with more than 2 operands), but working through every opcode would be much harder. But I think I'm close. One idea I had last night is to compare what opcodes HitchHiker's and MiniZork use before the first input. Anything which isn't used can't be the problem.

Quantization noise - the usual way to improve it is to add a noise signal (less than 1 bit of the output resolution) to the input before the requantization. Unfortunately, this only really works at high sample rates. Low sample rates & low resolution = low fidelity signal.

What do you think the following C should do? unsigned byte zmem[128*1024]; int read_word( int a, x ) { a = zmem[a++]<<8 + zmem[a]; ... } There are three (!) errors in the above code: precedence error : addition is done before shift order of operations : is a incremented before the second array reference? compiler bug : a contains a++ after the operation All three can be worked around by using a temporary variable. Here's another gotcha I ran into: int PC; void run( void ) { ... op2code( op & 31, zmem[PC++], zmem[PC++] ); ... } Looks reasonable, provide the next two bytes in the instruction stream as operands. Again, there are several potential bugs lurking: is PC incremented before or after the function call (tested - it's before, at least with my compiler) order of operations : which operand gets which byte? is actually PC incremented before the second array reference? #3 turned out to be not true - the same value was passed in for both operands. Again, recoding with temporary variables worked around the problem. In both of these cases, the code looks sane. The compiler doesn't flag them as errors. But the results aren't what you'd expect.

90% of Z3.C is done (which means I'm only 10% finished, of course). Still todo: input & parsing status line initialization (i.e. load file to memory) save /load (phase 2) input_stream / output_stream (phase 3 - not needed for HitchHikers) Of course, the challenge with a project like this is the debugging can't start until all the code is done. The C code is also a little ugly, but I'm avoiding doing any optimization until I port it to spin.

Zork! HitchHikers! Ahh, the memories of glowing green text and the frustration a text adventure can bring. Interestingly, Infocom had the forsight to create their games as a program for a virtual computer. That way they didn't have to create separate versions of each for each home computer. The same game file could run on multiple home computers using the existing interpretters. And when a new home computer reached the market, the whole library of games would be available by just writing one interpretter. My plan is to create a Z3 interpretter for the Propeller. (Although I'm skipping the features only used by two Z3 games.) No small feat given the Prop only has 32K of onboard RAM (plus 2K dedicated to each processor) while the Z3 story files can reach 128K. Obviously some kind of virtual memory will be required. The plan is to use standard SD cards to store the Z3 story files. When first started, the interpretter will copy the Z3 file to a SAV file and swap pages between the SD card and RAM. I'm hoping I will have 16K available for the story file and 64 pages is a large enough working set that the swapping won't bog down the game too much. But, the first step is to write the Z3 interpretter in C on my PC. Although there are Z-Machine interpretters out there, many of them are designed to handle all 8 versions of the Z-Machine; while I'm more interested in keeping the size requirements as small as possible. So I'm limitting myself to just version 3 (Z3). This includes more than half the Infocom catalog, including Zork & HitchHikers. I also want to avoid any license issues. (Not that I have a problem with the GPL per-se, but the Propeller Object Exchange is based on the MIT/X.11 license which doesn't have a copyleft clause. So if I use code which is GPL'd, then I won't be able to relicense it and put it on ObjEx.) And although I'd love to just start writting in SPIN, the PC is a much better debugging environment. I also won't have to deal with the whole SD/virtual memory issue.

This weekend my wife spotted Civilization Revolution for the PS3 at Walmart. She (and I) loved playing Civ (1,2&3) so she was immediately interested. I thought I remembered seeing a downloadable demo, but I couldn't find it. Silly me it's "Sid Meier's Civilization" so it's under S. Anyway, I downloaded it and starting playing Monday morning. They are cruel. This ain't no demo, it's the first third of the game in all it's glory. More than enough to make me remember why I spent so many hours playing Civ. I originally skipped the demo because some of the early reviews implied it was "dumbed down" for the console. While I understand that a Civ4 purist might scoff at the simplifications; I, for one, won't mind not having to micromanage each citizen. Unfortunately, you can't save your game in the demo. But I'm sure this coming weekend I'll be playing the full version.

Curiously, I wasn't able to find any detailed info about how the chip works.

http://en.wikipedia.org/wiki/10NES

Go watch Howard Tayler's talk. It's only bad if you stop now 'cause then you won't get any better; but if you put in the work then you will get better. However, expecting King Features Syndicate or Universal Press Syndicate to do anything more than send you rejection letter for your current output is, IMHO, hopelessly optimistic. Your 'toons need to be funnier and drawn as well as what you see in your local newspaper for them to even consider you.

When I last looked into this in January I determined it wasn't worth my effort, especially if I wasn't willing to install Linux on my PS3. What I wanted was a LiveCD so I wouldn't have to install more than just the bootloader. Plus, it had to be fail-safe so a reboot would get me back to the XMB. Although some people had done some work along those lines there wasn't anything which looked idiot-proof enough for me. Some notes I made at the time:

Not to be Simon Cowell, but I find it difficult to get past the low quality artwork to get to the low quality jokes. Two webcomics I read regularly are Sinfest and Schlock Mercenary. Both have collections available in book form (one measure of success), and Howard Tayler (Schlock) actually supports his family via Schlock related income! That being said, I must remind myself that even Howard wasn't an overnight success. Instead, it was many years of hard work. (He gave a talk at Utah Valley University called "Talent? Who needs Talent?", available on YouTube, which I highly recommend.)

If you are going to/from RGB you also need the Luma, not just the Chroma phase/saturation. Note: these are NTSC CCIR 601 formulas, ASTC is different. Y = 0.299R' + 0.587G' + 0.114B' I = 0.596R' - 0.275G' - 0.321B' Q = 0.212R' - 0.523G' + 0.311B' (All values are gamma corrected.)

In spite of Skeleton+ being freely downloadable, an amazing number of cartridges have been sold. So don't think others won't want a cartridge just because they can play it for free. Many people want to play it on the original hardware. One piece of advice: Before comitting your creation to cartridge ensure that it is perfect. There's no way to issue a patch because you've discovered an obscure bug or had an idea which makes the game ten times more fun. (Yes, I'm speaking from experience in both cases.) Take your time, playtest the heck out of it, and listen to suggestions.

The Propeller projects I listed in a previous blog: PWM based waveform generator Done, but I'm not going to release it as the limitations outweigh the results. Since the waveform is hardcoded, there's no way to dynamically change volume. There's also no way to internally mix voices onto one channel. And, finally, the sound isn't that impressive. (I was hoping to get something which really sounded like a cello or trumpet.) single pin NTSC text display driver Functionally working 100% even without a filtering cap. Now I need to make the hardcoded variables into parameters and calculated values. I might even do a PAL version. Plan is to release this to ObEx. IF_NEVER timing tests Complete. All IF_NEVERs take 4 cycles, irrespective of the opcode. It would have been more interesting if it wasn't, but this result merely confirms the datasheet. Extend NTSC240H to have background tiles too On hold pending interest (mine and others). I think my next geek project will be the GH antenna.

Who wouldn't want to have their own pinball machine? You too can be a pinhead, all you need is the space and the cash. I have the space . . . in theory. I have an unfinished basement but it has accumulated a lot of stuff & junk over the past decade of residence so there's not a lot of empty floor space. Getting stuff down to the basement is also a challenge as the stairs make a 180 degree turn halfway down. But ultimately no show stoppers. The cash is kinda sorta there too. The royalties from Skeleton+ have accumulated a tidy sum over the years - extra income just looking for something to be spent on. Pins can range from several thousand dollars for a NiB Stern or a mint "classic" to $500 or less for a fixer-upper or older electro-mechanical. One thing which experience has shown me is although I can fix things, that doesn't mean I will fix things. So my preference is for something which is 100% working. (And remember, anything which is labeled "easy fix" isn't or the seller would have fixed it.) Unfortunately, that cuts out a lot of pins available in the under $1000 range, particularly if I also avoid the EMs. (More because they tend to be fairly simple and therefore not worth the $$ IMHO.) Of course, I could get a NiB Stern but that's way beyond my "mad money" price range. The problem is, even if I stick to my "off the books mad money", I'm still spending hundreds of dollars on an entertainment item. I already have a PS3, Wii and other consoles to "spend" my limitted entertainment time on. Would a pin be worth the $$, or would it end up gathering dust after the newness wears off?

Yep, Prop = Parallax Propeller. The PWM waveform driver is something I tried before but didn't get the results I expected. The basic concept: Set Counter A to produce the desired output frequency and Counter B to output a DUTY (i.e. PWM) waveform to the desired output pin. Read Counter A's phase register and use the MSbyte as a lookup into a PCM waveform table. Set the frequency for Counter B to the lookup value. Repeat for the desired time period. In theory, instead of a square wave you can produce more "musical" tones.

Last night I posted my sprite video driver to the Prop forum, complete with demo (a bouncing beanie which explodes into individual sprites). Screen capture in MPEG2 of first 20 seconds: ntsc240h.zip So far, I've had two comments - one attaboy & one not-very-useful. (The latter obviously can't see the videogame potential.) But like the circus bugs in "A Bug's Life" I crave applause. I want that feedback! Sigh... other Prop projects I'm considering: PWM based waveform generator single pin NTSC text display driver IF_NEVER timing tests Extend NTSC240H to have background tiles too I also have Leprechaun & SpaceWar! 7800 to finish. Getting back to these means relearning my own coding, a daunting task. I also need to get the "new" PC for my Tempest cabinet working, and one of these days (maybe this summer when my Dad is in town) make some progress on my MAME cocktail cabinet. Oh, and how can I forget - I need to build a wideband Grey Hoverman antenna and mount it outside for better OTA HDTV reception. (I get 6 US networks and 6 Canadian networks all in full HD with my quick and dirty GH antenna in a 2nd floor window!)

Although you may want a tutorial, you don't need a tutorial. There is a huge amount of information in this forum alone, with links to other information sources. It may not be structured or provide the same level of hand holding as a tutorial, but this means you will have to think more thus improving your ability to learn the subject instead of simply parrotting by rote. Now, if you decide to document your own learning process as a "7800 101", I'm sure that others will find the information valuable. And if you have specific questions, or need clarification, then there are many here who can assist. A few years ago I tried to get a 7800 mailing list up & running. It still exists (although rarely gets used). But at that time I put together a list of 7800 related links: http://www.freelists.org/webpage/atari7800

If you ignore the "$100 shipping for the $1 item" scam artists, I think shippers fall into three main categories: 1. actual cost - typically these are low volume sellers so they have the time to figure out the shipping cost for each item. If they're smart, they will include the cost of any packing materials. 2. flat rate - they guys either ship lots of the same item or enough of similar items that they can determine what their overall actual cost is and then divide it by the number of items shipped. This is also the price the herd uses. 3. courier pricing - UPS, FedEx & the other couriers have online calculators. Plug in the size & weight of the item along with the to & from and the calculator gives the price. Or use one of the prepaid boxes. This is often used by high volume sellers who don't have the time to figure out the actual cost.

Modified the second clause so it only applies to binary only distributions. So if you include the source, then there's no requirement for a third-party acknowledgement in the software/documentation. But if you make a binary only (i.e. commercial) application using my diver, you have to give me credit.

The problem with URL citations is it isn't future proof. (One of the reasons the GPL insists the entire GPL be included. But I think I've found my happy medium: I have made the first clause more specific that the license only has to appear in the source file containing the driver (i.e. NTSC240H.spin). And the second clause (which is a combination of clause 2 & 3) only requires the copyright to be included as a third-party acknowledgement. I was thinking about it last night - I have written a driver, not the complete application. Thus, my license (and it's clauses) only apply to the driver. e.g. The person writing the rest of the application may want to have a disclaimer on the application, but there's no reason that my disclaimer has too be visible outside of the file containing the source code I created. I have also dropped the anti-advertising clause. I think that's more critical for semi-corporate copyright holders.

Actually, I just had a thought. The current license requires the user to duplicate my license verbatim. Maybe add a clause which allows the user to incorporate my license into theirs.