Cybearg

I'm posting some more questions here because I don't want people to ignore some earlier questions I had by me making a double-post. 1. I'm trying to use PEEK($0200 + tileNum) to determine what tiles are at a certain location, but the values I get seem nonsensical. For instance, tile \209 shows up as 138 while tile \208 shows up as 130. What gives? Why doesn't PEEK return "208"? 2. How does one define a 16-bit variable? I want a variable to hold the score, but it maxes out at 255, since it's apparently an 8-bit integer. How can I get a 16-bit integer? 3. At present, I am displaying the score like so: PRINT AT 3 COLOR 6, ((scoreA %10) + 16)*8+6 PRINT AT 2 COLOR 6, (((scoreA %100) / 10) + 16)*8+6 PRINT AT 1 COLOR 6, (((scoreA %1000) / 100) + 16)*8+6 PRINT AT 0 COLOR 6, (((scoreA %10000) / 1000) + 16)*8+6 This is, of course, clumsy and kind of inefficient. Is there a better way? 4. When using screen scrolling, is there a way to avoid HUD scrolling, or would one have to scroll and then print the HUD every frame to prevent that? 5. When scrolling, is there a way to dynamically change which DATA statement the new cards are being read from? For instance, let's say I have 3 or 4 DATA statements with backgrounds that I want to be drawn in at random intervals during scrolling. How could this be done?

I've been designing some sprites for an idea, but since I'll be using 2-color sprites (requiring two superimposed sprites) and animation frames add up quickly, I'm seeing how that 64-tile limitation can be pretty restricting at times. My current thinking is to have 4 x 2 tile sets for each sprite (4 total, since 8/2 = 4) set aside, which means 8 x 4 = 32 of 64 tiles will be reserved for sprites only, while the remaining 32 can have background cards. 32 should be plenty. The complication, though, is that there are multiple "states" to characters, each of which would take up at least 3 of those 4 reserved tile pairs. For instance, there is walking, idling, firing, and dying. That's not a problem so long as states can be fully represented with 4 tile pairs or less. The only complication I see is, since you can only load one set of tiles into memory at a time, there could be multiple sprites on-screen requiring their states to change simultaneously. Is there any user-defined stack that I could use to queue up state changes, so card sets could be loaded in at subsequent frames? Even if it took 4 frames to load the correct cards, it would be fast enough that the visual complication should be minimal as long as the process can be streamlined. Also, since any combination of states could be represented on-screen at once for any of the sprites, how would you recommend that I handle the DEFINE statements? I could arrange sprite data in labels by state so entire states are loaded at a time, but that means 4 labels per character type x 4 sprites x at least 6 character types = at least 96 DEFINE statements to account for all possibilities across different sprites and different character types, and a mess of branching logic to account for it all. If only I could define the card_num as a variable! Any suggestions for a good way to handle this? Also, on an unrelated note, is there any way to include one .bas file into another? I would rather define card data in a separate file so it doesn't clutter up the main .bas file.

How do you even...

Sweet, thanks! Can we get some sample screenshots in the OP?

Noted, thanks. I'll just have to design around that limitation, then.

On the Atari 2600, there are TIA registers that can be set to cause multiple instances of a single sprite to display in a horizontal row, like so: x1: x2: x3: This still only counts as one sprite because the kernel is just drawing the sprite three times in a row. Is there any equivalent of this for the Intellivision, or could it be added in somehow? This little trick can be enormously useful for making one sprite seem like a lot more, and while it's great that there are 8 sprites for the Inty, I have a few use cases that would supremely benefit from this functionality. Can it be done?

If it's already a stretch to compile C/BASIC into Assembly due to memory/size inefficiencies, I assume the problem would only be compounded if you convert BASIC to C, then C to Assembly, then Assembly to machine code. That's an awful lot of conversions for a low-spec system like Coleco. More likely I'll just have to use C with a bit of Assembly if I want to get into it. I just like the convenience and readability of BASIC when it comes to these older systems. Part of the reason may be because sample code tends to be written uber-efficiently with minimalist documentation, making it difficult to understand what's going on with C, while it's easier to follow BASIC at a glance.

I hope that you're still working on this, PixelBoy. I'd love to see BasicVision released! I skimmed the document and it looks very intuitive and convenient.

So... are good things being discussed? I really can't gauge from what I've read.

Turns out the problem was that I had some modified bB files in my project directory, namely score_graphics.asm. I just renamed that so it wouldn't get used in the compiling and all was well.

No, but programming games in C on a more modern processor would likely be more accessible to batariBASIC homebrewers than making whole race-the-beam kernels from scratch in Assembly. So it's still very relevant to those of us who aren't inclined toward Assembly programming.

Maybe I'm alone in this, but I think treep's proposal of shifting processing to a cheap on-cart processor would be awesome! I'd LOVE to have NES-equivalent capabilities on a 2600 cartridge! As for the question of "what's the point?", the point is that everyone who has a 2600 (a lot of people) can then play those advanced games. It only expands what the system is capable of. If there was a cartridge that could give the 2600 N64-style capabilities while still running the standard hardware, wouldn't that be pretty cool and worth doing? Expanding what can be done on a 2600 cart only expands the potential of the 2600. There will always be geniuses who push the 2600's capabilities with cutting-edge Assembly wizardry, but not everyone can do that. Would you rather have more great games, some that push native functionality and some that rely on newer assist hardware, or fewer games overall, potentially with more schlock as people who are limited by batariBasic push out only limited shovelware games because it's the best they can technically manage? Yes, the 7800 could use some love, but the 7800 doesn't have near the audience of the 2600, nor will it ever. Making more advanced things possible allows more variety for 2600 players and 2600 homebrewers while still leaving the 7800 and pure 2600 audiences in-tact. It doesn't hurt anyone to try to advance things.

