Robert M

Things I like in a RPG: - At least some non-linear play. REAL choices. - Manual stats allocation vs only Random. - Secret doors - Cursed items you have trouble getting rid of once you pick them up - Having a few really large scale battles. Things I hate: - Enemies can attack diagonally or at any angle for missle attacks, but I am limited to vertical and horizontal. - Fake choices! The game offers a choice, but if you choose one it makes you go back and choose the other. Grrrr! - An endless stream of piddly battles that are no challenge because you are level 1000+ but those groups of 2 goblins or 1 large spider insist on fighting you every 2 feet. BORING!

Oh good! Sorry about the whole branching address thing. I didn't have my handing dandy chart for calcuating branch offsets so I just put the target address. I thought that would be okay since that's how it was for original branch instructions in the listing. Cheers!

Here's a wacky idea that's been banging around in my head for a few weeks now. In single player mode, the kernel is a two line kernel and the one player's game fills the whole screen. For two player mode, split the screen horizontally one player on top and one on the bottom. Switch to a single line kernel repeated twice, once for each player thus filling the screen. That might be enough right there, but the graphics will be noticibly scrunched. You can take it a step further by using interlacing. You thereby restore each player's field to the same number of scanlines as the single player mode, but you are drawing only half of them each frame. Hopefully the interlaced graphics will appear less scrunched.

Okay, if you want to stick with your current listing, then I recommend you make what is best described as a software patch. From your source: F832 86,9A STX &9A ;Store the object dynamic data address. F834 A6,A0 LDX &A0 ;Get the object number. F836 20,FE,F6 JSR &F6FE ;See if another object has hit the dragon. F839 A6,9A LDX &9A ;Get the object address. F83B C9,51 CMP #&51 ;Has the sword hit the dragon. F83D D0,0C BNE &F84B ;If not, branch. change it to this: F832 86,9A STX &9A ;Store the object dynamic data address. F834 A6,A0 LDX &A0 ;Get the object number. F836 20,FE,F6 JSR &F6FE ;See if another object has hit the dragon. F839 A6,9A LDX &9A ;Get the object address. JMP &FD88 ;Jump to patch. NOP ;Use exactly 4 bytes ROM Then change the listing: ;Object #4 : State FF : Graphic FD88 F0 XXXX FD89 80 X FD8A 80 X FD8B 80 X FD8C F4 XXXX X FD8D 04 X FD8E 87 X XXX FD8F E5 XXX X X FD90 87 X XXX FD91 80 X FD92 05 X X FD93 E5 XXX X X FD94 A7 X X XXX FD95 E1 XXX X To this: ;Object #4 : State FF : Graphic ;Software patch FD88 CMP #&51 BEQ &FF93 ; Touching sword CMP #&87 BEQ &FD93 ; Touching dot JMP &F84B ; nothing happens FD93 JMP &F83F ; dragon dies That should work.

Okay, their are two problems with the change you made. First, you can't put another CMP instruction immediately after the first. When you do, the processor "forgets" the results of the first compare instruction. You need to put a Branch test after each compare like this: CMP #$51 - If the sword (#$51) hits dragon, jump to 'kill' routine BNE LF84B CMP #$87 - I added this line to make the dot (#$87) kill the drag BNE LF84B The other problem is you can't just delete bytes from the end of the new file to make it 4096 bytes long. By doing so you probably deleted the address that the processor uses to know where to begin executing the code. Another problem with adding code is that it can rearrange where graphics are located in memory. That can destroy the game timing because the processor may need to start crossing page boundaries to read graphics data. Doing so slows the processor down, which means it can't draw as much as it needs to to properly draw the screen. If you want to alter the code, you must first make sure that your changes won't move the graphics from their original positions, or else you will need to change the code to account for the moved graphics (not a trivial task). To do this compile the original file and produce a list file using the -l option on the command line. Look in the list file and see what addresses the various graphics are located at. Then go back into the code, and add an ORG statement before each section of graphics data to lock it location in memory in place like this: ORG spritestable .byte $00,$01...yada yada yada Now that you have locked the graphics in place. You need to find free space so you can insert your new code. I don't know if there is any unused space in the Adventure ROM. The best place to look again is in the list file. Hopefully the free space (if any) will be in a place that will not require you to move the graphics to get it into the region of space in the ROM where your additional code can expand into it. Here is another alternative. If you can reorder the objects in the game so that all the items you want to have be able to kill a dragon have the highest code values or the lowest code values, then you can make the change without needing to add any bytes of code. I am of course assuming that no where in the code it takes advantage of the objeect order in the same manner I am about to demonstrate. Assuming the dot and sword are the lowest numbered objects, say $00 = dot, and $15 = sword, then LDX $9A CMP #$16 - If the sword $15 or dot $00 BMI KillDragon Of if they are the highest object values: LDX $9A CMP #$6E - If the sword $6E or dot $7D BPL KillDragon I just noticed in your code snippet above you used the BNE instruction after the comparte. If LF84B is the location of the routine to kill the dragon, then you should be using BEQ not BNE. If by NOT branching falls through to the routine to kill the dragon then BNE was correct. Regards, Rob

