Jump to content
IGNORED

IntyBASIC compiler v0.9 recharged! ;)


nanochess

Recommended Posts

 

IntyBASIC does have an inline ASM "escape valve," and you could use that to insert ORG directives to move things around. That's clumsy and error prone and far from user friendly.

 

 

The largest game you can write without paging the ROM is around 50K words (100K bytes). But to get there, something needs to allocate the code among several disjoint memory areas. The cart.mac facility I wrote is one way to manage it. I'd be happy to help nanochess teach IntyBASIC how to drive its macros so that it simplifies the end programmer experience. Or, IntyBASIC could handle this itself.

:-)

 

While it would be nice to have the compiler auto stuff the code into the 5/6/D/F etc memory maps as needed, I have had success with ASM ORG commands in the actual Basic code to isolate title screens, intermission screens with lots of animation etc into the other memory holes. Not efficient to the last byte, it does work well enough that I haven't had to worry about the 16k barrier. One of my games is over 23k and working on a CC3.

 

That said, by the time I consider my games complete, it would be great to have a version of the compiler that handles the memory partitioning for me.

  • Like 2
Link to comment
Share on other sites

I honestly don't know how IntyBASIC manages the ROM memory map or even if it makes any attempt to manage the ROM memory map, aside from just putting ORG $5000 at the top of the output. In the simple examples I've run through it, it appears to start assembling the game at $5000 and goes linearly after that.

 

If that's the case, then yes, you'll run into a hiccup once the ROM gets big enough to cross the $7000 boundary. That's 8K words (16K bytes).

My current suggestion is in post #75 http://atariage.com/forums/topic/230642-intybasic-compiler-v09-recharged-;/?do=findComment&comment=3091584

 

IntyBASIC does have an inline ASM "escape valve," and you could use that to insert ORG directives to move things around. That's clumsy and error prone and far from user friendly.

Not so easy to use, but fortunately it helps the savvy programmer that wants to get more from IntyBASIC.

 

You could modify intybasic_prologue.asm to pull in "cart.mac", and use ASM statements to insert "ROMSEG" or "ROMSEGSZ" types of directives (really, macros from cart.mac) to move things around. This is slightly less error prone.

 

Or, IntyBASIC could inject these things itself. (Best option, IMHO.) Either it can manage the memory map directly, or it can offload to an abstraction like cart.mac. I honestly don't care either way.

 

 

The largest game you can write without paging the ROM is around 50K words (100K bytes). But to get there, something needs to allocate the code among several disjoint memory areas. The cart.mac facility I wrote is one way to manage it. I'd be happy to help nanochess teach IntyBASIC how to drive its macros so that it simplifies the end programmer experience. Or, IntyBASIC could handle this itself. (Maybe it does already?)

 

The way I set up cart.mac, you can add as many different memory maps as you like, to cater it to whatever board design or other criteria you need to apply. Right now it has two memory maps in the official version—16K, which matches the Mattel 5/6/D/F layout, and 42K, which seemed like a nice Cadillac layout that works well with JLP. (JLP actually supports fairly arbitrary ROM memory maps, although currently it fixes its extra RAM at $8040 - $9F7F.) But, say you're working with a particular board design that wants 5/6/9/A/B. You could add that to cart.mac pretty easily.

 

 

So, nanochess, does IntyBASIC manage the ROM memory map, and if so, how? And if not, does it make sense to target something like cart.mac? I recall you commenting in the past that programmers are free to modify intybasic_prologue.asm/epilogue.asm to suit their needs, including memory map, but I'm not sure that fits with the ease of use you're promoting with the rest of IntyBASIC. :-)

IntyBASIC currently doesn't manage by itself the ROM memory map.

 

I'm not closed to options for memory maps and probably in a future IntyBASIC version I'll integrate an easier way of handling this.

 

Anyway I'm still expecting a real Flash cart (the one from GroovyBee, one from 5-11under and LTO-Flash from you) and from there I'll choose a kind of common memory map compatible with emulator and/or homebrew publishing to be supported comfortably with IntyBASIC.

 

Also I would like to use the extra memory RAM that LTO-Flash has integrated and maybe the ROM page-mapper you've talked about.

