236 replies to this topic

[GroovyBee]

vprette, on Thu Feb 9, 2012 6:06 AM, said:

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.

[DZ-Jay]

vprette, on Thu Feb 9, 2012 6:06 AM, said:

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.

[vprette]

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 by vprette, Thu Feb 9, 2012 8:01 AM.

[DZ-Jay]

vprette, on Thu Feb 9, 2012 7:46 AM, said:

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.

[vprette]

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 by vprette, Thu Feb 9, 2012 9:48 AM.

[DZ-Jay]

vprette, on Thu Feb 9, 2012 9:01 AM, said:

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.

[DZ-Jay]

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.

[vprette]

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 by vprette, Fri Feb 10, 2012 5:43 AM.

[catsfolly]

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.

[DZ-Jay]

catsfolly, on Fri Feb 10, 2012 6:05 AM, said:

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.

[GroovyBee]

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

[DZ-Jay]

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 by DZ-Jay, Fri Feb 10, 2012 7:03 AM.

[intvnut]

GroovyBee, on Fri Feb 10, 2012 6:35 AM, said:

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

DZ-Jay, on Fri Feb 10, 2012 7:01 AM, said:

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

Edited by intvnut, Fri Feb 10, 2012 1:29 PM.

[intvnut]

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.

[vprette]

intvnut, on Fri Feb 10, 2012 1:15 PM, said:

GroovyBee, on Fri Feb 10, 2012 6:35 AM, said:

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

DZ-Jay, on Fri Feb 10, 2012 7:01 AM, said:

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

intvnut, on Fri Feb 10, 2012 1:15 PM, said:

GroovyBee, on Fri Feb 10, 2012 6:35 AM, said:

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

DZ-Jay, on Fri Feb 10, 2012 7:01 AM, said:

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

[vprette]

intvnut, on Fri Feb 10, 2012 1:26 PM, said:

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/

[vprette]

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 by vprette, Fri Feb 10, 2012 3:21 PM.

[GroovyBee]

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.

[DZ-Jay]

Quote

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   1.35K   7 downloads

[DZ-Jay]

GroovyBee, on Fri Feb 10, 2012 3:35 PM, said:

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.

[DZ-Jay]

vprette, on Fri Feb 10, 2012 3:19 PM, said:

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.

[GroovyBee]

DZ-Jay, on Fri Feb 10, 2012 3:41 PM, said:

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 .

[vprette]

DZ-Jay, on Fri Feb 10, 2012 3:37 PM, said:

Quote

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   1.35K   7 downloads

wait, are you speaking MACOS or windows? I work in windows

[DZ-Jay]

GroovyBee, on Fri Feb 10, 2012 3:44 PM, said:

DZ-Jay, on Fri Feb 10, 2012 3:41 PM, said:

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.

[DZ-Jay]

vprette, on Fri Feb 10, 2012 3:47 PM, said:

DZ-Jay, on Fri Feb 10, 2012 3:37 PM, said:

Quote

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   1.35K   7 downloads

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 by DZ-Jay, Fri Feb 10, 2012 3:49 PM.