Jump to content

Recommended Posts

I just use a build.bat file I made to compile, assemble, and run the game:

@ECHO OFF
..\intybasic main.bas ..\output.asm ..\
..\as1600 -o ..\output.bin -l ..\output.lst ..\output.asm
..\jzintv -e ..\exec.bin -g ..\grom.bin ..\output.bin

I just make sure that the game's primary BASIC file is called main.bas, stick it in a subdirectory of IntyB (which holds the emulator, BIOS, assembler, and compiler) and then just run it when I want to check on changes.

  • Like 1

BTW, if you don't want to dump copies of the tools in the IntyBASIC directory, you could set up some environment variables instead. That's what I do. Set up PATH to include the directory with jzIntv/SDK-1600's EXEs, copy the EXEC/GROM into jzIntv's 'rom' directory, and so on.

 

In Windows (at least up through Windows 7), you want to go to the System Properties 'Advanced' tab:

 

post-14113-0-00817700-1414187614_thumb.png

 

Click "Environment Variables..." Then go to the "System variables" pane at the bottom and scroll down to "Path":

 

post-14113-0-95555600-1414187640_thumb.png

 

Highlight Path and click "Edit..."

 

post-14113-0-14622700-1414187696_thumb.png

 

Append at the end the path to jzIntv's "bin" directory, separated from the previous directory by a semicolon. Use the actual directory you extracted it to here. What I typed in the screen shot is an example.

 

post-14113-0-95335100-1414187702_thumb.png

 

You can also set additional environment variables to make your life easier:

  • AS1600_PATH gives a list of directories to search for INCLUDEs. I usually add jzintv\examples\library to this path. You can add multiple directories there, and as1600 will search them all. In Windows, separate each path by a semicolon.
  • JZINTV_ROM_PATH gives a list of directories to search for ROMs, including exec.bin and grom.bin. jzIntv will also search "..\rom" relative to the directory that holds jzintv.exe if it can.

By setting those, you can run jzIntv and as1600 from any directory and they're "just always there". No copying executables to your project directory or anything. Much more convenient.

 

 

  • Like 2

By setting those, you can run jzIntv and as1600 from any directory and they're "just always there". No copying executables to your project directory or anything. Much more convenient.

 

 

Yup, that's what I do. Except that I also create aliases or wrapper scripts to all the executables with the flags that I commonly use.

 

In the case of IntyBASIC, the old version of the script used to make symbolic links to the prologue and epilogue libraries, which were neatly tucked away in the "lib" directory. That's because older versions of the compiler used to require them being in the current directory.

  • Like 1

Well, guys, I made a small mistake in the distribution, the intybasic_epilogue.asm file included one isn't the latest one, so it misses the code for the stack check feature.

 

It will be updated for v1.0, but in the meanwhile if someone wants to test the stack check feature, add this code to your intybasic_epilogue.asm (the first line is the reference for inserting the code)

        MVO     R0,     $20     ; Activates display

    IF DEFINED intybasic_stack
	CMPI #$308,R6
	BNC @@vs
	MVI $21,R0	; Activates Color Stack mode
	CLRR R0
	MVO R0,$28
	MVO R0,$29
	MVO R0,$2A
	MVO R0,$2B
	MVII #@@vs1,R4
	MVII #$200,R5
	MVII #20,R1
@@vs2:	MVI@ R4,R0
	MVO@ R0,R5
	DECR R1
	BNE @@vs2
	RETURN

	; Stack Overflow message
@@vs1:	DECLE 0,0,0,$33*8+7,$54*8+7,$41*8+7,$43*8+7,$4B*8+7,$00*8+7
	DECLE $4F*8+7,$56*8+7,$45*8+7,$52*8+7,$46*8+7,$4C*8+7
	DECLE $4F*8+7,$57*8+7,0,0,0

@@vs:
    ENDI

I just use a build.bat file I made to compile, assemble, and run the game:

@ECHO OFF
..\intybasic main.bas ..\output.asm ..\
..\as1600 -o ..\output.bin -l ..\output.lst ..\output.asm
..\jzintv -e ..\exec.bin -g ..\grom.bin ..\output.bin

I just make sure that the game's primary BASIC file is called main.bas, stick it in a subdirectory of IntyB (which holds the emulator, BIOS, assembler, and compiler) and then just run it when I want to check on changes.

 

BASH version for the Linux/OSX folks in the audience:

 

./intybasic_linux $1.bas $1.asm

./as1600 -o $1.bin -l $1.lst $1.asm

./jzintv -z1 $1.bin

 

Gives you all of your output files with the same name. Very handy when you want to keep several projects on the go. Just run the script as ./compile.sh gamename

 

Of course all your tools, output, etc end up in one ugly directory, but with everything named as such, I find it self-organizes remarkably well. Combine with Kate where you can have many text files open at once, and it's a great way to flip around between various source files, check your output listings, and heck flip between different versions of a game with just a couple of keystrokes on the command line.

 

Well, guys, I made a small mistake in the distribution, the intybasic_epilogue.asm file included one isn't the latest one, so it misses the code for the stack check feature.

 

 

OK, so I'm not completely crazy. I was testing it one day and it didn't seem to be working, but it was late and I figured maybe I wasn't blowing my stack, so it just had to be me being stupid.

 

I also noticed the bilingual source; made me chuckle. I'm known to pepper up my source with swearing in various languages at times but I assumed this was just the result of Senor Toledo being.. well, Senor Toledo ;)

  • Like 1

 

BASH version for the Linux/OSX folks in the audience:

./intybasic_linux $1.bas $1.asm
./as1600 -o $1.bin -l $1.lst $1.asm
./jzintv -z1 $1.bin