Link to comment
Share on other sites

While it would be nice to have the compiler auto stuff the code into the 5/6/D/F etc memory maps as needed, I have had success with ASM ORG commands in the actual Basic code to isolate title screens, intermission screens with lots of animation etc into the other memory holes. Not efficient to the last byte, it does work well enough that I haven't had to worry about the 16k barrier. One of my games is over 23k and working on a CC3.

I'm glad you're making the effort :) :thumbsup:

 

That said, by the time I consider my games complete, it would be great to have a version of the compiler that handles the memory partitioning for me.

I'm thinking in an elegant solution for this, I always have thought in IntyBASIC as a tool that should be of easy usage.

 

Even for myself it would help me greatly to go directly to code games and avoid continuous checking of memory maps, and going for 42K words usage (84 kilobytes) without worrying about locations.

Link to comment
Share on other sites

It's so easy as checking the CFG file to see the memory zones used, if one is exceeded, you can check the LST file and insert an ASM ORG directive to displace manually your program.

How about creating a simple post processing tool that analyses the *.cfg and tells the user that they overran a ROM segment? That way, people new to IntyBASIC get sensible feedback from the tools and don't have to understand all the gory, low level stuff from the get-go.

  • Like 1
Link to comment
Share on other sites

How about creating a simple post processing tool that analyses the *.cfg and tells the user that they overran a ROM segment? That way, people new to IntyBASIC get sensible feedback from the tools and don't have to understand all the gory, low level stuff from the get-go.

 

How about... cart.mac? :-) I'm sure folks are getting tired of hearing me beat that drum...

 

Seriously, if all you did was replace the ROM header with a "ROMSETUP 16K" type of declaration at the top, and add a "ROMEND" at the bottom, it'll report an assembler error if you overflow $5000 - $6FFF. If the programmer adds any other ROMSEG statements, it'll report whether you've overflowed the other ROM segments as well.

 

Newer versions of cart.mac offer a ROMREPORT which shows you how much ROM remains available in each ROM segment for your current memory map. Example:


=================================================================
          Program size:        $0901 (2305 dec) words
          ROM available:       $36FF (14079 dec) words
-----------------------------------------------------------------
       Range    Start    End           :     Used    Avail
         0:     $5000 - $6FFF          :    $0901    $16FF
         1:     $D000 - $DFFF          :    $0000    $1000
         2:     $F000 - $FFFF          :    $0000    $1000
=================================================================
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

  • Like 1
Link to comment
Share on other sites

 

 

How about... cart.mac? :-) I'm sure folks are getting tired of hearing me beat that drum...

 

Seriously, if all you did was replace the ROM header with a "ROMSETUP 16K" type of declaration at the top, and add a "ROMEND" at the bottom, it'll report an assembler error if you overflow $5000 - $6FFF. If the programmer adds any other ROMSEG statements, it'll report whether you've overflowed the other ROM segments as well.

 

Newer versions of cart.mac offer a ROMREPORT which shows you how much ROM remains available in each ROM segment for your current memory map. Example:


=================================================================
          Program size:        $0901 (2305 dec) words
          ROM available:       $36FF (14079 dec) words
-----------------------------------------------------------------
       Range    Start    End           :     Used    Avail
         0:     $5000 - $6FFF          :    $0901    $16FF
         1:     $D000 - $DFFF          :    $0000    $1000
         2:     $F000 - $FFFF          :    $0000    $1000
=================================================================
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

 

In the tradition of "show me the code!"

 

I made a couple of very mild updates to intybasic_prologue.asm and intybasic_epilogue.asm, and one minor update to cart.mac to let IntyBASIC manage setting up the stack. Now I'm able to get a report such as the above when compiling the examples coming from IntyBASIC.

 

Attached are my updates.

$ ./intybasic_linux sprites.bas /tmp/sprites.asm

IntyBASIC compiler v0.9 Oct/10/2014
(c) 2014 Oscar Toledo G. http://nanochess.org/

Compilation finished

$ as1600 -o /tmp/sprites /tmp/sprites.asm
=================================================================
          Program size:        $02ED (749 dec) words
          ROM available:       $3D13 (15635 dec) words
