DZ-Jay

Here are a few more sketch-to-artwork examples. The Snowman searching for Carol ... Turned into this ... And the Bad Toy original sketch ... Became this nice shiny toy: The book has quite a few such illustrations depicting some of the coolest parts of the book -- which happen to be inspired by some of the coolest cut-scenes in the game. -dZ.

Well, in reality, I learned that I was handy with the Pixelmator. The actual hand-drawn sketch looks like this: I then took a photo (the one above), traced it in Pixelmator with the "pen" tool, and shaded it by hand, in layers, digitally. It still took me like 30 to 40 hours to complete each illustration. I may be good at digital art, but I suck at time management. I am very, very slow. -dZ.

A similar translation happened with the title screen. First, I thought of a nice Christmas morning scene, so I drew this sketch: Which turned into this title screen: Which eventually evolved into the final one: But all the time, in my head I saw this: Honest-to-goodness, I always intended the Ghost to poke his head and peek from behind the presents. I just ran out of time. I also couldn't fit the fireplace in. The other fantastically surprising thing is that ... I drew the book cover and all its pictures myself. Who knew I could draw! (Spoiler Alert: I didn't.) Had I known I could do that, I wouldn't have spent several hundred dollars (and much consternation) in hiring someone to do the box art! Live and learn. Another lesson taken from the Carol experience. -dZ.

The Characters: Meet the main characters starring in Christmas Carol vs. The Ghost Of Christmas Presents. Some are naughty, some are nice, but they all have an important part to play in the story. Their likeness was inspired by the characters in the video game. That's right, those 8x8-pixel blobs actually looked like these in my head. I have a big head, it fits a lot of stuff. -dZ.

Hello there! Unfortunately, there is currently no option for PayPal. I have set up a business account with Square, which is used by many small retailers (you may have seen it at your local stores as well, where they scan your card into an iPhone and such). Rather than just a micro-payment to me, it's an entire retail merchant solution. It offers an absolutely secure method of payment and supports credit cards, Apple Pay, and Google Wallet as well. I hope this is acceptable to you and others, but if not, please contact me via PM and we can work something out. :) -dZ.

It's a long journey -- but don't worry, Santa Claus gave you an old map. 👍

By the way, regarding shipping ... There is flat rate shipping via Media Mail across the entire USA, along with additional options for Priority and Express Mail. There is also Priority International Mail options for Canada, Europe, and the rest of the world. All books are packaged carefully in sturdy, heavy-duty cardboard mailers. No bubbleopes or cheap-o wrappers here! That said, I set up the shipping zones by hand and tried my best to offer reasonable and inexpensive options for everyone, but I admit I may have made a mistake or omission. I bring this up because I received feedback from a visitor to the web site pointing out that his options included a ridiculously expensive shipping rate for Iowa, which is definitely a mistake, but not obvious to the visitor. They were clearly not happy, which made me sad. So I will ask to anybody interested in a copy, if you find that the shipping charge is too high, or if you were looking to order multiple copies, to please reach out to me directly (via PM, e-mail, or web site feedback post) so that we can discuss reasonable options. Orders are fulfilled directly by the CvG Books Publishing staff (i.e., Mr. & Mrs. DZ-Jay), and they're very reasonable people. -dZ.

Wow! I see that @Rev let the cat out of the bag. To be honest, I really wasn't sure if I should plug the book in AtariAge, precisely because it is not exactly Intellivision related ... although it kinda is, in a sorta kinda roundabout way. A little history on the project: As many of you may have heard in my Intellivisionaries Podcast interview (from way back when), the little cut-scenes and the character interactions of the game came from a few vignettes I created in my mind of Carol's adventure as I wrote the game. As the story evolved more and more in my head, the game became richer with a bit of a story arc, depicted in those cut-scenes. By the end, I had not only Carol's motivation to save Christmas, but an entire mythology of who she is (she's Santa's elite Elf Ranger), what she does (she searches around the world to ensure that all children are in Santa's list), where she goes (the Ice-Cube Caverns and nestled deeply in the Himalayan mountains), and who her enemies are (the Evil Snowman continually tries to ruin Christmas, and the Ghost likes to haunt during Halloween for candy). All this was in my head, and I always intended to put it to paper but ... you know ... as always, life has a tendency to get in the way. Eventually, as my granddaughters turned from drooling blobs into pretty little princesses, I was motivated to write it all down and share it with them. The result is this book: The fantastic, epic story of Carol Greenleaf as she explores the Ice-Cube caverns in search of the missing presents, and confronts her foes to ensure that Christmas morning comes to everyone, in all its glorious splendor. I wrote the book and drew all illustrations by hand, with the assistance of a few friendly elves (some of them in their professional capacities) who reviewed, edited, and provided feedback. If you enjoyed the game, you'll like the story. All your favorite moments are there -- those silly little cut-scenes come alive as part of the ongoing adventure that Carol experiences. Even the caverns in the game make their appearance as the backdrop of the story, and are described in exquisite detail as Carol explores them (plus there's a map!!!). It all leads to the epic confrontation inside the Krystal Keep fortress and a satisfying conclusion. (Spoiler alert: If you played the game to the end, you know how the story concludes ;)) Anyway, if anybody has any questions about the book or how to order, do not hesitate to contact me. -dZ.

