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

[freewheel]

Just wanted to say thanks again for the add-on hardware detection that's been coded up and/or added to IntyBASIC this year. You've made my life a lot easier. First Spear's comment about IF... THEN made me realize that I'm probably writing the most complicated/involved code about this that anyone's likely to ever bother with.

 

Oops. I've said too much.

[wolfy62]

Just wanted to say thanks again for the add-on hardware detection that's been coded up and/or added to IntyBASIC this year. You've made my life a lot easier. First Spear's comment about IF... THEN made me realize that I'm probably writing the most complicated/involved code about this that anyone's likely to ever bother with.

 

Oops. I've said too much.

Best of luck with this i am sure you will do great!

[freewheel]

Oscar, did the NTSC constant get broken in a recent release? I have the world's simplest program:

loop:
      PRINT AT 0,<3>NTSC
      GOTO loop

It displays 001 even when I use -P or --pal in the latest jzintv. Or is jzintv broken?

[+nanochess]

Oscar, did the NTSC constant get broken in a recent release? I have the world's simplest program:

loop:
      PRINT AT 0,<3>NTSC
      GOTO loop

It displays 001 even when I use -P or --pal in the latest jzintv. Or is jzintv broken?

Ouch! I'll check soon

[freewheel]

Ouch! I'll check soon

 

OK, confirmed, it's IntyBASIC. I grabbed some older code compiled with IntyBASIC from about a year ago, and it works fine with the latest jzintv. When I compile with 1.2.9, it doesn't work.

 

I looked in the prologue and didn't see any changes there, but I honestly don't know what you're doing for this so I'm no help

[+nanochess]

OK, confirmed, it's IntyBASIC. I grabbed some older code compiled with IntyBASIC from about a year ago, and it works fine with the latest jzintv. When I compile with 1.2.9, it doesn't work.

 

I looked in the prologue and didn't see any changes there, but I honestly don't know what you're doing for this so I'm no help

I'm not sure how it happened, but the value returned for the comparison of PAL mode is different. (using IntyBASIC v1.2.9 and latest jzintv 2018)

 

It's now $01bb for NTSC and $01f9 for PAL, so you should replace CMPI #520,R2 with CMPI #$01DB,R2 in intybasic_prologue.asm and it will work.

 

I'll account for this in future releases.

[freewheel]

It's now $01bb for NTSC and $01f9 for PAL, so you should replace CMPI #520,R2 with CMPI #$01DB,R2 in intybasic_prologue.asm and it will work.

 

I'll account for this in future releases.

 

Thanks, that did the trick! This isn't going to break anything else, is it? Why would earlier IntyBASIC work with the previous value? Something else in the prologue that you changed I guess?

 

Edit: I just diff'd 1.2.8 and 1.2.9. The only change you made was the MEMSET acceleration. You're not touching R2 in there, but I won't pretend to follow all the register juggling here.

[+nanochess]

 

Thanks, that did the trick! This isn't going to break anything else, is it? Why would earlier IntyBASIC work with the previous value? Something else in the prologue that you changed I guess?

 

Edit: I just diff'd 1.2.8 and 1.2.9. The only change you made was the MEMSET acceleration. You're not touching R2 in there, but I won't pretend to follow all the register juggling here.

 

I think jzintv is now more exact in the cycle counting for PAL. I don't remind modifying anything in intybasic_prologue.asm.

[freewheel]

 

I think jzintv is now more exact in the cycle counting for PAL. I don't remind modifying anything in intybasic_prologue.asm.

 

OK, on further analysis...

 

You also added a CALL CLRSCR to MAIN0. Interestingly, if I comment that out, the old value works. However, if I revert MEMSET to the 1.2.8 version, it also works with the old value. Something with these changes is what caused the problem. I don't understand nearly enough to know why.

 

Edit: Also, I noticed something. When I'm using jzintv in PAL mode, I very quickly see the Mattel EXEC titlescreen when I reset. I'm not sure if it always did that before, but thought I'd mention it.

[+DZ-Jay]

I'm not sure how it happened, but the value returned for the comparison of PAL mode is different. (using IntyBASIC v1.2.9 and latest jzintv 2018)

 

It's now $01bb for NTSC and $01f9 for PAL, so you should replace CMPI #520,R2 with CMPI #$01DB,R2 in intybasic_prologue.asm and it will work.

 

I'll account for this in future releases.

 

Would it be useful if instead of returning the counter value, you return a flag say like "TVMODE = 0" for NTSC and "TVMODE = 1" for PAL?

 

This is similar to what I do in P-Machinery. I think it is safer that way because although the actual hardware is purely deterministic, the emulator may not exactly match its timing. Also, any changes to the internal algorithm may affect the ultimate value.

 

Ultimately, what the programmer is interested in know is whether it is running in NTSC or PAL. The exact method of measuring, the cycle difference, etc. are not significant and should be abstracted.

 

-dZ.

[+DZ-Jay]

 

OK, on further analysis...

 

You also added a CALL CLRSCR to MAIN0. Interestingly, if I comment that out, the old value works. However, if I revert MEMSET to the 1.2.8 version, it also works with the old value. Something with these changes is what caused the problem. I don't understand nearly enough to know why.

 

Edit: Also, I noticed something. When I'm using jzintv in PAL mode, I very quickly see the Mattel EXEC titlescreen when I reset. I'm not sure if it always did that before, but thought I'd mention it.

 

