Jump to content
IGNORED

a few quick questions about larger projects and variable names


Recommended Posts

Hi everyone, I'm making steady progress and things are working well so far..  about to get into the sound section next.  However as I progress a few questions popped up in how you all do your projects.  

 

1. so far i've seen variables named very simple things like "c" and such.  can we give variables more complex names?  any limits like say.. 8 characters max?  

 

2. as your projects get more complex are you putting all of your code into one big bas file or are you able to break up your code into separate files to perhaps help keep things in manageable chunks?  

 

3. what text editor(s) do you use?  I started with textedit for mac, but now i'm using sublime text.  maybe there is something out there that perhaps is even made to use intellisensing with intybasic commands? 

 

 

Link to comment
Share on other sites

1. As far as I know, your variable names can be any length. Shorter variables names are of course easier to type. Single letter variables are useful for temporary use, loop variables and similar while longer variable names are more descriptive, like boatsizetime, dest_y, impact, cpuhand to take a few examples from my own projects. Experiment, the compiler probably will warn or bail out if you exceed its capacities!

 

2. You can indeed use INCLUDE to combine parts of your code or data. Usually you'd include constants.bas to keep fewer magic numbers in the code, or perhaps include graphics data separate from the code, depending on how large files you want to wade through. My projects so far have been small enough to not split it up into parts.

 

3. YMMV. To ask about editors is like asking which religion you subscribe to. Personally I'm an Emacs guy and have developed my own IntyBASIC-mode that while it doesn't implement syntax highlighting, at least invokes the compiler + assembler chain from within the editor, instead of using a shell prompt to run either the SDK commands or the compiler manually. However I keep a shell in Emacs to launch the emulator from, instead of a separate command shell. I know the topic has been raised if anyone has a vim mode for IntyBASIC but I haven't kept track if that has been implemented or is just on a wish list. Same about other editors - use what you like.

  • Like 1
Link to comment
Share on other sites

2 hours ago, carlsson said:

use INCLUDE to combine

ah ok so basically you compile the main.bas file but in that .bas file you INCLUDE the names of other .bas files? 

 

2 hours ago, carlsson said:

religion you subscribe to

yes very much understood! :)   I just wanted to be sure there might be an editor that was ready to go with intybasic commands and such.   I definitely need to look at @DZ-Jay 's SDK as even as modest as my progress I would like to improve the compile / execute flow to less "up up up enter" "up up up enter" "up up up enter"

Link to comment
Share on other sites

I suppose the as1600 assembler could accept multiple files as well but since the IntyBASIC compiler includes prologue and epilogue to your program, most likely you would include other .bas files into the main one instead of having previously compiled those separately into .asm to be included in the final stage of linking. The process might differ depending on your project.

 

Regarding editors, here are a few previous threads on the subject:
https://atariage.com/forums/topic/314662-preffered-ide-or-text-editor-for-intybasic-in-2020/

https://atariage.com/forums/topic/320300-vim-files-for-intybasic/

 

There also is IntelliTool though I've never tried it myself:

https://atariage.com/forums/topic/266703-intellitool-ide-for-intybasic/

 

Link to comment
Share on other sites

1 hour ago, carlsson said:

most likely you would include other .bas files into the main one

when you say include you mean have the .bas files in the same folder and use INCLUDE other.bas files so when it's time to make the .asm file the process grabs all of the .bas files and outputs a single asm right?  Something like this

 

main.bas (with INCLUDE graphics.bas and INCLUDE audio.bas)

graphics.bas

audio.bas

 

then in the terminal:

 

intybasic main.bas main.asm

 

this spits out a main.asm and you just as1600 that..  

 

 

 

1 hour ago, carlsson said:

Regarding editors,

Awesome i'll definitely check those out.  textedit was annoying because when you'd duplicate a .bas file it would make it a .txt anyway and then have the wrong association..  so far sublime text is at least not suffering from that annoyance.. heh.  

Link to comment
Share on other sites

oh wow libraries.. that's really cool.  i hadn't thought about that.  are there any shared library resources maybe out there that people have put in a repository somewhere?    the thought of folders is cool too..  in fact I just did some testing and hot damn it works. :)

 

and by "library" would that really mean effectively tried and true .bas files kept in the project to be called on?  

 

it was a bit of a mess in my intybasic folder..  with mac and pc files (so i can build from work or home from the same dropbox folder) but the projects and variations start to fill up fast..  

 

