Jump to content
IGNORED

IntyBASIC compiler v0.5


nanochess

Recommended Posts

They are. That's the problem.

I just tried deleting my intybasic_prologue.asm and intybasic_epilogue.asm. The result was that the basic compiler finished with no errors, and the assembler reported the same 39 errors that you have. So the problem is that the compiler can't find these files (or somehow, there is nothing in them).

 

When I run the compiler, my current directory is the directory where the test.bas and the prologue and epilogue files are. On windows, I run a batch file in the directory containing all 3 of these files ( the basic compiler is in another directory...)

 

Does this help? Maybe this is a job for nanochess....

Link to comment
Share on other sites

open test.asm or test2.asm, manually copy the prologue before the generated code, and then add the epilogue after the generated code.

test.asm I attached the compiled code generated by IntyBASIC 7. See if this one compiles with as1600.exe. If it compiles that one, then that rules out as1600.exe the problem. I'm not sure of your OS. Check the folder's permission.

Link to comment
Share on other sites

The some of the errors are located in that file listed:

528e 0204 0006 			BEQ T78
				MVII #-1,R0
 ERROR - expression exceeds available field width
5290 02b8 ffff 

528e 0204 0006 			BEQ T78
				MVII #-1,R0
 ERROR - expression exceeds available field width
5290 02b8 ffff 
 0x5292           

52a7 0204 0006 			BEQ T82
				MVII #-1,R0
 ERROR - expression exceeds available field width
52a9 02b8 ffff 


 

Regarding those errors, it looks like you have an older version of the assembler. In the past, the assembler didn't automatically truncate negative numbers to 16 bit, so a value like -1 was interpreted as a full 32-bit integer in C, causing the assembler to blow up with that error. You had to do something like:

 

 

          MVII #(-1 AND $FF), R0

 

to truncate it to 16-bits. The later versions fixed this.

 

Also, I second catsfolly's comments: you are not stupid, it is just hard to set up your environment, especially when we're trying to fix something broken rather than starting from scratch. We're here to help, and once we get everything going, it'll work. :)

 

-dZ.

Link to comment
Share on other sites

As the song says, sometimes you have to know when to fold'em. So, let's start with the basics (no pun intended), and set up everything from scratch. I tried to be concise with these steps and most of them are done from memory, so please feel free to ask for clarification or assistance with any of them.

 

 

1. Download and install:

The emulator and debugger is called jzIntv and the assembler is called as1600. Along with these core tools, Joe Zbiciak has made available the SDK-1600, which is a set of library and utility files to help in making Intellivision games.

  • Download the latest version of jzIntv and the SDK-1600 for Windows (I assume you are using Windows, right? If you're on MacOS X, then let me know, for I can give you more precise instructions).
  • Extract the ZIP file into wherever folder you want. This is going to be your "installation directory."

2. Setting up the environment:

Setting up the environment in Windows allows you to call the development tools from any working directory, rather than having to depend on them being in any specific place. It also frees you from having to copy them around every time you want to use them.

 

We also set up an environment variable for the assembler, which will point its library path to the SDK-1600 library source files. This will make the assembler always look for those files there first when included in your code, so that you don't have to fully qualify their location or copy them around every time you want to use them. I believe that the IntyBASIC compiler depends on some of these libraries.

 

Trust me, it will bring peace of mind. This is the step that most people do once and forget about it, and then wonder why everybody else is having problems assembling and compiling when it works so well in their computers. ;)

  • Open up the Control Panel -> System or Security -> System. This is the same as right-clicking on MyComputer on the Desktop and choosing Properties.
  • Click on the Advanced System Settings tab.
  • At the bottom of that screen, click on the Environment Variables button.
  • There are two sections, User variables and System Variables; we are going to work only with System Variables.
  • Follow the instructions on this post to set up three environment variables in your system.
    • PATH: to point to the jzIntv tools.
    • JZINTV_ROM_PATH: to point to your collection of ROMs.
    • AS1600_PATH: to point to the SDK-1600 libraries.

3. Setting up IntyBASIC:

