Jump to content

Photo

IntyBASIC compiler v1.0 crunchy&tasty :)


384 replies to this topic

#1 nanochess ONLINE  

nanochess

    River Patroller

  • 4,971 posts
  • Coding something good
  • Location:Mexico City

Posted Fri Nov 21, 2014 3:14 PM

Hi everyone.

 

I've put the IntyBASIC compiler v1.0 out of the oven, this compiler has made a long way since its first release in Jan/28/2014 ;)

 

I wanted to put every suggested feature into it, but I went for the most useful first over the ones that were another way of doing things.

 

  • PRINT finally allows to display decimal numbers, the library for this was provided by intvnut (many thanks!)
  • Everyone wanted it, so now there is Intellivoice support using the VOICE statement, the library also provided by all-powerful intvnut. (note: not yet tested in real hardware, but it should work)
  • Added --jlp switch in command line for using 16-bits RAM memory (almost 8000 words for arrays/variables) and also for multiplicacion/division acceleration via hardware. (for JLP boards)
  • Added ABS function (I'm almost sure freeweed suggested this)
  • Support for READ A(x) (requested by CrazyBoss)
  • Added USR function to call easily assembler functions (what you need DZ-Jay ;) )
  • Added DEFINE ALTERNATE so now you can define two separate GRAM blocks in one frame. (Tarzilla asked for this?)
  • Optimization of code generation in several ways so code will be slightly smaller and faster (specially PRINT with strings)
  • Removes extra RETURN at end of procedure if the statement combination RETURN/END is used
  • MUSIC statement alone doesn't activate the tracker module. Only if PLAY is used.
  • Warns if PROCEDURE is used without ending previous PROCEDURE.
  • Also warns of END used without starting PROCEDURE.
  • Intvnut also provided the IntySmap utility for mapping assembly code to BASIC source and easing debugging with jzintv.
  • DZ-Jay provided the intbas.pl script for structuring your projects.

I think this will be more than enough for a long time, because this has taken me a long time! :grin:

 

Enjoy it! 8)

 

Two pretty small updates one hour after this post was published, please download again. Thanks!

 

Edit: IntyColor allows to generate BITMAP statements instead of DATA ones :)

 

Edit: (Dec/15/2014) And some more improvements to IntyBASIC v1.0.1, I think these are way very useful :)

  • Statements DEFINE, SCREEN and PLAY allow the use of an array as reference, in order to ease dynamic modification of data.
  • DEFINE statement allows VARPTR syntax to ease choosing a bitmap from a definition using expressions ;)
  • Corrected total of free variables, it indicated one more than available.
  • Further optimization of code generation for PRINT.
  • Optimization of code generation for array access and PEEK.
  • Optimization of code generation for trees of addition and substraction with constant (PRINT AT and others)
  • Uses an ultra-optimized macro for multiplication up to 127 (provided by DZ-Jay, I had to implement this!! :) )
  • Speed up of code for keypad decoding (it was using way too much processor power)
  • Wind*ws version of IntySmap (I forgot to include it before)
  • Many thanks to Kiwi for contributing Apple Catcher as a game sample.
  • Many thanks to catsfolly for contributing Clowns&Ballons as a game sample.

Edit: (Jan/25/2015) More enhancements for IntyBASIC v1.0.2 :)

 

  • Support for changing title of compiled programs (via --title option in arguments)
  • Support for Cuttle Cart 3, same as JLP but no hardware acceleration for multiplication/division (via --cc3 option)
  • New CONT.* syntax, allows to check both controllers at same time!
  • Support for ON FRAME GOSUB, kind of interrupt support calling IntyBASIC code.
  • New sample frame.bas
  • Added usage instructions when running IntyBASIC without arguments.
  • Manual available in Spanish.

 

Edit: (Feb/18/2015) More enhancements for IntyBASIC v1.0.3 ;)

 

  • Added support for SGN() function (returns -1, 0, or 1 per sign of argument)
  • Added statements WHILE/WEND for loops
  • Added PLAY NONE statement to deactivate music player when needed (reactivate with PLAY SIMPLE/FULL) so you can finally use the noise channel to create big explosions.
  • Added sample of vertically scrolling a large bitmap over screen.
  • Solved bug where some alone statements were taken as labels if followed by colon.
  • Returns status to command line for batch scripts.
  • IntyColor: Support for images of any size (but multiple of 8 in X and Y directions) to support scrolling maps.
  • IntyColor: Added option for base offset in number of GRAM cards.
  • IntyColor: Returns status to command line for batch scripts.
  • IntyColor: Shows current color number and stack color numbers when "choking" in Color Stack mode.

