IntyBASIC v1.4.0 call for testers

[+nanochess]

Hi all.

 

I'm about to release officially IntyBASIC v1.4.0 with new features, corrections and enhancements.

 

But before doing it "officially" I need your help to check if your current programs compile with this new version of compiler and post here with your OK.

 

I've been careful but I'm trying not to release version after version because small bugs

 

Thanks!

 

Edit: for some reason I couldn't upload the ZIP here, so find it here https://github.com/nanochess/IntyBASIC/releases/tag/1.4.0

 

o Tracker allows playing 8 channels of music (using ECS PSG)

o Now detects failure of flow control when using GOTO to jump wrongly between procedures.

o Detects wrong flow of control (GOTO to PROCEDURE or GOSUB to non-PROCEDURE)

o Name mangling for assembler now uses original names, easing assembler interface.

o Support for local labels (using period character before a label, uses last global label as prefix)

o Added MUSIC GOSUB, MUSIC RETURN, MUSIC VOLUME and MUSIC SPEED.

o Added contrib/accel.bas it shows how to move sprites by fractions of pixel (contributed by intvnut)

o VOICE INIT now "shuts up" the Intellivision (contributed by intvnut) and the initializatin is done in automatic form at start of program.

o FLASH INIT SIZE to choose Flash memory size.

o Allows constants in DATA PACKED.

o Added ON expr FAST to avoid two instructions.

o Generates warnings for AND/OR/XOR and small operators non-parenthesized.

o Now direct CONT1, CONT2, CONT3 and CONT4 generate 8-bit results.

o Solved bug where IF CONT.B0 THEN wouldn't work, also ABS and SGN.

o Compatibility with Tutorvision consoles.

[artrag]

Going to try!! Thanks for the release!

[+Tarzilla]

Hi all.

 

I'm about to release officially IntyBASIC v1.4.0 with new features, corrections and enhancements.

 

But before doing it "officially" I need your help to check if your current programs compile with this new version of compiler and post here with your OK.

 

I've been careful but I'm trying not to release version after version because small bugs

 

Thanks!

 

Edit: for some reason I couldn't upload the ZIP here, so find it here https://github.com/nanochess/IntyBASIC/releases/tag/1.4.0

 

o Tracker allows playing 8 channels of music (using ECS PSG)

o Now detects failure of flow control when using GOTO to jump wrongly between procedures.

o Detects wrong flow of control (GOTO to PROCEDURE or GOSUB to non-PROCEDURE)

o Name mangling for assembler now uses original names, easing assembler interface.

o Support for local labels (using period character before a label, uses last global label as prefix)

o Added MUSIC GOSUB, MUSIC RETURN, MUSIC VOLUME and MUSIC SPEED.

o Added contrib/accel.bas it shows how to move sprites by fractions of pixel (contributed by intvnut)

o VOICE INIT now "shuts up" the Intellivision (contributed by intvnut) and the initializatin is done in automatic form at start of program.

o FLASH INIT SIZE to choose Flash memory size.

o Allows constants in DATA PACKED.

o Added ON expr FAST to avoid two instructions.

o Generates warnings for AND/OR/XOR and small operators non-parenthesized.

o Now direct CONT1, CONT2, CONT3 and CONT4 generate 8-bit results.

o Solved bug where IF CONT.B0 THEN wouldn't work, also ABS and SGN.

o Compatibility with Tutorvision consoles.

Perfect timing! I have a bunch of things to test with. Thanks!

[+nanochess]

Forgot to say the ECS player consumes more processor cycles, so you can only define 12 GRAM per frame. IntyColor includes a new flag to choose total number of GRAM defined per frame.

[blainelocklair]

Thanks for posting this up! I have downloaded it and will compile some programs, including my current project, with it. I'll also add some ECS music to it to see how it performs within the project.

 

- Blaine

[digress]

I compiled boothill with no issues under 1.4 intybasic. thumbs up

[+Lathe26]

I hope to test the new release out in the next few days.

[artrag]

The new warnings/errors are quite interesting.

I have a case to report.

 

I get:

Error: GOTO ACTIVATE_BONUS from procedure INACTIVE flows inside main code (stack disruption)

 

