catsfolly Posted February 11, 2012 Share Posted February 11, 2012 You really might want to look into Joe's advent.zip file above (in message 33). He has a perl script that makes a dictionary entry for each word, and then makes a string where each word is replaced by single number. The way he has set up the labels makes it easy to still read the text. The text files are much smaller this way. Maybe a similar automated approach could help you with your data entry. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 11, 2012 Share Posted February 11, 2012 You really might want to look into Joe's advent.zip file above (in message 33). He has a perl script that makes a dictionary entry for each word, and then makes a string where each word is replaced by single number. The way he has set up the labels makes it easy to still read the text. The text files are much smaller this way. Maybe a similar automated approach could help you with your data entry. Also, as I mentioned before, ideally you want a single routine to display the text and just read the appropriate entry from the look-up table. You can just put all your text blocks in a text file and process them through Joe's script. That will definitely make it easier to complete the entire set of data. We can help in the implementation of the display routine to unpack the strings. -dZ. Quote Link to comment Share on other sites More sharing options...
vprette Posted February 11, 2012 Author Share Posted February 11, 2012 (edited) I'll have a look to this but in the meantime I'm looking to keyboard intro and game logic... I can finish contents later also I still have position of text on screen hard coded :-) Edited February 11, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
vprette Posted February 12, 2012 Author Share Posted February 12, 2012 mmm... I downloaded the keyboard demo and run jzintv with ecs option on.... I see the blinking cursor by taping on the keyboard of my notebook has no effect Quote Link to comment Share on other sites More sharing options...
catsfolly Posted February 12, 2012 Share Posted February 12, 2012 mmm... I downloaded the keyboard demo and run jzintv with ecs option on.... I see the blinking cursor by taping on the keyboard of my notebook has no effect You have to press the "F7" key to switch the keyboard to ECS mode. Press the"F5" key to switch the keyboard back. (as described in jzintv/docs/programming/jzintv/jzintv.txt) Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 12, 2012 Share Posted February 12, 2012 mmm... I downloaded the keyboard demo and run jzintv with ecs option on.... I see the blinking cursor by taping on the keyboard of my notebook has no effect Valter, we need to work on hooking up Joe's keyboard decoder to P-Machinery. It should be simple, but P-Machinery has some expectations as to the input and output registers used, so the code may require some tweaking. I'll try to work on that by next week. I am concurrently working on the new version of P-Machinery, documentation for it, and finishing up Christmas Carol. I am the true poster-boy for Structured Procrastination. -dZ. Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 13, 2012 Share Posted February 13, 2012 mmm... I downloaded the keyboard demo and run jzintv with ecs option on.... I see the blinking cursor by taping on the keyboard of my notebook has no effect Valter, we need to work on hooking up Joe's keyboard decoder to P-Machinery. It should be simple, but P-Machinery has some expectations as to the input and output registers used, so the code may require some tweaking. I'll try to work on that by next week. I am concurrently working on the new version of P-Machinery, documentation for it, and finishing up Christmas Carol. I am the true poster-boy for Structured Procrastination. -dZ. dZ, In one program where I added keyboard support, I just added the following into SCANHAND, just after the opening PSHR: IF DEFINED SCAN_KBD CALL SCAN_KBD CMPI #KEY.NONE, R0 BEQ @@no_key MOVR R0, R1 MVI SHDISP, R2 TSTR R2 BEQ @@no_key ADDI #3, R2 MVI@ R2, R0 JSRD R5, QTASK @@no_key: ENDI And then, in the hand-controller dispatch tables, I added a fourth dispatch vector to handle keyboard events. The best solution in the world? Perhaps not. But it was really really easy. For P-Machinery, you probably want to be able to change input modes between keyboard + controllers and controllers only, if only for the fact that scanning the keyboard is so time consuming. Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 13, 2012 Share Posted February 13, 2012 IF DEFINED SCAN_KBD CALL SCAN_KBD CMPI #KEY.NONE, R0 BEQ @@no_key MOVR R0, R1 MVI SHDISP, R2 TSTR R2 BEQ @@no_key ADDI #3, R2 MVI@ R2, R0 JSRD R5, QTASK @@no_key: ENDI ... For P-Machinery, you probably want to be able to change input modes between keyboard + controllers and controllers only, if only for the fact that scanning the keyboard is so time consuming. Hmm... looking at that code again, if you don't mind burning an add'l word of stack, you could move the tests around and control keyboard scanning via your SHDISP table: IF DEFINED SCAN_KBD MVI SHDISP, R2 TSTR R2 BEQ @@no_key ADDI #3, R2 MVI@ R2, R0 TSTR R0 BEQ @@no_key PSHR R0 CALL SCAN_KBD MOVR R0, R1 PULR R0 CMPI #KEY.NONE, R1 BEQ @@no_key JSRD R5, QTASK @@no_key: ENDI Now if the fourth entry in your SHDISP table is 0, it won't scan the keyboard. Sure, it's still a hamfisted solution in many ways, but easy to add in. For a game like Colossal Cave it may be adequate. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 13, 2012 Share Posted February 13, 2012 mmm... I downloaded the keyboard demo and run jzintv with ecs option on.... I see the blinking cursor by taping on the keyboard of my notebook has no effect Valter, we need to work on hooking up Joe's keyboard decoder to P-Machinery. It should be simple, but P-Machinery has some expectations as to the input and output registers used, so the code may require some tweaking. I'll try to work on that by next week. I am concurrently working on the new version of P-Machinery, documentation for it, and finishing up Christmas Carol. I am the true poster-boy for Structured Procrastination. -dZ. dZ, In one program where I added keyboard support, I just added the following into SCANHAND, just after the opening PSHR: IF DEFINED SCAN_KBD CALL SCAN_KBD CMPI #KEY.NONE, R0 BEQ @@no_key MOVR R0, R1 MVI SHDISP, R2 TSTR R2 BEQ @@no_key ADDI #3, R2 MVI@ R2, R0 JSRD R5, QTASK @@no_key: ENDI And then, in the hand-controller dispatch tables, I added a fourth dispatch vector to handle keyboard events. The best solution in the world? Perhaps not. But it was really really easy. For P-Machinery, you probably want to be able to change input modes between keyboard + controllers and controllers only, if only for the fact that scanning the keyboard is so time consuming. Joe, P-Machinery doesn't use SCANHAND. It re-implements it to break it out into different "decoders" and uses the state dispatch table to assign a decoder to each sub-state. This makes it even simpler to add ECS Keyboard support exactly when it is wanted only. It should be real easy to take your code as is and add it to P-Machinery. I just need to mind the output register in order to be consistent. I also want to take the time and understand the code before incorporating it and this may take a couple of days. -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 13, 2012 Share Posted February 13, 2012 For P-Machinery, you probably want to be able to change input modes between keyboard + controllers and controllers only, if only for the fact that scanning the keyboard is so time consuming. Joe, P-Machinery doesn't use SCANHAND. It re-implements it to break it out into different "decoders" and uses the state dispatch table to assign a decoder to each sub-state. This makes it even simpler to add ECS Keyboard support exactly when it is wanted only. It should be real easy to take your code as is and add it to P-Machinery. I just need to mind the output register in order to be consistent. I also want to take the time and understand the code before incorporating it and this may take a couple of days. -dZ. Also, P-Machinery's input decoder framework could use a bit of work. It merges both the left and right controller, but has no capabilities for games that require two controllers simultaneously. It also only treats the disc as either a 4-way joystick with rolling-thumb heuristics, or a 4-direction switch with dead-zone diagonals. These were the requirements for Pac-Man and Christmas Carol; it's time for it to break out of that box. -dZ. Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 13, 2012 Share Posted February 13, 2012 Joe, P-Machinery doesn't use SCANHAND. It re-implements it to break it out into different "decoders" and uses the state dispatch table to assign a decoder to each sub-state. This makes it even simpler to add ECS Keyboard support exactly when it is wanted only. It should be real easy to take your code as is and add it to P-Machinery. I just need to mind the output register in order to be consistent. I also want to take the time and understand the code before incorporating it and this may take a couple of days. Heck, it should be easy enough to tweak SCAN_KBD to use different registers, too, if it ends up fitting better with the rest of P-Machinery. I don't quite remember why I set KEY.NONE to $FF instead of $00. I don't see anything in the code that precludes that change either, so if that makes your life easier, go with it. Once you get past all the vagaries of the hardware, the code itself is actually pretty simple. Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 13, 2012 Share Posted February 13, 2012 It should be real easy to take your code as is and add it to P-Machinery. One other thought: For P-Machinery, you probably do want to include the suggested DIS/EIS pairs that I mentioned in the tutorial thread, just to avoid any wackiness between the keyboard code, the SFX engine and the tracker. Quote Link to comment Share on other sites More sharing options...
vprette Posted February 14, 2012 Author Share Posted February 14, 2012 (edited) 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 - 79 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 (must reconnaise ONLY characters not symbols except ?) 0% - PLAY ENGINE4: implement level transition maps [huge task] - 14 macro_maps - 1% - PLAY ENGINE5: implement answer logic machine (game walkthrough) [huge task] - 0% - PLAY ENGINE6: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine [huge task] 0% - PLAY ENGINE7: ok (implement music pause) - SCORE: implement scoring 0% - BUG TESTING: 1 bug discovered/solved :-) - BOX: 80% - OVERLAYS: 0% - MANUAL: 5% Overall: 25% Edited February 14, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
vprette Posted February 15, 2012 Author Share Posted February 15, 2012 (edited) Few initial concepts to be clarified about game engine - the parser will be called from MY_INPUT proc, that is running during play state (right?) - the map transition is independent from the parser, and can be written in the MY_INPUT as a sequnce of: if keytab is N then (if youre in level_1 move to leve_2; if youre in LEVEL_4 move to LEVEL_7 etc.) if keytab is NE then (etc.) is this the best solution? or this transition must be writte inside the parser itself.... because this part I could already code without thinking of the parser at the moment (that's it, command recognition like TAKE or EAT is different from map movement recognition in my approach) I would define a global variable that say in which level I am (update everytime I enter a level) in MY_INPUT, when I press of the 9 directions, I check the variable and call another LEVEL depending on which level I am... Edited February 15, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted February 16, 2012 Share Posted February 16, 2012 (edited) Few initial concepts to be clarified about game engine - the parser will be called from MY_INPUT proc, that is running during play state (right?) MY_INPUT was the procedure assigned to a sub-state that handles showing text pages. You need another sub-state for capturing user input. The idea is that you have a state for regular play, let's call it "command," in which you are waiting for input from the user: the user types his command and the characters are displayed. Then the user hits the "ENTER" key and you switch states to "process," in which no input is being accepted, and the game parses the text and tokenizes the command in order to know what to do. When the command is parsed and tokenized and the resulting action is computed, then you switch to the "page" state, in which you display a page of text and wait for user input to switch to the next one. And finally, when all pages are rendered, the game switches back to "command" state and waits for more user input. This is just an example, but the intention is to treat your game as a finite state machine. Each machine state is defined in the state dispatch table and assigned an input decoder or none. - the map transition is independent from the parser, and can be written in the MY_INPUT as a sequnce of: if keytab is N then (if youre in level_1 move to leve_2; if youre in LEVEL_4 move to LEVEL_7 etc.) if keytab is NE then (etc.) is this the best solution? or this transition must be writte inside the parser itself.... because this part I could already code without thinking of the parser at the moment (that's it, command recognition like TAKE or EAT is different from map movement recognition in my approach) I'm not sure what the "map transition" is? Apart from the command-line input parser, is there going to be a "map" screen in which the user moves around using the disc? If so, I expect this to be a separate sub-state with its own handler routine: User enters command: "MAP" System switches to "map" sub-state, displays the map and accepts now disc input Player moves around in the map Player hits some "exit" key System switches back to "command" sub-state and waits for more user commands. I would define a global variable that say in which level I am (update everytime I enter a level)in MY_INPUT, when I press of the 9 directions, I check the variable and call another LEVEL depending on which level I am... I suppose that by "level" you are referring to the cave "rooms," right? If so, yes, you keep a global variable and update it every time the user moves. The variable should then serve as some sort of index into your game data, to know how the game needs to behave for that specific room. I don't know exactly how Colossal Cave Adventure is arranged, but I imagine that it should be a two-dimensional grid of cave rooms, where each room is a position in which the user can be at any time. If so, you can represent this grid with a look-up table in ROM that points to the routines that handle each room. Your global variable then should serve as an index into this grid. That way, you don't have to write tedious code with multiple "IF...ELSE" branches, you just compose your table pointer and call the function. There's more than one way to skin a cat, though. -dZ. Edited February 16, 2012 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
vprette Posted February 16, 2012 Author Share Posted February 16, 2012 The state "command" you refer is in fact state PLAY and use MY_INPUT The page transition is in my program the new state PAGE and use MY_INPUT_DISC... :-) the grid is 3-dimensional, and the table pointer I have to understand how to do..... at the moment I'm a bit lazy and focusing on two more easy part: the hidden novel (I just added, people need to discover how to show it :-) and the manual... also, since P-machinery is started around a pac-man game... I was thinking to work on a third project: Nibbler! nibbler could be more faisable for me and help me learn more about sprites and game sound effects before to work on Empires Collide... what you think? is Nibbler an easy project to approach? Quote Link to comment Share on other sites More sharing options...
vprette Posted February 16, 2012 Author Share Posted February 16, 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 demo music) - FONT: ok (custom) - CONTENTS: insert all levels message text descriptions - 79 over 214 [huge task] - MUSIC: translate mod to decles of custom music "shadows" 0% - GAME STATES: 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 (must reconnaise ONLY characters not symbols except ?) 0% - PLAY ENGINE4: implement level transition maps [huge task] - 14 macro_maps - 1% - PLAY ENGINE5: implement answer logic machine (game walkthrough) [huge task] - 0% - PLAY ENGINE6: implement the parser to reconnaise text/keypad commands inserted to be used by login transition machine [huge task] 0% - PLAY ENGINE7: ok (implement music pause) - HIDDEN NOVEL: ok (discover it! :-) ) - SCORE: implement scoring 0% - BUG TESTING: 1 bug discovered/solved :-) - BOX: 80% - OVERLAYS: 0% - MANUAL: 10% (based on ECS original layout) Overall: 28% Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 16, 2012 Share Posted February 16, 2012 (edited) The state "command" you refer is in fact state PLAY and use MY_INPUT The page transition is in my program the new state PAGE and use MY_INPUT_DISC... :-) the grid is 3-dimensional, and the table pointer I have to understand how to do..... My understanding of Colossal Cave is that it just keeps a table of rooms and exits for each room. Suppose there are only 4 possible exits from each room--North, South, East, West. (I know CC offers more possible exit directions than that, but I want to keep the example simple.) Now suppose you have 4 rooms connected in a square, numbered 1 through 4. 0 means no exit. Then the connectivity table for that might look like this: ROOMS PROC @@1 DECLE 2, 0, 3 ,0 ; Room 2 to the north, Room 3 to the east @@2 DECLE 0, 1, 4, 0 ; Room 1 to the south, Room 4 to the east @@3 DECLE 4, 0, 0, 1 ; Room 4 to the north, Room 1 to the west @@4 DECLE 0, 3, 0, 2 ; Room 3 to the south, Room 2 to the west ENDP So, that should set up a map that looks like this: 2 <====> 4 ^ ^ | | | | v v 1 <====> 3 To move between rooms (what I believe you mean by "map transition"), the lookup goes something like this: MVI CUR_ROOM, R1 ; Get current room (1, 2, 3, 4) DECR R1 ; make "zero based" SLL R1, 2 ; Multiply by 4, since 4 possible exits per room ADD DIRECTION, R1 ; 0 = N, 1 = S, 2 = E, 3 = W MVI@ R1, R0 ; Get new room number TSTR R0 BEQ @@no_exit ; 0 means "no exit in this direction" MVO R0, CUR_ROOM ; Update current room to new room ; do new room stuff here. There are ways to optimize this slightly, but honestly, I wouldn't worry about that too much at this point. Premature optimization is a bad idea. You don't need it yet, and may never need it. Edited February 16, 2012 by intvnut Quote Link to comment Share on other sites More sharing options...
vprette Posted February 16, 2012 Author Share Posted February 16, 2012 (edited) yes, for map transition I mean going N,S,E,W, and you can also go Up and Down, so it's 6 directions I try to keep separated the map transition from the parser for two reason: - map transition/movements between levels can be handled by keypad 1-9,clear,enter.. from the controller - during bug testing, it would be possible to move all around maps without any command, and this is priority before any insertion of command logic. following your example, I should define something like this: ROOMS PROC @@1 DECLE 2, 0, 3 ,0, 0, 0 ; Room 2 to the north, Room 3 to the east, no up or down @@2 DECLE 0, 1, 0, 4, 0, 0 ; Room 1 to the south, Room 4 to the east, no up or down @@3 DECLE 4, 0, 0, 1, 0, 0 ; Room 4 to the north, Room 1 to the west, no up or down @@4 DECLE 0, 3, 0, 2, 0, 0 ; Room 3 to the south, Room 2 to the west, no up or down ....... ;THERE WILL BE ALMOST 100 levels.... ENDP I also define 2 global variables: CUR_ROOM ;WILL BE USED FOR THE COMMAND LOGIC AS WELL DIRECTION ;IS UPDATED BY RECONNAISING KEYPAD INPUT (MY_INPUT) is this what I need? Edited February 16, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 16, 2012 Share Posted February 16, 2012 (edited) yes, for map transition I mean going N,S,E,W, and you can also go Up and Down, so it's 6 directions I try to keep separated the map transition from the parser for two reason: - map transition/movements between levels can be handled by keypad 1-9,clear,enter.. from the controller - during bug testing, it would be possible to move all around maps without any command, and this is priority before any insertion of command logic. following your example, I should define something like this: ROOMS PROC @@1 DECLE 2, 0, 3 ,0, 0, 0 ; Room 2 to the north, Room 3 to the east, no up or down @@2 DECLE 0, 1, 0, 4, 0, 0 ; Room 1 to the south, Room 4 to the east, no up or down @@3 DECLE 4, 0, 0, 1, 0, 0 ; Room 4 to the north, Room 1 to the west, no up or down @@4 DECLE 0, 3, 0, 2, 0, 0 ; Room 3 to the south, Room 2 to the west, no up or down ....... ;THERE WILL BE ALMOST 100 levels.... ENDP I also define 2 global variables: CUR_ROOM ;WILL BE USED FOR THE COMMAND LOGIC AS WELL DIRECTION ;IS UPDATED BY RECONNAISING KEYPAD INPUT (MY_INPUT) is this what I need? That would give you basic room to room travel. I'm looking at this code, though: http://www.rickmurphy.net/advent/INITAD.FT It looks like the rules might be a little more complicated. But, if you stick to the algorithm they describe there in sections 3 and 4, you can use the database in ADVENT.TX directly with minor modification (ie. use a script to convert it to appropriate assembly directives). Because we're dealing with binary numbers, we might want to consider tweaking the numeric ranges slightly, but whatever conversion script we use can do that under the hood. For example, 1024 is far more convenient than 1000 for division and modulo. I think if you read through this, it'll be clearer how to deal with the database. They lay out the algorithms and meanings in English, so it should be easier to reason about the code. Indexing into the database would be as I showed above, but it looks like the actual logic to decide whether you can move or not is a bit more involved. Fortunately, they spell it all out there. EDIT: BTW, here's the database itself. It appears that pretty much 90% of the game logic is encoded into this database: http://www.rickmurphy.net/advent/ADVENT.TX The other 10% is in that special computed goto, it appears. So if we can script the conversion of this database (possibly modifying its format slightly to pack into ROM better, since there are is a lot of wasted space in there), that captures the meat of the game very quickly. Then you can focus on all the Intellivision-specific enhancements after that. Edited February 16, 2012 by intvnut Quote Link to comment Share on other sites More sharing options...
vprette Posted February 16, 2012 Author Share Posted February 16, 2012 (edited) the problem is that I'm not sure which version fo the game is described there (not the original for sure , that has only 6 sections on the database) What I do now is proceed on paper: I have a solution of the game described in map, and the C64 version of the original game: Using Vice c64 emulator, I try to follow the map solution and build on paper a better described map. After this I should know exaclty movements from room to room, than I can translate to code.... this is for map transitions this job is for almost 100 rooms and 10 directions: 1000 combinations.... it's huge but my mind can handle about the game logic, this is based on the parser... I guess the parser must reconnaise the command and update consequently a COMMAND_INSERTED variables that goes from 0 to 200 (200 commands and word reconnaised) (this if command was made of only 1 word) and I combine COMMAND_INSERTED with CUR_ROOM to know what to do... this job is for almost 100 rooms and 200 commands: 20000 combinations!!!!.. and in the game the command is made by 2 words not 1 so it will be be much more!! I need the matrix and pointer for sure! better not to think about this part now :-0 it's not an easy task.... but now is time to play the game on c64 emulator to understand the logic :-) Edited February 16, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 17, 2012 Share Posted February 17, 2012 Valter, Trying to reverse the map in this way sounds exceptionally painful. It also isn't guaranteed to capture all of the subtlety. Some rooms have rules that prevent you from doing certain things unless you have a certain object, for example, or you've set some other flag elsewhere. Also, you have fun verbs like XYZZY and PLUGH... There's one other challenging thing: Some actions only have a certain percentage chance of succeeding. The version I've been examining is the OS/8 version, because it's easy to bring up the files for in the web browser. It's the "350 point" version. There's a 550 point and 581 point version beyond this. This appears to be source for a version of the 550-point cave: https://code.google.com/p/colossal-cave/source/browse/trunk/adv5/ . If you toggle open the ADV_DB, everything looks like it's in a much friendlier format. There isn't much C code to it, really. And, most of the game is compiled to a simple byte code, which may make the overall result more dense. I still think you should consider scripting all this stuff. If you have to do something 20,000 times, and you're correct 99.9% of the time, you've still make 20 mistakes that you now have to go find. Quote Link to comment Share on other sites More sharing options...
jeffgamer Posted February 17, 2012 Share Posted February 17, 2012 Not sure if this is the thread to request, but when this is released in cart form, please put me down on the list for a copy! Thanks! :-) Quote Link to comment Share on other sites More sharing options...
vprette Posted February 17, 2012 Author Share Posted February 17, 2012 (edited) Ok a little step forward: the so called travel table resume all teh allowed movement, not only by choosing a direction, but also in few cases by a condition. This table is resuming togheter the map transition logic and the game walkthrough logic, so I have to modify the project a bit. The correct table is the one below, since the advent.tx is the Woods expanded version: 1 2 2 44 1 3 3 12 19 43 1 4 4 5 13 14 46 30 1 5 6 45 43 1 8 49 2 1 8 2 12 7 43 45 30 2 5 6 45 46 3 1 3 11 32 44 3 11 48 3 33 65 3 79 5 14 4 1 4 45 4 5 6 43 44 29 4 7 5 46 30 4 8 49 5 4 9 43 30 5 300 6 7 8 45 5 5 44 46 6 1 2 45 6 4 9 43 44 30 6 5 6 46 7 1 12 7 4 4 45 7 5 6 43 44 7 8 5 15 16 46 30 7 24 47 14 30 8 5 6 43 44 46 8 1 12 8 7 4 13 45 8 301 3 5 19 30 9 302 11 12 9 10 17 18 19 44 9 14 31 9 11 51 10 9 11 20 21 43 10 11 19 22 44 51 10 14 31 11 310 49 11 10 17 18 23 24 43 11 12 25 305 19 29 44 11 3 48 11 14 31 12 310 49 12 11 30 43 51 12 13 19 29 44 12 14 31 13 310 49 13 11 51 13 12 25 305 43 13 14 23 31 44 14 310 49 14 11 51 14 13 23 43 14 303 30 31 34 14 16 33 44 15 18 36 46 15 17 7 38 44 15 19 10 30 45 15 304 29 31 34 35 23 43 15 34 55 15 62 69 16 14 1 17 15 8 38 43 17 305 7 17 306 40 41 42 44 19 39 18 15 38 11 8 45 19 15 10 29 43 19 307 45 36 19 308 46 37 19 309 44 7 19 74 66 20 26 1 21 26 1 22 15 1 23 8 1 24 7 1 25 9 1 27 17 8 11 38 27 40 45 27 41 44 28 19 38 11 46 28 33 45 28 36 30 52 29 19 38 11 45 30 19 38 11 43 30 62 44 29 31 17 1 32 19 1 33 3 65 33 28 46 33 34 43 53 54 33 35 44 34 33 30 34 15 29 35 33 43 55 36 37 43 17 36 28 29 52 36 39 44 37 36 44 17 37 38 30 31 56 38 37 56 29 39 36 43 39 64 30 52 58 39 65 70 40 41 1 41 42 46 29 23 56 41 27 43 41 59 45 41 60 44 17 42 41 44 42 43 43 42 44 46 43 42 44 43 44 46 43 45 43 44 42 45 44 43 43 44 48 30 44 50 46 45 43 45 45 46 43 45 47 46 46 45 44 11 47 45 45 11 48 44 29 11 49 50 30 43 49 51 44 50 44 43 50 49 44 29 50 52 46 51 49 44 51 52 43 51 53 46 52 50 45 52 51 44 52 53 29 52 55 43 53 51 44 53 52 45 53 54 46 54 53 43 11 55 52 44 55 56 30 55 57 43 56 55 29 11 57 55 44 57 58 46 57 13 30 56 58 57 44 11 59 27 1 60 41 43 29 60 61 44 60 62 45 30 61 60 43 11 62 60 44 62 63 45 62 30 43 62 15 46 63 62 46 11 64 39 29 56 59 64 65 44 65 64 43 65 66 44 65 68 61 65 311 46 65 312 29 66 313 45 66 65 60 66 67 44 66 77 25 66 314 46 67 66 43 67 72 60 68 66 46 68 69 29 69 68 30 69 74 46 70 71 45 71 39 29 71 65 62 71 70 46 72 67 63 72 73 45 73 72 46 74 19 43 74 69 44 74 75 30 75 76 46 75 77 45 76 75 45 77 75 43 77 78 44 77 66 45 78 77 46 79 3 1 the first and second numbers are rooms (from and to) where the second number can include a condition; from third number are the verbs (command passed by the parser) that result in the movement from room to room I have to make this TRAVEL_TABLE like the ROOMS PROC exemple of Joe? also: some room allow for a short descrition, so I also work on the short messages and need to introduce several variables to set when and if I have already been in the rooms (in which case I show the short description) 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 long descriptions (done) + short descriptions + verbs (reconnaised commands) + conditional messages + additional messages - 79 over 214 [huge task] - MUSIC: translate mod to decles of custom music "shadows" 0% - GAME STATES: 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 (must reconnaise ONLY characters not symbols except ?) 0% - PLAY ENGINE4: implement TRAVEL_TABLE (where unconditional and conditional movements from room to room are described) 0% - PLAY ENGINE5: implement logic machine (to change object inventory and change conditional variables to be used by the TRAVEL_TABLE) [huge task] - 0% - PLAY ENGINE6: implement the parser to reconnaise text/keypad commands inserted (VERBS) to be used by login machine [huge task] 0% - PLAY ENGINE7: ok (implement music pause) - HIDDEN NOVEL: ok (discover it! :-) ) - SCORE: implement scoring 0% - BUG TESTING: 1 bug discovered/solved :-) - BOX: 80% - OVERLAYS: 0% - MANUAL: 15% (based on ECS original layout, made with Indesign) Overall: 28% Edited February 17, 2012 by vprette Quote Link to comment Share on other sites More sharing options...
intvnut Posted February 24, 2012 Share Posted February 24, 2012 Valter, I stumbled across a version of the 550-pt Colossal Cave that had all the original C code for the bytecode interpreter based game. I spent some time off and on over the last week porting it all to the Intellivision. It's not 100% bug-free, but so far it works pretty well. Check it out! This version requires the ECS and JLP. It also uses bank switching to store the 144K byte database. This database contains both the text phrases and the bytecode for all the game logic. This leaves you about 100K bytes (50K words) to program up graphics and music to go with it. :-) The driver program that's in there now just reuses my ANSI terminal code to display text. That's easily replaced with something else. There are some other changes that should be made to fit it into P-Machinery or the like, but again, those are minor. The major point is that the bytecode engine runs just fine on the Intellivision and is ready to go. I haven't optimized this one bit. You might notice it's a little slow. It shouldn't be too hard to speed it up at least a little. To run this in one of the recent builts of jzintv: jzintv -s1 --jlp -m2 advent The "-m2" switches to the ECS keyboard map at startup. You can add more flags, of course (such as -z# to change the resolution of the display). The ZIP file contains all the C source and adventure database files I consulted when writing the Intellivision version. The Intellivision version is under the directory "adv5/intv/." I apologize for its messiness. This was meant to be a quick and dirty port. It needs some work to make it into a complete game. I'm hoping it'll kick-start your efforts, so you can focus on making this a nice game for Intellivision. Happy adventuring! --Joe adv5_for_inty.zip 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.