Jump to content
IGNORED

IntyBASIC compiler


nanochess

Recommended Posts

as1600 seems to have issue with compiled array asm. I'm unsure if I'm using them right in IntyBASIC. Maybe nanochess can take a look.

 

KaboomArray.bas Here's the BASIC source code.

 

Here's the arrayless source code.

 

KaboomArrayLess.bas

 

NOTE: Kaboom is just practice for me. Retroillucid asked me yesterday, I was like I will try. I think the array format would work best with this game since the Atari version there's more objects then Intellivision MOB can display. I wanted to do an array format to flicker the bombs when it exteeds 5 sprites. The bomber is 2 sprites and the basket is 1 sprite. I also wanted to make the basket flicker to make room for the bomb sprites. Nostalgic for some reason have trouble refreshing at 60 fps even though it is running at 60 fps. It should be solid on LCD TV like D2K did for mine.

  • Like 2
Link to comment
Share on other sites

as1600 seems to have issue with compiled array asm. I'm unsure if I'm using them right in IntyBASIC. Maybe nanochess can take a look.

 

attachicon.gifKaboomArray.bas Here's the BASIC source code.

 

Here's the arrayless source code.

 

attachicon.gifKaboomArrayLess.bas

 

NOTE: Kaboom is just practice for me. Retroillucid asked me yesterday, I was like I will try. I think the array format would work best with this game since the Atari version there's more objects then Intellivision MOB can display. I wanted to do an array format to flicker the bombs when it exteeds 5 sprites. The bomber is 2 sprites and the basket is 1 sprite. I also wanted to make the basket flicker to make room for the bomb sprites. Nostalgic for some reason have trouble refreshing at 60 fps even though it is running at 60 fps. It should be solid on LCD TV like D2K did for mine.

:thumbsup: :cool:

Link to comment
Share on other sites

I wanted to do an array format to flicker the bombs when it exteeds 5 sprites. The bomber is 2 sprites and the basket is 1 sprite. I also wanted to make the basket flicker to make room for the bomb sprites. Nostalgic for some reason have trouble refreshing at 60 fps even though it is running at 60 fps. It should be solid on LCD TV like D2K did for mine.

Flickering was frowned upon in Intellivision games back in the day ;). How about using pre-shifted GRAM cards for the basket and the bomber? That way you'd have 7 or 8 MOBs free for bombs. Given that there aren't many sprites in Kaboom you won't run out of resources if they are pre-shifted.

Link to comment
Share on other sites

Flickering was frowned upon in Intellivision games back in the day ;). How about using pre-shifted GRAM cards for the basket and the bomber? That way you'd have 7 or 8 MOBs free for bombs. Given that there aren't many sprites in Kaboom you won't run out of resources if they are pre-shifted.

post-24767-0-31654900-1392160371_thumb.png

 

Yeah, this is the reason why this bomber is frowning :). This screenshot is 2 frames merged together. I'm a bit crazy with system's sprite capability so I am a bit flicker happy ;). At least now I have bomb spawning system working and figuring out the slot system.

 

I was curious about the Intellivision disc control and it 16 point of direction may be good for iPod wheel like control. Up would be neutral, up+up+left would move the basket 1, left+up will move the basket 2, left+left+up would move the basket 3, left+left basketx-=4, on so on intil down+down+left would move the basket 7. Same to going right but going right.

Link to comment
Share on other sites

I was curious about the Intellivision disc control and it 16 point of direction may be good for iPod wheel like control. Up would be neutral, up+up+left would move the basket 1, left+up will move the basket 2, left+left+up would move the basket 3, left+left basketx-=4, on so on intil down+down+left would move the basket 7. Same to going right but going right.

 

That is brilliant! :thumbsup:
Link to comment
Share on other sites

as1600 seems to have issue with compiled array asm. I'm unsure if I'm using them right in IntyBASIC. Maybe nanochess can take a look.

 

 

Thanks for bringing it to my attention, just I've found a bug in assignation to arrays with constant index. I'll correct it for next version.

  • Like 1
Link to comment
Share on other sites

post-24767-0-71347400-1392178429_thumb.gif <---click to animate

SOURCE CODE:KaboomWIP.bas

 