For this code:

		
inactive: procedure
		resetsprite(n+4)
		
		' do not respawn if in boss mode
		if (enter_boss_mode) then return
		
		if (activate_bonus)	then goto activate_bonus
		
		' Respawn a new enemy
		e_time(n) = e_time(n) - 1
		
		if	(e_time(n) = 0) then 
			e_state(n) = e_active
			e_substate(n) = 0
			
			if ((frame and 3)=0) then 
				e_type(n) = enemy_type xor 1	'random(max_enemy_type+1)		'PRINT AT 11*20+0	COLOR 2,<3> e_type(n)
			else 
				e_type(n) = enemy_type			'PRINT AT 11*20+0	COLOR 5,<3> e_type(n)
			end if

			
			on  (e_type(n))  goto 	phi_rand_back,\
									phi_rand,\
									phi_rand,\
									my_phi,\
									phi_rand,\
									phi_rand,\
									my_phi_backa,\
									my_phi_backb
phi_rand:
			p(n) =  random(two_pi+1)
			return
my_phi_backa:
			e_time(n) = 127
			p(n) = (ms_p + 64 + random((two_pi+1)/8)) and two_pi
			return			
my_phi_backb:
			e_time(n) = 127
			p(n) = (ms_p - 64 - random((two_pi+1)/8)) and two_pi
			return			
my_phi:		
			p(n) = (ms_p - 32 + random(64)) and two_pi
			return
phi_rand_back:
			e_time(n) = 127
			p(n) =  ms_p + 128 - (two_pi+1)/16 + random((two_pi+1)/8)
			return
		end if

	end


''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'	Bonus
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
	const b_frame = 15
	
activate_bonus:
	e_state(n) = b_active
	e_type(n) = activate_bonus-1				' Bonus type	
	activate_bonus = 0
	e_time(n) = 0
	p(n) =  random(two_pi+1)
	return

Do I really corrupt the stack?

[artrag]

Forgot to say the ECS player consumes more processor cycles, so you can only define 12 GRAM per frame. IntyColor includes a new flag to choose total number of GRAM defined per frame.

 

 

Maybe a dummy question: why don't you run the music player after all the I/O in the vertical border has been completed?

In this way you can use all the border time for GRAM access (maybe at cost of small jitters in the note duration)

[+DZ-Jay]

Do I really corrupt the stack?

 

Well, for practical purposes, yes, since the compiler is not smart enough to tell that you are returning properly from the outside branch. All it knows is that you branched out of a subroutine, and therefore cannot guarantee the integrity of the stack.

 

In your case, you can safely ignore the warning. However, it is "unclean" and I wouldn't recommend it.

 

If you really want the branch, why not include it within the subroutine, at the end, and just return before it? If it's a block of code accessed from multiple places, perhaps it'll be best to wrap it as a subroutine and call it with GOSUB everywhere.

 

-dZ.

Edited December 29, 2018 by DZ-Jay

[+DZ-Jay]

 

 

Maybe a dummy question: why don't you run the music player after all the I/O in the vertical border has been completed?

In this way you can use all the border time for GRAM access (maybe at cost of small jitters in the note duration)

 

Or run the tracker outside the context of the ISR, like we do in assembly programs. The extra PSG management does not come for free, so playing 6 channels will always incur some cost in processing; but it should not be at the expense of GRAM and STIC handling.

 

-dZ.

[+nanochess]

The new warnings/errors are quite interesting.

I have a case to report.

 

I get:

Error: GOTO ACTIVATE_BONUS from procedure INACTIVE flows inside main code (stack disruption)

 

Do I really corrupt the stack?

You put the RETURN in the right place but the compiler cannot know that, your code is in the outside! So better to stay in the safe side

 

In fact your RETURN statement should've already generating an error of RETURN without PROCEDURE.

[+nanochess]

Maybe a dummy question: why don't you run the music player after all the I/O in the vertical border has been completed?

In this way you can use all the border time for GRAM access (maybe at cost of small jitters in the note duration)

I'm afraid my trained ear can notice it. But I'll try to optimize before release.

[+DZ-Jay]

I'm afraid my trained ear can notice it. But I'll try to optimize before release.

 

Couldn't you run the tracker right after the VBLANK-critical code (before returning control to the program)? That way, you can guarantee that the tracker runs within the engine cycle at the expense of delaying the game code. Your trained ears would be kept at ease.

 

