Cybearg

Agreed. var+= and var-= would be nice for the sake of convenience, but it's something that's pretty far down the list. I'm not sure if there are BREAK or CONTINUE commands. If there aren't, they would be nice additions, though I think that you can just GOTO out of an IF statement to serve as a BREAK or GOTO a label right before the NEXT to simulate a CONTINUE. For the IF blocks, it would be nice, but since you can just reverse the logic and use a GOTO to create a block, I doubt that we'll see it implemented. i.e. IF var1 = 0 AND var2 = 0 THEN x = 5 y = 6 ENDIF Is the same as IF var1 <> 0 OR var2 <> 0 THEN GOTO skip_if x = 5 y = 6 skip_if: CASE statements can be simulated with ON var GOTO or ON var GOSUB, except that relies on the values always being 0, 1, 2, ... It WOULD be kind of nice.

How about a MAKEGAME command that will allow me to vaguely describe my game idea and IntyBasic does the rest? That shouldn't be too hard to implement, I'm sure. The new stuff sounds great! I'll definitely drop in any specific ideas I might have. Right now, I just want a way to get more space out of the ROMs, but that will probably come down to encoding and other stuff that's not really in IntyBasic's realm to implement directly. Oh, well.

So those repeat values would be repeats per column instead of per row? So, if the screen indexes were organized this way, it would be 0, 20, 40 ... 1, 21, 41... 19, 39, 59... ? I'd wager a guess that there are likely to be more repeated values in a row than in a column, since there will be places where the sky is empty but there is something in the middle/lower screen in the foreground. What's that WORD() and LENGTH() stuff? Are you just demonstrating which represents BACKTAB words and which represents the length values?

Sorry, yes, that's a table of BACKTAB words. This encoding sounds interesting, but how would you read it out while scrolling? Wouldn't you need 12 separate tables, each with its own counter? Or, since you're packing 4 counters into a word, 48 separate counters? And yes, the BACKTAB words include color data, as well as the two high bits, which I use to specify collision cards and interaction cards. At present, the only compression option I have built into IntyMapper creates a table of unique words, then tables of a single byte per card that index the unique BACKTAB word, like so: REM 69 unique cards card_table: data $0000, $01E1, $0079, $05A1, $05A9, $0679, $0601, $063E, $0609, $43A4 data $42FC, $43AC, $05B9, $02F8, $0626, $00D6, $0076, $43B4, $43BC, $068E data $0089, $4682, $43A5, $08E1, $0EFB, $42FA, $02FC, $43BD, $060C, $44E5 data $44EC, $03B2, $05D9, $0611, $0682, $43C5, $43E5, $43EC, $43CC, $08F1 data $02FE, $0665, $4445, $444C, $0686, $02F4, $05E4, $4467, $446B, $05EC data $0539, $0604, $067C, $0301, $03A4, $03BA, $03C1, $0341, $0359, $0309 data $0321, $02F9, $0091, $0461, $0419, $0351, $0399, $0319, $43B2 REM 1680 bytes in map screen_0: data $00,$00,$00,$00,$01,$00,$00,$00,$00,$02 data $01,$03,$04,$05,$02,$01,$02,$01,$00,$00 data $00,$00,$00,$00,$00,$0C,$02,$01,$02,$0D data $0E,$01,$0F,$00,$10,$02,$00,$0D,$01,$05 ... This is limited to 256 unique BACKTAB words, but I'm willing to bet that I won't have that many, possibly not even across all levels. I wonder if I could combine this with the encoding you mentioned? There would be 1 word consisting of 4 counters followed by 2 words of single byte indexes. I can't guarantee that there won't be more than 16 cards of the same type in a row, but shouldn't this be able to compensate by just cutting off after 16 and starting a new counting set?

