IntyBASIC compiler v1.0 crunchy&tasty :)

[freewheel]

 

Now it's considerably more robust. You can do VOICE INIT to kill everything queued up, which is a reasonable thing to do in certain game circumstances. (Like, for example, your ship blows up and its game over.)

 

And if you want to annoy the hell out of people.

[intvnut]

 

And if you want to annoy the hell out of people.

 

"Impulse drive destroyed"

"Energy Level Three Hundred Ninety One"

"Starbase Three under attack"

"Battle computer destroyed""

"Shields 2/3rds down, under repair."

"Energy Level Three Hundred Twenty Seven"

"Tracking computer destroyed."

"Starbase Three under attack"

"Energy Level Two Hundred Thirteen"

"Hyperdrive destroyed."

"Energy Level One Hundred Forty Two"

"Starbase Three destroyed."

 

"The battle is ov-CRAZYBUS... CRAZ-CR-CRAY-CRAZYBUS"

 

 

(damn lot of good those shields did. *hmpf*)

Edited December 17, 2014 by intvnut

[intvnut]

I was too slow to add these flavor images...

 

 

 

"Impulse drive destroyed"

"Energy Level Three Hundred Ninety One"

"Starbase Three under attack"

"Battle computer destroyed""

"Shields 2/3rds down, under repair."

"Energy Level Three Hundred Twenty Seven"

"Tracking computer destroyed."

"Starbase Three under attack"

"Energy Level Two Hundred Thirteen"

"Hyperdrive destroyed."

"Energy Level One Hundred Forty Two"

"Starbase Three destroyed."

 

"The battle is ov-CRAZYBUS... CRAZ-CR-CRAY-CRAZYBUS"

 

 

(damn lot of good those shields did. *hmpf*)

 

 

[freewheel]

Just updated to IntyBASIC v1.0.1

 

Please check for changes in first post.

 

Hm. My sprites are exhibiting jitter when I use scrolling now. It's not horrible but it was soooo damn smooth before. Did you change anything around this, that you can think of? I'll have to do some experiments and see what I can uncover.

 

Edit: OK, fixed, and I can live with this - in fact it's probably better - but not sure what changed. Here's what I had to do:

 

Old:

 

1. Draw sprites

2. Scroll

3. WAIT

4. Draw next column

5. Check input

6. Draw sprites

 

New: remove step 6 (the double sprite drawing) but call it when the scroll speed drops to zero - because the scrolling routine is where I actually draw the sprites in 1 and it isn't called when speed is zero

 

It might be my spaghetti code biting me in the ass, but there are reasons why I had it calling SPRITE multiple times per cycle. Not sure what else might be affected but it's not a crisis for the moment. I suspect you've optimized something, somewhere.

Edited December 18, 2014 by freeweed

[+nanochess]

 

Hm. My sprites are exhibiting jitter when I use scrolling now. It's not horrible but it was soooo damn smooth before. Did you change anything around this, that you can think of? I'll have to do some experiments and see what I can uncover.

 

Edit: OK, fixed, and I can live with this - in fact it's probably better - but not sure what changed. Here's what I had to do:

 

Old:

 

1. Draw sprites

2. Scroll

3. WAIT

4. Draw next column

5. Check input

6. Draw sprites

 

New: remove step 6 (the double sprite drawing) but call it when the scroll speed drops to zero - because the scrolling routine is where I actually draw the sprites in 1 and it isn't called when speed is zero

 

It might be my spaghetti code biting me in the ass, but there are reasons why I had it calling SPRITE multiple times per cycle. Not sure what else might be affected but it's not a crisis for the moment. I suspect you've optimized something, somewhere.

 

There should be no problems with the optimization because things run faster.

 

You could try to return to your previous version of source, compile with a previous version of IntyBASIC and try to "separate" the code portion that changes behavior between IntyBASIC versions. I could check over that.

[intvnut]

 

Hm. My sprites are exhibiting jitter when I use scrolling now. It's not horrible but it was soooo damn smooth before. Did you change anything around this, that you can think of? I'll have to do some experiments and see what I can uncover.

 

