Kurt_Woloch

Here are my times for this week (July 16th through 22nd) on modern systems: PC: Serpentine (Remake) - 27 min. The only modern game I played this week is a remake of "Serpentine" which I've also tried on the Atari 7800. It's pretty slow and cuts some corners compared to most other ports. Most notably when you die the death is not shown, rather the screen clears instantly and the next life begins. Also the "home" of the player snakes is laid out differently, only showing the player snake, but not the spare snakes. Those are shown in a box to the left of the playfield instead. The game actually seems to be a bit harder than the original version although the enemies actually seem to be less agressive towards the player.

Here are my times for this week (July 16th through 22nd) on classic systems: Arcade: Burger TIme - 3 min. Crush Roller - 51 min. Faster Harder More Challenging Q*Bert - 5 min. Mario Bros. - 22 min. Mr. TNT - 3 min. Ms. Pac-Man - 18 min. Pooyan - 15 min. Turtles - 13 min. Atari 7800: Joust - 16 min. Mario Bros. - 23 min. Serpentine - 48 min. in 2 sessions Channel F: Pac-Man - 10 min. NES: Ice Climber - 7 min. This week I played quite a variety of games, replaying some classic games. After replaying the Atari 7800 version of Mario Bros., I also played the arcade original, where I reached the bonus round after Slipice appears and the iceicle rounds afterwards. Crush Roller is another sibling of Pac-Man which I don't remember having tried before. It has quite a few different game elements, though it runs on the same hardware. There are only two enemies, but they are rather aggressive, and there's a different way to defeat them... to crush them with a roller, but after you've done this a few times, they get smarter and try to avoid it... quite successfully. Looking at this and also Mr. TNT, which also runs on Pac-Man hardware, I come to the conclusions that other manufacturers didn't quite make it to make full use of Namco's hardware features, especially concerning sound. Mr. TNT only uses one timbre for all of the sound, and Crush Roller plays a somewhat cacophonic versoin of the Flea Waltz (as it's called in German). Apart from that I was quite successful in Pooyan, Turtles and Ms. Pac-Man. Another highlight this week was the Atari 7800 version of Serpentine which has been converted from the Atari 8-bit version. It plays about the same as the Atari 8-bit and the C-64 versions, only the colors and graphics are a little different (especially concerning the frog and eggs), and the sound is different as well.# Finally, Ice Climber was the pack-in of the NES when it was released here in 1987, and while it's not a "superhit game" as Donkey Kong is, it nicely showcases Nintendo's style which you can see in many of their games, at least the earlier ones, also including their arcade games.

Well, I think your TIA sound is great! I actually like it better than the sound of the released C-64 version because it's more varied. On the C-64, aside from the slithering of the snakes, you only hear blips and blops of various types, but in the same timbre. The SID definitely could have done better than that! The frog sound could have been replicated with a square wave with a narrow pulse width (e.g. $10 or so), but they didn't do that, they only used the triangle wave for everything. In fact I think they cut a few more corners on the C-64 version in order to keep the size under 16K because it should fit in a cartridge.

OK... one more thing I thought about concerning POKEY support... sorry if I'm offending anyone here, but I think for this game a POKEY on cartridge would be a wasted effort. I've noticed that with this game, the sound varies from version to version (much more so than the graphics), and there's not much more going on than some blips and short one-voice melodies (probably since the original version is coming from the Apple II). So with that level of sound, I think the TIA would be just fine. It doesn't matter if it sounds exactly the same as one of the other versions (i.e. the Atari 8-bit version it's derived from) or a bit differently, since in fact it's different in every version anyway, and since there's not much music in here either, it doesn't matter if it's a bit out of tune or played at a different pitch or in a different key. Just my 2 cents... In fact I wonder why the binary is 48K... I think the C-64 cartridge version is only 16K and still has all the 20 mazes of the original Apple II version. But of course on the C-64 they could decrunch quite a bit to the big 64K RAM which is always there while the 7800 doesn't have nearly that much...

Ah, OK, I see... I was assuming that the green snakes were red on the A8 version as well. I guess on the C-64 they do it the same way, but use the color RAM to color the green snakes green and the maze walls purple. So you're just keeping the character grid as on the A8 and C-64 (where it probably hasn't changed much as well) displaying it the 7800 way. That's why it looks and pretty much identical except for the frog and especially the eggs, which both use sprites on the C-64. You wouldn't necessarily need 160B mode, you could also display the green snakes separately, but that would probably also require a major overhaul since they are now just integrated with the character grid and displayed in another color on the A8 and C-64, but not as separate objects. Thanks for the explanation!