Is there some reason the ARM compiler can't be bundled with bB so that the ARM compiler is called to do whatever it needs to do during bB's compilation?

Hm... They do seem to compile fine. Weird, then. I'm not really doing anything out of the ordinary, just adding a playfield to a mostly blank game. If you're willing, I'll send you the problematic .bas file by PM and maybe you can identify what I'm overlooking.

Is there any way this could be done, or does the hands-off nature of the kernel make it impossible? If it can be done, how would it be done?

I'm noticing trouble with the latest DPC+'s playfield display. Namely, if any playfield data is defined, it becomes a flickery, crazy mess. I have tried code that worked with earlier versions of DPC+ (batari's latest releases) but now create the flickering problem I mentioned. As a comparison, here is the earlier DPC+ version: fixit.bas.bin And here is the latest DPC+ version with no code changes except moving a few declarations into bank 2: fixit_dpcnew.bas.bin I get the same effect every time I try to do anything with DPC+ and a playfield. Is this just me? Any fixes available?

But it's still all raw Assembly? No higher-level languages to assist?

Awesome! Glad to see the binary in there, and it's super exciting to have a music player! So the PAL/NTSC detection can determine the speed the game is running at? I didn't think that was possible! Are there different color palettes like with the Atari 2600, allowing one cart to automatically adjust to display the right palette/scanline count from a single cart now?

First off, thanks tons for your awesome, detailed post! Unfortunately, I'm gonna have to load off my questions... Increased custom tile space? I thought that FG/BG mode only made you lose the non-alphanumeric pre-built ROM cards? Aren't there only 64 custom RAM cards for both Color Stack AND FG/BG? Also, you're clearly using more than 4 color, there. I count at least 9. What gives? Very cool! It looks very complicated for tiles, but I guess it's just very clever tiling, huh? I think I follow... The image happens to have mostly green, then white, then cyan, then red, although that's only the case in this very specific scenario. I guess it takes a lot of careful, clever design to make your scene follow these patterns while still looking dynamic and good. From the tree to the green text, you mean? Ok, I think that makes sense. But what about all those tiny, multicolored details where there are balls and lights in close proximity on the tree? Also, are you able to use all foreground colors, or are you limited to only certain ones? Really clever! Does this technique often work, or was it just by fortune that it happened to suit this particular case? But, if it's possible to skip more than 1 place in a stack, why didn't you do so for the O? And why does the stack cycle instead of popping, as I would have expected? Again, really clever, but why didn't you just increment to the point in the stack that you needed? Was the compromise purely to save the GRAM space without having to load in another card?

Finally read it! Initially, I thought I would be going with Mode 0 (Color Stack), but Mode 1 (BG/FG) is looking more and more appealing, now. I foresee fiddling with those color bits will be a real pain in the butt unless I make some kind of subroutine to convert/set those bits for me. Or is that handled by the BASIC?

Thanks for the information! That explains it well. I'll reiterate the one question that wasn't answered:

I don't know what those things mean. Could you please explain? Also, can one change the foreground/background color of cards on a per-card basis, or does setting it for one card affect all until changed?

Thanks for the answers. Sounds like it will take a lot of careful management. To repost my above edited-in question: Also, if you try to load in more than the limit of cards for a frame, will it cause a timing error in the game resulting in screen rolling, or will the game know to take its time? For instance, let's say that the limit is 16 cards per frame and I try to load 64 cards .Will the game just load 16 cards per frame for 4 frames until it's finished, or will that one frame take 4 frames' worth of processing time to complete?

Ok, cool! I just noticed this that I must have overlooked (or didn't understand until now) from the manual: What is the "total" used for? If your data table holds, say, 16 definitions, you can then set the total to 2 in order to load two cards in at once? Does it improve the performance to batch-load 16 cards or does calling DEFINE 16 times, once for each individual card, have the same performance hit? And, when loading a card (or multiple cards) into RAM, does it reduce the number of processor cycles available for gameplay code for a frame, or does it only use cycles from the drawing processing? Also, if you try to load in more than the limit of cards for a frame, will it cause a timing error in the game resulting in screen rolling, or will the game know to take its time? For instance, let's say that the limit is 16 cards per frame and I try to load 64 cards .Will the game just load 16 cards per frame for 4 frames until it's finished, or will that one frame take 4 frames' worth of processing time to complete?

Well, since those 64 tiles are in RAM, I suppose one could just use data tables to hold a large tile set in ROM, then just swap out a handful of tiles (16 or so) into RAM as necessary, creating a large set in the long run, right? Ditto for sprites? For instance, let's say I have 5 levels with distinct tile sets. One level may have 32 cards that get loaded in from a data table, then the second level gets another, different set of 32 cards loaded in from a different data table. Maybe it's even done on the fly depending on where you are in the level, retiring or loading in card sets in-game as you explore different portions of a level. Likewise for an enemy sprite having a certain card for it, then that card is changed in RAM for each frame of animation, rather than swapping between cards. Or is loading a card into memory too slow to be practical for frame animations like that in real time? Is this the full set of available Intellivision pre-made cards?