IntyBASIC SDK Feedback Request

[+DZ-Jay]

I'm working on an update to the IntyBASIC SDK to fix a few things encountered since the last release (particularly with IntySmap) and I would like to request feedback from the community and any other improvements or issues that could be addressed in the next version.

 

So, if you have any problems, complaints, suggestions, or any other comments regarding the IntyBASIC SDK, I invite you to bring them up in this thread. I won't guarantee that every little thing will be addressed, but I will promise that all feedback will be considered.

 

-dZ.

[digress]

My colours went crazy when I updated intybasic_compiler_v1.2.8. I'm going to try the older version and see if it goes away. or if it's something else happened. I tried compiliing older versions of the the project to. I'll get back w you.

 

.. so when I went back to intybasic_compiler_v1.2.7 the colours returned to normal.

[+DZ-Jay]

My colours went crazy when I updated. I'm going to try the older version and see if it goes away. or if it's something else happened. I tried compiliing older versions of the the project to. I'll get back w you.

 

What do you mean "colours went crazy"? It could have something to do with the latest "Constants.bas," some of them changed.

 

-dZ.

[digress]

same project compiled with sdk 1.0.1 or 1.1.1 default. And then I replaced it with sdk 1.0.1 and manually over wrote the intybasic bin files with 1.2.7 to get the colours back as expected.

[+DZ-Jay]

 

same project compiled with sdk 1.0.1 or 1.1.1 default. And then I replaced it with sdk 1.0.1 and manually over wrote the intybasic bin files with 1.2.7 to get the colours back as expected.

 

 

I see. It definitely looks like a colour mode issue. Could you send me the source code (privately if necessary) for me to verify? It should be really easy to fix.

 

Also, when you say you "manually overwrote the intybasic bin files," are you also updating the files in the "lib" folder?

 

And one more question, if you don't mind: Are you installing the new SDK by itself to overwrite the previous one, or are you having two installations simultaneously in a separate location? This shouldn't matter, but I suppose there could be an issue of cross-configuration, where the environment is pointing to different libraries.

 

If there is a backwards-compatibility problem with the new SDK, or if there is an issue during the "upgrade" process, then we need to address that. Thanks for bringing this up.

 

-dZ.

[digress]

sure thing, i'll send you a pm.

 

 

 

I see. It definitely looks like a colour mode issue. Could you send me the source code (privately if necessary) for me to verify? It should be really easy to fix.

 

Also, when you say you "manually overwrote the intybasic bin files," are you also updating the files in the "lib" folder?

 

And one more question, if you don't mind: Are you installing the new SDK by itself to overwrite the previous one, or are you having two installations simultaneously in a separate location? This shouldn't matter, but I suppose there could be an issue of cross-configuration, where the environment is pointing to different libraries.

 

If there is a backwards-compatibility problem with the new SDK, or if there is an issue during the "upgrade" process, then we need to address that. Thanks for bringing this up.

 

-dZ.

[+DZ-Jay]

OK, I took a look at it and it seems that the compiler/SDK changes should not have made any difference. The program is setting the screen mode to Color Stack, but drawing using FG/BG. This line seems to be set exclusively for the title screen:

MODE SCREEN_COLOR_STACK, STACK_BLUE, STACK_RED, STACK_TAN, STACK_YELLOW

However, there is not another MODE statement in the entire program, so it never changes mode. I don't see how it ever worked before, except to think that somehow your older versions of the SDK had a different value for SCREEN_COLOR_STACK, or that statement was being ignored and the default mode was FG/BG. I don't know, but my tests confirm that IntyBASIC 1.2.7 (including the old epilogue and prologue library files) compiled in exactly the same way, setting Color Stack mode and printing weird colours.

 

In other words, it never should have worked the way you intended, and I can't get it to work either with the older version of IntyBASIC.

 

For the levels, if you want to draw in FG/BG mode, just use the following line in the "DrawScreen" procedure:

MODE SCREEN_FOREGROUND_BACKGROUND

And that should fix it. If you have questions on the color modes and differences between Color Stack and FG/BG or how to use them, just post a question.

 

 

-dZ.

[digress]

This worked btw. Thanks very much. Colours are back to normal . I'll have to work on the project some more now. That really messed me up for a bit and I was trying to figure out what went wrong. I thought perhaps I had too much data in one section casusing the rom to corrupt or something.

 

I'm using this 42k template that was provided. Trying to evenly split the data and routines to different sections. Is there any hard rules about how to tell when you have too much data in one setcion such as looking at the bin file with a hex editor?

 

When I compile a coleco bankswitching cart I get a readout telling me how much kb is available still in each bank so move stuff around accordingy.

 

example:

Writing 128k megacart

# SWITCH ROM_AD COL_AD FREE NAME

= ====== ======= ====== ===== ===============

7 0xFFF8 0x00000 0xC000 4569 Bank7

6 0xFFF9 0x04000 0xC000 646 Bank6

5 0xFFFA 0x08000 0xC000 16115 Bank5

4 0xFFFB 0x0C000 0xC000 16115 Bank4

3 0xFFFC 0x10000 0xC000 11455 Bank3

2 0xFFFD 0x14000 0xC000 16114 Bank2