Sorry I'm reviving this and sorry for coming late to the party again, but I just saw this on a Youtube video and had to try it... it's pretty much perfect, seems to play pretty much the same as the C-64 version I'm used to (including the slowdowns!) with just a slight update to the graphics. One thing that could be improved though... on the Apple II and C-64 versions, snakes that are shorter than the player snake are displayed in green instead of red. Do you think you could do this on the Atari 800 as well? I think all it would take to do this is to draw those snakes with the frog's pallette... or isn't it as simple as that?

Here are my times for this past week (July 9th through 15th) on modern systems: Browser-based: Doodle Jump Online - 2 min. The only modern game I played this week was "Doodle Jump Online" which I played in order to compare it to the WIP "Amoeba Jump" on the Atari 2600.

Here are my times for this past week (July 9th through 15th) on classic systems: Arcade: Jr. Pac-Man - 132 min. in 4 sessions Pac'n'Pal - 38 min. Pacmania - 26 min. Atari 2600: Amoeba Jump - 132 min. in 4 sessions TI-99/4A: Munchman - 11 min. This week I played a healthy variety of games... I had an extended session on a new version of the WIP "Amoeba Jump" on the Atari 2600 where at 4000 points you enter a zone which consists of only white, breakable platforms and no springs and lasts until 5000 points. At 7000 points another zone would start containing only blue, moving platforms, but I didn't manage to get that far into the game. Then after last week's run with Mouse Trap, this week, I replayed several Pac-Man variants, most of all "Jr. Pac-Man" in its original version, but also Pac'n'Pal, Pacmania and, last but not least, Munchman on the TI-99/4A. This brings up memories because it was one of the three games we bought with the TI-99 which was my first home computer. Somehow TI put its unique style into each of its game, even if they were arcade ports. Like in TI Invaders, here in each wave you encounter new enemies, and some of them look like the saucers in "Parsec". It seemed to me a bit like TI had its standard shapes which they inserted in every game they fit in, so you ended up playing Munch Man against the same enemies as TI Invaders. And as in TI Invaders, here you get an extra life every 10,000 points, but it's much easier to rack them up here. And "Pac'n'Pal" also contains cameos of characters out of other Namco games like Galaxian, Galaga and Rally-X. In Pac'n'Pal I tried to reach the score of 70,000 points at which the 2nd extra life would be given, but didn't get as far. In Pacmania, it occured to me that you can't corner as in other Pac-Man games, which makes the game harder, as well as the limited field of view.

So what is it you mean? Can we help you with it or do you have to find your way yourself?

How to start it? I guess one good first step would be to make the ball move... I took a deep look into Atari 7800 programming in the meantime, and I guess that right now you only have the ball in one zone, so you could start by making it so that the ball is able to move into any scanline it could possibly go to and adjust the display lists correctly... then the next step could be to make it move by itself in a proper ballistic curve, starting at the bottom where the ball is shot out in the original game.