I did just try out roms\example01 moving the rom and bin files to a sub folder and that worked out well.  That helped quite a bit.  i'll have to see about putting the path for future compiles as well.. that should help clean things up a lot!  

 

also, just curious about project sizes and such.  how many lines of code does an average game consist of?  well by average i mean a well made game.  I'm wrapping my head around how big a game i might want to make..  something in the vein of a game like night stalker, mission x or bump n' jump..   

Link to comment
Share on other sites

Not sure if you should count number of lines of source code as it depends how densely you pack your code. An Intellivision game using all available memory banks can be up to 42 kilodecles = 84 kilobytes binary data before you need to apply some advanced bank switching. There is an example in the contrib folder called 42k.bas that specifies all available segments.

 

I don't know if either of my finished projects is worthy to be called well made since I haven't got published, but both Ouranos and Santa Lucia are just short of 1000 lines. Merry Melodies around 1150 because it contains so many songs. Some of my unfinished games like Alligator Swamp and Manager Boss both are just over 900 lines, some other unfinished/unannounced games just over 700. Basically with a lot of BITMAP and MUSIC statements, the source code quickly grows in terms of number of lines, but also in compiled size. The Waltz Box I posted earlier this summer was 3600 lines but that is almost entirely music.

 

Some of the code I've received for others to audit were some 2000-3500 lines even in unfinished state (86 kilobyte source code, which still is a morsel for the compiler and assembler).

Link to comment
Share on other sites

@carlsson already responded, but here is some additional details.

 

10 hours ago, Caleb Garner said:

1. so far i've seen variables named very simple things like "c" and such.  can we give variables more complex names?  any limits like say.. 8 characters max?  

The compiler (and the assembler) load symbols such as variable names into internal strings in their respective run-time programming environment (C or C++ for each), so there is practically no limit to their lengths.

 

Shorter names, as @carlsson suggested, are easier to type; and mnemonic names are easier to read and understand.  Just pick your poison, as they say.  Naming conventions are as varied as the stars, so my personal recommendation is to pick your favorite and stick to it.  In my experience, the convention does not matter as much as its consistent application across your domain.

 

10 hours ago, Caleb Garner said:

2. as your projects get more complex are you putting all of your code into one big bas file or are you able to break up your code into separate files to perhaps help keep things in manageable chunks? 

As I am a big proponent of structured programming and development by decomposition, I always recommend the separation of code into modules, each circumscribed by their functionality or logical categorization.  It not only keeps the source code organize, it is also easier to troubleshoot, for you keep related routines together in smaller files which are easier to scan.

 

Creating sub-folders to organize your modules is also a good idea.  It makes navigating a large and complex program much more easier.  Remember, you are not only doing this for yourself as you work on your program -- you are doing it for the future you some weeks from now, when you need to modify or troubleshoot a particular part of the program that you have not touched in several weeks or months.  Chances are you may not remember in which specific line or section that particular piece of code resides on a file that spans several hundred or even thousands lines of code.

 

IntyBASIC supports the "include" directive, but these are not recursive.  That is, an included file must not include other files.  Because of this, it may be useful to have your "main" file be a collection of global variable and constant declarations, programmer comments, include directives, and other "top-level" program details.  You can then encapsulate logic and control flow into subroutines, broken down into modules.

 

The "include" directive takes either an absolute or relative path.  Relative paths are anchored to the main "BAS" file invoked in the compiler command-line.

   INCLUDE "constants.bas"
   INCLUDE "lib/enemy.bas"
   INCLUDE "lib/player.bas"
   INCLUDE "lib/collisions.bas"
   ' ...

 

To include assembly language modules, you must prefix the "include" directive with the "ASM" directive, in order to have the compiler pass the statement to the assembler.  The assembler has no limits on the depth of recursion.

 

Filenames can also be absolute or relative to the main "ASM" file invoked in the assembler command-line.

 

If you are using the IntyBASIC SDK, relative paths are anchored to the project's base folder.  (See the SDK documentation for more details.)

 

10 hours ago, Caleb Garner said:

3. what text editor(s) do you use?  I started with textedit for mac, but now i'm using sublime text.  maybe there is something out there that perhaps is even made to use intellisensing with intybasic commands?

 

Oh dear! ?  Now, you're just asking for trouble!

 

(Just kidding!)

 

Personally, I use TextMate on the Mac, and EditPlus on Windows.  Like @carlsson with his Emacs, I've rigged these applications environment to incorporate syntax highlighting for Assembly and IntyBASIC languages and to execute the P-Machinery and IntyBASIC tools directly from the interface.

 

