Jump to content
IGNORED

Colossal Cave Adventure diary


vprette

Recommended Posts

I have defined 14 new fonts :-)

 

I have attached the updated custom font file

 

 

what is still NOT WORKING is that If I add a tile I lost one more letter.... I can print only 23 custom chars... no matter what number I write in DEFINE_GRAM_BLOCK

 

for each new font I add I lost one letter at the end of the list...

 

Let me clarify something. Adding characters to the set means that you'll have to change the format word formula. Adding them at the top means you are offsetting the position of the "A" character (ASCII 65) down, which means that you have to add that number of cards to the base card.

 

Also, you'll need to change the total size of the GRAM block, so you need to alter the call to DEFINE_GRAM_BLOCK to include how many tiles you need.

 

Can you post the code that you use to define the GRAM block, to load it, and to display it? The "stats" seem to suggest that no GRAM is being used. That doesn't sound right, unless you are not loading the cards at the right point.

 

If you miss the VBLANK window, it may cause some of the data to not make it to GRAM. This is why it is important to do so in the initialization routines, while interrupts are disabled. There are even comments in the P-Machinery code suggesting what to do.

 

It'll be much easier if you posted some code. Also if you described the output or posted a screenshot of it.

 

-dZ.

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

You referring to catsfolly post, not mine :-)

mine show 37 tiles used..

 

about code:

 

in p-match.asm

DEFINE_GRAM_BLOCK(font_belli, 37)

 

in st_title

LOAD_GRAM_BLOCK(LETTERS,font_belli)

 

in st_level

;; ======================================================================== ;;

;; LEVEL_TEST: show custom fonts ;;

;; ======================================================================== ;;

LEVEL_TEST PROC

 

BEGIN

CALL CLRSCR ; Clear the screen

CALL PRINT.FLS

DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200

STRING 'ABCDEFGHIJKLMNOPQRSTUVWXYZA'

DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $0250

STRING 'A@?=<;:9876543>'

BYTE 0

RETURN

ENDP

 

 

The 14 new fonts code is at the end of the post.

result is below: adding 14 custom tiles result in 14 chars disappearing (from J to Z)

 

even adding no new tiles, but just using DZj's 26 fonts from original LETTERS proc... I still write only 23 chars: X,Y and Z disappear!

 

test_font_screen.JPG

 

;ASCII TO CUSTOM FONTS:

;@ = spazio OK

;? = ? OK

;> = > OK

;= = . OK

;< = , OK

;; = ] OK

;: = " OK

;9 = ' OK

;8 = ( OK

;7 = ) OK

;6 = / OK

;5 = 2 OK

;4 = 3 OK

;3 = disc OK

 

LETTERS PROC

@@data_start:

 

; Meant to represent Joypad DISC

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

; ........ - %00000000

DECLE $3C00 ; ..####.. - %01111100

; .######. - %11000110

DECLE $7E7E ; .######. - %11000110

; .######. - %11000110

DECLE $3C7E ; ..####.. - %01111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

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

 

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

; ........ - %00000000

DECLE $3C00 ; ..####.. - %01111100

; .....#.. - %11000110

DECLE $1C04 ; ...###.. - %11000110

; .....#.. - %11000110

DECLE $3C04 ; ..####.. - %01111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

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

 

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

; ........ - %00000000

DECLE $3C00 ; ..####.. - %01111100

; .....#.. - %11000110

DECLE $1C04 ; ...###.. - %11000110

; ..#..... - %11000110

DECLE $3C20 ; ..####.. - %01111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

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

 

 

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

; ........ - %00000000

DECLE $0400 ; .....#.. - %01111100

; ....#... - %11000110

DECLE $1008 ; ...#.... - %11000000

; ..#..... - %11000110

DECLE $4020 ; .#...... - %01111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

 

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

; ........ - %00000000

DECLE $0800 ; ....#... - %01111100

; .....#.. - %11000110

DECLE $0404 ; .....#.. - %11000000

; .....#.. - %11000110

DECLE $0804 ; ....#... - %01111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

 

 

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

; ........ - %00000000

DECLE $1000 ; ...#.... - %01111100