-----------------------------------------------------------------
       Range    Start    End           :     Used    Avail
         0:     $5000 - $6FFF          :    $02ED    $1D13
         1:     $D000 - $DFFF          :    $0000    $1000
         2:     $F000 - $FFFF          :    $0000    $1000
=================================================================
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

$ ./intybasic_linux music.bas /tmp/music.asm

IntyBASIC compiler v0.9 Oct/10/2014
(c) 2014 Oscar Toledo G. http://nanochess.org/

Compilation finished

$ as1600 -o /tmp/music /tmp/music.asm
=================================================================
          Program size:        $0841 (2113 dec) words
          ROM available:       $37BF (14271 dec) words
-----------------------------------------------------------------
       Range    Start    End           :     Used    Avail
         0:     $5000 - $6FFF          :    $0841    $17BF
         1:     $D000 - $DFFF          :    $0000    $1000
         2:     $F000 - $FFFF          :    $0000    $1000
=================================================================
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

ib_updates.zip

Edited by intvnut
  • Like 2
Link to comment
Share on other sites

 

In the tradition of "show me the code!"

 

I made a couple of very mild updates to intybasic_prologue.asm and intybasic_epilogue.asm, and one minor update to cart.mac to let IntyBASIC manage setting up the stack. Now I'm able to get a report such as the above when compiling the examples coming from IntyBASIC.

 

Attached are my updates.

Awesome! I didn't know your cart.mac could generate reports! Indeed it's very useful.

 

It looks like this could go into next version IntyBASIC :) of course with proper credit. Thanks!

 

BTW, a question, can ROMSEGSZ be used with an expression? for example:

 

ROMSEGSZ procedure_end-procedure_start
If it's possible then I could include this just before each PROCEDURE.

 

Of course still I would have to define some optional structure for data (maybe BLOCK/END statements)

Link to comment
Share on other sites

Awesome! I didn't know your cart.mac could generate reports! Indeed it's very useful.

 

It looks like this could go into next version IntyBASIC :) of course with proper credit. Thanks!

 

BTW, a question, can ROMSEGSZ be used with an expression? for example:

 

ROMSEGSZ procedure_end-procedure_start
If it's possible then I could include this just before each PROCEDURE.

 

Of course still I would have to define some optional structure for data (maybe BLOCK/END statements)

 

 

Unfortunately, ROMSEGSZ needs an expression whose value is known. It can take an expression, but if the labels "procedure_end - procedure_start" aren't already defined, then ROMSEGSZ won't work.

 

I'm going to guess your code generator is a fairly simple syntax-directed translator, so you may not have a way to catch instructions and count the size of blocks before emitting them to the code stream. Thus, this presents a bit of a phase-ordering conundrum. Hmmm...

Link to comment
Share on other sites

 

Unfortunately, ROMSEGSZ needs an expression whose value is known. It can take an expression, but if the labels "procedure_end - procedure_start" aren't already defined, then ROMSEGSZ won't work.

 

I'm going to guess your code generator is a fairly simple syntax-directed translator, so you may not have a way to catch instructions and count the size of blocks before emitting them to the code stream. Thus, this presents a bit of a phase-ordering conundrum. Hmmm...

 

That's right. I've an expression parser that creates expression trees, but not yet a statement tree.

 

Anyway I could count instructions and make a buffer for code output, a kind of simple assembler.

 

The problem would be that probably I would need to remove the ASM instruction that gives so much flexibility or limit it to the basic CP1610 instruction set and my own directives. I'll think about it.

Link to comment
Share on other sites

 

That's right. I've an expression parser that creates expression trees, but not yet a statement tree.

 

Anyway I could count instructions and make a buffer for code output, a kind of simple assembler.

 

The problem would be that probably I would need to remove the ASM instruction that gives so much flexibility or limit it to the basic CP1610 instruction set and my own directives. I'll think about it.

 

Well, most of the Intellivision instructions are just 1 or 2 words, with J/JSR being the only 3 word instructions. The other assembly directives you can pass through with ASM, though, could do just about anything. So, perhaps limiting it, and requiring folks to INCLUDE an asm file for more significant assembly code (say, when writing entire functions) might be the way to go.

 