Gives you all of your output files with the same name. Very handy when you want to keep several projects on the go. Just run the script as ./compile.sh gamename

 

Of course all your tools, output, etc end up in one ugly directory, but with everything named as such, I find it self-organizes remarkably well. Combine with Kate where you can have many text files open at once, and it's a great way to flip around between various source files, check your output listings, and heck flip between different versions of a game with just a couple of keystrokes on the command line.

 

With a minor tweak, you can have AS1600 output both BIN+CFG and ROM versions of your program:

.

./intybasic_linux $1.bas $1.asm
./as1600 -o $1 -l $1.lst $1.asm  ; leave suffix off of target to -o to get both BIN and ROM versions output together
./jzintv -z1 $1.bin

.

And again, in Linux/OSX, I recommend placing these tools in your $PATH, so that you don't need to copy them into your project directory. Once you do that, you can remove the "./" from the front of each line.

 

FWIW, jzIntv's debugger offers some additional capabilities that could make it interesting for IntyBASIC. It can load the symbol table output from AS1600, and it can load a source-map from AS1600. This gives you the ability to do source-level debugging at the assembly level.

 

With some additional information, in theory jzIntv could know about IntyBASIC variables and the IntyBASIC => assembly mapping, and show you which IntyBASIC statement you're executing in jzIntv's debugger.

 

For those of you who want to experiment with what's there already, add the following to your AS1600 and jzIntv command lines:

.

as1600 -o game -l game.lst -j game.smap -s game.sym game.asm
jzintv -d --src-map=game.smap --sym-file=game.sym game.bin

.

Notice the flags involving "game.smap" and "game.sym". Those are the important ones. The first is the source-map, which relates assembly source lines to addresses in the ROM file. The second one is the symbol table, which gives the mappings between symbols and values.

 

 

 

Note that how jzIntv formats its output depends on how many columns wide your terminal window is. In Windows, use the debugger command >123 to change the width of the window, replacing 123 with the number of columns. In OSX and Linux, resizing your window by dragging the edge generally is sufficient.

Edited by intvnut
  • Like 1

No need for ROM files whilst developing, at least not at this point. And I *like* everything in one directory for now :P Actually it's mostly because I can't stand maintaining unwieldly $PATHs across lots of different systems. Not for every tool I use, anyway.

 

 

 

OK fine, it's laziness :P

OK fine, it's laziness :P

 

 

Interestingly for me, setting up $PATH is also out of laziness. If I edit anything in jzIntv or as1600 or the like, I don't want to have a gajillion copies laying around that all need updates. I like being able to walk into a random directory and saying "jzintv foo" and it just works, and as a bonus always brings me the latest build of jzIntv. ;)

Edited by intvnut

I also use $PATH, although I've been known to make symbolic links in "/usr/bin/" just so I don't have to "promote" some ugly directory into my pretty execution path.

 

If you check out the script I included in the IntyBASIC distro, the typical command line that I use for the assembler is:

 

my $cmd_line  = "${ as1600 } -o ${ bin_dir }/${ name } -l ${ bin_dir }/${ name }.ls -s ${ bin_dir }/${ name }.sym -j ${ bin_dir }/${ name }.map ${ asm_dir }/${ asm_file }";
  • Like 1

Well, guys, I made a small mistake in the distribution, the intybasic_epilogue.asm file included one isn't the latest one, so it misses the code for the stack check feature.

 

It will be updated for v1.0, but in the meanwhile if someone wants to test the stack check feature, add this code to your intybasic_epilogue.asm (the first line is the reference for inserting the code)

        MVO     R0,     $20     ; Activates display

    IF DEFINED intybasic_stack
	CMPI #$308,R6
	BNC @@vs
	MVI $21,R0	; Activates Color Stack mode
	CLRR R0
	MVO R0,$28
	MVO R0,$29
	MVO R0,$2A
	MVO R0,$2B
	MVII #@@vs1,R4
	MVII #$200,R5
	MVII #20,R1
@@vs2:	MVI@ R4,R0
	MVO@ R0,R5
	DECR R1
	BNE @@vs2
	RETURN

	; Stack Overflow message
@@vs1:	DECLE 0,0,0,$33*8+7,$54*8+7,$41*8+7,$43*8+7,$4B*8+7,$00*8+7
	DECLE $4F*8+7,$56*8+7,$45*8+7,$52*8+7,$46*8+7,$4C*8+7
	DECLE $4F*8+7,$57*8+7,0,0,0

@@vs:
    ENDI

So basically you check the stack boundary for overflow on every ISR, right?

  • Like 1

Is it possible to convert an asm to IntyBasic? Would that make it easier to see what's going on in the code? Asm language is too much to re-learn and too little time.

Yes, it's possible, but only manually.

Is it possible to convert an asm to IntyBasic? Would that make it easier to see what's going on in the code? Asm language is too much to re-learn and too little time.

 

If you mean arbitrary assembly code (ie. an existing game originally written in assembly), that seems doubtful. You might be able to get a rough translation, but it'd be fairly rough going and not terribly easy to understand.

 

An automated translation would turn something like this:

     MVI $015D, R0
     MVO R0, $0173

Into something like this:

     R0 = PEEK( 349 )
     POKE 371, R0

Not terribly illuminating.

 

For a meaningful result, you'd need to translate manually, which means you would need to actually understand the original code.

 

 

Now, if you're trying to reconstruct a .bas file from the .asm file output by IntyBASIC, that's much easier. The original .bas file is interleaved in with the .asm output. ;) But something tells me that's not what you're after.

Edited by intvnut
  • Like 1
  • 4 weeks later...

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