Edit: OK, fixed, and I can live with this - in fact it's probably better - but not sure what changed. Here's what I had to do:

 

Old:

 

1. Draw sprites

2. Scroll

3. WAIT

4. Draw next column

5. Check input

6. Draw sprites

 

New: remove step 6 (the double sprite drawing) but call it when the scroll speed drops to zero - because the scrolling routine is where I actually draw the sprites in 1 and it isn't called when speed is zero

 

It might be my spaghetti code biting me in the ass, but there are reasons why I had it calling SPRITE multiple times per cycle. Not sure what else might be affected but it's not a crisis for the moment. I suspect you've optimized something, somewhere.

 

Do 1 and 6 draw the sprites in the exact same places, or does the code in 6 see an updated "world view"? If 6 sees an updated world view, then faster code for 4 and 5 could make a difference.

[freewheel]

Random weirdness that took me FOREVER to track down:

 

Some old code still had me using only RETURN for closing out my GOSUBS (no END). It compiled perfectly fine with IntyBASIC 1.0.1. But then I realized I was still doing PRINT number the awkward way, so I converted some statements to PRINT <x>number. Suddenly, it compiled but the assembler started barfing on undefined labels for the printnum routine. Changed RETURN to END and everyone's happy.

 

Just wasn't the kind of dependency I expected. I had commented out several hundred lines of code trying to figure out why the hell a statement that compiled and assembled perfectly fine in one program, wouldn't in another. I ended up almost re-writing it from scratch until I noticed the PROC causing the problem, but not the contents of the PROC. Weirdness.

[First Spear]

How would "saving state" for a game be implemented? For example, in Kroz there are 3 slots that let players pick up a game later after it is powered-off.

 

Thanks.

[freewheel]

How would "saving state" for a game be implemented? For example, in Kroz there are 3 slots that let players pick up a game later after it is powered-off.

 

Thanks.

 

You mean within your game itself? Well, you'd have to make sure your game is very much state-oriented. Then take every applicable variable and save it off to cartridge flash. Re-load that to re-start the game accordingly. It's a fair bit of work; you really need to design your game from the ground up to support this. Unless you go with something very simple like how many levels in you are - that's trivial to implement. I assume Kroz is more complex, saving say inventory, player statistics, location, that sort of thing.

 

I doubt that IntyBASIC has hooks into whatever flash is available, but POKEs might manage it.

 

I've thought about it and to be honest, I think a code-based save is more appropriate for a system of this vintage. Battery-backed and flash-based saving really didn't exist until after the INTV was off the shelf. Code-based is fairly simple, you just take your inventory, status, whatever, pass it through a hash function of sorts, and bang out a code. Of course it's annoying as all hell to write these codes down and have to re-enter them every time, but that's part of the charm of the mid 80s

Edited December 24, 2014 by freeweed

[intvnut]

 

You mean within your game itself? Well, you'd have to make sure your game is very much state-oriented. Then take every applicable variable and save it off to cartridge flash. Re-load that to re-start the game accordingly. It's a fair bit of work; you really need to design your game from the ground up to support this. Unless you go with something very simple like how many levels in you are - that's trivial to implement. I assume Kroz is more complex, saving say inventory, player statistics, location, that sort of thing.

 

I doubt that IntyBASIC has hooks into whatever flash is available, but POKEs might manage it.

 

IntyBASIC doesn't have the hooks, I'm pretty sure, since nanochess hasn't contacted me to ask about them, and it's a little non-obvious.

 

JLP stores game states in flash, and so requires significant (in processor cycles) time to move save state into/out of flash. Also, some care should be taken for wear leveling (although realistically what I do in my own code is probably overkill).

 

POKEs alone won't cut it. The flash programming is time-wise expensive and stalls the MCU that's at the heart of JLP. That means JLP "disappears" during the flash programming process. Therefore, the flash programming steps require a very compact, 5-word "stub program" in Intellivision system RAM to handshake with JLP. This stub manages the start and end of the programming process from the Intellivision side. During the programming process, none of the JLP resources (RAM or ROM) are available, so the stub has to double as polling loop and ISR. Also, the Intellivision system stack needs to reside in System RAM (at least during the programming process).

 