Well I finally located the data and code related to doorways. Hopefully I can get it figured out later tonight, or maybe tomorrow. Who all is working on something for this contest? Just curious. I'll be happy to share my latest disassembly once I figure out how doors work. There are some weird things going on in this game. Cheers!

One of my favorites long ago was "The Bounty" http://www.klov.com/game_detail.php?letter...=B&game_id=7203 A very fun little game. Back in the heyday, the big local arcade would sometimes have all the games on free play for half a day. While everyone else stood in line to play Star Wars or Bump 'n Jump, my friends and I would play this game largely by ourselves. Good-times!

Behold! the Yoink... http://www.atariage.com/forums/viewtopic.php?t=41822

I noticed it was different. Did you do that? It looks nice.

MP3 files work fine for me, I make the header a little longer (2 sec) and encode at 192kbs, I can fit 255 in my mp3 player Good Luck Interesting, thanks for the info. I will have to experiment with MP3s as you have described.

Well since I recently obtained a starpath supercharger (thanks CPUWIZ!), I have begun to fantasize about creating a portable gaming library. I would store all the 2K and 4K ROMs I own on an Apple iPod Music player in WAV format. Then I could carrying the iPod and supercharger to transport a couple hundred games from my library, all without risk of losing or damaging the originals. Plus I would have all the great starpath supercharger titles on the iPod as well. I know mp3 files won't work with the supercharger, so I would have to use WAV format. Has anyone else tried to load games into a supercharger from a portable music player? Any success or failure stories? Cheers!

Good news!! How did you confirm this? Go here: http://www.uspto.gov/ Search for "Wolfenstein" in the Trademarks database.

BTW, the trademark on the word "Wolfenstein" for video games expired in 1996. Of course the recent titles including "Wolfenstein" from id software are trademarked, but the word "Wolfenstein" by itself is not. So it should be okay to use "Wolfenstein" as a title for this hack without raising legal hell. Cheers

I have managed to disassemble some more of the venture code. Here is my latest work. The attached file is zipped so you need to unzip it. Winzip for windows users, and gzip for UNIX and Linux users. Since the file originated on a Unix system, I recommend that Windows users after unzipping the file should open it in WordPad and save as a .txt file. That will fix any carriage return issues with the file. Cheers! venture.s.gz

Thank you very much sir, I owe you $4.00 ! You paid for shipping twice. That's kind of you. If you want to just put a personal check in the box that's fine by me. I had to pay for the power supply immediately according to ebay if I used the but it now option. Thanks, for the stuff. I have been shopping for a supercharger for some time now. Getting the thing already modded is a big plus! Cheers!

Yoink!

Lesson 5 - Excercise Answers: Exercises: 1. Perform the following binary additions of 2's complement numbers. Express the final result in 8 bits and indicate whether UNDERFLOW or OVERFLOW occurred. a. %10010100 + %01101000 --------- %11111100 -> No overflow or underflow. b. 11111 -> carry the 2. %00110100 + %01101111 --------- %10100011 -> Overflow occurred! Adding 2 positive numbers resulted in a negative. c. 11111 -> carry the 2. %10011100 + %11111000 --------- %10010100 -> No Underflow. d. 11 11111 -> Carry the 2. %01010011 + %11011101 --------- %00110001 -> No overflow or underflow. 2. Perform the following binary subtractions of 2's complement numbers. Express the final result in 8 bits and indicate whether UNDERFLOW or OVERFLOW occurred. a. %10110100 - %01001000 - 1 1 -> borrow 2 --------- %01001100 -> Underflow occurred! (-) minus (+) should not equal a (+) b. %00110100 - %01101011 - 11 1 11 -> borrow 2 --------- %11001001 -> No overflow or underflow. c. %10111100 - %11011010 - 11 1 -> borrow 2 --------- %11100010 -> No overflow or underflow. d. %00010111 - %11010111 - 11 -> borrow 2 --------- %01000000 -> No overflow or underflow. 3. Convert the following 8-bit 2's complement numbers to their negative equivalent a. %00010010 |||||||| vvvvvvvv %11101101 -> invert all bits. + 1 -> add 1. --------- %11101110 b. %01000101 = %10111011 c. %01111111 = %10000001 d. %00000000 |||||||| vvvvvvvv %11111111 + 1 --------- %00000000 -> Pretty cool hey! There is no negative zero in two's complement! 4. Convert the following 8-bit 2's complement numbers to their positive equivalent a. %10110110 |||||||| vvvvvvvv %01001001 + 1 --------- %01001010 b. %11001101 = %00110011 c. %11111111 = %00000001 d. %10000000 = %10000000 -> Note this is the one case that doesn't work because there is no way to show positive 128 in 8 bits using two's complement format. 5. Provide a description of what would constitute OVERFLOW and UNDERFLOW for addition and subtraction involving 16-bit (word) 2's-complement numbers. ANSWER: The number of bits used to represent a two's complement number determines the range of values that can be represented. For 8-bit numbers the range is from +127 to -128. For 16-bit numbers the range is from 32767 to -32768. Therefore overflow occurs in math with 16 bit numbers if the result of the operation is larger than 32767. Underflow occurs if the result is less than -32768.

