INTYBASIC 1.2 problems

[artrag]

Intybasic is awesome, in just 20 minutes of work without having never developed on Intellivision I did something working (almost).

Just a question: running INTYTEST or INTTDBUG I get the same jzintv window i get with INITYRUN, without any command line interface for debugging.

F4 does not work in the jzintv, the sole command working is F1 (exit)

I tried both putting the focus on the jzintv widow and on the CMD window, but I get no result.

How do I activate the step by step debugging ?

test.bas

test.rom

Edited August 14, 2015 by artrag

[GroovyBee]

Good start. A few comments :-

 

- I can see a huge DIM array in 8 nit RAM so that you only have 10 8bit variables left! Thats not going to be much for your game. How about peeking information from the background BACKTAB instead? That will leave you a whole bunch of 8 bit RAM.

- I'm not sure about the kind of game its going to be, but you need to think about how to get around corners and through gaps in the walls. Requiring precision corning/lining up will make for quite an irritating game in my opinion.

 

Keep it up!

[+nanochess]

In jzintv console issue a >160 command, this will expand horizontally the window so you can see the source code.

 

If still IntyBASIC source code doesn't appear, you can check with "MODE CON:" in CMD to check if your Windows is English, if isn't then soon there will be a patched jzintv version by intvnut.

[+Tarzilla]

Good start. A few comments :-

 

- I can see a huge DIM array in 8 nit RAM so that you only have 10 8bit variables left! Thats not going to be much for your game. How about peeking information from the background BACKTAB instead? That will leave you a whole bunch of 8 bit RAM.

- I'm not sure about the kind of game its going to be, but you need to think about how to get around corners and through gaps in the walls. Requiring precision corning/lining up will make for quite an irritating game in my opinion.

 

Keep it up!

 

None if he uses other IntyBasic features like SCROLL or PLAY

From the manual>>>>>>>>>>>>>>  Real number of variables allowed


The number of 8-bits variables allowed are:


        228
        
        Substract 3 if you use SCROLL
        Substract 3 if you use VOICE
        Substract 6 if you use the keypad
        Substract 26 if you use PLAY


The number of 16-bits variables allowed are:


        47 (7962 if using --jlp or --cc3 switch)
        
        Substract 20 if you use SCROLL or 30 if you use VOICE


Note each location of an array allocated with DIM counts as one variable.

I haven't seen anyone talk about using this flag for using the extra Ram of the JPL or CC3, but you should be able to get some huge arrays using it:

(7962 if using --jlp or --cc3 switch)

Groovy is correct though, in this case, peeking the BACKTAB in front of a moving character is definitely a better technique than storing data in arrays.

[GroovyBee]

You also need to be using the colour stack colours in the background BACKTAB, so change this line :-

 

	const WALL = 94*8+STACK_ORANGE

to

 

	const WALL = 95*8+CS_RED

If you try CS_ORANGE you'll invoke coloured squares mode on the cells (not what you want). Thats because GROM cards can only be the fist 8 colours of the palette.

[+DZ-Jay]

Just a question: running INTYTEST or INTTDBUG I get the same jzintv window i get with INITYRUN, without any command line interface for debugging.

 

F4 does not work in the jzintv, the sole command working is F1 (exit).

 

How do I activate the step by step debugging ?

 

Sorry, that was my fault and we are fixing it in the upcoming IntyBASIC SDK 1.2, which should be out soon.

 

To work around it, call INTYDBUG or INTYTEST with the -d option at the end of the command line.

 

Essentially, those tools "forgot" to send the debugger command to the emulator. DOH!

 

dZ.

[artrag]

Can I map an array name to a memory area?

I would map my huge array to 0x2000 in order to access to backtab ram without using peek an poke

[+nanochess]

Can I map an array name to a memory area?

I would map my huge array to 0x2000 in order to access to backtab ram without using peek an poke

 

Hmmmm. No, PEEK and POKE are pretty efficient, so you could envelope them in a DEF FN macro.

 

 

DEF FN read_screen(a) = PEEK(512+(a))
DEF FN write_screen(a,b) = POKE 512+(a),b

[artrag]

Having an array mapped in backtab ram would make transparent it's use

[artrag]

What about a an option "at" for the dim command?

[+nanochess]

What about a an option "at" for the dim command?

 

I'll add it to my TODO list

[artrag]

In this case maybe supporting natively two dimensional arrays could help even more

[carlsson]

For all of us who grew up with Commodore BASIC, to PEEK and POKE directly into video memory is not foreign at all. I suppose if you want syntactical sugar, you could ask for a couple of functions PUTCHAR, PUTATTR, GETCHAR, GETATTR which will take two arguments: an index 0-239 and the data.

 

Edit: Hm yes, there already were examples of DEF FN above, perhaps extend those a bit.

Edited August 8, 2015 by carlsson

[artrag]

No additional clumsy functions please.

All I propose is to let the coder to map the variables and the arrays in ram where he likes, eventually on I/O ports.

It is a compiled language, and all I/O is mapped in ram space, so it should be a very easy addition.

 

One could in this way do

 

DIM psg_reg(15) at $01F0

 

and access to the audio chip using psg_reg as an array

[GroovyBee]

Personally I don't see the need to map the PSG to an array. You can already play sounds, music and read controllers in the language itself.

 

As long as what the user calls is compiled to tight assembly language, it doesn't matter what the process is. I did a quick test and compiled the following code :-

