DZ-Jay

Works better than before. I do have some feedback: The sensitivity of your hand-controller decoding seems very flaky. Sometimes I can shoot two shots in a row, sometimes it forces me to wait about a second before I am allowed to shoot. (I press the button multiple times in a row and it doesn't take it.) I'll play some more and provide additional feedback.

I mentioned in a previous post that the Christmas Carol game employed a sequencing or scripting engine I created to handle cut-scenes, the so-called "Auto-Pilot." I though I'd give some details on that for those interested in such things. I'll try to not get too technical, but anybody curious enough to wander into this blog and wanting further information can just contact me directly and I'll share what I can. Background First, a bit of background. Back in the yonder days of 2008, when I was working on an Intellivision version of Pac-Man, I thought that apart from the normal AI of the ghosts I would need some sort of mechanism with which to script the Pac-Man cut-scenes. My idea was that it would leverage the normal game engine, but provide various commands to position and move the sprites without having to write special-purpose code or individual state machines. The cut-scenes were static animations, typically moving and animating the sprites in specific ways, so I wanted a way to define a "script" that said something like "start Pac-Man at the left-edge, move him to the center, turn up, and walk off the screen, etc." Something like that. My self-prescribed requirements at the time were indeed very simple: provide a mechanism to script each object individually. Thus, the focus was on a per-object script, rather than an overall script for the entire scene. This is a decision which will come to haunt me later, but at the moment it made perfect sense: there is no "scenery" in the Pac-Man's cut-scenes, only moving sprites. So I went and created such a scripting engine, which supported very simple commands such as MoveX, MoveY, SetPositionXY, SetDirection, etc. I used it to animate the ghosts in their pen, and was planning on testing it for the return of their eyes after getting eaten. I called it the Auto-Pilot. The full list of supported commands is below: DEFINE_ENUM(AUTO_CMD, 24)@@Delay EQU [email protected]@Wait EQU [email protected]@GotoScript EQU [email protected]@GotoStep EQU [email protected]@Stop EQU [email protected]@MoveToTile EQU [email protected]@MoveToX EQU [email protected]@MoveToY EQU [email protected]@MoveToXY EQU [email protected]@MoveToTarget EQU [email protected]@MovePix EQU [email protected]@SetTarget EQU [email protected]@SetSpeed EQU [email protected]@SetDirToX EQU [email protected]@SetDirToY EQU [email protected]@SetDir EQU [email protected]@SetState EQU [email protected]@SetFlag EQU [email protected]@ClearFlag EQU [email protected]@FlipFlags EQU NEXT_IDXEND_ENUM Here's the very first script I made for the ghosts moving up and down inside the pen, courtesy of my source version-control time machine: ;;==========================================================================;;;; Title: Auto-Pilot Scripts ;;;; By: DZ-Jay ;;;; Description: Data structures for Auto-Pilot scripts. ;;;; ;;;; Copyright 2010, DZ-Jay, <[email protected]>. ;;;;==========================================================================;;APS_CAGED PROC ; +---------------------------+-------------------+-------------------+ ; | Command: | Param1: | Param2: | ; +-----[email protected]@Up: DECLE AUTO_CMD.SetSpeed, GHST_CAGE_SPEED, 0 DECLE AUTO_CMD.GotoStep, AUTO_STEP(4), [email protected]@Down: DECLE AUTO_CMD.SetSpeed, GHST_CAGE_SPEED, 0 DECLE AUTO_CMD.GotoStep, AUTO_STEP(6), [email protected]@Cycle: DECLE AUTO_CMD.SetDir, SPR_DIR.Up, 0 DECLE AUTO_CMD.MoveToY, $2E, 0 DECLE AUTO_CMD.SetDir, SPR_DIR.Down, 0 DECLE AUTO_CMD.MoveToY, $32, 0 DECLE AUTO_CMD.GotoStep, AUTO_STEP(4), 0 ENDP Scripting Carol Later on, still back in the halcyon days of 2010, when Pac-Man begat Christmas Carol, this simple scripting engine would serve as the basis for the Ghost Of Christmas Presents' movements during the initial phase of development, when he just moved in patterns instead of finding his own path using AI. It was straightforward and effective, and rather powerful. As you may imagine, altering the script was a matter of tweaking the command parameters, and you could "attach" one of these scripts to any of the game engine sprite objects simply by telling the framework something like "enable Auto-Pilot on sprite X." Eventually, the Auto-Pilot grew into a more feature-rich scripting engine when it was used to great effect for the animated cut-scenes of the final Christmas Carol game. It was wrapped in a larger framework I called the "Stage Intro Sequencer," which handled all the infrastructure for the cut-scenes; things like initialization, clean-up, drawing the background scene, revealing the stage title and number, launching the Auto-Pilot scripts for each object in use during the cut-scene, etc. Technical Details The Auto-Pilot itself is exceedingly simple, its design is elegant and streamlined, but it is very versatile. The engine is just a state machine with a dispatcher: it has a table of routines for each script command available; as it transitions from one state to the next, advancing through the script, it calls the appropriate routine for the current step. When the command routine completes, depending on the type of command, it either returns control to the game or calls the Auto-Pilot dispatcher to jump to the next step. An important detail to note is that the Auto-Pilot is not directly called by the game engine, at least not in the way it would if it were just one more game feature. As mentioned before, for better or worse (and I think for the worse, as I shall comment later on), the Auto-Pilot was designed to attach itself to a game object (logical sprite). Therefore, the execution of the script is performed from the perspective -- and within the context -- of the object. In other words, all the commands used in an Auto-Pilot script can be understood to manipulate a particular game object, and not just the general game-state or background scenery. I worked-around this limitation, as I shall discuss later, but it was always more of a hack than part of the grand unified vision. This is the main reason I called it the "Auto-Pilot," since it was intended to be a means to create scripted objects which move under autonomous control. The Sprite Object Record In the P-Machinery game engine (the framework I devised for Pac-Man and later used in Christmas Carol), each logical game object is defined as a data structure called the Sprite Object Record. This record includes a number of fields that describe the state and attributes of each object; things like its position, direction of movement, current state, displacement speed, various attribute flags, etc. Among the fields is a pointer to an Auto-Pilot script. P-Machinery itself does not prescribe the structure or its fields; it just treats each Sprite Object Record as an atomic unit, passing it around various game-specific routines that use it to process the game state. It does reserve some basic fields for itself, like the ones to handle object state and attribute flags; but even those afford a degree of flexibility to the game program which can, for instance, define any number of states relevant to game-specific objects. Below is a full list of all fields used in a Christmas Carol sprite object. ; -------------------------------------- ; Defines a data record for the Ghost ; sprite object. ; --------------------------------------GHOST_OBJ STRUCT 0 ; Address [email protected]@GRAM EQU GRAM_BLOCK.Elf ; Pointer to GRAM [email protected]@System EQU .SYSMEM ; \_ Keep pointers to the RAM where this record is [email protected]@Scratch EQU .SCRMEM ; /@@ObjType EQU [email protected]@ObjIdx EQU .anim_obj_idx ; 16-bit System [email protected]@AnimSeq SYSTEM 1 ; Pointer to animation [email protected]@SpeedRate SYSTEM 1 ; MOB speed [email protected]@TargetFunc SYSTEM 1 ; Pointer to auto-targeting routine ; 8-bit Scratch [email protected]@sX SCRATCH 1 ; \_ MOB screen coordinates (sX,sY)@@sY SCRATCH 1 ; /@@tX SCRATCH 1 ; \_ Target virtual [email protected]@tY SCRATCH 1 ; /@@State SCRATCH 1 ; Current Sprite [email protected]@Flags SCRATCH 1 ; Status [email protected]@DirCurr SCRATCH 1 ; MOB current direction [email protected]@DirNext SCRATCH 1 ; MOB next direction [email protected]@RateFrac SCRATCH 1 ; Left-over MOB speed [email protected]@ScriptSeq SCRATCH 2 ; Pointer to sprite auto-pilot script [email protected]@Mob SCRATCH 1 ; Assigned MOB number ENDS As you can see above, the second from last field, @@ScriptSeq, is intended to hold a pointer to an Auto-Pilot script. Another relevant field for our discussion is @@Flags, which is an 8-bit register holding the state of various sprite attributes. The full specification of the bit-field is below: ; +---+---+---+---+---+---+---+---+; | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |; +---+---+---+---+---+---+---+---+; ^ ^ ^ ^ ^ ^ ^ ^; | | | | | | | '-----| Flip adjustment; | | | | | | |; | | | | | | '---------| Stealth; | | | | | |; | | | | | '-------------| New Tile; | | | | |; | | | | '-----------------| Animate; | | | |; | | | '---------------------| Active; | | |; | | '-------------------------| Flip X; | |; | '-----------------------------| Hit; |; '---------------------------------| Auto-Pilot Hopefully it is obvious from the above list that, apart from generic fields like Active, Animate, and AutoPilot, the rest are employed for very game-specific attributes. Christmas Carol was the first application of the P-Machinery framework, and both grew organically together; and as the complexity increased, some compromises were made along the way that fused various pieces together. This is the main reason why P-Machinery was later released without a sprite engine: because a lot of it was interdependent on game-specific functionality which was not adequately generalized. On the one hand, Christmas Carol was completed and released to great success; on the other, the generalized, all-purpose game development framework that P-Machinery was intended to be, never reached its full potential. This is a problem I intend to fully rectify with P-Machinery 2.0, aptly named P-Machinery AGE (Advanced Game Engine). Engaging The Auto-Pilot During game-play (or at any point in the game program), engaging an object "on auto-pilot" involves just assigning a script to its @@ScriptSeq field and setting its Active and Auto-Pilot flags. The rest is handled automatically by the framework. As the P-Machinery engine periodically handles the motion routines of each active object, it test the Auto-Pilot flag. If set, it will call the Auto-Pilot dispatcher; otherwise, it will invoke the motion routine as normal. The basic algorithm is like this: If the object Active flag is set thenIf the object AutoPilot flag is set thenCall the Auto-Pilot dispatcher for the object [*]Else Call the normal motion routine for the object [*]Else Do nothing In pseudo-code, it'll look like this: procedure MoveGhost { // Only handle the Ghost if it is active if (GhostObj.Flags(Active) == True) { // Determine whether we move the Ghost // or let the Auto-Pilot handle it. if (GhostObj.Flags(AutoPilot) == True) { Call AutoPilotDispatcher(GhostObj) } else { Call MoveEnemy(GhostObj) } }} Thus, each object can engage its own Auto-Pilot script, which works even during normal game-play. In fact, Christmas Carol is full of such little scripts; they handle many of the scripted animations and motions which do not depend on game-state or the normal path-finding logic. An example of this is when the Ghost stops periodically in the middle of game-play to "look around." Another one is when the elf dies, which invokes a complex "death" animation sequence. Coming Up Next... In the next installment in this series we'll delve deeper into the guts of the Auto-Pilot engine to see what makes it tick. We'll follow that with a technical description of the available commands and what they do. Eventually, we'll present some sample scripts from Christmas Carol and hopefully all this background will help to illustrate how an insane amount of versatility and complexity is encapsulated in such a simple interface, which affords an exceedingly large amount of creative expression. Finally, we'll conclude with some lessons learned from the practical application of the original Auto-Pilot engine to the Christmas Carol game, and what design constraints, limitations, or principles we would change or improve upon for its next incarnation in P-Machinery 2.0. -dZ.

GotY?

The SDK does it for you for free. Creating a new project with "intynew" will do that automatically if you provide a title and an author. There is also a sample project called "classic" that shows how to do it yourself. -dZ.

By the way, you are "guinea piggying" the installation and manual setup. The SDK itself I've been using for several years and it works quite well. Hopefully this week-end we'll have a public release of both Windows and MacOS versions of the IntyBASIC SDK. dZ.

The irony is that I am a Mac user. You will find that the SDK for Mac is actually better than the one for Windows in that the tools are a lot more versatile in the way they handle arguments and even integration with the online "man pages" manual. However, I was a Windows developer for many years but never developed on the Mac, so it was easy for me to create an easy to use installer for Windows that does *everything*, but the same eludes me on the Mac. What it should do is: copy folder with all tools and documents; install the SDL framework; set the tools permissions; create 2 environment variables and add to the $PATH; then create an alias to the folder on the Desktop and a custom configuration for Terminal.app for debugging. I got it to do step 1. everything else has to be manual right now. dZ.

To anybody reading this, the advantage of the IntyBASIC SDK was always intended to be easy, turn-key set up, without the mess of having to create special folders and muck with the environment. The Windows version works well that way, but since I am not a Mac programmer (only a regular Mac user), I do not know how to prepare a package to do the exact same thing on MacOS. Even though you will have to set up your environment variables by hand on the Mac right now, it is still a one-time thing, and once you are set up, all you need to do is use the IntyBASIC SDK as always intended. It provides many tools to create new projects, compile and assemble in one go, and even build and test in the debugger in one go. It includes comprehensive documentation for each tool and all sorts of help. The MacOS version even installs "man pages" for each of the tools. -dZ.

OK, I prepared a quick-and-dirty installer for the MacOS version of the SDK. The Mac version is ready to roll (and even better than the Windows one!) and even includes the latest version of the compiler and assembler, but I haven't been able to prepare an idiot-proof installer that will set up the environment correctly. I've sent blainelocklair a PM with the installer and instructions on how to set up the environment variables. He can be the guinea pig in testing it and if it works, I'll post the full thing publicly later today. blainelocklair, please make sure to comment out any environment variables you added for your current installation so that they don't collide with the SDK ones. The IntyBASIC SDK is a self-contained environment, which includes the compiler, assembler, emulator, and all necessary tools to run. Anybody else wants to test the MacOS version of the IntyBASIC SDK? -dZ.

I have a Mac OS version of the SDK ready but unreleased. It requires some minor setup on the user's part since the installation package is not ready. It should make using IntyBASIC on a Mac an easy job. Send me a PM and I'll hook you up with it this week. dZ.

I have some exciting news. My grand-stepson step-grandson grandson-step step-son-grand-step step-step-grandson step-grandson-step grandson-step-squared ... the step-son of my step-daughter is paying us a visit next Friday. He will spend the night and has volunteered to read the Christmas Carol story for us and provide his feedback. I am excited (and a bit nervous) about this development. You see, he is 9 years old, and precisely the right target age I've been proclaiming for the book since the beginning. This will actually test that. (Eek!) As you may remember, my 12 year-old nephew has already declared the book to be very good, but disclaimed his comments by suggesting obliquely that no self-respecting 12 year-old boy would actively pick a book about Christmas magic and elves and cute ghosts from a bookstore's shelf -- not unless there was enough fame and pop-culture "coolness" behind it to overcome the stigma of it not being about super-heroes or gross-out topics. A 9 year-old, however, my nephew predicted would be the perfect candidate for it. (I thought it was cute how he distanced himself so much from that demographic, as if those additional 3 years of life had endowed him with such wisdom and maturity. I guess in a sense it has, but still ... ) Anyway, my grand-step-something-or-other is coming, and we'll finally get a perspective from someone belonging to the (presumably) appropriate age group. I'm excited. (Eek!) Like before, I should expect to write an entry with his feedback, good or bad next week. In the meantime, I aim to get Chapter 13 -- the penultimate chapter of the story -- completed by then so that he can have an almost complete story to read. He would then be left at the cliffhanger building up to the exciting climax, right before the concluding chapter. If he should like the story, that should keep him on the hook. Let us see how that goes. See ya', -dZ.

I played the ROM for a few tries. I have some feedback: There is a glitch when you kill an enemy, in which the sprite pops up for a frame or so below the entrance gate. Actually, it's the bullets counter card that pops up briefly. The gun initially acts as a "wall," in that colliding with it will stop you. I have to move away and then back in, in order to advance. At one point, the gun came out at the bottom of the screen, and the enemy that was close by continued walking into the bottom border and left the screen. At another point, I was shooting at an enemy, and he went through a wall at the same time. It seems that the collision detection has a problem with priorities. Sometimes it takes 2 bullets to kill an enemy, sometimes I spent all 5 bullets and he is still walking. I don't understand that. The fast colour flickering of the initial "Ready!" message is distracting and makes the letter hard to read. I know that this is something done in many platforms, but the Intellivision colour palette makes it look weird when you're cycling through some very dark strange colours. Also, the "Ready!" message should perhaps come from the side first. When it starts in the center, it is hard to read, so by the time you focus on it, it has left the screen, then it comes back from the other side. Feels unpolished. Papi bullets probably shouldn't kill Papi. If the game is about helping Papi survive, perhaps it shouldn't be called "Get Papi!" That's it for now. It's looking good.

Got my assignment ... Elf mission accepted! This Santa's helper is ready to rock n' roll!

YAAAAAAAY!

Holy crap!!! I remember that. Jeez, even when you tend to think that the coolest stuff happened in the 1980s, you are reminded of stuff like that. -dZ.

Houston, we've had some progress. Yes, indeed we have. After several weeks of goofing off and doing other stuff (even my blog entries were about other topics during that time), I finally came back to the Christmas Carol story and wrote one more chapter. Well, before we celebrate some huge accomplishment, let me temper the mood by stating that the new chapter is merely four pages long, so not really that big a deal. What is a big deal, actually, is the fact that I am now only two more chapters away from the ending! (Bring out the bubbly! Yay!) To be honest, chapter 12 is only four pages long because that's as long as it needs to be. It wasn't rushed or anything, it is just a brief interlude depicting one of the short vignettes from the game's cut-scenes. It fits within the narrative and adds charm and whimsy to the story. For anybody who played the game, you will recognize the vignette as the introduction sequence to Stage #7, "Krystal Keep." Here it is in full, for your viewing pleasure: https://vimeo.com/301452466 Notice that it is purely a visual gag. Part of the fun is that in the animation, Carol's eyes dart left to right following the Snowman as he walks by, suggesting that there is more to that makeshift snowy figure than what it seems. Well, of course, that wouldn't translate very well to the written word, so I took a different approach: I distilled the sequence to its essence, which I took to be Carol building a decoy, and the Snowman -- knowing that the elf must be nearby -- searching and scanning all around for it. The surprise is that the narrative suggests -- and indeed this is reinforced by the Snowman's thoughts -- that Carol built the decoy and ran away to hide; but in reality, she is actually hiding inside the fake snowman! This is revealed in the story in a similar way to the animation sequence. The Evil Snowman, it is stated, is absolutely sure that she went to hide nearby that he will then spend some time searching for her in the surrounding caverns. Since Carol can assume he won't be back to this room, where he already searched, she is free to go about and escape the cavern to another area by just going in the opposite direction. Chapter 12 is thus aptly named "The Great Frosty Escape," and I think it is very effective in not only being entertaining and whimsical, but in showing Carol Greenleaf's audacity and resourcefulness. Plus it reinforces the notion that she does not need magical snowflakes or other external powers to outwit her foes. During the development of the game, my wife provided the idea for the vignette. It was the first multi-object animation sequence that showed more than two sprites at a time, theretofore. When my wife suggested it, I told her "hmm ... that's going to require a lot more infrastructure than what I have right now. I can't do it." Which she took to mean "it is technically impossible," and proceeded to tell me how she knew I could do it if I only figured it out. At that point, the two or three sequences I had made had either the Ghost by itself, the Elf by itself, or the Ghost and the Snowman together; all of which used the existing assets and engine features available to the game itself. "This new one," I told her, "will required Carol holding two sticks, the Snowman with his twiggy arms, an some fancy new animation to depict the melting of the snowman to reveal the elf inside!" To which she responded, "alright, so you can do it." How could I argue with that logic. Thus, I updated my cut-scene sequencing engine, which I had christened the "Auto-Pilot," to support additional commands and to manipulate up to six or eight individual objects (or composite sprites) at once independently. I am glad I did, for after that the cut-scenes became a lot more elaborate, and a lot more expressive. For instance, in that snowman sequence, there are a few subtle features that add depth: there is a shadow when the Snowman passes in front of the decoy, the decoy itself has moving eyes that follow the Snowman, and the animation of the Snowman's arms was altered to do the "search with hand over eyes" effect. And that's on top of the existing background features, like the randomly timed droplets falling from the ceiling, cute little emoticons on top of the sprite heads, and the automatic cover at the edges of the screen that allowed the sprites smooth ingress and egress onto the stage. All of that together would have been impossible previously, and the new Auto-Pilot engine afforded it almost for free with a simple scripting interface. I therefore, dedicate this chapter to my wife for not only inspiring the vignette which served as its source, but for pushing me to enhance the original game code with a feature which is arguably one of the best of the entire Christmas Carol game: the fun and expressive animated cut-scenes. Anyway, enough of that. I'm going now back to work. I have to start work on chapter 13. See ya', -dZ.

And just for the sake of giving you all the options, the LTO Flash! is $119 USD + shipping and is currently available directly from the manufacturer; but you could also get an older, discontinued device called the Cuttle Cart 3, which is only available in eBay from some speculators/gougers at several hundred USD; and your third option is to wait for something called The Hive which is another flash cart in development for several years, which nobody knows when or if it is coming out. All that to say that perhaps those $119 USD for the LTO Flash! is not so bad. -dZ. P.S. The Cuttle Cart 3 (CC3) works very well, and I used one myself. However, I bought it when it was still available. If you can find one at a reasonable price it would be very useful; but I'm afraid it's treated by some as a "collector's item."

Looks good, but perhaps too much grey. That particular shade of grey does not look too good with the green, it makes it look a little drab. -dZ.

I am using Safari and it works fine. I also tried with Firefox on my Mac and it asked me if I wanted to allow access to the QuickTime plug-in. After that, it worked as well. -dZ.

Well, you could do it by shifting the cards in real time, but it's a lot easier to just pre-compute the shifts and just cycle the GRAM with new cards. We call it "GRAM Cycling" because the technique is not only used for shifting, but for key-frame animation. The trick is to do the GRAM cycling within the VBLANK period. -dZ.

Instead of using a MOB for a sprite, you draw the sprite on GRAM and place it on the BACKTAB (the background). When the sprite moves, you animate it by switching the card in GRAM which displaces the object. For example, your bullet can "move" 8 pixels like this: ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ##...... .##..... ..##.... ...##... ....##.. .....##. ......## ##...... .##..... ..##.... ...##... ....##.. .....##. ......## ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ You use the logical position of the object to compute an offset in the card. When the object crosses a tile boundary, you reset the animation card to the first one, and "move" the tile to the next one in BACKTAB. The "GRAM Cycling" is the constant switching of the GRAM card with a new animation frame. Does it make sense? -dZ.

Of course! You're doing great. For a prototype, it surely almost looks like it could be a complete game. I say "almost" because it needs more mechanics and a little polish; but what you have is very solid and interesting. I can't wait to see what game you have in mind. Get some rest, cheers! -dZ.

Aha! Gotcha! No worries. Since you are interested in learning techniques for Intellivision games, one thing that you may want to try as part of your proof-of-concept is to use GRAM cycling for sprites rendered in the BACKTAB. This is yet one more technique that can help you in the future make a game with more enemies or moving objects. For this program, the easiest way would be to use the technique for the bullet. Since the bullet has no animation, and does not have to go over anything (i.e., it collides with anything on its path), it is the simplest object to animate in the BACKTAB. If you are interested, we can help you with that. It should be simple, but it is very effective and is a useful technique to know. -dZ.

Looks great! It seems that you are re-using one of Papi's MOBs for the bullet. However, as I mentioned before, Papi uses only three colours, so you should be able to composite him with only three MOBs, leaving one for the bullet. Is there a specific reason you are using four MOBs for Papi instead of three? Perhaps we can help you re-compose the sprite so that he keeps all his colours and pixels, but uses three MOBs. -dZ.

According to the IntyBASIC manual, you do: SOUND 0,1,0 SOUND 1,1,0 SOUND 2,1,0 SOUND 4,1,$38

Perhaps I don't understand your question. Just in case, here's a brief explanation: "DECLE" is in Assembly Language like "DATA" is in BASIC, which is to say, a way of storing data in ROM. Both store a 16-bit word (the Intellivision is only word-addressible; when accessing 8-bit RAM, it just makes the high-order byte all zeros). The difference between "BITMAP" and "DATA" in IntyBASIC is that "BITMAP" automatically packs two bytes in "little-endian" format. That is, the first byte goes on the lower-order half of the DECLE, and the second byte goes on the high-order half. This is an exceedingly convenient format to pack graphics data to copy into GRAM in the most efficient way. The typical Assembly Language block-copy loop for GRAM is like this: ; Copies one card of data into GRAM ; packed in 4 16-bit words in ROM. ; R4 = auto-increment register pointing to source data ; R5 = auto-increment register pointing to destination REPEAT (4) [email protected] R4, R0 ; Get word data [email protected] R0, R5 ; Copy first byte into destination SWAP R0 ; Flip word [email protected] R0, R5 ; Copy second byte into destination ENDR Thus, we pack the 8 bytes of a GRAM card into 4 16-bit words, where each DECLE packs two words: the odd-numbered bytes in the low-ordered half; the even-numbered bytes in the high-ordered half. For example: ; Animation Tile: 0 (ID: 0) ; -------------------------------- ; ..###... - %00111000 DECLE $7C38 ; .#####.. - %01111100 ; #.#.###. - %10101110 DECLE $AEAE ; #.#.###. - %10101110 ; #######. - %11111110 DECLE $FEFE ; #######. - %11111110 ; #######. - %11111110 DECLE $B6FE ; #.##.##. - %10110110 ; -------------------------------- The "BITMAP" statement does this automatically for you by accepting as input a string describing an 8-bit graphic in either binary ("00110011") or symbolic ("..##..##"). The compiler will take a pair of BITMAP statements, decode the argument, and pack the two bytes into a DECLE as mentioned above. Does this answer your question? -dZ.