I'm not sure if gravedigging is frowned on or not, but I've been trying this. Works great in Stella without any modification necessary to the kernel--RevEng must have built this mod into bB somewhere. I have a few questions, though. First off, I have a Genesis controller that I got off of eBay... I think. I've never owned a Sega console, so I know very little about its authenticity. It has the Sega logo on it, but it feels light and flimsy. It has 6 buttons, a Mode bumper in the upper right, a Start button, and the directional buttons. When I plug it in with the 2 button demo running on my Harmony (I selected the game with the joystick, then plugged in the controller, as instructed), the only button that gets any response is the B button. The screen remains colored red and I don't get any second button response. It's possible I got a broken controller or some cheap knock-off that was manufactured wrong or a later generation controller that isn't wired the same. In any case, I need a working controller. The link given in the OP doesn't work anymore, so does anyone know where I could get a reasonably-priced Genesis controller that is guaranteed to work correctly? Secondly, I'm a little puzzled as to how this code works. It sets the lowest bit of an arbitrary variable to 1 if INT1{7} is 1: genesispad=genesispad & $fe if INPT1{7} then genesispad=genesispad | 1 But then just a little ways down it checks if the lowest bit is 1 AND INPT1{7} is 0: if genesispad{0} && !INPT1{7} then pfpixel 26 6 on How can it be both? How could genesispad{0} have gotten set to 1 from INTP1{7} being true, then just a few lines later, genesispad{0} is 1 and INTP1{7} is 0? Nevermind. I just realized that the genesispad bit is set at the start of the program, not in the loop. Sily me! But then, if you need to select the game with the joystick but have the gamepad plugged in when the game begins, how do you make that swap in time? Finally, does this work for both first and second controllers, or the first controller only?

Don't worry about that! I've already made an entire map editor to ease the IntyBasic design process. Implementing an encoding script shouldn't be too much more to ask. Here is an example of two screens of map data: screen_0: data $0000,$0000,$0000,$0000,$01E1,$0000,$0000,$0000,$0000,$0079 data $01E1,$05A1,$05A9,$0679,$0079,$01E1,$0079,$01E1,$0000,$0000 data $0000,$0000,$0000,$0000,$0000,$05B9,$0079,$01E1,$0079,$02F8 data $0626,$01E1,$00D6,$0000,$0076,$0079,$0000,$02F8,$01E1,$0679 data $0000,$0000,$0000,$0000,$0000,$0079,$0000,$02F8,$01E1,$0000 data $0000,$0000,$02F8,$0000,$0079,$0000,$068E,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$0079,$063E,$0000,$0000,$0000,$0000 data $0089,$0000,$0000,$0000,$0000,$0601,$0000,$0000,$0000,$0000 data $0000,$08E1,$0000,$0EFB,$0000,$0601,$0000,$43A5,$43AC,$0000 data $42FA,$0000,$0000,$0EFB,$0000,$0601,$0000,$0000,$0000,$0000 data $08E1,$0000,$05D9,$0611,$0000,$0000,$43A5,$43BD,$43B4,$43AC data $03B2,$0000,$0000,$0611,$0000,$0000,$0000,$0000,$0000,$43A5 data $0000,$05D9,$0000,$0611,$0000,$43A5,$43BD,$068E,$0000,$43B4 data $43AC,$0000,$0000,$0611,$0000,$08F1,$0000,$0000,$43A5,$43BD data $0000,$0000,$0000,$0000,$0000,$43BD,$0000,$068E,$0000,$02F4 data $43B4,$0000,$0000,$0000,$0000,$0000,$42FC,$42FC,$43BD,$0000 data $08E1,$0000,$05B9,$0000,$0539,$0604,$0000,$0665,$0000,$0000 data $060C,$0679,$0000,$0679,$0000,$0679,$0604,$0000,$0000,$0000 data $0000,$08E1,$0000,$0000,$0301,$0604,$0000,$02F4,$0000,$02FE data $060C,$0000,$0000,$0000,$0000,$0000,$0604,$0000,$02FE,$0000 data $0000,$02F8,$03C1,$0341,$0359,$0604,$0000,$0000,$0000,$0665 data $060C,$0309,$0679,$0301,$0321,$02F9,$0604,$0000,$0665,$0000 data $02F8,$0000,$0461,$0419,$02F8,$0604,$0000,$0000,$0000,$02F4 data $060C,$0351,$02F9,$0399,$0319,$0000,$0604,$02F4,$0000,$0000 screen_1: data $0601,$063E,$0609,$0679,$0000,$0000,$0000,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000 data $0601,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000 data $0601,$0000,$0000,$0000,$0089,$0000,$0000,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$4682,$0000,$0000,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$0089,$0000,$0000,$0000,$43A5,$42FC data $43A5,$42FC,$42FC,$42FC,$42FC,$42FC,$02FC,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$42FA,$0000,$0000,$43A5,$43BD,$0000 data $43BD,$0000,$0000,$0000,$0000,$0000,$060C,$0000,$0000,$0000 data $0000,$0000,$0000,$0000,$0682,$0000,$43A5,$43BD,$0000,$0000 data $0000,$0000,$0000,$02FE,$0000,$0000,$060C,$0000,$0000,$0000 data $0000,$0000,$43A5,$42FC,$42FC,$42FC,$43BD,$0000,$0000,$0000 data $0000,$0000,$0000,$0665,$0000,$02F4,$060C,$0000,$0000,$0000 data $0000,$43A5,$43BD,$0000,$0000,$0000,$0000,$0000,$0000,$0000 data $02F4,$0000,$0000,$0000,$0000,$0000,$060C,$0000,$0000,$0000 data $43A5,$43BD,$0000,$02FE,$0000,$0000,$0000,$0000,$43A5,$42FC data $0000,$0089,$0000,$02F4,$0000,$0000,$060C,$0000,$0000,$43A5 data $43BD,$0000,$0000,$0665,$0000,$0000,$0000,$43A5,$43BD,$0000 data $0000,$4682,$0000,$0000,$0000,$0000,$060C,$0000,$0000,$060C data $0000,$0000,$0000,$0000,$0000,$0000,$43A5,$43BD,$0000,$068E data $43A5,$42FC,$42FC,$42FC,$42FC,$43AC,$060C,$0000,$0000,$060C data $0000,$0000,$0000,$0000,$0000,$43A5,$43BD,$0000,$0000,$0665 I need to separate each set of 240 card values into separate tables so that it can be read in during horizontal scrolling.

