Jump to content
IGNORED

Program does not compile any more.


PuzZLeR

Recommended Posts

You've all been so kind and helpful, and again I reach out for a little rescuing.

 

My program suddenly stopped compiling. What I mean is that regardless of any change I make in the code now, it still outputs the same result. I can change a "BLUE" to a "YELLOW", or select this instead of that, and the same result keeps outputing, from the last good compile, with no change. No errors, but no change.

 

I do notice the run window now runs longer. Hmmmm.

 

I am in the hopes that some of you have seen this before and immediately know what to do. So, I ask, what is the first thing I should look at?

 

Is the program getting too big? (The ROM is now 41KB.) Do I need to play around with the ORG statement? I did and either it didn't help, or I didn't do it right.

 

Any other clues what I should check? I can upload code, or an LST file, or whatever you feel should be investigated.

 

Thanks again my friends.

Link to comment
Share on other sites

Chances are good that your program has either spilled into an address range such as $7xxx, which requires special handling, or one part of your program ended up overlapping another part of your program.

 

It's not clear from your message, however, whether:

  • IntyBASIC fails to compile your BAS file into an ASM file.
  • AS1600 fails to assemble your ASM file into a BIN+CFG (or .ROM).
  • jzIntv fails to run the resulting BIN+CFG (or .ROM).  This includes the Intellivision starting up, but going "of in the weeds" / "CPU crashed".

Knowing what to do next depends on which step is failing.

  • Like 1
Link to comment
Share on other sites

Hi intvnut, thanks for responding. Hopefully this may help you (or anyone else) help me.

 

The following worked fine in the CLI window:

intybasic input.bas output.asm

 

Then the following:

as1600 -o output.bin -l output.lst output.asm

Resulted in:

 

ERROR SUMMARY - ERRORS DETECTED 1430
              -   WARNINGS      0  

   

To give you an idea what caused this for me. (Using hypothetical code.)

 

The following code fragment, although was logically wrong in not giving me the result I wanted, compiled and ran just fine with 0 errors detected.

 

if avatar_y_pos<  enemy_y_pos then enemy_y_pos=enemy_y_pos-1
if avatar_y_pos>= enemy_y_pos then enemy_y_pos=enemy_y_pos+1
if avatar_x_pos<  enemy_x_pos then enemy_x_pos=enemy_x_pos-1
if avatar_x_pos>= enemy_x_pos then enemy_x_pos=enemy_x_pos+1

When I tried to change it to the following, by entering some code before each line (pretend the function is called about 10 times and the parameters are different numbers) then the problem began:

 

goNorthFunction(par1,par2) and goNorthFunction(par3,par4) and goNorthFunction(par5,par6) <"etc, etc"> and enemy_y_pos>8   then if avatar_y_pos<  enemy_y_pos then enemy_y_pos=enemy_y_pos-1
goSouthFunction(par1,par2) and goSouthFunction(par3,par4) and goSouthFunction(par5,par6) <"etc, etc"> and enemy_y_pos<96  then if avatar_y_pos>= enemy_y_pos then enemy_y_pos=enemy_y_pos+1
goWestFunction(par1,par2)  and goWestFunction(par3,par4)  and goWestFunction(par5,par6)  <"etc, etc"> and enemy_y_pos>8   then if avatar_x_pos<  enemy_x_pos then enemy_x_pos=enemy_x_pos-1
goEastFunction(par1,par2)  and goEastFunction(par3,par4)  and goEastFunction(par5,par6)  <"etc, etc"> and enemy_y_pos<160 then if avatar_x_pos>= enemy_x_pos then enemy_x_pos=enemy_x_pos+1

That's the only change I made, just trying to make the sprites move according to a certain way, and these functions have been used many, many times throughout the program before without any problems.

 

Hopefully this helps.

 

Link to comment
Share on other sites

When the total of error quantity is so big, I'm pretty certain that you exceeded the addressing space through $FFFF.

 

I would suggest to remove any ASM ORG statement to check if errors disappear, check your generated .CFG file, and start adding again some ASM ORG statements.

  • Like 1
Link to comment
Share on other sites

Hi Nanochess. Thanks for chiming in.

 

Yes, that high number is a horror show! ?

 