You could probably make a cheesy estimate that each ASM statement counts as 2 words (assuming each ASM holds one CP-1610 instruction), and that would cover 99% of the cases. It would overestimate in many cases, but that should be mostly harmless. The overestimate would only affect that local block of code and the one ROMSEGSZ call. At most, ROMSEGSZ might say something doesn't fit when in fact it does, but that would only happen when the ROM is really full and the block containing the ASM is near the end of the program.

 

Once you start using cart.mac, though, you could also set it to a very generous memory map, and so the condition "the ROM is really full" also would be very rare.

  • Like 1
Link to comment
Share on other sites

Another random problem, curious if anyone thinks of anything obvious:

 

I have a problem with in-game sounds. Now, I'm not playing music in the game. Just one simple on-event sound effect at a time. Like this:

 

SOUND 1,400,15

 

I used it in pINg and it was weird - early on it had problems but I must have gotten it into a nice spot in the code because I'm happy with the result. So now, I'm trying again. What's happening is that the majority of the time, the sound effect is being "clipped". Sometimes so badly that all you get is a lightning-fast blip, almost like noise. I've played around with WAITs and SOUND 1,500,0 to mute it after it's done, loops before and after to isolate it, loops around it to make it last longer, whatever I can think of. Nothing lets it play out, consistently.

 

Is there anything very, very stupid that I could be doing here? Most of the time I'm calling SOUND from within a PROC, but that shouldn't matter? I thought it would just load up the PSG and essentially say "play this, please". But that makes me wonder - using MUSIC, you control duration of a note. What controls how long a SOUND happens for, and such? This code from the game2.bas sample seems simple enough, and works just fine. But mine doesn't :(

 

 

IF BLINK THEN SOUND 1,500,15:BLINK=0 ELSE SOUND 1,,0 'monster die sound

Edited by freeweed
Link to comment
Share on other sites

Another random problem, curious if anyone thinks of anything obvious:

 

I have a problem with in-game sounds. Now, I'm not playing music in the game. Just one simple on-event sound effect at a time. Like this:

 

SOUND 1,400,15

 

I used it in pINg and it was weird - early on it had problems but I must have gotten it into a nice spot in the code because I'm happy with the result. So now, I'm trying again. What's happening is that the majority of the time, the sound effect is being "clipped". Sometimes so badly that all you get is a lightning-fast blip, almost like noise. I've played around with WAITs and SOUND 1,500,0 to mute it after it's done, loops before and after to isolate it, loops around it to make it last longer, whatever I can think of. Nothing lets it play out, consistently.

 

Is there anything very, very stupid that I could be doing here? Most of the time I'm calling SOUND from within a PROC, but that shouldn't matter? I thought it would just load up the PSG and essentially say "play this, please". But that makes me wonder - using MUSIC, you control duration of a note. What controls how long a SOUND happens for, and such? This code from the game2.bas sample seems simple enough, and works just fine. But mine doesn't :(

 

 

If you're using PLAY then you should use SOUND 2 because the music player uses internally a kind of SOUND 0 and SOUND 1

 

When you use SOUND like in your example, you should keep a kind of frame counter for the sound, for example, 10 frames for a ping, that is approximately 1/6 second.

 

If you change it per frame, you'll hear very short tones, in fact the emulator will have trouble emulating sound effects at 1/60 second because of buffering.

Link to comment
Share on other sites

 

If you're using PLAY then you should use SOUND 2 because the music player uses internally a kind of SOUND 0 and SOUND 1

 

When you use SOUND like in your example, you should keep a kind of frame counter for the sound, for example, 10 frames for a ping, that is approximately 1/6 second.

 

If you change it per frame, you'll hear very short tones, in fact the emulator will have trouble emulating sound effects at 1/60 second because of buffering.

 

I think I'm confused. I thought that the whole PLAY/SOUND thing meant that if you are currently PLAYing something, you can't use all the SOUND channels at that time. Which makes sense, there are only so many channels. Are you saying that if my program uses PLAY in the code anywhere, that I'd be limited to SOUND 2 (and have to be using PLAY SIMPLE, I'd think)? I'm seeing this clipping when no PLAY is happening.

 

