Cybearg Posted October 24, 2014 Share Posted October 24, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 24, 2014 Share Posted October 24, 2014 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: Click "Environment Variables..." Then go to the "System variables" pane at the bottom and scroll down to "Path": Highlight Path and click "Edit..." 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. 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. 2 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted October 24, 2014 Share Posted October 24, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted October 25, 2014 Author Share Posted October 25, 2014 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 Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 25, 2014 Share Posted October 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 25, 2014 Share Posted October 25, 2014 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 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 25, 2014 Share Posted October 25, 2014 (edited) 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 October 25, 2014 by intvnut 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 25, 2014 Share Posted October 25, 2014 No need for ROM files whilst developing, at least not at this point. And I *like* everything in one directory for now 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 Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 25, 2014 Share Posted October 25, 2014 (edited) OK fine, it's laziness 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 October 25, 2014 by intvnut Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted October 25, 2014 Share Posted October 25, 2014 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 }"; 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted October 25, 2014 Share Posted October 25, 2014 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? 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted October 25, 2014 Author Share Posted October 25, 2014 So basically you check the stack boundary for overflow on every ISR, right? That's right 1 Quote Link to comment Share on other sites More sharing options...
tacrec Posted October 28, 2014 Share Posted October 28, 2014 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. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted October 29, 2014 Author Share Posted October 29, 2014 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. Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 29, 2014 Share Posted October 29, 2014 (edited) 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 October 29, 2014 by intvnut 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted November 21, 2014 Author Share Posted November 21, 2014 And now there is a compiler even better IntyBASIC v1.0 http://atariage.com/forums/topic/232063-intybasic-compiler-v10-crunchy-tasty/ 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.