I'm suspecting it's the ASM ORG statements I'm using that are causing the problem as my program is growing. I do need the ASM ORG $A000 statement in there otherwise the program won't run, but will play around with the others and report back.

 

(The ROM is currently over 40KB now, but I put in ASM ORG $A000 a little while ago when the ROM got to about 17KB or 17.5KB to keep it working.)

 

I will be back soon. Thanks again.

  • Like 1
Link to comment
Share on other sites

My tip of asm org is the $5000-6FFF to be the boot/main game loop.  Asm org $A000-$BFFF procedure, and $C100 and up for graphic/data table. The other 3 segment $2000, $7100 and $4800 are extra if you want to stuff title screen or more data into those segments.

The .cfg that compile with .bin tell you where the segments are and the size.  I usually do manual calculation via calculate to tell more how big a segment are and document that into the source code.

example:
'$2000 - 0/4095 decle
'$5000M- 6143/8191 decle
'$7100 - 0/3839 decle
'$A000A- 6143/8224 decle
'$c100 - 13055/16127 decle
'$4800 - 0/2047

  • Like 1
Link to comment
Share on other sites

Hi Kiwi. Thanks for responding.

 

I see you have knowledge about this from other posts too, but I am still learning it, and still studying the sample 42k.bas.

 

Below is a simplified idea of my Main file, which "includes" my other content and code in other files. Currently I'm only using ASM ORG $A000.

 

Any tips from you or others?


 

include "constants.bas"

goto start_of_program
asm org $A000
start_of_program: wait

wait
stack_check
wait

wait
play volume 15
play full
wait
play tune_intro
wait

REM Title Screen:

title_screen_control_1:
<"print title screen text">

if (CONT.LEFT+CONT.RIGHT+CONT.UP+CONT.DOWN)=0 then goto title_screen_control_1

play none
sound 0,1,0
sound 1,1,0
sound 2,1,0
sound 4,1,$38

cls

wait
define DEF00,16,gramchars1
wait
define DEF16,16,gramchars2
wait
define DEF32,16,gramchars3
wait
define DEF48,16,gramchars4
wait

<"some initialized variables">

SCREEN level_01_cards

gameloop:
for i=1 to 240
wait
gosub <"this procedure">
gosub <"that procedure">
gosub <"another procedure">
next i
goto gameloop

include "game_procedures_01_sprites.bas"
include "game_procedures_02_movement.bas"
include "game_procedures_03.bas"
include "game_sfx.bas"
include "game_data.bas"
include "game_screens.bas"
include "game_cards_gfx.bas"
include "game_music.bas"

 

Link to comment
Share on other sites

6 minutes ago, PuzZLeR said:

Below is a simplified idea of my Main file, which "includes" my other content and code in other files. Currently I'm only using ASM ORG $A000.

The cartridge start address is at $5000 so without ASM ORG, it is default to segment $5000. So something like,

 

include "constants.bas"

goto start_of_program
start_of_program: wait

wait
stack_check
wait

wait
play volume 15
play full
wait
play tune_intro
wait

REM Title Screen:

title_screen_control_1:
<"print title screen text">

if (CONT.LEFT+CONT.RIGHT+CONT.UP+CONT.DOWN)=0 then goto title_screen_control_1

play none
sound 0,1,0
sound 1,1,0
sound 2,1,0
sound 4,1,$38

cls

wait
define DEF00,16,gramchars1
wait
define DEF16,16,gramchars2
wait
define DEF32,16,gramchars3
wait
define DEF48,16,gramchars4
wait

<"some initialized variables">

SCREEN level_01_cards

gameloop:
for i=1 to 240
wait
gosub <"this procedure">
gosub <"that procedure">
gosub <"another procedure">
next i
goto gameloop
ASM ORG $A000
include "game_procedures_01_sprites.bas"
include "game_procedures_02_movement.bas"
include "game_procedures_03.bas"
ASM ORG $C100
include "game_sfx.bas"
include "game_data.bas"
include "game_screens.bas"
include "game_cards_gfx.bas"
include "game_music.bas"

I moved the ASM ORG $A000 to before, include "game_procedures_01_sprites.bas" and ASM ORG $c100 before include "game_sfx.bas". This is where it would set since data takes the most segment. 

  • Thanks 1