; ..#..... - %11000110

DECLE $2020 ; ..#..... - %11000000

; ..#..... - %11000110

DECLE $1020 ; ...#.... - %01111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

 

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

; ........ - %00000000

DECLE $1000 ; ...#.... - %11111100

; ...#.... - %11000110

DECLE $0010 ; ........ - %11111100

; ........ - %11000110

DECLE $0000 ; ........ - %11111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

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

; ........ - %00000000

DECLE $2800 ; ..#.#... - %11111100

; ..#.#... - %11000110

DECLE $0028 ; ........ - %11111100

; ........ - %11000110

DECLE $0000 ; ........ - %11111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

 

 

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

; ####.... - %00000000

DECLE $30F0 ; ..##.... - %01111100

; ..##.... - %11000110

DECLE $3030 ; ..##.... - %11000110

; ..##.... - %11000110

DECLE $F030 ; ####.... - %01111100

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

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

 

 

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

; ...##... - %00000000

DECLE $1818 ; ...##... - %00000000

; ....#... - %00000000

DECLE $0008 ; ........ - %00000000

 

 

 

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

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

; ...##... - %00000000

DECLE $1818 ; ...##... - %00000000

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

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

; ..#..... - %00000000

DECLE $3020 ; ..##.... - %00000000

; ..###... - %00000000

DECLE $3C38 ; ..####.. - %00000000

; ..###... - %00000000

DECLE $3038 ; ..##.... - %00000000

; ..#..... - %00000000

DECLE $0020 ; ........ - %00000000

 

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

; ..###... - %00000000

DECLE $4438 ; .#...#.. - %00000000

; ....##.. - %00000000

DECLE $100C ; ...#.... - %00000000

; ........ - %00000000

DECLE $1000 ; ...#.... - %00000000

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

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

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

 

 

@@A: ; GRAM Tile: 0

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

; ........ - %00000000

DECLE $3800 ; ..###... - %00111000

; .##.##.. - %01101100

DECLE $C66C ; ##...##. - %11000110

; #######. - %11111110

DECLE $C6FE ; ##...##. - %11000110

; ........ - %00000000

DECLE $0000 ; ........ - %00000000

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

 

etc...

etc...

Edited by vprette
Link to comment
Share on other sites

You referring to catsfolly post, not mine :-)

mine show 37 tiles used..

 

about code:

 

in p-match.asm

DEFINE_GRAM_BLOCK(font_belli, 37)

 

in st_title

LOAD_GRAM_BLOCK(LETTERS,font_belli)

 

in st_level

;; ======================================================================== ;;

;; LEVEL_TEST: show custom fonts ;;

;; ======================================================================== ;;

LEVEL_TEST PROC

 

BEGIN

CALL CLRSCR ; Clear the screen

CALL PRINT.FLS

DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_GRN , $0200

STRING 'ABCDEFGHIJKLMNOPQRSTUVWXYZA'

DECLE ((237 + GRAM_BASE_CARD(font_belli)) SHL 3) OR C_YEL , $0250

STRING 'A@?=<;:9876543>'

BYTE 0

RETURN

ENDP

 

 

The 14 new fonts code is at the end of the post.

result is below: adding 14 custom tiles result in 14 chars disappearing (from J to Z)

 

even adding no new tiles, but just using DZj's 26 fonts from original LETTERS proc... I still write only 23 chars: X,Y and Z disappear!

 

test_font_screen.JPG

 

;ASCII TO CUSTOM FONTS:

;@ = spazio OK

;? = ? OK

;> = > OK

;= = . OK

;< = , OK

;; = ] OK

;: = " OK

;9 = ' OK

;8 = ( OK

;7 = ) OK

;6 = / OK

;5 = 2 OK

;4 = 3 OK

;3 = disc OK

 

 

I tried this and got similar results.

I found that if I moved the "LOAD_GRAM_BLOCK" to ST_LVL_INIT, it started to work...

 

		   CALL	STOPALLTASKS					;   1. Stop all tasks
			CALL	RESET_CTRL.Force				;   2. Reset Input Controller values
			CALL	RESET_STIC					  ;   3. Reset the STIC (clone) registers
			CALL	CLRSCR						  ;   4. Clear the screen

	   LOAD_GRAM_BLOCK(LETTERS,font_belli)

			CLRR	R0
			MVII	#PLAYER_INFO.Score,	 R4