Frame counter - how do you mean, exactly? I tried a FOR loop around the SOUND command itself (even played with WAITs) but that didn't work. How do I "change it per frame", when the game essentially loops over and over? I guess what I may be asking is how do I abstract the SOUND command out of the "play a sound when things happen" logic, which have to be executed repeatedly (as often as possible, really)? Queue up a SOUND command, only play it on every 10th frame somehow?

 

Not sure if my questions make sense.

Link to comment
Share on other sites

 

If you change it per frame, you'll hear very short tones, in fact the emulator will have trouble emulating sound effects at 1/60 second because of buffering.

 

I'm a little confused by the emulator comment here. jzIntv (and I presume other emulators) seek to generate the same sounds as the Intellivision. Any buffering would just cause the sounds to be delayed slight, but none of them would be dropped.

 

The "groovy" demo I posted years ago played a sample through the PSG by modulating the volume registers. Arnauld posted an even better such demo a few years back. They play fine in emulation.

 

A sound effect that plays for 1/60th of a second will be hard to hear, but not because of anything the emulator does, but rather because the sound effect lasts for 1/60th of a second.

 

 

 

Frame counter - how do you mean, exactly?

 

He means keep a variable somewhere that counts the number of video frames that have gone by. You want the sound effect to stick around for multiple display frames. So, at the point where you trigger the effect, start the counter. Wherever you 'WAIT' in your code (which waits for a frame boundary) or similar, update that counter. When some number of frames have gone by, you know it's time to stop the sound effect.

 

There are multiple ways to do that, but the basic gist is that the code that starts the sound is timewise distant (and likely physically distant) from the code that stops the sound.

 

If you just put a busy loop there that loops for, say, 1/10th or 1/6th of a second, your whole game will pause for that period of time, and that's no good. I've played games that do that, and it's annoying.

Edited by intvnut
  • Like 1
Link to comment
Share on other sites

 

I think I'm confused. I thought that the whole PLAY/SOUND thing meant that if you are currently PLAYing something, you can't use all the SOUND channels at that time. Which makes sense, there are only so many channels. Are you saying that if my program uses PLAY in the code anywhere, that I'd be limited to SOUND 2 (and have to be using PLAY SIMPLE, I'd think)? I'm seeing this clipping when no PLAY is happening.

 

Yes, if you're using PLAY SIMPLE you'll be limited to SOUND 2.

 

Ok, clipping, then let us go ahead.

 

 

Frame counter - how do you mean, exactly? I tried a FOR loop around the SOUND command itself (even played with WAITs) but that didn't work. How do I "change it per frame", when the game essentially loops over and over? I guess what I may be asking is how do I abstract the SOUND command out of the "play a sound when things happen" logic, which have to be executed repeatedly (as often as possible, really)? Queue up a SOUND command, only play it on every 10th frame somehow?

 

Not sure if my questions make sense.

Draw a line with 60 squares horizontally in paper, each square is a video frame.

 

Fill a square with ink, this is where you used SOUND 1,400,15

 

Draw a line until 5 squares ahead, this is what happens if you don't update SOUND (tone keeps working)

 

Leave square 6 without anything inside, this is where you would use SOUND 1,,0

 

You should hear a pure tone without any problem.

 

Now the code for testing it:

 

loop:
  WAIT
  SOUND 1,400,15
  FOR C=0 TO 5:WAIT:NEXT C
  SOUND 1,400,0
  FOR C=0 TO 50:WAIT:NEXT C
  GOTO loop
Now ideally you shouldn't stop your game for every sound effect, so we would rewrite the sound effect like this:

 

loop:
  WAIT
  IF cont1.button <> 0 AND sound_effect = 0 THEN sound_effect=20
  IF sound_effect = 20 THEN SOUND 1,400,15
  IF sound_effect = 15 THEN SOUND 1,,0
  IF sound_effect <> 0 THEN sound_effect = sound_effect - 1
  GOTO loop
This effectively plays a sound effect while your game keeps running, note how it depends on current sound state.

 