Link to comment
Share on other sites

Hi again. Couldn't report back till now (still was experimenting, work, Real Life, yaddy-yah...).

 

Good news. My program runs and compiles just fine now, by shifting ASM ORG $A000 lower in the code. Thanks Kiwi.

 

Bad news. With ASM ORG $C100 placed where Kiwi suggested, or other places I've experimented with, I get a stack overflow. Something is funky on my end.

 

I would say, no problem, as long as the program keeps growing and compiling without issue I'm good. I don't need ASM ORG $C100... yet. But now my ROM is over 50kb, and I'm getting concerned.

 

Any suggestions?

 

(This is also concerning in that I have yet to put any title screen graphics, music, sound effects, etc!  Yikes! ?  Maybe I should start a thread on managing ROM size, either with more efficient code, or with better use of ORG.)

Link to comment
Share on other sites

7 hours ago, PuzZLeR said:

Hi again. Couldn't report back till now (still was experimenting, work, Real Life, yaddy-yah...).

 

Good news. My program runs and compiles just fine now, by shifting ASM ORG $A000 lower in the code. Thanks Kiwi.

 

Bad news. With ASM ORG $C100 placed where Kiwi suggested, or other places I've experimented with, I get a stack overflow. Something is funky on my end.

 

I would say, no problem, as long as the program keeps growing and compiling without issue I'm good. I don't need ASM ORG $C100... yet. But now my ROM is over 50kb, and I'm getting concerned.

 

Any suggestions?

 

(This is also concerning in that I have yet to put any title screen graphics, music, sound effects, etc!  Yikes! ?  Maybe I should start a thread on managing ROM size, either with more efficient code, or with better use of ORG.)