Yes please. I am still working to understand the code. I am putting in a couple hours a day, but I need more time. How about extending to the 1st of Feb? I have attached my partial disassembly so others can play around with it. All The graphics data and colors are labeled. Cheers! venture.txt.gz

I weigh 227 pounds today.

That sounds reasonable. I haven't found where it tracks if you have completed a room yet or not. Maybe you could impose an order on all the rooms so that the player has to complete the rooms in a specific order. Only one room is unlocked at a time. If the locks are single bits in a byte, assuming %0000 means all rooms unlocked and %1111 means all rooms locked. Then, intialize to %1110. Then as each room is completed set the carry bit and perform a bit shift to lock the previous room and unlock the next. %1110 Room 1 unlocked %1101 Room 2 unlocked %1011 Room 3 unlocked %0111 Room 4 unlocked %1111 All rooms completed Yes, I haven't found that data yet either. I have found the data that tells the starting position for each sprite in each room. The positions are packed into single bytes. The upper nybble is the starting X position. The lower nybble is the starting Y position. You have to mulitply the X nybble by 10 to get the true value, and multiply the Y nybble by 5. The big rooms consume the a lot of ROM space in both data and code, so replacing them with other zoom-in rooms will free up considerable ROM space. (I hope). I smell a label contest...

OKay, I started looking over the code. It seems to me that an end screen hack is very doable. Its going to take some big changes. I am thinking of removing the 2 rooms where you are just a dot, and adding about 10 - 15 of the "zoomed-in" rooms. One of which code be an end screen. Walking out a door in a room leads directly to another zoomed room. I noticed you are using the trademarked Wolfenstein logo on your label mockup. Is that wise? I would hate to see the legal heads from id shutting down this project. Cheers!

Did you mean: 2+4+8+16+256+1024+32768 = 34068 decimal? Keep up the lessons! I'm stretching the left-side of my brain passed its limits now! Yes, Thanks for catching that. I will edit the original post.

