Jump to content

Photo

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

Intellivision IntyBASIC

393 replies to this topic

#376 artrag OFFLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Thu Aug 9, 2018 4:20 PM

Using the fixed point math I've spotted this

 

 

data -0.7071,0.7071
                                SRCFILE "testbasic.bas",48
DECLE -46336
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
 
I do not get errors by Intybasic but the assembler reports an "out of range error"....
Is there any mean to overcame this errors?


#377 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,286 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Thu Aug 9, 2018 4:24 PM

Using the fixed point math I've spotted this
 
 
data -0.7071,0.7071
                                SRCFILE "testbasic.bas",48
DECLE -46336
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
 
I do not get errors by Intybasic but the assembler reports an "out of range error"....
Is there any mean to overcame this errors?


AND with $FFFF ?

The assembler uses 32-bit values internally, but renders 16-bit values when assembling.

#378 intvnut OFFLINE  

intvnut

    River Patroller

  • 3,088 posts
  • Location:@R6 (top of stack)

Posted Thu Aug 9, 2018 5:48 PM

 

Using the fixed point math I've spotted this

 

 

data -0.7071,0.7071
                                SRCFILE "testbasic.bas",48
DECLE -46336
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
 
I do not get errors by Intybasic but the assembler reports an "out of range error"....
Is there any mean to overcame this errors?

 

 

 

AND with $FFFF ?

The assembler uses 32-bit values internally, but renders 16-bit values when assembling.

 

 

I don't think -46336 is a meaningful number here.  Masking with $FFFF (even if you could) is the wrong thing to do.

 

AS1600 allows the range -32768 to 65536, which encompases the entire signed and unsigned 16-bit ranges.  -46336 is outside both of those ranges.

 

As a fixed point number in Q8 notation, 0.707 is $00B5, and in the rotated Q8, would be $B500.   -0.707 would be $FF4B, and in rotated Q8, $4BFF.

 

-46336 is $FFFF4B00, which is the wrong value, since the negation is being applied to the rotated value.

 