Now for sake of completeness, before label loop insert PLAY SIMPLE, run it again and check how sound is chopped, then change SOUND 1 to SOUND 2. ;)

Link to comment
Share on other sites

I'm a little confused by the emulator comment here. jzIntv (and I presume other emulators) seek to generate the same sounds as the Intellivision. Any buffering would just cause the sounds to be delayed slight, but none of them would be dropped.

 

The "groovy" demo I posted years ago played a sample through the PSG by modulating the volume registers. Arnauld posted an even better such demo a few years back. They play fine in emulation.

 

A sound effect that plays for 1/60th of a second will be hard to hear, but not because of anything the emulator does, but rather because the sound effect lasts for 1/60th of a second.

 

I think the emulator giving me these results was an old version of Nostalgia.

 

Still I want to run some "ear" tests when I get my Flash cart to confirm some of my theories between emulation, AY-3-8910 and AY-3-8914.

Link to comment
Share on other sites

Interesting. You were very right about the SOUND 2 being required. But it's not triggered from PLAY in the code (I commented that out and even deleted that for testing), it's triggered from MUSIC being there. What's funky is that it works perfectly for the "ping!" noise in pINg. I guess I don't really have other sound effects so hadn't noticed.

 

Now to make this sound thing actually work. I'm not sure I can make terribly complex sound effects using one tone only, that has to time itself and shut off somewhere else in the code, but I'm sure are tricks :)

 

Or of course I could write intro music myself just using SOUND, and then have all channels available.

Edited by freeweed
  • Like 1
Link to comment
Share on other sites

I remember Joe producing a getkey code longtime ago for Colossal, but if I remember this one is working for a single keystroke to be buffered somewhere... not sure how ti can be translated to an INPUT command... Joe suggestions?

 

You'll need to allocate an array somewhere to hold the input line. Since you're using an ECS, you can allocate that buffer in ECS RAM starting at $4040. The ECS provides 8-bit memory at $4040 - $47FF.

 

If IntyBASIC adds support for input from the ECS keyboard, then it could manage a line buffer in ECS memory. Otherwise, if you drop to assembly code to do this, then you could use ECS memory for that purpose.

 

The next hurdle you'll reach is string manipulation in general. I don't think IntyBASIC really has a full complement of string operations, and you need that for something like Chatterbot. (If I recall correctly, it is an ELIZA-like program, correct?)

Link to comment
Share on other sites

nanochess, I'm porting my little project Chatterbot in intybasic: do I see right that INPUT command is not implemented?

is there any support on the keyboard insertion, or I should use ASM code?

 

Currently there is no support for the ECS keyboard, you will need to code it in assembly.

Link to comment
Share on other sites

I was looking through the source of the IntyBASIC Prologue and I noticed something curious: the comments are bilingual! LOL! To me it's funny because I've noticed that a lot in source code from programmers in Mexico or Spain. In Puerto Rico, for some reason, we always tended to write source code symbols, comments, and documentation in English, so it was very rare to see any Spanish at all.

 

Anyway, I like it. It gives it an International savoir faire. :)

 

    ; NTSC frequency for notes
ntsc_note_table:  PROC
    ; Silencio - 0
    DECLE 0
    ; Octave 2 - 1
    DECLE 1721,1621,1532,1434,1364,1286,1216,1141,1076,1017,956,909
    ; Octave 3 - 13
    DECLE 854,805,761,717,678,639,605,571,538,508,480,453
    ; Octave 4 - 25
    DECLE 427,404,380,360,339,321,302,285,270,254,240,226
    ; Octave 5 - 37
    DECLE 214,202,191,180,170,160,151,143,135,127,120,113
    ; Octave 6 - 49
    DECLE 107,101,95,90,85,80,76,71,67,64,60,57
    ; Octave 7 - 61
    ; Solo caben dos notas más.
    ENDP


    ; Tabla de notas PAL
