DZ-Jay

You are right, that's my mistake. I meant to say that you "half it" not "double it." You double the Kilo-Word size to get the Kilo-Byte size. Sorry about that. -dZ.

Hehehe, yeah that's true. We shall see how it comes out and how it is received. I think it'll be good. -dZ.

The title is a joke throwing back to my Slashdot days, where trolls would jump over each other to be the first one to post, usually with a typo on the heading. Yeah, procrastination is not fun. On the other hand, I am one of the most productive and workaholic persons I know, specifically because I tend to do all sorts of things -- including actual work -- in an effort to avoid precisely the one thing I need to do at that moment. -dZ.

Never had a blog before, and probably never will again, but I thought it may be useful to type short entries of what I'm working on as a blog rather than abusing the "Status Update" feature. I intend to write brief updates on the progress of my projects -- both retro-game-related and not. I don't expect anybody to read this, so this blog is mostly for me: talking to myself keeps me sane, and helps me focus. I know that sounds sort of stupid, but it works for me. First of all I should state upfront that I am a world-class procrastinator. Seriously, it's like my super-power. I present this blog as the purest form of evidence to that statement: I have just created a brand new blog, and I am writing this post right at this very moment, in a subliminal attempt to avoid working on my projects. That's how I get things done. I always wanted to write a blog, but never got around to it. There's absolutely no better motivation for a procrastinator than starting up another project and giving it more importance -- then suddenly, boom! I have a blog. Yes, it's weird and more than a bit silly, but it works. The trick is to be stupid enough to fall for your own deception. (Ab)using this technique (which apparently is called "structured procrastination," look it up) has led me to complete many of my accomplishments, which aren't really many. I did learn Assembly Language and made an Intellivision game, so there's that. Anyway, the reason I mentioned my super-powers of procrastination is two-fold: First, because it's true. It feels right and cathartic to say it. Second, as a warning to anybody crazy enough to follow this blog: don't expect many entries. It only takes a slight elevation in priority for this blog to be utterly abandoned. Such is the procrastinator's way. So... what am I working on right now? Well, I have currently five active projects going, in various stages of development. I intend to post entries on any of them as I make progress (or not, as per the previous paragraph, don't count on it). P-Machinery 2.0 Advanced Game Engine (P-MAGE) - A comprehensive and optimized game engine and development framework for Intellivision games, built up from scratch to be fast, efficient, and easy to use. It's about 80% done (it's always about 80%, and has been for the past five years), and hopefully will see a release next year. <REDACTED> - My next Intellivision game, which I will keep unnamed for the time being. It's actually just in the technical design stage at the moment, waiting for P-Machinery AGE to reach 85% maturity so that I can start coding it simultaneously. The story and game-play mechanics are all defined and documented, and it plays really well in my head. CvW 2014 Special Edition - Yes, it's been several years, but I have yet to deliver the custom-made Christmas Carol Special Edition to the winner of the 2014 CvW championship. The good news is that the game is complete and thoroughly tested by myself and a secret beta-tester elf who will remain anonymous. I am just waiting on manufacturing to deliver it on cartridge. Many problems in my life during the past few years conspired to delay this project gravely. It will happen this year, that's my promise. CvW 2015 Arcade Marquee - Another casualty of the same family and personal problems that affected the previous project. The actual custom marquee is finally completed and in my hands. I am now waiting for my carpenter to finish building the light-box to mount it on. The design was made by a graphic artist and it is fabulous! I can't wait for the owner to receive it. Christmas Carol Children's Book - The Christmas Carol game for Intellivision came to life through a very strange and convoluted set of circumstances. One other consequence of those strange circumstances was that its story formulated in my head as a whimsical world of Christmas adventures. Although hard to pick apart from 8-bit animated graphics, the cut-scenes and most of the level progression in the game -- all the way to the boss level and saving Christmas -- attempted to depict a story arc that had popped into my head as I was developing the game. I always intended to write it all down as a children's book, but never got around to, until now. So that's it for this first post, so much for brief entries. Phew! I do feel better now. Well, that's enough distraction for now; I should go back to work on one of those projects. See ya'! -dZ.

Haha! That's funny! But seriously, that's how I do my artwork too, pixel by pixel. https://player.vimeo.com/video/54165189

Nah, it's a dud (in our area at least). Be careful what you guys wish for -- your prayers are also keeping me safe...

