Jump to content
nanochess

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

Recommended Posts

 

I suppose I was using an old version of jzintv. So far everyone can change in intybasic_prologue.asm the 415 to 520 as suggested by intvnut.

 

Also, I failed to note this: You also have to invert the sense of the branch that follows:

        CMPI #520,R2  ; <- new threshold
        MVII #1,R0
        BLE _MAIN3    ; <- was BGE, now is BLE
        CLRR R0
_MAIN3: MVO R0,_ntsc

What's weird is that I specifically used the --pal flag and the NTSC value to calibrate timing in Desert Bus, and it worked flawlessly. Down to within about 3 seconds when simulated out to 8 hours! Now I'm really confused... the timing code came from an example by intvnut, but I can't see you taking into account IntyBASIC's "minor issue".

 

Weird.

 

It's entirely possible I was still updating the display at 60Hz... Did you try an animation test? :-) I seem to recall my early --pal support was basically junk.

Edited by intvnut

Share this post


Link to post
Share on other sites

 

It's entirely possible I was still updating the display at 60Hz... Did you try an animation test? :-) I seem to recall my early --pal support was basically junk.

 

It's been a while. What I do remember is that I set up the timing, benchmarked it to an 8 hour run, and then set --pal. And it was all messed up (faster or slower, I can't even remember that much). I then added the IntyBASIC check for NTSC, adjusted my timing accordingly, and it worked like a charm with --pal.

 

If you remember: it was a dead-simple counter that just checks the FRAME count, and if it goes over 50/60 (as appropriate), increments the number of seconds. Like I said, it was dead accurate over 8 hours so it at least adjusted for the CPU speed properly.

 

I really should test this out with the current IntyBASIC and the year-old version I first wrote it in, that may help Oscar.

Share this post


Link to post
Share on other sites

If you remember: it was a dead-simple counter that just checks the FRAME count, and if it goes over 50/60 (as appropriate), increments the number of seconds. Like I said, it was dead accurate over 8 hours so it at least adjusted for the CPU speed properly.

 

Or at least the refresh rate. I believe for awhile I had had the NTSC CPU clock rate for both, and just changed the refresh interval. Or something. All I know is that the PAL numbers were jacked up in the older versions.

Share this post


Link to post
Share on other sites

 

Or at least the refresh rate. I believe for awhile I had had the NTSC CPU clock rate for both, and just changed the refresh interval. Or something. All I know is that the PAL numbers were jacked up in the older versions.

 

Oh. Riiiiiiight. I always assume that the CPU and the refresh rate are tied together, but I guess that's not necessarily the case. Which means audio is an open question.

 

I'll run a bunch of tests next time I'm stationary for a bit. There are a surprising (to me) number of PAL users here; I'd hate to see homebrew that isn't inclusive.

Share this post


Link to post
Share on other sites

 

Oh. Riiiiiiight. I always assume that the CPU and the refresh rate are tied together, but I guess that's not necessarily the case. Which means audio is an open question.

 

I'll run a bunch of tests next time I'm stationary for a bit. There are a surprising (to me) number of PAL users here; I'd hate to see homebrew that isn't inclusive.

 

Just to confuse things worse: in jzIntv, I can control the CPU MHz, PSG MHz and refresh rate separately. I think I was getting 2 of the 3 correct. The only real way you'd notice the CPU MHz was wrong was with a timing loop such as what IntyBASIC uses.

 

What really boggles me is that the timing loop that's there expects fewer iterations for PAL than for NTSC, but every aspect of the PAL system would give you more iterations. The slower refresh interval gives you more time between interrupts (which means more iterations). The faster CPU gives you more iterations per second regardless of the refresh interval.

 

Anyway, find your old version of Desert Bus that you timed for 8 hours on jzintv --pal and let's look at it. We can even look at a disassembly if needed, or at least use jzIntv's debugger to watch it in action.

Share this post


Link to post
Share on other sites

OK no, the problem is IntyBASIC. I just compiled with 1.1, and it detects PAL just fine. 1.2.4, seems to not notice it. Obviously something changed, I'll see if my feeble brain can find it. The section in the prologue is identical, but something has to have changed somewhere. Is it maybe just not checking for the NTSC const properly? In fact, how DOES this magic actually work?:

 

IF NTSC = 1 THEN print at 0,"ntsc" ELSE print at 1,"pal"

 

I'm never defining NTSC anywhere. I assume the compiler has it hard-coded; maybe that part got commented out.

 