1 0xFFFE 0x18000 0xC000 6864 Bank1

0 0xFFFF 0x1C000 0x8000 3413 Fixed

gerry@Workstation ~/mr_turtle_f18a

[+nanochess]

 

This worked btw. Thanks very much. Colours are back to normal . I'll have to work on the project some more now. That really messed me up for a bit and I was trying to figure out what went wrong. I thought perhaps I had too much data in one section casusing the rom to corrupt or something.

 

I'm using this 42k template that was provided. Trying to evenly split the data and routines to different sections. Is there any hard rules about how to tell when you have too much data in one setcion such as looking at the bin file with a hex editor?

 

When I compile a coleco bankswitching cart I get a readout telling me how much kb is available still in each bank so move stuff around accordingy.

 

example:

Writing 128k megacart

# SWITCH ROM_AD COL_AD FREE NAME

= ====== ======= ====== ===== ===============

7 0xFFF8 0x00000 0xC000 4569 Bank7

6 0xFFF9 0x04000 0xC000 646 Bank6

5 0xFFFA 0x08000 0xC000 16115 Bank5

4 0xFFFB 0x0C000 0xC000 16115 Bank4

3 0xFFFC 0x10000 0xC000 11455 Bank3

2 0xFFFD 0x14000 0xC000 16114 Bank2

1 0xFFFE 0x18000 0xC000 6864 Bank1

0 0xFFFF 0x1C000 0x8000 3413 Fixed

gerry@Workstation ~/mr_turtle_f18a

 

 

Just list your *.cfg file after assembling and check with the 42k sample that you didn't exceed any area.

[+nanochess]

Just tested myself the SDK over Windows, and it's a delight to use, a simple command and everything goes neatly ordered.

 

Really it's an excellent way to start with IntyBASIC.

 

I would use it if I wasn't so afraid of nested folders and liking so much doing everything by hand. I know my setting is a chaos, but I'm too old to change it now

[+DZ-Jay]

Unfortunately, the only reliable way to do this at the moment in IntyBASIC programs is to look into the Listing file generated by the assembler. The SDK "IntyBuild" tool puts these in the "bin" folder of your project.

 

That file contains the entire assembled program, with the ROM address for each opcode on the left-hand margin. By subtracting the ending address from the starting address of certain sections you can tell how big they are in DECLEs.

 

In Assembly Language programs we address this by using macro directives to switch segments that automatically keep track of space used and generate usage statistics at assembly time. IntyBASIC, however, has no intelligence on the size of the instructions nor the space consumed.

 

I guess a set of user macros could be defined, similar to the ones we use in Cart.mac or P-Machinery. However, this will sort of push people towards a specific work-flow or pattern. For example, it would be necessary to pepper the code with these directives at various points for it to track segment usage.

 

dZ.

[intvnut]

I have merged cart.mac with IntyBASIC multiple times over the years and it works nicely.  Since it keeps track of how much you've used in each "ROM segment", you can issue ROMSEG directives to move pieces of code around without using fragile ORG statements.  I realize that "pushes people toward a specific work flow," but it's a workflow that not dramatically different from ASM ORG.  It's just a lot friendlier about reporting ROM size and overflows, and a lot less fragile genereally.  That, and you don't have to change the order you define things in your source file when you want to move things around physically in your ROM.

 

But, you don't need to go that far to get some basic sanity checking.  To detect basic ROM overwrite bugs, add the assembler command line flag --err-if-overwritten, or the shorter spelling -e. 

 

And if you have certain memory areas that are 100% no-go, you can add some code near the top of your BASIC program to make them off limits.  I think the following should work.  A Q&D test confirms it.

' Make $7000, $C000 off-limits.
ASM      ERR_IF_OVERWRITTEN 1
ASM _tmp QSET $
ASM      ORG  $7000
ASM      DECLE -1
ASM      MEMATTR $7000, $7000, "-RWBN"
ASM      ORG  $C000
ASM      DECLE -1
ASM      MEMATTR $C000, $C000, "-RWBN"
ASM      ORG  _tmp

 

You can get AS1600 to output a friendly, human readable memory map summary by adding --show-map or -m to the assembler command line.  For TagAlong Todd 2V, it outputs:

 MEMORY MAP SUMMARY
===========================================================
      Address Range            Size             Flags
-----------------------------------------------------------
      $5000 - $5EC2            $0EC3            R---P
===========================================================
 TOTAL INITIALIZED SIZE:  $0EC3 words

 

And if you add the overwrite checker above, you'll get additional lines in the memory map summary for those addresses.  You'll see that the flags show this area as no-read, no-write.  The additional words will not appear in the final BIN file either.

 MEMORY MAP SUMMARY
===========================================================
      Address Range            Size             Flags
-----------------------------------------------------------
      $5000 - $5EC2            $0EC3            R---P
      $7000 - $7000            $0001            ----P
      $C000 - $C000            $0001            ----P
===========================================================
 TOTAL INITIALIZED SIZE:  $0EC5 words

Only downside is that the two extra words count toward your Initialized Size that the assembler reports.

 

I suppose I could had a more general feature to the assembler to throw an error if the current address ever crosses boundaries that the programmer specifies.