Colossal Cave Adventure diary

[vprette]

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

Edited February 10, 2012 by vprette

[+DZ-Jay]

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.

[+DZ-Jay]

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.

[+DZ-Jay]

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.

Edited February 10, 2012 by DZ-Jay

[+DZ-Jay]

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.

[+DZ-Jay]

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  MVI@ 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  MVI@ 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

Edited February 10, 2012 by DZ-Jay

[+DZ-Jay]

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  MVI@ 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  MVI@ 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.

[intvnut]

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.

 

dZ,

 

The EXEC will check for "viable ROM" at $4800 and $7000 before doing most of its initialization, and if it see ROM at either location, it will jump to it.

 

My cart.mac will detect ROM segment overflows, but only if you put "ROMEND" at the end of your program. If you don't put ROMEND at the end of your program, you could successfully assemble your program, but you may have overflowed the last segment you assembled into. That's what I think happened here: The game edged out of $5000 - $6FFF into $7000, and the pre-title-screen code sees "viable ROM" at $7000 and jumps into what's actually data.

 

 

In other news, I wrote a quick and dirty Perl script to compress the Colossal Cave Phrase Data from the OS/8 version of Colossal Cave. The entire phrase database fits in about 7K words, using the extremely simplistic scheme I mentioned this morning. I'm attaching my scripts and their output.

 

--Joe

advent.zip

[intvnut]

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.

 

You can map code at $7xxx if you are careful.

 

The EXEC checks $7000 and $4800 for "viable ROM" (which means "upper 6 bits are zero") during early bootup. If it detects viable ROM there, it'll branch there immediately. So, you can wrest control of the game boot process by putting ROM at $7000 or $4800.

 

Another strategy is to make sure a value greater than $03FF ends up at $7000, also to foil the check. That usually means you can't have code that spills directly from $6FFF to $7000, but it does mean you can map ROM at $7001 - $7FFF.

 

Now, another challenge is the fact that the ECS maps ROM at $7000. One way to handle that is to use a bankswitched ROM at $7xxx, and switch out the ECS ROM and switch in your own ROM. You don't need dynamic ROM switching during your game to make that work. In fact, in the 42K memory map, the cart.mac code tries to switch out the ECS ROMs to make room for your own game.

 

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

[GroovyBee]

Sounds like I should move over to using the cart.mac myself instead of doing it all the "hard" way.

[catsfolly]

Sounds like I should move over to using the cart.mac myself instead of doing it all the "hard" way.

 

I'm not using cart.mac for "Paddle Party" because I am essentially doing 4 separate games, and I have different ram "assignments" for each game.

 

For example, "Doubleball" has two ball structures, "Air Hockey" has temp vectors for collision calculators, while "Tennis in Space" has variables for scrolling. So I have different "org" statements and ram allocation for each game. I don't think cart.mac supports this approach...

[+DZ-Jay]

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

[+DZ-Jay]

Sounds like I should move over to using the cart.mac myself instead of doing it all the "hard" way.

 

I'm not using cart.mac for "Paddle Party" because I am essentially doing 4 separate games, and I have different ram "assignments" for each game.

 

For example, "Doubleball" has two ball structures, "Air Hockey" has temp vectors for collision calculators, while "Tennis in Space" has variables for scrolling. So I have different "org" statements and ram allocation for each game. I don't think cart.mac supports this approach...

 

Cart.mac doesn't really support that "out-of-the-box," but I do something similar in Christmas Carol. I added some macros that re-assign RAM or "truncate" RAM back to a particular address so that I can assign different blocks for the various machine states. Then cart.mac can continue allocating and validating RAM usage.

 

For example, I have a set of variables that are global to the game world, but after that, there is a block of 8-bit RAM used for game-play and level parameters, and another overlapping set used for the introduction sequences. For instance, I define the global variables normally:

 

; ======================================================
; GAME WORLD STATE
; ======================================================

; --------------------------------------
; Player State Information
; --------------------------------------
PLAYER_INFO     STRUCT  0
@@ScoreRevs     SCRATCH 1
@@Score         SCRATCH 2
@@Lives         SCRATCH 1

@@DigitCount    EQU     4
@@Digits        SCRATCH @@DigitCount
               ENDS