Setting up the compiler is simple, just download and extract.

  • Download the latest version of IntyBASIC (I believe it is 0.7).
  • Extract the ZIP archive anywhere in your computer. This will be your IntyBASIC "installation" directory.

 

One quirk of IntyBASIC is that it expects all files to be in the same folder. Personally, I don't like this, but such is life. Hopefully, nanochess will change this in the future, if he hasn't already. ;)

As an alternative, if you have Perl installed in your computer, you can use this simple distribution of IntyBASIC that I prepared some time ago. It includes the same files, but organizes them into sub-directories (I am a maniac that way!). It also brings a nifty Perl script that allows you to run the compiler and assembler in whatever directory your files are in, without having to put them all in the same place. It also runs the compiler and assembler as a single step.
You can get the "DZ's Special" distro of IntyBASIC from this post. :)

4. Using IntyBASIC:

 

  • Put your BASIC source files in the IntyBASIC "installation" directory.
  • Open up a new Command console window.
  • Navigate (change working directory, or "cd") to the IntyBASIC "installation" directory.
  • Run the IntyBASIC compiler followed by the assembler.

 

I hope this helps.

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

One quirk of IntyBASIC is that it expects all files to be in the same folder. Personally, I don't like this, but such is life. Hopefully, nanochess will change this in the future, if he hasn't already. ;)

 

Versión 0.7 includes support for library paths ;)

Link to comment
Share on other sites

  • 1 month later...

I just looked over the manual. Very exciting stuff! Can't wait to try it!

 

I have a few questions, though:

 

  1. Is there any form of bankswitching, or are we limited to the 16k available in the $5000 to $6fff range?
  2. The 8k in $D000-$DFFF and $F000-$FFFF are meant for just graphics, correct? Would defining graphics in this area allow the program to automatically find them when referenced, or will something special have to be done?
  3. The manual mentions "characters", "cards," and "sprites," but doesn't make a clear distinction between what they are. What is the difference, exactly? Can they all be custom-defined?
  4. Is there (or will there ever be) the possibility of multicolor sprites, like how some kernels of batariBaisc for the 2600 can do different colors per sprite line?
  5. Is there any way to look at the value of a character/card that has been defined in the background? For instance, let's say I made a platformer out of characters/cards/tiles/whatever and I wanted to react differently depending on what the player sprite collided with, like spikes, water, lava, ground, ice, etc.
  6. How would one interface with the Intellivoice module? Is there any equivalent to the AtariVox's saving capabilities with the Intellivoice or other product?
  7. I know the manual mentions that there is currently no way to tell if you're running out of memory or ROM space. Could that be changed in future releases, particularly with the ROM? I'm uneasy with the idea of suddenly being all out of space.
  8. The manual mentions dimming arrays, but surely single values can be dimmed as well, right? Would that take the form of a one-index array, or as defining an array without the index?
  9. The manual describes how to display decimal, hexadecimal, and characters, but how would one displaying binary values?
  10. Can one define a label for individual bits, as with batariBasic's DEF function, to turn a byte into 8 easily-readable booleans?
  11. If one is comparing a boolean value, such as IF A = TRUE where A is 35, does it return any non-zero value as true?
  12. If I understand correctly, Mode 0 limits you to 4 colors for the background that you define from the 16-color palette, but you get access to more "cards", while Mode 1 gives you access to more colors, but at the cost of far fewer cards? How many possible cards are lost with Mode 1?
  13. How big are the cards? 8x8, I assume?
  14. How much of the screen is actually used by IntyBasic? batariBasic, for example, shows the contents of the screen in a sort of letterbox, probably due to timing limitations. Can IntyBasic display full screen content, or is it likewise limited (and if so, by about how much)?
  15. How does one actually define sprites, or are they defined as cards (as the syntax seems to imply)? How would this work for sprites that are 8x16 if cards are 8x8?
  16. Can background cards contain multiple colors? If so, how would the different colors be defined? If not, then can cards somehow be overlayed in the background to create the impression of multiple colors, or what options are there?

I'm sure I'll think of more questions, but that's a start. :)

