Jump to content
IGNORED

Baby Pac-Man


PacManPlus

Recommended Posts

Speak for your OWN Concerto. That's your own fault. LOL. In the meantime I play it on mine.

Concerto was broken from day one. Every single ROM I flashed onto the device got corrupted to the point of extreme bugginess or broken gameplay.

 

 

 

And I got farther on my hardware with Concerto than many users did. Some people were unable to even select a ROM from the menu. The fact the developer was asking me to go out and buy another 7800 console on the random chance it would be more compatible than with my current hardware was an unacceptable solution. I don't hoard multiple consoles for every system.

 

My 7800 console is not broken. It still plays all original 7800 games including modern homebrew, and a vast majority of 2600 games including the original Harmony cart, without issue.

Link to comment
Share on other sites

OK, here are some comments as for the ball physics... I just looked at a gameplay video of the original arcade game in order to better understand it.

 

Basically, the ball physics of the unobstructed rolling ball should work such that the ball follows a ballistic curve, that is, the vertical speed stays the same while the horizontal speed (measured in scanlines per second counted from the top) increases by a fixed amount at regular intervals (which means that if it's negative, the ball goes up, and that negative value slowly decreases).

 

This would be the movement of the unobstructed ball. If it hits something, it might bump off depending on the angle it hits the obstruction in. In this case, basically the movement gets divided in two components relative to the angle of the obstruction... one component that's parallel to the obstruction surface which is kept or slightly decreased, and another that's "normal" to the obstruction surface which basically gets negated (and possible decreased in intensity as well, or increased if it's a power bumper or such).

 

Quite ofteh at least in this game, however, the ball will be "guarded" by a path it is going through... either the curved ones at the top or a straight one where "Tunnel" or "Fruit" lights up. For the curved ones, it should be made sure that the ball is going smoothly through them and doesn't ever fall off or be brought off-track by something that seems like a "cliff" in the curve. To achieve this, while on screen the ramps are pixellated, for the sake of calculation, they should be in angles and also be treated as such. This probably requires a bit of complex mathematics unless the ball is unobstructed. I still think this is important to get right because the ball is in such "guide rails" quite often.

 

That being said, the way the 7800 version of the pinball playfield looks now I've got the feeling that some paths are not as smoothly curved as they should be... for instance, when the ball goes down through the "tunnel" section, the path changes into the angle at which the flippers are placed with only 2 or at most 3 intermediate steps, which if treated physically correct, might cause the ball to bump off one of the steps and get slightly off the guarded track, which is not what happens in the original version because that one is more "round".

Basically the ball will follow a parabola as an arc. And you got horizontal and vertical mixed up. Negating the action of friction, horizontal offset per frame remains constant until the ball collides with object. Vertical offset per frame steadily reduces at a constant rate. First the offset is positive, meaning the ball is travelling upwards, then as the offset crosses the zero point and becomes negative, the ball begins it's downward trajectory. A couple of pointers here, the frame rate is 60Hz, so even changing the vertical offset by one pixel per frame will cause a very fast gravitation, leading to fast drains. The offset has to be computed on a fractional basis, often using maths that define less than one pixel width, then the x/y position is updated based upon nearest neighbor. The maths can be problematic for 8-bit systems because the screen for instance is 192 pixels high by 160 pixels wide. Realtime multiplication / division of variables is too costly for 8-bit processors that lack floating point maths, so we could bit shift the data. For instance, an 8-bit value that subdivides each pixel into 16 pieces could use the upper 4 bits (nibble) to calculate the position data. However the realtime position of the ball will experience an overflow condition after travelling just 16 pixels.

 

So it may be necessary to use 16-bit maths to calculate position data with subpixel precision. The least significant byte calculates the subpixel depth, and the most significant byte determines the actual position on screen. Any increment or decrement resulting in an overflow condition on the least significant byte must carry over to the most significant byte, if proper 16-bit positional data is to be carried out. I think it is doable but realistic physics with sub-pixel precision requires 16-bit math and will require more adds or subtracts when using 8-bit cpu. Another thing to bear in mind is to watch how fast the ball can accelerate. If necessary, set a maximum "speed limit" for the vertical or horizontal velocity. Many platform games do this when players fall, so the player does not pass through the floor. Likewise in real life there is a phenomenon known as "terminal velocity" where the acting force of wind resistance equalizes the acceleration of gravity. For humans in freefall, this is roughly 120mph straight down. Chances are barring superhuman strength, you will probably die when you hit the ground. :skull:

 

If the ball accelerates to such speeds that it moves multiple pixels per frame, it could potentially miss collision detection with walls or flippers, resulting in the ball passing through objects it shouldn't or otherwise getting "stuck". We don't want the ball to go out of bounds at all, but also provide some means of resetting position in software if it does, whether this means counting as a drain or placing the ball in the plunger or some other location. This way the gameplay is not suspended indefinitely in the event the ball travels out of bounds, with no means for the player to continue their game besides resetting the console.

 

Just some food for thought. I'm not a programmer but am good with maths and have a good understanding of physics. A believable physics engine is one of several necessary components for good gameplay in a pinball simulator.

  • Like 1
Link to comment
Share on other sites

OK... I would definitely use subpixel math here. The way I'd normally do it is that both for the velocity and position of the ball (for each coordinate of it, of course) there would be one pixel byte and one subpixel byte. In each frame, there would be a 16-bit addition of the velocity to the pixel values. This way it doesn't actually matter much which direction the ball goes, the addition is always the same. In addition to that, a constant value is added to one of the velocity subpixel values in order to simulate gravity in each frame, increasing the pixel velocity value on overflow.

 

As for checking for collision, you probably assume that a collision is only given if the ball is at an exact row or column value. But there are ways to go around this.

The way I'd do it is to define a number of areas in which the playfield is subdivided. First there's a check which of the areas the ball currently is in. You can either do this freshly every frame or check if the ball is still in the same area as in the last frame and then first check if it's gone to the adjacent ones, and only if that fails, check for all others. For each area, only one or two different collision checks are performed. There are basically three types of collision checks:

1. Collision with a straight wall (can be horizontal or vertical)

2. Collision with a slanted wall or

3. Collision with the inside or outside of a circle.

For a straight wall, you can simply check if the ball has gone beyond the boundary to check for, such as if the x or y coordinate has become higher or lower than the value to check for.

Slanted walls usually have an equation defining them, such that x*a + y*b = c, or x*a + y*b + c = 0, where x and y are the ball coordinates, a and b are values unique for that slant and c is a value unique to that line. Now if x*a + y*b + c is positive, the ball is on one side of the line, and if it's negative, it's on the other side. The "wrong" side in terms of the check would mean it has collided with the obstacle.

Finally, circles are actually easy to check for as well. You first subtract the ball position from the center of the circle. For both x and y differences, you take the absolute value and then the square of that absolute value, then add both squares together, so that result is (dx*dx + dy*dy) with dx and dy being the differences in x and y coordinates. The result is then checked against the square of the circle radius. If it's greater than that, the ball is outside the circle, if it's smaller, it's inside. For the square values, you can use a lookup table with an appropriate number of entries. The fact that the ball itself has got a size is accounted for by positioning the lines and circles so that they actually fall on the center of the ball when it's just hitting the obstacle.

 

Here's another picture to illustrate this area principle and also the placement of the check boundaries and the different types of checks. I've colored the checking boundaries red and the area boundaries pink. As you can see, the areas can be checked pretty easily because they are always divided by horizontal or vertical lines, and by cleverly cascading the checks, there are only at most 6 checks to be performed until you have the exact area the ball is currently in. Note that the circles are always whole here, but they are actually only checked in the areas where they actually go along an obstacle. In the other areas, they are not being compared by simply not having that check performed in that area.

 

post-8393-0-00370400-1529829326.png

 

Note that this picture is only there to illustrate the principle... the lines and circles are not all exactly where they should be. I've also only drawn the full set of lines and circles for the left half of the playfield, but they should of course be there in both halves.

Edited by Kurt_Woloch
Link to comment
Share on other sites

 

Slanted walls usually have an equation defining them, such that x*a + y*b = c, or x*a + y*b + c = 0, where x and y are the ball coordinates, a and b are values unique for that slant and c is a value unique to that line. Now if x*a + y*b + c is positive, the ball is on one side of the line, and if it's negative, it's on the other side.

One small issue with your post above is that multiplication and division aren't really feasible on an 8-bit CPU like the 6502. You can easily simulate multiplication and division by powers of 2 by simply bit shifting the data. Multiplication must be done in longhand as there isn't a simple 8bit multiply function. Multiplication by 3 could be accomplished by bit-shifting the byte over one bit and adding it to itself. For arbitrary multiplication of 8-bit integers, you would need to perform separate bitshift and addition operations for every "1" in the multiplicand, then store the data in a 16-bit register. And division is an even more arcade process than multiplication. You simply cannot call and execute a single command like X*Y=Z where X and Y are two 8-bit integers and have the CPU magically output 16 bits to a register as two consecutive bytes. Many games get around math and complex arithmetic requirements by inserting lookup tables into a ROM. Many times you see sprites move in a smooth circular arc in an 8-bit game, the engine is using a lookup table to position the sprites because the trig necessary to draw perfect concentric circles is impossible or would consume enormous amounts of resources. Firebars in Super Mario Bros castle stages (NES uses a 6502 derivative) are a good example where the game engine uses lookup tables to position the rotating sprites instead of actual math.

Link to comment
Share on other sites

Yes, I know... that's why thought to myself that checking against a slanted wall might actually be computationally more expensive than against a circle (using lookup tables). Whereas as long as the flippers aren't activated, the slants are pretty eay... the lines should be something like 4*x+y+c, and 4*x can easily be computed by left-shifting twice. However, the flippers are also slanted lines and move to different positions, and that's where things really get complicated. At the same time, the flippers are what the player actually controls and thus the ball's interaction with the flippers is probably the most critical thing on the whole playfield to get right because the player expects the ball to act in a certain way according to the "real thing" when the flippers get operated while the rest of the playfield more or less always sits in the same position.

 

That being said, what happens if a collision is detected is probably in every case more complicated to calculate than detecting the collision in first place.

Link to comment
Share on other sites

Whoa.

 

Thanks for the conversation, guys... I'll need to read through those posts again to see if we all have the same / similar ideas on how to do this.

 

A few things to remember:

  • I had to take a few small liberties with some of the tiles that make up the playfield, as I ran out of tiles to use (that's why there are some places with missing / discolored outlines). So I'm not sure how much I can change that... We can still 'act' like the correct curves are there though.
  • The 'trapped' ball at the top doesn't need to be considered, as it is always on a fixed path, so I plan on just having a table for that one.
  • I have to read several points around the ball to see which tile it 'collided' with, and act accordingly - the 'act accordingly' part is the one I'm afraid of...
  • I had actually planned on using bytes / sub bytes for positioning, so I'm glad I'm thinking the same way...

It's going to be slow moving from here on in though... I'm trying to focus my efforts on my new job.

  • Like 5
Link to comment
Share on other sites

Well, as for the trapped ball... if there's a table for that, then there's the question if that table could also be used for the two curves on the upper left and right... as soon as the player's ball enters one of these areas, it could simply move as if it was the trapped ball and then get out at the other end of the curve at about the same speed it entered, but in a straight line down. This could save us from having to calculate the "proper" reactions of the ball to those two sharp curves...

 

What I was suggesting above was essentially replacing the tile-based collision detection... it doesn't save you from the "act accordingly" part though. ;-)

Link to comment
Share on other sites

If I were to attempt a pinball game I think I'd handle most of the physics as vector * speed instead of x and y velocities, that way it would be simple to have a 256 byte lookup table that lists vectors for each 256th of a circle and those vectors could be used when counting sub-pixel amounts in order to have the ball move on one axis faster than the other without too many complications.


Getting the angle of the ball once it hits something would then be a case of finding the difference between the angle index of the ball, the angle index of the wall or object it's colliding with, working out the difference, and offsetting the balls angle by that amount. Once you have the new angle you can look up the new vector and move the ball in that direction. Gravity can be simulated by having the angle of the ball change towards 128/256 over time while it's not colliding with anything.

  • Like 1
Link to comment
Share on other sites

Unfortunately this approach sacrifices a realistic ballistic curve while the ball doesn't collide with anything... it would be more like a circle then. I'm just wondering what would be the best of both worlds... while unobstructed, the ball's movement would be expressed in X and Y velocity, then on a collision that would be converted into the vector * speed format and after the bumping action it would be converted back into x/y.

Link to comment
Share on other sites

OK, this one didn't leave me alone, so here's some formulas to play with... I'm trying to correctly calculate a new set of x/y velocities from an old set of x/y velocities if the ball is reflected by a slanted line.

 

Let's assume the line at the lower left (to the left of the left flipper) which goes down one step for each 4 steps to the right. We now have to convert the ball motion into a vector relative to the slant of the line (forgive me if you don't understand this, I know it's hard)... to do this we apply a turning matrix to the original x/y vectors to arrive at the x/y vectors relative to the slant of the line. The turning matrix formula looks like this:

 

x' = x * cos a - y * sin a
y' = x * sin a + y * cos a

with x and y being the original x and y velocities, a being the angle of the slant and x' and y' being the resulting vectors relative to the slant of the line.

 

Now, Sin and Cos? Well, yeah, but you don't need to calculate that... since the line is fixed, you can pre-store them. For this line, the "sin a" part would be roughly 0.96, and the "cos a" part would be roughly 0.24... not really exactly, it's only there for illustration. Basically we have to arrive at sin and cos values such that sin a / cos a is the slant of the line (4/1) and (sin a) squared + (cos a) squared = 1. (You'd best express this in a "fraction" byte so that the sin and cos values are all multiplied by 256, so the actual values would be 61 and 246 here. Actually, the ideal values in this case would be 62 and 249.

 

But for clarity, let's stick to our original float values...

 

Let's assume that the original speed vector of the ball is X = 3 and Y = -1, which means it goes down 3 pixels per frame and left 1 pixel per frame, so it's hitting the line pretty much straight on, but not exactly.

We now compute the vector relative to the slant of the line by multiplying the original vectors with the turning matrix, so that:

x' = x * 0.96 - y * 0.24 = 3 * 0.96 - (-1 * 0.24) = 2.88 + 0.24 = 3.12
y' = x * 0.24 + y * 0.96 = 3 * 0.24 + (-1 * 0.96) = 0.74 - 0.96 = -0.22

Now x' is the speed at which the ball is vertically hitting the line, and y' is the speed at which it travels along the line in its direction.

Now to make it bump off, we negate x' so that x' is now -3.12.

 

Then we reverse the turning matrix to turn this vector back to the original components. The reverse of the turning matrix is basically the turning matrix for the negative angle, which is: sin a = -0.96 and cos a = 0.24, so we just reversed the "sin a" part here.

 

Now we repeat the same calculation as before with the new values (x' now becomes x and y' now becomes y):

x' = x * 0.96 - y * -0.24 = -3.12 * 0.96 - (-0.24 * -0.24) = -3 + -0.0576 = -3.06
y' = x * -0.24 + y * 0.96 = -3.12 * -0.24 + (-0.24 * 0.96) = 0.75 + (-0.23) = 0.52

 

We now have the new speed vector of the ball after bumping off, which is -3.06 (3 pixels up per frame) / 0.52 (0.5 pixels to the right per frame)

I know that's a lot of calculation, but at least it only uses multiplications, no divisions. I think it would be best to do a multiplication routine multiplying a 16-bit value with an 8-bit value (representing the sin and cos values) giving a new 16-bit value where the lower 8 bits of the actual 24-bit result are truncated. I think this shouldn't be too computationally expensive.

 

For special cases such as the aforementioned circles or the moving flippers, I can also think of a routine calculating the sin and cos values on the fly without too much overhead. Just ask me... ;-)

 

I've drawn up another picture to illustrate this:

post-8393-0-62235800-1529866483.png

 

The red arrows show the direction at which the ball is initially travelling before hitting the ramp with the green lines giving the X and Y components of the speed (enlarged so you can read the numbers). The blue lines and numbers show the converted vector so you can see which directions they now represent. After negating the X component (3.1 to -3.1) the vector is "turned back" to its original orientation so that the X and Y values represent the actual screen axis again.

 

I hope this wasn't too complicated... I tried to make it as easy as possible without using special mathematical symbols.

Link to comment
Share on other sites

Hey guys. Just some quick links about ball control and techniques that pinheads use that would make Baby stand out from other 8 bit pins.

 

Dead bounce:

 

Live catch:

 

Drop catch:

 

Post pass: (I use this all of the time on Medieval Madness; it is a lifesaver!)

 

I know everyone has ideas and opinions, but I wanted to share my thoughts on control schemes. Bob, if you like it, hey great; if not no biggie. Just wanted to share my thoughts. I really think this game would sing on a twin stick setup with the 7800 Pro Line coupler or a SEGA pad through a 7800 adapter.

 

It looks amazing by the way. I loaded it up on my mac and just stared at your playfield for the pin part. The Pac part totally kicked my butt btw! :)

 

post-30305-0-52759200-1529869434_thumb.jpg

  • Like 1
Link to comment
Share on other sites

I don't have time to properly respond to everything that's been said here, but I think Kurt's approach is WAY too complex for what the 7800 is capable of, and too complex for what can realistically be achieved. There are a few things that Bob needs to put in place in order to reduce the amount of work the system needs to do in order to pull this off, and some "realistic physics" is going to have to be sacrificed.

 

  1. The screen needs to be broken up into grids. Collision should only be checked against something that occupies the grid that the ball is currently in. Depending on how granular you make that grid, and how much processing time you need, you can check four grids: the one the ball is in, as well as the three grids in the approximate direction of the ball. e.g. If the ball happens to be travelling up and to the right, the grids you would check are the ball's current grid, the one above, the one to the right, and the one above and to the right. That significantly cuts down on the number of collision checks you need to make.
  2. Any area that's enclosed, like the FRUITS and TUNNEL portions, that should put the ball on rails. Don't bother processing collision for the ball at that point, just take the current speed that the ball has and run it through a predetermined, precalculated vector. That will definitely keep the ball from getting stuck, and cut down on the amount of work you need to do. Trying to send the ball through those rails with realistic collision and physics is going to drive you nuts, especially when you start debugging it.
  3. If you want to cut down further processing at the expense of memory, you can have a second representation of the playfield, strictly for collision, with everything expanded outward by the radius of the ball. That way you're only processing collision at the point of the very center of the ball. You don't want to have to extend a collision vector in a variety of directions to see if the ball happened to bump into something, especially in a direction other than the one it was travelling. Your representation of the collidable playfield should allow you to treat the ball as a single pixel in size.

Obviously this needs to be achievable first, and then improved upon in later iterations. Don't go for perfect on the first pass. Go for feasible. I'm speaking with experience.

Edited by procyon
  • Like 4
Link to comment
Share on other sites

I'm with procyon here. There is absolutely no room for complex trigonometric functions, square roots, or division / multiplication other than simple bit shifts.

 

16-bit additions for x/y position and velocity, and ball path moving in a parabola by incrementing / decrementing the vertical displacemet by some small fixed amount each frame, is about the limits of the math we can achieve for the pinball. Fortunately parabolic trajectories are easy to calculate. When the ball collides with the flipper, it's horizontal displacement, ie the balls lateral position in relation to the flipper zone, will etermine it's outward trajectory when the flipper is hit. The closer to the end of the flipper the ball is at, the wider the angle. This will be constructed by a fixed collision zone. When the ball enters the collision zone, one of three possible lookup tables will result: the ball collides with the flipper without actuation. In this case it rolls down the flipper until it drains or the user actuates the flipper. The second lookup table is for actuating the flipper with the ball in the collison zone. Closer to the drain, the wider the shot. Closer to the origin of the flipper, the more upwards it travels, with velocity slowing down. At the inner edge of the flipper near the axle, the ball will be knocked backwards with relatively low velocity. Third lookup table is for when the flipper is already actuated before the ball enters the collision zone. If it's travelling fast, it bounces off like a wall, otherwise the flipper will cradle the ball at the base. Relaxing the flipper allows the ball to roll down, and precise timing hitting the trigger to take aim. The tuning of the lookup table for the flippers is the most critical part of the engine. You want the player to have control of where the ball goes by precise timing the flipper hits. But there's no room for advanced physics simulations, ball tricks like dead catch and other things they try to simulate in Pinball arcade aren't going to work on vintage 8-bit cpu. You need at least 32-bit floating point maths for advanced calculations like that.

 

Nudging the table using the joystick (by for instance using the two buttons for flippers, stick for nudging) could work by changing the x or y offset of the ball for one frame without altering the velocity. It would be nice if the nudge event could present a shift of the graphics but understandable if that isn't feasible. Nudging was easy to simulate on the NES because the x/y offset could be changed on the fly for ppu graphics. As always, three or more nudges in a short period of time amounts to a tilt condition and loss of ball. Display a warning onscreen after two consecutive nudges, with an internal counter that clears after a few seconds.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I'm not a programmer, but I do have a special soft spot for pinball sims, new and retro. Obviously real world physics is more complex, but the gist of basic pinball strategy is you can aim the ball tragectory striking the flipper button, based on it's current position when rolling down the flipper. This can be implemented to a degree even on 8-bit platforms.

 

@Pacmanplus, if you can, try to get in touch with Brian Parker of RetroUSB. He goes by Bunnyboy on NintendoAge but thebest way to contact him is via the contact form on his website. In 2016, he made a quite good pinball simulator for that year's Christmas 8-bit Xmas cart.

 

Since the NES and 7800 share a similar CPU architecture, maybe he could give you pointers about the development of the physics engine for Baby Pac.

 

The old development thread is here:

http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=162942

  • Like 1
Link to comment
Share on other sites

Came on here just to say that I'm really glad I found this project. A bit latter than I wish I did, but as an owner of a Baby Pac machine myself, I support the eventual completion of this project.

You own one! Lucky! How much maintenance is that thing if you don't mind me asking. My Pac-Man cab still sings like a bird but I've repaired my board twice and the monitor is a time bomb waiting to die.

  • Like 1
Link to comment
Share on other sites

You own one! Lucky! How much maintenance is that thing if you don't mind me asking. My Pac-Man cab still sings like a bird but I've repaired my board twice and the monitor is a time bomb waiting to die.

 

The occasional bit of work here and there (plus keeping the machine and glass clean), but nothing major since the one time a wire got short-circuited and blew the fuse- plus having to repair the right saucer/launcher which still goes dead occasionally here and there so I have to remove the CP and glass and free the ball myself, but it only fails on certain power-ons afaik. It cost me 1 grand and was a local pickup but it was hugely worth it, and this port will help get the game into even more homes if it ever comes out on cart.

  • Like 1
Link to comment
Share on other sites

Small Update:

 

'Bump'ing the table is now implemented, although nothing happens to the ball yet. The playfield reflects the bump. I took RevEng's advice about skipping all other routines while bumping the table, and it seems to fit.

Also, small update to the 'PAC-MAN' energizer area on the pinball playfield.

 

It's going to be very slow going from this point on, sorry guys.

 

Bob

BabyPac.A78

BabyPac.BIN

  • Like 12
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...