IntyBASIC & Memory Mapping Problem - help!

[freewheel]

I think I finally made a game big enough that I need to use my brain a bit more. Here's the current .cfg that's produced by as1600:

 

[mapping]
$0000 - $000D = $4800
$000E - $100D = $5000
$100E - $1772 = $6000
$1773 - $2672 = $8100
$2673 - $3672 = $9000
$3673 - $3F4F = $A000
$3F50 - $4E4F = $C100
$4E50 - $57D4 = $D000

This crashes jzintv.

 

I thought I was using safe address spaces but obviously I'm doing something wrong. Right now I'm only using ASM ORG $8100 and ASM ORG $C100 - until now I've been managing this correctly.

 

I thought that $5000 - $6FFF, $8100 - $BFFF and $C100 - $FFFF were totally safe to use, and I don't see that I'm overflowing these ranges.

 

Am I being stupid here? Do certain parts of my code need to reside in certain addresses?

[intvnut]

Have you tried running it in the debugger to see where you crash?

 

If you turn on register history (h), jzIntv will write a dump of the last 64K instructions that executed. That usually gives a gigantic hint of where things went off the rails.

[intvnut]

And for the record, I don't see anything immediately wrong with this memory map.

[GroovyBee]

What command line flags are you invoking jzintv with? Are you telling it to enable the ECS and you aren't using the JLP flag?

[freewheel]

EDIT: Sigh.

 

Double sigh.

 

It's possible to ORG to the same address multiple times in IntyBASIC, and it doesn't throw an error. It just causes really, really bizarre behaviour.

 

My scroll wheel is a bit sensitive so occasionally it middle-click pastes something in a very, very bad spot. Sorry for the annoyance guys - but thanks for the sanity check!

 

I'm surprised that neither the compiler nor assembler complains about this - should they?

[GroovyBee]

At least you found it in the end. Perhaps IntyBASIC needs some kind of separate Lint like tool?

[intvnut]

The assembler allows this on purpose to allow for certain code generation tricks.

 

It may be possible to add a warning when you assemble over previously assembled code. I don't want to make it illegal, however, as it's too useful. I probably need a way to say "I'm doing this on purpose."

 

The main thing I use it for is pre-filling the ROM with fixed data, and then overwriting that with program code. I also have the occasional macro that "goes back" and patches up some code at the end of assembly.

 

Anyway, I'm glad you figured it out.

[intvnut]

Regarding a lint-check in BASIC (missed that suggestion when looking from my cell phone): FWIW, ASM ORG I believe is currently 'invisible' to IntyBASIC, in that ASM statements are verbatim copied to the assembly output. I suppose you could add a ORG keyword to the language, which would at least allow IntyBASIC to understand your intent; however, I don't think it keeps track of assembly addresses, so it's really the wrong layer to implement a check for this.

 

Probably the longer term solution for IntyBASIC is to teach it about memory maps, so that ASM ORG disappears entirely from IntyBASIC. That is, once IntyBASIC gets smart enough to do the necessary tracking to correctly check ASM ORG statements, it's not that much harder to just have it handle the whole address map itself.

[+Tarzilla]

Regarding a lint-check in BASIC (missed that suggestion when looking from my cell phone): FWIW, ASM ORG I believe is currently 'invisible' to IntyBASIC, in that ASM statements are verbatim copied to the assembly output. I suppose you could add a ORG keyword to the language, which would at least allow IntyBASIC to understand your intent; however, I don't think it keeps track of assembly addresses, so it's really the wrong layer to implement a check for this.

 

Probably the longer term solution for IntyBASIC is to teach it about memory maps, so that ASM ORG disappears entirely from IntyBASIC. That is, once IntyBASIC gets smart enough to do the necessary tracking to correctly check ASM ORG statements, it's not that much harder to just have it handle the whole address map itself.

For people new to IntyBASIC, especially those that can't think in HEX or DECLs, the memory map is a common tripping point. Trying to explain how looking at the .LST file and looking to see if something doesn't fit with the ASM ORG statements can be difficult. Someone with more time could probably write a command line tool or Excel macro to process the LST and produce an color coded listing showing red where it is out of the selected map. I think we all agree that a new statement on the first line of an IntyBASIC program called MEMORYMAP=X where X equal one of several predefined maps and have IntyBASIC handle the ASM ORG's would be the best thing. I know it is on Oscar's long list.

[freewheel]

Thanks again for the input guys. I just panicked because I had one of those "wait, do I actually not have a goddamn clue what I'm doing??" moments.

 

I agree, it'd be great if IntyBASIC handled this internally, but it's obviously a fair bit of work because we've been discussing this for over a year. Until such time as it does, some kind of tool would be super handy. If I wanted to do Hex in my head I'd just write in ASM I really like Tarzilla's idea of a color-coded memory map - that'd be slick. I'm surprised this doesn't come up more often, to be honest.