Edited by Cybearg
Link to comment
Share on other sites

I just looked over the manual. Very exciting stuff! Can't wait to try it!

 

I have a few questions, though:

A few!!! :o

  • Is there any form of bankswitching, or are we limited to the 16k available in the $5000 to $6fff range?
Currently you should track manually your memory usage, but you can use the memory map as available for code or data.

 

Some valid areas are $2000-$2fff, $5000-$6fff, $a000-$bfff and $c100-$ffff.

 

  • The 8k in $D000-$DFFF and $F000-$FFFF are meant for just graphics, correct? Would defining graphics in this area allow the program to automatically find them when referenced, or will something special have to be done?

 

Code or graphics. IntyBASIC will find automatically the data because it references by label in assembler.

 

Just be sure to put "ASM ORG $D000" (for example) before your code/data.

 

  • The manual mentions "characters", "cards," and "sprites," but doesn't make a clear distinction between what they are. What is the difference, exactly? Can they all be custom-defined?

 

I shouldn't have used characters, it should read cards, I'll check later.

 

Cards are the base character set contained in Intellivision ROM (256 of these) and also the 64 definable contained in GRAM (64 of these).

 

Sprites (MOB) are 8 graphic elements movable pixel-by-pixel over screen.

 

 

  • Is there (or will there ever be) the possibility of multicolor sprites, like how some kernels of batariBaisc for the 2600 can do different colors per sprite line?

 

You can use multicolor sprites if you put multiple sprites over same place. Of course given the 8 sprite limit of Intellivision you should be wise.

 

 

  • Is there any way to look at the value of a character/card that has been defined in the background? For instance, let's say I made a platformer out of characters/cards/tiles/whatever and I wanted to react differently depending on what the player sprite collided with, like spikes, water, lava, ground, ice, etc.

 

Use PEEK(expr) statement, the expr value should be $0200-$02ef to read the number of card in screen.

 

  • How would one interface with the Intellivoice module? Is there any equivalent to the AtariVox's saving capabilities with the Intellivoice or other product?

 

No idea. Also I don't plan support for it.

 

  • I know the manual mentions that there is currently no way to tell if you're running out of memory or ROM space. Could that be changed in future releases, particularly with the ROM? I'm uneasy with the idea of suddenly being all out of space.

 

You should check manually your generated code after assembly.

 

  • The manual mentions dimming arrays, but surely single values can be dimmed as well, right? Would that take the form of a one-index array, or as defining an array without the index?

 

Yep, you can use DIM A(1) and later you can use A(0)=5 and so.

 

  • The manual describes how to display decimal, hexadecimal, and characters, but how would one displaying binary values?

 

IntyBASIC only displays cards (really it wrotes directly into screen memory the value).

 

You should write routines for displaying decimal and hexadecimal values, or binary if you like.

 

  • Can one define a label for individual bits, as with batariBasic's DEF function, to turn a byte into 8 easily-readable booleans?

 

You can use constants with the CONST statement, like CONST color_mask = 7

 

Remember some bitwise operations in Intellivision aren't so optimum, like OR which is created with a mix of AND/XOR.

 

  • If one is comparing a boolean value, such as IF A = TRUE where A is 35, does it return any non-zero value as true?

 

Yep, IF statement jumps on non-zero result. All comparison operators return zero or -1 (for easeness of using AND)

 

  • If I understand correctly, Mode 0 limits you to 4 colors for the background that you define from the 16-color palette, but you get access to more "cards", while Mode 1 gives you access to more colors, but at the cost of far fewer cards? How many possible cards are lost with Mode 1?

 

You only have access to the base 64 cards of Intellivision GROM in mode 1, plus the 64 definable cards in GRAM.

 

  • How big are the cards? 8x8, I assume?

 

You're right.

 

  • How much of the screen is actually used by IntyBasic? batariBasic, for example, shows the contents of the screen in a sort of letterbox, probably due to timing limitations. Can IntyBasic display full screen content, or is it likewise limited (and if so, by about how much)?

 