; --------------------------------------
; Game Engine Information
; --------------------------------------
GAME_INFO       STRUCT  0
@@State         SCRATCH 1
@@CtrlScanner   SCRATCH 2
@@CtrlDisp      SCRATCH 2
@@PsgState      SCRATCH 1
               ENDS

; --------------------------------------
; Game World Information
; --------------------------------------
WORLD_INFO      STRUCT  0
@@Level         SCRATCH 1
@@Stage         SCRATCH 1
@@Difficulty    SCRATCH 1
@@Flags         SCRATCH 1

@@NextLife      SCRATCH 2
@@ExtraCount    SCRATCH 1
               ENDS

 

Then "mark" the current RAM cursors before allocating for level parameters:

; ======================================================
; LEVEL PLAY STATE
; ======================================================
LVL_SCR_START   EQU     .SCRMEM
LVL_SYS_START   EQU     .SYSMEM

; --------------------------------------
; Level State Information
; --------------------------------------
LEVEL_INFO      STRUCT  0
@@CandyCnt      SCRATCH 1
@@SnoflkCnt     SCRATCH 1
@@Deaths        SCRATCH 1
@@Perfect       SCRATCH 1

@@PresentCnt    SCRATCH 1
@@PresentVec    SCRATCH 1

@@BonusMult     SCRATCH 1

@@SpeedDelay    SCRATCH 1
@@PlayerHits    SCRATCH 1
               ENDS

; --------------------------------------
; Level Map Information
; --------------------------------------
LEVEL_MAP       STRUCT  0
               ; Level maze data base addresses
@@vmap          SYSTEM  1
@@present       SYSTEM  1
@@btab          SCRATCH 2
@@snoflk        SCRATCH 2

               ; Effective maze dimensions
@@eff_min_y     SCRATCH 1                               ; NOTE: These are set in reverse order so that
@@eff_min_x     SCRATCH 1                               ;       we can load them from 16-bit ROM without
@@eff_max_y     SCRATCH 1                               ;       having to swap them first.
@@eff_max_x     SCRATCH 1                               ;

               ; Sprite Positions
@@elf_pos       SCRATCH 2
@@snowman_pos   SCRATCH 2
@@ghost_pos     SCRATCH 2

               ; Sprite Orientation
@@elf_dir       SCRATCH 1
@@snowman_dir   SCRATCH 1
@@ghost_dir     SCRATCH 1

               ; Bonus Item Counts
@@candy_cnt     SCRATCH 1
@@snoflk_cnt    SCRATCH 1
@@bonus_cnt     SCRATCH 1
               ENDS

 

 

 

Then I "truncate" RAM by resetting the cart.mac cursors back to my markers:

; ======================================================
; PRACTICE MODE STATE
; ======================================================
LVL_SCR_END     EQU     .SCRMEM                         ; \
LVL_SYS_END     EQU     .SYSMEM                         ;  |_ "Practice Mode" variables overlap the
RESET_SCRATCH_RAM(LVL_SCR_START)                        ;  |    "Level Play" variables
RESET_SYSTEM_RAM (LVL_SYS_START)                        ; /

; --------------------------------------
; Practice Mode State Information
; --------------------------------------
SCROLL_INFO     STRUCT  0
               ; Menu screen data base addresses
@@btab          SYSTEM  1

@@ScrollFunc    SYSTEM  1
@@ShiftFunc     SYSTEM  1
@@ScrollRate    SYSTEM  1

@@Padding       EQU     2
@@StartRate     EQU     PIX_RATE(35)                    ; Start at 20 pixels/second
@@AccelRate     EQU     PIX_RATE(25)                    ; Accelerate by (20 pixels/second)^second
@@MaxRate       EQU     PIX_RATE(400)
@@Delay         SCRATCH 1
@@State         SCRATCH 1
@@Flags         SCRATCH 1
@@Column        SCRATCH 1
@@PadCol        SCRATCH 1
@@RateFrac      SCRATCH 1
               ENDS

 

Both sets overlap, but it doesn't matter as long as they are used at different states, which my game does.

 

I love "cart.mac," mostly because it solved a lot of problems for me before I even had to get acquainted with the complexities of managing ROM segments. When that became a necessity, it was rather magical to know that cart.mac supported that too!

 

-dZ.

[vprette]

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.

 

dZ,

 