Edit: (Apr/23/2015) Mostly fixes and enhancements for IntyBASIC v1.0.4 :grin:

  • Added support for secondary PSG in ECS (SOUND 5-9). Using it will activate code to deactivate ECS ROM.
  • Added RAND(limit) for getting a random number in the range 0..limit-1 (note it includes mult. routine)
  • Added intvnut routine for fast multiplication, used and included only for expressions saying var * var.
  • Slight optimization when using PRINT with spaces as output.
  • Modulus operator optimizes every power of 2.
  • Multiplication by 32, 64 and 128 is now optimized.
  • Division by 32, 64 and 128 is now optimized.
  • Solved bug where constant in left side of multiplication operator wasn't optimized.
  • Solved bug where if last statement inside last IF was RETURN, PROCEDURE wouldn't insert final RETURN.
  • Solved bug in space counting for 8-bits and 16-bits variables.
  • Solved bug in IntyColor where "wide" bitmaps (longer than 160px) where badly processed.

Attached Files



#2 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 3:25 PM

!!!!!!!!!!!!!!!!!!!!!! VOOOOOOOOOOOOOOOOICE!!!!!!

 

Goddamnit, there goes this weekend. Have I ever said thank you enough for this?

 

Only one comment so far: "Warns if PROCEDURE is used without ending previous PROCEDURE" - maybe I'm reading this wrong, but every single program I've ever written (well, almost) will display warnings. I frequently GOSUB from within another GOSUB. It's going to be very difficult to notice legitimate warnings now.



#3 nanochess ONLINE  

nanochess

    River Patroller

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

Posted Fri Nov 21, 2014 3:27 PM

!!!!!!!!!!!!!!!!!!!!!! VOOOOOOOOOOOOOOOOICE!!!!!!

 

Goddamnit, there goes this weekend. Have I ever said thank you enough for this?

 

Only one comment so far: "Warns if PROCEDURE is used without ending previous PROCEDURE" - maybe I'm reading this wrong, but every single program I've ever written (well, almost) will display warnings. I frequently GOSUB from within another GOSUB. It's going to be very difficult to notice legitimate warnings now.

 

No problems if you use PROCEDURE/END nested right (GOSUB doesn't affect), besides it's only a warning.

 

The assembler can still process the generated programs, but intvnut has said AS1600 will not accept bad nested PROCs in the future.



#4 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,824 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 21, 2014 3:29 PM

!!!!!!!!!!!!!!!!!!!!!! VOOOOOOOOOOOOOOOOICE!!!!!!

 

Goddamnit, there goes this weekend. Have I ever said thank you enough for this?

 

Only one comment so far: "Warns if PROCEDURE is used without ending previous PROCEDURE" - maybe I'm reading this wrong, but every single program I've ever written (well, almost) will display warnings. I frequently GOSUB from within another GOSUB. It's going to be very difficult to notice legitimate warnings now.

 

He means that code like this generates a compile time warning:

FRED       Procedure
           PRINT "Fred"
           RETURN

BARNEY     Procedure
           PRINT "Barney"
           RETURN

And this does not.

FRED      Procedure
          PRINT "Fred"
          RETURN
          End

BARNEY    Procedure
          PRINT "Barney"
          RETURN
          End

Edited by intvnut, Fri Nov 21, 2014 3:30 PM.


#5 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,824 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 21, 2014 3:31 PM


  • Intvnut also provided the IntySmap utility for mapping assembly code to BASIC source and easing debugging with jzintv.

 

 

I don't have a lot of time right now (I'm at work), but the short version is this:  With this utility, you can do source-level debug of your IntyBASIC program in jzIntv's built in debugger.  :D



#6 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 3:32 PM

Oh. So nothing to do with what I'm worried about. Then I'm all good :)

 

Edit: nanochess, how could you not mention this - it outputs how many 8 and 16 bit variables you're using, out of the total available. That is INSANELY handy. Also 72 16 bit vars? Wow. I've done a lot of optimization because I thought I was limited to a lot less. This opens up a bunch of possibilities.

 

First compile of GoatNom ends up with a completely broken game. I'm going to have to see what the heck is going on.

 

Edit: it's something to do with collision detection and background cards. This line here:

 