Full screen displayed.

 

  • How does one actually define sprites, or are they defined as cards (as the syntax seems to imply)? How would this work for sprites that are 8x16 if cards are 8x8?

 

Using the DEFINE statement as documented in IntyBASIC manual, also you should check the example programs ;)

 

The 8x16 sprites are built around two 8x8 cards aligned in an even location. Read also the STIC manual, I've put a link to it in the IntyBASIC manual.

 

  • Can background cards contain multiple colors? If so, how would the different colors be defined? If not, then can cards somehow be overlayed in the background to create the impression of multiple colors, or what options are there?

 

Background cards only can contain two colors, the background color and the foreground color.

 

Again I suggest you to read the STIC manual.

I'm sure I'll think of more questions, but that's a start. :)

:)
Link to comment
Share on other sites

Currently you should track manually your memory usage, but you can use the memory map as available for code or data.

 

Some valid areas are $2000-$2fff, $5000-$6fff, $a000-$bfff and $c100-$ffff.

So then there is no bankswitching and no possibility of future bankswitching, but by using those valid areas (that are otherwise left empty?), you can get up to 48k from the main 16k + 4 x 8k?

 

I shouldn't have used characters, it should read cards, I'll check later.

 

Cards are the base character set contained in Intellivision ROM (256 of these) and also the 64 definable contained in GRAM (64 of these).

 

Sprites (MOB) are 8 graphic elements movable pixel-by-pixel over screen.

If I understand between the manual and what you say later, there are 64 pre-defined ROM cards, and then the rest of those 256 ROM cards (which act as background tiles) can be defined in the game ROM, correct? With an additional 64 in RAM that can be modified during game operation for dynamic backgrounds and such?

 

Use PEEK(expr) statement, the expr value should be $0200-$02ef to read the number of card in screen.

Is that the same as the 64 GRAM cards, or is this something different?

 

You should check manually your generated code after assembly.

How is that done? The assembly file will be a lot larger than the compiled binary, but don't binaries come in standardized sizes with junk code to fill the empty space? 2600 ROMs are always 2, 4, 8, 16, or 32k, so you can't tell by looking at the file size how much of that is filler and how much is code.

 

Yep, you can use DIM A(1) and later you can use A(0)=5 and so.

So you can't define something like DIM my_variable = 30 and it always has to be in arrays?

 

IntyBASIC only displays cards (really it wrotes directly into screen memory the value).

 

You should write routines for displaying decimal and hexadecimal values, or binary if you like.

I just mean, is there a way to define a value in binary rather than hex, decimal, or character? I have no idea how I would implement that myself.

 

In batariBasic, you can define a value in decimal like a = 10, hex like a = $0A, or binary like a = %00001010. Being able to handle numbers in binary is very convenient when visualizing bitwise operations.

 

You can use constants with the CONST statement, like CONST color_mask = 7

No, I don't think I explained it right. In batariBasic, you can define individual bits like so:

def lowest_bit=a{0}

def highest_bit=a{7}

 

...and then use them like:

if highest_bit then lowest_bit = false

 

It was very convenient. Can that be done here?

 

The 8x16 sprites are built around two 8x8 cards aligned in an even location. Read also the STIC manual, I've put a link to it in the IntyBASIC manual.

Alright, I'll check it out. Does using 8x16 sprites halve the number of cards you can have, then, or is there no impact?

 

Background cards only can contain two colors, the background color and the foreground color.

Well, at least there's two! That should be enough for quite a few interesting things. :)

 

BTW, you really should use IntyBASIC v0.7.3, is the latest version ;)

I've got the latest. Just downloaded it yesterday! Edited by Cybearg
Link to comment
Share on other sites

 

If I understand between the manual and what you say later, there are 64 pre-defined ROM cards, and then the rest of those 256 ROM cards (which act as background tiles) can be defined in the game ROM, correct? With an additional 64 in RAM that can be modified during game operation for dynamic backgrounds and such?

 

Nope. There are 256 pre-defined ROM cards. These cards are defined by a ROM chip in the Intellivision and cannot be changed.

