IntyBasic - using PRINT AT for background images

[tuatara21]

I have been using the following statement to print certain background objects on the screen in my game for the IntyBasic contest.

 

in this example, I am placing a "wall" image to cover an entryway in the castle:

PRINT AT 9, $1860

PRINT AT 10, $1860

However I am getting an error in jzintv when I attempt to execute the ROM now.

Starting jzIntv...

HALT! PC=7004 Instr = 78 MS = 62

If I comment out a handful of the PRINT AT statements, the ROM executes properly.

ROM is currently hovering between 17-18k so I wasn't sure if I was up against the limit (without bankswitching).

I have used the above PRINT AT statements elsewhere in the program and they execute as expected. The image ($1860) output is correct when I reference it in the screen [label] statement.

Please advise, perhaps there is an alternate method to perform this task.

[intvnut]

The issue is that your game has gotten too big to function as on contiguous piece of code. It's nothing specifically to do with PRINT AT.

 

A quick, simple solution might be to add this at the very beginning of your program. The BASIC programming compo folks will have to say whether this violates any of the rules: (Since it's just an ORG statement, I think it's OK.)

.

'       Make this the first few lines of your program:
        GOTO Start
        ASM ORG $C040
Start:  WAIT

.

This will roughly double the amount of space you can use for your program before size becomes an issue. If you need to go larger than that, it's doable. You need to use more ASM ORG statements, usually between Procedures, if you're using Procedures. Right now you're at about 16K bytes (8K words), but with just two ORG statements you could go to ~80K bytes (~40K words).

 

All that said, with your existing program, you might consider ways of making it smaller. If you have a lot of PRINT AT statements that are doing largely similar things, is are there ways you can use loops, for example, to reduce repetitive code, and maybe some arrays or clever uses of RESTORE/DATA/READ?

[tuatara21]

Thanks for the quick response! I will give that a try. I already implemented a number of loops and a few other tricks to consolidate the code. I'm sure there is more optimization that I can do but trying to squeeze in a few more features before the contest ends :-)

[+Tarzilla]

The issue is that your game has gotten too big to function as on contiguous piece of code. It's nothing specifically to do with PRINT AT.

 

A quick, simple solution might be to add this at the very beginning of your program. The BASIC programming compo folks will have to say whether this violates any of the rules: (Since it's just an ORG statement, I think it's OK.)

.

 

'       Make this the first few lines of your program:
        GOTO Start
        ASM ORG $C040
Start:  WAIT

.

This will roughly double the amount of space you can use for your program before size becomes an issue. If you need to go larger than that, it's doable. You need to use more ASM ORG statements, usually between Procedures, if you're using Procedures. Right now you're at about 16K bytes (8K words), but with just two ORG statements you could go to ~80K bytes (~40K words).

 

All that said, with your existing program, you might consider ways of making it smaller. If you have a lot of PRINT AT statements that are doing largely similar things, is are there ways you can use loops, for example, to reduce repetitive code, and maybe some arrays or clever uses of RESTORE/DATA/READ?

ASM ORG is the only ASM statement allowed for the contest. There is also a sample 42k.bas file that shows more usage of ASM ORG.

[intvnut]

ASM ORG is the only ASM statement allowed for the contest. There is also a sample 42k.bas file that shows more usage of ASM ORG.

 

Ok, thanks for the confirmation. I figured since ORG isn't actual code, it's just allowing you to fit more BASIC in, that it should be allowed.

 

 

Thanks for the quick response! I will give that a try. I already implemented a number of loops and a few other tricks to consolidate the code. I'm sure there is more optimization that I can do but trying to squeeze in a few more features before the contest ends :-)

 

My pleasure! I know the fuse is burning down quickly on the contest, and that's literally the quickest and easiest fix I could think of.

 

The reason your code crashed is that it crossed the boundary from $6FFF to $7000 in the Intellivision memory map. The Intellivision looks for the Keyboard Component (or ECS) at $7000, and if it sees something that looks like program code there, it'll jump directly to $7000, bypassing the rest of your program. Your program rightly got confused, and everything went pear-shaped.

 

And if you're wondering what my suggested code does: It moves most of your program to the address range $C040 - $FFFF. That's 16K words (32K bytes) of contiguous memory with very few restrictions. The code generated by the compiler is very simple too: It's just a simple branch from the code at $5xxx to the new spot at $C040:

.

        ;FILE c040.bas
        ;[1]         GOTO Start
        SRCFILE "c040.bas",1
        B Q3
        ;[2]         ASM ORG $C040
        SRCFILE "c040.bas",2
 ORG $C040
        ;[3] Start:  WAIT
        SRCFILE "c040.bas",3
        ; START
Q3:             CALL _wait

.

You don't necessarily need a WAIT there, any BASIC statement would do. I just used WAIT as it's benign.

Edited December 29, 2015 by intvnut

[tuatara21]

perfect, that worked like a charm!! Thanks again!!

[+Tarzilla]