I spent most of all day programming this game. I kept saying to myself to stop, but myself couldn't listen. Anyway, I will have to reprogram this game. I probably going to reduce the number of bombs from 10 to 8. To keep the bombs solid until the 6th bomb enter the playfield, would start flickering sprites. I think I can do a better job with the slot system and have the bomb explode from bottom from top, which doesn't work too well with this build. Once the array is fixed, then I can use for statement to use recursive to reduce the bin size a lot, which is 6KB bin now,

 

I will probably push the wall done a bit so the score won't get blocked by the bomber. I want to keep the basket as sprite due to collusion detection against sprites. There is graphics for remaining basket in the ROM as lives system. I may probably convert one of the bomber's sprite to card to increase the sprite for the bombs. Next to load a blank card into the gram so I can use colorstacks to change the colors to mimic the flashy effect like the Atari 2600 version. I can draw then wall graphics and the cityscape background.

Edited by Kiwi
  • Like 5
Link to comment
Share on other sites

attachicon.gifKaboomWIPa.gif <---click to animate

SOURCE CODE:attachicon.gifKaboomWIP.bas

 

I spent most of all day programming this game. I kept saying to myself to stop, but myself couldn't listen. Anyway, I will have to reprogram this game. I probably going to reduce the number of bombs from 10 to 8. To keep the bombs solid until the 6th bomb enter the playfield, would start flickering sprites. I think I can do a better job with the slot system and have the bomb explode from bottom from top, which doesn't work too well with this build. Once the array is fixed, then I can use for statement to use recursive to reduce the bin size a lot, which is 6KB bin now,

 

I will probably push the wall done a bit so the score won't get blocked by the bomber. I want to keep the basket as sprite due to collusion detection against sprites. There is graphics for remaining basket in the ROM as lives system. I may probably convert one of the bomber's sprite to card to increase the sprite for the bombs. Next to load a blank card into the gram so I can use colorstacks to change the colors to mimic the flashy effect like the Atari 2600 version. I can draw then wall graphics and the cityscape background.

I had to add "end" statements to all the procedures to get it to compile. But after that it seems to work fine.

The flickering is a little annoying - I think you could do the bombs in backtab with scrolling, and then have plenty of sprites for the bomber, basket and score...

Link to comment
Share on other sites

post-24767-0-65242300-1392264985_thumb.gif <-click to animate

 

I changed the bomb slot system to reduce flickering. Also reduced the maximum bombs from 10 to 8 bombs. It now only flicker bombs when the 6th, 7th, 8th bomb is on screen. I showed when the bomb is dropping at higher speed, less bombs are on screen therefore no flickering is occurring. I move the bomber down 1 card.

 

One thing I can't do with this binary is test it on the real console. Therefore, I can't tell if the flicker is going to be solid or not. D2K flicker is solid with LCD. I will see if I can use the one of the bucket colors and turn that to card. It will be a bit harder to figure out, I can use the skyblue line and leave the bucket as sprites . I do plan to use Activision font for the number in the score.

 

And backtab scrolling, won't the all the sprites move with the offset? I haven't played with the offset yet so I don't have an answer for this question :dunce: .

  • Like 2
Link to comment
Share on other sites

 

 

And backtab scrolling, won't the all the sprites move with the offset? I haven't played with the offset yet so I don't have an answer for this question :dunce: .

 

Normally, the sprites move with the offset. But, if you adjust the sprites position by subtracting the offset from it, then the result will a a sprite standing still.

 

Here is a "technical demo" to illustrate this:

 

The sprite on the left "A" is set to one position. As the offset register changes, this sprite moves down with the rest of the screen.

The sprite on the right "B" has it's position adjusted to counteract the effect of the offset. So it stands still.

 

post-14916-0-78898000-1392350364_thumb.gif

 

This demo seems to work, but we may need to get nanochess to add some scrolling support, because it is critical that the changes to the offset registers and the sprites happen in the same frame.

	REM
	REM Techdemo
	REM Created in IntyBASIC
	REM by Catsfolly
	REM Feb 2014.
	REM 
	cls

	DEFINE 0,1,gramchars
	WAIT
	
	REM fill the screen with a grid
	for a= 0 to 239
	Poke $200+a, $800 + 0 + 1
	next a
	
	offset=0
	WAIT