pal_note_table:  PROC
    ; Silencio - 0
    DECLE 0
    ; Octava 2 - 1
    DECLE 1923,1812,1712,1603,1524,1437,1359,1276,1202,1136,1068,1016
    ; Octava 3 - 13
    DECLE 954,899,850,801,758,714,676,638,601,568,536,506
    ; Octava 4 - 25
    DECLE 477,451,425,402,379,358,338,319,301,284,268,253
    ; Octava 5 - 37
    DECLE 239,226,213,201,190,179,169,159,150,142,134,127
    ; Octava 6 - 49
    DECLE 120,113,106,100,95,89,84,80,75,71,67,63
    ; Octava 7 - 61
    ; Solo caben dos notas más.
    ENDP
For bonus points, the NTSC section is in English while the PAL section is in Spanish. Region-savvy and all! ;)

 

-dZ.

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

OK, I think it's time to revive this post with the "DZ's Special Distro" of IntyBASIC for all those OCS-freaks out there (like me!) that can't bear seeing those dirty eeky binary files commingling with your clean and pure source files. ;)

 

This distro includes a handy Perl script that compiles and assembles your program in one shot. (Living up to it's master's obsessions, intbas.pl creates asm and bin directories during its execution, appropriate for segregating stinky binaries from pristine sources.) Obviously, it requires Perl to be installed in your system, which happens to come with Mac OS X.

 

It also includes all sample programs provided by nanochess. The distro has been updated with the latest version of IntyBASIC (v0.9) and all latest sample programs.

 

I use this layout and the Perl script when toying around with IntyBASIC. I find it handy to be able to just compile and assemble in one step, and to have the assembler generate all symbol, map, and listing files; which are useful for debugging. (Did I mention that I also like to keep files organized by kind?) I thought that perhaps others may find some use for it as well.

You'll have to configure the file paths to use at the top of the script, and perhaps add the script to your binary path environment variable ($PATH).

 

This bundle comes with no guarantees, and was not commissioned nor authorised by nanochess--but given that he "liked" my post with the last version, I figured he doesn't mind too much. ;)

 

Below is the directory layout used by "DZ's Special Distro."

 

Enjoy!

-dZ.

 
=============================================================================
FILE PATH:                              DESCRIPTION:
=============================================================================
+-- intybasic                           Installation directory
    +-- 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
    |    |-- intycolor                  -> IntyColor for Mac OSX
    |    |-- intyColor.exe              -> IntyColor for Windows
    |    `-- intycolor_linux            -> IntyColor for Linux
    |
    +-- examples                        BASIC sample program repository
    |    +-- controller                 Sample Project: controller
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- controller.bin   \_ Game binary in BIN+CFG format
    |    |    |    |-- controller.cfg   /
    |    |    |    |-- controller.ls    -> Assembler listing file
    |    |    |    |-- controller.map   -> Assembler memory map
    |    |    |    |-- controller.rom   -> Game binary in ROM format
    |    |    |    `-- controller.sym   -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- controller.asm   -> Generated assembly source
    |    |    |
    |    |    `-- controller.bas        BASIC source file
    |    |
    |    +-- 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
    |    |
    |    +-- intycolor                  Sample IntyColor Project
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- sample.asm       -> Generated assembly source
    |    |    |
    |    |    |-- colors_reference.bmp  -> Colors reference for bitmaps
    |    |    `-- sample.bmp            -> Sample screen bitmap
    |    |
    |    +-- music
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- music.bin        \_ Game binary in BIN+CFG format
    |    |    |    |-- music.cfg        /
    |    |    |    |-- music.ls         -> Assembler listing file
    |    |    |    |-- music.map        -> Assembler memory map
    |    |    |    |-- music.rom        -> Game binary in ROM format
    |    |    |    `-- music.sym        -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- music.asm        -> Generated assembly source
    |    |    |
    |    |    `-- music.bas             BASIC source file
    |    |
    |    +-- screen
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- screen.bin       \_ Game binary in BIN+CFG format
    |    |    |    |-- screen.cfg       /
    |    |    |    |-- screen.ls        -> Assembler listing file
    |    |    |    |-- screen.map       -> Assembler memory map
    |    |    |    |-- screen.rom       -> Game binary in ROM format
    |    |    |    `-- screen.sym       -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- screen.asm       -> Generated assembly source
    |    |    |
    |    |    `-- screen.bas            BASIC source file
    |    |
    |    +-- scroll
    |    |    +-- bin                   AS-1600 assembler output
    |    |    |    |-- scroll.bin       \_ Game binary in BIN+CFG format
    |    |    |    |-- scroll.cfg       /
    |    |    |    |-- scroll.ls        -> Assembler listing file
    |    |    |    |-- scroll.map       -> Assembler memory map
    |    |    |    |-- scroll.rom       -> Game binary in ROM format
    |    |    |    `-- scroll.sym       -> Assembler symbol table
    |    |    |
    |    |    +-- asm                   IntyBasic compiler output
    |    |    |    `-- scroll.asm       -> Generated assembly source
    |    |    |
    |    |    `-- scroll    .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
    |
    +-- games                           BASIC game program repository 
    |   `-- (empty)                     Add your own programs here.
    |
    +-- lib                             IntyBasic library modules
    |    |-- intybasic_prologue.asm     -> Prologue module
    |    `-- intybasic_epilogue.asm     -> Epilogue module
    |
    |-- manual.txt                      IntyBasic manual
    `-- INTBAS - README.txt             This README file.
 
