Jump to content

Photo

IntyBASIC compiler


165 replies to this topic

#126 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Mon Feb 10, 2014 5:21 PM

I decided to release the binary and the source code for those who wants to learn to code in IntyBASIC.  I started the object with projection at 1 instead of 0. 

 

Attached File  AppleCatcher.bin   8KB   255 downloads

Attached File  Applecatcher.bas   10.38KB   140 downloads
EDIT: Attached File  AppleCatcher.zip   163bytes   135 downloads extract the .cfg, I forgot to include this in this post.
Enjoy. :)


Edited by Kiwi, Mon Feb 10, 2014 6:03 PM.


#127 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,637 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Mon Feb 10, 2014 6:30 PM

I decided to release the binary and the source code for those who wants to learn to code in IntyBASIC.  I started the object with projection at 1 instead of 0. 

 

Enjoy. :)

 

I'm pretty amazed by how fast you have become proficient in the language :thumbsup: :)



#128 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Tue Feb 11, 2014 3:53 PM

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.

 

Attached File  KaboomArray.bas   4.42KB   149 downloads Here's the BASIC source code.

 

Here's the arrayless source code.

 

Attached File  KaboomArrayLess.bas   4.36KB   166 downloads

 

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.



#129 retroillucid OFFLINE  

retroillucid

    Facebook.com/Collectorvision

  • 7,357 posts
  • CollectorVision Games - Publishing Homebrew
  • Location:Montreal, Canada

Posted Tue Feb 11, 2014 4:01 PM

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:

#130 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Tue Feb 11, 2014 4:52 PM

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.

#131 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Tue Feb 11, 2014 5:22 PM

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.

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



#132 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,515 posts
  • Bitnik
  • Location:Canada

Posted Tue Feb 11, 2014 6:30 PM

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:

#133 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,637 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Tue Feb 11, 2014 8:56 PM

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.



#134 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Tue Feb 11, 2014 10:29 PM

KaboomWIPa.gif <---click to animate

SOURCE CODE:Attached File  KaboomWIP.bas   11.96KB   203 downloads

 

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, Tue Feb 11, 2014 10:29 PM.


#135 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • 704 posts
  • Location:Japan

Posted Wed Feb 12, 2014 11:01 AM

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



#136 JoeM_Intellivision OFFLINE  

JoeM_Intellivision

    Stargunner

  • 1,130 posts

Posted Wed Feb 12, 2014 12:14 PM

God Bless all you programmers - it's all Greek to me - appreciate your efforts and collaboration.
Joe.

#137 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,345 posts

Posted Wed Feb 12, 2014 10:41 PM

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



#138 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,637 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Thu Feb 13, 2014 10:49 AM

Just uploaded IntyBASIC compiler v0.4 solving the bug detected by Kiwi.



#139 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • 704 posts
  • Location:Japan

Posted Thu Feb 13, 2014 10:02 PM


 

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.

 

shot0001.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 *8) + 6
	
	REM the offset is subtracted from position of sprite 1 (the B) 
	SPRITE 1, 120 + $300, ((50 - offset) AND $7f) + $100, (34 *8) + 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 "#......."
	
	



#140 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,637 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Thu Feb 13, 2014 10:16 PM

 

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.



#141 Carl Mueller Jr OFFLINE  

Carl Mueller Jr

    Moonsweeper

  • 454 posts
  • Location:Kagoshima, Japan

Posted Fri Feb 14, 2014 2:21 AM

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

#142 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Feb 22, 2014 4:57 AM

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, Sat Feb 22, 2014 5:11 AM.


#143 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Feb 22, 2014 6:04 AM

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, Sat Feb 22, 2014 6:05 AM.


#144 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Feb 22, 2014 6:12 AM

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, Sun Feb 23, 2014 8:56 AM.


#145 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,637 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Sat Feb 22, 2014 7:51 AM

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.

#146 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Feb 22, 2014 8:29 AM

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.

 

Attached Files


Edited by DZ-Jay, Sat Feb 22, 2014 8:52 AM.


#147 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Feb 22, 2014 8:36 AM

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, Sun Feb 23, 2014 8:57 AM.


#148 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • 704 posts
  • Location:Japan

Posted Sun Feb 23, 2014 8:19 AM

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



#149 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sun Feb 23, 2014 8:56 AM

 

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.



#150 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,790 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sun Feb 23, 2014 9:18 AM

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(8)
        MVI@    R4,     R0
        MVO@    R0,     R5
    ENDR
 
        CLRR    R0
        MVII    #$18,   R4
    REPEAT(8)
        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, Sun Feb 23, 2014 9:35 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users