...


 

But I don't know why this made a difference...

 

post-14916-0-11731900-1328564745_thumb.gif

 

catsfolly

Link to comment
Share on other sites

I tried this and got similar results.

I found that if I moved the "LOAD_GRAM_BLOCK" to ST_LVL_INIT, it started to work...

 

		   CALL	STOPALLTASKS					;   1. Stop all tasks
			CALL	RESET_CTRL.Force				;   2. Reset Input Controller values
			CALL	RESET_STIC					  ;   3. Reset the STIC (clone) registers
			CALL	CLRSCR						  ;   4. Clear the screen

	   LOAD_GRAM_BLOCK(LETTERS,font_belli)

			CLRR	R0
			MVII	#PLAYER_INFO.Score,	 R4
...


 

But I don't know why this made a difference...

 

First of all, in P-Machinery you should load GRAM on the initialization step of the state that you will use. This allows you to use different graphics characters for the title screen and for the game.

 

Second, it should have work in ST_TTL_INIT, but I think I just saw an error in P-Machinery. You need to remove the macro "ISR_ENABLE_DISPLAY" from the top of that procedure.

 

That's the problem. Let me explain.

 

Access to GRAM is restricted during what is called the VBLANK period, which is when the electron gun of the TV set is being realigned back to the top of the screen to draw a new frame. Also called vertical retrace. This period is rather short and is only available at the very beginning of an ISR, which is the handler of the hardware interrupt request for VBLANK.

 

Loading that many characters into GRAM takes so many cycles that there is not enough time to finish before VBLANK expires, and access to GRAM is locked out by the STIC (video chip). You don't get an error, but all reads or writes to GRAM will just be ignored.

 

However, the STIC only locks out the GRAM bus while the display is active (so that it can read graphics data to draw a frame for the video signal). Your code can take advantage of this fact and disable the display during an ISR routine, and then you have full and unrestricted access to GRAM--until the next VBLANK interrupt request arrives. It is then typical for initialization routines to not only disable the display, but to disable interrupts while loading data into GRAM.

 

By default, display will not be enabled until you write to a specific STIC register, so disabling display is as simple as not writing to that register during an ISR.

 

P-Machinery initialization routines are supposed to do this, except for one stupid error in the ST_TTL_INIT routine: the macro ISR_ENABLE_DISPLAY, which does what it says. That means that VBLANK will still expire as normal, and the STIC will assert control of the GRAM bus.

 

If you notice, ST_LVL_INIT doesn't have that macro, this is why it worked there.

 

I guess I didn't test custom GRAM graphics in the title screen in P-Machinery (for that matter, neither in Christmas Carol, which is why I didn't notice). Sorry about that.

 

-dZ.

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

Below is the updated version of ST_TTL_INIT as it will appear in P-Machinery from now on. The only difference is the removal of the ISR_ENABLE_DISPLAY macro.

 

I also moved the state transition to the bottom, but this is inconsequential. It was just to be consistent with the other initialization routines.

 


;; ======================================================================== ;;
;;  ST_TTL_INIT:  ISR routine to initialize the game environment.           ;;
;; ======================================================================== ;;
ST_TTL_INIT     PROC
               DIS     ; Start Critical Section

               CLRR    R0                              ; \_ Reset horizontal delay to zero
               MVO     R0,     STIC.h_delay            ; /

               ; --------------------------------------
               ; This is a good point to clear the screen
               ; and initialize background colours if
               ; using a custom Title Screen.
               ;
               ; We don't really draw the title screen
               ; here, we just initialize the environment.
               ; This includes loading graphics into
               ; GRAM, setting colours, initializing
               ; the STIC and all that boring back-end
               ; stuff.
               ;
               ; Staggering the tasks this way allows us
               ; to separate initializing (which should
               ; only happen once) and actually engaging
               ; the title screen (which could recur).
               ; --------------------------------------
                                                       ; Initialize environment for new game state
               CALL    STOPALLTASKS                    ;   1. Reset the task queue
               CALL    RESET_CTRL.Force                ;   2. Reset Input Controller values
               CALL    RESET_STIC                      ;   3. Reset the STIC (clone) registers
               ; CALL    CLRSCR                          ;   4. Clear the screen.

               MVII    #(TASK.Delay + 1),      R0      ; \_ Activate the default task
               MVO     R0,     TSKACT                  ; /     (this is used for delay timers and such)

               ; Interrupts are enabled on return
               SET_GAME_STATE(TITLE, Start, cNormal)   ; Change states
               IRET
               ENDP

