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

[artrag]

Another feature request: could you extend the use of DATA PACKED to numeric constants? Now it works only with strings, but often the data to be stored do not need 16 bits and storing them with DATA PACKED in single bytes would give a huge rom saving.

 

It should come from free reusing the code for strings. Maybe you could just add a compile time check giving a warning message if some constant in DATA PACKED statements is larger than 255 or smaller than -128

Edited February 17, 2018 by artrag

[artrag]

Oscar, I've another feature request about the PLAY command.

 

At the moment, the volume of the music can be changed dynamically using

 

PLAY VOLUME x

 

Implementing this command costs CPU time because you have to scale, frame by frame, the channel volumes. Moreover all the channels get the same volume.

It is good to fade in or fade out the music, but it does not add flexibility to the music player because you cannot change the volume of a given note on a channel and costs extra CPU cycles.

 

My proposal is to extend the MML syntax with a volume modifier to be used in the MUSIC command

 

The volumes could be changed note by note, channel by channel, and all the processing would be done at compile time, avoiding the processing needed for changing the volume on fly.

(Naturally if you use PLAY VOLUME, like now, you need the scaling code anyway).

 

A tentative proposal could be Vn with n in 0-15 to be used with a note o a sustain symbol.

E.g.

label: DATA 8 ' Ticks per note (there are 50 ticks per second)

MUSIC V15F4,V10A4#,V10C5 ' here volumes are 15,10,10

MUSIC S,S,S ' here volumes stay 15,10,10

MUSIC V10S,V7S,V7S ' here volume are 10,7,7

Naturally, also instruments and drums can be scaled at compile time, even if they include modulation of volume.

I do not know how you have defined them so I do not know what would be the coding effort to add this flexibility, but it should be doable.

[carlsson]

I wonder how much it takes to include and integrate e.g. Arnauld's tracker as a binary module to an IntyBASIC program. Some of the RAM space might need to be reserved of course, but if the intent is to have very advanced music playing, I would consider that approach instead of extending the IntyBASIC MUSIC syntax greatly, which I consider more for simple jingles and alike.

[artrag]

Well, it should be evaluated. If possible I would even suggest to integrate a pt3 player whose tracker is the VortexTrackerII for Windows

It is here https://bulba.untergrund.net/vortex_e.htm and it is specific for AY8910/AY8912 audio chips

 

Its player is in z80 asm and should be ported to CP1610

Edited February 23, 2018 by artrag

[+nanochess]

I'm afraid PT3 uses a >LOT< of memory for its tables.

 

These are the things I'm considering for next version of music player:

 

* MUSIC GOSUB/MUSIC RETURN for creating easily patterns. (one level deep)

* MUSIC SPEED for changing speed during playing. (less memory consumption)

* Extending MUSIC to 8 channels (to account for ECS) or creating a PLAY ECS label statement, so two separate players.

* MUSIC WAVEFORM to change shape of instrument (volume, frequency, exponential adjust)

* MUSIC VOLUME to change volume of music, to create decay of music, or increase like in electronic music.

 

I can go more free over 8 bits variables but I need to be careful about 16 bits ones, I don't want a superplayer that leaves you without 16-bit variables because it wouldn't be useful.

 

I want more things but given my consistent lack of time, I'll try to get at least 3 of these in next release.

[carlsson]

While you consider MUSIC GOSUB, you might as well want to consider MUSIC LOOP or if that should be MUSIC WHILE / MUSIC WEND.

 

By the way, if I understand Arnauld's tracker correctly, it uses 20 variables in 8-bit scratch RAM and 5 variables in 16-bit system RAM.

 

(36 + 9 in the ECS enhanced version)

Edited February 23, 2018 by carlsson

[artrag]

Question: where should I peek in ram to know if I'm using PLAY FULL or PLAY SIMPLE ?

I need this information on the ISR and I do not want to add an extra variable due to the fact it has to be possible to get this information from the music player itself

[+nanochess]

Question: where should I peek in ram to know if I'm using PLAY FULL or PLAY SIMPLE ?

I need this information on the ISR and I do not want to add an extra variable due to the fact it has to be possible to get this information from the music player itself

The variable you need is _music_mode:

 

0 = No tracker playing
2 = SIMPLE NO DRUMS
3 = SIMPLE
4 = FULL NO DRUMS
5 = FULL

Note that probably I can change this or add bits in future revisions of IntyBASIC

[artrag]

From the ASM file I cannot find the ram address,there is no memory map apparently...

Can I use the name _music_mode directly in intybasic somehow ?

 

PS

Rules in the intybasic contest mention version 1.2.9 so for now it should be fine

Edited February 26, 2018 by artrag

[+nanochess]