It's a little tricky, but I have developed some library code to make it work pretty well. Kroz uses that code, and it works well. Christmas Carol uses a simpler version of it. (We had planned a more extensive high score leaderboard using the full code, but time constraints cut that short.)

 

JLP flash support could be integrated into IntyBASIC. The real question comes down to programming model, and how you want to stash things in flash and retrieve them. JLP actually puts very little structure on how the flash gets used; it just reports how much is available, lets you program rows, read rows, and erase sectors (which are groups of 8 rows). Adding support for that to IntyBASIC really is a matter of thinking about the programming model you'd like to expose. You want something that makes sense in an IntyBASIC context.

 

As nanochess is the IntyBASIC architect, it's really up to him to decide if this is something he wants to support, and what that support looks like.

[+nanochess]

 

IntyBASIC doesn't have the hooks, I'm pretty sure, since nanochess hasn't contacted me to ask about them, and it's a little non-obvious.

 

JLP stores game states in flash, and so requires significant (in processor cycles) time to move save state into/out of flash. Also, some care should be taken for wear leveling (although realistically what I do in my own code is probably overkill).

 

POKEs alone won't cut it. The flash programming is time-wise expensive and stalls the MCU that's at the heart of JLP. That means JLP "disappears" during the flash programming process. Therefore, the flash programming steps require a very compact, 5-word "stub program" in Intellivision system RAM to handshake with JLP. This stub manages the start and end of the programming process from the Intellivision side. During the programming process, none of the JLP resources (RAM or ROM) are available, so the stub has to double as polling loop and ISR. Also, the Intellivision system stack needs to reside in System RAM (at least during the programming process).

 

It's a little tricky, but I have developed some library code to make it work pretty well. Kroz uses that code, and it works well. Christmas Carol uses a simpler version of it. (We had planned a more extensive high score leaderboard using the full code, but time constraints cut that short.)

 

JLP flash support could be integrated into IntyBASIC. The real question comes down to programming model, and how you want to stash things in flash and retrieve them. JLP actually puts very little structure on how the flash gets used; it just reports how much is available, lets you program rows, read rows, and erase sectors (which are groups of 8 rows). Adding support for that to IntyBASIC really is a matter of thinking about the programming model you'd like to expose. You want something that makes sense in an IntyBASIC context.

 

As nanochess is the IntyBASIC architect, it's really up to him to decide if this is something he wants to support, and what that support looks like.

 

I'm thinking about it, probably I'll decide about the programming model once I get my JLP cartridge, currently I'm not sure if jzintv supports some kind of emulation of the Flash implementation.

 

It would be very useful to save high-score tables or progress points for RPG games.

[intvnut]

 

I'm thinking about it, probably I'll decide about the programming model once I get my JLP cartridge, currently I'm not sure if jzintv supports some kind of emulation of the Flash implementation.

 

It would be very useful to save high-score tables or progress points for RPG games.

 

There is support in jzIntv for JLP's flash save states. The --jlp flag enables it, although jzIntv 'forgets' the flash contents on exit since it doesn't know where to put them. The flag --jlp-savegame=filename puts the flash image on disk.

 

LTO Flash will eventually support emulating JLP's flash save states as well; however, it may not be in the very first firmware. (LTO Flash is field upgradable.)

[First Spear]

 

I was thinking of, in my code, saving things I need to save in an in-memory structure (eg array) that is sa6 512 bytes. Those bytes need to go "somewhere" when the player wants to save the game and when the Inty gets power they need to come out of that "somewhere" and into the structure so my code could then unwrap it into the game. I'm OK with the de/serialization part, it's the storage and retrieval I am unsure of.

 

Thanks.

 

 

[snip]and flash-based saving really didn't exist until after the INTV was off the shelf. Code-based is fairly simple, you just take your inventory, status, whatever, pass it through a hash function of sorts, and bang out a code. Of course it's annoying as all hell to write these codes down and have to re-enter them every time, but that's part of the charm of the mid 80s

[snip]

[First Spear]

 

 