People like it so much, they can't wait for Flappy Bird on cart. No news of anyone making Angry Birds, Twirly Copter, or Fruit Ninja though, for some reason. All comes down to level design. If the levels were the exact same as on the NES, most levels weren't designed for you to keep moving without ever stopping, so having to play it that way would naturally make it harder, especially if the entire level was synchronized to the start of the level and could be thrown off by you bumping into something and getting slowed down.

Is the ARM those .c files? So it's not just running raw ASM but it's actually running the ASM through a C program in an external processor, or something? Thanks a ton for your effort, Omega. I'll let RevEng know.

Alright, I think that this is the file you want. Let me know if it's not. Odd that they compile automatically to .list.txt now. I could have sworn it used to make .lst files. Looks like A and a reside in $d1. main.bas.list.txt

Hmm... There seems to be a bit of a problem with the sizing. Before this, I was getting a report of 60 bytes free in bank1, but this brings me over by 28: This is what my game looks like, so there's not much I can do to cut down on that space: set kernel DPC+ set tv ntsc set kernel_options collision(playfield,player1) goto __Bank_2 bank2 bank 2 temp1=temp1 __Bank_2 ...

I don't know, because DPC+ seems to auto-assign variable locations or something. DPCplusbB.h, which should have those definitions, like with the standard kernel in 2600basic.h below: Instead looks like this: 2600basic.h.txt DPCplusbB.h.txt

1. I'm using batariBasic v1.01dreveng36 - I don't know what version that means I have, though. 2. Would it be possible to allow that to be set? For instance, use the highest bit of an arbitrary name that the user gets to define in batariBasic, such as "dim bit_variable = c" or something? If not then, personally, just assigning it to the highest bit of "a" is fine. That should be something that I can manage to modify if I have a need. EDIT: I've attached my version of DPCplus_kernel.asm. Comparing them in Notepad++, I see quite a few differences, but I don't know how many mean anything important. DPCplus_kernel.asm

Thanks, Omega! Unfortunately, when I stick the new DPCplus_kernal.asm into my game folder and try to compile, I get this: No idea what that means. Also, from testing your example .bin (which does work), it looks like the score is set permanently for the ROM, am I correct in that? I need the ability to switch between the separated score and the normal score display in real time by setting a bit or by sacrificing a variable or something. The idea is that I want to show a counter and a timer, then switch to the score when points are gained, then switch back to the counter and timer again in-game.

As a small feature request, could 7800basic support inlining .bas files? IntyBasic recently added support for including one .bas file in another, which has allowed me to break sound, music, map, and table data out into separate .bas files for individual editing. It has done wonders for reducing clutter in my main .bas file and it would be great to have that same feature in 7800basic, especially since 7800 games can conceivably be so huge. Also consider this a feature request for batariBasic to add the same functionality. I'd think it would be as simple as checking to see whether an include is a .bas or an .asm file, then including .bas files before compilation and .asm files after compilation but before assembly.

Thanks, DZ. What I've got was already mentioned earlier in this thread. At the moment, I'm not really using any algorithm per se for compression--I'm just reducing the words of screen data to a table of unique words and tables of indexing bytes, more or less cutting the required size in half.

Ah, that's a relief. Thanks, Rev! Are there any parts set by 7800basic that can't be changed on the fly when developing multiple games on the same cart? In batariBasic, there are quite a few things that can only be set once that significantly affect the games' design, like your kernel.