There are 64 cards in RAM that can be user defined and modified during game operation.

No cards are defined in the game ROM.

 

The background image is an array of cards that appears as 12 rows of 20 cards. This is called backtab. Each backtab location contains the number of the card to display, a flag to indicate if it is a RAM image or a ROM image, and color information. Backtab is located in memory from $0200 to $02ef.

  • Like 1
Link to comment
Share on other sites

So then there is no bankswitching and no possibility of future bankswitching, but by using those valid areas (that are otherwise left empty?), you can get up to 48k from the main 16k + 4 x 8k?

There is a chance for bankswitching once I get the LTO Flash Cart and specifications. I don't hope to support any other bankswitching.

 

If I understand between the manual and what you say later, there are 64 pre-defined ROM cards, and then the rest of those 256 ROM cards (which act as background tiles) can be defined in the game ROM, correct? With an additional 64 in RAM that can be modified during game operation for dynamic backgrounds and such?

 

Is that the same as the 64 GRAM cards, or is this something different?

As catsfolly said. (thanks catsfolly! :thumbsup: )

 

How is that done? The assembly file will be a lot larger than the compiled binary, but don't binaries come in standardized sizes with junk code to fill the empty space? 2600 ROMs are always 2, 4, 8, 16, or 32k, so you can't tell by looking at the file size how much of that is filler and how much is code.

as1600 has an option to generate a listing file, you should read that file to check the addresses used.

 

So you can't define something like DIM my_variable = 30 and it always has to be in arrays?

I'm not sure to understand what you're trying to say.

 

I just mean, is there a way to define a value in binary rather than hex, decimal, or character? I have no idea how I would implement that myself.

 

In batariBasic, you can define a value in decimal like a = 10, hex like a = $0A, or binary like a = %00001010. Being able to handle numbers in binary is very convenient when visualizing bitwise operations.

Ah, ok, you can use decimal and hexadecimal as you wrote it. I think I can support binary in the next version of IntyBASIC ;)

 

No, I don't think I explained it right. In batariBasic, you can define individual bits like so:

def lowest_bit=a{0}

def highest_bit=a{7}

 

...and then use them like:

if highest_bit then lowest_bit = false

 

It was very convenient. Can that be done here?

I understand. No, I don't have support for that style of bit operations.

 

I'm trying hard to not include anything "heavy" which could be hidden and slow.

 

Alright, I'll check it out. Does using 8x16 sprites halve the number of cards you can have, then, or is there no impact?

Only 64 GRAM cards available and only 8 sprites available, 8x8 sprites would require 8 GRAM if every one is different, or them could share one GRAM if same drawing.

 

8x16 sprites would require from 2 GRAM to 16 GRAM, at your choice.

 

Well, at least there's two! That should be enough for quite a few interesting things. :)

 

I've got the latest. Just downloaded it yesterday!

Cool! 8)

Link to comment
Share on other sites

Nope. There are 256 pre-defined ROM cards. These cards are defined by a ROM chip in the Intellivision and cannot be changed.

There are 64 cards in RAM that can be user defined and modified during game operation.

No cards are defined in the game ROM.

Ah, I see. Are 64 cards enough for a decent set of background tiles, or is it pretty limiting? Reusability is obviously going to be very important.

 

There is a chance for bankswitching once I get the LTO Flash Cart and specifications. I don't hope to support any other bankswitching.

Alright, awesome! Will that bankswitching be an option for burned carts as well, or only on the Flash Cart? And what kind of sizes will be available then?

 

as1600 has an option to generate a listing file, you should read that file to check the addresses used.

Right, I am making list files. I just don't know where it specifies how many bytes are free/used. Does it specifically state it somewhere?

 

I'm not sure to understand what you're trying to say.

I figured it out. I didn't realize that IntyBASIC has such dynamic memory management. In batariBasic, you have to specify specifically what memory locations are being mapped to variables. For instance:

 

DIM my_variable = $50

 

This would map "my_variable" to the memory location $50. This could then be used as a single variable:

 

my_variable = 9

REM this would cause $50 to hold 9

 