OK, now... there's one caveat in the code I gave which I didn't think of yesterday, which is with negative numbers. The code I gave above actually assumes that all factors are positive; if they are negative, the multiplication won't work correctly. But actually they can be negative... both the sin and cos values and the x/y speeds. Thus, sadly, the code I gave above doesn't always work correctly. To make it work correctly, you'd have to do the following: - If both factors are positive, you can add them up as described - If one factor is negative, you have to negate that one so that it becomes positive, negate any result to which the new result should be added up, then do the multiplication and then negate the result again. - If both factors are negative, you have to negate both factors and then do the multiplication with their positive counterparts. - For the "-sin(a2)" part, you have to negate the result afterwards if none or both factors are positive, but not negate it if one of them is positive and one negative. For the x and y velocities, you can assume they're negative if their high bit is set, and then adding them up between frames (without collision) will work the same regardless if positive or negative. However, the sin and cos values already use up the full range of one byte (for the fraction from 0 to 1), so if they're supposed to be negative, you have to note this elsewhere and then account for it. Yes, I know it gets even more complicated...

Well, if you've got your own snippets in Batari Basic for your own WIP, we could open a new thread for that one and continue the physics code discussion there.

Well, I was looking for a multiplication routine that might do what's necessary for the formulas given above, and I've found one... theoretically. The problem is that it doesn't quite work out, but anyway, look here: http://codebase64.org/doku.php?id=base:8bit_multiplication_16bit_product This multiplies the base numbers that are in my formula as well, one 8-bit number (actually 0.8 in my formula) and one 16-bit number (actually 8. . The trouble is, there can be overflows if the result exceeds 16 bit, and with my numbers it would because the result should be 24-bit treated as 8.16 in my formula (with the lower 8 bits stripped away to get 8.8 again). But I think I got the principle of the multiplication routine, so here I'll try to extend it to the format we need for my formulas: ;------------------------ ; 16bit * 8bit = 24bit multiply ; By White Flame, extended by Kurt Woloch ; Multiplies "factor8" by "factor16" and stores result in resultL, resultM and resultH ; In this version, both inputs must be unsigned ; We need the following 1-byte variables that are not declared here: ; Source values: factor8, factor16L, factor16H (do not get changed) ; Temp values: tempfactor8, tempfactor16L, tempfactor16M, tempfactor16H ; Result value: resultL, resultM, resultH ; initialisation, leave this out if there is a number the new product should be added to ; in this case that number should be stored in resultL, resultM and resultH lda #$00 sta resultL sta resultM sta resultH ; initialisation of temporary values for factors because those get shifted away keep_result: lda factor8 sta tempfactor8 lda factor16L sta tempfactor16L lda factor16H sta tempfactor16M lda #$00 sta tempfactor16H beq enterLoop doAdd: clc lda resultL adc tempfactor16L sta resultL lda resultM adc tempfactor16M sta resultM lda resultH adc tempfactor16H sta resultH loop: asl tempfactor16L rol tempfactor16M rol tempfactor16H enterLoop: lsr tempfactor8 bcs doAdd bne loop The way you would use this in my formulas is the following: Assuming you have the current ball speed in each direction (x and y) as an 8.8 number (8-bit pixel, 8-bit subpixel) and the computed sin and cos values as a 0.8 number (since they can only be 0 to 1). Then the 8.8 ball speed would be used as factor16, and the sin / cos values would be factor8. The result would be put back into the ball speed by making resultH the pixel and resultM the subpixel value with resultL being discarded. So since it gets discarded you can cut the sequence lda resultL / adc tempfactor16L / sta resultL, but doing so impacts the precision of resultM a bit (by up to 8 "ticks" or 1/32 pixels/frame) because adding up resultL also generates the carry which is added up to resultM. I hope this is halfway clear and usable... and I didn't make any coding mistakes. You could also use the registers X and Y instead of resultM and resultH as it's done in the original version (albeit a bit unclearly) which would speed up the code a bit, but you have to use those variables in the end, of course. To illustrate this, here's another code example how to call this. Let's assume we did the following: mul_16_8: <code above> rts Then we can call the subroutine as follows in order to calculate one of my formulas, let's say these ones: x'' = y * sin(a*2) - x * cos(a*2) y'' = x * sin(a*2) + y * cos(a*2) Let's assume we've stored the values as follows: xH... ball speed x in pixels xL... ball speed x in subpixels yH... ball speed y in pixels yL... ball speed y in subpixels sina2... sin(a*2) (fractional) (pre-computed) cosa2... cos(a*2) (fractional) (pre-computed) Now we first calculate the part x * cos(a*2): lda cosa2 sta factor8 lda xL sta factor16L lda xH sta factor16H jsr mul_16_8 Now we have the term x * cos(a*2) in the variables resultL, resultM and resultH. In order to subtract this from the next term, we have to negate them: lda resultL eor #FF sta resultL lda resultM eor #FF sta resultM lda resultH eor #FF sta resultH Now we add the term y * sin(a*2) to the result. To do this, we enter the multiplication routine at the entry point where the result doesn't get cleared: lda sina2 sta factor8 lda yL sta factor16L lda yH sta factor16H jsr keep_result Now we have completed calculating the new x value, but we can't store it away yet because we have to use the ORIGINAL x value to calculate the new y value, so we'll temporarily use the X and Y registers to store them (since the multiplication routine doesn't use X and Y): ldx resultM ldy resultH Now we add up the new Y value according to the formula above the same way, but this time we don't have a negative term, so we don't have to do the negation part, and the code for doing this gets reduced to: lda cosa2 sta factor8 lda yL sta factor16L lda yH sta factor16H jsr mul_16_8 lda sina2 sta factor8 lda xL sta factor16L lda xH sta factor16H jsr keep_result Now we just need to store the new direction values in the ball direction variables: stx xL sty xH lda resultM sta yL lda resultH sta yH Note that if we always use the multiplication this way, there are some things that could be optimized... for instance, we could store yL, yH, xL, xH, sina2 and cosa2 in the temporary factor variables instead of the non-temporary ones because we still have got them in their original variables where they don't get discarded by the multiplication routine.