Link to comment
Share on other sites

thanks as usual, it works now :-)

 

since I'm practising with gram, I'd like to tentativley introduce a graphic screen.

I have 2 pictures 160x72 to be used as welcome screen and final score screen...that means 180 tiles... what docs do I need to read to understand how to populate the screen? is there any developer tool to automatically convert a picture to decles?

picts.zip

Edited by vprette
Link to comment
Share on other sites

Large screens need to be made up from repeated tiles. For example, if you had bricks in the picture you would create one GRAM card of some bricks and use it several times. If you had a border like a picture frame you could use the same GRAM card for the left and right sides and another GRAM card for the top and bottom. There are also a selection of shapes in GROM. If you can use GROM cards you'll need less of the GRAM cards.

Link to comment
Share on other sites

When I zoom into the forest scene there are lots of artefacts (graphical junk). There are also 8x8 tiles that have more than 2 colours in them. so they would need MOB overlays. With quite a bit of work you could convert the images into Inty format. However, the conversions will lose some of the details so the images on the Inty wouldn't look exactly like those bitmaps.

Link to comment
Share on other sites

thanks as usual, it works now :-)

 

since I'm practising with gram, I'd like to tentativley introduce a graphic screen.

I have 2 pictures 160x72 to be used as welcome screen and final score screen...that means 180 tiles... what docs do I need to read to understand how to populate the screen? is there any developer tool to automatically convert a picture to decles?

 

You should read the Wiki and the documentation on the BACKTAB. The document "stic.txt" included with the SDK-1600 should be a good start.

 

The basic thing to know is that you do not "draw" on the screen as in other computers, but use GRAM cards to make the pictures. So you'll have to design your graphics as "tiles," load them into GRAM, and then assign the tiles and their colours to the BACKTAB, or Background Table.

 

Another important thing to remember is that there is very limited colour. Each tile can only use two colours: a Foreground and a Background colour. One of the pictures you sent looks like it may be too colourful for the Intellivision.

 

I personally don't know of any automated tools for tiling pictures for the BACKTAB. In my games so far I've done it by hand. I "draw" the picture in an ASCII file with colour attributes as symbols, and wrote a Perl script to convert it into GRAM tiles and BACKTAB data words. However, these are rather specific to the requirements of my games.

 

-dZ.

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

Update

 

- TITLE SCREEN: ok (custom screen)

- INTRO: ok (welcome message)

- INIT: ok (integrate tracker and start music)

- FONT: ok (custom)

- CONTENTS: insert all level message text descriptions 20%

- MUSIC: translate mod to decles

- PLAY ENGINE1: implement level to level to show several text description when pushing the disc or a key (like pages of a book)

- PLAY ENGINE2: implement inputs from keypad (8 directions, music pause and disc touch)

- PLAY ENGINE3: implement text input from keyboard

- PLAY ENGINE4 : implement level logic

- PLAY ENGINE5: implement the parser to reconnaise text commands inserted

- SCORE: implement scoring

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

 

Overall: 10%

 

this is the improvements thanks to the custom fonts :-) also I finalized the input interface bottom of the screen

 

font_screen.JPG

Edited by vprette
Link to comment
Share on other sites

Update

 

- TITLE SCREEN: ok (custom screen)

- INTRO: ok (welcome message)

- INIT: ok (integrate tracker and start music)

- FONT: ok (custom)

- CONTENTS: insert all level message text descriptions 20%

- MUSIC: translate mod to decles

- PLAY ENGINE1: implement level to level to show several text description when pushing the disc or a key (like pages of a book)