No problem, we're here to help. Just a bit of trivia: The Intellivision has a 16-bit CPU and the console hardware has been designed to support 8, 10, and 16 bit memory. 8-bit and 16-bit, I'm sure you know; but 10-bit was because at the time, memory was so expensive that 10-bit chips were more accessible than 16-bit ones. Besides, General Instruments (the CP-1610 CPU manufacturer) happened to be one of the biggest manufacturers of 10-bit memory chips. When the Intellivision came out, all Mattel cartridge ROMs were 10-bits, while internally the machine used a combination of 10-bit ROM for the EXEC and GROM, and 8-bit and 16-bit RAM for scratch and system memory. Due to the 10-bit width of the ROM addresses, the programmers affectionally called the data word a "Decle". This stuck all the way to this day, and we still call the data word a "Decle" even though we use 16-bit wide ROM today. Because of the above, and contrary to many other contemporary and modern platforms, the Intellivision programming community (going all the way back to the Mattel Blue Sky Rangers) measure the size of programs in "Decles" (which originally were 10-bit wide but now are 16-bits). This gave the indication of how much ROM space a cartridge needed, since that was the word-size of the machine. So, when we say "8K" (without the "B" following it) in the Intellivision world, people mean "8 Kilo Decles" which translates to 1,024 x 16-bit words. File sizes are still reported by modern PCs in "KB" (Kilo Bytes), so you just need to be aware of that distinction. If you are assembling the game from source, the output of the assembler will give you this information. If you are trying to assess the size from a binary file, then yes, the best way is to read the memory map values in the CFG file, or take the ROM file size (in KB) and half it (to KW). That seems like a good assumption to make. If we accept that a "rom" or "bin" file is a binary image of the program in cartridge ROM, then it takes the same amount of space it would require to store in the cartridge, and since 8-bit Kilo Bytes are half the size as 16-bit Decles, then it works. Just make sure to start with the actual size of the file and not its allocated space on disk, which is block-aligned and may be larger. I am assuming that this is because you are trying to make use of the Party Line menu which was already created back in its day. If so, then the best way is to disassemble the ROM or to follow it's execution in the debugger. Just be aware that the code may be a bit obfuscated due to optimizations. If you were building your own menu and the games were built to fit within a single page, then you can use whichever page your want, as long as it is valid, and it doesn't interfere with any other memory address space reserved by the console. (Remember, the ROM address space on the Intellivision is broken up into non-contiguous segment, and "pages" are essentially segments if addresses starting at higher bases.) -dZ.

Looks good!

Well, Mattel's point is that if you were looking to purchase the console with the largest number of games available, then the Intellivision would be better over the Atari, since you could play both sets of games on it. It's a marketing feature, not a legal deposition. They never claimed that all games were from Mattel, in the same way that nobody claimed that Activision or Imagic games were from Mattel, yet they were available for the Intellivision. So, you bought an adapter for your Intellivision, and automatically expanded your pool of available games significantly. Whether they were "native" or not it doesn't matter: you plugged them into your Intellivision and they worked, just like Intellivoice or ECS games. You weren't supposed to be aware that you just bought an Atari VCS when you purchased your System Changer. -dZ.

It's that weird burping noise it makes when you start the game. It's supposed to be "Yer out!" -dZ.

You should take the memory addresses from the original CFG files of each game. That range should tell you the game size and should inform which segments to use for bank-switching. In that last comment, yes. The 16K file size represents an 8K (words, not bytes) ROM size, in Intellivision parlance. -dZ.

Tell him, that's how card shuffling sounds in Las Vegas.

I guess I don't understand your ultimate goal. Your other post suggested that you were only doing the page ROM thing in order to learn Assembly Language and the tools, presumably for the purpose of programming games. Now it seems that you were looking to learn the tools and Assembly for the purpose of stitching the Party Line ROMs together. So here's my suggestion: If you want to stitch together the ROMs , then yeah we can help you figure that out. If you wish to figure out the Party Line (or any Mattel) games to perhaps hack them and modify them, or just for curiosity's sake, then we can help you with that also, but you will need to learn about the EXEC, the disassembler, provide a symbol table for EXEC entry points and variables (I believe I have one handy from a similar project), and maybe learn a bit of assembly language. If you want to learn how to make Intellivision home-brewed games, then forget all of the above because they wont help, and either pick up IntyBASIC (compiled BASIC) or the SDK-1600 (assembly). Home-brewed games do not use any of the EXEC stuff and access the hardware directly. Either way, we're here to help. dZ.

Well, I was going by the actual problem that The Master is trying to address: I was trying to help that goal rather than helping him get lost in the weeds. If he really wants to reverse-engineer the Party Line games, then yeah, he'll have to get some information on the EXEC. dZ.

