DZ-Jay

February 8, 2012

I do not care much of the crash so far.... I think is due to unlukely reproducible situation: I let the levels call in cascate without waiting... up to 10 level it start writing slow on screen.. If I put 15 levels (that is written pages) in cascate it crashes like some overflow happened.... but this will not be the case of play state since we are supposed to wait for user input.. still, i wonder what is the reason (cp1600 or emulator?)

I was thinking about what you said and I think it could be a task queue or a stack overflow. I added some debug code to Christmas Carol to trap errors such as these and display state information prior to crashing. I can send you this code and add it to P-Machinery in the future.

Note that by default, P-Mach sets the size of the task queue to 8 (0..7 in TSKQM/MAXTSK) and the stack to 16 (STACK_SIZE). This should be sufficient for most applications, but it can be incremented to 16 (0..15). The stack can be incremented to about 40.

However, keep in mind that incrementing the sizes will take more System RAM, which is precious. You are very early in your development, and you haven't many tasks to deal with nor much nested logic, so if these resources are being exhausted right now it is most likely either a bug, or something that can be easily optimized.

In any case, you can play with the numbers and re-assemble, and see the usage change in the assembler output message.

-dZ.

February 8, 2012

Thanks for all the encouraging words. I am knee deep in scrolling code right now.

No, it is not done yet.

I will let everyone know as soon as it gets into a playable state...

catsfolly.

How 'bout now?

February 8, 2012

I do not care much of the crash so far.... I think is due to unlukely reproducible situation: I let the levels call in cascate without waiting... up to 10 level it start writing slow on screen.. If I put 15 levels (that is written pages) in cascate it crashes like some overflow happened.... but this will not be the case of play state since we are supposed to wait for user input.. still, i wonder what is the reason (cp1600 or emulator?)

Valter, send me or post the code that you use for the paging and I'll try to find out what's wrong.

-dZ.

February 8, 2012

Oh, I just realized that you want to give the player the ability to pause the music during the game. Then it is still easy! Instead of calling TRKPLAY on the "Level" state directly, you set up a variable as a flag and you test it before. If the flag is set, you call TRKPLAY, otherwise you don't. Then when the user presses "Clear" you silence the PSG volume registers and toggle the flag.

Easy! Definitely "Green".

-dZ.

I guess I'll do the same to transition from page to page when in PAGE state:

if the disc is pressed I update a variable, I chekc teh variable and call corresponding page

So if I'm at page 1A the variable is 1, when disc pressed variable is 2, I check and CALL page 1B.... so for each page... since in the game logic I always proceed forward never back...

Remember to define variables using SCRATCH or SYSTEM macros. In this case, 8-bit SCRATCH should be fine, and it will give support up to 256 pages (0..255).

-dZ.

February 8, 2012

I realize we need a bug testing phase... I have some crash after going through 15 pages...

Can you provide some details? What changes did you do?

February 8, 2012

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

- FONT: ok (custom)

- CONTENTS: insert all levels message text descriptions 20%

- MUSIC: translate mod to decles

- PLAY ENGINE1: implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure 5%

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

- PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine

- PLAY ENGINE6: implement music pause

- SCORE: implement scoring

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

Overall: 12%

Great work! I will also help where I can. I have ideas on how to implement the parser, and I plan on writing an ECS Keyboard scanning routine for P-Mach.

You can go ahead and change "PLAY ENGINE6" to green. It's very easy. If you want to stop the music, just call TRKINIT. If you really want to pause so that it later continues where it was, you just silence the PSG and switch to a sub-state that does not update the music tracker. I can give you some very short code that silences the PSG.

-dZ.

Oh, I just realized that you want to give the player the ability to pause the music during the game. Then it is still easy! Instead of calling TRKPLAY on the "Level" state directly, you set up a variable as a flag and you test it before. If the flag is set, you call TRKPLAY, otherwise you don't. Then when the user presses "Clear" you silence the PSG volume registers and toggle the flag.

Easy! Definitely "Green".

-dZ.

February 8, 2012

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

- FONT: ok (custom)

- CONTENTS: insert all levels message text descriptions 20%

- MUSIC: translate mod to decles

- PLAY ENGINE1: implement PAGE state and transition from PAGE to PLAY by reconnaising disc pressure 5%

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

- PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine

- PLAY ENGINE6: implement music pause

- SCORE: implement scoring

- BOX: 80%

- OVERLAYS:

- MANUAL: 5%

Overall: 12%

Great work! I will also help where I can. I have ideas on how to implement the parser, and I plan on writing an ECS Keyboard scanning routine for P-Mach.

You can go ahead and change "PLAY ENGINE6" to green. It's very easy. If you want to stop the music, just call TRKINIT. If you really want to pause so that it later continues where it was, you just silence the PSG and switch to a sub-state that does not update the music tracker. I can give you some very short code that silences the PSG.

-dZ.

February 8, 2012