- PLAY ENGINE2: implement inputs from keypad (8 directions, music pause and disc touch)

- PLAY ENGINE3: implement text input from keyboard

- PLAY ENGINE4 : implement level logic

- PLAY ENGINE5: implement the parser to reconnaise text commands inserted

- SCORE: implement scoring

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

 

Overall: 10%

 

this is the improvements thanks to the custom fonts :-) also I finalized the input interface bottom of the screen

 

font_screen.JPG

 

Wow, it looks nice! Much more legible :)

They're a bit squashed, though. Those are a very old set I played with once. Let me see if I find the long ones.

 

-dZ.

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

I start working on the user input: the simpliest one is catching the disc pressure on the joypad, this is used to move from a page to another when text description is more than one page.... I was thinking about study the handdemo.asm in the sdk1600, unless you suggest a better code to look at...

 

in p-machinery it seems I should use

SET_GAME_STATE(LEVEL, wait, cNormal) or similar....

Edited by vprette
Link to comment
Share on other sites

I start working on the user input: the simpliest one is catching the disc pressure on the joypad, this is used to move from a page to another when text description is more than one page.... I was thinking about study the handdemo.asm in the sdk1600, unless you suggest a better code to look at...

 

There's code already provided in P-Machinery. Just take a look at the demo.

 

There are three controller decoders provided in the framework.

  • CTRL_CHECKANY - Triggers an event when any input is received. Good for "Press any key" situations, like the title screen.
  • CTRL_CHECKKEY - Triggers an event for each type of input received, keypad, disc, or action button.
  • CTRL_GAMEPLAY - Triggers an event when disc input is received, treating the disc as a 4-way joystick.

 

In P-Machinery, you assign which decoder your want to use for each machine sub-state in the GAME_STATE_DISP dispatch table defined in "st_dispatch.asm". This table defines all sub-states (up to 8 per main state. Main states are by default "Title," "Level," and "Game-Over." Sub-states are, for instance, "Title-init," "Title-start," "Title-end.")

 

The States and Sub-States are defined in the "state.const" file. For the moment just leave the defaults and we'll discuss new states later.

 

Let's consider the "Level" (Game-Play) state. It has 6 sub-states:


               ; STATE: Level
