Carl Mueller Jr

Hi all, My website has moved to the following address: http://carlmuellerjr.blogspot.com As before, it contains the steps you need to take to order any of the above game ROMs listed in the title. There is also detailed information about what is included. Thanks, Carl

Just follow the directions on my Blogger page. Basically, send payment to cmjrd2k@gmail.com, and send a note to carljr17@hotmail.com to let me know you've made payment in which ROM you wanted (you may also be required to send the first five digits of your DRUID, if it's an LTO Flash! ROM). That's it. Rest assured that you will get your ROM, I've had no dissatisfied customers. Thanks, Carl

I'm very sorry for all the trouble. I have not received any mail from you. Why not send me the details through Atariage, and I'll get back to you with the ROM?

It's my birthday, somebody please buy a ROM. :-) Carl

I am pleased to announce that D2K Special Edition ARCADE ROM is now available for LTO Flash!. Check out my blogger page for more information: Http://www.carlmuellerjr.com Note that this ROM will not work under emulation, it specifically for the LTO Flash!. This is the only kind of ROM that will ever be offered for the special edition, so please don't ask for exceptions. Thanks a lot, Carl

Hey everyone, Just letting you know that the D2K ARCADE ROM is now only $10, and will remain that way in perpetuity. Also note that D1K and Ms. Pac-Man are no longer free downloads. If you have them, please continue to use them for your own personal use, but please do not distribute them in any form (including source code). I'd like this stuff to be free, but $10 is a pretty big deal to me these days, and I find people are just not willing to make the donation without a little… encouragement. Thanks, Carl http://www.carlmuellerjr.com

Hi all. I turned 45 in December. Living with disease since age 17. I did the first Intellivision and early homebrewing stuff in my early 20s (early 90s). Time really flies :-(

I don't want to state (or restate) the obvious, but I really believe the EXEC was really instrumental in the early success of the Intellivision. With the initial 4K cartridge restriction, and without code for interfacing with the hardware, a macro language for sound effects, impression routines for graphics, collision routines that dispatch only on collisions the game is interested in, etc. etc., there is no way they could have been as sophisticated as they were. I would go as far as to say they could not have offered anything much more advanced than a typical Atari VCS game at the time, and considering the heftier price tag of the Intellivision, it would have been a dealbreaker. Intellivision may not have test marketed successfully, and we probably would not even be talking about it today if it wasn't for David Rolfe's brilliant idea, design, and execution. I suspect the Pretty Dumb Idea was perhaps a smaller ROM size and/or a more conventional approach (routines that cartridges simply called to, rather than the EXEC being the main program that dispatched to cartridge programs). I think it's utterly brilliant that cartridges essentially contain tightly compacted data tables that describe things such as which object collisions it's interested in, where graphics tables are located, etc. and need only include routines for custom behavior, allowing cartridges to be even trimmer, the extra space allowing them to be even more sophisticated, include more animation, etc. The EXEC may be criticized for updating objects at 20 Hz and splitting up tasks, but it did have to fit in 4K. There would not have been space to unroll code to update GRAM, and the 10-bit ROM restriction also meant no packing (allowing for the "SWAP" trick to buy even more cycles). And obviously, it also had to be programmed to be more generally useful.

As long as you're still taking ideas, this would be my personal ideal for an add-on module that expanded the stock capabilities of the Intellivision: - ECS support (8-bit RAM, second PSG, two controller ports) - Intellivoice support - Tutorvision support (3 additional pages of GRAM) (should also actually be compatible with Tutorvision cartridges, which we will no doubt see reproductions of soon). - Clean composite and S video-out (may only be possible with Intellivision II or modified a model 1) Not only would this be 100% Intellivision (and no one could argue that), but the additional three pages of GRAM would add significant capability to the Intellivision, including a bitmapped display. You could also do things like preloading sprite animations in GRAM, freeing up precious VBLANK cycles, making things like true software sprites far more practical (in a way, breaking the 8 sprite limit). Also simplifies programming large scrolling backgrounds, so you don't have to worry about reloading GRAM for different areas of the map. I can see RPGs, text and graphical adventures, driving games, vector games, first-person perspective games, etc. etc. being particularly stunning under this configuration. It also has the advantage that developers need not modify their development systems (or very little), emulators would only require slight tweaks for the additional GRAM pages, and having a single all-in-one add-on unit would be pretty slick, particularly if there was cases for both the Intellivision I and II. Heck, even I buy one of these things and I don't even own an Intellivision at the moment. Carl

I don't think it's beside the point when you're trying to assess how a game's collision detection is handled and you incorrectly report that it's flakiness is due to the EXEC, an operating system that it does not actually use. And actually, there are hardware flaws in the Intellivision. For example, moving object #1 will not collide with the screen border.

I was only referring to how they were referenced in Intellivision programming circles, there is no evidence to support that they were ever called MOBs at APH, Mattel, or any place else that developed Intellivision software.

Microsurgeon does not use the EXEC except to read the hand controls. Even if it did, collision detection isn't a problem with the EXEC because the hardware will record all collisions and set latches so that interactions, even if they occurred a few frames before will not be missed. If the object has changed its internal ROM database pointer between the time the hardware recorded the interaction and the time the EXEC gets around to dispatching, you will miss the collision however. I don't know what's going on with Microsurgeon, but I've known since I was a kid that it was very particular with where you shot the background. Anyway, it's definitely not the hardware.

By the way, as far as I know the Intellivision was the first game console to actually support smooth scrolling. Even the Colecovision, which came out more than two years after the Intellivision, lacked smooth scrolling in hardware.

Space Armada does not really use software sprites. The game does sequence background pictures for animation, but it does not actually shift their patterns to give the illusion of movement. Instead, the screen scrolls and the background patterns remain fixed, only to change when animations occur. The shields, weapons fire, and ship are all moving objects, so their positions are modified to hide that the screen is scrolling. (Normally, moving objects move with the background.) It might be fun to make a list of games that do use true software sprites. Right now I can only think of Wormwhompper and He-Man. Ms. Pac-Man originally used software sprites for the ghosts' eyes, but it was eventually removed because it slowed down the game too much. The code however remains, and can be viewed in the source code. Carl