With the JLP memory map (which is supported by the LTO Flash! and jzIntv), your program can use up to 42K (that's "K" as in "Kilo Words" not "Kilo Bytes").

 

The only problem, as you have encountered, is that those 42K are scattered in segments of various sizes across the memory map.  However, by allocating your code and data to different segments, as others have suggested with the "ORG" statement, it's not really such a big trauma to spread your program throughout.

 

Personally,  I wouldn't worry too much about that until after you reach another limit.  50 KB is merely 25K out of 42K.

 

By the way, there is no magic to "ASM ORG."  All it does is tell the assembler "start putting the following code and data at address $XXXX," which presumably is another memory segment with free space available.

 

Like Kiwi said, the default is putting everything on the "main" segment at $5000, which is only about 8K (that's 16 KB).

 

One common memory map used is this:

 Segment      Range     Size
--------- ------------- ----
    0     $5000 - $6FFF  8K
    1     $A000 - $BFFF  8K
    2     $C040 - $FFFF 16K
    3     $2000 - $2FFF  4K
    4     $7100 - $7FFF  4K
    5     $4800 - $4FFF  2K
--------- ------------- ----
                        42K

As your program gets bigger we could help figuring out how to split it and where to fit it.

 

    dZ.

  • Thanks 1
Link to comment
Share on other sites

Don't forget to give a look to the generated CFG and LST files as it will tell you on what memory areas is spilling your program.

 

For example, in the LST file search for ASM ORG (IntyBASIC source code is intermixed with assembler code), and see how changes the address at the left.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Hey thanks guys. Useful info.

 

Tell you what. Since - currently - I am experiencing no problems, I will continue as is. I will keep watching the LST and CFG files in the meantime.

 

When, or if, I am experiencing such problems again as my program grows I will chime back in this thread, and upload said files if it helps. Nevertheless, even without problems I will report back with my progress if I was able to figure out something on my own - in case this will help someone else in the future.

 

Thanks again! ?

Link to comment
Share on other sites

I don't know your coding style, but generally it would be a good idea to have all code in one place and all data (graphics, music, levels etc) in another place, instead of interleaving the two with graphics and subroutines a little everywhere. I think it makes arranging the segments easier. Without outing anyone, I've seen IntyBASIC examples of both styles.

Link to comment
Share on other sites

2 hours ago, carlsson said:

I don't know your coding style, but generally it would be a good idea to have all code in one place and all data (graphics, music, levels etc) in another place, instead of interleaving the two with graphics and subroutines a little everywhere. I think it makes arranging the segments easier. Without outing anyone, I've seen IntyBASIC examples of both styles.

That's typically what I do and would recommend it.  Since in my own programs the data (graphics, lookup tables, music, etc.) tends to be larger than the code, I aim to put data in the largest segments, which allows me to limp along without having to worry about the rest for a lot longer.

 

    dZ.

Link to comment
Share on other sites

I'm a bit confused by the legal memory ranges, and am hoping some of you could shed more light.

Not sure if I should have started a new thread, but it seems on topic for this one.

 

I'm attempting to write a game with IntyBASIC.  At some point it got so large it crashed, and I just added an "ASM ORG $D000"

in one spot, to avoid spanning the $7000 address.  That made the crash go away, though I never dug any deeper to see why.

At some later time, I took out that ASM ORG, and voila, it began to work again.  But then after some more changes, it crashes again.

 

The "bad" .cfg file contains

 

[mapping]
$0000 - $2CFF = $5000

 

while the "good" one has

 

[mapping]
$0000 - $1EFF = $5000
$1F00 - $2CFF = $D000
 

The reason I'm confused is that the jzintv memory_map.txt document says this about available memory ranges:

 

$5000 - $5014  ROM ok.  RAM ok only if boot ROM at $7000 or $4800.

$5015 - $6FFF  RAM/ROM ok.
$7000          ROM ok if no ECS.  RAM at $7000 confuses EXEC boot sequence.
$7001 - $77FF  RAM/ROM ok if no ECS.
$7800 - $7FFF  ROM ok if no ECS.  Do not map RAM here due to GRAM alias

 

I'm not adding any RAM, and not using ECS, so I assume my program is all ROM (except of course

for the variables IntyBASIC allocates in 8-bit scratch ram and 16-bit system ram).  Thus it would seem safe

to let it span the range $5000 thru $7CFF.

 

And there appear to be some games out there that do span this range ($5000 .. $7FFF),

for example Congo Bongo, Defender, Dig Dug and PacMan, to name a few.

 

Is my memory map OK, and I just need to look for the problem elsewhere?

Or is there something not quite right about my understanding of $7000.

 

Link to comment
Share on other sites

18 minutes ago, Peripheral said:

I'm a bit confused by the legal memory ranges, and am hoping some of you could shed more light.

Not sure if I should have started a new thread, but it seems on topic for this one.

 

I'm attempting to write a game with IntyBASIC.  At some point it got so large it crashed, and I just added an "ASM ORG $D000"

in one spot, to avoid spanning the $7000 address.  That made the crash go away, though I never dug any deeper to see why.

At some later time, I took out that ASM ORG, and voila, it began to work again.  But then after some more changes, it crashes again.

 

The "bad" .cfg file contains

 

[mapping]
$0000 - $2CFF = $5000

 

while the "good" one has

 

[mapping]
$0000 - $1EFF = $5000
$1F00 - $2CFF = $D000
 

The reason I'm confused is that the jzintv memory_map.txt document says this about available memory ranges:

 

$5000 - $5014  ROM ok.  RAM ok only if boot ROM at $7000 or $4800.

$5015 - $6FFF  RAM/ROM ok.
$7000          ROM ok if no ECS.  RAM at $7000 confuses EXEC boot sequence.
$7001 - $77FF  RAM/ROM ok if no ECS.
$7800 - $7FFF  ROM ok if no ECS.  Do not map RAM here due to GRAM alias

 

I'm not adding any RAM, and not using ECS, so I assume my program is all ROM (except of course

for the variables IntyBASIC allocates in 8-bit scratch ram and 16-bit system ram).  Thus it would seem safe

to let it span the range $5000 thru $7CFF.

 

And there appear to be some games out there that do span this range ($5000 .. $7FFF),

for example Congo Bongo, Defender, Dig Dug and PacMan, to name a few.

 

Is my memory map OK, and I just need to look for the problem elsewhere?

Or is there something not quite right about my understanding of $7000.

 

As the jzIntv document mentions, there is an issue with the lower addresses in the $7xxx space that conflicts with the EXEC boot sequence, with or without the ECS.

 

