DanBoris

Ah, ok, I assumed you meant that the first circuit had two speeds, instead of two speed ups. I'll have to draw that one up. Dan

In the discussion of the ball horizontal control circuit, supercat proposed a simplified circuit that would perform the same function. This is the circuit I believe he is describing: starfire.zip It actually comes pretty close to working, and it does use less chips, but instead of generating 3 speeds it generates 4. The VSYNC input will make sure the circuit is only enabled for the first four lines on the screen. For each count on the hit counter the MOVE signal will be enabled for either 1,2,3 or 4 lines as follows: Count Move high on line(s) 0-3 2 4-7 1,2 8-11 2,3,4 12-15 1,2,3,4 I may still be possible to modify this further to get it to work exactly like the original Pong worked.

In this, what exatly are VC1 and VC2? temp1 = V1 nor V2 nor VC1 ; Low is good temp2 =/V2 nor VC2 Move = temp1 nor temp2 nor /VSync Dan

djmips, Yes, the number of horizontal lines when MOVE is high corresponds to the number of pixels the ball will move each frame. supercat, It's an interesting idea, although I haven't studied it carefully, I don't think it will work because it appears you will end up with MOVE being high for to many lines. Also you still can't get rid of the NOR and 3 NANDs right after the counter since you need these to decode the number of hits that correspond to each speed range. With that said, I do recall reading an interview with Al Alcorn at one point that said if he had to do the design again, he could probably do the same game with even fewer logic chips then the original design. Dan

You are right, I missed part 2 of the Ball Horizontal control.

As supercat observed in my last entry, I totally missed this part the first time around. Better late then never... _pesco_pacman_v8.zip For anyone who has played Pong, you may remember that the more times you volley the ball back and forth, the faster the ball will move. This counter counts those volleys. Each time the ball is hit by either player the counter will increment until it reaches a count of 12, at which point it will be disabled by NAND gate E1. The counter is reset by the RST SPEED signal which we will discuss at a later date There are three counter states that are decoded by the logic gates B1, E1 and H1.: Counter H1(11) H1(3) 0-3 0 0 4-11 0 1 12-15 1 1 At the beginning of each video frame these outputs are gated through two more NAND gates (H1) by the VRESET signal where they are applied to the clear inputs on J/K flip-flops H2. The flip-flips are clocked by the /256H at the start or each horizontal line. When the counter is in the range of 0-3, the MOVE signal will be high for one horizontal line, in the range 4-11, it will be high for two horizontal lines, and in the range of 12-15, three horizontal lines. The more lines the MOVE signal stays high for, the faster the ball will move. Let’s take a look at how this works for the 12-15 counter state. Initially after VRESET the Q output of both flip-flops will be low (due to the clear) which will result in MOVE being high. At the start of the next horizontal line when /256H goes high, since the J and K inputs of the first flip/flip are high, it will toggle setting it’s Q output high. The J and K inputs of the second flip/flop are both low so its state will not change. After the first clock pulse MOVE is still high. On the second clock pulse, the first flip-flip will toggle again, but since the J input of the second one is high, its output will go high. After the second clock pulse MOVE is still high. On the third clock pulse the first flip-flop will toggle again, settings its Q output high, and the second flip-flop will remain unchanged. Both inputs of NAND H4 are now high so its output goes low. The MOVE signal will now stay low until the next VRESET.

So the ball actually bounces off the left and right sides of the screen? That I wasn't expecting at all. Some video would definitly be helpful if it's not to hard for you to create. Thanks Dan

You also have to take into account the cost of recovering that gold, it may end up that the cost of recovering the gold is actually more then the gold itself is worth. Dan

Yes, VPOSxxx are taps off of the vertical ball counter. The 555 in necessary for the score sound since it's a much longer delay the could easily be generated with an existing counter signal. By using the counter in this circuit they saved themselves a chip and a couple discrete components (at least 2 caps and a resistor). The miss sound, which I haven't talked about yet, also uses one of the VPOS counters. I do wonder why they used the vertical position counter instead of the main vertical sync counter. The only reason I can think of is that they were already driving to many chips off the vertical sync counter. Dan

