Introducing P-Machinery 1.0 (beta)

[vprette]

I get error "The program needs Include dependencies: you must save it in IW folder or a sub folder"

 

I'm guessing this error is coming from "Intelliware" somewhere. "IW folder" sounds like something to do with the Intelliware environment.

 

On my machine (a Macbook), I

1. downloaded pmach

2. found all the missing include files (except for pause.asm).

3. Then I commented out the include for pause.asm.

4. After that I was able to assemble and run the pmach-test program.

 

ok so I need to setup a compile ambient...

 

I write from a Mac in fact... so I would be very interested to do the same environment of you... do you use jzintv-1.0-beta-macosx.zip ?

[catsfolly]

I get error "The program needs Include dependencies: you must save it in IW folder or a sub folder"

 

I'm guessing this error is coming from "Intelliware" somewhere. "IW folder" sounds like something to do with the Intelliware environment.

 

On my machine (a Macbook), I

1. downloaded pmach

2. found all the missing include files (except for pause.asm).

3. Then I commented out the include for pause.asm.

4. After that I was able to assemble and run the pmach-test program.

 

ok so I need to setup a compile ambient...

 

I write from a Mac in fact... so I would be very interested to do the same environment of you... do you use jzintv-1.0-beta-macosx.zip ?

 

I think the latest version is:

 

http://spatula-city.org/%7Eim14u2c/intv/dl/jzintv-20101224-macosx.zip

 

dZ-Jay's code probably needs the latest version of jzintv to compile and run.

[+DZ-Jay]

Guys,

I indeed use the bleeding edge as1600 assembler that comes with Joe's development kit. Though I'm not sure if the version will matter so much as the SDK libraries.

 

The "pause.asm" is a recent addition to the TASKQ library. Joe and I worked on it as a means to pause/unpause tasks in the task queue during game play. He intended to add it to the next version of the SDK-1600, but he may not have done it so far.

 

In any case, you can comment the include from the P-Mach code. The demo does not use it, though it is good to have as part of your game tool kit.

 

I'll post here a copy of "pause.asm" when I return, but just ignore it for now.

 

dZ.

Edited January 29, 2012 by DZ-Jay

[vprette]

Guys,

I indeed use the bleeding edge as1600 assembler that comes with Joe's development kit. Though I'm not sure if the version will matter so much as the SDK libraries.

 

The "pause.asm" is a recent addition to the TASKQ library. Joe and I worked on it as a means to pause/unpause tasks in the task queue during game play. He intended to add it to the next version of the SDK-1600, but he may not have done it so far.

 

In any case, you can comment the include from the P-Mach code. The demo does not use it, though it is good to have as part of your game tool kit.

 

I'll post here a copy of "pause.asm" when I return, but just ignore it for now.

 

dZ.

 

I get error messages for const/ctrl.const

invalid opcode

 

referring to DEFINE_ENUM(CTRL_KEYPAD, 12)

 

this command is described in the macro/enum.mac, so whay is not working?

[+DZ-Jay]

I get error messages for const/ctrl.const

invalid opcode

 

referring to DEFINE_ENUM(CTRL_KEYPAD, 12)

 

this command is described in the macro/enum.mac, so whay is not working?

 

That error is because it is treating a macro as an instruction, and it's failing.

 

Can you confirm that enum.mac is included properly? This is very strange. There was someone else in the IntvProg that was able to assemble and run the demo, so I assumed it was fine.

 

Can you please post the resulting listing file?

[vprette]

I get error messages for const/ctrl.const

invalid opcode

 

referring to DEFINE_ENUM(CTRL_KEYPAD, 12)

 

this command is described in the macro/enum.mac, so whay is not working?

 

That error is because it is treating a macro as an instruction, and it's failing.

 

Can you confirm that enum.mac is included properly? This is very strange. There was someone else in the IntvProg that was able to assemble and run the demo, so I assumed it was fine.

 

Can you please post the resulting listing file?

 

