Jump to content
IGNORED

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


Recommended Posts

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?
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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?)

Link to comment
Share on other sites

 

 

 

 

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.

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

  • 4 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

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
  • Like 3
Link to comment
Share on other sites

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.
  • Like 2
Link to comment
Share on other sites

Thanks guys, that totally makes sense!

 

re: link to source code. The link should be back up now https://src-code.simons-rock.edu/git/awilliams/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:

Link to comment
Share on other sites

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.simons-rock.edu/git/awilliams/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:

 

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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