I am trying to come up with a decent RPG-style of game, so saving a complex set of states will be very necessary. I think that IntyBASIC makes a great platform for the graphics and game play and music, but I do need to get my head around strategies for loading/saving, as well as using large amounts of memory for swapping/storage.

 

All ideas appreciated. Thanks!

 

 

I'm thinking about it, probably I'll decide about the programming model once I get my JLP cartridge, currently I'm not sure if jzintv supports some kind of emulation of the Flash implementation.

 

It would be very useful to save high-score tables or progress points for RPG games.

[intvnut]

I was thinking of, in my code, saving things I need to save in an in-memory structure (eg array) that is sa6 512 bytes. Those bytes need to go "somewhere" when the player wants to save the game and when the Inty gets power they need to come out of that "somewhere" and into the structure so my code could then unwrap it into the game. I'm OK with the de/serialization part, it's the storage and retrieval I am unsure of.

 

Thanks.

 

 

Well, that aligns well with what the flash provides. The flash is organized as rows of 96 words (192 bytes), in groups of 8 rows per sector. You can program each row individually, but you can only erase by sector. Empty (erased) rows read as $FFFF

 

So what I typically do (and recommend to others) is to put a version number in the first two words of the data. Highest version number is newest, and version $FFFFFFFF is 'empty'. When writing:

• Scan to the first 'free' row
• If there are no free rows, erase the sector with the oldest data and pick the first row in that sector
• Write your data to the selected row

When reading, find the row with the newest data and read that in.

 

This requires a pool of rows at least two sectors large. A larger pool spreads the wear over more sectors. The flash on JLP has about 10,000 erase/write cycles per sector, so you want to spread your writes out. You also don't want to save to flash gratuitously, but rather when there's something actually new and interesting to save. JLP makes all the flash not used by the game or firmware available for save-game storage. Even a 42K word game only uses about 1/3rd the storage JLP offers, so there's plenty there for save-states.

 