By the way, I've edited my previous comments and fixed up the tables a little, for clarity. -dZ.

It's my pleasure. When I started programming for the Intellivision, I was in a similar situation: I had a computer science and engineering background, but haven't really not done much in several years. When I joined the community, there was no IntyBASIC, so programming for the Intellivision was all done in Assembly Language -- I was utterly lost! I basically started from scratch, and it was the fine folks in this forum and in the old IntvProg mailing list that provided a lot of insight and assistance to get me to where I am today. Like you, I am not satisfied with merely "getting it to work"; I must understand how something works as well in order to assimilate it and build upon it as a foundation. I am just paying it forward, and glad that I have the opportunity to share my experience and knowledge with others. Good luck, and do not hesitate to ask anything else. If I'm not around, I'm sure others will chime in. -dZ.

It just occurred to me that my response relies on some core details about the console and the hand-controller which may not be completely clear to you. So, let us get down to basics. The Intellivision hand-controllers have the following control surfaces: 12 key keypad (0-9, Enter, clear) 16-direction disc 3 action buttons (physically four, but two of them are hard-wired to the same lines, making them act as one) That's a total of 31 individual control surfaces, each one requiring a unique signal in order for the program to distinguish them. In an ideal situation, each control surface would have a dedicated line to uniquely identify its input unambiguously. In such an ideal scenario, there is no real need for any fancy decoding function: if the signal for, say, action button #3 is pressed, you know exactly what it is and where it came from, and can handle it without issues. However, due to technical considerations, costs, and other factors, the Intellivision hand-controllers have only 8 wires on which to send signals to the I/O chip (which, by the way, takes the role as the sound chip as well). So, if we do the math, that's 31 individual signals to be sent across 8 wires, and somehow they need to be uniquely distinguished by the program in order for them to be useful. So the hardware engineers came up with a neat solution: they assigned each of the 31 control signal a unique combination of those 8 wires. Because those 8 wires eventually feed into a digital circuit, they are turned into an 8-bit byte. Thus, you could consider each one of those 31 signals a unique 8-bit binary code. Nonetheless, they are still 31 signals all using the same 8 bits, and so there is obviously some overlap between them. The good news is that the original hardware engineers thought of all that, and chose wire combinations that not only were unique to each control signal, but that each had a unique set of bits that were used for itself. That means that you could easily tell the difference between, say, a keypad key and a disc press, because there is at least one bit that only one of them uses. Therefore, the presence of that bit or bits guarantees (to some degree) that the signal is one or the other. Notwithstanding, the fact that there are 31 distinct codes spread around those 8 bits forces us to be a bit more creative in our input handling, and requires us to decode the input signal into a usable value. The code above exploits the fact that some combination of bits apply only to one input or another, and uses this to detect the disc vs. the action buttons vs. the keypad. That's what the "AND $E0" and "AND $1F" expressions do: they mask one set of bits to check whether they are set or not, and from this it can be gleaned which type of signal it is. If you do not know what "bit masking" is or how it works, or need a refresher on your Boolean logic, no worries! Just check out this post I made some years ago on the subject for some guidance. So that's what those expressions do. Now, because the input signal is 8-bits long, that means that there are in theory 256 unique values that the controller could provide. In practice, as we already established, there are only 31; but they are not neatly packed -- they are actually spread out throughout all those 8 bits in order to guarantee their uniqueness. Still, 256 values means that we could easily build a lookup table with every single possible value and just use whatever the controller gives us as an index into the table. That would work, of course. However, I hope you can appreciate how exceedingly inefficient it would be if every time there is a new signal we go and search through 256 possible entries, comparing each one, to see which one we have. On a resource-constrained machine running a fast-paced gain, this can be horrendously slow. This is why we do that special masking and try to figure out which are the unique set of bits that apply to one control type versus the other: because if we narrow it down to, say, a disc input, or a keypad input, our search space becomes a lot smaller. Let me know if any of this is not clear, or if you have any other questions. -dZ.