Fair enough. I'm really not clear on what you're talking about. How do I utilize these other ROM segments, and what are they? The problem is, even with compression (at least the kind recommended to me by nanochess--if there's a better form, I've not seen it mentioned) is, since my game is a side-scroller that moves at a fixed rate, 1 pixel every 8 cycles, I can calculate how long it a level will take to play: 8 frames / pixel * 8 pixels / card * 20 cards / screen * 10 screens / level = 12800 / (60 frames / second) / (60 seconds / minute) = 3.555 minutes of gameplay per 10 screens of level data. And since there are (approximately) 240 bytes per screen when using compression, each level is 2,400 bytes. The plan was for 3 levels per stage and 6 stages in the game, putting the entire game at just a little over an hour to play--and this isn't through speed-running, since the game moves at a fixed pace. I really don't feel like 3.5 minutes for a level and 64 minute for an entire game is a good value. To get a minimum acceptable size, I would need to double level sizes, which means double the time to develop and double the ROM space required (4,800 bytes per level * 18 levels = 86,400 bytes for stage data). That's a fair bit more than the 42K words I have available for the entire game. So that means either the game needs to be significantly re-designed to make better use of its limited resources to get more gameplay out of it, or I need some way to hugely boost the amount of ROM at my disposal.

Has anyone with a working brain a bit of time to spare for this? Tweaking the linked minikernel to support a second 6-digit score separated into 2 digits and 4 digits would be ideal, but setting a bit somewhere to switch the normal score between normal and a 00___0000 version would be great, too. If it matters, I'm working in the DPC+ kernel.

So graphics/playfield data is limited to only certain banks, like in batariBasic? I would have thought that graphics, maps, and music would comprise the bulk of a game's data. On an unrelated note, how difficult would it be to do a compilation cart with 7800basic? Is it just a matter of building a number of games and just keeping their data separated but otherwise programming as normal, or are there some necessarily tricks to get around things like palette data being set that can't be changed in a ROM? On another unrelated note, what's the compression like for graphics/map/music/etc. data in 7800basic? Does it provide some built-in compression, or does that have to be done yourself? I know that you're just discussing 144k, but will higher values like the 512k+ that batariBasic can handle eventually come to 7800basic?

And here you go. New save files will include stack colors and will replace existing stack colors when a save file with stack colors is opened. I experimented with also auto-opening custom GRAM images, but I didn't have much luck getting it to work, plus it would probably lead to crash central if map files were shared between people without identical file structures, so it's probably best to keep that as a load-when-you-need-it sort of thing. IntyMapper-1.2.2.zip

I've pondered it some more and, after further playtesting, the scrolling speed I was playing at just was too slow to be satisfying. To make it fun, I've had to double the scroll speed, which means that each 10-screen level that before lasted ~7 minutes will only last 3 and a half. That's just unacceptable for gameplay. Even with compression, there's no way I can get a decent game size for a scrolling game (that doesn't rely on procedural generation or simplified game fields) without the size benefits of page flipping. Consider this an extremely strong "pretty please," nanochess.

True, I don't currently save that. I figured I'd wait until someone asked for it, so I'll implement saving the color stack sometime soon.

Creeper. I see the benefit of what's being discussed. I may well use it in future games, but for the time being, tile-by-tile detail is a necessary part of making the levels feel fresh and interesting, particularly since the shape of buildings drives the core level design and influences gameplay in the primary movement mechanics.

Confirmed. I have the same problem. Unfortunately, it's nothing that I can fix as it is apparently a problem with the GameMaker functions that I call to open/save files. Sorry for the inconvenience, but at least we've got it figured out. I also noticed a couple inconsistencies in IntyMapper's GROM tileset compared to the Intellivision's. 1.2.1 corrects this inconsistency. IntyMapper_1.2.1.zip

While export directly exports the map's values to separate tables with one word per tile, compress instead creates a table of unique card values, then all the map tables use 1 byte to reference the unique values in the card table, allowing each screen to be expressed with 240 bytes instead of 240 words, nearly cutting map size in half. It's nanochess's suggestion for how to compress map data in the thread I linked to. That's... concerning. I didn't change the export functionality at all. I just downloaded the .zip and tried it again to make sure, but I couldn't replicate your problem--it saved fine and I don't see anything in the code that would be stopping it from saving unless you hit cancel or something. Are you getting any kind of error, or do you save and literally nothing happens--no new files whatsoever? Does the program continue to function as normal? Can you walk me through the process you took? Is anyone else having a similar problem?