Your data is large enough that it would occupy 3 or 4 consecutive rows. (It's probably easiest code-wise to round up to 4 rows.) The same algorithm applies; just operate on groups of 4 rows at a time.

 

If you want multiple "save slots", such as what you find in Phantasy Star and Kroz, you can dedicate separate pools to different save slots, or any number of other methods.

 

The JLP Flash software interface has three basic APIs:

• Copy a row of JLP flash to JLP RAM
• Copy a row of JLP RAM to JLP flash
• Erase a sector of JLP flash

That's it. Simple and relatively light-weight. Everything else gets implemented as a software layer on the Intellivision. You can make that software layer work however you like, including implementing the algorithm I described above.

 

LTO Flash! will offer an emulation of this API, only saving the data on external flash. (This allows each game to have its own private "JLP save state" area unaffected by the others.) The external flash works rather differently under the hood; however LTO Flash! will provide the same software interface and erase/write granularity, so if it works on LTO Flash! it should work on a JLP board too. That matters if you want to produce cartridges of your game.

Edited December 25, 2014 by intvnut

[First Spear]

I am missing something simple here, please help me with a clue.

 

I used IntyMapper to create two simple .txt files in CS mode using only GROM shapes. I am trying to make a "map of the world", where the world is currently two backgrounds that will be stitched together (left and right).

 

Using scroll.bas as the starter code, I took the output from IntyMapper and replaced the existing "graphics" with "gfx_lt" and "gfx_rt" and also setup the DEFINE. I noticed that the DATA statements generated show hex values and not BITMAP ops. I ignored that fact, changed the DEFINE to include my new images, displayed.... And got an all-black background with a chewed-up-looking yellow shape.

 

Around line 565 in manual.txt from IntyBASIC there is a description showing a DATA statement but I am not making the mental connection on how to adapt scroll.bas to use these statements. And I don't think it's the rum in my blood.

 

 

Thanks.

mapperleft.txt

mapperright.txt

Edited January 2, 2015 by First Spear

[freewheel]

FYI, DATA vs BITMAP is simply for human readability - they end up with the same thing in the end. You can DEFINE either, interchangeably. Although I believe there's a byte-ordering difference so be careful. Otherwise DATA is really just for compactness of source. BITMAP is just the binary representation which takes up a lot more space in your .bas.

 

Keep in mind that IntyMapper creates code intended to be used with SCREEN, not DEFINE. In fact if you're using GROM only, there's no need for DEFINE at all - DEFINE is specifically to load custom tiles into GRAM.

 

scroll.bas does not work with this sort of thing. You need to draw a column of graphics using PRINT, and refer to the tile you want for each row (I *think* you can use GROM for this, but have never tried).

 

As always, I hope people will correct me where I'm mistaken. But I think you're mixing up your tools and concepts a little. If you're trying to use SCROLL, it's not quite as simple as creating 2 full screens and scrolling between them. I mean, you can do it, but not in the way you're describing. These tools are wonderful for time saving, but you still need to have a rough grasp of how to talk to the STIC to make things appear the way you want. I suspect if you look closely enough at each DATA entry, and break it down to what you're loading into the STIC, you'll find that you're simply telling it to use a blank tile.

Edited January 2, 2015 by freeweed

[First Spear]

Thanks for clearing that up for me a bit more.

 

Well, I have two screens of background data, and want them to scroll around a "center", in that I don't want a MOB to move, I want the background to move around it. A working example would be the car in Safecracker. How is that done in IntyBASIC?

 

 

Thanks.

 

FYI, DATA vs BITMAP is simply for human readability - they end up with the same thing in the end. You can DEFINE either, interchangeably. Although I believe there's a byte-ordering difference so be careful. Otherwise DATA is really just for compactness of source. BITMAP is just the binary representation which takes up a lot more space in your .bas.

 

Keep in mind that IntyMapper creates code intended to be used with SCREEN, not DEFINE. In fact if you're using GROM only, there's no need for DEFINE at all - DEFINE is specifically to load custom tiles into GRAM.

[snip]

[freewheel]

Thanks for clearing that up for me a bit more.

 

Well, I have two screens of background data, and want them to scroll around a "center", in that I don't want a MOB to move, I want the background to move around it. A working example would be the car in Safecracker. How is that done in IntyBASIC?

 

If I'm reading you right, you're basically looking at creating a playfield that is 40x12 tiles, that wraps around itself horizontally.

 

Start with scroll.bas, and comment out/delete the entirety of the "scroll upward" and "scroll downward" sections. The framework nanochess lays out is very slick and adaptable - you really only have to look at 2 parts: one, the code that says "now I scroll" (which he controls via timers, and you probably want to control via controller input), and two, the actual drawing of the new column of background. Which he calls clear_column. You're going to need to expand this PROC a fair bit. Oh, and you can discard the extra PRINT of \257 at a random location, that's just to add some texture to his sample program.

 

In clear_column, all he's doing is printing GRAM card 0 over and over again (\256), through all 12 rows of a given column. You need to adapt your code to do that. This is tricky and also very easy once you get the right pattern down. If you're using GROM cards only, first make sure you know how to print the appropriate GROM card. Check the STIC register format for the appropriate encoding. Lemme do this in hex values and hopefully it makes sense. Let's use a var, cardnum, to indicate the GROM card you wanna select at a given position. Keep in mind that PRINT just accepts "any" numeric value so you can do all sorts of fun math here. It's incredibly flexible if a bit obtuse at first. What you're going to end up with is something like this:

 

For basic GROM cards, where you're only using the first 8 foreground colors:

PRINT AT ROW*20+COL,(cardnum*+color

If you want the "higher" 8 colors, just add $1000 to the math at the end. If you need to advance the color stack, add $2000 to set the appropriate bit.

 

If both, you can save time and just add $3000. Also, The $1000, $2000, $3000 can also be done via variables depending on how fancy you want to get. You can combine the $1000 and color, for example, into a single 16 bit variable #color and simply add that guy in. A lot of the guys create CONSTs for these as well, just to avoid "magic numbers" in your code. It just depends on your style. Tarzilla has an excellent layout for this.

 

If this isn't 100% clear, break down those hex values into binary and compare to the STIC register values, and you'll see which bits I'm selecting. Just make sure you don't accidentally set bit 11 or you'll be looking at GRAM (been there, done that). The *8 is just to shift the bits over by 3, incidentally.

 

With that done, the only tricky part is to know what the hell to use for cardnum. And that's fairly easy, but there are a lot of ways to do it. My thinking? Don't think of your background as "screens". Think of it as columns of cards/tiles. And all you're doing as you scroll is selecting the next column, either to the left or the right as appropriate. You'll need to store your data somehow. You could conceivably read it all into RAM as a huge array - you're talking about a pretty small world here, 480 cards in total. Or read it from DATA statements on the fly. It depends on how much work/flexibility you're looking for.

 

One simple, if inefficient way (which is fine in terms of ROM space) would be DATA $0015, $0212, $0023... etc where each value corresponds to the appropriate GROM card. Use each DATA line to represent a column:

 

background1: DATA $0212,$0022... $0062 (you can put 10 values per DATA statement which is the number of rows, happy coincidence)

background2: DATA $0012,$0095... $0013

.

.

.

background40: DATA $0011,$0056... $0022

 

You have to turn it around 90 degrees in your head

 

Now, the logic to call this would be .. ugly. I know of another IntyBASIC program that uses this method but it's called infrequently, to set up a level. To handle scrolling, you'd need 40 IF statements which will bog down your scrolling and probably cause MOB jitter (speaking from experience here). The rest of the gang has MUCH better ideas than this, I'm just throwing out a very rudimentary concept. Get this working, and you're 90% there. A better idea:

 

If you want to keep using your IntyMapper DATA statements, that's probably doable, and I suspect you'd just PRINT AT ROW*20+COL,cardval and the color etc would be already encoded in the DATA value. Remember, no DEFINE needed (for those). Just keep in mind that the DATA statements are ordered by row, and with horizontal scrolling you're only drawing a column at a time. So you'll need to be clever Here's where READ comes in (and potentially ugly math).

 

RESTORE sets a pointer for your next READ, and you'd READ cardval to get the appropriate value for PRINT. You could in theory just RESTORE to the "beginning" of our data every time you want to READ a value, and traverse your DATA that way. ie: you start with value 0, loop until you hit the value you want, then actually PRINT that to the screen. You determine where to stop based on the current ROW*COL value. Or, you could break the data up into rows (like I had with background1...40 above) and then you only need to loop through a single row to get to the appropriate column value. And there are surely even better, simpler ways of doing this.

 

What I don't know is if IntyBASIC has the ability to play with the RESTORE pointer via math tricks. Ideally RESTORE label+ROW*COL would be extremely useful. Under the covers, the hardware allows this kind of addressing but I have no idea if it's been implemented. I seem to recall we had a discussion on something similar a few months ago but I can't remember where or what the final solution was.

 

Beyond that, you need to watch out to make sure you don't start wrapping into negative value land (ie: if you're on column 0 and need to draw a column to the left, the column should be set to 39 and not 255), and also make sure you're using 16 bit variables when needed (depends on what you do here - personally I'd keep rows and columns separate but you could in theory just use a variable that allows 0-479).

 

 

 