Or as an array, if referenced like so:

 

my_variable[0] = 5: my_variable[9] = 9

REM this would cause $50 to hold 5 and $59 to hold 9

 

Apparently in IntyBasic, you only DIM arrays. You don't DIM single variables and instead just dynamically assign them, like so:

 

DIM my_array(3): REM 3-index array

my_variable = 1: REM creates a new variable and gives it the value 1

 

It's just a bit different than what I'm used to. :) The dynamic memory management is awesome, though!

Ah, ok, you can use decimal and hexadecimal as you wrote it. I think I can support binary in the next version of IntyBASIC ;)

Yes, please! That would be great!

 

I understand. No, I don't have support for that style of bit operations.

 

I'm trying hard to not include anything "heavy" which could be hidden and slow.

Aw... Well, maybe you'll think of an efficient way to add that in. It's awfully convenient.

 

Only 64 GRAM cards available and only 8 sprites available, 8x8 sprites would require 8 GRAM if every one is different, or them could share one GRAM if same drawing.

 

8x16 sprites would require from 2 GRAM to 16 GRAM, at your choice.

So sprites count against the memory available for background cards? Edited by Cybearg
Link to comment
Share on other sites

Ah, I see. Are 64 cards enough for a decent set of background tiles, or is it pretty limiting? Reusability is obviously going to be very important.

These are enough if you work hard :) and also use the GROM predefined cards to "complete" the drawing.

 

Alright, awesome! Will that bankswitching be an option for burned carts as well, or only on the Flash Cart? And what kind of sizes will be available then?

I cannot elaborate on it until I've the full documentation of LTO Flash.

 

Right, I am making list files. I just don't know where it specifies how many bytes are free/used. Does it specifically state it somewhere?

Nope, you should check the hexadecimal values for addresses.

 

I figured it out. I didn't realize that IntyBASIC has such dynamic memory management. In batariBasic, you have to specify specifically what memory locations are being mapped to variables. For instance:

 

DIM my_variable = $50

 

This would map "my_variable" to the memory location $50. This could then be used as a single variable:

 

my_variable = 9

REM this would cause $50 to hold 9

 

Or as an array, if referenced like so:

 

my_variable[0] = 5: my_variable[9] = 9

REM this would cause $50 to hold 5 and $59 to hold 9

 

Apparently in IntyBasic, you only DIM arrays. You don't DIM single variables and instead just dynamically assign them, like so:

 

DIM my_array(3): REM 3-index array

my_variable = 1: REM creates a new variable and gives it the value 1

 

It's just a bit different than what I'm used to. :) The dynamic memory management is awesome, though!

Excellent! :)

 

Yes, please! That would be great!

 

Aw... Well, maybe you'll think of an efficient way to add that in. It's awfully convenient.

 

So sprites count against the memory available for background cards?

That's right, but you can reuse background cards or GROM tiles for sprites.

Link to comment
Share on other sites

That's right, but you can reuse background cards or GROM tiles for sprites.

Well, since those 64 tiles are in RAM, I suppose one could just use data tables to hold a large tile set in ROM, then just swap out a handful of tiles (16 or so) into RAM as necessary, creating a large set in the long run, right? Ditto for sprites?

 

For instance, let's say I have 5 levels with distinct tile sets. One level may have 32 cards that get loaded in from a data table, then the second level gets another, different set of 32 cards loaded in from a different data table. Maybe it's even done on the fly depending on where you are in the level, retiring or loading in card sets in-game as you explore different portions of a level. Likewise for an enemy sprite having a certain card for it, then that card is changed in RAM for each frame of animation, rather than swapping between cards. Or is loading a card into memory too slow to be practical for frame animations like that in real time?

 

Is this the full set of available Intellivision pre-made cards?

Edited by Cybearg
Link to comment
Share on other sites

Well, since those 64 tiles are in RAM, I suppose one could just use data tables to hold a large tile set in ROM, then just swap out a handful of tiles (16 or so) into RAM as necessary, creating a large set in the long run, right? Ditto for sprites?

 