Sorry it took me so long to post these answers. ANSWERS TO EXERCISES: 1. Convert 213 to binary 213 / 2 = 106 with a remainder of 1 ---------+ 106 / 2 = 53 with a remainder of 0 --------+| 53 / 2 = 26 with a remainder of 1 -------+|| 26 / 2 = 13 with a remainder of 0 ------+||| 13 / 2 = 6 with a remainder of 1 -----+|||| 6 / 2 = 3 with a remainder of 0 ----+||||| 3 / 2 = 1 with a remainder of 1 ---+|||||| 1 / 2 = 0 with a remainder of 1 --+||||||| %11010101 binary = 213 decimal. 2. Convert %00101100 to decimal %00101100 |||||||| |||||||+--- 0 * 2^0 = 0 * 1 = 0 ||||||+---- 0 * 2^1 = 0 * 2 = 0 |||||+----- 1 * 2^2 = 1 * 4 = 4 ||||+------ 1 * 2^3 = 1 * 8 = 8 |||+------- 0 * 2^4 = 0 * 16 = 0 ||+-------- 1 * 2^5 = 1 * 32 = 32 |+--------- 0 +---------- 0 0 + 0 + 4 + 8 + 0 + 32 + 0 + 0 = 44 decimal. 3. Convert 1087 to binary 1087 / 2 = 543 with a remainder of 1 543 / 2 = 270 with a remainder of 1 270 / 2 = 135 with a remainder of 0 135 / 2 = 67 with a remainder of 1 67 / 2 = 33 with a remainder of 1 33 / 2 = 16 with a remainder of 1 16 / 2 = 8 with a remainder of 0 8 / 2 = 4 with a remainder of 0 4 / 2 = 2 with a remainder of 0 2 / 2 = 1 with a remainder of 0 1 / 2 = 0 with a remainder of 1 So 1087 decimal = %10000111011 binary. 4. Convert %1000010100011110 to decimal | | | |||| | | | |||+---- 1 * 2^1 = 2 | | | ||+----- 1 * 2^2 = 4 | | | |+------ 1 * 2^3 = 8 | | | +------- 1 * 2^4 = 16 | | +----------- 1 * 2^8 = 256 | +------------- 1 * 2^10 = 1024 +------------------ 1 * 2^15 = 32768 2+4+8+16+256+1024+32768 = 34078 decimal 5. Using the list of binary numbers below: %00110101 %01000101 %11100001 %10100110 %01001011 %01001110 %11001001 Take the LSB from each of the above numbers, in order from top to bottom, to create a new binary number. The LSB from the first number in the list should be the LSB of the new number. The LSB of the last number in the list is the MSB of the new binary number. What is the new binary number? Now convert that number to decimal. answer: The LSB is the rightmost digit of each number, so the new binary number is: %1010111 which in decimal is: 64+0+16+0+4+2+1 = 87 6. For each of the numbers below, convert them to decimal twice. The first time assume that the numbers are in unsigned positive integer format. The second time assume that the numbers are in sign-magnitude format. a. %1000101 unsigned = 64 + 0 + 0 + 0 + 4 + 0 + 1 = 69 decimal signed = (-1) * (0 + 0 + 0 + 4 + 0 + 1 ) = -5 decimal b. %0101010 unsigned = 0 + 32 + 0 + 16 + 0 + 2 + 0 = 50 signed = (+1) * ( 32 + 0 + 16 + 0 + 2 + 0 ) = 50 c. %1100110 unsigned = 64 +32 + 0 + 0 + 4 + 2 + 0 = 102 signed = (-1) * ( 32 + 0 + 0 +4 +2 +0 ) = -38 d. %0000010 unsigned = 2 signed = 2 7. What is the range of positive unsigned integers that can be stored in a word. answer: There are two basic ways to solve this problem. I will demonstrate both because I think its important to see the relationships that make both methods arrive at the same answer. a. The first approach is to realize that smallest unsigned integer is always zero. The binary value is unsigned so no bits are needed to store the sign of the number. In that case the largest unsigned number is the value of the binary number with all bits set to 1. A word has 16 bits, so the biggest unsigned binary number in a word is %1111111111111111 If we convert that to decimal we get: 2^15 + 2^14 + 2^13 + 2^12 + 2^11 + 2^10 + 2^9 + 2^8 + 2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0 = 32768 + 16384 + 8192 + 4096 + 2048 + 1024 + 512 + 256 + 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 65535. b. The second approach is to recall the formula from lesson 2 to find the maximum number of items that you can enumerate given N bits. The binary number system is just an enumeration of the natural numbers. combinations = 2 ^ 16 = 65536 combinations. Recall however that the enumeration begins at 0, so that leaves 65536 - 1 = 65535 as the largest possible unsigned integer in a word. BONUS QUESTION 1: For each number a-d in problem 6, is each number signed or unsigned? (Hint: refer to lesson 1). answer: This is a trick question. The correct answer is both. As we learned in the first lesson bits represent whatever you the programmer say that they represent. They can represent both at the exact same time. It doesn't matter, they are only bits. Meaning is given by you the programmer with the logic of your code. BONUS Question 2: Is the sign-magnitude format an Enumeration (Lesson 2) or a code (Lesson3), and why? It is a code, because enumerations represent only positive values from 0 to N. I just thought of another valuable piece of information I forgot to include in this lesson. Please note that the LSB of a binary number indicates whether the number is odd or even. If the LSB is 1 then the number is odd. If the LSB is zero, then the number is even. In your code you may wish to take an action only on odd or even scanlines or frames. You will know if the scanline or frame is even or odd by examining the LSB of the scanline or frame counter.[/code]

Only 2 weeks!? Any chance you could give us a month? Cheers! Rob

QUICK TIP: The added buttons in the picture are from Radio shack. They are part number 275-1566A. I tried a different switch first, but that switch took too much force to be comfortable to play with. Cheers!