The EXEC will check for "viable ROM" at $4800 and $7000 before doing most of its initialization, and if it see ROM at either location, it will jump to it.

 

My cart.mac will detect ROM segment overflows, but only if you put "ROMEND" at the end of your program. If you don't put ROMEND at the end of your program, you could successfully assemble your program, but you may have overflowed the last segment you assembled into. That's what I think happened here: The game edged out of $5000 - $6FFF into $7000, and the pre-title-screen code sees "viable ROM" at $7000 and jumps into what's actually data.

 

 

In other news, I wrote a quick and dirty Perl script to compress the Colossal Cave Phrase Data from the OS/8 version of Colossal Cave. The entire phrase database fits in about 7K words, using the extremely simplistic scheme I mentioned this morning. I'm attaching my scripts and their output.

 

--Joe

 

the message from jzintv when try to run the rom is: Halt! PC=7007 Instr= 82 MS= 62

[intvnut]

the message from jzintv when try to run the rom is: Halt! PC=7007 Instr= 82 MS= 62

 

Can you look at the listing file or maybe the .cfg file and see if your ROM edged into the $7xxx space? I suspect it did.

 

dZ tells me that there's an explicit "ROMEND" at the end of P-Mach, but if any of your code appears after ROMEND, then cart.mac can't catch ROM overflow.

[vprette]

the message from jzintv when try to run the rom is: Halt! PC=7007 Instr= 82 MS= 62

 

Can you look at the listing file or maybe the .cfg file and see if your ROM edged into the $7xxx space? I suspect it did.

 

dZ tells me that there's an explicit "ROMEND" at the end of P-Mach, but if any of your code appears after ROMEND, then cart.mac can't catch ROM overflow.

 

I had Includes after ROMEND

I moved before like

 

 

;INSERITI INCLUDE PER IL TRACKER

INCLUDE "tracker.asm"

INCLUDE "macro/tracker.mac"

INCLUDE "demosong.asm"

;INSERITO INCLUDE PER IL FONT

INCLUDE "memunpk.asm"

 

ROMEND

INCLUDE "macro/stats.mac"

 

now I get error message segment overflow in segment 0

at least we know it is an overflow: what can I do now?

Edited February 11, 2012 by vprette

[intvnut]

That would do it. Segment overflow means you need to use ROMSEG to move some of your game out of the $5000 - $6FFF segment of address space into one of the other segments. I saw in another post that you're currently using the 16K address map. Your other two ROM segments are "ROMSEG 1" and "ROMSEG 2", which correspond to $Dxxx and $Fxxx.

 

If you think you're going to end up with a fairly large game (which, depending on what happens with the text, or if you add any graphics, you may very well), you might want to switch to the 42K map. You'll still need a ROMSEG to move some of your stuff over to a different segment, but ROMSEG 2 is huge all by itself (about 16K, $C022 - $FFFF), and ROMSEG 1 is about 12K.

 

I didn't create the ROMSEGs to make life difficult. The Intellivision has lots of fun potholes in its address map. Whee. "cart.mac" does what it can to paper over them, but it can't hide them completely.

Edited February 11, 2012 by intvnut

[+DZ-Jay]

the message from jzintv when try to run the rom is: Halt! PC=7007 Instr= 82 MS= 62

 

Can you look at the listing file or maybe the .cfg file and see if your ROM edged into the $7xxx space? I suspect it did.

 

dZ tells me that there's an explicit "ROMEND" at the end of P-Mach, but if any of your code appears after ROMEND, then cart.mac can't catch ROM overflow.

 

I had Includes after ROMEND

I moved before like

 

 

;INSERITI INCLUDE PER IL TRACKER

INCLUDE "tracker.asm"

INCLUDE "macro/tracker.mac"

INCLUDE "demosong.asm"

;INSERITO INCLUDE PER IL FONT

INCLUDE "memunpk.asm"

 

ROMEND

INCLUDE "macro/stats.mac"

 

now I get error message segment overflow in segment 0

at least we know it is an overflow: what can I do now?

 

Great! That's what we were expecting. Now we now how to fix it: just use more than one segment. "Cart.mac" makes this brain-dead simple with the macro "ROMSEG x":

 