Not a problem, it is my pleasure. I may have made some assumptions as to your level of understanding when I wrote my response, and I am sorry for that. So if anything at all is not clear, please feel free to ask, and I'll do my best to provide a more suitable answer. :) -dZ.

To your questions: What does (c AND $E0) do? It masks the action-button bits (the upper 3 bits of the 8-bit signal returned from CONT) discarding the bits applicable to the keypad and disc. Does the '+' treat this as OR? The Intellivision CPU has no native OR operation, so implementing one is expensive. However, because OR results in a "True" value when any of the arguments is "True"; then adding numeric values would serve as a reasonable substitute. Think about it: if all values are zero (False), then the result is zero (False); but if any of them is different from zero, then the result is going to be not-zero (True). The specific combination of values being "ORed" here are those that overlap with the keypad, so the line is testing to see if the signal represents a keypad press. I don't get how this returns 2 from controller direction table? The expression (c AND $1F) masks the lower 5 bits of the signal returned by CONT ($1F being the 1's complement of $E0). This value is then used as an index into the data table "controller_direction." Essentially, the 5-bit signal codes for each direction are sorted in the table, and for each of the valid values, a corresponding direction is assigned. Consider that the signals are a type of "gray code" -- that is, a set of "on bits" that uniquely identify a particular signal, but which are highly unlikely to occur accidentally by mechanical artefacts, noise, and other extraneous factors. Thus, it is just a bunch of on-and-off bits which perhaps may seem even random. Because the disc codes fit within only 5-bits, we can build a table of 32 values (2^5), each entry representing one of those codes. Note that not all codes will be valid (remember, only 16 signals are used for the disc, yet there are 32 possible ones). Thus, you will see that those entries will yield a zero. A zero is also returned for valid disc directions that do not fit within the four cardinal points (i.e., the so-called perfect diagonals). For reference, the disc signal codes are listed below, taken from the documentation included with P-Machinery. In reality, you don't have to worry about those magic values at all, for they are abstracted in the "constants.bas" file included with the IntyBASIC SDK. The values below are sorted by the disc input as we recognize it: a value from 0 to 15 indicating the direction that was pressed; starting from the tippity-top of the disc and going clockwise: Disc: ------- ------- -------- Input Code Signal ------- ------- -------- 0 0x04 00000100 1 0x14 00010100 2 0x16 00010110 3 0x06 00000110 4 0x02 00000010 5 0x12 00010010 6 0x13 00010011 7 0x03 00000011 8 0x01 00000001 9 0x11 00010001 10 0x19 00011001 11 0x09 00001001 12 0x08 00001000 13 0x18 00011000 14 0x1C 00011100 15 0x0C 00001100 ------- ------- -------- If we sort by the binary codes, instead of disc direction, we get the following list: ; SORTED BIT PATTERN ; Signal Input Code Decimal ;------- ------ ---- ------- 00000001 8 0x01 1 00000010 4 0x02 2 00000011 7 0x03 3 00000100 0 0x04 4 00000110 3 0x06 6 00001000 12 0x08 8 00001001 11 0x09 9 00001100 15 0x0C 12 00010001 9 0x11 17 00010010 5 0x12 18 00010011 6 0x13 19 00010100 1 0x14 20 00010110 2 0x16 22 00011000 13 0x18 24 00011001 10 0x19 25 00011100 14 0x1C 28 Look at the "Decimal" column, which indicates the sorted input code in decimal. Notice that there are gaps in the sequence from 0 to 31. That's because we are using only 16 signals out of the 32 possible codes that could fit in the 5 bits that the hand-controller uses for disc input. We can build the full table plugging up those "missing" entries with zeros: ; SORTED BIT PATTERN ; Signal Input Code Decimal Table Value ;------- ------ ---- ------- ----------- ---- 0 DATA 0 00000001 8 0x01 1 DATA 3 00000010 4 0x02 2 DATA 2 00000011 7 0x03 3 DATA 3 00000100 0 0x04 4 DATA 1 ---- 5 DATA 0 00000110 3 0x06 6 DATA 2 ---- 7 DATA 0 00001000 12 0x08 8 DATA 4 00001001 11 0x09 9 DATA 4 ---- 10 DATA 0 ---- 11 DATA 0 00001100 15 0x0C 12 DATA 1 ---- 13 DATA 0 ---- 14 DATA 0 ---- 15 DATA 0 ---- 16 DATA 0 00010001 9 0x11 17 DATA 3 00010010 5 0x12 18 DATA 2 00010011 6 0x13 19 DATA 0 00010100 1 0x14 20 DATA 0 ---- 21 DATA 0 00010110 2 0x16 22 DATA 0 ---- 23 DATA 0 00011000 13 0x18 24 DATA 4 00011001 10 0x19 25 DATA 0 ---- 26 DATA 0 ---- 27 DATA 0 00011100 14 0x1C 28 DATA 1 ---- 29 DATA 0 ---- 30 DATA 0 ---- 31 DATA 0 That's how the "controller_direction" table is constructed: It is just the set of 32 values that we map to each of the possible 32 input codes provided by the hardware, filling in any gaps or invalid values with zeroes. So, why did we use those table values specifically? Because we are mapping the 16 possible directions of the disc into the four cardinal points. That is, the 16 values, starting from zero at the top, and going clockwise on the disc, are converted into the values 1, 2, 3, and 4 representing North, East, South, and West, respectively (reserving zero for invalid values that we will ignore). Below is an illustration. I've shaded the disc valid areas showing. As you correctly pointed out in your original message, we are not only considering the specific, perfectly aligned direction for each cardinal point; but we've instead widen the range accepted for each direction to compensate for typical human inaccuracy when pressing the disc. The perfect-diagonals then act as the boundaries between each direction. ;; 1 1 1 ;; ;; 0 N..N..N 0 ;; ;; x ';:::::;' x Legend: ;; ;; 4 ';:::;' 2 ------------- ;; ;; W:, ':' ,:E N: North 1 ;; ;; ::::-_ v _::::: E: East 2 ;; ;; 4 W::::::"> + <"::::::E 2 S: South 3 ;; ;; :::::-' ^ '-::::: W: West 4 ;; ;; W:-" ,:, "-:E x: Invalid 0 ;; ;; 4 .;:::;. 2 ;; ;; x ,:::::::, x ;; ;; 0 S''S''S 0 ;; ;; 3 3 3 ;; The same applies to the next question. I hope this helps. -dZ.