Here are the ROM, ASM, and LST files from 1.1 and 1.2.4. I'm literally doing nothing but calling the above line in an infinite loop. I ran a diff between the .asm files, and I see absolutely nothing that clues me in. The vast majority of the changes are in bug fixes in the math routines, and JLP support. So I'm way out of my depth. Maybe you guys can figure this out.

pal_test_111_vs_124.zip

Share this post


Link to post
Share on other sites

And I'm finally understanding more about how each PSG register is being used. Oscar, I think you have a typo:

SOUND 4,[NOISE 6 bits],[MIX]      Noise and mix register ($38 value by default)

According to the PSG documentation that I can find, there are only 5 bits on that register. Which my testing seems to confirm - once I go over 31, it seems to wrap back 0.

 

I also want to figure out a better way to explain how the MIX register works. We may need a lookup table because active-low tends to be confusing to people:

 

$38 turns on all 3 tones, and disables all noise. $7 would be just noise. $0 turns on noise AND tones for all 3 channels. $63 means complete silence for all 3. And every mix in between.

 

Or better yet, change how the syntax works. Maybe something like SOUND 0,value,volume,mix, where mix is 0=silence, 1=tone, 2=noise, 3=both? To me it makes more sense to control the mixer on a per-channel basis like this. SOUND 4 would then just take a single (5-bit) value for noise.

 

Thoughts?

 

I'm only just starting to figure out how the envelope generator works, but I'll get there. Already coming up with some trippy stuff.

  • Like 1

Share this post


Link to post
Share on other sites

According to the PSG documentation that I can find, there are only 5 bits on that register. Which my testing seems to confirm - once I go over 31, it seems to wrap back 0.

Yep! Noise is a 5 bit register and common to all channels.

 

$63 means complete silence for all 3.

Its $3F for silence on tones and noise for all 3. Even the "Your friend the EXEC" manual gets that wrong :lol:. Bits 6 and 7 have to be zero or you'll stop the controllers from working.

 

I'm only just starting to figure out how the envelope generator works, but I'll get there. Already coming up with some trippy stuff.

You can get even more interesting results by modulating the channel volume.

Share this post


Link to post
Share on other sites

You can get even more interesting results by modulating the channel volume.

 

I agree, especially because it allows you to control the envelope for each channel individually. That said, I do like that the built-in envelope generator can serve as a sort of LFO amplitude modulator with various waveforms.

Share this post


Link to post
Share on other sites

Its $3F for silence on tones and noise for all 3. Even the "Your friend the EXEC" manual gets that wrong :lol:. Bits 6 and 7 have to be zero or you'll stop the controllers from working.

 

 

I have absolutely no idea where $63 came from. However yes, it would disable one of the controller ports. Whoops! :lol:

Share this post


Link to post
Share on other sites

And I'm finally understanding more about how each PSG register is being used. Oscar, I think you have a typo:

SOUND 4,[NOISE 6 bits],[MIX]      Noise and mix register ($38 value by default)

According to the PSG documentation that I can find, there are only 5 bits on that register. Which my testing seems to confirm - once I go over 31, it seems to wrap back 0.

 

I also want to figure out a better way to explain how the MIX register works. We may need a lookup table because active-low tends to be confusing to people:

 

$38 turns on all 3 tones, and disables all noise. $7 would be just noise. $0 turns on noise AND tones for all 3 channels. $63 means complete silence for all 3. And every mix in between.

 

Or better yet, change how the syntax works. Maybe something like SOUND 0,value,volume,mix, where mix is 0=silence, 1=tone, 2=noise, 3=both? To me it makes more sense to control the mixer on a per-channel basis like this. SOUND 4 would then just take a single (5-bit) value for noise.

 

Thoughts?

 

I'm only just starting to figure out how the envelope generator works, but I'll get there. Already coming up with some trippy stuff.

 

Thanks for the report, I'll correct it.

 

BTW, I'm sure you're meaning $3F instead of $63 ;)

Share this post


Link to post
Share on other sites

Apparently he converted hexadecimal to decimal but forgot to remove the dollar, as $3F = decimal 63.

 

That is amazing if so - I don't usually make that kind of mistake. The only time my brain sees decimal values of registers is when I output them to the screen, which I definitely wasn't doing here. I'm atrocious at doing hex <-> dec in my head, so I generally just stick to hex and binary values for things.

 

Maybe my subconscious is smarter than I think (but still not quite smart enough).

Share this post


Link to post
Share on other sites

Is there any technical document about how to code the intellivoice?

It would be nice having commands in intybasic to fully control intellivoice e.g. with custom samples.