From the ASM file I cannot find the ram address,there is no memory map apparently...

Can I use the name _music_mode directly in intybasic somehow ?

 

PS

Rules in the intybasic contest mention version 1.2.9 so for now it should be fine

No way to use _music_mode without using ASM statement and that's not allowed by the contest.

 

But you can PEEK directly the location where it ends after assembly (check .lst file, use -l option of as1600 to generate it into a file of your choice)

 

Like this:

 

as1600 -o myprog -l myprog.lst myprog.asm

[artrag]

Ok, thanks!

[carlsson]

I wonder how many existing IntyBASIC programs would break if the mechanism MUSIC.PLAYING in the future referred to this variable instead of a pointer that is 0 when no music is playing, and constantly changing address if either of the music routines is used. I know the compiler will be status quo until after the contest, but if breakage is not expected it could be one more change for the next version.

[+nanochess]

Ok, thanks!

If you're going to send your game to IntyBASIC contest I would suggest you to assign a variable everytime you use PLAY FULL or PLAY SIMPLE.

 

This way the code would be portable to future revisions of IntyBASIC

[artrag]

Thanks for the suggestion, I will it will taken into account as a such

[carlsson]

While discussing DATA statements, I just imagined a bit of syntactic sugar: "BDATA" which takes data bytes and the compiler rearranges pairs of these into 16-bit words in little (?) endian order. It would be an alternative to BITMAP when importing graphics data. Today you can already use DATA but then your graphics data needs to be swapped around in word order.

[artrag]

About the same of my proposal to have the command data packed to store bytes in word

Edited March 16, 2018 by artrag

[artrag]

Another thing I would like to propose is variable aliases.

 

How could you face the depletion of 16 bit ram?

 

Easy: reuse the same variables in different subroutines (provided that you do not need to keep the game state in them across different iterations). The side effects are that you cannot use meaningful names for reusable variables, unless you are very lucky.

The possible solution is to define alias names for different valuables aiming to the very same ram area.

 

The compiler could be made complex at will by analyzing the usage of variables and coverage map of the procedures finding by itself what can be overwritten, but in its simplest implementation you only need to add a keyword alias to make two variables overlap in ram and leave the management of collisions to the coder.

[artrag]

Maybe a dull question.

I'm computing a bit mask for testing COLX for a given events

How do I do powers of 2 in intybasic ?

 

m = 2^n

 

It seems that ^ is not supported, I could solve with an array of bit masks but I wanted just to be sure that this is the sole way.

 

PS

Maybe an operator to shift bit positions could be more efficient and would allow things like this (COLX>>n) and 1

Edited March 28, 2018 by artrag

[+DZ-Jay]

Maybe a dull question.

I'm computing a bit mask for testing COLX for a given events

How do I do powers of 2 in intybasic ?

 

m = 2^n

 

It seems that ^ is not supported, I could solve with an array of bit masks but I wanted just to be sure that this is the sole way.

 

PS

Maybe an operator to shift bit positions could be more efficient and would allow things like this (COLX>>n) and 1

 

I don't think there's an exponent operator, but multiplication and divisions by powers of two is optimised with shifts, and modulus is optimised with ANDed bitmasks.

 

I agree that perhaps adding support for "^" maybe useful. I don't know about adding a shift operator -- it was never part of any BASIC I remember.

 

-dZ.

[GroovyBee]

Maybe a dull question.

I'm computing a bit mask for testing COLX for a given events

Just use HIT_SPRITE0 to HIT_SPRITE7 from constants.bas

[artrag]

Ok, this is for constants

How if n is a variable?

 

My code tests collision of a given sprite plane with a set of enemies

Edited March 28, 2018 by artrag

[GroovyBee]

Just add the masks you need together or am I missing something?

[artrag]

I have a subroutine with N as parameter

Without computing 2^n on COL2>>N and 1 you need an array of precomputed values of powers of 2

[carlsson]

I believe DZ-Jay is correct about shift operators traditionally haven't been part of BASIC. It seems that modern versions of BBC BASIC support it, as well as various other modern dialects including Visual BASIC, but not really in the 8-bit era (if we pretend the Intellivision belongs in that era, despite it is 16 bit). I checked other fairly advanced ones like Locomotive (Amstrad CPC), MSX and Microworld (Microbee) but didn't get conclusive results.

 

Even so, IntyBASIC already goes beyond what many of those 1980's languages were capable of and rightfully so. I would consider it to be an effective imperative programming language modeled after the BASIC syntax rather than attempting to be ANSI compliant and that's it. Thus if bitwise operators are not very expensive to implement in machine code, I'd agree that a future version might as well support those.

[GroovyBee]

An array will be far faster than a power function.