DEFINE_ENUM(GST_LEVEL, 
   ADD_ENUM_ELEMENT(Init   )
   ADD_ENUM_ELEMENT(Wait   )
   ADD_ENUM_ELEMENT(Play   )
   ADD_ENUM_ELEMENT(Retry  )
   ADD_ENUM_ELEMENT(Death  )
   ADD_ENUM_ELEMENT(Done   )
END_ENUM

 

If you check the default dispatch table for that state in "st_dispatch.asm" you'll see how each one is mapped to a handler routine in "st_level.asm":


               ; ------------------------------------------
               ; STATE: Level
               ; ------------------------------------------
               ;       State:                  Controller:     Dispatch:
               ;       --------------------    -----------     -----------
@@__level:      DECLE   ST_LVL_INIT,            CTRL_NONE,      NO_DISP
               DECLE   ST_WAIT_ENGINE,         CTRL_NONE,      NO_DISP
               DECLE   ST_LVL_PLAY,            CTRL_GAMEPLAY,  TEST_INPUT
               DECLE   ST_LVL_RETRY,           CTRL_NONE,      NO_DISP
               DECLE   ST_LVL_DEATH,           CTRL_NONE,      NO_DISP
               DECLE   ST_LVL_DONE,            CTRL_NONE,      NO_DISP
               DECLE   @@__dead,               CTRL_NONE,      NO_DISP
               DECLE   @@__dead,               CTRL_NONE,      NO_DISP

 

 

They are defined in order, so "Init" maps to "ST_LVL_INIT," "Wait" maps to ST_WAIT_ENGINE, "Play" maps to "ST_LVL_PLAY," etc.

 

Each record in the dispatch table is composed of three fields: The state handler routine, the controller decoder, and the decoder event handler required for the decoder. If no decoder is used for a state, it is mapped to "CTRL_NONE," which does nothing.

 

Notice that by default, the "Play" sub-state (ST_LVL_PLAY) is assigned the decoder CTRL_GAMEPLAY, with TEST_INPUT as the event handler. This means that during this state, P-Machinery will use the "joystick" disc decoder and call the TEST_INPUT when a disc event is detected.

 

The routine TEST_INPUT is the one that displays "up," "down," "right," and "left" in the demo.

 

That is a fine routine for arcade games like Pac-Man and Christmas Carol, but for your purpose you may want to change it to the general CTRL_CHECKKEY, which triggers and event for disc and other input.

 

So you would change it like this:

 


               ; ------------------------------------------
               ; STATE: Level
               ; ------------------------------------------
               ;       State:                  Controller:     Dispatch:
               ;       --------------------    -----------     -----------
@@__level:      DECLE   ST_LVL_INIT,            CTRL_NONE,      NO_DISP
               DECLE   ST_WAIT_ENGINE,         CTRL_NONE,      NO_DISP

               DECLE   ST_LVL_PLAY,            CTRL_CHECKKEY,  MY_INPUT    ; New decoder and event handler.

               DECLE   ST_LVL_RETRY,           CTRL_NONE,      NO_DISP
               DECLE   ST_LVL_DEATH,           CTRL_NONE,      NO_DISP
               DECLE   ST_LVL_DONE,            CTRL_NONE,      NO_DISP
               DECLE   @@__dead,               CTRL_NONE,      NO_DISP
               DECLE   @@__dead,               CTRL_NONE,      NO_DISP

 

Checking the documentation comments in CTRL_CHECKKEY, it says that instead of a straight event-handler, it expects a dispatch table defining the individual handlers for each of the input:


;;  DISPATCHER:                                                             ;;
;;  This routine expects a dispatch table of the following format:          ;;
;;                                                                          ;;
;;      DISP_TBL:   DECLE   keypad_handler                                  ;;
;;                  DECLE   action_handler                                  ;;
;;                  DECLE   disc_handler                                    ;;

 

So, you can implement "MY_INPUT" (or whatever you want to call it) like this:



;; ======================================================================== ;;
;;  Input Event Dispatch Table.                                             ;;
;; ======================================================================== ;;
MY_INPUT        PROC
               ; --------------------------------------
               ; Event Dispatch Table
               ; --------------------------------------
               DECLE   IN_KEYPAD                       ; Key pad
               DECLE   IN_ACTION                       ; Action buttons
               DECLE   IN_DISC                         ; Disc
               ENDP

;; ======================================================================== ;;
;;  Input Event Handlers.                                                   ;;
;; ======================================================================== ;;
IN_KEYPAD       PROC
               BEGIN

               ; Handle keypad input

               RETURN
               ENDP

IN_ACTION       PROC
               BEGIN

               ; Handle action button input

               RETURN
               ENDP

IN_DISC         PROC
               BEGIN

               ; Handle disc input

               RETURN
               ENDP

 

That's just an example, of course.

 

Furthermore, in the documentation comments of the CTRL_CHECKKEY decoder, it explains what to expect for each event:


;;  The dispatched function will receive the class-specific decoded value   ;;
;;  in R2.  Below is a list of the values grouped by input class:           ;;
;;                                                                          ;;
;;      KEYPAD:                                                             ;;
;;      ---+-------+---------------------------------------                 ;;
;;          Value   Description                                             ;;
;;          -----   ---------------------------------------                 ;;
;;          0 - 9   Digit 0 through Digit 9                                 ;;
;;          10      Clear                                                   ;;
;;          11      Enter                                                   ;;
;;                                                                          ;;
;;      ACTION BUTTON:                                                      ;;
;;      ---+-------+---------------------------------------                 ;;
;;          Value   Description                                             ;;
;;          -----   ---------------------------------------                 ;;
;;          0       Top action buttons                                      ;;
;;          1       Bottom-Left action button                               ;;
;;          2       Bottom-Right action button                              ;;
;;                                                                          ;;
;;      DISC:                                                               ;;
;;      ---+-------+---------------------------------------                 ;;
;;          Value   Description                                             ;;
;;          -----   ---------------------------------------                 ;;
;;          0       Up                                                      ;;
;;          1       Right                                                   ;;
;;          2       Down                                                    ;;
;;          3       Left                                                    ;;

 

Convenient symbols are defined in the "ctrl.const" file for each of these, so you can use labels instead of memorizing these codes. For instance, if you want to check whether the "Right" direction was pressed, you could do something like this:


IN_DISC         PROC
               BEGIN

               ; Handle disc input
               CMPI  #CTRL_DISC.Right, R2
               BEQ  @@right

               ; Not right..

@@right:     ; handle "right" direction

               RETURN
               ENDP

 

I hope this helps.

 

-dZ.

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

Valter,

 

I just noticed that the CTRL_CHECKKEY decoder treats the disc as only 4-way. This is mainly because that's what I needed for the practice menu screen in Christmas Carol. I should offer another option for the full 16 directions. But I don't think you need that right now, right?

 

Also, as you may imagine, anybody can write their own decoder routines (as long as they follow the In/Out interface used by P-Machinery), and assign them in the state dispatch table. That way, P-Machinery is very extensible.

 

-dZ.

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

Valter,

 

I just noticed that the CTRL_CHECKKEY decoder treats the disc as only 4-way. This is mainly because that's what I needed for the practice menu screen in Christmas Carol. I should offer another option for the full 16 directions. But I don't think you need that right now, right?

 

Also, as you may imagine, anybody can write their own decoder routines (as long as they follow the In/Out interface used by P-Machinery), and assign them in the state dispatch table. That way, P-Machinery is very extensible.

 

-dZ.

 

By the way, there is a difference between the disc event CTRL_CHECKEY and the one in CTRL_GAMEPLAY. The one in CTRL_CHECKKEY just assigns the cardinal points on the disc directly the directions, therefore it has "dead-zones" when you hit the disc diagonally. It also has "de-bouncing" and "de-noising" algorithms, based on those in SCANHAND in the SDK-1600.

 

CTRL_GAMEPLAY has heuristics to allow the player to roll his thumb across the disc and attempts to discern the intended direction. This is the decoder used in Christmas Carol during level game-play. It is also optimized to only detect disc input and work very fast by forgoing de-bouncing.

 

-dZ.

Link to comment
Share on other sites

I try to put some order in my mind :-)

 