IF (COL7 AND $100)

 

Now triggers on ANY card regardless of what's present. Before it would only be true if there were pixels defined in that card. The manual says this:

 

bit 8 means collision against background pixel (pixel set not color 7)

 

But... that's not how it used to work. Did you fix something here, and I've been mis-using this? I'd then ask the question - how does one detect collision with background cards?


Edited by freeweed, Fri Nov 21, 2014 3:41 PM.


#7 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 3:45 PM

Also I'm going to be a serious pain in the ass and report that voice.bas does not produce anything for me. And yes, my jzintv build does work with Intellivoice ROMs :)



#8 nanochess ONLINE  

nanochess

    River Patroller

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

Posted Fri Nov 21, 2014 3:50 PM

Oh. So nothing to do with what I'm worried about. Then I'm all good :)

 

Edit: nanochess, how could you not mention this - it outputs how many 8 and 16 bit variables you're using, out of the total available. That is INSANELY handy. Also 72 16 bit vars? Wow. I've done a lot of optimization because I thought I was limited to a lot less. This opens up a bunch of possibilities.

 

First compile of GoatNom ends up with a completely broken game. I'm going to have to see what the heck is going on.

 

Edit: it's something to do with collision detection and background cards. This line here:

 

IF (COL7 AND $100)

 

Now triggers on ANY card regardless of what's present. Before it would only be true if there were pixels defined in that card. The manual says this:

 

bit 8 means collision against background pixel (pixel set not color 7)

 

But... that's not how it used to work. Did you fix something here, and I've been mis-using this? I'd then ask the question - how does one detect collision with background cards?

 

My mistake, please download again the file, I've updated intybasic_epilogue.asm. There is one variable less in the 16-bits area, but I don't have time to recompile IntyBASIC right now.

 

Also I'm going to be a serious pain in the ass and report that voice.bas does not produce anything for me. And yes, my jzintv build does work with Intellivoice ROMs :)

 

Have you ran jzintv with the switch -v1 ? ;)



#9 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 3:57 PM

 

My mistake, please download again the file, I've updated intybasic_epilogue.asm. There is one variable less in the 16-bits area, but I don't have time to recompile IntyBASIC right now.

 

 

Have you ran jzintv with the switch -v1 ? ;)

 

Muchas gracias, all fixed!

 

No, I have never used -v1. Intellivoice ROMs that I have never required it. That being said - it works now. This is COOOOOOOOOOOOOOL.

 

Expect a heck of a lot of voice support in homebrew in the coming months, boys!

 