Notice at the top of P-Machinery where it says "ROMSEG 0". Everything included after that will be assembled into segment #0. You need to find an appropriate place and switch segments like this:

 

      INCLUDE "blah1.asm"

      INCLUDE "blah2.asm"

      INCLUDE "blah3.asm"

      ROMSEG 1

      INCLUDE "blah4.asm"

      INCLUDE "blah5.asm"

 

You continue using different segments as they fill up.

 

-dZ.

[+DZ-Jay]

That would do it. Segment overflow means you need to use ROMSEG to move some of your game out of the $5000 - $6FFF segment of address space into one of the other segments. I saw in another post that you're currently using the 16K address map. Your other two ROM segments are "ROMSEG 1" and "ROMSEG 2", which correspond to $Dxxx and $Fxxx.

 

If you think you're going to end up with a fairly large game (which, depending on what happens with the text, or if you add any graphics, you may very well), you might want to switch to the 42K map. You'll still need a ROMSEG to move some of your stuff over to a different segment, but ROMSEG 2 is huge all by itself (about 16K, $C022 - $FFFF), and ROMSEG 1 is about 12K.

 

I didn't create the ROMSEGs to make life difficult. The Intellivision has lots of fun potholes in its address map. Whee. "cart.mac" does what it can to paper over them, but it can't hide them completely.

 

I think it's a safe bet by now that you are going to need the 42K map due to the size of the text data. This is also very simple with "cart.mac". In the main source file of your P-Machinery game, find the following line:

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

 

and change it to,

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

 

That's it, instant 42K memory map. The available segments and your usage should be returned in the output of the assembler by P-Machinery, something like this:

   Available:
     Segment 0  (8K): 841 words.
     Segment 1  (8K): 4401 words.
     Segment 2 (15K): 2322 words.
     Segment 3  (4K): 4096 words.
     Segment 4  (3K): 3840 words.
     Segment 5  (2K): 2034 words.
               TOTAL: 17534 words.

 

Notice that each one has a different size. You can use them in any order as long as you don't overflow them.

 

-dZ.

Edited February 11, 2012 by DZ-Jay

[+DZ-Jay]

As you can all tell, I'm a "cart.mac" cheerleader.

[vprette]

Seems fixed!!

:-0

 

you look like a group of magicians

[intvnut]

Notice that each one has a different size. You can use them in any order as long as you don't overflow them.

 

Not only that, but you can also switch ROMSEGs as often as you like, if you really need to pack things carefully. Example:

 

   ROMSEG 2
   INCLUDE "blah_a.asm"
   ROMSEG 1
   INCLUDE "blah_b.asm"
   ROMSEG 2
   INCLUDE "blah_c.asm"
   ROMSEG 1
   INCLUDE "blah_d.asm"
   ROMSEG 2
   INCLUDE "blah_e.asm"
   ROMSEG 1
   INCLUDE "blah_f.asm"
   ROMSEG 2
   INCLUDE "blah_g.asm"
   ROMSEG 1
   INCLUDE "blah_h.asm"

 

That is perhaps an extreme example. But, there are times when file "A" needs to be included before file "B", but you need them in different ROMSEGs. cart.mac is here to help.

 

As you can all tell, I'm a "cart.mac" cheerleader.

 

I guess I must have done an OK job, then. :-)

[intvnut]

Seems fixed!!

:-0

 

you look like a group of magicians

 

Quoting the Wizard of Oz: Ignore the man behind the curtain!

 

[+DZ-Jay]

Seems fixed!!

:-0

 

you look like a group of magicians

 

Quoting the Wizard of Oz: Ignore the man behind the curtain!

 

 

Wow! Joe, nice pearly whites you have in that photo!

[vprette]

Done some initial study on the walkthrough logic, and update status

 

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 - 38 over 214 [huge task]

- MUSIC: translate mod to decles of custom music "shadows" 0%

- PLAYER STATE: ok (add state PAGE)

- PLAY ENGINE1: ok (implement transition from PAGE to PAGE and 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 0%

- PLAY ENGINE4: implement level logic transition machine (game walkthrough) [huge task] - 14 macro_levels 0%

- PLAY ENGINE5: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine [huge task] 0%

- PLAY ENGINE6: ok (implement music pause)

- SCORE: implement scoring 0%

- BUG TESTING: 1 bug discovered/solved :-)

- BOX: 80%

- OVERLAYS: 0%

- MANUAL: 5%

Overall: 25%

Edited February 11, 2012 by vprette