=============================================================================
Edited by DZ-Jay
  • Like 2
Link to comment
Share on other sites

I was looking through the source of the IntyBASIC Prologue and I noticed something curious: the comments are bilingual! LOL! To me it's funny because I've noticed that a lot in source code from programmers in Mexico or Spain. In Puerto Rico, for some reason, we always tended to write source code symbols, comments, and documentation in English, so it was very rare to see any Spanish at all.

 

Anyway, I like it. It gives it an International savoir faire. :).

 

 

Hehehe, it will disappear in next version.

 

Because my native tongue is Spanish I always write comments in Spanish (except of course when I get paid for programming projects from other countries), anyway Princess Quest for Intellivision is fully commented in Spanish.

 

When the music tracker was translated to English for IntyBASIC, obviously I missed these messages. ;)

 

 

OK, I think it's time to revive this post with the "DZ's Special Distro" of IntyBASIC for all those OCS-freaks out there (like me!) that can't bear seeing those dirty eeky binary files commingling with your clean and pure source files. ;)

 

This distro includes a handy Perl script that compiles and assembles your program in one shot. (Living up to it's master's obsessions, intbas.pl creates asm and bin directories during its execution, appropriate for segregating stinky binaries from pristine sources.) Obviously, it requires Perl to be installed in your system, which happens to come with Mac OS X.

 

It also includes all sample programs provided by nanochess. The distro has been updated with the latest version of IntyBASIC (v0.9) and all latest sample programs.

 

I use this layout and the Perl script when toying around with IntyBASIC. I find it handy to be able to just compile and assemble in one step, and to have the assembler generate all symbol, map, and listing files; which are useful for debugging. (Did I mention that I also like to keep files organized by kind?) I thought that perhaps others may find some use for it as well.

You'll have to configure the file paths to use at the top of the script, and perhaps add the script to your binary path environment variable ($PATH).

 

This bundle comes with no guarantees, and was not commissioned nor authorised by nanochess--but given that he "liked" my post with the last version, I figured he doesn't mind too much. ;)

 

Below is the directory layout used by "DZ's Special Distro."

 

Enjoy!

-dZ.

 

 

In fact I like it enough to ask for your permission to include your Perl script in IntyBASIC v1.0 :) I'm sure a lot of programmers would find it useful.

 

Is it possible?

  • Like 2
Link to comment
Share on other sites

In fact I like it enough to ask for your permission to include your Perl script in IntyBASIC v1.0 :) I'm sure a lot of programmers would find it useful.

 

Is it possible?

Of course! Do as you please with it. In fact, I was thinking of preparing "installer" packages for Windows and Mac that set up the environment, copy the files, and install any necessary libraries or frameworks (e.g., SDL, jzIntv, etc.); like I did for Christmas Carol.

 

If you would like the final v1.0 distribution to be packaged like that, we can talk and I'll make sure to follow your expectations. Otherwise, it'll be just another "unofficial" rogue distro like this one. :lol:

 

dZ.

  • Like 3
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...