Compression and decompression of text on the Intellivision should not be a big problem for most use cases, since it falls outside the critical path. First, we can assume that compression occurs at compile time, outside the constrains of the machine, so time and algorithm complexity is not really a factor. This leaves us with decompression and retrieval. I would imagine that the use cases that require the storage and retrieval of huge amounts of text, are orthogonal to the ones that require immediate "twitch-reflex" response processing. If it takes the program, say 10 frames to decompress and display a single sentence (a considerable number of CPU cycles), that is still 1/6th of a second, which is significantly faster than normal human reading speed. I further posit that a human would not mind terribly waiting even a couple of seconds for a "wall-o'-text" to render after input. Now, if you need to decompress a large amount of text in a single frame while playing music, updating sprites, cycling the graphics RAM, and computing other miscellaneous state information; then you are in trouble. But I do not see that as a practical or common requirement. Humans really do not read that fast, and the focus of attention cannot be sustained at that speed. dZ.

OK, thanks. I'll try to get a copy of VisualC++ 2008 (I think I have one lying around) and test. -dZ.

Can you do another fresh install and note the variable before and after IntyBASIC SDK install? -dZ.

OK, I just checked in my Windows XP installation and, after a fresh install, the $PATH variable turns into: PATH=C:\WINDOWS;C:\WINDOWS\SYSTEM;C:\WINDOWS\SYSTEM32;C:\Documents and Settings\Administrator\My Documents\IntyBASIC SDK\bin So, it is appending it. I wonder what's it doing to the C++ installation.

No worries, I don't doubt there's a problem. It just seems weird. Could it be that the path variable becomes too long and its truncated?