My recommendation is to use whatever you are comfortable with.  It seems everybody has their own preference, and most people do not go through the trouble of creating special language files for their editors, but if they do, they tend to share them.  I certainly would share anything I have for my preferred editors, but for anything else, your mileage may vary.

 

     -dZ.

Link to comment
Share on other sites

2 hours ago, Caleb Garner said:

oh wow libraries.. that's really cool.  i hadn't thought about that.  are there any shared library resources maybe out there that people have put in a repository somewhere?    the thought of folders is cool too..  in fact I just did some testing and hot damn it works. :)

 

and by "library" would that really mean effectively tried and true .bas files kept in the project to be called on?  

 

The IntyBASIC SDK comes with a few, but other than that, I do not know of some centralized repository of shared libraries -- probably because the community is rather small and there hasn't been much chance to build one.

 

 

2 hours ago, Caleb Garner said:

it was a bit of a mess in my intybasic folder..  with mac and pc files (so i can build from work or home from the same dropbox folder) but the projects and variations start to fill up fast..  

 

That's one of the issues that the IntyBASIC SDK tries to address.  It grew out of an installation package I created that organizes all files into a nice folder taxonomy that is easy to navigate.  Then it was picked up by a collaborative effort from the community to build a useful programming environment that was easier to use by newcomers, and include documentation and tutorials.  I'm just the guy who maintains it now.

 

2 hours ago, Caleb Garner said:

I did just try out roms\example01 moving the rom and bin files to a sub folder and that worked out well.  That helped quite a bit.  i'll have to see about putting the path for future compiles as well.. that should help clean things up a lot!

 

Or take a look at the IntyBASIC SDK ... ;)

 

2 hours ago, Caleb Garner said:

also, just curious about project sizes and such.  how many lines of code does an average game consist of?  well by average i mean a well made game.  I'm wrapping my head around how big a game i might want to make..  something in the vein of a game like night stalker, mission x or bump n' jump..   

In general, project and file size is not a problem at all.  The problem is the harsh constraints of the hardware and the splintered memory map available for home-brew programs.

 

Just know that games any of the classic games, like Night Stalker and Mission X, etc., are rather small.  We've learned a thing or two since the early 1980s, so home-brew games tend to be a lot bigger than that -- not because they are bloated or less efficient, but because they are much more sophisticated, and include much more complex graphics, animations, and music, and other assets.

 

My personal recommendation is to just start making your game and deal with the limitations as you encounter them.  Trust me, the 42K memory map supported by most cartridges is plenty for most games.  There have been a few games that break out of that by employing bank-switching or heavy compression, but it's not really the norm.

 

      -dZ.

Link to comment
Share on other sites

1 hour ago, DZ-Jay said:

We've learned a thing or two since the early 1980s, so home-brew games tend to be a lot bigger than that

Also the original games rely on the EXEC ROM with various entry points to nifty library routines of which a majority may be documented but not all. A compiler like IntyBASIC makes its own routines so it (almost?) entirely is independent of that system ROM, which of course makes the games larger but also much faster since the EXEC was called at a 20 Hz duty cycle if I understand correctly while programs that don't rely on it can run as fast as possible, whether those are hand made in assembly language or a compiled language.

Link to comment
Share on other sites

1 hour ago, carlsson said:

Also the original games rely on the EXEC ROM with various entry points to nifty library routines of which a majority may be documented but not all. A compiler like IntyBASIC makes its own routines so it (almost?) entirely is independent of that system ROM, which of course makes the games larger but also much faster since the EXEC was called at a 20 Hz duty cycle if I understand correctly while programs that don't rely on it can run as fast as possible, whether those are hand made in assembly language or a compiled language.


The EXEC intercepted and handled the VBLANK IRQ on every interrupt event, at 60 Hz.  However, it spread its processing across three frames, which is why the old games ran at 20 Hz.

 

Part of the reason for this was that, at the time of its design, it was not clear if the entire set of tasks could be performed in a single frame.

 

The EXEC does a substantial amount of work in each iteration:  it updates GRAM, cycles animations, checks for object-to-object and object-to-boundary collisions, adjusts velocity of objects based on 2D vectors, scrolls the screen, updates the background scene, plays music and sound effects, decodes and debounces user input, updates a random number generator, etc.

 

It does all those things and more in a rather sophisticated way.  For instance, it doesn’t just update sprite velocities, it can track its position and adjust it as necessary to reach a given location, and triggers an event when it gets there.

 

