Jump to content
nanochess

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

Recommended Posts

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. :P

  • Like 2

Share this post


Link to post
Share on other sites

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. :P

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

Share this post


Link to post
Share on other sites

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? :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :P

Share this post


Link to post
Share on other sites

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 :P

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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! :thumbsup:

 

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?

Share this post


Link to post
Share on other sites

Awesome! :thumbsup:

 

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 😅

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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!

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
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...