INCLUDE "constants.bas"

DEF FN RSCREEN(aColumn,aRow) = PEEK(SCREENADDR((aColumn),(aRow)))
DEF FN WSCREEN(aColumn,aRow,aValue) = POKE SCREENADDR((aColumn),(aRow)), aValue

CONST BRICK=(95*+CS_GREEN
DIM M(10)

CLS
M(0)=99
WSCREEN(0,0,BRICK)
#in=RSCREEN(0,0)

PRINT AT SCREENPOS(0,1),<3>#in,">",<3>M(0)

loop:
	WAIT
	GOTO loop

In order to compare the efficiency of variables access and peek/poke.

M(0)=99                ' 2 CPU instructions.
WSCREEN(0,0,BRICK)     ' 5 CPU instructions [1].
#in=RSCREEN(0,0)       ' 2 CPU instructions.

At the end of the day it might look like like a lot to to the programmer but IntyBASIC doen't put much in the way between you and the bare metal underneath.

 

^[1] I'd expected the compiler to also make a 2 instruction sequence for this line of code. I've reported it to nanochess as an optimisation issue, so it can be sped up in a future version.

[artrag]

It is a matter of clearness and transparency, not of efficiency (even if having mapped an array at 0x0200 cannot be less than efficient for the compiler).

Moreover porting any basic program to Intybasic would be simpler using the syntax I proposed.

[GroovyBee]

It is a matter of clearness and transparency, not of efficiency.

Efficiency matters when you have a CPU that is as slow at the Intellivisions. The less it has to do the better .

 

Being able to map the screen to array would be nice, but you can do what you want today using the functions above and they are exactly the same speed as dealing with an array when reading and slower when you write. In a game, the slow write isn't really such an issue because you'll spend far more time reading the screen for collision detection purposes.

[artrag]

[...]having mapped an array at 0x0200 cannot be less than efficient for the compiler[...]

 

[artrag]

I moved to Intybasic v1.2 and removed the huge matrix but now I do not get any rom

The compiler hangs with this message

C:\Users\Admin\Documents\IntyBASIC SDK\Projects\test>intybuild test.bas

IntyBASIC Build Script (INTYBUILD.BAT)

Created by: DZ-Jay

Last updated: 07/13/2015

IntyBASIC compiler v1.2 Jul/31/2015

© 2014-2015 Oscar Toledo G. http://nanochess.org/

This application has requested the Runtime to terminate it in an unusual way.

Please contact the application's support team for more information.

IntyBASIC compilation failed.

Program build aborted.

In attach the new test.bas whose compilation fails with the above error

test.bas

[+nanochess]

 

I moved to Intybasic v1.2 and removed the huge matrix but now I do not get any rom

The compiler hangs with this message

C:\Users\Admin\Documents\IntyBASIC SDK\Projects\test>intybuild test.bas

IntyBASIC Build Script (INTYBUILD.BAT)

Created by: DZ-Jay

Last updated: 07/13/2015

IntyBASIC compiler v1.2 Jul/31/2015

© 2014-2015 Oscar Toledo G. http://nanochess.org/

This application has requested the Runtime to terminate it in an unusual way.

Please contact the application's support team for more information.

IntyBASIC compilation failed.

Program build aborted.

In attach the new test.bas whose compilation fails with the above error

 

 

In your TEST procedure each of the four calls to RSCR have an extra parenthesis in the left side, for some reason IntyBASIC isn't reporting the bug and gets stuck.

 

Anyway removing the extra parenthesis makes your program to work.

 

I'll check later the IntyBASIC bug.

[artrag]

removing the extra parenthesis works!

here the fixed code and its compiled rom

test.bas

test.rom

[artrag]

Hi Oscar

I have another problem with the intycompiler: it reports the following errors without any indication of what goes wrong.

Actually the problem is at assembly time, but I cannot say why it hangs

C:\Users\Admin\Documents\IntyBASIC SDK\Projects\test>intybuild test

IntyBASIC Build Script (INTYBUILD.BAT)

Created by: DZ-Jay

Last updated: 07/13/2015

IntyBASIC compiler v1.2 Jul/31/2015

© 2014-2015 Oscar Toledo G. http://nanochess.org/

11 used 8-bit variables of 228 available

0 used 16-bit variables of 47 available

Compilation finished

Assembling...

ERROR SUMMARY - ERRORS DETECTED 2

- WARNINGS 0

AS1600 assemblage failed.

Program build aborted.

C:\Users\Admin\Documents\IntyBASIC SDK\Projects\test>

In attach the test.bas that caused the errors

test.bas

[artrag]

This version avoids the problem using

 

on expr goto label1,label2 etc

 

never the less the problem above seems inexplicable

test.bas

test.rom

[+DZ-Jay]

As the output suggests, those are errors during assemblage, generated by the assembler, so they are outside the domain of the IntyBASIC compiler.

 

The assembler writes all it's errors in the "listing" file (".lst") it generates. The IntyBASIC SDK tools put that file in the "bin" folder of your project.

 

Just scan the listing file for the word "ERROR" to see the error details. Note that the error occurred during assemblage, so it is related to the assembly language file generated by IntyBASIC.

 

dZ.

[GroovyBee]

I had a quick look and IntyBASIC didn't generate a label for a branch and then duplicated a label name (hence the 2 errors). So its something nanochess needs to look at.