The same with sprite collisions:  it fully decodes them, and triggers events accordingly.

 

The EXEC was a wonderful piece of technology, and it may have seem like “the future” back then.  It’s just that it was designed at a time when game engines and frameworks were virtually unknown, so it had to forge its own path.  Many of its design concepts are now standard.

 

IntyBASIC, on the other hand, doesn’t even try to do most of these functions.  As convenient and useful as it is (and it is that in spades), it is still a rather primitive framework in which the programmer still has to solve most common problems himself.

 

   dZ.

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

2 minutes ago, DZ-Jay said:

look at the IntyBASIC SDK ... ;)

absolutely! likely something i'll sit with this weekend.  i'd like to streamline the build process..  i don't know what the best option by my current setup with terminal while functional is not elegant at all.  :)

 

 

regarding variables thanks to both of you for clearing that up!  I'm sure as i dig into the book deeper that was probably self evident, but just not there yet and like to understand what i do understand about game design / development from other stuff translates over.  

 

39 minutes ago, DZ-Jay said:

We've learned a thing or two since the early 1980s,

Yea that's really exciting.  I do think that anything I have in mind will not be content intensive.  I have a few ideas for games that I want to start with that are simple and then work up to more challenging / pixel pushing down the road..  

1 hour ago, DZ-Jay said:

The "include" directive takes either an absolute or relative path.

I'm not sure if i should be worried about this, but I do wonder if when i do this are there any concerns about code breaking / not working right?  when this is done, do any code concerns crop up that wouldn't happen if everything were in one?  

 

2 hours ago, carlsson said:

84 kilobytes binary data

that's a lot right?  the C64 is 64kb of ram..  i know i'm looking at this wrong..  i recall the intellivision has a lot less than 64kb of ram to work with..  or maybe that includes rom data that is non volatile?  

 

Link to comment
Share on other sites

Yes, that is 84 kilobytes of cartridge ROM. The amount of RAM is much less. The exact number of variables you can use in IntyBASIC also depends on if you're using the music routines, the scrolling routines etc. I believe the manual specifies this.

 

As a side note, once you get ahold of the LTO Flash! you may actually make programs that use up to 8000 extra words of RAM, so called JLP memory. The emulator supports this too, and a few cartridge manufacturers have this capacity though it is by no means default to include extra RAM on the cartridge. It might not be that commonly used, but good thing to keep in mind that a such option exists for games that need to hold a lot of data that has to be modified over the course of the game.

Link to comment
Share on other sites

5 minutes ago, Caleb Garner said:

 

I'm not sure if i should be worried about this, but I do wonder if when i do this are there any concerns about code breaking / not working right?  when this is done, do any code concerns crop up that wouldn't happen if everything were in one?  

 

Not at all.  What “include” does is inject the content of the referenced file inline at that point, and proceed with compilation.

 

5 minutes ago, Caleb Garner said:

that's a lot right?  the C64 is 64kb of ram..  i know i'm looking at this wrong..  i recall the intellivision has a lot less than 64kb of ram to work with..  or maybe that includes rom data that is non volatile?  

 

Er ... 42K ... where the “K” stands for 16-bit words.  That’s the ROM size, exhausting the available memory map without additional tricks.

 

The Intellivision has very limited RAM.  So we do not load the programs into RAM like you do on the C64, which has no built in storage.  We run the program from the cartridge ROM.  That’s frees the RAM for variables.
 

   dZ.

Link to comment
Share on other sites

8 minutes ago, DZ-Jay said:

inline at that point

does this mean if you needed it to be in another part of the code you would actually include it again lower down or once included once in that spot it's "there" to be referenced in other ways?

 

9 minutes ago, DZ-Jay said:

That’s frees the RAM for variables.

ah yes ok understood.. and that is interesting about C64 difference.. it does load EVERYTHING from the floppy disks for the most part.. there's no back and forth with a 5.25" floppy except major loads or saving current progress.  

Link to comment
Share on other sites

45 minutes ago, Caleb Garner said:

does this mean if you needed it to be in another part of the code you would actually include it again lower down or once included once in that spot it's "there" to be referenced in other ways?

 

Including modules in IntyBASIC is just like including library modules in other programming languages:  you only include them once.  Think of it this way:  the compiler scans the main file, and every time it finds an "included" directive, it fetches the target file, and injects it inline as if you copy+pasted it at that precise point in the source code.  Then, it compiles the entire thing as if it were a single, monolithic file.

 