Question for intvnut - in a previous thread you mentioned some sample voice data that has been made available. I'm presuming this is what nanochess has incorporated here; seems like a few basic phonemes are available. Now - obviously there's a way to record and encode your own voice data, after all that's what they did back in the day. Without getting too deep for the moment - my understanding is that the voice chip is really just a fancy PSG that's optimized for human speech noises (layman's explanation). So - can I feed this routine arbitrary binary data to see what happens? Without yet getting into the exact encoding mechanisms and such? (Does my question even make sense...?)



#10 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,824 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 21, 2014 3:58 PM

Also I'm going to be a serious pain in the ass and report that voice.bas does not produce anything for me. And yes, my jzintv build does work with Intellivoice ROMs :)

 

You need the -v1 switch.  jzIntv does detect the original voice games by CRC and turns voice on for you, but it has no means to detect new games that use voice.



#11 nanochess ONLINE  

nanochess

    River Patroller

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

Posted Fri Nov 21, 2014 3:58 PM

I wanted a boxed Sheldon Cooper, but I could only get this :lol:

	VOICE INIT

loop:	VOICE PLAY penny
	FOR A=1 TO 50
	WAIT
	NEXT A
	GOTO loop

penny:  VOICE PP, EH, NN1, IY, PA4, PA4, PA4, 0



#12 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 4:05 PM

Another weird one - the sound "XR" does not work. Gives an assembler error "undefined symbol  _XR" if it's present anywhere in the VOICE data.



#13 nanochess ONLINE  

nanochess

    River Patroller

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

Posted Fri Nov 21, 2014 4:08 PM

Another weird one - the sound "XR" does not work. Gives an assembler error "undefined symbol  _XR" if it's present anywhere in the VOICE data.

 

Oops! it's XR2, just updating this in the manual.



#14 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 4:14 PM

 

Oops! it's XR2, just updating this in the manual.

 

That's the only one I could find. Everything else checks out. I've already got it spouting foul language (almost):

 

    VOICE GG2,OY
    VOICE FF, UH, KK2
    VOICE YY2,OR,SS,EH,LL,FF,PA1,0
  

The OR is a very different voice. I'm going to have a lot of fun playing with this! Xmas came early :D


Edited by freeweed, Fri Nov 21, 2014 4:15 PM.


#15 nanochess ONLINE  

nanochess

    River Patroller

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

Posted Fri Nov 21, 2014 4:15 PM

 

That's the only one I could find. Everything else checks out. I've already got it spouting foul language (almost):

 

    VOICE GG2,OY
    VOICE FF, UH, KK2
    VOICE YY2,OR,SS,EH,LL,FF,PA1,0
  

The OR is a very different voice. I'm going to have a lot of fun playing with this! Xmas came early :D

 

OMG! I've created a monster!

 

:lol: :lolblue:



#16 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 4:22 PM

There doesn't seem to be a good sound for the "oh" in "go". Edit - no, it's "OW". Not what I expected. Also "OR" should probably not be in the list of sounds - it's its own word, like the MATTEL phrase and PRESS. That's why it sounded so weird. Better cursing:

 

    VOICE GG3,OW,PA2
    VOICE FF,UH,KK2,PA2
    VOICE YY2,OW,RR2,SS,EH,LL,FF,PA1,0

 

 

I plan on writing a table of "sounds like" translation table for this, once I get my feet wet. I am not an expert on this stuff but man - with the ROM space we have available, the possibilities are endless. It's a bit robotic compared to most Intellivoice games but I am super impressed with the implementation.


Edited by freeweed, Fri Nov 21, 2014 4:29 PM.


#17 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 4:37 PM

Also because no speech synthesizer is complete without it:

 

    VOICE GG2,RR2,IY,TT1,NG1,SS,PA1
    VOICE PP,RR2,OW,FF,EH,SS,ER1,PA1
    VOICE FF,AA,LL,KK1,UH,NN1,PA1
    VOICE WW,UH,LL,DD1,PA1
    VOICE YY1,UW1,PA1
    VOICE LL,AY,KK1,PA1
    VOICE TT1,UW1,PA1
    VOICE PP,LL,EY,PA1
    VOICE AA,PA1
    VOICE GG2,EY,MM,PA1
    VOICE UH,FF,PA1
    VOICE CH,AE1,SS,SS,PA1,0

 

I'll stop polluting this thread now. We should start a thread specifically for IntyVOICE :)


Edited by freeweed, Fri Nov 21, 2014 4:38 PM.


#18 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,824 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 21, 2014 4:38 PM

Question for intvnut - in a previous thread you mentioned some sample voice data that has been made available. I'm presuming this is what nanochess has incorporated here; seems like a few basic phonemes are available. Now - obviously there's a way to record and encode your own voice data, after all that's what they did back in the day. Without getting too deep for the moment - my understanding is that the voice chip is really just a fancy PSG that's optimized for human speech noises (layman's explanation). So - can I feed this routine arbitrary binary data to see what happens? Without yet getting into the exact encoding mechanisms and such? (Does my question even make sense...?)

 

The technical term for what's in the Intellivoice is that it has an LPC-12 Vocal Tract Model.  LPC stands for Linear Predictive Coding, and 12 refers to the "order" of the model.  (LPC-12 uses a 12th order model.  In practical terms, the function that computes the next sample has 12 coefficients on 12 multiplies.)

 

The Intellivoice actually takes coded data that updates the coefficients on that model, as well as the "excitation" that drives the model.  (If you want to read up more on this, google "LPC" and "vocal tract model", and you can find more math than you can shake a stick at.)

 

Throwing random data at the Intellivoice is unlikely to get you useful results.  The Intellivoice has a small processor that decodes the coded data, and if you send garbage to it, it gets cranky and will jump off in the weeds, generally going silent at that point, or leaving an annoying buzzing sound.  Not really much fun, and not really useful.

 

I already went through all that pain for you.  Frank Palazzolo and I reverse engineered the Intellivoice data formats.  I actually interfaced a real Intellivoice to jzIntv running on my PC so I could experiment on it.  Frank got me started and then I was able to work out 98% of the opcode bits from there.  The result was this document:  http://spatula-city...._instr_set.html

 

If you just want to make unique sound effects with the Intellivoice, you can send whatever data you like as long as you encode it within the framework of the SP0256 instruction set.  You can also use the voice driver to trigger those samples, and use the Intellivoice as a source of additional sound effects.

 

If you want to play voices, then you'll have to encode voice data down to the actual Intellivoice data.  That's considerably more involved.

 

I do have some rather finnicky tools I've put together that do that, but they're far from ready for prime time.  Generally, it takes me several tries of tweaking the inputs to the code to get an acceptable, intelligible sample out the other side.  Also, all of the voice data is "uncompressed," and so even small samples are huge.

 

In the meantime, see if anyone recognizes where this sample comes from...

Attached Files


Edited by intvnut, Fri Nov 21, 2014 4:53 PM.


#19 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,824 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 21, 2014 4:46 PM

There doesn't seem to be a good sound for the "oh" in "go". Edit - no, it's "OW". Not what I expected. Also "OR" should probably not be in the list of sounds - it's its own word, like the MATTEL phrase and PRESS. That's why it sounded so weird. Better cursing:

 

    VOICE GG3,OW,PA2
    VOICE FF,UH,KK2,PA2
    VOICE YY2,OW,RR2,SS,EH,LL,FF,PA1,0

 

 

I plan on writing a table of "sounds like" translation table for this, once I get my feet wet. I am not an expert on this stuff but man - with the ROM space we have available, the possibilities are endless. It's a bit robotic compared to most Intellivoice games but I am super impressed with the implementation.

 

 

This data sheet should be helpful:  http://www.futurebots.com/spo256.pdf

 

Those are the same allophones as what IntyBASIC's using.  Flip to the middle (page 5 of the PDF, page 8 of the original document) for a description of the phonemes, and example phrases.


Edited by intvnut, Fri Nov 21, 2014 4:47 PM.


#20 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 4:53 PM

OK, so it's a fair bit more complicated than bit-banging the PSG. :P

 

And very cool on that data sheet. Now, in another thread you referred to "AL2 samples" - is this what we're talking about? All of the various KK, EH, etc? Or are these sounds basically part of the chip itself (the data sheet seems to hint strongly at that).

 

And I guess the obvious question - Mattel must have had some fairly sophisticated tools to break their recordings down into a format that works. Any chance Keith acquired this IP (the tools) with everything else and is willing to share with the community? And yes, I realize how potentially hilarious that question is. Or are we basically stuck at reverse engineering what they did?


Edited by freeweed, Fri Nov 21, 2014 5:11 PM.


#21 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,824 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 21, 2014 5:24 PM

OK, so it's a fair bit more complicated than bit-banging the PSG. :P

 

And very cool on that data sheet. Now, in another thread you referred to "AL2 samples" - is this what we're talking about? All of the various KK, EH, etc? Or are these sounds basically part of the chip itself (the data sheet seems to hint strongly at that).

 

The SP0256-AL2 is the chip that that datasheet refers to.  The chip in the Intellivoice is the SP0256-012, which has different speech data in its onboard ROM.  The data is "built in" to the extent that it's held in an on-chip 2K byte ROM.   Take a look here.  The ROM is the large rectangular region in the upper right that takes up most of the upper right corner of the die.  Frank dumped the speech data from the AL2 chip, and I reworked it into a form that allows us to download it and play it on the SP0256-012 that's in the Intellivoice.  Magic!

 

 

 


And I guess the obvious question - Mattel must have had some fairly sophisticated tools to break their recordings down into a format that works. Any chance Keith acquired this IP (the tools) with everything else and is willing to share with the community? And yes, I realize how potentially hilarious that question is. Or are we basically stuck at reverse engineering what they did?

 

Not just sophisticated tools, but also a recording studio as well.  Also, having spoken to folks who've worked in that type of business:  Typically all of the speech data then gets hand-edited by experts to correct encoding artifacts, etc.  One of my old supervisors said that there was one lady in his previous organization who could pinpoint the bad coefficient like nothing.  He'd never seen anything like it.  No one else could match her for editing encoded speech data.

 

From the stories I've read and seen regarding the original tool chain, that environment was present at Mattel Electronics too, so it's unlikely they had very friendly turn-key tools.  It's more likely it was low level finnicky stuff like what I've cobbled together.

 

If you can find the videos from Intellivision Lives—I think they're up on YouTube now—the videos from Steven Roney and Bill Fisher about Space Spartans touch on some of the fun voice encoding challenges they were up against.



#22 Tarzilla OFFLINE  

Tarzilla

    Stargunner

  • 1,916 posts
  • Huh?
  • Location:Alberta, Canada

Posted Fri Nov 21, 2014 5:40 PM

Hi everyone.

 

I've put the IntyBASIC compiler v1.0 out of the oven, this compiler has made a long way since its first release in Jan/28/2014 ;)

 

I wanted to put every suggested feature into it, but I went for the most useful first over the ones that were another way of doing things.

 

  •  
  • Everyone wanted it, so now there is Intellivoice support using the VOICE statement, the library also provided by all-powerful intvnut. (note: not yet tested in real hardware, but it should work)

Great, thanks to you I can throw away all the hand inserted assembly for Intellivoice I've been working on the the last month and replace it with something that actually works! Thanks!



#23 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 5:46 PM

Great, thanks to you I can throw away all the hand inserted assembly for Intellivoice I've been working on the the last month and replace it with something that actually works! Thanks!

 

I've had a browser tab open on the previous Intellivoice thread for a couple of weeks now, ready to do exactly what you did. I just needed some spare time and mental cycles to take a first crack at it.

 

Procrastination pays off once again!



#24 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,824 posts
  • Location:@R6 (top of stack)

Posted Fri Nov 21, 2014 8:41 PM

I don't have a lot of time right now (I'm at work), but the short version is this:  With this utility, you can do source-level debug of your IntyBASIC program in jzIntv's built in debugger.  :D

 

Ok, here's a screen shot showing some fun stuff.

 

jzintv_basic_debug.png

 

What you see here is 'sprites.bas' running in jzIntv's debugger.  Notice that column in the middle that shows what BASIC statement each assembler statement is part of?  That's what we've enabled here.

 

It's not completely tight integration, but it's a step forward.  To see your BASIC program in jzIntv's debugger, do the following:

  • Compile your game as always with IntyBASIC:                         intybasic game.bas game.asm
  • Ask AS1600 for a source map file with the -j flag:                       as1600 -o game -l game.lst -j game.smap game.asm
  • Run the new "intysmap" utility on the source map file:                   contrib/intysmap game.smap
  • Now tell jzIntv about the source map file when you launch the debugger:    jzintv -d --src-map=game.smap game

Now jzIntv will show the IntyBASIC source alongside the disassembly when running your game in jzIntv's debugger.

 

You can go a step further and have jzIntv recognize labels from the assembly code by adding the -s flag to AS1600, and --sym-file to the jzIntv command line:

  • Compile your game as always with IntyBASIC:                         intybasic game.bas game.asm
  • Ask AS1600 for a source map file with the -j flag:                       as1600 -o game -l game.lst -j game.smap -s game.sym game.asm
  • Run the new "intysmap" utility on the source map file:                   contrib/intysmap game.smap
  • Now tell jzIntv about the source map file when you launch the debugger:    jzintv -d --src-map=game.smap --sym-file=game.sym game

Now jzIntv will know about the various labels from the generated assembly.  This doesn't necessarily correlate well back to the original BASIC source, but it can still be helpful.  For example, WAIT maps to _wait, so this additional flag will tell jzIntv about _wait. 

 

Play around with it.  See what you think.  I'm sure it can be improved.

 

BTW, down the road, the intysmap utility won't be necessary.  I worked with nanochess to define a new directive that builds the required information into the generated ASM file in such a way that the next release of AS1600 will extract it automatically.  :D



#25 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Nov 21, 2014 9:31 PM

I touched on this, but for any programmers not paying attention:

 

The compiler now provides some great feedback in terms of how much RAM you're using for variables, and how much you have left. For example, this is GoatNom after I've included VOICE and MUSIC support:

 

135 used 8-bit variables of 178 available
15 used 16-bit variables of 42 available
 

The "available" numbers will change depending on what you compile in (ie: what you use in your code). Several of nanochess's routines take a chunk out of this. VOICE support takes quite a few out of the 16 bit variables (something like 30 I think). MUSIC takes a fair bit of the 8 bit (again something like 30). And neither are comprehensive measures, I'm just going by memory here. But wow, there's still a ton of room to play around in. And I've been very lazy on a large new chunk of code, so I can reclaim some of that space.

 

Anyway, an extremely handy addition as we start getting more and more complicated with IntyBASIC games. I've avoided a lot of arrays as they use a goodly amount of space, but at least now I can keep easier tabs on it.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users