Edited by artrag

Share this post


Link to post
Share on other sites

Is there any technical document about how to code the intellivoice?

It would be nice having command in intybasic to fully control intellivoice e.g. with custom samples.

 

This is a very large can of worms :)

 

There are the basic voice samples that you can easily use in IntyBASIC, of course. Custom samples need to be encoded very specifically to work with the Intellivoice. Information on how to do it is out there, sort of. But it's non-trivial. You'd also have to add your voice data to intybasic_epilogue.asm, but that's reasonably easy:

 

_OY:

DECLE _OY.end - _OY - 1

DECLE $0310, $014C, $016E, $02A6, $03AF, $00CF, $0304, $0192

DECLE $03CA, $01A8, $007F, $0155, $02B4, $027F, $00E2, $036A

DECLE $031F, $035D, $0116, $01D5, $02F4, $025F, $033A, $038A

DECLE $014F, $01B5, $03D5, $0297, $02DA, $03F2, $0167, $0124

DECLE $03FB, $0001

_OY.end: ; 34 decles

 

Just define your sound/word, and insert the voice data with a unique label, and it should work?

 

At least *some* people have tools to help with this - I believe the Elektronite guys have an encoding program. But they don't tend to put their tools out there for just anyone to use. And the encoding is the (very) hard part.

Share this post


Link to post
Share on other sites

 

Where do I find docs on what the data are?

They should be the 12 coefficients of a linear filter. Usually in this kind of systems you can also specify the pulse in input.

Share this post


Link to post
Share on other sites

Where do I find docs on what the data are?

They should be the 12 coefficients of a linear filter. Usually in this kind of systems you can also specify the pulse in input.

 

The technical specs and information on instruction set and usage are available in the SDK-1600 distro that includes jzIntv.

Share this post


Link to post
Share on other sites

I've stopped development of IntyBASIC for more or less 3 months but now finally I've restarted with some "minor" modifications that will shape IntyBASIC at large:

 

New in version 1.2.5:

  • Added UNSIGNED statement, allows to make unsigned comparisons (useful for larger than 16-bits values) ;)
  • Added PLAY VOLUME statement (do you want to make music softer?) ;)
  • Added NO DRUMS syntax to PLAY (allows to use noise channel for explosions)
  • Added MUSIC JUMP statement (allows to have an intro in music and a looping part)
  • Added MUSIC.PLAYING expression (allows to exit when music has finished playing)
  • Added CALL statement (like USR but outside expressions so you don't need a variable)
  • DATA allows for string literal (for text programs)
  • DO statement followed by colon now isn't taken as label.
  • Corrected bug in PAL detection.
  • Updated constants.bas (corrections and new constants for Coloured Squares mode) and keypad.bas sample.
  • Added contrib/ColouredSquares.bas a sample of drawing lines in Coloured Squares mode by GroovyBee.
  • Added samples/bats.bas (animated bats)
  • Added samples/envelope.bas (using envelope sounds)
Enjoy it! ;) (see first post)
  • Like 5

Share this post


Link to post
Share on other sites

Finally getting around to looking at MUSIC JUMP. I imagine it's used for this:

PLAY intro_label

intro_label: MUSIC A3,-,-,-
             more notes

main_music: MUSIC C3,-,-,-
            more notes

MUSIC JUMP main_music

So that you can have an intro, then loop the body of the music. And I assume that MUSIC REPEAT serves no purpose here, because you'll forever loop due to the JUMP statement..?

 

How possible would it be to have something like MUSIC JUMP, but a bit more selective? Like this:

PLAY song_label

song_label:  MUSIC A3,-,-,-
             more notes

MUSIC LOOP song_label,2

'rest of the music goes here
             MUSIC C3,-,-,-
             more notes


So that I could loop over the first section twice, then continue on with the rest. Ideally allowing a counter for how many times to loop.

 

Right now I just duplicate a lot of MUSIC statements to accomplish this, which isn't a big deal given the available ROM size, but still. Can something like this be done?

  • Like 3

Share this post


Link to post
Share on other sites

I think this is a bug in the manual, in the area discussing PRINT:

 

 

For Foreground/Background mode, use $0000-$0007, and $0200 is bit 0 of background
color, $0400 is bit 1 of background color, $1000 is bit 2 of background color
and $2000 is bit 3 of background color. (check MODE statement below)

 

I think bit 2 and bit 3 are reversed here. Both from what I know, plus explicit testing. I had this backwards at some point too, so I wonder if there's a STIC guide out there with the wrong register details.

  • 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.

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