Negation should be applied before rotation, resulting oin $4BFF.  (Or if it's 1s complement, $4AFF.  I forget, is the rotated Q8 in 1s complement?)



#379 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,286 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Fri Aug 10, 2018 3:31 AM

 

 

 

 

I don't think -46336 is a meaningful number here.  Masking with $FFFF (even if you could) is the wrong thing to do.

 

AS1600 allows the range -32768 to 65536, which encompases the entire signed and unsigned 16-bit ranges.  -46336 is outside both of those ranges.

 

As a fixed point number in Q8 notation, 0.707 is $00B5, and in the rotated Q8, would be $B500.   -0.707 would be $FF4B, and in rotated Q8, $4BFF.

 

-46336 is $FFFF4B00, which is the wrong value, since the negation is being applied to the rotated value.

 

Negation should be applied before rotation, resulting oin $4BFF.  (Or if it's 1s complement, $4AFF.  I forget, is the rotated Q8 in 1s complement?)

 

Yeah, I didn't even think of what the value was.  I just thought that perhaps that the values generated by IntyBASIC were correct but too large.  That's what I get for responding quickly without paying to much attention.  DOH! :dunce:

 

If IntyBASIC is mangling the fraction values by negating after rotation then that needs to be fixed, obviously.

 

   -dZ.



#380 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,286 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Fri Aug 10, 2018 3:37 AM

 

Using the fixed point math I've spotted this

 

 

data -0.7071,0.7071
                                SRCFILE "testbasic.bas",48
DECLE -46336
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
asm\testbasic.asm:1864: ERROR - expression exceeds available field width
 
I do not get errors by Intybasic but the assembler reports an "out of range error"....
Is there any mean to overcame this errors?

 

 

artrag:  One possible work-around is to use the correct 16-bit values given by intvnut above in hexadecimal to avoid the broken encoding.

 

A quick test with the IntyBASIC SDK shows that "0.707" is encoded as "46336," which is $B500, so Q8 rotated.  So try with $4BFF (or $4AFF if 1's complement).

 

  -dZ.



#381 artrag OFFLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Fri Aug 10, 2018 4:19 AM

Do not worry, I was already generating the correct data.

I was referring any parameter of intybasic or of as1600 to change behavior that leads to the error, but it is definitely an Intybasic bug connected to fixed point constants



#382 artrag OFFLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Fri Aug 10, 2018 4:35 AM

Oscar: fixed point math seems quite buggy

This line of code 

 

#ex(0) = -1.0+.#ex(0)

 

does not work!

 

While this other

 

#ex(0) = #ex(0)-.1.0

 

works as expected


Edited by artrag, Fri Aug 10, 2018 4:35 AM.


#383 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,286 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Fri Aug 10, 2018 4:45 AM

Oscar: fixed point math seems quite buggy

This line of code 

 

#ex(0) = -1.0+.#ex(0)

 

does not work!

 

While this other

 

#ex(0) = #ex(0)-.1.0

 

works as expected

 

Could you provide some sample values?  The first one seems to work (although I removed the "." in front of the ex(0) expression, since I thought it was a typo).

 

Sample:

#ex = 2.0
#ex = -1.0 + #ex
PRINT <>#ex

Prints "1".

#ex = 0.0
#ex = -1.0 + #ex
PRINT <>#ex

Prints "65535" (or -1 unsigned)

 

   -dZ.


Edited by DZ-Jay, Fri Aug 10, 2018 4:53 AM.


#384 artrag OFFLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Fri Aug 10, 2018 5:04 AM

no, the '.' is for fixed point math

 

  #A=#A+.#B         Fixed addition (note use of 16-bits variables)
  #A=#A-.#B         Fixed substraction (note use of 16-bits variables)

Edited by artrag, Fri Aug 10, 2018 5:04 AM.


#385 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,286 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Fri Aug 10, 2018 5:13 AM

 

no, the '.' is for fixed point math

 

  #A=#A+.#B         Fixed addition (note use of 16-bits variables)
  #A=#A-.#B         Fixed substraction (note use of 16-bits variables)

 

 

Sorry, you are right, I saw that as soon as I sent the message.  And you are also right that it does not work correctly.

 

Sample:

#ex = 2.0
#ex = -1.0 +.#ex
PRINT <>#ex

Prints "2".

 

   -dZ.



#386 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Tue Sep 4, 2018 9:41 AM

I have a question about .rom size.

 

Near the end of the IntyBASIC Programming Contest my MazezaM.rom file started getting close to 42k and it wouldn't load in jzintv.  When this happened I would usually try to trim some code or move the various "asm org" commands around until it would work with jzintv again.

 

After the contest I returned to this issue and started getting a bit confused.  In my program I only used the following segments:

  • Segment 0 (by default) (8kb)
  • Segment 1 (asm org $A000) (8kb)
  • Segment 2 (asm org $C040) (approx 16kb)

But these segments have a total size of 32kb and yet my .rom file was 42kb and seemed to work.

 

Was my .rom file clobbering other areas of memory?  Would it have worked if I had put it only a flash cart (like LTO Flash)?  I was only working with jzintv and never seemed to have a problem, but now I am a bit suspicious that I wasn't really creating a valid .rom file.

 

The manual for IntyBASIC does give a pointer on how to investigate the memory locations that are used:

 

Another way is to look into the generated .lst file, you can see what memory locations are used by IntyBASIC generated code.

However, I'm still a bit of a noob and don't really know what I'm looking at when I open the resulting .list file :? .  I also skimmed through Oscar's new book (so good!  :)  :thumbsup: ) but that didn't seem to resolve my confusion. 

 

PS  This issue also motivated me to start squishing the MazezaM.rom file and I'll post a new 34kb version on the MazezaM thread.



#387 carlsson OFFLINE  

carlsson

    Metagalactic Mule

  • 7,711 posts
  • Location:Västerås, Sweden

Posted Tue Sep 4, 2018 9:59 AM

The Intellivision is a 16-bit console, which means that the segment between $5000 - $6FFF holds 8 kilowords (or I suppose kilodecles may be the traditional term to use). However when you view file size on the PC, you get it in kilobytes, which are 8-bit so if your game was 42 kilobytes on disk that would be 21 kilowords, i.e. arranged as 8 kilowords at $5000, 8 kilowords at $A000 and 5 kilowords at $C040.

 

However it depends where your ASM ORG statements were located. Check the LST or at least CFG file to see the size of the segments. If either of these extend the end of a segment, it would sequentially fill memory until you actually tell it to use a diferent segment. I think that might be what happened, if you overflow $BFFF.

 

You linked to a site with your source code, though it gives HTTP 500 Internal server error right now, perhaps on purpose in case you withdrew the code from public viewing.


Edited by carlsson, Tue Sep 4, 2018 10:00 AM.


#388 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,286 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Tue Sep 4, 2018 10:00 AM

I have a question about .rom size.

 

Near the end of the IntyBASIC Programming Contest my MazezaM.rom file started getting close to 42k and it wouldn't load in jzintv.  When this happened I would usually try to trim some code or move the various "asm org" commands around until it would work with jzintv again.

 

After the contest I returned to this issue and started getting a bit confused.  In my program I only used the following segments:

  • Segment 0 (by default) (8kb)
  • Segment 1 (asm org $A000) (8kb)
  • Segment 2 (asm org $C040) (approx 16kb)

But these segments have a total size of 32kb and yet my .rom file was 42kb and seemed to work.

 

Was my .rom file clobbering other areas of memory?  Would it have worked if I had put it only a flash cart (like LTO Flash)?  I was only working with jzintv and never seemed to have a problem, but now I am a bit suspicious that I wasn't really creating a valid .rom file.

 

The manual for IntyBASIC does give a pointer on how to investigate the memory locations that are used:

However, I'm still a bit of a noob and don't really know what I'm looking at when I open the resulting .list file :? .  I also skimmed through Oscar's new book (so good!  :)  :thumbsup: ) but that didn't seem to resolve my confusion. 

 

PS  This issue also motivated me to start squishing the MazezaM.rom file and I'll post a new 34kb version on the MazezaM thread.

 

The size of the segments is measured in Kilo-words (16-bit), while the file size is declared in Kilo-bytes (8-bit).  This means that a full 42K (words, not bytes) will take 84Kb on a file.  If your file is 42Kb in size, then you're just half-way. :)

 

When you say that the game "wouldn't load in jzIntv," what specifically happened?  Did you get an error message?

 

A few things to keep in mind about the Intellivision memory map:

  • The memory map is fractured into multiple "segments" which are not contiguous.
  • The "ASM ORG" statement is an Assembly Language directive that instructs the assembler to store the program at a specific memory address.
  • The "standard" memory map we use in home-brewed games (and supported by IntyBASIC) is one offering 42K (words, not bytes!) spread throughout 5 segments.
  • If your game program overflows the default segment #0 of 8K (again, words, not bytes!), then you can either optimize it for size, or split the code with "ASM ORG" statements, and put the overflow in another segment.
  • Each procedure and data table must fit within a single segment, so you cannot just split wherever you wish.


#389 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Tue Sep 4, 2018 2:38 PM

Thanks guys, that totally makes sense!

 

re: link to source code.  The link should be back up now https://src-code.sim...ams/MazezaM_SOS.  We run our own git server at our college, but the uptime is much lower than 100% largely due to my incompetence in the area :woozy:



#390 First Spear OFFLINE  

First Spear

    Stargunner

  • 1,305 posts
  • Location:Somewhere in Uptown

Posted Wed Sep 5, 2018 10:48 AM

When you are looking at fitting things into the ROM, one thing that can help is to have single "master .bas" which just has some starter game info with an Include for the sections of your game. That way, when you run out of space in a section, you can move those little bits around in other memory areas without breaking anything major. I had all of my music in one large file for example, it fit nowhere contiguously, but calling out each song let me do 2 things - (1) fit the code and (2) make quicker changes. YMMV. HTH.



Goto MyGameStart

ASM ORG $2000
MyGameStart:
	STACK_CHECK
	Wait
	Voice Init
	Wait
	Flash Init
	Wait
	Sound 4,,$38
 	Include "constants.bas"
	Include "AllMyVariablesInOneFile.bas"
	Goto MainSwitchboard


ASM ORG $5000
	
        Include "MyGraphicsScreens.bas" 


ASM ORG $A000

	Include "SomeGameCode.bas"
	Include "SomeOtherGameCode.bas"
	Include "MoreGameCodeILine.bas"
	Include "NewStuffIJustMade.bas"
		

ASM ORG $C100

	Include "MusicCode.bas"
	Include "MoreMusicCode.bas"
	Include "GraphicsForEnemies.bas"
	Include "GraphicsForSpaceShips.bas"
	
ASM ORG $4810

	Include "SoundEffects.bas"
	Include "OtherGraphics.bas"
	  

	MainSwitchboard:
		CLS
		For #dodo= 0 to 7
			ResetSprite(#dodo)
		Next
		Mode SCREEN_CS , BORDER_BROWN , BORDER_BROWN , BORDER_BROWN , BORDER_BROWN
		Wait
		If #someCondition = 0 Then 
			Goto ThatThing
		ElseIf #someCondition = 1 Then 
			Goto ThatOtherThing
		End If
		Wait
		Goto MainSwitchboard




Thanks guys, that totally makes sense!

 

re: link to source code.  The link should be back up now https://src-code.sim...ams/MazezaM_SOS.  We run our own git server at our college, but the uptime is much lower than 100% largely due to my incompetence in the area :woozy:

 



#391 artrag OFFLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Mon Sep 24, 2018 1:21 AM

Oscar, how many bits are used in constant evaluation in Intybasic?

I have
N = 100000/256/256 and 255
But it seems to not give a correct result

#392 intvnut OFFLINE  

intvnut

    River Patroller

  • 3,088 posts
  • Location:@R6 (top of stack)

Posted Mon Sep 24, 2018 3:35 AM

Oscar, how many bits are used in constant evaluation in Intybasic?

I have
N = 100000/256/256 and 255
But it seems to not give a correct result

 

It appears all expression evaluation is at 16 bits, so 100000 becomes 34464 straight out of the gate (e.g. 100000 AND $FFFF).  I tried this example program:

.

X# = 100000
X# = 100000/256
X# = 100000/256/256 AND 255

.

It gave the following compiler output for those four statements:

.

    ;[1] X# = 100000
    SRCFILE "/tmp/i.bas",1
    MVII #34464,R0
    MVO R0,V1
    ;[2] X# = 100000/256
    SRCFILE "/tmp/i.bas",2
    MVII #134,R0
    MVO R0,V1
    ;[3] X# = 100000/256/256 AND 255
    SRCFILE "/tmp/i.bas",3
    CLRR R0
    MVO R0,V1

.

As you can see, the expression 100000/256 gives 134, which is consistent with 34464/256, not 100000/256.  100000/256 should give 390.

 

(Note: I did try adding parentheses also; however, if 100000/256 gives the wrong value, there's no point in continuing.)

 

Perhaps literal constants larger than 65535 should be an error?



#393 nanochess OFFLINE  

nanochess

    Processorus Polyglotus

  • Topic Starter
  • 5,578 posts
  • Coding something good
  • Location:Mexico City

Posted Mon Sep 24, 2018 4:54 AM

I was wondering why I didn't saw this before and then I saw it was just written a few hours before :rolling:

Just saw some silly decisions in my code (although everything looked at distance ends looking silly :P)

* If you use the statement CONST, your constant will be limited to 16 bits. Because I'm using a sparse C++ array and I need to distinguish the zero so (value & 0xffff) | 0x10000
* If you use directly the number, it will be put directly into the tree so it can be optimized.
* Almost all operators will work with the full 32-bits numbers, except division and modulus for some stupid reason.

So I'm removing this limitation from division and modulus. Later I'll see what I can do with CONST.

#394 artrag OFFLINE  

artrag

    Stargunner

  • 1,122 posts

Posted Mon Sep 24, 2018 11:20 AM

I was wondering why I didn't saw this before and then I saw it was just written a few hours before :rolling:

Just saw some silly decisions in my code (although everything looked at distance ends looking silly :P)

* If you use the statement CONST, your constant will be limited to 16 bits. Because I'm using a sparse C++ array and I need to distinguish the zero so (value & 0xffff) | 0x10000
* If you use directly the number, it will be put directly into the tree so it can be optimized.
* Almost all operators will work with the full 32-bits numbers, except division and modulus for some stupid reason.

So I'm removing this limitation from division and modulus. Later I'll see what I can do with CONST.

You could improve this in the next release...

Edited by artrag, Mon Sep 24, 2018 11:21 AM.






Also tagged with one or more of these keywords: Intellivision, IntyBASIC

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users