GroovyBee Posted February 9, 2012 Share Posted February 9, 2012 but the procedure always call 2B... so the variable is not incremented in fact.... what do I wrong? If R0 is not equal to 1 and its not equal to 2 then the code will "fall through" to the code at label @@2B. You need to add some code before @@2B if you want to do something else. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 9, 2012 Share Posted February 9, 2012 To increase the variable and reconnaise the page I wrote this. D_DISC PROC BEGIN ; handle "next page" MVI PAGESTEP, R0 ; IF (R0 = 1) THEN GOTO LEVEL_2B CMPI #1, R0 BEQ @@2B ; ELSEIF (R0 = 2) THEN GOTO LEVEL_7B CMPI #2, R0 BEQ @@7B ; ELSE BEQ @@ELSE @@2B: INC PAGESTEP, R4 CALL LEVEL_2B return @@7B: INC PAGESTEP, R4 CALL LEVEL_7B return @@ELSE: RETURN ;return della procedura D_DISC ENDP but the procedure always call 2B... so the variable is not incremented in fact.... what do I wrong? A few comments. First, you do not need a branch for ELSE. Whatever code you write after all your tests will be the ELSE itself; it will be executed only when none of the other tests are true. This is your problem, just like GroovyBee said. The "IF..ELSEIF...ELSE" pattern is usually like this: D_DISC PROC BEGIN ; handle "next page" MVI PAGESTEP, R0 ; IF (R0 = 1) THEN GOTO LEVEL_2B CMPI #1, R0 BEQ @@2B ; ELSEIF (R0 = 2) THEN GOTO LEVEL_7B CMPI #2, R0 BEQ @@7B ; ELSE ; Do whatever you need to do when all cases failed. RETURN ;return della procedura D_DISC @@2B: INC PAGESTEP, R4 CALL LEVEL_2B RETURN @@7B: INC PAGESTEP, R4 CALL LEVEL_7B RETURN ENDP Second, where are you initializing the value of PAGESTEP? If you don't initialize it, it'll probably be zero the first time, so both tests will fail, causing it to go to the "ELSE" portion. This means that the variable will never get incremented. As an optimization, try to code your counters starting from zero, so page #1 is actually PAGESTEP = 0. After all, computers usually count from zero. -dZ. Quote Link to comment Share on other sites More sharing options...
vprette Posted February 9, 2012 Author Share Posted February 9, 2012 (edited) works perfeclty now and I'm kind of happy (problem was I did not inizialise to 0 the variable) :-) I full the chain of level-to-level walkthrough by disc pression now, and after that I will have to proceed with music pause implementation Edited February 9, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 9, 2012 Share Posted February 9, 2012 works perfeclty now and I'm kind of happy :-) I full the chain of level-to-level wlaktrough by disc pression now, and after that I will have to proceed with music pause implementation Great! Here's another hint. If the numbers you are expecting in PAGESTEP are always sequential, then you can avoid the expense of all those comparisons and create a "jump table." A jump or dispatch table defines a list of branches to go to, and you find the proper branch by adding the conditional value as an offset to the table's base address. This is the same way that the "switch" statement works in C and the "SELECT CASE" works in VB. In fact, this is so common, that there are macros to support this pattern in the SDK-1600. You can have something like this: D_DISC PROC BEGIN MVI PAGESTEP, R0 SWITCH R0, @@swt_tbl ; ON 0, 1, 2... @@swt_tbl: DECLE @@case1, @@case2, @@case3 @@case1: ; R0 = 0 RETURN @@case2: ; R0 = 1 RETURN @@case3: ; R0 = 2 RETURN ENDP However, notice that it only jumps when a valid case is found. There is no "else" so you'll have to test that outside the switch. Since the PAGESTEP value is sequential, just test for any value greater than the ones that are valid in the @@swt_tbl: D_DISC PROC BEGIN MVI PAGESTEP, R0 CMPI #3, R0 ; Accept values below 3 BGE @@else ; SWITCH R0, @@swt_tbl ; ON 0, 1, 2... @@swt_tbl: DECLE @@case1, @@case2, @@case3 @@case1: ; R0 = 0 RETURN @@case2: ; R0 = 1 RETURN @@case3: ; R0 = 2 @@else: RETURN ENDP -dZ. Quote Link to comment Share on other sites More sharing options...
vprette Posted February 9, 2012 Author Share Posted February 9, 2012 (edited) I have implemented the music tag! music is stopped and reactivated correctly, AND psg is silenced it was easy as DZj say!! New status (Blue is done, Green is faisable, Yellow is difficult. Red is very hard to code for me) - TITLE SCREEN: ok (custom screen) - INTRO: ok (welcome message) - INIT: ok (integrate tracker and start demo music) - FONT: ok (custom) - CONTENTS: insert all levels message text descriptions 25% [huge task] - MUSIC: translate mod to decles of custom music "shadows" - PLAY ENGINE1: ok (implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure) - PLAY ENGINE2: ok (inputs from keypad reconnaise 8 directions, "Clear" as music pause and disc touch) - PLAY ENGINE3: implement text input from keyboard - PLAY ENGINE4: implement level logic transition machine (game walkthrough) [huge task] - PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine [huge task] - PLAY ENGINE6: ok (implement music pause) - SCORE: implement scoring - BUG TESTING: - BOX: 80% - OVERLAYS: - MANUAL: 5% Overall: 20% Edited February 9, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 9, 2012 Share Posted February 9, 2012 I have implemented the music tag! music is stopped and reactivated correctly, AND psg is silenced it was easy as DZj say!! New status (Blue is done, Green is faisable, Yellow is difficult. Red is very hard to code for me) - TITLE SCREEN: ok (custom screen) - INTRO: ok (welcome message) - INIT: ok (integrate tracker and start demo music) - FONT: ok (custom) - CONTENTS: insert all levels message text descriptions 25% (huge task) - MUSIC: translate mod to decles of custom music "shadows" - PLAY ENGINE1: ok (implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure) - PLAY ENGINE2: ok (inputs from keypad reconnaise 8 directions, "Clear" as music pause and disc touch) - PLAY ENGINE3: implement text input from keyboard - PLAY ENGINE4: implement level logic transition machine (game walkthrough) (huge task) - PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine (huge task) - PLAY ENGINE6: ok (implement music pause) - SCORE: implement scoring - BUG TESTING: - BOX: 80% - OVERLAYS: - MANUAL: 5% Overall: 20% That's great, Valter! -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 Valter, I know you said you had the music pause ready, but I just realized that the code to do it is already available in P-Machinery (recall, that it had music already, I just took it out). To pause, you do the following. The GAME_INFO.PsgState is a variable already defined to keep the previous state of the PSG. MVI PSG0.chan_enable, R0 ; \ MVO@ R0, GAME_INFO.PsgState ; |_ Mute all PSG channels MVII #$3F, R0 ; | (saving their status). MVO R0, PSG0.chan_enable ; / To unpause the music you reset the PSG state: MVI GAME_INFO.PsgState, R0 ; \_ Unmute all PSG channels MVO R0, PSG0.chan_enable ; / Note that this code actually just mutes the PSG by setting the volume of all channels to zero. It is up to your game to "pause" the music state by not calling TRKPLAY, as we have discussed before. Otherwise, it'll just keep playing, you just won't hear it. By the way, that code is already available in the PAUSE_GAME routine in "engine_util.asm." Pausing the game by hitting 1+9 during the title screen or the game-play levels is already built-in, and pauses the music as well. -dZ. Quote Link to comment Share on other sites More sharing options...
vprette Posted February 10, 2012 Author Share Posted February 10, 2012 (edited) thanks I started looking to the game walkthrough logic.... not easy since the original code is in fortran! other source in C are modified from the original and change contents... so it seems I have to learn Fortran as well! the second thing I would like to care about is allowing ECS keyboard after reading all the docs, I find out there are 214 pages to be written, so far I have written only 32... it means the final rom will be very big, probably more than 100K . Hope this not introduce issues Edited February 10, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
catsfolly Posted February 10, 2012 Share Posted February 10, 2012 Do you mean 100k bytes or 100k words? The Intellivision can easily handle 42k words programs. Larger sizes require bank switching, which means sections of memory have to be switched in and out. It makes life more complicated. Joe Zbiciak wrote some routines for Space Patrol that can create and print "packed strings" containing 2 characters per word. This is better than the regular "string" command which stores 1 character per word. Using these routines would cut your memory requirements in half. See the discussion in http://games.groups....og/message/7141 for details. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 Do you mean 100k bytes or 100k words? The Intellivision can easily handle 42k words programs. Larger sizes require bank switching, which means sections of memory have to be switched in and out. It makes life more complicated. Joe Zbiciak wrote some routines for Space Patrol that can create and print "packed strings" containing 2 characters per word. This is better than the regular "string" command which stores 1 character per word. Using these routines would cut your memory requirements in half. See the discussion in http://games.groups....og/message/7141 for details. By the way, P-Machinery has some routines to support packed strings. (Actually, wrappers to Joe's routines). I don't think I included them in the last release, but they will be there in the next one. Like David said, you should really pack your strings, 2 characters per word, or else the game is going to be huge! -dZ. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 10, 2012 Share Posted February 10, 2012 If you used radix 40 you could pack 3 characters per word. That gets you upper case 'A' to 'Z', '0' to '9' and four left over for punctuation e.g. ' ', '.', '?' and '!'. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 (edited) Also, I wonder if instead of a straight port you should work on a re-implementation. A game engine should be simple enough to create natively in the Intellivision, and then it's a matter of including the room and item descriptions. I don't think I ever played Colossal Cave Adventure, but from what I understand it is the granddaddy of text adventure and interactive-fiction games. In my experience on working on Z-Machine, SCUMM, and SGI in the past , they usually operate in a similar way: There is a set of room and item objects with attributes that include which items are in each room and their state. Each room and item has a name and a description. The commands accepted are typically of the form "VERB NOUN," where "NOUN" may be optional. There is a dispatch table for each room that maps an accepted verb to a handler function, with a default handler available for some actions like "TAKE" and "LOOK." The game engine parses the command line into tokens, looks up the "VERB" token in the ones defined for the current room; if there, it calls the assigned function; otherwise responds with an error such as "I DON'T KNOW WHAT %VERB% MEANS." The verb handling function then tests to see if a noun was provided. If the verb requires a noun, and none was provided, it responds with an error such as "WHAT DO YOU WANT ME TO %VERB% WITH?" If a noun is required but the token does not match any of the known owns, it responds with an error such as "I DO NOT SEE ANY %NOUN% here." The state of objects, the player, and the world in general is kept in global variables which are updated by the verb handlers. A verb handler also tests for the current state of objects and the world. For instance, if the verb is "LOOK" but the player inventory does not contain the lamp, and the room is dark, the game may respond with "YOU SEE NOTHING IN THE DARK." Otherwise, it responds with the room description. I'm sure a simple machine like this can be constructed in the Intellivision. To simplify things, compromises can be made in the number of items accepted in inventory, the number of rooms available, and the number of verbs or nouns accepted per room. Just an idea. -dZ. Edited February 10, 2012 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 10, 2012 Share Posted February 10, 2012 (edited) If you used radix 40 you could pack 3 characters per word. That gets you upper case 'A' to 'Z', '0' to '9' and four left over for punctuation e.g. ' ', '.', '?' and '!'. You can do even better with "dictionary" compression. Colossal Cave (and any text adventure) reuses many words, so at some point it may be worth actually compressing the text that way and writing a simple decompressor. For example, if you just did something really dumb and stored a 16 bit address for each word, then the decompressor would look something like this, conceptually: Get address of next word If it's 0, stop. If it's not zero, print the word stored at the address. Print a space character. Repeat Since most words will be more than 2 characters and since the space character is implicit, that super simple scheme would net you a noticeable savings. To take most of the pain out of it, though, it may be worth scripting the compression outside of the assembler, and have it generate the assembly for you. Otherwise, you'd have to write all that stuff manually: DICT PROC[/font] @@Welcome S16 "Welcome" @@to S16 "to" @@Colossal S16 "Colossal" @@Cave_ S16 "Cave." ENDP MSG PROC @@intro DECLE DICT.Welcome, DICT.to, DICT.Colossal, DICT.Cave_, 0 ENDP That encoding took up 15 words (if I counted correctly). The original phrase took 27 bytes (including terminating NUL), so there's a modest increase here, since there was no reuse. I say modest increase because 15 words is 30 bytes. But the moment you reuse a word, you start gaining. (Side note: S16 is my macro for encoding packed strings, with two bytes per word.) You can obviously gain much, much more with more sophisticated compression. (Second side note: This editor hates me when I try to post well formatted code.) I don't think I ever played Colossal Cave Adventure, but from what I understand it is the granddaddy of text adventure and interactive-fiction games. It appears my Ubuntu box has it installed (under the name "adventure"). I wouldn't be surprised if you could find a version that compiles on MacOS X easily, since I think it's part of the BSD Games distribution. (I'd check right now, but for whatever reason I can't connect to my wife's Mac.) Edit: This appears to be a MacOS X port of one version of Adventure: http://www.lobotomo.com/products/Adventure/index.html Edited February 10, 2012 by intvnut Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 10, 2012 Share Posted February 10, 2012 Valter, Do you have a link to that FORTRAN? It might be instructive to me to play with its table of phrases. According to Wikipedia, the original game required about 300K bytes of core, which is beyond what fits in JLP. But, I think we can do better through compression. Quote Link to comment Share on other sites More sharing options...
vprette Posted February 10, 2012 Author Share Posted February 10, 2012 If you used radix 40 you could pack 3 characters per word. That gets you upper case 'A' to 'Z', '0' to '9' and four left over for punctuation e.g. ' ', '.', '?' and '!'. You can do even better with "dictionary" compression. Colossal Cave (and any text adventure) reuses many words, so at some point it may be worth actually compressing the text that way and writing a simple decompressor. For example, if you just did something really dumb and stored a 16 bit address for each word, then the decompressor would look something like this, conceptually: Get address of next word If it's 0, stop. If it's not zero, print the word stored at the address. Print a space character. Repeat Since most words will be more than 2 characters and since the space character is implicit, that super simple scheme would net you a noticeable savings. To take most of the pain out of it, though, it may be worth scripting the compression outside of the assembler, and have it generate the assembly for you. Otherwise, you'd have to write all that stuff manually: DICT PROC[/font] @@Welcome S16 "Welcome" @@to S16 "to" @@Colossal S16 "Colossal" @@Cave_ S16 "Cave." ENDP MSG PROC @@intro DECLE DICT.Welcome, DICT.to, DICT.Colossal, DICT.Cave_, 0 ENDP That encoding took up 15 words (if I counted correctly). The original phrase took 27 bytes (including terminating NUL), so there's a modest increase here, since there was no reuse. I say modest increase because 15 words is 30 bytes. But the moment you reuse a word, you start gaining. (Side note: S16 is my macro for encoding packed strings, with two bytes per word.) You can obviously gain much, much more with more sophisticated compression. (Second side note: This editor hates me when I try to post well formatted code.) I don't think I ever played Colossal Cave Adventure, but from what I understand it is the granddaddy of text adventure and interactive-fiction games. It appears my Ubuntu box has it installed (under the name "adventure"). I wouldn't be surprised if you could find a version that compiles on MacOS X easily, since I think it's part of the BSD Games distribution. (I'd check right now, but for whatever reason I can't connect to my wife's Mac.) Edit: This appears to be a MacOS X port of one version of Adventure: http://www.lobotomo....ture/index.html If you used radix 40 you could pack 3 characters per word. That gets you upper case 'A' to 'Z', '0' to '9' and four left over for punctuation e.g. ' ', '.', '?' and '!'. You can do even better with "dictionary" compression. Colossal Cave (and any text adventure) reuses many words, so at some point it may be worth actually compressing the text that way and writing a simple decompressor. For example, if you just did something really dumb and stored a 16 bit address for each word, then the decompressor would look something like this, conceptually: Get address of next word If it's 0, stop. If it's not zero, print the word stored at the address. Print a space character. Repeat Since most words will be more than 2 characters and since the space character is implicit, that super simple scheme would net you a noticeable savings. To take most of the pain out of it, though, it may be worth scripting the compression outside of the assembler, and have it generate the assembly for you. Otherwise, you'd have to write all that stuff manually: DICT PROC[/font] @@Welcome S16 "Welcome" @@to S16 "to" @@Colossal S16 "Colossal" @@Cave_ S16 "Cave." ENDP MSG PROC @@intro DECLE DICT.Welcome, DICT.to, DICT.Colossal, DICT.Cave_, 0 ENDP That encoding took up 15 words (if I counted correctly). The original phrase took 27 bytes (including terminating NUL), so there's a modest increase here, since there was no reuse. I say modest increase because 15 words is 30 bytes. But the moment you reuse a word, you start gaining. (Side note: S16 is my macro for encoding packed strings, with two bytes per word.) You can obviously gain much, much more with more sophisticated compression. (Second side note: This editor hates me when I try to post well formatted code.) I don't think I ever played Colossal Cave Adventure, but from what I understand it is the granddaddy of text adventure and interactive-fiction games. It appears my Ubuntu box has it installed (under the name "adventure"). I wouldn't be surprised if you could find a version that compiles on MacOS X easily, since I think it's part of the BSD Games distribution. (I'd check right now, but for whatever reason I can't connect to my wife's Mac.) Edit: This appears to be a MacOS X port of one version of Adventure: http://www.lobotomo....ture/index.html I have this one for OSX, this is the Wood's expanded, I guess 40% bigger Quote Link to comment Share on other sites More sharing options...
vprette Posted February 10, 2012 Author Share Posted February 10, 2012 Valter, Do you have a link to that FORTRAN? It might be instructive to me to play with its table of phrases. According to Wikipedia, the original game required about 300K bytes of core, which is beyond what fits in JLP. But, I think we can do better through compression. http://jerz.setonhill.edu/if/crowther/ Quote Link to comment Share on other sites More sharing options...
vprette Posted February 10, 2012 Author Share Posted February 10, 2012 (edited) I admit I'm a bit demoralized since I have now systematic crash when running the rom, even if there are no error from the compiler... I don't know if this is realted to the memory dimension of the rom: has jzintv some limitation for running 18k roms? what happend is that I simply add more levels/pages to the st_level.asm. I just COPY existing code updating the name of the proc to LEVEL_32...LEVEL_33 etc. at one point, adding another level, make the rom crash.... it's not due to the contents of the code since I'm just adding level after level, like this ;; LEVEL_32: snake ;; ======================================================================== ;; LEVEL_32 PROC BEGIN CALL CLRSCR CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU@CAN9T@GET@BY@THESNAKE=@' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 RETURN ENDP ;; LEVEL_33 ;; ======================================================================== ;; LEVEL_33 PROC BEGIN CALL CLRSCR CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 RETURN ENDP ;; LEVEL_34 ;; ======================================================================== ;; LEVEL_34 PROC BEGIN CALL CLRSCR CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 RETURN ENDP ....... I do call each of these PROC from LEVEL_1 for testing the txt (below I call level31)... ;; ======================================================================== ;; ;; LEVEL_1: descrizione foresta 1 ;; ;; ======================================================================== ;; LEVEL_1 PROC BEGIN SET_GAME_STATE(LEVEL, Play, cNormal) ; Engage the Level Play engine. CALL CLRSCR ; Clear the screen CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU@ARE@STANDING@AT@THE@END@OF@A@ROAD@@@BEFORE@A@SMALL@BRICKBUILDING=' STRING '@@@@@@@@@@@AROUND@YOU@IS@A@@@@@FOREST=@@@@@@@' STRING '@@@@@@@@@@@@@@@@@@@@@@@@@@A@SMALL@STREAM@FLOWSOUT@OF@THE@BUILDING@AND@DOWN@A@GULLY=@@@@@@@@@@@@@@@@@@@@@@' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 call LEVEL_31 RETURN ENDP it works perfectly until LEVEL_32, as soon I add one more level I have a rom compiled without errors that crash when launched....... this is related to jzintv? what kind of error report can I force jzintv to provide? Edited February 10, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 10, 2012 Share Posted February 10, 2012 The Inty memory map is not continuous for cart ROMs. You have $5000 to $6FFF free and then you must move part of your code to $8000 to $BFFF. Have a look in your symbol table and check if labels are in the range $7000 to $7FFF. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 it works perfectly until LEVEL_32, as soon I add one more level I have a rom compiled without errors that crash when launched....... this is related to jzintv? what kind of error report can I force jzintv to provide? I can tell you it is not jzIntv. That is for sure. If you are able to run the debugger, then turn the CPU history on with the command "H" then "R" to run the emulation, then when it crashes type "D" to "dump" the CPU history. Send me the "*.hst" file it generates and I'll take a look at what happened. The attached BATCH files are the ones now distributed with P-Machinery for Windows, and it assembles with symbols and execute the emulator with the necessary debug information. Copy them to the folder where you game is stored. You can then assemble from the DOS prompt like this: C:\build.sh Then you run the debugger like this: C:\run.sh -d To run normally, just use "run.sh" -dZ. batchfiles.zip Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 The Inty memory map is not continuous for cart ROMs. You have $5000 to $6FFF free and then you must move part of your code to $8000 to $BFFF. Have a look in your symbol table and check if labels are in the range $7000 to $7FFF. That shouldn't be a problem, GroovyBee. P-Machinery uses the "cart.mac" macro that abstracts the ROM segments. It uses by default the first segment with a memory map of 16K, but it is configurable. It then tracks memory allocation and gives an error on assembly if the address space available is overrun. Allocating code and data to different segments is as simple as calling a macro, for example, ROMSEG 2 If there was a memory problem, he should have received an assembler error, so I'm more inclined to think it is either a stack overflow or some other logic error. -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 I admit I'm a bit demoralized since I have now systematic crash when running the rom, even if there are no error from the compiler... I don't know if this is realted to the memory dimension of the rom: has jzintv some limitation for running 18k roms? what happend is that I simply add more levels/pages to the st_level.asm. I just COPY existing code updating the name of the proc to LEVEL_32...LEVEL_33 etc. at one point, adding another level, make the rom crash.... it's not due to the contents of the code since I'm just adding level after level, like this ;; LEVEL_32: snake ;; ======================================================================== ;; LEVEL_32 PROC BEGIN CALL CLRSCR CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU@CAN9T@GET@BY@THESNAKE=@' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 RETURN ENDP ;; LEVEL_33 ;; ======================================================================== ;; LEVEL_33 PROC BEGIN CALL CLRSCR CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 RETURN ENDP ;; LEVEL_34 ;; ======================================================================== ;; LEVEL_34 PROC BEGIN CALL CLRSCR CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 RETURN ENDP ....... I do call each of these PROC from LEVEL_1 for testing the txt (below I call level31)... ;; ======================================================================== ;; ;; LEVEL_1: descrizione foresta 1 ;; ;; ======================================================================== ;; LEVEL_1 PROC BEGIN SET_GAME_STATE(LEVEL, Play, cNormal) ; Engage the Level Play engine. CALL CLRSCR ; Clear the screen CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200 STRING 'YOU@ARE@STANDING@AT@THE@END@OF@A@ROAD@@@BEFORE@A@SMALL@BRICKBUILDING=' STRING '@@@@@@@@@@@AROUND@YOU@IS@A@@@@@FOREST=@@@@@@@' STRING '@@@@@@@@@@@@@@@@@@@@@@@@@@A@SMALL@STREAM@FLOWSOUT@OF@THE@BUILDING@AND@DOWN@A@GULLY=@@@@@@@@@@@@@@@@@@@@@@' BYTE 0 CALL PRINT.FLS DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $02dc STRING '?;' BYTE 0 call LEVEL_31 RETURN ENDP it works perfectly until LEVEL_32, as soon I add one more level I have a rom compiled without errors that crash when launched....... this is related to jzintv? what kind of error report can I force jzintv to provide? Valter, can you provide the code that calls the multiple levels? Perhaps there is something wrong there. Also, 32 is a power of two, so that makes it suspect as some sort of bad pointer outside a look-up table or something like that. -dZ. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 10, 2012 Share Posted February 10, 2012 That shouldn't be a problem, GroovyBee. P-Machinery uses the "cart.mac" macro that abstracts the ROM segments. I'm so "old school" on the Inty . Quote Link to comment Share on other sites More sharing options...
vprette Posted February 10, 2012 Author Share Posted February 10, 2012 it works perfectly until LEVEL_32, as soon I add one more level I have a rom compiled without errors that crash when launched....... this is related to jzintv? what kind of error report can I force jzintv to provide? I can tell you it is not jzIntv. That is for sure. If you are able to run the debugger, then turn the CPU history on with the command "H" then "R" to run the emulation, then when it crashes type "D" to "dump" the CPU history. Send me the "*.hst" file it generates and I'll take a look at what happened. The attached BATCH files are the ones now distributed with P-Machinery for Windows, and it assembles with symbols and execute the emulator with the necessary debug information. Copy them to the folder where you game is stored. You can then assemble from the DOS prompt like this: C:\build.sh Then you run the debugger like this: C:\run.sh -d To run normally, just use "run.sh" -dZ. batchfiles.zip wait, are you speaking MACOS or windows? I work in windows Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 That shouldn't be a problem, GroovyBee. P-Machinery uses the "cart.mac" macro that abstracts the ROM segments. I'm so "old school" on the Inty . Yeah, I know. Joe has done a terrific job with the SDK-1600. That "cart.mac" handles the ROM header, stack allocation, System and Scratch RAM allocation, and even ROM segmenting transparently--it's a thing of beauty. -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 10, 2012 Share Posted February 10, 2012 (edited) it works perfectly until LEVEL_32, as soon I add one more level I have a rom compiled without errors that crash when launched....... this is related to jzintv? what kind of error report can I force jzintv to provide? I can tell you it is not jzIntv. That is for sure. If you are able to run the debugger, then turn the CPU history on with the command "H" then "R" to run the emulation, then when it crashes type "D" to "dump" the CPU history. Send me the "*.hst" file it generates and I'll take a look at what happened. The attached BATCH files are the ones now distributed with P-Machinery for Windows, and it assembles with symbols and execute the emulator with the necessary debug information. Copy them to the folder where you game is stored. You can then assemble from the DOS prompt like this: C:\build.sh Then you run the debugger like this: C:\run.sh -d To run normally, just use "run.sh" -dZ. batchfiles.zip wait, are you speaking MACOS or windows? I work in windows Well, I've learned my lesson. Those are for Windows. I should have mentioned "*.bat" not "*.sh" in my comment, though. -dZ. Edited February 10, 2012 by DZ-Jay 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.