catsfolly Posted July 1, 2014 Share Posted July 1, 2014 Here's the list file from when it got 39 errors. http://www.atari2600land.com/test2.lst It looks like the basic compiler couldn't find the intybasic_prologue.asm and intybasic_epilogue.asm files. These files should be in the same directory as the test.bas file. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 1, 2014 Share Posted July 1, 2014 They are. That's the problem. Quote Link to comment Share on other sites More sharing options...
catsfolly Posted July 1, 2014 Share Posted July 1, 2014 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.... Quote Link to comment Share on other sites More sharing options...
Kiwi Posted July 1, 2014 Share Posted July 1, 2014 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 1, 2014 Share Posted July 1, 2014 14 errors now. http://www.atari2600land.com/test3a.lst Quote Link to comment Share on other sites More sharing options...
catsfolly Posted July 1, 2014 Share Posted July 1, 2014 14 errors now. http://www.atari2600land.com/test3a.lst 14 errors now. http://www.atari2600land.com/test3a.lst It looks like it's finding the prologue and epilogue now, but somehow you are back to running the old version of the assembler. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted July 1, 2014 Share Posted July 1, 2014 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. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted July 1, 2014 Share Posted July 1, 2014 (edited) 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 July 1, 2014 by DZ-Jay 4 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted July 1, 2014 Author Share Posted July 1, 2014 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 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted July 1, 2014 Share Posted July 1, 2014 Versión 0.7 includes support for library paths I thought you mentioned this before, but wasn't sure. Thanks. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 23, 2014 Share Posted August 23, 2014 (edited) I just looked over the manual. Very exciting stuff! Can't wait to try it! I have a few questions, though: Is there any form of bankswitching, or are we limited to the 16k available in the $5000 to $6fff range? 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? 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? 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? 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. How would one interface with the Intellivoice module? Is there any equivalent to the AtariVox's saving capabilities with the Intellivoice or other product? 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. 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? The manual describes how to display decimal, hexadecimal, and characters, but how would one displaying binary values? Can one define a label for individual bits, as with batariBasic's DEF function, to turn a byte into 8 easily-readable booleans? 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? 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? How big are the cards? 8x8, I assume? 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)? 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? 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 August 23, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 23, 2014 Author Share Posted August 23, 2014 I just looked over the manual. Very exciting stuff! Can't wait to try it! I have a few questions, though: A few!!! 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. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 23, 2014 Author Share Posted August 23, 2014 BTW, you really should use IntyBASIC v0.7.3, is the latest version http://atariage.com/forums/topic/223886-intybasic-compiler-v07-now-with-intycolor/ Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 23, 2014 Share Posted August 23, 2014 (edited) 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 = 7No, 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 August 23, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
catsfolly Posted August 24, 2014 Share Posted August 24, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 24, 2014 Author Share Posted August 24, 2014 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! ) 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! Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 24, 2014 Share Posted August 24, 2014 (edited) 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 August 24, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 25, 2014 Author Share Posted August 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 25, 2014 Share Posted August 25, 2014 (edited) 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 August 25, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 25, 2014 Author Share Posted August 25, 2014 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 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 25, 2014 Share Posted August 25, 2014 (edited) 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 August 25, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 25, 2014 Author Share Posted August 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 25, 2014 Share Posted August 25, 2014 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? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 25, 2014 Author Share Posted August 25, 2014 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. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted August 25, 2014 Share Posted August 25, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.