DZ-Jay

February 11, 2012

In any case, I think Valter's issue is that he's spilling into $7xxx. I think he should switch to the 42K memory map, and add some ROMSEG directives to move his data out of the very limited $5000 - $6FFF segment.

--Joe

I agree, but wouldn't cart.mac catch this? P-Mach is using it, with a very explicit ROMEND at the bottom--unless it got overwritten...

February 10, 2012

This is strange. Looking at a history dump of the ROM when it crashes, it seems to crash during the ROM header setup. The dump is identical to another one from my own game up until the point when the EXEC is reading the copyright date. There's a test there that fails:
5014 0000 0000 0000 01FE 103C 02F1 101D ---Z--iq  [email protected] R5,R1			  604
5014 0070 0000 0000 01FE 103D 02F1 101E ---Z--iq  SWAP R1				 612
5014 7000 0000 0000 01FE 103D 02F1 101F -------q  [email protected] R1,R0			  618
FFFF 7000 0000 0000 01FE 103D 02F1 1020 ------iq  SWAP R0				 626
FFFF 7000 0000 0000 01FE 103D 02F1 1021 S------q  ANDI #$00FC,R0		  632

0000 7000 0000 0000 01FE 103D 02F1 1023 ---Z--iq  BNEQ $1003			  640
In address $1021, my game results in a non-zero value, while the Colossal Cave ROM does, causing it fall through and jump to address $7000 (R1). It's a fast death shortly thereafter:
0000 7000 0000 0000 01FE 103D 02F1 1025 ---Z--iq  MOVR R1,R7			  647
0000 7000 0000 0000 01FE 103D 02F1 7000 ------iq  SDBD					654
0000 7000 0000 0000 01FE 103D 02F1 7001 -----D-q  SDBD					658
0000 7000 0000 0000 01FE 103D 02F1 7002 -----D-q  SDBD					662
0000 7000 0000 0000 01FE 103D 02F1 7003 -----D-q  SDBD					666
0000 7000 0000 0000 01FE 103D 02F1 7004 -----D-q  SDBD					670
0000 7000 0000 0000 01FE 103D 02F1 7005 -----D-q  SDBD					674
0000 7000 0000 0000 01FE 103D 02F1 7006 -----D-q  HLT					 678
Perhaps Joe can shed some light?

Valter, did you change anything in the way the ROM is set up at the top of the main source file:
ROMSETUP 16K, 2010, "P-MACH Test", BOOT_UP, STACK_SIZE
I suppose it is possible that some memory has been overwritten...

Attached is the CPU history dump.

-dZ.

dump.hst.txt

OK, it's not the copyright date, that happens before. According to the memory map, address $7000 is the ECS EXEC ROM. Whatever it is, the test results in zero, causing it to fall through and ultimately crash.

I don't know much about the underlying EXEC, so I'm afraid I can't help much.

-dZ.

February 10, 2012

This is strange. Looking at a history dump of the ROM when it crashes, it seems to crash during the ROM header setup. The dump is identical to another one from my own game up until the point when the EXEC is reading the copyright date. There's a test there that fails:

5014 0000 0000 0000 01FE 103C 02F1 101D ---Z--iq  [email protected] R5,R1			  604
5014 0070 0000 0000 01FE 103D 02F1 101E ---Z--iq  SWAP R1				 612
5014 7000 0000 0000 01FE 103D 02F1 101F -------q  [email protected] R1,R0			  618
FFFF 7000 0000 0000 01FE 103D 02F1 1020 ------iq  SWAP R0				 626
FFFF 7000 0000 0000 01FE 103D 02F1 1021 S------q  ANDI #$00FC,R0		  632

0000 7000 0000 0000 01FE 103D 02F1 1023 ---Z--iq  BNEQ $1003			  640

In address $1021, my game results in a non-zero value, while the Colossal Cave ROM does, causing it fall through and jump to address $7000 (R1). It's a fast death shortly thereafter:

0000 7000 0000 0000 01FE 103D 02F1 1025 ---Z--iq  MOVR R1,R7			  647
0000 7000 0000 0000 01FE 103D 02F1 7000 ------iq  SDBD					654
0000 7000 0000 0000 01FE 103D 02F1 7001 -----D-q  SDBD					658
0000 7000 0000 0000 01FE 103D 02F1 7002 -----D-q  SDBD					662
0000 7000 0000 0000 01FE 103D 02F1 7003 -----D-q  SDBD					666
0000 7000 0000 0000 01FE 103D 02F1 7004 -----D-q  SDBD					670
0000 7000 0000 0000 01FE 103D 02F1 7005 -----D-q  SDBD					674
0000 7000 0000 0000 01FE 103D 02F1 7006 -----D-q  HLT					 678

