Jump to content

Robert M

Members
  • Content Count

    1,532
  • Joined

  • Last visited

Community Reputation

21 Excellent

About Robert M

  • Rank
    Stargunner
  • Birthday 06/13/1969

Contact / Social Media

Profile Information

  • Custom Status
    Rootbeer!
  • Gender
    Male
  • Location
    Western NY state
  1. Yes, you can extend the sprite to any height at the bottom pole as long as you stop the skewing action. If you skew the sprite one pixel at a time rather than 2 you can get a pole 7 pixels high, but the railing angle is much steeper.
  2. If you are willing to accept that the railing pole (at least on top) is only 3 pixels high, then you can draw the whole rail and suppport poles by skewing the P1 sprite. The sprite starts on the left and moves 2 pixels to the right each line: 01234567 XXXX X XX X XX X XX 01234567XX XX XX Then of course the sprite image data is skewed to make the support pole straight: %00001111 %00001011 %00100011 %10000011 %00000011 .. repeat this line for the height of the railing %00001000 %00100000 %10000000
  3. I remember long ago on the stella mailing list someone posted a table that showed what will happen if you hit HMOVE at any of the 76 cycles, for all possible inputs -7 to +8. I believe that is how we rediscovered the HMOVE timings that do not generate the 16 blank color clocks on the left edge of the screen. I can't find that post now. It was a good bit of TIA research. Edit: Here it is... http://www.biglist.com/lists/stella/archives/199804/msg00198.html
  4. Here is the text from the manual: T'was the night before Christmas and all through Santa's warehouse, just about everything was stirring except one tired elf... Jolly Holly the elf sighed. The Big Cheese was away on his flight, the warehouse was locked up and the big return party was going to start in 10 min. What a year! The elf magic to make the toys load themselves in the sleigh went haywire sending toys flying around the warehouse knocking down elves. The elevators went nuts too, and won't stop running. Holly could hear them banging around in the warehouse. "I'll deal with that tomorrow.", she promised herself. Suddenly Ralph elf burst into the office panic stricken. "Mrs. Claus is on one of her rampages again!", he yelled. "Oh no!" whimpered Holly, "What now?". Mrs Claus and her inferiority complex. She can't stand being relegated to baking cookies and smiling in a grandmotherly way. "She says the party decorations aren't good enough. Here is a list of what she wants added.", squeaked Ralph as he handed Holly the list. Holly eyed the list. "Oh great! This stuff is all over the warehouse, and I just finished locking up.". OBJECTIVE Help Holly collect the 40 items demanded by Ms. Claus in time, or be demoted to cleaning out the stables. The warehouse has 8 rooms. In each room Holly must collect 5 items and a key, then get to the exit. Finish all 8 rooms in 8 minutes to win. GAMEPLAY Press RESET to begin a new game. The game will start when you move Holly. Use the joystick (in the left port) to control Holly. Pushing left and right will make Holly walk. Holding down the fire button while pushing left or right will make Holly dash. The energy bar at the bottom of the screen shows how much dash Holly has left. Each room of the warehouse has 7 floors. Holly must ride elevators to reach other floors. Hold the joystick up or down to get Holly onto an elevator as it reaches her floor. Once Holly is on an elevator, hold left or right to have her get off at the next floor. Pick up items by running over them. When everything is collected, a door appears. Touch the door to go to the next room. Picking up the key, or exiting a room restores Holly's dash energy. Each room has a different set of toys out of control. If a toy touches Holly, she will fall to the bottom floor and be stunned for 5 seconds. Some toys fire darts which can knock Holly down. The timer shows how much time Holly has left. The game ends when all the rooms are completed, or the timer expires. The remaining time is your final score. SELECT SWITCHES Use the difficulty switches to increase the challenge. Left Difficulty Switch: A = Holly drops the item collected on a floor if hit by a toy B = Holly never drops a collected item Right Difficulty Switch: A = Toys move 25% faster B = Toys move at normal speed Press Reset to start a new game. The timer will start as soon as you begin moving. Game Design by Lucy Mundschau, Rob Mundschau Programming by Rob Mundschau Graphics by Nathan Strum Written using Batari bBasic v1.0 by Fred Quimby
  5. I had a request for standalone ROM images for Elf Dash that was part of Stella's Stocking. So here they are. Happy Holidays! ElfDashNTSC_011308.bin.bin ElfDashPAL60_011308.bin.bin
  6. Okay, I am selling a Sega Master System lot. It has 33 games, the TV hook up, power supply, 3 controllers, the 3D glasses, and the light gun. All are in great shape. I just cleaned the 3 controllers and they are smooth and responsive. All 33 games are in the box. 27 of them have instructions. The other 6 are cartridge in box only. A couple boxes have catalog/posters in them. NOTE: The 3D glases and the especially the light gun require a CRT television to work. The light gun can not work with a LCD display. The 3D glasses might work with a LCD TV, but it depends how it buffers the frames. The image below shows what you will get. I am willing to answer any questions. This is all working great. I had a good time playtesting everything before offering it for sale. I am asking $179 shipped to anywhere in the U.S.. If a buyer wants to ship it out of the U.S. I will need to look into shipping and insurance costs I came up with the asking price by taking the CIB prices off rarityguide.com and averaged them with the last week eBay prices from videogames.pricecharting.com. I then divided that average price in half and added $20 for shipping. I am open to hearing offers. I am looking to sell the whole package together. If there are no overall takers I will be willing to sell it in parts. Thanks for looking.
  7. So I purchased a lot of Atari games, and it included an envelope with some warranty cards and a receipt. The interesting part (to me anyway) is that the buyer wrote the name of the game they purchased and the date it was bought on the warranty cards. Looking at the dates you can see the purchase history for a single Atari game shopper circa 1980. Feb 2nd, 1980 ( Groundhog day sale?) - Atari System - Combat - Video Olympics Feb 9th, 1980 ( one week later) - Air Sea Battle June 18th, 1980 - Breakout (price was $16.99), and Pam bought it so does that mean someone else bought the other games? Oct 25th, 1980 - Home Run December 23rd, 1980 - Street Racer (Merry Xmas!) - Not a fun game in my opinion. Maybe it soured the buyer against buying more games?
  8. That's a good mystery. Are you willing to post the entire list file, or the original asm file generated by the batari Basic compiler?
  9. Its hard to say. Try this: When you compile your code add this option '-lmylisting.lst' . That's a lowercase L after the dash. DASM will produce a list file that has all the compiler information. Find the message in that listing file and you may more clearly see what is causing it.
  10. I have been thinking about developing a script driven sound driver for the VCS. My thoughts are outlined below. I thought it would be good to get some feedback on what I have in mind before implementing it: Script Driven Sound Driver for VCS: =================================== This document outlines a proposal for a scripting language for the VCS that will enable simpliciation of the programming of the sound features of the TIA. PROS: ----- - Scripts can be shared. - Development of sound can be more easily handed off to another team member. - No need to write a new sound driver for a game. CONS: ---- - Interpreting scripts is fairly time intensive. Each script command will take between 40 and 60 cycles to complete. That said, sound generation requires few commands, and large calculations can be spread over several TV frames. In general I expect a program will need to commit between 3 to 5 scanlines of processor time for each TIA Audio channel every TV frame. - ROM and RAM usage will not be optimal. This only matters if you are a trying for a minimum size game. With bankswitching and other recent ROM and RAM expansion modes this is no longer a real issue. PROGRAMMER'S MODEL: ==================== The TIA has two audio channels numbered 0 and 1. Each audio channel has three write-only registers: AUDVx = Channel volume 0 to 15 (0 == min/off, 15 == max) AUDFx = Channel frequency 0 to 31 (0 = highest, 31 = lowest) AUDCx = Channel Waveform 0 to 15 (Documented elsewhere) Since the TIA registers are write-only, we need RAM available for scripts to perform calculations and keep track of state, such as loop counters. For each TIA audio channel we will add up to 8 virtual read/write registers of 8-bits each. The registers are numbered 0 through 7. A good script will use as few virtual registers as possible to conserve RAM. In addition to these registers, each Audio channel driver requires a two byte pointer in RAM (script_pointer) that points to the next byte in the current script, and a second two byte pointer of temporary RAM (temp_pointer) is needed while the driver is actively executing script commands during a TV update. During the rest of the TV frame temp_pointer RAM is free to hold other values. Both of these pointers and the eight virtual registers will need to be in zero page RAM. Note: If you use scripts that require less than 8 virtual registers, then your program need not allocate RAM for the unused registers, and that RAM may be used for other purposes SCRIPT LANGUAGE INSTRUCTION SET: (Proposed) ================================ For the instruction parameters below: <dest-all> = AUDCx, AUDVx, AUDFx, REG[0-7] <dest> = REG[0-7] <src> = REG[0-7] <reg> = REG[0-7] <value> = An immediate 8-bit value. INSTRUCTION: QUICK DESCRIPTION: ------------ ------------------ DONE ; Completed processing for current TV frame. ; Whatever values are in the TIA Audio registers ; are set for the current TV frame. Processing ; continues at the next script instruction on the ; following TV frame. DURD <reg> ; Decrement <reg>, if (<reg> != 0) then end ; script processing as if the instruction was DONE, ; and repeat this instruction next frame. ; Else, processing proceeds to next instruction. ; Use this instruction to play a fixed note for a ; duration. MOVR <dest-all>, <src> ; Put the value of register <src>, or the MOVI <dest-all>, <value> ; immediate <value> into the register <dest> ADDR <dest>, <src> ; Add the value of register <src>, or the ADDI <dest>, <value> ; immediate <value> to <dest-reg> and store the ; result in <dest>. XORR <dest>, <src> ; Perform a bitwise exclusive-OR of the value in XORI <dest>, <value> ; register <src>, or the immediate <value> with ; the contest of register <dest> and store the ; result in <dest> ANDR <dest>, <src> ; Perform a bitwise AND of the value stored in ANDI <dest>, <value> ; register <src>, or the immediate <value> with ; the contest of register <dest> and store the ; result in <dest> TRUNC <AUDVx|AUDFx>,<src> ; Truncate the value in <src> and write it to the ; TIA volume or frequency register. The value in ; <src> is treated as a fixed point value allowing ; fractional volume and frequencies: ; AUDVx => <src> is 4.4 fixed point value. ; AUDFx => <src> is 5.3 fixed point value. ; | | ; | +-> Fraction part is ignored ; +---> Integer part written to ; the register. DIV2 <reg> ; Divide the value in <reg> by 2, and discard any ; fractional portion. { bitwise shift right one } GO <label-in-bank> ; Jump to the given address in the script. ; {MUST BE IN THE SAME MEMORY BANK!} ONGO <index-reg> ; Use the value in <index-reg> to select a 'GO' GO <index0-label> ; instruction from the following list. No bounds GO <index1-label> ; checking is done, so be sure you won't go off GO <index2-label> ; the end of the list GO <indexN-label> LKUP <dest>, <table-label>, <index-reg> ; This is a table lookup instruction. The value in ; Given: <table-label> = pointer to table in bank. ; <index-reg> = register 0 to 7 ; <dest> = value at [<table-label> + <index-reg>] DECT <reg> ; Decrement <reg>, if <reg> is zero skip the next ; instruction. Used to build loops by having a ; GO instruction next. ZERT <reg> ; If <reg> is zero skip the next instruction. ; Used to build loops by having a GO instruction ; next. CMPR <reg>, <reg> ; Compare a register against another or an CMPI <reg>, <value> ; immediate value. If <true?> then skip the next ; instruction.
  11. Okay, so somebody reminded me I never finished my assembly language programming courses. Here is the next one after a five year hiatus. My bad Assembly Language Programming Lesson 7 - State Machines: ========================== Written by Robert Mundschau in May 2011. ----- The last topic we must cover before we can discuss programming the 6507 with assembly langauge is state machines. You need to understand state machines, because the 6507 microprocessor is a state machine. when you understand the rules for state machines, assembly language programming (all programming really) will make more sense. At the root, state machines are abstract mathematical constructs. What is special about state machines is that they can be implemented as real mechanical or electronic machines. We will show that a state machine can impose a set of logical control or rules onto a system. This control makes the real-world device predictable and useful. A state machine is a list of states, a list of possible inputs, and a matrix of next states for each current-state/input combination. For a really simple real world example consider an electric light connected to and on/off switch. In our imaginary perfect world we can simplfy the state machine to the following: SIMPLE LIGHT SWITCH: -------------------- Lists of States: ( LIGHT_ON , LIGHT_OFF ) List of Inputs: ( SWITCH_UP, SWITCH_DOWN ) Table of Transitions: | Input: current state: | SWITCH_UP | SWITCH_DOWN +-------------+------------- LIGHT_ON | LIGHT_ON | LIGHT_OFF <<== The cells of the table ------+-------------+------------- contain the next state. LIGHT_OFF | LIGHT_ON | LIGHT_OFF To understand this state machine, consider you have the current state of LIGHT_ON or LIGHT_OFF, and given an input of SWITCH_UP or SWITCH_DOWN you find the cell in the matrix that corresponds to the combination of the two. The contents of the matching cell in the table is the new state of the machine following the given input. All input to a state machine is processed one input at a time in the order the inputs happened. We wil tackle the problem of simultaneous inputs later, assume for now that can not happen. We have modeled a simple light switch. We ignored real-world details to simplify the model down to its bare essentials. We assumed a perfect electrical supply to the system, and don't worry whether the bulb could burn out. An infinite number of inputs exist to any real-world system. As a programmer you will need to learn to elimnate inputs you don't need to worry about in your design. Or which will be handled elsewhere in the system. Hitting an atari with a baseball bat is an input to the system, but I doubt you will bother trying to write any code to deal with that potential input. A broken joystick reporting both left and right directions at the same time, however, is a very real input to consider. Will the state machine of your game program handle that input? Does it need to? As a programer you need to consider all reasonable inputs or your game may act glitchy or provide cheats to the player you never intended. Using state machines in your game design is a useful way to control player interaction with the system. When you see video game glitches it can be because an input/state combination occurred that the programmer did not account for in their design and implementaion. ----- Now lets examine a slightly more complex and useful state machine. Imagine a simple gumball vending machine. The machine will only take pennies. The machine has a vend button, and has the ability to detect when it is empty. If a user inserts a penny and presses the vend button, the machine will vend one gumball. If the user inserts a second penny, the first penny is returned. Any penny inserted while the machine is empty will be returned. Using these simple requirements we can generate the state machine design below. PENNY GUMBALL MACHINE: ---------------------- List of States: ( {starting state}WAITING, READY_TO_VEND, EMPTY ) List of Inputs: ( PENNY, VEND_BUTTON, EMPTY_SIGNAL ) Table of Transitions: | Input: Current State: | PENNY | VEND_BUTTON | EMPTY_SIGNAL | +-----------------+---------------+--------------+ WAITING |READY_TO_VEND | WAITING | EMPTY | < next state exit action | none | none | none | < extra work --------------+-----------------+---------------+--------------+ READY_TO_VEND |READY_TO_VEND | WAITING | EMPTY | exit action | return penny | vend gumball | return penny | --------------+-----------------+---------------+--------------+ EMPTY |EMPTY | EMPTY | EMPTY | exit action | return penny | none | none | There are three big differences between this state machine and the first state machine we looked at: 1. It has more states and inputs than the first example. A state machine can have any number of states and inputs, and they do not have to be the same number of each. 2. In the list of states I marked the WAITING state at the {starting state}, which means the state machine is in the WAITING state when it starts running. If you don't specify a starting state for your state machine, it can start in any state which may cause unwanted behavior. For the light switch example the starting state didn't matter. 3. In the cells of the state transition table I added an exit action to be performed before transitioning to the new state. The addition of actions changes the state machine into something useful. Our design has three possible exit actions which we could add to the design as a list like this: List of Exit Actions: ( none, return penny, vend gumball). To operate this state machine, when an input arrives the following happens: 1. Lookup the the transition table entry corresponding to the current state and the input. 2. Perform the exit action in that table entry. 3. Change the current state to the next state in that table entry. Using this algorithm the exit actions represent real world interactions with the user. The underlying state machine acts as the controller to limit the interactions with the user to the correct order. The user must insert a penny and then press the vend button to receive a gumball. Pressing vend and then inserting a penny will not yield a gumball. The Penny Gumball Machine example uses exit action items to join the logical control aspects of an state machine to real world interactions with the user. You can imagine that the actions "return penny" and "vend gumball" are implemented with a mechanism activated by the mechanical or electronic device that implements the state machine logic. Hopefully, it is clear now why state machines are so useful. ---- You can tie actions to more than just the exit from a given state. There are three distinct places to attach actions to a state machine: 1. Exit Action - Performed on exiting the current state. (as above) 2. Transition Action - On the specific transition from current state to the next state. 3. Enter Action - On entering the next state. Any combination of the 3 actions can happen when the state machine processes an input. The listed order is the same order the actions will be taken during input processing. First, the Exit Action is performed. Second, the Transition Action is performed. The state is changed to the new state, and lastly the Enter Action for the new state is performed. Hopefully, the operation of the Exit Action and Enter Action are clear, but the Transition Action may be harder to grasp at first. A transition action can be different for every combination of current and next states that can be made from the List of States. We can show all the combinations of current and next states as a 2-dimensional matrix with the current state on the rows and the next state on the columns. The cells of the matrix hold the Transition Action. Below is an example of the Transition Action Table for the Simple Gumball Machine. Imagine we delete the Exit Actions in the original design and replace them with these Transistion Actions. Table of Transition Actions: | Next State: Current State: | WAITING | READY_TO_VEND | EMPTY | +---------------+---------------+--------------+ WAITING | none | none | none | <= Actions --------------+---------------+---------------+--------------+ NOT READY_TO_VEND | vend gumball | refund penny | refund penny | States! --------------+---------------+---------------+--------------+ EMPTY | none | none | none | This alternate approach is almost identical to the original design. It does not handle the case, however, where the user inserts a penny into an empty machine. Using this alternate approach that case would result in the user losing their penny. Do not take from this limited example that exit actions are somehow superior to transition actions or entry actions. Each kind of action serves a different purpose and can be equally useful. Often state machines will use a fairly complex combination of the different kinds of actions to model complex behavior with a relatively simple design. ---- At the start of the lesson I indicated that the 6507 microprocessor is a state machine, and we will examine that state machine in detail next lesson. Right now it is important to recognize that as a programmer you can use state machines to help you writing your game code. You can use state machines in your code to simplify your work. Try to break your game into its actors and see if the state machine paradigm can be applied to them. Once we start looking at real code, we will return to state machines to see how they are really implemented. State machines can be nested and interact with each other. For example, an given action may be to generate an input to one or more other state machines. Or a state machine may only be allowed to process input when another state machine is in the correct state. When applying the state machine paradigm to a game element try to map states to a high level framework of control. For example, you probably don't want a separate state for an object moving in each possible direction if the constraints for motion are the same in all directions. Rather, a single state of IN_MOTION combined with some other infomration about direction and speed stored elsewhere will yield a cleaner design. Let's take a look at an example state machine for an existing video game object. Consider the "square" hero from the Atari game Adventure, and how we might describe the state machine that limits the user's control of this character in the game. List of States: OFF: This is the starting state at the game select screen. ACTIVE: The hero is free to move. DEAD: The hero is in the stomach of an dragon. WINNER: The player has won the game. No more motion allowed. List of Inputs: SELECT: The player pressed the select switch. RESET: The player pressed the reset switch. CHOMP: A dragon has swallowed the player. VICTORY: The chalice is in the gold castle. State Transition Table Current | Input: State: | SELECT | RESET | CHOMP | VICTORY ----------+----------+----------+-----------+---------- OFF | OFF | ACTIVE | OFF {*} | OFF {*} ----------+----------+----------+-----------+---------- ACTIVE | OFF | ACTIVE | DEAD | WINNER ----------+----------+----------+-----------+---------- DEAD | OFF | ACTIVE | DEAD | WINNER{*} ----------+----------+----------+-----------+---------- WINNER | OFF | ACTIVE | WINNER{*} | WINNER{*} ----------+----------+----------+-----------+---------- The transistions marked with {*} should never occur. In the real game there is logic to prevent the player from being eaten after winning the game. Its helpful to consider these unexpected interactions in your game designs. Can you think of some actions to attach to this state machine? Clearly the RESET input should change the position of the hero in the game world. Can you imagine a state machine to handle the player carrying and dropping game objects? ---- As a last note, we have considered so far that only one input can happen at a time. In the real world it is possible for inputs to happen simultaneously. Or if not exactly at the same time, then within the time it takes for the state machine to come finish processing one input and getting a chance to process another input. For example, the user can press the select and reset switches at roughly the same time. As a programmer you must deal with simultaneous inputs in one of two main ways: 1. Assign a different priority to all inputs. The highest priority input is always handled first. Lower priority inputs are handled after, or ignored. 2. Create a new input that is a combination of multiple inputs. So if SELECT and RESET are pressed at the same time, the input to the system becomes SELECT_AND_RESET. This approach can cause the number of inputs to balloon exponentially if applied liberally. It can be really useful on a limited basis. ============================================================================ Exercises: ---------- 1. Generate a state machine for a light with two control switches. Changing the position of either switch will toggle the light on/off. Assume only one switch can change at any time. Provide the lists of states, inputs and transitions. 2. Add a "REFUND" input to the PENNY GUMBALL MACHINE specification above to let the user get their penny back. 3. BONUS CHALLENGE: Pick an element of an existing Atari VCS game and create a state machine for the behavior of the element.
  12. I'm back after a log hiatus from the board. I have been dabbling with an idea that as a community we need to stop reinventing the wheel in our code. I believe that it is possible to assemble a core framework or set of libraries if you will to assist in creating games for the Atari 2600. The goal is to compile a set of useful macros and routines into a package with documentation. Using this package, a programmer can get a project started very quickly. If necessary custom optimizations can be made later in the project. To that end, I have created some macros for bank-switching, and for indexed jumps. I will add more macros and routines as I complete them for my own projects, and others are welcome to contribute their ideas. Below is a list of the macros in the zipped package attached to this post. The attached zip file contains the ARPM files and an example program using some of the macros. ; Macros defined: ; --------------- ; From ARPM_BankSwitch.h: ; ----------------------- ; BS_START_BANK <bank_num> - Declare a new bank and insert common code. ; BS_END_BANK <bank_num> - End a bank image and report space remaining. ; ; JMB <label> - JuMp Bank switched. (Replaces JMP instruction) ; JSB <label> - Jump to Subroutine Bank switched (Replaces JSR) ; RTB <label> - ReTurn from subroutine Bank switched. (Replaces RTS) ; ; From ARPM_IndexedJump.h: ; ------------------------ ; JIT_START <table-name> - Start a new indexed-jump table. ; JIT_ENTRY <address-label> - Add a pointer to the table ; JIT_END <table-name> - Finalize the table into ROM. ; ; JIX <table-name> - Jump Indexed X (ON X GOTO <table-name>) ; JIY <table-name> - Jump Indexed Y (ON Y GOTO <table-name>) ; ; SIX <table-name> - Subroutine Indexed X (ON X GOSUB <table-name>) ; SIY <table-name> - Subroutine Indexed Y (ON Y GOSUB <table-name>) ; ;============================================================================= Future dream features: - A formal TV frame generating label that you can hang kernels off of. - A script driven sound FX and music engine. - Kernels - RAM bit field macros Cheers! Rob ARPM_v1.zip
  13. I sold Duallies a NES system and games. It was an A+ experience.
  14. I am looking to to sell off my meager NES collection. Everything is tested and working. The buyer shall receive: - 1 classic NES console. I replaced the 72 pin connector last year so it definitely does not suffer from the blinking screen problem. - 2 NES pad controllers - 2 Light gun controllers. - Power supply - 1 Component video cable. - 1 RF video adapter cable (Sega brand, but it works fine). Plus the following games: - The Adventure of Link (aka Zelda 2) - Super Mario Bros. 3 (with instructions) - Super Mario Bros./Duck Hunt (with instructions) - Teenage Mutant Ninja Turtles - Crystal Mines (With instructions, the prequel to Crystal Mines 2 on the Lynx) - Mappy Land (with instructions) - Quattro Pro - 4 games in one (Boomerang Kid, Super Robin Hood, Treasure Island Dizzy, Linus Spacehead) - Loopz I am asking $34 shipped within the united states, or make me an offer. Cheers!
  15. I know this is not video game related, but I thought I would offer to sell here first. I have a large (~2500 points) Dark Eldar Army for the tabletop game Warhammer 40K. It is mostly painted. I am looking to sell it at a very reasonable price. If there is any interest I will post more details + photos and an asking price. Cheers!
×
×
  • Create New...