for whatever reason the error disappear (I did nothing) but now I have error calling SET_GAME_STATE, see the listing file I send to you (too long to be posted here

thanks

[vprette]

Ok

the code is running now.. let's move to something a bit more serious :-)

 

I want to use a custom title screen

the code I have to modify is all inside state/st_title.asm ?

 

how do I change the background green color?

Edited January 30, 2012 by vprette

[+DZ-Jay]

I get error messages for const/ctrl.const

invalid opcode

 

referring to DEFINE_ENUM(CTRL_KEYPAD, 12)

 

this command is described in the macro/enum.mac, so whay is not working?

 

That error is because it is treating a macro as an instruction, and it's failing.

 

Can you confirm that enum.mac is included properly? This is very strange. There was someone else in the IntvProg that was able to assemble and run the demo, so I assumed it was fine.

 

Can you please post the resulting listing file?

 

for whatever reason the error disappear (I did nothing) but now I have error calling SET_GAME_STATE, see the listing file I send to you (too long to be posted here

thanks

 

That's another macro.

[+DZ-Jay]

Ok

the code is running now.. let's move to something a bit more serious :-)

 

I want to use a custom title screen

the code I have to modify is all inside state/st_title.asm ?

 

how do I change the background green color?

 

Ah, great!!

 

In st_title.asm you'll see comments where it says things like "here you draw custom title screen."

 

I sorry Valter, I am not at home right now and can't see the code, but when I return I can help you better. I expect to return by Thursday.

 

To change the background colour, you need to iterate through the BACKTAB (background table) and change the colour of each card (or tile).

 

For information on what is the BACKTAB and how it works, I suggest you check out the IntelliWiki.

 

Basically, the screen is composed of 20 columns by 12 rows of "cards," which are just 8 by 8 pixel character tiles.

 

Each card can have a background and a foreground colour, and display a tile from either GROM or GRAM. The GROM contains the built in fonts and other graphic elements. GRAM offers a 64 tile buffer for custom cards.

 

dZ.

[+DZ-Jay]

Valter,

 

I forgot to say that there is a routine in the SDK-1600 called CLRSCR that clears the screen. It does this by setting all BACKTAB cards to "blank" with a specified background colour.

 

You can call that routine from the appropriate point in the "st_title.asm" module. It should have a name like TTL_INIT, or something like that (I'm sorry but I can't recall right now).

 

That should change the background colour at the same time as it clears the screen and leaves it ready for you to draw your custom title screen.

 

dZ.

[catsfolly]

The Intellivision backtab operates in 2 modes.

1. "Foreground/Background" Mode

2. "Color Stack" mode.

 

In Foreground/Background mode, the Foreground (on bits) and Background (off bits) colors can be selected for each "card" (character) of backtab.

Unfortunately, only the first 64 characters of GROM can be used in Foreground/Background mode. This means only the upper case letters and numbers.

 

In Color Stack mode, which is the default for the title screen, the Foreground color can be selected for each "card" of backtab. The background color comes from a list of 4 colors known as the "color stack". The cards will use the first color in this list as the background color. If a backtab card has the "advance color stack" bit set, the background color will advance to the next color in the list. If the current color is at the end of the list, the advance color stack bit will send it back to the top of the list.

 

The colors are set in the interrupt service routine. For example, this code will set the color stack to red,white,blue, and black (and set the border color to black).

 

 

 

		MVO	 R0,	 STIC.viden  ; Enable display
		MVI	 STIC.mode, R0	   ; ...in color-stack mode
		MVII	#C_RED, R0		  ;
		MVO	 R0,	 STIC.cs0	; set first color to RED
		MVII	#C_WHT, R0		  ;
		MVO	 R0,	 STIC.cs1	; set second color to WHITE
		MVII	#C_BLU, R0		  ;
		MVO	 R0,	 STIC.cs2	; set third color to BLUE
		MVII	#C_BLK, R0		  ;
		MVO	 R0,	 STIC.cs3	; set fourth color to BLACK
		MVO	 R0,	 STIC.bord   ; set border color to BLACK
 

[vprette]

I managed to change title screen text/colors :-)

 

thanks

 

Now I have to study the game state, I'd like to move from title screen to a graphic page and AFTER to the loop state waiting for control inputs... so an additional state..

 

the problem here is that the game has several location, so I would have to produce 10+ graphics.... it woul take me ages :-)

 

having just one initial grapchi page seems nosense, so I may abandon this idea and state with the only text plan

Edited January 30, 2012 by vprette

[vprette]

If I understand, after Title I move to ST_LVL_INIT

from this to level to level?

In fact in my case I need a new level for each text page, when I press a direction I should go to next level(page).... this code implement only one level and tape the text according to the direction..... I should modify so that taping a direction I call next level instead of printing the direction... it's lot different... and messy for me :-)

Edited January 30, 2012 by vprette

[+DZ-Jay]

If I understand, after Title I move to ST_LVL_INIT

from this to level to level?

In fact in my case I need a new level for each text page, when I press a direction I should go to next level(page).... this code implement only one level and tape the text according to the direction..... I should modify so that taping a direction I call next level instead of printing the direction... it's lot different... and messy for me :-)

 

Valter,

 

Printing the direction is done as a demonstration of using the controller input decoder.

 