Great! More time to procrastinate. Sheesh! You're not helping!

The disassembler is not perfect. In my experience, it confuses some data with code, throwing your research off into the weeds. Also, it has no knowledge of the EXEC's symbol table, so unless you can produce one, it will just give you useless labels or absolute addresses. Overall, disassembling a Mattel game and reverse-engineering its source, for the purpose of learning Assembly Language, is to me at least, the wrong approach. If someone went to a mechanic and said, "I know nothing about cars but I want to learn to fix them, so could you please tell me where I could find an engineering schematic from Ford or GM?" I would expect the mechanic to respond with "forget that, if you want to learn to fix cars, then take this course or read this book," rather than just letting the guy shoot himself in the foot without guidance on how to actually do the task he wanted. -dZ.

As someone who grew up with both, I wouldn't go that far. Them's fight'n werds!

The "Go For The Gold" title was actually built after the fact. That is, the games it included already existed, were tested and debugged, and were already out in production on their own. Basically, they wanted to package them together with minimal effort. From what I can see in the Blue Sky Rangers' web site, it seems the "Party Line" games were also envisioned (and developed) as stand-alone games to be released in a six-cartridge series, but were then later made candidates for Mattel's new "album cartridge" concept. That suggests to me that they were bundled together in much the same way as the "Go For The Gold" games. If they are all 4K games, they would all fit within the same ROM "segment." A similar technique to what intvnut mentioned above should work: Concatenate the binaries into one larger one Prepare a CFG file declaring the base ROM address and page of each game (in the same order you concatenated them) Post your work here and others may be able to assist. Most of us that came here with a programming background never touched Assembly Language before, so you are not alone. Personally, I do not think that reverse-engineering old Mattel games is the best and easiest introduction into that realm. If that's really what you want, there are tutorials and small sample programs included in the "SDK-1600" distribution to guide you -- and of course, there's always posting in this forum to ask your questions. As someone that came to this community in much the same way as you, I would recommend starting directly with making your own game, preferably one with which you are already very familiar, like an old arcade game or even something simple like Pong. Just pick your poison and get to work. The idea is that with an existing and valid game concept, you just need to focus on how to implement it in Assembly Language -- and that's where the tutorials and the sample programs and the community assistance comes in. As your skills mature and you find your way, you'll probably either evolve your game (if you really, really wanted to make it), or discard it and start from scratch with a proper project. In any case, getting started is the hardest part, but never be afraid of starting with a real project just because you may throw it away eventually. That's all part of the process. The problem with reverse-engineering a game is that... well, that's a separate skill in itself, and it sort of presupposes an already working knowledge of Assembly Language. There is no source code for those old Mattel games, so you'll have to disassemble them, which means that you won't see what the programmer saw -- you won't see macros and formulas and subroutines and logic functions; no symbols or variable names or any comprehensive structure; you will only see the final operations, instructions, and data that the machine sees after assemblage. It's absurdly hard, especially when you consider the talent and experience that Mattel programmers applied to their programs in order to make them fit into their modest cartridge ROM in whichever ways they could. Besides, old Mattel games used the EXEC (the built-in "operating system" and programming framework of the Intellivision), which is something not readily documented any more, plus home-brew games completely skip it, so no effort is typically put in understanding it. Starting from scratch is almost always easier than that, and eliminates an entire layer of incidental complexity from the task: that of "software-archeology" in reconstructing the intent of the programmer from arcane and often obfuscated machine code. Although your mileage may vary, as they say. Then, of course, there's the IntyBASIC SDK. Why not give that a try first? -dZ.

I don't understand how that "randomization" routine works. The way we do random numbers in other platforms is by using Linear-Feedback Shift Register (LFRS), which is just a register that shifts its value by a number of bits, and in doing so applies a function (typically a simple XOR) on itself. Thus, every new state is wholly determined by its previous state, but depending on the initial seed value, the sequence is pseudo-random. The initial seed is typically a polynomial. I guess that if you have access to write it in machine code, you could get away with something serviceable that only takes a few bytes of code. In interpreted BASIC it may be too slow. Here's a sample implementation. Another alternative -- and indeed, the one implemented in the game Doom -- is to run your pseudo-random number generator outside your program with a good seed, creating a pseudo-random sequence of numbers, and store that as an array of data in your program. Then, your program only has to read the next value in the array. Your game will be utterly deterministic, but by doing something like you had above to select a "random" entry point into the array, you could add a bit of entropy. And if all you need is one random number, then that's even easier. just follow the advice in here. -dZ.

That's the best way! -dZ.