Yes, there is, but as far as I've seen, it only supports multiplication of two 8-bit variables, giving a 16-bit result, so 8.0 * 8.0 = 16.0. What we'd need for my formulas is 8.8 * 0.8 = 8.8 and 8.8 + 8.8 = 8.8 routines. You could maybe get around that by limiting the motion to 16 pixels per frame (so essentially 4.4), then you have one byte that you can multiply with that 0.8 (converted to a 8.0) giving a 16-bit result (16.0) which would actually be 12.4 and should then be converted back to 4.12 (out of which the lower 4 or 8 bits could be discarded). I don't have experience with the different kernels available because I've never programmed in Bb.

In which way could I help? What exactly are you trying to do? I've gone through the instruction set of Batari Basic a bit, and unfortunately, it's not easy doing this in Batari Basic since while it does support 8.8 variable types, it doesn't support a multiplication between them, which is what we'd need for the calculations I gave above. So you'd probably have to insert those as an ASM section.

Here are my times on modern games for this past week (July 2nd through 8th)... Browser based (Kongregate): William and Sly 2 - 84 min. The only modern game I played this week is "William and Sly 2". It's a 2D platformer with gorgeous graphics where you guide a fox through a maze of platforms in a somewhat magical setting. You can pray at 3 shrines which gives you magical powers given the necessary prerequisites, or collect mushrooms and keys to open boxes, or collect bombs in order to break up stones unveiling runes which act as teleporters after you manage to insert some elements on the top of 4 statues in the right order. All in all it's a pretty good, smooth game with photorealistic graphics.