The input decoder accepts a table that contains "callback" routines for each controller event. For instance, when a keypad key is pressed the routine at the entry in the table for the keypad will be called automatically.

 

The same happens for disc input. I think the value in R0 (I'm not sure which register right now, sorry) corresponds to either the key or disc direction pressed. The code should specify I the comments.

 

P-machinery does not have a concept of "levels" per se, so it is open to many types of games. The term "level" may be used in the code, but it is just a vestige of working on Pac-Man. It actually represents the "game-play" state, as opposed to the title screen or game-over states.

 

For most part, you'll only need three states: title screen, game-play, and game-over.

 

Once the game enters "game-play" state, the P-Mach state machine should remain there until the player dies. You could add more states, but it is not really necessary.

 

An example of an extra state is Christmas Carol's intermission screens between levels. It requires special game logic that does not really qualify as "game-play" since it is autonomous.

 

Keep in mind that each "main" state can be sub-divided in up to 8 sub-states. This allows you to break up, say, the title screen state into something like init, draw, and wait for input.

 

As an example, consider that the "game-play" state in Christmas Carol is broken down into:

- init level

- play level

- replay level (after player death)

- end level (after completion)

- end game (after last death)

- wait for input.

 

In the case of a text adventure, I would imagine that you could treat the many rooms like I treat the levels on Carol. In that case, the "game-play" state could be broken up into:

 

- init room

- wait for input

- process command

- exit room

- player death

 

You wouldn't need a new state per room, you just keep that state of your world in variables and update them as the player moves from room to room.

 

That's just an example, of course.

 

Once I return later this week, I can offer more concrete examples and even code samples.

 

dZ.

Edited January 30, 2012 by DZ-Jay

[vprette]

Additional confusion :-)

 

I'm just after the title screen

I'm in the st_level section..

inside ST_LVL_INIT, if I write some text onscreen like

CALL PRINT.FLS

DECLE C_GRN, $0200

STRING 'WELCOME STRANGER'

BYTE 0

it works and proceed to SET_GAME_STATE

 

If I try do to the same by calling a PROC, like

CALL LEVEL_INTRO

where the proc is the following:

 

LEVEL_INTRO PROC

CALL PRINT.FLS

DECLE C_GRN, $0200

STRING 'WELCOME STRANGER'

BYTE 0

ENDP

 

the proc is called but it does not come back to ST_LVL_INIT and stop there.... I need to add some return command, but IRET or TRET make the game freeze with black screen.... what it's wrong?

Edited February 1, 2012 by vprette

[GroovyBee]

Something like this should work :-

 

LEVEL_INTRO	 PROC
PSHR R5
CALL	PRINT.FLS
DECLE   C_GRN,  $0200
STRING  'WELCOME STRANGER'
BYTE	0
PULR PC
ENDP

 

You need to save the return address (in R5) on the stack at the start of your procedure "PSHR R5" because it gets trashed when you are CALLing PRINT.FLS. When you come to the end of the procedure you need to take the return address off the stack and put it in the program counter "PULR PC".

[+DZ-Jay]

Additional confusion :-)

 

I'm just after the title screen

I'm in the st_level section..

inside ST_LVL_INIT, if I write some text onscreen like

CALL PRINT.FLS

DECLE C_GRN, $0200

STRING 'WELCOME STRANGER'

BYTE 0

it works and proceed to SET_GAME_STATE

 

If I try do to the same by calling a PROC, like

CALL LEVEL_INTRO

where the proc is the following:

 

LEVEL_INTRO PROC

CALL PRINT.FLS

DECLE C_GRN, $0200

STRING 'WELCOME STRANGER'

BYTE 0

ENDP

 

the proc is called but it does not come back to ST_LVL_INIT and stop there.... I need to add some return command, but IRET or TRET make the game freeze with black screen.... what it's wrong?

 

Valter,

 

IRET and TRET are macros to encapsulate terminating a procedure.

 

IRET returns from an interrupt routine, or ISR. It gives control back to the EXEC at the point that the ISR was called. If you notice, it is at the end of all the state handling routines like ttl_init.

 

TRET returns from a task queued with TASKQ. It gives control back to the task manager.

 

These return routines are abrupt shortcuts. That is, they have return addresses hard-wired to labels, and consequently alleviate the need to keep track of the return address or to push one into the stack.

 

For regular purpose code, Groovy's example should work. The CALL operation puts the return address into R5, so you cannot touch that register during your procedure. If you need to use it, you'll have to save the address somewhere temporarily. Typically this is done by pushing it into the stack with PSHR. You then pop it to return.

 

The operations BEGIN and RETURN do this for you. They are the same as saying,

 

PSHR R5 ; save return address

...

PULR R7 ; pop the return address into the instruction pointer

 