Can you elaborate? The installer should append the IntyBASIC SDK paths to the PATH environment itself, not overwrite it. Are you seeing something different? Edit: My understanding is that the "C:\WINDOWS\SYSTEM32" is the standard path, so why would you need to add it? Never mind that. I suppose something else screwy is going on ...

You may want to take a look at the IntyBASIC SDK, which makes building games with IntyBASIC even easier with a few additional tools, the emulator/debugger and everything you need to make games, all bundled up and ready to go. https://atariage.com/forums/topic/240526-introducing-the-intybasic-sdk/

In Pac-Man, background tiles are 8x8 pixels, while sprites are 16x16. In Christmas Carol, the virtual tiles are 4x4 pixels, while the sprites and background cards are 8x8 pixels. I did not have the resolution to make the mazes the same size as the background tiles. My point is that the visual representation of the world does not have to correspond exactly to the actual game world. It not really necessary to map everything to an 8x8 card or to depend on the pixels on that card for collisions. dZ.

Thanks, but I was just generalizing the options, not providing specific implementation details. I think my point still stands: the path is part of the virtual world map which can be either encoded in the background graphics (as you suggest for AD&D, and as I described in my examples for Christmas Carol items), or stored elsewhere in a table. In either case, the player's sprite position is then translated into the position on the map (whether on a table or in the background) and compared against the available path of the location, upon which the game reacts. I do not know how Lock 'N' Chase work, but considering that it is a clone of Pac-Man, it probably works in a similar fashion to it. In Pac-Man, the path is stored in a table of virtual tiles, defining the exits available on that tile. The sprites are allowed to continue forward motion on a tile until the next transition, at which point the position of the sprite is translated into a virtual tile coordinate, and a response is made to the current movement. The Pac-Man model is very common, especially among maze games with a two-dimensional corridor. Encoding bits of the virtual map on the background representation itself (e.g., BACKTAB) is very useful, but is not always practical. -dZ.

It's a lot simpler than what you are thinking. I will give you an example of how this is implemented in my own game, Christmas Carol, which was based on effort to port Pac-Man originally. The maze on the screen is a visual representation of the world, but there is an internal data structure that actually provides all the information for the maze. It defines a set of "tiles" or blocks, where each indicate the path ways in and out of them, and whether there is an item (a candy or snowflake) in it. The entire maze is then divided into these "tiles." It then becomes a matter of computing the position of the player within this "virtual map" using the sprite coordinates. Sometimes, you can encode this information directly on the background tiles, say, by making the assumption that "card #5 is always a wall," or "card #1 indicates an open path"; but once again, you take the player's sprite position on the screen and compute his position in the actual world (whether virtual map or background card), then read the necessary information and act on it. In the case of D&D: Cloudy Mountain, I believe it works the same way: there is an internal data structure that tells you how the world is laid out, including the pathways, walls, etc. Then, the game just keeps track of the position of the player within this virtual world map, as it displays only a portion of it at a time. You can think about it this way: do you remember those games like Defender or even World of Warcraft, in which you have a screen showing you a piece of the world and a mini map showing you the rest of the world? Well, the game actually tracks the player in the wider map, and just shows you the portion where the player is at each moment. That's the theory, which should be enough to get you started. If you are looking for practical implementations, well, it really depends on the game, because the set of data points you need to track may or may not fit in GRAM or the BACKTAB, or other "natural" places, and so you may need to build data tables to define your virtual world map. In my game, I use a combination of both: there are a few bits left unused in the BACKTAB cards, so I encode the state of retrievable or consumable items there (since I can alter the bits). As the player moves, I compute his position on the BACKTAB, retrieve the card and see if there is an item there. If there is, I update the background card and act on the event by giving the player points and engaging some game state if necessary. For the maze itself, I store an array of each virtual "tile" specifying which exits it supports: whether you can move out of it via north, south, east or west. Then I perform the calculation mentioned above: as the player moves or changes direction, I figure out his current "virtual tile," get the exits available, and decide whether he is allowed to move there or not. Then finally, act on it by moving the player, or blocking him. Hope this helps. dZ.

Uh ... that's actually all dynamic card cycling. There is no access to HSYNC interrupts on the Intellivison, only VBLANK. dZ.

I run and test the IntyBASIC SDK on an emulated installation of Windows XP, on a Parallels virtual machine. The virtual hardware specs are also low as well.