Now - this will either be extremely confusing, overly complicated, and difficult to read, in which case I apologize. Or it might point you in the right direction. What you're wanting to do isn't terribly difficult, once you "get it". Really just a handful of lines of code. But it's tricky to get it written down and working the first time. It's the kind of thing that I'll spend several hours on, and at the end slap myself for not figuring it out faster. Because it's less than a dozen lines of code most likely.

Edited January 2, 2015 by freeweed

[intvnut]

What I don't know is if IntyBASIC has the ability to play with the RESTORE pointer via math tricks. Ideally RESTORE label+ROW*COL would be extremely useful. Under the covers, the hardware allows this kind of addressing but I have no idea if it's been implemented. I seem to recall we had a discussion on something similar a few months ago but I can't remember where or what the final solution was.

 

IntyBASIC has ON .. GOTO, right? It's a bit piggy on codesize, but you could do something like this to get an "ON .. RESTORE":

.

             ON column GOTO set_col0, set_col1, set_col2, set_col3, ... 

set_col0:    RESTORE col0_data : GOTO draw_column
set_col1:    RESTORE col1_data : GOTO draw_column
set_col2:    RESTORE col2_data : GOTO draw_column
set_col3:    RESTORE col3_data : GOTO draw_column
...

draw_column:   ... code to draw column here ...