By the way, if you look at the macro definitions, they are well commented. They all include a boilerplate header that explains their function and usage.

 

dZ.

Edited February 1, 2012 by DZ-Jay

[vprette]

thanks a lot!

I'm using begin and return it seems working... so I move from a page to the next now

I want to introduce a 3 seconds pause in the first page.. is this done by the timer.asm task somehow?

[+DZ-Jay]

thanks a lot!

I'm using begin and return it seems working... so I move from a page to the next now

I want to introduce a 3 seconds pause in the first page.. is this done by the timer.asm task somehow?

 

Yes. You use the STARTTASK routine. It starts a timer for the specified time. When the timer expires, a function you specify will be added to the task queue. It will then be executed at the end of the next game loop cycle.

 

Note that the timers are all counted in frames per second, which are 60 Hz on NTSC and 50 Hz on PAL. To pause for three seconds, you set the timer to 60 x 3, or 180 frames. The ISR interrupt is the heartbeat of the game engine.

 

STARTTASK is part of Joe Zbiciak's SDK-1600. For more information on how to use it, you can read the comments on the code. P-Mach offers some macros to simplify its use, but I can't recall them right now, sorry.

 

Just a note on its use: STARTTASK is intended to deal with recurring and one-off timers in one single interface. One-shot timers are disabled after they expire, while recurring ones are re-scheduled automatically every time they fire. The way it tells the difference is that recurring timers have an even number of frames, and one-off timers have an odd number. Moreover, the scheduler decrements the counter by 2, so you must multiply your timer times by 2. For instance, in your example you need 180 frames, so you set up your timer for (60 x 3 x 2) -1. The minus one is to turn it into an odd number, for a one-shot.

 

And one more note. You'll notice that STARTTASK accepts two timer counts. The first one is the initial delay, the second is the re-schedule time. For one-shots, you ignore the second one and just use the first one. For recurring, you set them both. The initial delay allows you to set the recurring timer to start after a short delay instead of immediately. It will then reoccur on the period of the second timer.

 

dZ

Edited February 1, 2012 by DZ-Jay

[vprette]

is this done in simple way by the procedure WAIT from timer.asm?

I set the WTIMER and call WAIT but everything stop, like the timer never expire...

[vprette]

About the audio tracker, I try the following

 

insert the initialization and call to the tracker in my intro proc

 

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

;; LEVEL_INTRO: first message and start music ;;

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

LEVEL_INTRO PROC

 

BEGIN

CALL CLRSCR ; Clear the screen

CALL PRINT.FLS

DECLE C_GRN, $0200

STRING ' WELCOME STRANGER..'

BYTE 0

 

CALL TRKINIT ; initialize tracker

CALL TRKSNGINIT ; initialize song

DECLE SONG00

@@spin CALL WAITVBL ; wait for VBlank

CALL TRKPLAY ; tick the player

B @@spin ; spin forever

 

RETURN

ENDP

 

 

I have no error messages from the compiler, but the result is no music and black screen instead of WELCOME STRANGER..

IF I indent the symbol to avoid the loop like:

;@@spin CALL WAITVBL ; wait for VBlank

CALL TRKPLAY ; tick the player

;B @@spin ; spin forever

 

the proc is working again and I see the WELCOME STRANGER.. message but I do not hear any music...

Edited February 1, 2012 by vprette

[+DZ-Jay]

Valter,

Your problem is that you broke out of the P-Mach game loop and made your own infinite loop.

 

Also, you are calling the tracker update routine on "realtime" when you should be calling it only once per frame to keep time.

 

P-Mach makes this quite easy. In fact, I can give you the code I use in Christmas Carol to update the music tracker. I removed it from P-Mach but I guess it could be kept in there.

 

I'm at the airport right now, on my way home. I'll be able to offer code samples and more concrete help by tomorrow morning.

 

dZ.

Edited February 1, 2012 by DZ-Jay

[+DZ-Jay]

By the way, you should not make any infinite loops when using P-Mach. Let the game engine framework do that for you.

[+DZ-Jay]

is this done in simple way by the procedure WAIT from timer.asm?

I set the WTIMER and call WAIT but everything stop, like the timer never expire...

 

No. WAIT is a routine Joe used in 4-Tris to pause for a specified time waitin for an event. I don't recall right now it's use, but its application was rather narrow. You are better off using STARTTASK.

 

dZ.

[+DZ-Jay]

Hey, guys! I'm back! Attached is a copy of the missing "pause.asm" file. You should put it along with "taskq.asm," "wait.asm," and "timer.asm," for it is part of the TASKQ library.

 

-dZ.

 

pause.asm