1- the state "Title" I do not touch

"Level" is there I have to define handlers

"Game-Over" is where maybe I have to put the final score, for the moment I do not care

So I work only on the "level state

 

2- in st_dispatch.asm I define sublevels of "level"

I do not need retry nor death since were is not a player death, so I would delete that, right?

; STATE: Level

DEFINE_ENUM(GST_LEVEL, 8 )

ADD_ENUM_ELEMENT(Init )

ADD_ENUM_ELEMENT(Wait )

ADD_ENUM_ELEMENT(Play )

ADD_ENUM_ELEMENT(Done )

END_ENUM

 

after I have to delete corresponding handlers map in st_dispatch.asm

 

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

; STATE: Level

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

; State: Controller: Dispatch:

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

@@__level: DECLE ST_LVL_INIT, CTRL_NONE, NO_DISP

DECLE ST_WAIT_ENGINE, CTRL_NONE, NO_DISP

DECLE ST_LVL_PLAY, CTRL_CHECKKEY, MY_INPUT

DECLE ST_LVL_DONE, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

 

now in st_level I erase old procedure TEST_INPUT and put this one:

 

;; ======================================================================== ;;

;; Input Event Dispatch Table. ;;

;; ======================================================================== ;;

MY_INPUT PROC

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

; Event Dispatch Table

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

DECLE IN_KEYPAD ; Key pad

DECLE IN_ACTION ; Action buttons

DECLE IN_DISC ; Disc

ENDP

 

;; ======================================================================== ;;

;; Input Event Handlers. ;;

;; ======================================================================== ;;

IN_KEYPAD PROC

BEGIN

 

; Handle keypad input

 

RETURN

ENDP

 

IN_ACTION PROC

BEGIN

 

; Handle action button input

 

RETURN

ENDP

 

IN_DISC PROC

BEGIN

 

 

; Handle disc input