If the game code is too long between frames it already gets delayed anyway, so there was never a guarantee that the game code would run within a single frame. This gives the programmer an incentive to optimize his game code, which he has full control over. That is, rather than reducing the GRAM copy cycle (and thus, limiting the potential for animations and such), which is something the programmer has absolutely no control over.

 

-dZ.

Edited December 29, 2018 by DZ-Jay

[carlsson]

o Solved bug where IF CONT.B0 THEN wouldn't work, also ABS and SGN.

I don't know what this is supposed to mean, but IMHO ABS still is broken though I know you don't agree with me so I have learned to live with it and make workarounds.

 

Otherwise, some of my most recent programs compile and run without issues. I didn't try any of the new features though, which perhaps is most important to test before making a final release.

[artrag]

I'm afraid my trained ear can notice it. But I'll try to optimize before release.

At the end of the current frame, you can compute and store the psg values in ram and write them to the psg at the beginning of the next frame. It will cost ram but it will minimize the time lost during the border time.

[+DZ-Jay]

At the end of the current frame, you can compute and store the psg values in ram and write them to the psg at the beginning of the next frame. It will cost ram but it will minimize the time lost during the border time.

 

Unlike the STIC, there is no requirement to reserve PSG updates to the VBLANK period -- the only requirement is to update it periodically, once per frame to maintain the music's temporal integrity. Therefore, I don't really think it matters when in the frame it's updated as long as it is updated once and roughly at the same point every time.

 

I don't really understand why it needs to be at the top of the ISR rather than at the bottom, and I don't really understand why the tracker's processing has an impact on GRAM updates. I do not think this is necessary. In fact, I think it's disingenuous because in IntyBASIC, GRAM updates is a feature for which the programmer has little control, and it is also critically time-bound to the VBLANK period.

 

In my mind, if the programmer is given the option to use fully the GRAM capabilities (i.e., copying 16 cards per frame), and to use fully the music tracker capabilities (i.e., 6 tracker channels), and his game loop is too slow to run at 60 Hz; it is absolutely under his control to either reduce GRAM use, reduce music channel use, optimize his code, or reduce the frame-rate of his game loop.

 

It is my opinion that limiting either feature takes away this power from the programmer's hands.

 

-dZ.

Edited December 29, 2018 by DZ-Jay

[artrag]

One word: jitter

[+DZ-Jay]

One word: jitter

 

??? The PSG does not need to be updated before GRAM, so there is no need for it to have an impact on it at all.

[artrag]

 

??? The PSG does not need to be updated before GRAM, so there is no need for it to have an impact on it at all.

A trained ear can notice that the length of the notes varies according to the time taken by the gram update.

If you update the psg always at the same time in the frame there will be no jitter

[artrag]

Anyway for my untrained hear the result depends case by case.

[+DZ-Jay]

A trained ear can notice that the length of the notes varies according to the time taken by the gram update.

If you update the psg always at the same time in the frame there will be no jitter

I understand that, and I experience it myself sometimes (I was a Dj for many years, so I have an ear that notices small timing differences in sounds). However, I insist that the difference in the few cycles it takes to process GRAM before will not make a noticeable difference, as long as the period is mostly stable.

 

Take a look at older games and see if you notice any jitter in the music. Most of the older assembly language games, especially those by Arnauld, Joe Z., and Carl, which use music considerably, typically update outside the ISR context, but at a mostly stable period.

 

In my opinion, the trick is to update the PSG at roughly the same point in the engine and make the period predictable to the ear. Psychoacoustics will take care of the rest.

 

dZ.

[+DZ-Jay]

Heres some info:

https://en.m.wikipedia.org/wiki/Just-noticeable_difference#Music_production_applications

https://sound.stackexchange.com/questions/25070/what-is-the-resolution-of-human-hearing

[artrag]

The generated code is slightly more efficient, as now you support R1 in ADDI while in previous version you had mainly R0

[+nanochess]

 

The generated code is slightly more efficient, as now you support R1 in ADDI while in previous version you had mainly R0

 

 

 

Indeed there is more optimization required by my work on the recent Elektronite games and some of the issues you brought in my Github.