IntyBASIC compiler v1.2.9: The good things are now better!

[intvnut]

Yeah, I doubt anyone has tested an IntyBASIC game on a Sears console yet (I think there's only been one IntyBASIC game on cart so far, and the LTO Flash was just released. Let me know if I can help out somehow, if you don't have a Sears console. Desert Bus will just have to live with this as a bug for now.

 

In theory, this could also show up in jzIntv with the Sears EXEC. I'll have to try this later.

 

The Sears EXEC title screen runs with much different timing than the Mattel EXEC, because it doesn't wait for vertical retrace to draw the rest of the screen. The "Copr @ 1984 Mattel" string resides in GROM. The Mattel EXEC waits for vertical retrace to copy that string out. The Sears EXEC doesn't, because it doesn't need the string.

 

(And yes, the string in GROM has the year as 1984.)

[freewheel]

 

In theory, this could also show up in jzIntv with the Sears EXEC. I'll have to try this later.

 

 

I've been trying to figure out a way to .. um.. try this.. my EXEC ROM dumper is on the fritz though.

[freewheel]

So, one Sears EXEC ROM dump later, and a suggestion from intvnut, and I think we have a fix:

 

Simply CALL CLRSCR at the end of _MAIN in intybasic_prologue.asm. When you reset with a Sears EXEC, you get a blank green screen instead of the Mattel-esque title screen. It's not perfect, but it's such a quick flash that no one would ever notice. The only reason I noticed in the first place was the "IntyBASIC program" text. It doesn't seem to affect anything else, but I'm far from the expert on how to determine that.

 

Note: this has been tested in jzintv only, not on real hardware. That will have to wait until after PRGE. Based on what I've seen, I'm pretty sure it will be have the same way on a console.

 

Oscar, this should be considered for inclusion in the next IntyBASIC release It's a small thing, but I think it's worth fixing.

[+nanochess]

So, one Sears EXEC ROM dump later, and a suggestion from intvnut, and I think we have a fix:

 

Simply CALL CLRSCR at the end of _MAIN in intybasic_prologue.asm. When you reset with a Sears EXEC, you get a blank green screen instead of the Mattel-esque title screen. It's not perfect, but it's such a quick flash that no one would ever notice. The only reason I noticed in the first place was the "IntyBASIC program" text. It doesn't seem to affect anything else, but I'm far from the expert on how to determine that.

 

Note: this has been tested in jzintv only, not on real hardware. That will have to wait until after PRGE. Based on what I've seen, I'm pretty sure it will be have the same way on a console.

 

Oscar, this should be considered for inclusion in the next IntyBASIC release It's a small thing, but I think it's worth fixing.

 

Just updated for next IntyBASIC release Thanks!

[+DZ-Jay]

So, one Sears EXEC ROM dump later, and a suggestion from intvnut, and I think we have a fix:

 

Simply CALL CLRSCR at the end of _MAIN in intybasic_prologue.asm. When you reset with a Sears EXEC, you get a blank green screen instead of the Mattel-esque title screen. It's not perfect, but it's such a quick flash that no one would ever notice. The only reason I noticed in the first place was the "IntyBASIC program" text. It doesn't seem to affect anything else, but I'm far from the expert on how to determine that.

 

Note: this has been tested in jzintv only, not on real hardware. That will have to wait until after PRGE. Based on what I've seen, I'm pretty sure it will be have the same way on a console.

 

Oscar, this should be considered for inclusion in the next IntyBASIC release It's a small thing, but I think it's worth fixing.

 

I believe I had suggested this before as a fix to CART.MAC. I didn't notice about the problem with the Sears EXEC, but the Mattel title screen had a tendency of popping up uninvited sometimes when you hit refresh on the regular console and the emulator.

 

In P-Machinery I have it like this (the macros should be self-explanatory):

                ; --------------------------------------
                ; Configure the cartridge ROM header
                ;       (Universal Data Block)
                ; --------------------------------------
                .CORE.SetPC(MEMMAP.RomHeader)           ; ROM Header: $5000
                BIDECLE _rom.null0                      ; $5000  MOB picture base        (points to NULL(0) list)
                BIDECLE _rom.null0                      ; $5002  Process table           (points to NULL(0) list)
                BIDECLE %startaddr%                     ; $5004  Program start address
                BIDECLE _rom.null0                      ; $5006  Background picture base (points to NULL(0) list)
                BIDECLE _rom.null1                      ; $5008  GRAM pictures           (points to NULL(1) list)
                BIDECLE _rom.title                      ; $500A  Cartridge title/date
                DECLE   $03C0                           ; $500C  Skip ECS, run code after title, no clicks
_rom.null0:     DECLE   $0000                           ; $500D  Screen border control
                DECLE   $0000                           ; $500E  0 = color stack, 1 = f/b mode
_rom.null1:     DECLE   1,1,1,1,1                       ; $500F  Initial color stack 0 and 1: Blue (color #0)

          LISTING "prev"

                ; --------------------------------------
                ; Set title
                ; --------------------------------------
_rom.title:     __rom_adjust_copyright(%year%)          ; $5014  Copyright year

                STRING  STR.FromSymbol(%title%), 0      ; $5015  Game program title

          LISTING "on"

                ; --------------------------------------
                ; Start the bootstrap sequence:
                ;   hijack the EXEC's title sequence,
                ;   clear the screen, and wait for the
                ;   next ISR so that we can take over
                ;   and keep the display disabled.
                ; --------------------------------------
_rom.start:     SCREEN.ClearAll
                ISET    _rom.init, Disable
                SPIN                                    ; Wait for VBLANK interrupt
_rom.init:      CLRSTK                                  ; Exit ISR context (clear the stack)

          LISTING "prev"

                ; If the ECS is not required just jump to the start address
            IF (.DEV.UseEcs = PM.FALSE)
                B       %startaddr%
            ELSE

[Kiwi]

Now I remember the 2nd question. How do you use function with arguemental variable. Like if I wanted to spawn an enemy in a game for example, I would use SpawnEnemy(enemytype,x,y); in C.

 

One work around I do for Intybasic is to prep the variable first and then spawn the enemy.

 

For example,

enemytype=1:x=52:y=52:gosub SpawnEnemy.

 

I notice def fn, but not really sure if I can do what I wanted written above.

[intvnut]

Now I remember the 2nd question. How do you use function with arguemental variable. Like if I wanted to spawn an enemy in a game for example, I would use SpawnEnemy(enemytype,x,y); in C.

 

One work around I do for Intybasic is to prep the variable first and then spawn the enemy.

 

For example,

enemytype=1:x=52:y=52:gosub SpawnEnemy.

 

I notice def fn, but not really sure if I can do what I wanted written above.

 

I don't think IntyBASIC supports that yet, does it?

Since all variables are global in IntyBASIC (no notion of "local scope") is there a meaningful way to define "function parameters"? I guess you could define some global variables to associate with a function's putative parameter list. Everything would still be global though.

 

In some Microsoft BASICs I've worked with (TI Extended BASIC and QBASIC come to mind), you could declare SUBROUTINEs that had parameters, and that would add a new name you could reach via CALL. e.g. CALL MYSUB(arg1, arg2, arg3) would copy the arguments to variables that were only visible within the SUBROUTINE, IIRC.

Edited October 19, 2016 by intvnut

[+nanochess]

Yep, currently no support for locals.

 

I've finished implementing three optimizations more:

1. Insertion of random NOP in the code (no, it was not A.I. but a bug in cycle counting for MVO) I've removed these.
2. Preservation of flags across instructions (mainly the Z flag), so for example (DECR R0, MVO R0,V7, TSTR R0, BNE) removes the TSTR R0.
3. This same preservation removes a CLRR R0 in many cases. (ANDI R0,#1, BNE, CLRR R0) removes the CLRR R0.

I'll be testing across all my code samples to check for wrong optimization before releasing this. These 3 optimizations combined saves normally around 20 instructions in "big" games. Although space is not so important in games, the small perfomance gains accumulate

[mmarrero]

Hi Oscar,

I found 2 minor music related bugs in IntyBasic, MUSIC JUMP causes MUSIC.PLAYING=0 for a few frames, and C7 sounds more like C0.

PLAY FULL
PLAY MySong
WHILE 1
WAIT
IF MUSIC.PLAYING=0 THEN
x=x+1:PRINT AT 0,<>x
END IF
WEND

MySong:
DATA 12
MUSIC C7W,s,s
MUSIC -,-,-

MUSIC C7X,s,s
MUSIC -,-,-

MUSIC C7Y,s,s
MUSIC -,-,-
MUSIC JUMP MySong4

MySong4:
MUSIC C7Y,s,s
MUSIC -,-,-

MUSIC REPEAT

 

 

My only other issue is not Intybasic related. When code/data lands "cross" a memory segment, .rom doesn't always crash instantly. For example, the 1st time I saw that crash, it was after the title screen. When I added code for debugging, it didn't. It then took me a while to figure the problem. Now I'm aware.

Everything else is great, especially option explicit. Thanks!

 

[+nanochess]

Thanks, just I've confirmed and corrected these.

[freewheel]

Feature request: Controller 3 and 4 support Unless it's already there and I missed it. I kinda mocked up a game and then realized I might not have 4 controller support yet

[GroovyBee]

Feature request: Controller 3 and 4 support Unless it's already there and I missed it. I kinda mocked up a game and then realized I might not have 4 controller support yet

 

Are cont3 and cont 4 not working for you?

[freewheel]

 

Are cont3 and cont 4 not working for you?

 

Well I'll be damned. Undocumented feature

 

I took a quick peek in the manual and it's not mentioned. Very cool to see that it works. Plus gives me an excuse to finally use my Flashback adapter cables.

[GroovyBee]

 

Well I'll be damned. Undocumented feature

 

I took a quick peek in the manual and it's not mentioned. Very cool to see that it works. Plus gives me an excuse to finally use my Flashback adapter cables.

 

Its been in there over a year :-

 

http://atariage.com/forums/topic/240512-intybasic-compiler-v11-the-directors-cut-;/

[freewheel]

 

Its been in there over a year :-

 

http://atariage.com/forums/topic/240512-intybasic-compiler-v11-the-directors-cut-;/

 

Yeah, I see that now. I wonder what other undocumented/experimental commands are out there that I missed, or forgot about.

[+nanochess]

 

Yeah, I see that now. I wonder what other undocumented/experimental commands are out there that I missed, or forgot about.

Woops! I never made it official but it works. No key decoding though.

[freewheel]

Woops! I never made it official but it works. No key decoding though.

 

Sure does Just checked out some code myself.

 

Joe provided me with some helpful keyboard decoding ASM a while back; let me know if you ever want help incorporating that into IntyBASIC. It works flawlessly and I've used it all over the place already. I can't do much more than test and maybe provide syntax suggestions, but I think it would be a fantastic addition to the language.

[GroovyBee]

Latest constants.bas

[GroovyBee]

Fixed point maths seems to be buggy. The following code :-

#test=1.0
#test=#test+1.5

Does not generate an adcr after the add to account for the fractional portion.

    MVII #1,R0
    MVO R0,V1
    ADDI #32769,R0    ; ERROR! There should be an "ADCR R0" after this instruction.
    MVO R0,V1

[+nanochess]

 

Fixed point maths seems to be buggy. The following code :-

#test=1.0
#test=#test+1.5

Does not generate an adcr after the add to account for the fractional portion.

    MVII #1,R0
    MVO R0,V1
    ADDI #32769,R0    ; ERROR! There should be an "ADCR R0" after this instruction.
    MVO R0,V1

 

Yep, recently I've found a lot of bugs in implementation, it is half-cooked. I'll see what I can do apart from this.

[GroovyBee]

Yep, recently I've found a lot of bugs in implementation, it is half-cooked. I'll see what I can do apart from this.

 

Probably the easiest thing to do is for the user to force the initialisation of a variable with a fixed point representation e.g.

#fred=0.0

Then the compiler knows that all arithmetic performed on the variable fred should be done with fixed point notation and emit the adcr instruction after operations.

 

Failing that, just add a new fixed point data type, perhaps an & prefix?

[+DZ-Jay]

Failing that, just add a new fixed point data type, perhaps an & prefix?

 

 

Nooooooo... I vote for the first one. Actually, I would prefer automatic "promotion" of the variables when detecting floating points in some operand within an expression, and injecting the ADCR behind the scenes, and not have the programmer even have to think about it.

 

-dZ.

[GroovyBee]

Nooooooo... I vote for the first one. Actually, I would prefer automatic "promotion" of the variables when detecting floating points in some operand within an expression, and injecting the ADCR behind the scenes, and not have the programmer even have to think about it.

Having an explicit type has more advantages because you can emit warnings when you try and do arithmetic with fixed point variables and 8/16bit integer variables, or use a fixed point type in a for loop and so on. Likewise, using % to signify 32 bits and allowing only 32 bit addition, subtraction would also allow scores to exceed 65535 easily too.

[+nanochess]

IntyBASIC SDK v1.2 coming real soon!

 

[+DZ-Jay]

Lol! No no no! I will be working on it soon, I promise.

 

I just completed two major personal projects that I had to get our of the way, and I will be free to dedicate time to the IntyBASIC SDK very soon.

 

Hopefully we'll see a release for Windows next week!