Does anyone know what and original Pong machine does during the attract mode? I have been trying to finish my analysis of the Pong schematics and the attract mode is turning out to be a little tricky. I know the net and score remain on the screen and the paddles are hidden, but I am not clear on what the ball does. I am not sure if it's hidden, or if continues to repeated serve. Dan

It's been a while since I did an update to my Pong circuit analysis, but I just get distracted by other project far to easily! The next section is the hit sound, the sound made when the ball is hit. _corrected_pesco_pacman_roms_v6a.zip When the ball hits either paddle the /HIT signal will go low which will clear C2 and set the /Q output high. For /HIT to go low VPOS256 has to be high, so there won’t be another positive edge on VPOS256 to clock the counter until the next frame. On the next positive edge of VPOS256 after HIT as gone high the sound will be turned off. I haven’t worked out the exact timing on this but it should only stay enabled for one or two frames. The /Q output enables NAND gate C3 and allow the VPOS16 signal to pass through to the sound output.

I actually started to work on an Action compiler for the PC written in C# but never got to far on it. I used the Gold Parser Generator to create the parser, but I really got stuck on the code generation side of things. I studied some of the machine code that the Action compiler generated and it's pretty amazing how optimized it's code generation was. For example it would put 0 in the Y register for one instruction, then a dozen instructions later it would need a 1 in the Y register so instead of loading 1 into Y it would increment Y which saves a couple bytes of memory and a couple machine cycles. Dan

If we could get some schematics for it (either from Curt of by circuit tracing), then it probably wouldn't be to hard to put together some software to test it. Dan

It also would have been cool if it was at the same time as CGE. Dan

One of the Robot Chicken episodes had a great Spy Hunter parody. It started with breaking news of a high speed police chase, and when the cut to the video it's Spy Hunter. Very funny bit. Dan

I always thought the Sega Star Trek sit down was pretty cool because it had the controls on the arms instead of in front of you. http://www.klov.com/game_detail.php?letter...mp;game_id=9770 Dan

The dlend table is used to store the index of the next available spot in each DL where you can write a DL entry. The piece of code below simple resets all these indexes to 0. When I write to a DL entry this index is added to the starting address of the DL to get the address to write the entry into. Dan

You shouldn't need any kind of inverter since the 5200 used active low chip enables which is what most EPROMs use. Dan

As far as I know, no one has done a disassembly of Mario Bros. Dan

The IRQ is NOT wired up on the Pokey cartridges, but since there is an IRQ pin on the cartridge connector, it would be pretty easy to wire the Pokey IRQ pin to the cartridge pin. Dan

Yes, untangling the GOTOs in the basic program would probably be the hardest part of the conversion. In some cases the GOTOs could be so tangled up that you would have to manually re-structure the program to get it into the more structured Action language. Dan I would say 80% of this project is easy, but the remaining 20% can be very hard to implement. Turning interpreted code into compiled code can be hard (calculated gotos, data lines etc) You might want to take a look on existing Basic to /Pascal/C/Java converter available in sourcecode on the Internet (Google). Carsten

I refurbished that style Space Invaders II recently, and I can tell you that the PS is definitly missing from this one. It should be in the space between the monitor and the isolation transformer. Dan

Yes, you would get a little audio glitch once per frame, but it probably isn't too noticable, and using 32V saved them from having to add more chips just to generate pure tones for the audio. All the audio circuits in Pong get thier frequencies from counters that are already used for other things. Dan

The next couple of circuits are used to generate the sounds for the game. The first sound circuit is for the score sound. This sound is played whenever either player misses the ball. When a player misses the ball the /MISS signal will go low which will trigger the 555 timer G4. When triggered the output of G4 will go high and stay high for 242ms at which point the output will return low. When the output of the timer is high the 32V signal will be allowed to pass through NAND C3 to the sound output. 32V comes from the vertical counter and has a constant frequency of 213Hz.

At the most fundemental level you could say that the display list on the 7800 and the A8 do the same thing, they both define to the graphics chip how to generate the display, but the exact details of how this happens are quite different. For example as you point out the A8 doesn't use the display list to control sprites, but on the 7800 all graphics are generated via the display list. The display list on the 7800 is also a lot more flexible and gives a lot more control over how the screen is drawn. Dan