CMPI #CTRL_DISC.Right, R2

BEQ @@right

 

; Not right..

 

@@right: ; handle "right" direction

CALL PRINT.FLS

DECLE C_YEL, $02DD+1

STRING 'Disc to the right'

BYTE 0

 

 

RETURN

ENDP

 

there is a code for testing the right disc pressure...

 

now the first issue:

If I understood the 3 decoders are

- CTRL_CHECKANY that I do not care during level state

- CTRL_CHECKKEY to define separately each key of the joypad

- CTRL_GAMEPLAY that only define the disc

 

in my case I need to use CTRL_CHECKKEY since I want to map: disc,1,2,3,4,6,7,8,9,clear

 

PROBLEM: if I put CTRL_CHECKKEY, when I push any button the emulator kills itself!!

Edited by vprette
Link to comment
Share on other sites

I try to put some order in my mind :-)

 

1- the state "Title" I do not touch

"Level" is there I have to define handlers

"Game-Over" is where maybe I have to put the final score, for the moment I do not care

So I work only on the "level state

 

2- in st_dispatch.asm I define sublevels of "level"

I do not need retry nor death since were is not a player death, so I would delete that, right?

; STATE: Level

DEFINE_ENUM(GST_LEVEL, 8 )

ADD_ENUM_ELEMENT(Init )

ADD_ENUM_ELEMENT(Wait )

ADD_ENUM_ELEMENT(Play )

ADD_ENUM_ELEMENT(Done )

END_ENUM

 

after I have to delete corresponding handlers map in st_dispatch.asm

 

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

; STATE: Level

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

; State: Controller: Dispatch:

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

@@__level: DECLE ST_LVL_INIT, CTRL_NONE, NO_DISP

DECLE ST_WAIT_ENGINE, CTRL_NONE, NO_DISP

DECLE ST_LVL_PLAY, CTRL_CHECKKEY, MY_INPUT

DECLE ST_LVL_DONE, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

DECLE @@__dead, CTRL_NONE, NO_DISP

 

now in st_level I erase old procedure TEST_INPUT and put this one:

 

;; ======================================================================== ;;

;; Input Event Dispatch Table. ;;

;; ======================================================================== ;;

MY_INPUT PROC

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

; Event Dispatch Table

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

DECLE IN_KEYPAD ; Key pad

DECLE IN_ACTION ; Action buttons

DECLE IN_DISC ; Disc

ENDP

 

;; ======================================================================== ;;

;; Input Event Handlers. ;;

;; ======================================================================== ;;

IN_KEYPAD PROC

BEGIN

 

; Handle keypad input

 

RETURN

ENDP

 

IN_ACTION PROC

BEGIN

 

; Handle action button input

 

RETURN

ENDP

 

IN_DISC PROC

BEGIN

 

 

; Handle disc input

CMPI #CTRL_DISC.Right, R2

BEQ @@right

 

; Not right..

 

@@right: ; handle "right" direction

CALL PRINT.FLS

DECLE C_YEL, $02DD+1

STRING 'Disc to the right'

BYTE 0

 

 

RETURN

ENDP

 

there is a code for testing the right disc pressure...

 

now the first issue:

If I understood the 3 decoders are

- CTRL_CHECKANY that I do not care during level state

- CTRL_CHECKKEY to define separately each key of the joypad

- CTRL_GAMEPLAY that only define the disc

 

in my case I need to use CTRL_CHECKKEY since I want to map: disc,1,2,3,4,6,7,8,9,clear

 

PROBLEM: if I put CTRL_CHECKKEY, when I push any button the emulator kills itself!!

 

Strange, the changes you described seem correct. Does it give an error when assembling, or does it just crash during execution? I'll test over here and see what I find.

 

-dZ.

Link to comment
Share on other sites

 

PROBLEM: if I put CTRL_CHECKKEY, when I push any button the emulator kills itself!!

 

Stranger still, it works when I tried it. There's only one stupid bug in the sample code I gave you: there is no code for pressing a direction other than "right," so it falls through to the same "Disc to the right" message.

 

But other than that, it worked here. Are you sure you made the changes in the right place?

 

-dZ.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...