As promised, Big Fonts! I also have numbers if you need them... Actually, I have a full "printable character" ASCII set, including lower-cased letters.

-dZ.

fonts.asm

February 8, 2012

So, catsfollly... Is it done yet? How 'bout now? And now?

...

Now?

February 8, 2012

New update

"Wait" state works, but...

I still need a new sub-state!

I explain: from a user point of view I can be in 2 states:

- when intv expect my input (I handle this with "Play" sub-state)

- when intv show one of several text pages of a long description of 2-3 pages: in this case the ONLY input accepted is the disc pressure

to handle this I need a sub-state PAGE and I can still use the ST_LVL_PLAY procedure but using as controller the CTRL_GAMEPLAY that only accept disc input, right?

So I would change in "state.const"

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

ADD_ENUM_ELEMENT(Page )

END_ENUM

and change 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 ;handle keeypad commands

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 ST_LVL_PLAY, CTRL_GAMEPLAY, TEST_INPUT ;handle disc pressure only

DECLE @@__dead, CTRL_NONE, NO_DISP

??

You are right! That's exactly how P-Machinery should be used in such circumstances. Then you have your normal "Play" sub-state (which you can rename if you wish) where full input will be expected (eventually from the ECS keyboard, right?). Then you have a "Page" sub-state where only the disc is accepted so the user can read more than one page of text.

You can then use the "Wait" state for delays and transitions between these states.

Your assessment on the changes are correct. Although you can remove "Retry" and "Death" if you're not planning on using them. Just remember that the names defined in the "state.const" file are used for the SET_GAME_STATE macro and such, but that the actual sub-states are defined in the dispatch table in "st_dispatch.asm" file. Also that each sub-state defined in the table must correspond to a state handler routine.

They should respectively match in order, and there must be 8 records defined. Any unused sub-states must be mapped to the "@@__dead" state, which is ignored.

Those are the requirements for defining states in P-Machinery. It's that simple.

-dZ.

February 7, 2012

You don't have to create a state for the intro unless you have considerable logic for that state that should be treated separated from the "game/level" state.

If all you need is a short delay or a transition, then you can consider that delay or transition a sub-state of the "Level" state. However, it's up to you. P-Machinery will support any number of states.

-dZ.

February 7, 2012

To clarify: as you see in the actual rom: during the 3 seconds on teh INTRO message "welcome stranger.." the game accept keypad inputs... I want to avoid this.

Wait, I don't understand. Are you saying that you want to delay for three seconds without accepting input? All you need to do is to switch to state "Level-Wait" prior to setting calling STARTTASK with the 3 second delay trigger. In the routine that is called when the timer is up, you switch the state back to "Level-Play" to continue normally.

This is why all levels contain a "Wait" sub-state, so that you can have delays and other transitions that do minimal background stuff and ignore input if you want to.

In Christmas Carol, I have two wait sub-states, "WaitKey" and "Wait". I use "Wait" for delays that must not accept input (like during the "Get Ready!" sequence); I use "WaitKey" for delays that may accept any key (like during the introduction sequence animation, so that the user can skip it).

If your remember the dispatch table, the "Level-Wait" entry has no input decoder and just calls the "Wait Engine".

So, you can do something like this:

       ; Whenever you want the delay...

       SET_GAME_STATE(LEVEL, Wait, cNormal)
       ; ...
       STARTTASK
       DECLE Task.Delay
       DECLE MY_CONTINUE
       DECLE (60 * 3 * 2) - 1
       DECLE 0

And in the continue routine:


MY_CONTINUE  PROC
       BEGIN

       ; Delay is up! continue as normal
       SET_GAME_STATE(LEVEL, Play, cNormal)

       RETURN
       ENDP

Does this make sense?

-dZ.

February 7, 2012

Another useful note: The CTRL_CHECKKEY decoder only triggers events on "key-down." That is, when keys, buttons or the disc are pressed; not when they are released.

Again, this was all based on the code I made for Christmas Carol and the requirements were simpler. I should generalize it better.

Eventually I'll update it to do both "key-down" and "key-up" events.

-dZ.

February 7, 2012

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.

February 7, 2012

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.

February 7, 2012

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.

February 7, 2012

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.

February 7, 2012

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.

February 7, 2012

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

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.

February 7, 2012

What are the XMP files in that *.zip? Can you convert them to *.bmp, *.gif or *.png format?

I think it's the native format for GIMP.

February 7, 2012

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.

February 6, 2012

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

February 6, 2012

Catsfolly,

By the way, that explanation was intended for Valter. You probably already know about VBLANK and ISRs and enabling active display.

February 6, 2012

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.

February 6, 2012

You referring to catsfolly post, not mine :-)

mine show 37 tiles used..

Oops! Sorry.

I'll check it when I get home from work tonight.

-dZ.

Sign In

Profiles

Member Map

Forums

Blogs

Gallery

Calendar

Store

Posts posted by DZ-Jay