Perhaps Joe can shed some light?

Valter, did you change anything in the way the ROM is set up at the top of the main source file:

ROMSETUP 16K, 2010, "P-MACH Test", BOOT_UP, STACK_SIZE

I suppose it is possible that some memory has been overwritten...

Attached is the CPU history dump.

-dZ.

dump.hst.txt

February 10, 2012

Valter, where is "LEVEL_1" being called from? I see that it sets the state, but the state should have been set before, no?

-dZ.

Nevermind that.

February 10, 2012

Valter, where is "LEVEL_1" being called from? I see that it sets the state, but the state should have been set before, no?

-dZ.

February 10, 2012

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.

I send you the st_level.asm and, yes it's not jzintv, it's crashing with Nostalgia also

jzIntv may have some bugs, though I don't know of any right now; but it is a very robust program and expressly designed for developers.

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
Well, I've learned my lesson. Those are for Windows. I should have mentioned "*.bat" not "*.sh" in my comment, though.

-dZ.

You extract the "*.bat" files from the ZIP file, and copy them to the "col" folder where you keep your code. Then you open a "Command" shell window and change directory to that folder:

C:\CD C:\path\to\game\folder

And run the batch files from there.

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

Well, I've learned my lesson. Those are for Windows. I should have mentioned "*.bat" not "*.sh" in my comment, though.

-dZ.

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.

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 '[email protected]@[email protected]@[email protected]'

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 '[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@@[email protected]@[email protected]='

STRING '@@@@@@@@@@@[email protected]@[email protected]@@@@@[email protected]@@@@@@'

STRING '@@@@@@@@@@@@@@@@@@@@@@@@@@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@@@@@@@@@@@@@@@@@@@@@'

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.

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.

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

February 10, 2012

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.

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.

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      ; \
       [email protected]    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.

February 10, 2012

Any new updates? I'm still real excited about this.

And this just happens to be one of the only times of the year i actually have any money, and i'm spending it hand over fist.

I'm sorry, but I recently had a family emergency that kept me from working on the game. I am now continuing with the development. The game is almost complete, only the final polish is what's left. It'll come out, I swear.

-dZ.

February 9, 2012

As always, you're welcome to incorporate any and all of the library functions I've written and put into the public domain. I've got code for reading the ECS keyboard and synth, for example, that you can take any time.

Thanks, I'll definitely make use of it, since most of P-Machinery already relies in the SDK-1600. The framework is mostly wrappers around that.

-dZ.

February 9, 2012

Hello:

I'm planning on working to update the P-Machinery engine/framework to fix some bugs, be more consistent in its nomenclature, and add new features.

Among the things I was thinking are needed are:

More variety of input decoders, such as support for two controllers and even including an ECS keyboard decoder.
A simpler abstraction of printable text functionality that will also support custom GRAM font sets without much effort.
Built-in support for music using Arnauld's tracker (I'll ask him first to make sure it's OK).
A basic Sprite Driver and programming model that is flexible and easy to use.

I also was thinking of writing simple game to accompany a tutorial on how to use P-Machinery in practical situations. Perhaps a version of "Tag-Along-Todd" built entirely in P-Machinery.

Regarding the Sprite Driver, what I want to do is offer a flexible programming model that abstracts all the hard stuff of handling sprites, such as limited access during VBLANK, collision detection, variable velocity, and animations. Something like simple data structures that keeps the state of the objects and are accessible at all times, and then blasted into the STIC registers and cycle GRAM as needed.

Does anybody have any additional suggestions or comments?

P-Machinery is intended not only to make it simpler for newcomers to get acquainted with the platform, but to actually ease the development of real games. It should offer facilities to make simple stuff very easy and almost automatic, and hard stuff at least possible.

-dZ.

February 9, 2012

Looking good found out about this on Intvrevolution

hey! i have seen that site....what an awesome site!

p.s. catsfolly....are you done with this game yet?

Nope. Not just yet...

Homebrew programming takes time!

"Donkey Kong Arcade started development in 2002." - from the Intellivision.us website. That's with Carl Mueller Jr. doing the programming, a guy who knows the Intellivision so well he can emulate it on wimpy 8 bit systems.

"Andrew Davie and Thomas Jentzsch have been working on this Atari 2600 port of Boulder Dash® for almost a decade." - from the Atariage home page.

I promise I will finish Paddle Party in less than 10 years.

Catsfolly

I understand you need more time.

So...

...

...Now?

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.

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.

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.

February 9, 2012

The dispatch table for CTRL_CHECKKEY needs to include event handlers for all input types.

yes I noticed, in fact I have cutted part of the code to make the post simplier, sorry :-)