loop:	
	REM the position of sprite 0 (the A) is not adjusted by the offset 
	SPRITE 0, 30 + $300, 50 + $100, (33 * + 6
	
	REM the offset is subtracted from position of sprite 1 (the B) 
	SPRITE 1, 120 + $300, ((50 - offset) AND $7f) + $100, (34 * + 6
	WAIT
	poke $31,offset
	if (FRAME AND $0f)=$0f THEN offset = (offset+1) AND 7

	GOTO LOOP

gramchars:

REM 0

	BITMAP "########"
	BITMAP "#......."
	BITMAP "#......."
	BITMAP "#......."
	BITMAP "#......."
	BITMAP "#......."
	BITMAP "#......."
	BITMAP "#......."
	
	

  • Like 2
Link to comment
Share on other sites

 

This demo seems to work, but we may need to get nanochess to add some scrolling support, because it is critical that the changes to the offset registers and the sprites happen in the same frame.

 

You're doing it just right.

 

Because once you use SPRITE, the data is saved for update in next video interruption, and your POKE just after WAIT is exactly in timing.

 

I still don't have used the scrolling registers of Intellivision, but I think that probably would be useful to have a whole screen scroll in four or height directions (SCROLL statement?) and some way of setting the hidden border registers.

  • Like 1
Link to comment
Share on other sites

attachicon.gifKaboomWIP2.gif.gif <-click to animate

 

I changed the bomb slot system to reduce flickering. Also reduced the maximum bombs from 10 to 8 bombs. It now only flicker bombs when the 6th, 7th, 8th bomb is on screen. I showed when the bomb is dropping at higher speed, less bombs are on screen therefore no flickering is occurring. I move the bomber down 1 card.

 

One thing I can't do with this binary is test it on the real console. Therefore, I can't tell if the flicker is going to be solid or not. D2K flicker is solid with LCD. I will see if I can use the one of the bucket colors and turn that to card. It will be a bit harder to figure out, I can use the skyblue line and leave the bucket as sprites . I do plan to use Activision font for the number in the score.

 

And backtab scrolling, won't the all the sprites move with the offset? I haven't played with the offset yet so I don't have an answer for this question :dunce: .

Really nice job. By the way, the D2K engine uses a 50-50 duty cycle when multi-plexing, meaning that sprites are displayed every other frame, usually at 60 frames per second (ideally). This gives them a pretty solid look (albeit translucent).

 

On some flat-panel displays though, this is not necessarily the ideal approach since they clearly update at something less than 60 Hz (I suspect around 30 Hz). To circumvent this problem, I display each sprite on for two frames, then offer two frames (with the "3030" code). Flickery, but at least they don't disappear altogether!

 

Carl

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

Hi, I'm about to play with the IntyBasic compiler (sorry I'm late, work is brutal!) and I have a request for nanochess: could you prepare a distribution with compiler binary, sample source, and generated source separate. It makes me cringe seeing all those files in the same folder. :)

 

Also, is the distro at the head of this thread the latest version, and does it include the Mac OSX compiler?

 

Thanks! I'll post more as I progress. I want to play with catsfolly's "Ballowns & Cloons." ;)

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

OK, I have the IntyBasic compiler set up to my liking, but it seems to expect the prologue and epilogue files in the same folder as binary. And so, I have another request: can this be configurable with an environment variable?

 

This will allow for future expansion, if you ever decide to include additional "pre-fabbed" modules with the compiler, you could have a "lib" directory for library files. Alternatively, instead of injecting the files, you could include them like this:

       INCLUDE "intybasic_epilogue.asm"
 
       ; generated assembly code...
 
       INCLUDE "intybasic_prologue.asm"

And let the jzIntv assembler pick them up from its configured library directory path in $AS1600_PATH. (I told you, I'm more than a bit obsessive with how I organize my projects. :) )

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

OK, I have the IntyBasic compiler set up to my liking, but it seems to expect the prologue and epilogue files in the same folder as binary.

 

Hmm... I just realized that it's not even expecting it in the binary path... it's expecting the library files to be adjacent to the BASIC source file! :o

 

This seems to suggest a pattern of dropping all basic source files in the same directory (along with the library files). That's generally fine, but could it be configurable (pretty please)? I tend to segregate my projects into separate folders. :)

 

-dZ.

 

P.S. Sorry for all the fussiness. :)

Edited by DZ-Jay
Link to comment
Share on other sites

Hi, I'm about to play with the IntyBasic compiler (sorry I'm late, work is brutal!) and I have a request for nanochess: could you prepare a distribution with compiler binary, sample source, and generated source separate. It makes me cringe seeing all those files in the same folder. :)

With so many examples it would be useful. I'll think about it.

 

Also, is the distro at the head of this thread the latest version, and does it include the Mac OSX compiler?