Another thing you could do is put ASM ORG $C040 command a couple of lines above the Print statements that were causing you grief, that would push all successive code into the 32 k block as stated, however the gotcha is if you add any code above the ASM org $c040 you will be constantly moving the ASM org "up" through you code. Joe's suggestion is probably the best considering the short timeframe. Nanochess does have intelligent, compiler based ASM ORGing on his list of future features.

[intvnut]

Another thing you could do is put ASM ORG $C040 command a couple of lines above the Print statements that were causing you grief, that would push all successive code into the 32 k block as stated, however the gotcha is if you add any code above the ASM org $c040 you will be constantly moving the ASM org "up" through you code. Joe's suggestion is probably the best considering the short timeframe. Nanochess does have intelligent, compiler based ASM ORGing on his list of future features.

 

Yeah, I was going for the quick-hit, which doubles the available space in 3 lines. If you're right on the boundary and the deadline is just a couple days away, that seems most prudent.

 

If you've divided your code up nicely into procedures and data tables, then you can play around with packing them nicely into different pockets of memory. That's definitely more involved, though.

[fsuinnc]

The issue is that your game has gotten too big to function as on contiguous piece of code. It's nothing specifically to do with PRINT AT.

 

A quick, simple solution might be to add this at the very beginning of your program. The BASIC programming compo folks will have to say whether this violates any of the rules: (Since it's just an ORG statement, I think it's OK.)

.

'       Make this the first few lines of your program:
        GOTO Start
        ASM ORG $C040
Start:  WAIT

.

This will roughly double the amount of space you can use for your program before size becomes an issue. If you need to go larger than that, it's doable. You need to use more ASM ORG statements, usually between Procedures, if you're using Procedures. Right now you're at about 16K bytes (8K words), but with just two ORG statements you could go to ~80K bytes (~40K words).

 

All that said, with your existing program, you might consider ways of making it smaller. If you have a lot of PRINT AT statements that are doing largely similar things, is are there ways you can use loops, for example, to reduce repetitive code, and maybe some arrays or clever uses of RESTORE/DATA/READ?

 

Man, I wish I was better at keeping track of all the conversations on this board. This has been driving me crazy for the past couple of weeks. Add a simple line to my program and suddenly it doesn't work. I figured it was a size limit thing but wasn't sure how to get around it. (all I could think to do was thoroughly read documentation and instructions and that just wasn't going to happen).

 

very happy I found this. Thanks to all!

[GroovyBee]

Man, I wish I was better at keeping track of all the conversations on this board. This has been driving me crazy for the past couple of weeks. Add a simple line to my program and suddenly it doesn't work. I figured it was a size limit thing but wasn't sure how to get around it. (all I could think to do was thoroughly read documentation and instructions and that just wasn't going to happen).

 

You could have just asked for help instead . Honestly, there is no shame in that. Us more seasoned programmer types want you to have fun making your games. If you have problems beyond the IntyBASIC compiler its always good to look in the final *.lst file for your game and search for the words "ERROR" and "WARNING" and then ask how to fix these critical issues.

[fsuinnc]

 

You could have just asked for help instead . Honestly, there is no shame in that. Us more seasoned programmer types want you to have fun making your games. If you have problems beyond the IntyBASIC compiler its always good to look in the final *.lst file for your game and search for the words "ERROR" and "WARNING" and then ask how to fix these critical issues.

 

Thanks. I try to look around for answers and/or figure things out on my own before posting my questions and I try stay up on the conversations here in Inty programming section, especially the IntyBASIC stuff. Everyone is so great about helping that I want to make sure I put in the effort before posting so I don't become a pest. The title on this thread threw me off and I hadn't looked at it.

 

Thanks again. Even the tip the .lst file is helpful.

[GroovyBee]

Thanks. I try to look around for answers and/or figure things out on my own before posting my questions and I try stay up on the conversations here in Inty programming section, especially the IntyBASIC stuff. Everyone is so great about helping that I want to make sure I put in the effort before posting so I don't become a pest. The title on this thread threw me off and I hadn't looked at it.

Yep! Putting the effort in, to find the solution yourself, is a good approach because you learn much more from your own mistakes, in my experience. I always like to see "First I tried this...." and "then this..." type questions (even better if source code is shown) because it means the OP is motivated to get a solution to their problem and not do a "cut and paste" job.

 

Thanks again. Even the tip the .lst file is helpful.

Glad to help!

[PuzZLeR]

Actually I learned just from reading other people's questions when outlined properly.

 

I would like to start a thread of my own IntyBASIC questions. The reason is that I'd prefer not to burden the forum with a dozen tiny questions. Or would the latter be more appropriate protocol?

[GroovyBee]

I would like to start a thread of my own IntyBASIC questions. The reason is that I'd prefer not to burden the forum with a dozen tiny questions. Or would the latter be more appropriate protocol?

The best thing to do would be to ask questions in your game development thread in my opinion. Questions are typically game specific so it makes sense to do it there.

[PuzZLeR]

The best thing to do would be to ask questions in your game development thread in my opinion. Questions are typically game specific so it makes sense to do it there.

 

Cool. Makes sense then since it will also add context.