col0_data:   DATA ...
col1_data:   DATA ...
col2_data:   DATA ...
col3_data:   DATA ...
...

.

But that's if you really want to use READ statements to get the data. You could also just use PEEK and POKE. (Works best if you store your data as actual formatted background characters.) Something along these lines:

.

        REM assume left column; 
        REM right column should be similar, just with a different screen address (531 instead of 512)

        D_ADDR = data_table + col * 12  : REM address of the data to display
        FOR I = 0 TO 11 
            POKE 512 + I * 20, PEEK( D_ADDR + I )
        NEXT I

Edited January 2, 2015 by intvnut

[freewheel]

Both good ideas. I still haven't played much with ON..GOTO so I haven't put much thought into how well it reads nor efficiency. It's certainly a better idea than my first stab at 40 IF statements

 

PEEK/POKE is something us oldschool BASIC guys just did all the time - but it's really left the BASIC space. So I often forget we can use it. It's definitely a useful idea here.

[intvnut]

Both good ideas. I still haven't played much with ON..GOTO so I haven't put much thought into how well it reads nor efficiency. It's certainly a better idea than my first stab at 40 IF statements

 

PEEK/POKE is something us oldschool BASIC guys just did all the time - but it's really left the BASIC space. So I often forget we can use it. It's definitely a useful idea here.

 

I have a feeling the PEEK/POKE approach will end up giving the tightest code (both size and speed) if your background map data consists of already-formatted words. The ON..GOTO simulating a supposed ON..RESTORE is likely going to be a size pig, both in the source and in the compiled result, and somewhat heavier on cycles.

 

BTW, I left some complex expressions in the POKE and PEEK statements, as IntyBASIC does a really good job of keeping intermediate calculations in registers. If you put intermediate values into variables, those get saved/restored from RAM, eating up a bit of your RAM space and eating up cycles. I'm not sure if I made the right tradeoff with the computation for D_ADDR, but I'm pretty sure I did with 512 + I*20.

 

It's something to experiment with.

[First Spear]

Wow. And wow. Many re-reads in the making here.

 

I am starting with two "screens" horizontally, but ultimately I want about 30 screens high and 40 screens wide (reason why I'm trying to use ROM for the shapes to minimize RAM use).

 

Thanks. I am sinking more and more time into this.... A very worthwhile distraction from my regular "life stuff"!

[freewheel]

I am starting with two "screens" horizontally, but ultimately I want about 30 screens high and 40 screens wide (reason why I'm trying to use ROM for the shapes to minimize RAM use).

 

Minimize ROM usage

 

The same kinda thinking applies if you go bigger, it just means that you have to include the vertical scrolling (which is extremely similar to horizontal) and keep track of a lot more rows and columns. Realistically it's not a lot more code though, just more data in ROM to make up the levels. That's one hell of a large game world for the INTV btw!

[intvnut]

Wow. And wow. Many re-reads in the making here.

 

I am starting with two "screens" horizontally, but ultimately I want about 30 screens high and 40 screens wide (reason why I'm trying to use ROM for the shapes to minimize RAM use).

 

Thanks. I am sinking more and more time into this.... A very worthwhile distraction from my regular "life stuff"!

 

 

If you are going to do a 4-direction scroller ultimately, then you may as well store your world data in the same orientation as the display, rather than turning it sideways as freeweed and I were suggesting above. Flipping it sideways makes sense only for a horizontal scroller.

 

Also, 30 screens high x 40 screens wide is 360 x 800 tiles, or 288,000 tiles. Unless you have a procedurally generated world or some form of compression, that's going to take a ton of ROM space. It'd fit on an LTO Flash (with page flipping), but not even JLP win its current form will hold it without compression. Compression adds its own challenges.

Edited January 3, 2015 by intvnut