If you were to include the same file multiple times in the same program, this would be the same as if you copy+pasted that code into your program multiple times:  the code would be duplicated, which may or may not be what you intend.  For instance, if you include the same variable declaration or subroutine definition twice in the same program, the compiler will fail with a naming clash error.

 

My recommendation is to treat the "include" directive as a library import function, like in other programming languages, and to use the external modules to separate the concerns of your code into either re-usable libraries, or just encapsulated functionality.
 

I hope that makes sense.

 

45 minutes ago, Caleb Garner said:

ah yes ok understood.. and that is interesting about C64 difference.. it does load EVERYTHING from the floppy disks for the most part.. there's no back and forth with a 5.25" floppy except major loads or saving current progress.  

 

I don't think the C64 can execute from floppy.  I believe that the floppy disk is not memory mapped -- it is just random-access data storage, so it needs to be loaded into memory for it to be visible to the CPU.

 

A similar thing happens in the Intellivision with the ECS and a tape drive:  the tape contains encoded data, which must be read and decoded and store somewhere in the memory space accessible to the CPU for it to be able to execute it.  In the case of cartridges, these are connected directly to the data bus, so they are fully memory mapped.

 

    -dZ.

Link to comment
Share on other sites

Although we're verging into off-topic land again, IIRC the 1541 does have 2K RAM where you could store a routine that will read a sector into it or so. Perhaps you didn't see that crazy demo a month or two ago where a C64 was used to bootstrap a 1541. Then they cut off the IEC cable, soldered on two RCA connectors and plugged the disk drive straight onto a monitor. The disk drive CPU then generates clock and data pulses at such voltages and speed that the monitor will treat it as a video signal.

 

 

But yes, the typical use case is to load data from a secondary device into computer RAM and then execute it. The C64 has a cartridge ROM window of a mere 16 kilobytes but thanks to various bank switching techniques employed since the C64GS c:a 1990, it can use cartridges 64-256K, even images up to 1 MB by sliding the window.

Link to comment
Share on other sites

7 minutes ago, carlsson said:

Although we're verging into off-topic land again, IIRC the 1541 does have 2K RAM where you could store a routine that will read a sector into it or so. Perhaps you didn't see that crazy demo a month or two ago where a C64 was used to bootstrap a 1541. Then they cut off the IEC cable, soldered on two RCA connectors and plugged the disk drive straight onto a monitor. The disk drive CPU then generates clock and data pulses at such voltages and speed that the monitor will treat it as a video signal.

Yes, I am aware of that, there's is a separate 6502 in the drive as well.  I remember having a disk copy utility back in the day that, once the loaded into the drive, could make duplicates of disks without the computer.

 

All that said, you still need to read the data from the disk media into memory for it to be accessible to either the computer's or drive's CPU. ;)

 

The Intellivision's default media, on the other hand, is a cartridge, which works similarly in the C64, where you can run directly from the ROM and use on-board RAM because the ROM boards plug directly into the data bus and become part of the memory address landscape.  That's what I meant.

 

7 minutes ago, carlsson said:

 

 

But yes, the typical use case is to load data from a secondary device into computer RAM and then execute it. The C64 has a cartridge ROM window of a mere 16 kilobytes but thanks to various bank switching techniques employed since the C64GS c:a 1990, it can use cartridges 64-256K, even images up to 1 MB by sliding the window.

?

  • Like 1
Link to comment
Share on other sites

1 hour ago, carlsson said:

1 MB RAM

oh wow that's cool and yea that makes a lot of sense.. that 1mb is reserved for fast access of whichever rom is loaded. probably 1mb is just a nice generous number for any intellivision game?  Still that's awesome.  

 

 

but then the question is if you loaded the chess rom onto an LTO would it be able to allowcate the 2kb or whatever it is that was on the original cartridge to help (i assume) the computer to be able to make the needed calculations in as timely a fashion possible.  

 

Link to comment
Share on other sites

It says "Compatible with all the original games and prototypes, and every homebrew we've tried" so I would assume it is fine including Chess which allocates 2K 16-bit (?) RAM at $D000 - $D3FF. I suppose with clever use of POKE/PEEK and ASM ORG, you could declare otherwise ROM areas as RAM for use with jzintv and LTO, if the extra 8000 words are not enough. The compiler probably can't use it for variables though, and it is not anything I've ever experimented with. It probably is considered quite non-standard.

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