Here are my times on classic games for this past week (July 2nd through 8th)... Arcade: Pooyan - 8 min. Mouse Trap - 257 min. Venture - 32 min. Atari 2600: Mouse Trap - 6 min. Venture - 8 min. Colecovision: Mouse Trap - 31 min. Venture - 120 min. Intellivision: Mouse Trap - 47 min. VIC-20: Pooyan - 16 min. This week started out by discovering a VIC-20 homebrew port of Pooyan. I think it's about as good as the Datasoft version, but suffers a bit from the fact that all the objects are pretty big compared to the screen size, so it's hard to dodge enemy fire. After that, I attempted to play multiple versions of the Exidy arcade games "Mouse Trap" and "Venture" whose home versions were done by Coleco. With "Mouse Trap", I remember I rolled the Colecovision version some years ago. This time I started with the arcade original which plays fairly smoothly, but gets very fast after a few levels. I managed to reach about 150,000 points on it though. The Colecovision version is not bad either, but never gets as fast as the arcade version. On the Atari 2600, as usual for Coleco, they left out more game elements than would have to be necessary... there are no eagles, no teleporters, no bonus items and no music and only one set of doors, making the game pretty simple. The Intellivision version is much better, but suffers from an annoying music. Also, the eagle usually flies directly towards the player, making it hard to avoid it. With Venture, it's a similar thing... I didn't get very far on the Arcade original, but managed to clear Level 9 on the Colecovision, just to have Level 9 repeat again (not even the set of Level 7 through 9 which would make it more consistent). The Atari 2600 version looks fairly good, but again they left out more elements than necessary... the enemies aren't animated, you only get 200 points for the treasure, but none for shooting enemies and completing a level, and there are only 2 instead of 3 distinct levels. There's no music on here as well.

Well, the sound effects being played in the arcade original of Baby Pac-Man (except for the music) are only playing one at a time... on the video part it's either the siren or the gobbling sound, but not both at once, and in the pin part you also only hear one effect at once, thus the effects could be coded so that each one takes up both channels since they're not supposed to be playing two at a time anyway.

I've also played Level 2 of Pitfall II; and I've refined a map I found online, so I thought I'd post it here. What I've done is to add some paths you can go in order to collect all that's collectable. One difficulty of Level 2 is that there are some paths that cross each other, but you can't get from a platform to a ladder it crosses and vice-versa. The way I've expressed this is by using different colors for the paths, and I've only included the paths that make sense to go. I've divided the maze in zones so that if two paths cross this way, they are of different color, whereas paths that lead to each other basically have the same color. OK, they do have to change color eventually, but... I also tried to make each red cross the center of a zone with each cross having a zone in a different color. Since there are actually only a few ways into and out of each zone, it makes sense to finish the zones one after another. You start in the green zone, then you'd want to do the purple one, tackling the red one in between, but the red one is special in that it's actually impossible to get into it without hurting the player (other than with the trick mentioned above), but there's one spot where you can safely leave it and go back to the purple one.The next one would be the blue zone, followed by the yellow, green and dark red zones. From there you can only go back to the green, yellow and blue zone which leads into the orange and finally the pink one. I hope this makes it a bit easier and clearer.

Here are my times for this past week (June 25th through July 1st)... Browser Based: Doodle Jump Online - 3 min. The only modern game I played this week is a browser version of the phone app "Doodle Jump" in order to compare it to the Atari 2600 demakes "Poodle Jump" and "Amoeba Jump" and also in order to record the sounds (and convert them for a possible further demake to a different system).

Here are my times on classic games for this past week (June 25th through July 1st)... Arcade: A.P.B. (All Points Bulletin) - 90 Atari 2600: Amoeba Jump (WIP) - 11 min. Frostbite - 15 min. Poodle Jump (WIP) - 11 min. Seaquest - 25 min. Zaxxon - 9 min. Atari 7800: Baby Pac-Man (WIP) - 105 min., in 4 sessions Spirit of the ancients - 2 min. Commodore 64: David's Midnight Magic - 83 min. in 2 sessions David's Midnight Magic II - 25 min. Moonwalker - 52 min. This week I'Ve played quite an assortment of different games. I played the latest build of Baby Pac-Man on the Atari 7800 which now features colored mazes, and, inspired by that I replayed the C-64 classic David's Midnight Magic as well as its sequel which actually is a hack of the original version with improved graphics and music. Then I tried the C-64 version of Moonwalker. The home computer versions have been made by U.S. Gold and are very different from Sega's version for its consoles and its arcade machine. In the home computer versions, the first two levels are large scrolling overhead mazes where you have to pick up various objects shown on a map while avoiding enemy robots. The 2nd level is structured a bit differently, however, since after clearing the first part of the maze, you transform into a car and then quickly have to pass over to the next part of the maze, but if you fail to do that, you lose a life and have to start over. I find this game more frustrating than Sega's version, and even though the programmers claim in an interview that they put out the best they could do, it still doesn't quite feel like an exiting and challenging game. What doesn't help is that the game is a multi-loader tape, and if you fail at Level 2, you have to rewind the tape and pretty much restart the loading process, waiting a few minutes for the game to restart. Also, while they programmers claim they were required to put in "all of the music", in fact they only play snippets of Michael Jackson's songs. Then I replayed the original version of A.P.B. getting pretty far using continues, but there's a point I can't pass, I think it's Day 12 or so. On the Atari 2600, I replayed Coleco's Zaxxon and Activision's Seaquest (after I managed to remember its name) and Frostbite. And then I looked at some WIP's from this site... Spirit of the ancients on the Atari 7800 is inspired by Dungeon Master, but I couldn't quite find out what to do. And then there are "Poodle Jump" and "Amoeba Jump" which are both derived from the phone app "Doodle Jump" and, as simplicistic as they are, I actually wonder why this seems to be the first "demake" of this game since a similar version could also run on the Channel F or Odyssey^2 systems.