It looks like you are doing the same for all directions. If this is the case, you do not need the comparisons. The event will be called whenever any direction is pressed on the disc, so just execute normally when that happens.

that's what I imagine, so I can cut all that code and write directly the IFTHEN part..

However, I am curious why you need a different procedure for each page? If you store your text in ROM and you index them with a table, then you can use the same routine to print the text always, just change the pointer to the table, no?

-dZ.

I will consider this, that would mean to have only 2 proc, one for Play sub-state and one for Page sub state.. I have to think about this

Sure. You know, on the "thinking" part, when I started working on my Pac-Man port, I spent months working on the theory of the game before ever writing a single line of code. I did not know much Assembly Language, had no idea about programming for Intellivision, understood very little about the colour and graphics restrictions, etc., so I concentrated on "thought experiments" to consider how to build the game in concept.

I took over an entire year of on-and-off "design" and "theory" work. At the end, I had a very clear idea of how to implement the game logic, for instance, how to track the pills eaten by Pac-Man, how to store the maze design in ROM in a way that encodes all path information, and how to maintain a table of parameters that change on every level. I also came up with a state machine model that I could use to handle the game engine.

Most of that theory resulted in P-Machinery and eventually culminated in Christmas Carol.

It's fun to start coding and see things happen right before your eyes, but sometimes it's more fruitful to spend some time considering how the entire thing would work, and how to put it together. It's boring stuff sometimes, and it's most in your head; but it leads to a more solid program.

This is your project, and you should do as you wish with it. There are probably ways in which I would do it differently, but I wouldn't want to impose my personal ways on you. After all, I'm also starting as a game programmer.

That said, I'll assist you in any way I can, just let me know if there's anything I can do. I just want to see other projects succeed.

-dZ.

February 9, 2012

Oh, by the way and unrelated to this last issue, I meant to mention before that there's a macro in P-Mach to convert screen coordinates into BACKTAB addresses. I noticed that you hardcode the position where you want text to appear when you call PRINT.FLS, and I thought you could use this instead to make it easier:

      CALL PRINT.FLS
      DECLE   C_GRN, BTAB_ADDRESS(col, row)
      DECLE   'This is my text'

Where "col" and "row" represent the screen column and row, respectively. Columns are from 0 to 19, rows are from 0 to 12.

-dZ.

February 9, 2012

I made a new brand for this project and hopefully further ECS projects of mine in the future :-)

do you like?

Looks nice.

About the test variable, I defined this on the "cart.mac"

; --------------------------------------

; Variable for Page state (from page to page)

; --------------------------------------

PAGESTEP SCRATCH 1

now what I need to do is add in the MY_INPUT_DISC proc check of the variable and CALL to correspondent page, plus incresing the variable.

In basic terms (blue being not-asm code to be translated)

MY_INPUT_DISC PROC

; --------------------------------------

; Event Dispatch Table

; --------------------------------------

DECLE D_DISC ; Disc

ENDP

The dispatch table for CTRL_CHECKKEY needs to include event handlers for all input types. You can just simply return with no code in the ones you don't want to handle, but they need to be there.

D_DISC PROC

BEGIN

; PAGE CHANGE - Handle disc input

CMPI #CTRL_DISC.Right, R2

BEQ @@disc

CMPI #CTRL_DISC.Left, R2

BEQ @@disc

CMPI #CTRL_DISC.Up, R2

BEQ @@disc

CMPI #CTRL_DISC.Down, R2

BEQ @@disc

It looks like you are doing the same for all directions. If this is the case, you do not need the comparisons. The event will be called whenever any direction is pressed on the disc, so just execute normally when that happens.

@@disc: ; choose page

IF PAGESTEP = 1 then

CALL LEVEL_2B

PAGESTEP = PAGESTEP +1

ELSEIF IF PAGESTEP = 2 then

CALL LEVEL_2C

PAGESTEP = PAGESTEP +1

...

RETURN

ENDP

how do I handle an IF... ELSEIF logic?

IF...ELSIF logic is handled using the test-and-jump pattern: you test for a condition and jump to a branch if true or false. You do this for all conditions you want to test. For example:

      MVI       PAGESTEP, R0

      ; IF (R0 = 1) THEN GOTO LEVEL_2B
      CMPI     #1, R0
      BEQ       LEVEL_2B

      ; ELSEIF (R0 = 2) THEN GOTO LEVEL_2C
      CMPI     #2, R0
      BEQ       LEVEL_2C

      ; ELSE

However, I am curious why you need a different procedure for each page? If you store your text in ROM and you index them with a table, then you can use the same routine to print the text always, just change the pointer to the table, no?

-dZ.

Sign In

Profiles

Member Map

Forums

Blogs

Gallery

Calendar

Store

Posts posted by DZ-Jay