Further on this, perhaps it's time we all extirpate the EXEC boot sequence completely. I just took the plunge last week-end with P-Machinery: hooking up at the PlayCable monitor in location $4800, hijacking the initial minimal EXEC sequence. At that point, I do all my normal start-up, but I first start by clearing all memory and resetting all devices (PSG, STIC, BACKTAB, etc.).

 

Now I see a lot less flickering and color changing when I start up or reset the emulator, including no more occasional appearances of the Mattel title screen. It looks a lot more stable, since I keep interrupts disabled and the display inactive throughout.

 

I would even recommend intvnut to add this to CART.MAC in a future update to the SDK-1600 (or I can make a patch for it).

 

It's time to take the training wheels off. Buh-bye EXEC.

 

-dZ.

[+nanochess]

Actually is only the comparison before setting the value for the programmer, only needs to check the special variable NTSC.

 

On the other side, I'll add a note in documentation that you can avoid the EXEC entirely using a single statement at start of your program:

 

SOUND 9,,$38

 

This will enable ECS support code and bypass EXEC.

[+DZ-Jay]

Actually is only the comparison before setting the value for the programmer, only needs to check the special variable NTSC.

 

On the other side, I'll add a note in documentation that you can avoid the EXEC entirely using a single statement at start of your program:

 

SOUND 9,,$38

 

This will enable ECS support code and bypass EXEC.

 

But does it initialize the system or just jumps from there to programmer's code? The idea is not only to bypass the EXEC, but to replace its boot up sequence. Otherwise, every program will have to have boiler-plate code to clear the screen and reset the STIC, etc.

 

-dZ.

[+nanochess]

But does it initialize the system or just jumps from there to programmer's code? The idea is not only to bypass the EXEC, but to replace its boot up sequence. Otherwise, every program will have to have boiler-plate code to clear the screen and reset the STIC, etc.

 

-dZ.

It cleans everything, just Yesterday I checked and the only things it doesn't initialize are the scroll offset registers and added the pertaining code.

[+DZ-Jay]

It cleans everything, just Yesterday I checked and the only things it doesn't initialize are the scroll offset registers and added the pertaining code.

Awesome!

 

By the way, I am curious to know if you have a reason not to do this automatically by the prologue.asm. Do you see a use case that needs to keep the EXEC boot sequence?

[+nanochess]

Awesome!

 

By the way, I am curious to know if you have a reason not to do this automatically by the prologue.asm. Do you see a use case that needs to keep the EXEC boot sequence?

Just my hard-to-machineness, I still want be able to make programs using only $5000 to $6fff in case I make my own cart PCB ?

[+DZ-Jay]

Just my hard-to-machineness, I still want be able to make programs using only $5000 to $6fff in case I make my own cart PCB ?

Gotcha. Would it be worth making that the option?

 

I'm just thinking that a simpler setup and interface for programmers is always better.

[+nanochess]

Gotcha. Would it be worth making that the option?

 

I'm just thinking that a simpler setup and interface for programmers is always better.

Yep, it's worth it because in the case of a missing cfg file, the bin still works.

 

I know. It's kind of crazy. But that is me

[+DZ-Jay]

Yep, it's worth it because in the case of a missing cfg file, the bin still works.

 

I know. It's kind of crazy. But that is me

 

LOL! I meant if it made sense to make the "bypass EXEC" the default behaviour and "use $5000 - $6FFFF" the optional condition -- But yeah, it's your platform, so you do what you think is best.

 

-dZ.

[First Spear]

Should that now be set as mandatory for all "normal" IntyBASIC programs? Enable the ECS just in case it is connected, and always bypass the EXEC since it can never be used?

 

 

 

 

Actually is only the comparison before setting the value for the programmer, only needs to check the special variable NTSC.

On the other side, I'll add a note in documentation that you can avoid the EXEC entirely using a single statement at start of your program:

SOUND 9,,$38

This will enable ECS support code and bypass EXEC.

[+nanochess]

Should that now be set as mandatory for all "normal" IntyBASIC programs? Enable the ECS just in case it is connected, and always bypass the EXEC since it can never be used?

 

 

 

 

 

Now it looks like a good idea.

[freewheel]

Is there no way to use colored squares mode in IntyBASIC? I don't think I've ever tried it.

 

Oh wait, is it just color stack mode, and you set bit 12 on a card? Does that mean you can mix and match the modes?

[+nanochess]

Is there no way to use colored squares mode in IntyBASIC? I don't think I've ever tried it.

 

Oh wait, is it just color stack mode, and you set bit 12 on a card? Does that mean you can mix and match the modes?

 

Yes, just set color stack mode, set bit 12 and clear bit 11 in card. This means also you don't have access to GROM cards with "high" colors.

[freewheel]

 

Yes, just set color stack mode, set bit 12 and clear bit 11 in card. This means also you don't have access to GROM cards with "high" colors.

 

Yeah, I've already had to define my own GRAM cards to do that I just never intentionally tried colored squares before!

[+DZ-Jay]

Is there no way to use colored squares mode in IntyBASIC? I don't think I've ever tried it.

 

Oh wait, is it just color stack mode, and you set bit 12 on a card? Does that mean you can mix and match the modes?

 

Yes, on both counts: You can "mix and match" Color Stack and Colored Squares modes. The reason is that "Colored Squares" is not really a screen mode per se, it's a "mode" on a card in Color Stack.

 

Like nanochess said, this "feature" limits the use of color in GROM cards in Color Stack mode, since setting the "pastel" color bit turns the card into "Colored Square" mode.

 

-dZ.