Great game here! In fact, I think this demake could be done on some other old systems as well... the blocky score digits remind me of the Channel F; and the sounds remind me of the Odyssey^2, and I think the game should be doable on both of those systems. On the Channel F, it might get a decent framerate because most of the objects are just 1-pixel high strips (and it doesn't have too many colors as well), and the Odyssey^2 actually should be able to display the platforms as sprites (similar to its Q*bert version) which are actually part of the "block" object, and the 4 redefinable sprites would cover the player and a spring. The only tricky thing here is that there are more than 12 platforms on screen at once, so you may have to multiplex the sprites (which happens in Q*bert as well) or use quad characters.

OK, I see... so S is the same thing as (IS). I thought it was referring to the status register. But no, that one is actually called W on the F8. In my code I currently use the terms (IS), (IS)+ and (IS)-, which seem to work the same way as S, I and D, or as (IS), (IS++) and (IS--)... at least DASM understands them that way. That's the way the mnemonics have been written in the VIdeobrain disassemblies which I studied when I first tried to code for the F8 processor. I'm usually careful with registers 0-15 since some of them have other nicknames and secondary functions... I'm generally only using registers 0 through 10 in a direct way since registers 11 through 15 have other functions as well... registers 10 and 11 together form register H, and registers 14 and 15 together form register Q, both of which can be used to manipulate memory pointers. And I do use Q in this way to access tables. Also, registers 12 and 13 form K which is used to store the return addresses of subroutine calls. This is probably overcautious, if not using H and K I could go up to R13. As for the LI - COM - INC chain, it's not only about saving time, but also about saving code bytes since doing a LI with the final value only takes 2 bytes. Depending on what you try to do, I admit it may be hard to read though... I saw a video on Youtube that claims that code is actually written to be readable by humans and only happens to be executed. So actually code is often written so that it's readable if the optimum size or execution time isn't achieved this way (happens at work all the time as well).

OK, here's another thing about the formulas I gave earlier... in them, I converted the ball movement into movement relative to the target and back to x/y using two turning matrices. But of course it's possible to roll those two into one matrix which will calculate the resulting speed values directly. To do this, you have to combine the formulas, so that: x'' = x * (-cos(a)^2 + sin(a)^2) + y * sin(a) * cos (a) * 2 y'' = x * cos(a) * sin(a) * 2 + y * (cos(a)^2 - sin(a)^2) Now this is a more complicated formula than the one above, but you can precalculate all the terms X and Y have to be multiplied with, and some of them even occur in both formulas. So you basically you need the following values calculated: sin(a)^2 - cos(a)^2 cos(a)^2 - sin(a)^2 (which is the negative of the previous value) sin(a) * cos(a) * 2 What's more, due to special properties of sinus and cosinus, the terms we are looking for also describe sinus curves, so that: sin(a)^2 - cos(a)^2 = -cos(a*2) cos(a)^2 - sin(a)^2 = cos(a*2) sin(a) * cos(a) * 2 = sin(a*2) Therefore, the term that directly transforms the source direction vector to the final direction vector gets reduced to: x'' = y * sin(a*2) - x * cos(a*2) y'' = x * sin(a*2) + y * cos(a*2) So this basically reduces the necessary calculation to 4 multiplications, at least if you know the angle and thus the sin and cos values beforehand. Remeber, they apply to the slant of the object being hit, not to the angle at which the ball is hitting it. And even for the "circle" collision check I described earlier, those sin and cos values should be able to be calculated rather easily by taking into account the position of the ball relative to the center of the circle. For the collision check, we calculate the following values: dx = x of ball - x of circle center dy = y of ball - y of circle center dx2 = dx * dx, this is dx2 squared dy2 = dy * dy, this is dy2 squared dx2+dy2, this is the sum of dx2 and dy2 r, the radius of the circle (pre-stored in ROM) r2, this is the squared radius (can be looked up in a lookup table or already stored in ROM for that check) Now the sin value is actually roughly (dx / r), and the cos value is roughly (dy / r)... OK, we need to do two divisions here, of a type that calculates a fraction of a byte value by another byte value (and expresses it in a byte where 0 = 0 and 255 in that byte = 1, so like a subpixel value). You can now square the sin and cos values by multiplying them by themselves (or possiby using another lookup table for that) using a multiplication of two 8-bit values giving a 16-bit value out of which only the top 8 bits get used. OK, I think I get carried away here... Anyway, I also tried the latest binary. I think the ghosts now move a bit more random now, which is good. I also see the color change in the mazes when they repeat has been implemented, which is good as well. As for the ball, I've seen that too. There was a yellow ball in there... I can imagine adding that as an option with the yellow ball being slightly bigger, lighter and "springier" than the normal grey ball... as if the yellow ball was made out of rubber vs. the normal steel ball. As for the sound, as far as I know the Baby Pac-Man machine's sound hardware is probably derived from that of pinball machines and only plays one sound effect at a time which in turn may use multiple channels. So the way I'd do it would be to also play only one sound effect at a time, but let sound effects use both sound channels at once.

Well, in case you didn't notice, in my last post I did try to simplify the complex trigonometric functions so that the actual calculation of the reflected direction from the incoming direction only involves 8 16-bit * 8-bit multiplications. Of course it's possible to implement a grid which the playfield is divided into. But this may use up more memory because for each grid cell there has to be defined which checks to make, and some items to check may fall into multiple grid cells. It even becomes more complicated if you check multiple grid cells in each frame, whereas in my proposal the ball position always falls into only one area, and there are actually only two areas on the playfield which would have more than one collision check... and the two checks they each have would be for horizontal and vertical position only, so very simple ones. I'm also for putting the ball on rails on any enclosed area. I already proposed to do this for the two curves on top of the playfield which are rather cumbersome to calculate, and the other enclosed areas are actually straight up/down paths, so I'd simply clear the left/right movement there and only allow up/down movement as normal, without any collision checks, until the ball has left the path on the top or bottom. In fact, I'd propose that if the ball goes down the TUNNEL or FRUIT paths, the rail continues until it hits the flippers, so that actual collision and path calculation only take place if the ball hits that area not coming down through the vertical paths. The ball could also be put on the same rail if it goes up those paths (which may happen if it came down the other way and the flippers are operated in a certain way), but it should be taken care of accordingly calculating its speed because in this case it may not go high enough to hit certain targets before it starts coming down again. Kosmic Stardust, I think your proposal regarding the flipper behavior is an interesting one. The question is what to put into the lookup tables. This is a part I didn't think of very much yet. I still believe that most of the tricks shown in the videos should be possible with an 8-bit pinball game. There have been other pinball games on 8-bitters which look pretty convincing, like Broderbund's David Midnight Magic, Atari's Midnight Magic (on the 2600), Sublogic's Night Mission and of course EA's Pinball Construction Set, so I think something like this should be possible on the 7800 as well.