Slashdot Mirror

And it's saved me and others countless time, I'm certain. When it comes to C code I comment similarly to how the article suggests. It's fairly obvious. For example, consider this code. There's some tricky stuff involved in correctly emulating the controller inputs for the Intellivision, and the bulk of the comments revolve around explaining the trickiness.

That said, when I code assembly language, I tend to comment nearly every line. Why? Unlike C code, most assembly statements aren't very descriptive. For instance, "MVI@ R4, R0" means "read whatever R4 points to into R0." Ok, but what might R4 be pointing to? What kind of thing are you reading? What are you trying to accomplish? Imagine if you wrote your C code so that all pointers were named p and q, and all other variables were named i, j, k, a, b, and c. That's what assembly's often like. So, I use short per-line comments (or sometimes per group-of-lines comments) to add that missing information. Here's an example from Space Patrol. (In this particular example I also was counting cycles, due to the performance critical nature of the code. That's an entirely different story.)

All I can say is that comments like these have saved my ass more than once.

Hmmm... I found a copy of the DDR version of the track. That's enough for me for now.

Prevailing wisdom and personal experience suggest using "-j N+1" for N CPUs. I have a 4 CPU setup at home (dual dual-core Opterons). Here's are approximate compile times for jzIntv + SDK-1600, which altogether comprise about 80,000 lines of source:

• -j4: 6.72 seconds
• -j5: 6.55 seconds
• -j6: 6.58 seconds
• -j7: 6.59 seconds
• -j8: 6.69 seconds

Now keep in mind, everything was in cache, so disk activity didn't factor in much at all. But, for a typical disk, I imagine the difference between N+1 and N+2 to be largely a wash. N+1 seems to be the sweet spot if the build isn't competing with anything else. Larger increments might make sense if the build is competing with other tasks (large background batch jobs) or highly latent disks (NFS, etc). But for a local build on a personal workstation? N+1.

This particular patent looks to be a rather unusual and somewhat odd way to implement breakpoints. You put the breakpoints in at compile-time as function calls to an empty function, and then the debugger (if it's running) puts a trap in that empty function. The technique isn't too far, though, from some ancient and well known techniques.

I once implemented a debug monitor in a similar manner: Call a magic location. If the monitor's present, see if the host wants anything. If the monitor's not present, it's a NOP. Similar concept. In my case, though, I was implementing remote watch windows over a special parallel-cable link. The monitor request poll just lived in the idle loop. The test was cheap enough I actually left it in my production code. (Look for EC_POLL and friends.) The monitor itselfis pretty simple and kinda cool. (Source: INTV-side ASM and PC-side C code)

Prior to that, I had implemented a monitor for an 8052 board that used the "call-instruction-as-breakpoint" technique. If you wanted a breakpoint in a loop, you were advised to assemble NOPs or a call to the breakpoint function into your app, because the normal breakpoint clearing technique (replace the call with the original code) meant you couldn't hit the breakpoint more than once. The breakpoint design wasn't mine. I'm pretty sure every CPU board we had in the lab for the particular modular computer system we had used the same technique. (It was a custom system designed by our professors and implemented incrementally over the years by students.)

Methinks there's lots of prior art in this space. Even if EPSON's exact way of doing it wasn't previously widely known, it's close enough to other techniques that it brings the novelty and obviousness into question.

This particular patent looks to be a rather unusual and somewhat odd way to implement breakpoints. You put the breakpoints in at compile-time as function calls to an empty function, and then the debugger (if it's running) puts a trap in that empty function. The technique isn't too far, though, from some ancient and well known techniques.

I once implemented a debug monitor in a similar manner: Call a magic location. If the monitor's present, see if the host wants anything. If the monitor's not present, it's a NOP. Similar concept. In my case, though, I was implementing remote watch windows over a special parallel-cable link. The monitor request poll just lived in the idle loop. The test was cheap enough I actually left it in my production code. (Look for EC_POLL and friends.) The monitor itselfis pretty simple and kinda cool. (Source: INTV-side ASM and PC-side C code)

Prior to that, I had implemented a monitor for an 8052 board that used the "call-instruction-as-breakpoint" technique. If you wanted a breakpoint in a loop, you were advised to assemble NOPs or a call to the breakpoint function into your app, because the normal breakpoint clearing technique (replace the call with the original code) meant you couldn't hit the breakpoint more than once. The breakpoint design wasn't mine. I'm pretty sure every CPU board we had in the lab for the particular modular computer system we had used the same technique. (It was a custom system designed by our professors and implemented incrementally over the years by students.)

Methinks there's lots of prior art in this space. Even if EPSON's exact way of doing it wasn't previously widely known, it's close enough to other techniques that it brings the novelty and obviousness into question.

This particular patent looks to be a rather unusual and somewhat odd way to implement breakpoints. You put the breakpoints in at compile-time as function calls to an empty function, and then the debugger (if it's running) puts a trap in that empty function. The technique isn't too far, though, from some ancient and well known techniques.

I once implemented a debug monitor in a similar manner: Call a magic location. If the monitor's present, see if the host wants anything. If the monitor's not present, it's a NOP. Similar concept. In my case, though, I was implementing remote watch windows over a special parallel-cable link. The monitor request poll just lived in the idle loop. The test was cheap enough I actually left it in my production code. (Look for EC_POLL and friends.) The monitor itselfis pretty simple and kinda cool. (Source: INTV-side ASM and PC-side C code)

Prior to that, I had implemented a monitor for an 8052 board that used the "call-instruction-as-breakpoint" technique. If you wanted a breakpoint in a loop, you were advised to assemble NOPs or a call to the breakpoint function into your app, because the normal breakpoint clearing technique (replace the call with the original code) meant you couldn't hit the breakpoint more than once. The breakpoint design wasn't mine. I'm pretty sure every CPU board we had in the lab for the particular modular computer system we had used the same technique. (It was a custom system designed by our professors and implemented incrementally over the years by students.)

Methinks there's lots of prior art in this space. Even if EPSON's exact way of doing it wasn't previously widely known, it's close enough to other techniques that it brings the novelty and obviousness into question.

This particular patent looks to be a rather unusual and somewhat odd way to implement breakpoints. You put the breakpoints in at compile-time as function calls to an empty function, and then the debugger (if it's running) puts a trap in that empty function. The technique isn't too far, though, from some ancient and well known techniques.

I once implemented a debug monitor in a similar manner: Call a magic location. If the monitor's present, see if the host wants anything. If the monitor's not present, it's a NOP. Similar concept. In my case, though, I was implementing remote watch windows over a special parallel-cable link. The monitor request poll just lived in the idle loop. The test was cheap enough I actually left it in my production code. (Look for EC_POLL and friends.) The monitor itselfis pretty simple and kinda cool. (Source: INTV-side ASM and PC-side C code)

Prior to that, I had implemented a monitor for an 8052 board that used the "call-instruction-as-breakpoint" technique. If you wanted a breakpoint in a loop, you were advised to assemble NOPs or a call to the breakpoint function into your app, because the normal breakpoint clearing technique (replace the call with the original code) meant you couldn't hit the breakpoint more than once. The breakpoint design wasn't mine. I'm pretty sure every CPU board we had in the lab for the particular modular computer system we had used the same technique. (It was a custom system designed by our professors and implemented incrementally over the years by students.)

Methinks there's lots of prior art in this space. Even if EPSON's exact way of doing it wasn't previously widely known, it's close enough to other techniques that it brings the novelty and obviousness into question.

This particular patent looks to be a rather unusual and somewhat odd way to implement breakpoints. You put the breakpoints in at compile-time as function calls to an empty function, and then the debugger (if it's running) puts a trap in that empty function. The technique isn't too far, though, from some ancient and well known techniques.

I once implemented a debug monitor in a similar manner: Call a magic location. If the monitor's present, see if the host wants anything. If the monitor's not present, it's a NOP. Similar concept. In my case, though, I was implementing remote watch windows over a special parallel-cable link. The monitor request poll just lived in the idle loop. The test was cheap enough I actually left it in my production code. (Look for EC_POLL and friends.) The monitor itselfis pretty simple and kinda cool. (Source: INTV-side ASM and PC-side C code)

Prior to that, I had implemented a monitor for an 8052 board that used the "call-instruction-as-breakpoint" technique. If you wanted a breakpoint in a loop, you were advised to assemble NOPs or a call to the breakpoint function into your app, because the normal breakpoint clearing technique (replace the call with the original code) meant you couldn't hit the breakpoint more than once. The breakpoint design wasn't mine. I'm pretty sure every CPU board we had in the lab for the particular modular computer system we had used the same technique. (It was a custom system designed by our professors and implemented incrementally over the years by students.)

Methinks there's lots of prior art in this space. Even if EPSON's exact way of doing it wasn't previously widely known, it's close enough to other techniques that it brings the novelty and obviousness into question.

According to this, his charisma is pretty high.

I authored an Intellivision emulator and a development kit for Intellivision. I've got a decent portion of the free Intellivision emulator market, and pretty much all of the dev-kit market. Sure, that's an active audience measured in the dozens, but I'm happy. :-)

I authored an Intellivision emulator and a development kit for Intellivision. I've got a decent portion of the free Intellivision emulator market, and pretty much all of the dev-kit market. Sure, that's an active audience measured in the dozens, but I'm happy. :-)

Ditto. Throwing my own 2 cents in:

I had some vague notions, and had even written some toy programs that implemented those notions. But otherwise I sorta jumped head first into writing my emulator, jzIntv. What made that even more exciting is that there wasn't much documentation out there, and basically only one person, Carl Mueller Jr., who had done any real reverse engineering work on it.

I built from his documentation and experiments using his emulator to produce my own. (His emulator was a closed-source, DOS-only implementation. Mine is open source and cross platform.) I think for me, the most interesting parts were in learning the system, reverse engineering it in the areas that were still quite grey, and documenting it for everyone. I also put together a development kit for the machine, because Carl's tools were, again, DOS-only and closed source.

It's been a hell of a trip, and I managed to learn a lot doing it. It's been my background project. As part of that, I've also written a couple of games, and am about to release probably my second largest non-work programming project, Space Patrol, pretty soon. (I consider jzIntv/SDK-1600 to be one very large project, although Space Patrol will get absorbed into that megaproject after it's released.)

Nobody taught me how to do any of that. I'm an EE by training. But, you pick up on things if you read and ask questions. It's what you gotta do. And if it's going to be a meaningful hobby, it's gotta hold your attention. So, on those points I highly agree w/ the parent to this comment.

Ditto. Throwing my own 2 cents in:

I had some vague notions, and had even written some toy programs that implemented those notions. But otherwise I sorta jumped head first into writing my emulator, jzIntv. What made that even more exciting is that there wasn't much documentation out there, and basically only one person, Carl Mueller Jr., who had done any real reverse engineering work on it.

I built from his documentation and experiments using his emulator to produce my own. (His emulator was a closed-source, DOS-only implementation. Mine is open source and cross platform.) I think for me, the most interesting parts were in learning the system, reverse engineering it in the areas that were still quite grey, and documenting it for everyone. I also put together a development kit for the machine, because Carl's tools were, again, DOS-only and closed source.

It's been a hell of a trip, and I managed to learn a lot doing it. It's been my background project. As part of that, I've also written a couple of games, and am about to release probably my second largest non-work programming project, Space Patrol, pretty soon. (I consider jzIntv/SDK-1600 to be one very large project, although Space Patrol will get absorbed into that megaproject after it's released.)

Nobody taught me how to do any of that. I'm an EE by training. But, you pick up on things if you read and ask questions. It's what you gotta do. And if it's going to be a meaningful hobby, it's gotta hold your attention. So, on those points I highly agree w/ the parent to this comment.

Probably the most impressive stuff I've done has been in software:

• Wrote my own Intellivision emulator and development kit.
• Back in the day, did plenty of graphics hacks.
• Wrote a VT-100 PacMan clone. (Using the same VT-100 engine, I ported Doom to VT-100 also.)
• Wrote a falling tetrominoes game for the Intellivision, and I'm currently writing a new game for the same system.

In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:

• I designed and had fabricated a hardware pseudo-random number generator.
• Designed and built an ISA bus card that interfaced Intel and Motorola serial, parallel and timer chips to the PC, along with software drivers for accessing them from C.

(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)

Probably the most impressive stuff I've done has been in software:

• Wrote my own Intellivision emulator and development kit.
• Back in the day, did plenty of graphics hacks.
• Wrote a VT-100 PacMan clone. (Using the same VT-100 engine, I ported Doom to VT-100 also.)
• Wrote a falling tetrominoes game for the Intellivision, and I'm currently writing a new game for the same system.

In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:

• I designed and had fabricated a hardware pseudo-random number generator.
• Designed and built an ISA bus card that interfaced Intel and Motorola serial, parallel and timer chips to the PC, along with software drivers for accessing them from C.

(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)

Probably the most impressive stuff I've done has been in software:

• Wrote my own Intellivision emulator and development kit.
• Back in the day, did plenty of graphics hacks.
• Wrote a VT-100 PacMan clone. (Using the same VT-100 engine, I ported Doom to VT-100 also.)
• Wrote a falling tetrominoes game for the Intellivision, and I'm currently writing a new game for the same system.

In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:

• I designed and had fabricated a hardware pseudo-random number generator.
• Designed and built an ISA bus card that interfaced Intel and Motorola serial, parallel and timer chips to the PC, along with software drivers for accessing them from C.

(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)

Probably the most impressive stuff I've done has been in software:

• Wrote my own Intellivision emulator and development kit.
• Back in the day, did plenty of graphics hacks.
• Wrote a VT-100 PacMan clone. (Using the same VT-100 engine, I ported Doom to VT-100 also.)
• Wrote a falling tetrominoes game for the Intellivision, and I'm currently writing a new game for the same system.

In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:

• I designed and had fabricated a hardware pseudo-random number generator.
• Designed and built an ISA bus card that interfaced Intel and Motorola serial, parallel and timer chips to the PC, along with software drivers for accessing them from C.

(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)

Probably the most impressive stuff I've done has been in software:

• Wrote my own Intellivision emulator and development kit.
• Back in the day, did plenty of graphics hacks.
• Wrote a VT-100 PacMan clone. (Using the same VT-100 engine, I ported Doom to VT-100 also.)
• Wrote a falling tetrominoes game for the Intellivision, and I'm currently writing a new game for the same system.

In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:

• I designed and had fabricated a hardware pseudo-random number generator.
• Designed and built an ISA bus card that interfaced Intel and Motorola serial, parallel and timer chips to the PC, along with software drivers for accessing them from C.

(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)

Probably the most impressive stuff I've done has been in software:

• Wrote my own Intellivision emulator and development kit.
• Back in the day, did plenty of graphics hacks.
• Wrote a VT-100 PacMan clone. (Using the same VT-100 engine, I ported Doom to VT-100 also.)
• Wrote a falling tetrominoes game for the Intellivision, and I'm currently writing a new game for the same system.

In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:

• I designed and had fabricated a hardware pseudo-random number generator.
• Designed and built an ISA bus card that interfaced Intel and Motorola serial, parallel and timer chips to the PC, along with software drivers for accessing them from C.

(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)

Ok, explain how making a few minor tweaks, such as spacing menu items a little further apart and placing them in another font, as well as updating the scroll bars a little makes it less usable? In my opinion, it makes it less ugly. Compare: this Acme screenshot to a mockup I just made that I find significantly less ugly.

How have I ruined usability?

You remind me of the guy in Crazy People who came up with a slogan for Volvo: "Boxy, but good." What you're telling me goes a step further: "It can't be good unless it's boxy." The two are separable to some extent.

Believe what you will, but I'm not asking for "bling bling," and I think most modern UIs are too flashy. I can't stand OS X for extended periods of time (except over an ssh connection), and when I have to use WinXP, I set it to "classic." *sigh*

Is it too much to ask for the menus to be spaced a little further apart in a less jagged font, or even just confirmation that it can be done? Compare the original to a mockup I just made. Notice that the menus are in a more approachable font and spaced further apart. The scroll bars are also the more common type you find these days on the right, not the Athena/X11 style on the left.

Just because an interface is spartan doesn't mean it must eschew all the useful minor improvements UIs have made over the years. I know when my eyes are tired and bleary from a long day of hacking, I'll have a better chance of hitting the menu I want in the proposed version.

Incidentally, you can soon add the Intellivision catalog of games to the list of games that will run on the GP2X. I worked with a GP2X early adopter to get my Intellivision emulator jzIntv ported to the beast. The port actually went very quickly once we determined that the SDL port was crap and started mistrusting it at each step. Once we stopped trusting it and tested what actually worked, we quickly converged on a working, full-speed port.

Right now he's sorting out bindings for all the buttons. Once that's sorted, look for binaries at the link above.

OMG, this song isn't you is it? Drew Barrymore's Dealer: John Holmes, Jr.

Huh, weird. I still get 9440 hits for Joe Zbiciak. I still get as many even when I turn off the Personalized Search feature. And in the first 20 pages or so, there are very few hits for a "Joe" or a "Zbiciak" that isn't me.

LOAD? LOAD? Hardly! Try OLD "CS1:".

And, to send you back to the good old days, check out this track laid down over Pirate Adventure.

The TI-99/4A was the first computer I owned (got it for my 8th birthday, just as TI was pulling out of the market), but not the first I programmed. I had programmed many a PET, VIC-20 and Commodore 64 before that. The TI *was* the first machine I programmed assembly code on, using the Mini-Memory cart. Fun times!

--Joe

Ah yes, The Pinball Song, featuring the Pointer Sisters! (Link goes to a remix version with a remixed video as well.) If that link doesn't work, I've put a copy on my DSL. Don't hit me too hard, or I'll remove it.

Oh, and it didn't come from Sesame Street, apparently. It came from The Electric Company.

Back when I was still in college, I'd walk around the EE lab and hum a bar or two under my breath as I walked by someone. The target would often then start humming the tune and have it stuck in their head the rest of the day. Mission accomplished. :-)

--Joe

Besides, isn't it rather irrelevant? Ok, suppose editing the Makefile to get program X to build constitutes modification, and GPL v3 requires you to post your modifications. Big deal. You'd have a link on your website to the modified Makefile. How edifying. *snort*

I personally don't mind that GPL v2 allows companies and websites to take my GPL'd code, make proprietary modifications, and then deploy that code on their servers without sharing the modifications. In a sense, it's an awful lot like the First Sale doctrine, although that space is already confusing enough wrt. to software. The real point is, I offer my software to people to use and modify as they see fit. If they want to start distributing a modified version, though, they need to pony up the changes. That seems fair. If they just want to use it to run their site, I don't mind that GPL v2 doesn't require them to share the changes.

Incidentally, if you have GPL v2 Java applets, JavaScript, or other code that gets downloaded by your web browser, that is distribution in my opinion. But, then, "View Source..." lets you get at most of that. (Just not the Java applets.)

--Joe

One bright point is that most software packages will probably offer you a level of choice as to what restrictions get placed on GPL code. Recall this paragraph from GPL v2:

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

So, for instance, jzIntv, my Intellivision emulator, is offered under "either version 2 of the License, or (at your option) any later version." Unless GPL v3 offers my users something that GPL v2 doesn't, my users can decide not to subject themselves to GPL v3.

Now what isn't clear by that wording is if someone could fork this "GPL v2 or later" code and make it GPL v3 only without the copyright holder(s) (me, for most of it) giving permission. I think the answer's "yes." But that won't remove the GPL v2 code from the planet. And so just as you see some projects pick the proprietary-friendly BSD license over the GPL (since each has a different notion of freedom), I think you'll see GPL'd projects split along v2 / v3 lines as well. In my case, I may not even be able to publish code under GPL v3. My hands are "unclean." Looky here, my name is on 1, 2, 3, 4 software-related patents! I promise they are not as asinine as "one-click," and much narrower in scope.

Also, I'm one of the co-architects of several device security features that my employer will include on multiple upcoming chips. These features will be used by our customers to implement DRM! I didn't implement DRM myself. Rather, like the TPM chip, we provide an infrastructure that could be used for good or evil. But I did my best to make the infrastructure watertight. Sorry folks.

This doesn't surprise me at all. As an emulator author myself (jzIntv), I've worked closely with other emulator authors to reverse engineer and understand all the corners of my chosen system of interest.

I've worked with the authors of Bliss, IntvWin/IntvDos, Nostalgia, IntvPC, Kinty and the MESS Intellivision driver to work out emulation bugs and understand the various odd machine details. The authors of those emulators also have worked with each other--it's not like I'm some central focus here. It's a friendly community.

It'd surprise me more if the emu authors couldn't get past their egos to such an extent that they simply didn't talk to each other except to flame.

Microsoft's spider hit me awhile back, computing all sorts of amusing math on this old CGI I wrote waaaaaay back when I was in college. Damn spider transfered nearly 60MB of HTML out of that CGI before it got bored and moved on.

I ended up explicitly adding it to my robots.txt file.

Go get an Intellivision and play 4-Tris. ;-)

Many hacks, on their face, are pointless indulgences. However, that's true only on their face. After all, Linux was a pointless indulgence at one time.

My personal hobbies, such as twiddling with 80s video game equipment, are equally indulgent. They also, however, fill a creative need, and they hone my skills.

For instance, I wrote a super fast square root routine for the Intellivision. It's about 7x to 15x as fast as the built in routine, and it even does fixed-point square roots. Its run-time is very predictable and it handles the full range of unsigned 16-bit numbers--neither of which describe the built in code. I had no idea how to compute a square root before I wrote this routine, but I needed it for one of my (also unimportant) projects.

Is it really useful? Not directly, except to the handful of people that enjoy twiddling with Intellivision source code. (I'd guess that's no more than a dozen of us, and only maybe 2 or 3 people in that group might actually use this code.) But, I learned lots of neat tricks as I optimized the algorithm and wrote the assembly. Not only did I learn how to compute a square root, but also I learned how to optimize that implementation multiple ways. I even came up with some optimizations that went beyond the C code I found online. All this makes me a better programmer.

So is this a pointless indulgence? If you didn't enjoy yourself while you did it; if you didn't grow somehow as a person or as a hacker as you did it; if you didn't somehow benefit yourself, then yes. Otherwise, it was FAR from pointless.

There are precisely two places I'll comment every line, and it's for the same reason: Assembly code, and tricky high-level language code. Otherwise, I stick to the occasional one-liner if something's non-obvious, or blocks of "big picture" / "middle picture" comments.

Here's an example of how I code. It's not the most refined example, but it illustrates a range of tricky and non-tricky code. (This file actually could use some more per-line comments in the blitter.)

Here's an example of how I assembly code. I use a combination of block comments to say what the next block does, and line-by-line comments to give the blow-by-blow.

There are precisely two places I'll comment every line, and it's for the same reason: Assembly code, and tricky high-level language code. Otherwise, I stick to the occasional one-liner if something's non-obvious, or blocks of "big picture" / "middle picture" comments.

Here's an example of how I code. It's not the most refined example, but it illustrates a range of tricky and non-tricky code. (This file actually could use some more per-line comments in the blitter.)

Here's an example of how I assembly code. I use a combination of block comments to say what the next block does, and line-by-line comments to give the blow-by-blow.

Something more approachable might be to write a game on one of the old console systems -- anything from Atari and Intellivision up through about Sega Genesis and Super Nintendo shouldn't be too hard.

On most of those systems, you're still responsible for all the code on the system. Many of your comments about initializing timers, setting up the stack, etc. still apply.

The plus side is that the project can stay a pure software project -- no hardware design is necessary. Also, you can do much (all?) of your development using emulators. And, to top it off, most game systems have more interesting displays than just some LEDs. ;-)

That said, there is a certain satisfaction from building up a system from chips, writing code for it, and saying "I built that!"

Actually, I have explained much of the details of how to make the cart. All of the technical information required to design an Intellivision cartridge is on my website. Certain specifics of the cart I sold I've kept to myself.

FWIW, I have released the ROM image and source code to the game.

This is currently a link to the full version of this comment, which has a screenshot image in it. The HTML body follows.

The below screen shot of DOOM for Intellivision is accompanied by some funky digital noise which I have no idea how to capture and put here from one of these emulators without installing additional software. I've installed three versions of it already. One of the emulators has an AVI capture mode on it, maybe I should try doing that. The PNG is here also so you can make a comparison, size or otherwise, in the wake of the recent discussions about GIF and PNG. I generated the screen shot below with Nostalgia, a neat Intellivision emulator. I'm sorry about the dodgy quality, but I hit alt-printscreen a little too late, and I'd already spent too much time on this. It's not like it's really playable at these speeds.

To hear the music and see the sights yourself, download doom.rom, doom.cfg or doom.bin for the various emulators you might download. (Get them from here, original source, )

I apologize for the blocky formatting of the HTML, but I am too lazy to remove it.

This is currently a link to the full version of this comment, which has a screenshot image in it. The HTML body follows.

The below screen shot of DOOM for Intellivision is accompanied by some funky digital noise which I have no idea how to capture and put here from one of these emulators without installing additional software. I've installed three versions of it already. One of the emulators has an AVI capture mode on it, maybe I should try doing that. The PNG is here also so you can make a comparison, size or otherwise, in the wake of the recent discussions about GIF and PNG. I generated the screen shot below with Nostalgia, a neat Intellivision emulator. I'm sorry about the dodgy quality, but I hit alt-printscreen a little too late, and I'd already spent too much time on this. It's not like it's really playable at these speeds.

To hear the music and see the sights yourself, download doom.rom, doom.cfg or doom.bin for the various emulators you might download. (Get them from here, original source, )

I apologize for the blocky formatting of the HTML, but I am too lazy to remove it.

This is currently a link to the full version of this comment, which has a screenshot image in it. The HTML body follows.

The below screen shot of DOOM for Intellivision is accompanied by some funky digital noise which I have no idea how to capture and put here from one of these emulators without installing additional software. I've installed three versions of it already. One of the emulators has an AVI capture mode on it, maybe I should try doing that. The PNG is here also so you can make a comparison, size or otherwise, in the wake of the recent discussions about GIF and PNG. I generated the screen shot below with Nostalgia, a neat Intellivision emulator. I'm sorry about the dodgy quality, but I hit alt-printscreen a little too late, and I'd already spent too much time on this. It's not like it's really playable at these speeds.

To hear the music and see the sights yourself, download doom.rom, doom.cfg or doom.bin for the various emulators you might download. (Get them from here, original source, )

I apologize for the blocky formatting of the HTML, but I am too lazy to remove it.

The 'free.fr' site's pretty bad, but the mirror sitting on my Linux box seems to be holding up just fine. So come slashdot me!

5:58pm up 344 days, 20:05, 4 users, load average: 0.00, 0.00, 0.00

why yes, yes it can.

http://spatula-city.org/~im14u2c/intv/doom/

You've got to be kidding. I didn't know Intellevision could run DOOM.

Will Grandma ever stop calling my Game Cube "Nintellevision?"

http://intyos.spatula-city.org/

About your sig: Actually, I currently write games on a machine with about 1.5K of memory and an 895kHz CPU. And I am grateful.

Those were the days when programming was really fun, man! I remember being really excited when the PalmPilot came out, cuz it sounded like a good opportunity to get back to programming the way folks were meant to do it.
Who's with me??

I'm with you! I currently write stuff for the old Intellivision video game system. This thing runs at about .89 MHz, with the average instruction being around 8 cycles. It's a .1 MIPS machine, although it is 16-bit. It very little RAM (around 448 bytes for variables, 2048 bytes for graphics, 240 bytes for display memory). The machine is still sufficient for games, though, because it has hardware sprites and a 3-voice square-wave/noise generator for sound.

In comparison, the Apple // was approximately .25 MIPS, I believe. (1.023 MHz, average instruction around 4 cycles.) It had a lot more memory, but vastly inferior sound. At least it had a bitmapped graphics mode though! :-)

Shameless plug: You can find my Intellivision development kit here.

If you still need a decent integer square root algo, check out this page. I used the mborg_isqrt2 variant on that page as a starting point for writing my highly optimized Intellivision version for SDK-1600. My optimized version takes about 600 - 700 cycles for a 16-bit square root, on a machine where most operations take 6 to 8 cycles. (The version I was replacing took 4000 - 10000 cycles.)

This book looks like it might be interesting to me. Here at work, we had our own math expert, but he's retired (or semi-retired). We've contracted with him to do math libraries, and that works for now. But what about 10 years from now? There's a lot of subtlety in some of these algorithms (it's not always just as easy as whipping through a Taylor series expansion), so it's probably time someone in our group started learning. :-)

If you still need a decent integer square root algo, check out this page. I used the mborg_isqrt2 variant on that page as a starting point for writing my highly optimized Intellivision version for SDK-1600. My optimized version takes about 600 - 700 cycles for a 16-bit square root, on a machine where most operations take 6 to 8 cycles. (The version I was replacing took 4000 - 10000 cycles.)

This book looks like it might be interesting to me. Here at work, we had our own math expert, but he's retired (or semi-retired). We've contracted with him to do math libraries, and that works for now. But what about 10 years from now? There's a lot of subtlety in some of these algorithms (it's not always just as easy as whipping through a Taylor series expansion), so it's probably time someone in our group started learning. :-)

I used to plant this QBASIC program in the labs at school and other unsuspecting machines. It fairly reasonably emulates a good ol' car alarm, and it manages to lock out Ctrl-Alt-Del.

This was even more fun, because the school had just bought a lab full of machines that had no reset button, and had a dual-stage power off (you had to hit a button on the side, and then the button on the front). Strange AT&T Pentium-60 machines.