You can just skip the range from $7000 to $70FF to avoid any issues.  This is why the memory map I mentioned above separates that area into two:  $5000 - $6FFF and $7100 - $7FFF.

 

   dZ.

Link to comment
Share on other sites

Thanks for the tip, I'll avoid $7000 to $70FF going forward.

 

> As the jzIntv document mentions, there is an issue with the lower addresses in the $7xxx space that conflicts with the EXEC boot sequence, with or without the ECS.

 

I saw a bit about the ECS using this memory, but didn't see anything about

a conflict when ECS is not present.  Can you point me to the documentation

you're referring to?  thanks.

Link to comment
Share on other sites

9 minutes ago, Peripheral said:

Thanks for the tip, I'll avoid $7000 to $70FF going forward.

 

> As the jzIntv document mentions, there is an issue with the lower addresses in the $7xxx space that conflicts with the EXEC boot sequence, with or without the ECS.

 

I saw a bit about the ECS using this memory, but didn't see anything about

a conflict when ECS is not present.  Can you point me to the documentation

you're referring to?  thanks.

"RAM at $7000 confuses EXEC boot sequence."


That's the EXEC of the Master Component.

 

Edited by DZ-Jay
Link to comment
Share on other sites

6 minutes ago, Peripheral said:

"RAM at $7000 confuses EXEC boot sequence."

 

That says "RAM", which implies writability.  I thought program code and data were all ROM, no?

Sorry, you are right, but I believe that anything present on that address causes an issue during bootstrap.

 

Perhaps @intvnut can offer more details.
 

   dZ.

Link to comment
Share on other sites

4 minutes ago, DZ-Jay said:

Sorry, you are right, but I believe that anything present on that address causes an issue during bootstrap.

 

Perhaps @intvnut can offer more details.
 

   dZ.


I found this in an old thread in the IntvPROG mailing list, from Joe Z. (intvnut):

Quote

For the ROM, I first off simply ignored the ECS ROMs entirely.  The ECS ROMs are page flipped and can be disabled in early boot, so I assumed they could be (largely) ignored.  There are some hiccups, though:  If you do not have a page flipped cartridge, you cannot put ROM at $7000, and there's no way around it.  $7000 is the first place the EXEC checks at bootup, and the ECS ROM at $7000 is activated at reset time.  So, I can't put ROM at $7000.  With the Intellicart and CC3, both of which map memory in 256-word chunks, it's sufficient to start at $7100.  Punch line:  $2xxx, $7xxx and $Exxx are available if you avoid the first portion of $7xxx and "switch out" the ECS ROMs.

 

<emphasis added>

Link to comment
Share on other sites

Thanks for digging that up!

 

I'd still be curious to know why my program ran OK some of the time,

and why Congo Bongo, Defender, Dig Dug and PacMan seem to work OK.

Perhaps it depends on the actual content of the ROM in 7000 .. 70FF?

 

It's not urgent, so no need to dig further.

But, if anyone does know, I'd still be curious to learn why.

Link to comment
Share on other sites

Isn't every cartridge (or at least each publisher) using its own mapping w.r.t. segments in use? In the highlight in intvnut's mail above, it mentions "page flipped cartridge". If the games you found use a such mapping, perhaps it works for those but not for the mapping model used by IntyBASIC and various modern cartridge designs?

 

Could it be so that if certain "garbage" is at $7000, the EXEC bails out and jumps elsewhere for the startup sequence, so depending on what randomly appeared there in your program, it worked automagically for a while but once you made changes and some other content ended up there, it would crash?

Link to comment
Share on other sites

1 hour ago, carlsson said:

Isn't every cartridge (or at least each publisher) using its own mapping w.r.t. segments in use? In the highlight in intvnut's mail above, it mentions "page flipped cartridge". If the games you found use a such mapping, perhaps it works for those but not for the mapping model used by IntyBASIC and various modern cartridge designs?

You need to page-flip the $7xxx range in order to use it when the ECS is available.  That's what it means.

1 hour ago, carlsson said:

Could it be so that if certain "garbage" is at $7000, the EXEC bails out and jumps elsewhere for the startup sequence, so depending on what randomly appeared there in your program, it worked automagically for a while but once you made changes and some other content ended up there, it would crash?

That is my guess too.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...