Yep. The latest version includes the Mac OSX compiler.

 

OK, I have the IntyBasic compiler set up to my liking, but it seems to expect the prologue and epilogue files in the same folder as binary. And so, I have another request: can this be configurable with an environment variable?

 

This will allow for future expansion, if you ever decide to include additional "pre-fabbed" modules with the compiler, you could have a "lib" directory for library files. Alternatively, instead of injecting the files, you could include them like this:

       INCLUDE "intybasic_epilogue.asm"
 
       ; generated assembly code...
 
       INCLUDE "intybasic_prologue.asm"
And let the jzIntv assembler pick them up from its configured library directory path in $AS1600_PATH. (I told you, I'm more than a bit obsessive with how I organize my projects. :) )

 

-dZ.

 

Hmm... I just realized that it's not even expecting it in the binary path... it's expecting the library files to be adjacent to the BASIC source file! :o

 

This seems to suggest a pattern of dropping all basic source files in the same directory (along with the library files). That's generally fine, but could it be configurable (pretty please)? I tend to segregate my projects into separate folders. :)

 

-dZ.

 

P.S. Sorry for all the fuzzyness. :)

Hmmm... maybe a command-line option to set up the path for libraries, alternately an environment variable.

  • Like 1
Link to comment
Share on other sites

Perhaps I'm the only OCS freak with code organization, but in the off chance that there may be others out there, I've prepared a sample distro split into different folders. It includes a handy Perl script called "intbas.pl" that compiles then assembles a BASIC project. I call this the "DZ's Special" distro.

In trying to keep things neat (I know, I know, I need help), it keeps the prologue and epilogue files in a "library" folder, and creates symbolic links to them on the project's directory before compiling. (The script goes through some additional gymnastics to change directories and keep the IntyBasic compiler happy.)

The upshot is that you can keep your projects separate, and then compile and assemble in a single go.

The installation layout is as follows:

=============================================================================
FILE PATH:                              DESCRIPTION:
=============================================================================
+-- intybasic                           Installation directory
    +-- games                           BASIC game project repository
    |    +-- game1                      Sample Project: game1
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- game1.bin        \_ Game binary in BIN+CFG format
    |    |    |    |-- game1.cfg        /
    |    |    |    |-- game1.ls         -> Assembler listing file
    |    |    |    |-- game1.map        -> Assembler memory map
    |    |    |    |-- game1.rom        -> Game binary in ROM format
    |    |    |    `-- game1.sym        -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- game1.asm        -> Generated assembly source
    |    |    |
    |    |    `-- game1.bas             BASIC source file
    |    |
    |    +-- game2                      Sample Project: game2
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- game2.bin        \_ Game binary in BIN+CFG format
    |    |    |    |-- game2.cfg        /
    |    |    |    |-- game2.ls         -> Assembler listing file
    |    |    |    |-- game2.map        -> Assembler memory map
    |    |    |    |-- game2.rom        -> Game binary in ROM format
    |    |    |    `-- game2.sym        -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- game1.asm        -> Generated assembly source
    |    |    |
    |    |    `-- game2.bas             BASIC source file
    |    |
    |    +-- sprites
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- sprites.bin      \_ Game binary in BIN+CFG format
    |    |    |    |-- sprites.cfg      /
    |    |    |    |-- sprites.ls       -> Assembler listing file
    |    |    |    |-- sprites.map      -> Assembler memory map
    |    |    |    |-- sprites.rom      -> Game binary in ROM format
    |    |    |    `-- sprites.sym      -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- sprites.asm      -> Generated assembly source
    |    |    |
    |    |    `-- sprites.bas           BASIC source file
    |    |
    |    +-- test
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- test.bin         \_ Game binary in BIN+CFG format
    |    |    |    |-- test.cfg         /
    |    |    |    |-- test.ls          -> Assembler listing file
    |    |    |    |-- test.map         -> Assembler memory map
    |    |    |    |-- test.rom         -> Game binary in ROM format
    |    |    |    `-- test.sym         -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- test.asm         -> Generated assembly source
    |    |    |
    |    |    `-- test.bas              BASIC source file
    |    |
    |    `-- title
    |        +-- bin                    AS-1600 assembler output
    |        |    |-- title.bin         \_ Game binary in BIN+CFG format
    |        |    |-- title.cfg         /
    |        |    |-- title.ls          -> Assembler listing file
    |        |    |-- title.map         -> Assembler memory map
    |        |    |-- title.rom         -> Game binary in ROM format
    |        |    `-- title.sym         -> Assembler symbol table
    |        |
    |        +-- asm                    IntyBasic compiler output
    |        |    `-- title.asm         -> Generated assembly source
    |        |
    |        `-- title.bas              BASIC source file
    |
    +-- bin                             IntyBasic binary distribution
    |    |-- intbas.pl                  -> Helper script to compile/assemble
    |    |-- intybasic_linux            -> IntyBasic for Linux
    |    |-- IntyBASIC.exe              -> IntyBasic for Windows
    |    `-- intybasic                  -> IntyBasic for Mac OSX
    |
    +-- lib                             IntyBasic library modules
    |    |-- intybasic_prologue.asm     -> Prologue module
    |    `-- intybasic_epilogue.asm     -> Epilogue module
    |
    |-- manual.txt                      IntyBasic manual
    `-- INTBAS - README.txt             This README file.

=============================================================================

Note that I am not making any claims on the compiler. IntyBasic is exclusively the work of nanochess, and this was not an authorized development, just an honest offering in case anybody is as obsessive as I am.

 

The "intbas.pl" script requires Perl, and has only been tested on Mac OSX, though it should work on Windows as well. You'll have to configure a couple of file paths at the top of the script that point to the assembler, the compiler, and the library files. Also, you may want to add the script's location to your execution path ($PATH).

 

Cheers!

 

-dZ.

 

 

UPDATE: Updated "intbas.pl" script to create the "asm" and "bin" folders for the project if they do not exist.

 

intybasic - DZ's Special.zip

Edited by DZ-Jay
  • Like 2
Link to comment
Share on other sites

Hmmm... maybe a command-line option to set up the path for libraries, alternately an environment variable.

 

That's even better. :)

 

OK, enough fussiness with files now... On to "Clowns & Balloons"! :)

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

DZ-Jay, on 22 Feb 2014 - 9:04 PM, said:snapback.png

OK, I have the IntyBasic compiler set up to my liking, but it seems to expect the prologue and epilogue files in the same folder as binary. And so, I have another request: can this be configurable with an environment variable?

This will allow for future expansion, if you ever decide to include additional "pre-fabbed" modules with the compiler, you could have a "lib" directory for library files. Alternatively, instead of injecting the files, you could include them like this:

INCLUDE "intybasic_epilogue.asm"

; generated assembly code...

INCLUDE
"intybasic_prologue.asm"And let the jzIntv assembler pick them up from its configured library directory path in $AS1600_PATH. (I told you, I'm more than a bit obsessive with how I organize my projects. :) )

-dZ.

 

With so many examples it would be useful. I'll think about it.


Yep. The latest version includes the Mac OSX compiler.



Hmmm... maybe a command-line option to set up the path for libraries, alternately an environment variable.

 

 

Yeah - can imagine having different "epilogues" - maybe one that supports scrolling, or one that calls the music tracker.

Using includes would make it possible to choose which one was included.

 

I guess it is tricky to make things simple for beginners, but versatile for more experienced users...

Link to comment
Share on other sites

 

DZ-Jay, on 22 Feb 2014 - 9:04 PM, said:snapback.png

 

Yeah - can imagine having different "epilogues" - maybe one that supports scrolling, or one that calls the music tracker.

Using includes would make it possible to choose which one was included.

 

I guess it is tricky to make things simple for beginners, but versatile for more experienced users...

 

 

I don't think it's so tricky. If beginners are expected to unzip the archive into a single directory, then make the compiler load the libraries from the current working directory (like it does today), but provide a command-line option to specify the path.

 

-dZ.

Link to comment
Share on other sites

nanochess:

I found the reason the initialization drops GRAM writes. Your _int_vector ISR can be optimized to run faster during VBLANK. For instance, the following change to @@vi0 will read the collisions register faster.



 
@@vi0:
        ;
        ; Save collision registers for further use
        ;
        MVII    #$18,   R4
        MVII    #_col0, R5
    REPEAT(
        MVI@    R4,     R0
        MVO@    R0,     R5
    ENDR
 
        CLRR    R0
        MVII    #$18,   R4
    REPEAT(
        MVO@    R0,     R4
    ENDR


Also, is there a reason why you need to set COLOR STACK mode on every VBLANK? I recommend doing it in @@vi0 during initialization.

 

-dZ.

Edited by DZ-Jay
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...