[intvnut]

Well, it's not color coded, but 'cart.mac' does provide the ability to summarize the overall memory map and it will tell you if you've overflowed a section. And since you never use 'ORG' statements with cart.mac, freewheel's error wouldn't have happened. Instead, cart.mac adds a "ROMSEG" directive that switches code generation between ROM segments, and it keeps track of how full each segment is. A mis-pasted ROMSEG may still result in a crash if you put it between two executable statements without a branch, but even that's solvable if you don't mind wasting a little ROM.

 

To use cart.mac, you'd need to hack intybasic_prologue.asm and intybasic_epilogue.asm slightly, and include cart.mac as part of the build.

 

It's also fairly easy to add new memory maps to cart.mac.

 

Maybe I'll grab the latest IntyBASIC and throw together a more recent proof-of-concept. I did this once several months ago. Perhaps it's time to revisit it.

[intvnut]

Ok, I did a quick conversion of IntyBASIC to cart.mac again, and wrote up an example based on the existing 42K.BAS example in the contrib folder. When you assemble this example, you'll get a summary from the assembler:

$ as1600 -o 40k_cartmac.bin -l 40k_cartmac.lst 40k_cartmac.asm 
=================================================================
          Program size:        $0375 (885 dec) words
          ROM available:       $9A8B (39563 dec) words
-----------------------------------------------------------------
       Range    Start    End           :     Used    Avail
         0:     $5000 - $6FFF          :    $026F    $1D91
         1:     $8100 - $BFFF          :    $0084    $3E7C
         2:     $C100 - $FFFF          :    $0082    $3E7E
=================================================================
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

If I did everything correctly, the assembler will put all of the library code in intybasic_epilog.asm into the ROM segments where there's room, automatically. No more "leaving some room in the last segment" trickery.

 

To change ROM segments, you just insert the statement "asm ROMSEG x", where x is 0, 1 or 2, to start assembling in that segment. You can switch ROM segments as often as you like; the ROMSEG directive keeps track of how full each segment is, and won't assemble over any existing code.

 

And, if you overflow the memory map, you'll get an error at assembly time, rather than a silent crash.

 

This is an update to an earlier tweak I had made of this form. This time, I used IntyBASIC 1.2.5 as my base, so you should be able to drop in these files on a fresh IntyBASIC 1.2.5 folder and start experimenting.

 

All this is released to the public domain / free for everyone to use for whatever purpose. It can be extended to other memory maps, better integrated in IntyBASIC and so on. This is just a good starting point. :-)

 

Please, try it and let me know how it works for you.

 

EDIT: The version I posted originally had a big bug that broke 8 bit variables. This version should correct it. Please download again if you've downloaded it already.

intybasic_cartmac.zip

Edited March 21, 2016 by intvnut

[intvnut]

NOTE: The version I posted earlier had a big bug that broke 8 bit variables. If you downloaded this a few minutes ago, please download the fix above. Thanks.

[First Spear]

 

Because my work-in-progress had/has a lot of Words, I wrote a C# console app to count the DATA statements and then move sections of text and decorate sections with ASM ORG to fit the code in the different location to leave use the default region for the actual program code. But I am using a lot of data, I don't see that as priority-necessary for most games at all.

 

 

At least you found it in the end. Perhaps IntyBASIC needs some kind of separate Lint like tool?

[GroovyBee]

Because my work-in-progress had/has a lot of Words, I wrote a C# console app to count the DATA statements and then move sections of text and decorate sections with ASM ORG to fit the code in the different location to leave use the default region for the actual program code. But I am using a lot of data, I don't see that as priority-necessary for most games at all.

 

I wouldn't expect a Lint like tool to hack up a developer's source code. Its a tool that applies a stricter level of warning/error checking over and above the normal checking IntyBASIC does. It would be up to the developer to manually fix problematic code, or to temporarily turn off that check around the code with issues (as is appropriate).

[First Spear]

I am with you on that homey. See my post from August 2015 - http://atariage.com/forums/topic/242011-intybasic-de-linter-consideration/- and you have posted on the topic as well in the past. We are on the same page.

 

I understand the difference between a delinter and a code-hacking tool, I was just making the statement that going beyond delinting is probably not necessary and that to really use all of the memory effectively, some serious text manipulation has to happen.

 

 

 

I wouldn't expect a Lint like tool to hack up a developer's source code. Its a tool that applies a stricter level of warning/error checking over and above the normal checking IntyBASIC does. It would be up to the developer to manually fix problematic code, or to temporarily turn off that check around the code with issues (as is appropriate).