For instance, let's say I have 5 levels with distinct tile sets. One level may have 32 cards that get loaded in from a data table, then the second level gets another, different set of 32 cards loaded in from a different data table.

 

That's right :)

Link to comment
Share on other sites

Ok, cool!

 

I just noticed this that I must have overlooked (or didn't understand until now) from the manual:

 

 


DEFINE card_num,total,label
Loads graphics in GRAM "card_num" (0-63) for a total of "total" cards.
label points to graphics. (DATA or BITMAP)
Graphics will be loaded in next frame.
Only constants (not expressions) can be used in parameters.
Note there is an approximate limit of loading 18 GRAM cards per frame
(measured with emulator in NTSC mode)

 

What is the "total" used for? If your data table holds, say, 16 definitions, you can then set the total to 2 in order to load two cards in at once?

 

Does it improve the performance to batch-load 16 cards or does calling DEFINE 16 times, once for each individual card, have the same performance hit?

 

And, when loading a card (or multiple cards) into RAM, does it reduce the number of processor cycles available for gameplay code for a frame, or does it only use cycles from the drawing processing?

 

Also, if you try to load in more than the limit of cards for a frame, will it cause a timing error in the game resulting in screen rolling, or will the game know to take its time? For instance, let's say that the limit is 16 cards per frame and I try to load 64 cards .Will the game just load 16 cards per frame for 4 frames until it's finished, or will that one frame take 4 frames' worth of processing time to complete?

Edited by Cybearg
Link to comment
Share on other sites

Ok, cool!

 

I just noticed this that I must have overlooked (or didn't understand until now) from the manual:

 

 

 

What is the "total" used for? If your data table holds, say, 16 definitions, you can then set the total to 2 in order to load two cards in at once?

Yep, you can set the total to 2 and load only two cards in next frame.

 

Does it improve the performance to batch-load 16 frames or does calling DEFINE 16 times, once for each individual card, have the same performance hit?

If you use multiple DEFINE before the next WAIT statement, only the last one will be executed.

 

And, when loading a card (or multiple cards) into RAM, does it reduce the number of processor cycles available for gameplay code for a frame, or does it only use cycles from the drawing processing?

Yep, as the cards are loaded on each frame, if you define 16 cards each frame you'll have less execution time available.

Link to comment
Share on other sites

Thanks for the answers. Sounds like it will take a lot of careful management.

 

To repost my above edited-in question:

 

Also, if you try to load in more than the limit of cards for a frame, will it cause a timing error in the game resulting in screen rolling, or will the game know to take its time? For instance, let's say that the limit is 16 cards per frame and I try to load 64 cards .Will the game just load 16 cards per frame for 4 frames until it's finished, or will that one frame take 4 frames' worth of processing time to complete?

Link to comment
Share on other sites

Thanks for the answers. Sounds like it will take a lot of careful management.

 

To repost my above edited-in question:

 

Also, if you try to load in more than the limit of cards for a frame, will it cause a timing error in the game resulting in screen rolling, or will the game know to take its time? For instance, let's say that the limit is 16 cards per frame and I try to load 64 cards .Will the game just load 16 cards per frame for 4 frames until it's finished, or will that one frame take 4 frames' worth of processing time to complete?

Currently there is no limit in the number of cards you can update, but if you try to update more than 18 cards at a time everything after the number 18 will not update.

Link to comment
Share on other sites

Ah, I see. Are 64 cards enough for a decent set of background tiles, or is it pretty limiting? Reusability is obviously going to be very important.

As you may imagine, no buffer size is ever enough! ;)

 

However, having this limitation in mind, and with a bit of clever thought, you can get some rather complex scenes in the Intellivision. Take a look at any of the screenshots from GroovyBee's games, designed by pixel artist nonner42.

 

There are a few tricks you can use:

  • Intermixing GROM tiles with your custom GRAM ones
  • Overlaying MOBs to add additional colour
  • Clever use of the Color Stack and "reversed video" to extend the palette

Of course, you can always do "multiplexing," but it is not very effective on the Intellivision, and therefore not very common.

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