Williams Games & Ram Speeds

D_Harris

Well-known member
Joined
Jan 27, 2008
Messages
2,518
Reaction score
51
Location
Staten Island, New York
I'm a stickler keeping the original game play original for the classics and wanted to ask about the swapping of 4164 ram in place of 4116 ram on certain Williams games like StarGate.

I've noticed that the commonly available 4164 ram is faster than the original 4116 ram used on Williams board sets and wanted to know if this would result in speed-ups, or to put it more accurately, will it result in a lack of things slowing down when there is a lot occurring on the screen during game play.

Any thoughts?

Thanks.

Darren Harris
Staten Island, New York.
 
One trick is to find an older home that still has 110v instead of the 120v. Plug the game in there, and because of the voltage difference (the old type), you can use the raster RAM, but play at normal speeds.

or I just made that up.
 
I've swapped out the ram chips to 4164 in my Joust and haven't noticed any differences at all.
 
One trick is to find an older home that still has 110v instead of the 120v. Plug the game in there, and because of the voltage difference (the old type), you can use the raster RAM, but play at normal speeds.

or I just made that up.

:beerchug:
 
There will be absolutely zero difference in game play. Provided the ram is as fast or faster, it will function properly. The faster speed rating of the RAM will not change the speed of the machine - that is dictated by the main processor.

-Ian
 
There will be absolutely zero difference in game play. Provided the ram is as fast or faster, it will function properly. The faster speed rating of the RAM will not change the speed of the machine - that is dictated by the main processor.

-Ian

I just wanted to confirm.

I know the game speed will not change. I was wondering about the slow-downs that are normal when there are a lot of things happening on the screen.

Darren Harris
Staten Island, New York.
 
I know the game speed will not change. I was wondering about the slow-downs that are normal when there are a lot of things happening on the screen.

That will all stay the same. A clock cycle still takes the same amount of time, regardless if your RAM is faster than it needs to be.

In order to actually change the speed at which the game writes to/reads from RAM, you'd have to change the speed at which the bus operates - which, in this case, would require increasing the processor speed.

Imagine this - a bus drops you off at a stop. You know that the bus will make it's entire route and return to this stop in half an hour. You go into the store, then come back out to catch the bus. It doesn't matter whether you spend five minutes in the store, or 25 minutes in the store - the bus isn't going to come back any faster.

-Ian
 
That will all stay the same. A clock cycle still takes the same amount of time, regardless if your RAM is faster than it needs to be.

In order to actually change the speed at which the game writes to/reads from RAM, you'd have to change the speed at which the bus operates - which, in this case, would require increasing the processor speed.

Imagine this - a bus drops you off at a stop. You know that the bus will make it's entire route and return to this stop in half an hour. You go into the store, then come back out to catch the bus. It doesn't matter whether you spend five minutes in the store, or 25 minutes in the store - the bus isn't going to come back any faster.

-Ian

Is that a good analogy? What about hitting several stores before the bus comes returns? Therefore you'll have more stuff(information) with you when you get back on the bus. :D

Darren Harris
Staten Island, New York.
 
i buy your technical input....but when you get to the higher levels indeed there is a difference between 4164 and 30 yr old 4116 rams.

i don't even know why but it is observable after wave 30.
can only assume it has something to do with how the system is handling the ram to ram stuff like sean riddle touched on regarding the mame play.

as an experiment i randomly mixed up old 4116 ram with "converted" 4164 ram on a cpu. robotron seemed even slower than with all old ram. explain that.

i'm not even looking for validation because it requires being way way way over analytical about game play and i'm embarrassed that the addiction of playing robotron progressed to that point. :)


Here is my conspiracy theory-
we know in mame per Sean Riddle's speed testing that rom to ram and ram to ram weren't the same. so they changed the speed of the emulation. release note for 0145u2 listed below.

and that fix specifically slowed down things like the speed of the projectiles for enforcers, brains and tanks. plus it slightly reduced speed of grunts on 9 waves.

so could it be that the old ram is somehow churning out some different timings, because the observable things that seem faster with 4164 rams are the same thing you see with mame without 0145u2 (just not as drastic a speed difference)

"Williams blits with bit 2 set take approximately 2x as long because
they are bus-shared with RAM. Should impact some timing behaviors such
as later levels in Robotron, where approximately 10% of the blits are
done with bit 2 set."

I have a friend with a nice clean original robotron that plays slow slow slow, compared to another persons. that's another one to try to explain. i can't, but it's observable to the observant player over wave 30.
argue away, i have nothing more to add beyond that
"observation"
 
Last edited:
Imagine this - a bus drops you off at a stop. You know that the bus will make it's entire route and return to this stop in half an hour. You go into the store, then come back out to catch the bus. It doesn't matter whether you spend five minutes in the store, or 25 minutes in the store - the bus isn't going to come back any faster.

Good analogy. Modern computers can often take advantage of faster RAM since the memory timing is configurable in the BIOS. i.e. you can tell the bus driver to drive faster if you're a quick shopper. The timing of old arcade games is 'hard-wired' though. There is no way for the RAM to tell the CPU that there is valid data on the output, just like you can't call the bus driver to ask him to pick you up earlier.
 
Last edited:
one thing you'll greatly benefit from is that the 4164 ram doesn't overheat. i think it's a great thing. really no reason not to update from the 4116 ram just for that alone. online resources say the failure rate of 4116 ram is high whereas 4164 ram is low.

good thing for marathoning.
 
This should only make a difference if the original RAM speed wasn't faster than every potential memory bus cycle. If it was fast enough, then it would always have data ready before the bus cycle asked for it (and making it faster won't change anything).

If it wasn't fast enough, then it's possible on some accesses you would get wait states inserted into the cycle (which just delays the cycle until the RAM is ready to complete it) .. so inserting faster RAM would reduce or eliminate the wait states, and potentially change the game functionality.

Of course that's a general answer. If you're wondering about a specific game/CPU/RAM combination, the answer could be calculated based on the timing diagrams in the respective datasheets.

LeChuck
 
that makes sense. then i'm going to assume the ram must be slower than spec, nowadays. what you'll notice on robotron is brains that get "stuck" and don't fire. or tank waves where hardly any shots are fired before you pick them off at high levels. makes the game kind of boring actually.....

my one buddy that has a normal speed robotron is wanting to go for some 5 man tournament runs from the other friend's "slow" robotron. can't see why that wouldn't be "legal" per TG.
 
If it wasn't fast enough, then it's possible on some accesses you would get wait states inserted into the cycle (which just delays the cycle until the RAM is ready to complete it) .. so inserting faster RAM would reduce or eliminate the wait states, and potentially change the game functionality.

But you'd have to disable the wait states. It's not going to be a magic, automatic thing that happens when faster RAM is inserted.

-Ian
 
that makes sense. then i'm going to assume the ram must be slower than spec, nowadays. what you'll notice on robotron is brains that get "stuck" and don't fire. or tank waves where hardly any shots are fired before you pick them off at high levels. makes the game kind of boring actually.....

my one buddy that has a normal speed robotron is wanting to go for some 5 man tournament runs from the other friend's "slow" robotron. can't see why that wouldn't be "legal" per TG.

As long as the RAM can serve up the bits faster than the CPU can handle them you are fine. The clock speed is 1MHz or about 500nS. The original RAM was 450nS RAM. So anything faster than that is good.

Trivia:
Q: Do you know the difference between 150nS and 450nS RAM?
A: Probably nothing. The difference was what speed the chips were certified to run at.

They make 20,000 chips. They have orders for 2,000 chips at 150nS, 4,000 chips at 250nS and 12,000 450nS chips. They will start on the chips and when they get 2,000 chips that test good at 150nS, they turn the clock down, dump all the chips that foiled back into the bucket and start testing for 250nS until they get the 4,000 chips that that they need. Then they turn the clock down again, dump all the chips back in the bucket and test until they get the 12,000 450nS chips they need. Could some of those 450nS chips test good at 150nS, absolutely. It was luck of the draw literally.

The issue with the blaster fire in the higher waves is simply the draw/calculation loop. You (the main character) are #1 on the draw list. Then come your bullets. Then come the family members, then come the moving objects and then finally come any enemy missles, ray blasts, bullets, etc.

So if the processor can handle 75 objects drawn in a single frame (an arbitrary number, I don't remember the actual number) and there are 95 objects, the last 20 won't get drawn until the next frame, so they will appear "frozen". There is arbitration logic to make sure that objects within classes get equivalent time slices. So they don't stay frozen for long. Especially since you are free to move and shoot at full speed until you kill off enough objects to get the number down to a point that the CPU can handle all of the objects every frame.

That is why all of the good players know to take advantage of that momentary period where you are moving 2 to 3 times faster than everything else to kill the most dangerous and closest enemies as quickly as possible.

ken
 
But you'd have to disable the wait states. It's not going to be a magic, automatic thing that happens when faster RAM is inserted.
To clarify, I was referring to logic that does automatically insert wait states when the device isn't ready to supply its data. I'm not sure if any classic game designs utilize this though (even with CPUs that support a wait/busy control signal). If the access times are dictated purely by HW, e.g. fixed strobe clocking, then yes that is another case where faster RAM won't help anything.

LeChuck
 
That is why all of the good players know to take advantage of that momentary period where you are moving 2 to 3 times faster than everything else to kill the most dangerous and closest enemies as quickly as possible.

ken

this is where the mame emulation of robotron still isn't correct.
instead of being 2 to 3 times faster at the start of higher waves, you are sluggish just like everything else.

if you take real robotron side by side with emulated. you'll notice even on wave 1 the movement of the player is more sluggish/slow than real.
and you can really feel it if you are the one doing the controlling.
 
MAME uses an emulated 6809 and then it is tweaked to give the person who did the tweaking what he thought "felt" like the game. I don't know which game they used to set the tweaking, but I'm pretty sure it was either Defender or Stargate. Neither of which use the DMA "Special Chips". That started with Robotron.

ken
 
I've been doing some "tweaking" tests in mame per direction of sean riddle. i have hopes we'll see some progress on mame being close to real in the near future. :)


Here are snippets of knowledge written at the beginning of the mame video source code for williams-

Williams 6809 system

****************************************************************************

The basic video system involves a 4-bit-per-pixel bitmap, oriented
in inverted X/Y order. That is, pixels (0,0) and (1,0) come from the
byte at offset 0. Pixels (2,0) and (3,0) come from the byte at offset
256. Pixels (4,0) and (5,0) come from the byte at offset 512. Etc.

Defender and Stargate simply draw graphics to the framebuffer directly
with no extra intervention.

Later games added a pair of "special chips" (SC-01) to the board which
are special purpose blitters. During their operation they HALT the
main CPU so that they can control the busses. The operation of the
chips is described in detail below.

The original SC-01 had a bug that forced an XOR of the width and height
values with 4. This was fixed in the SC-02, which was used on several
later games.

Beginning with Sinistar, additional video tweaks were added.

In Sinistar, a clipping window can be specified and enabled in order
to prevent the blitter chip from drawing beyond a certain address.
This clipping window can be switched on and off at will.

In Blaster, a number of features were added. First, a fixed window can
be enabled which cuts off blitter drawing at 0x9700. Second, on a
per-scanline basis, an "erase behind" feature can be turned on which
clears the video RAM to 0 after it is refreshed to the screen. Third,
on a per-scanline basis, an alternate color can be latched as the new
background color.

For Mystic Marathon and the 3 other "2nd generation" Williams games,
a tilemap background layer was added. This layer consisted of 24x16
tiles and only scrolled in the X direction. In addition, the palette
was expanded to 1024 entries, some of which were used for the tilemap.
The traditional foreground bitmap could be configured to use any bank
of 16 colors from the full palette.

****************************************************************************

Blitter description from Sean Riddle's page:

This page contains information about the Williams Special Chips, which
were 'bit blitters'- block transfer chips that could move data around on
the screen and in memory faster than the CPU. In fact, I've timed the
special chips at 16 megs in 18.1 seconds. That's 910K/sec, not bad for
the early 80s.

The blitters were not used in Defender and Stargate, but
were added to the ROM boards of the later games. Splat!, Blaster, Mystic
Marathon and Joust 2 used Special Chip 2s. The only difference that I've
seen is that SC1s have a small bug. When you tell the SC1 the size of
the data to move, you have to exclusive-or the width and height with 2.
The SC2s eliminate this bug.

The blitters were accessed at memory location $CA00-CA06.

CA01 is the mask, usually $FF to move all bits.
CA02-3 is the source data location.
CA04-5 is the destination data location.

Writing to CA00 starts the blit, and the byte written determines how the
data is blitted.

Bit 0 indicates that the source data is either laid out linear, one
pixel after the last, or in screen format, where there are 256 bytes from
one pair of pixels to the next.

Bit 1 indicates the same, but for the destination data.

I'm not sure what bit 2 does. Looking at the image, I can't tell, but
perhaps it has to do with the mask. My test files only used a mask of $FF.

Bit 3 tells the blitter only to blit the foreground- that is, everything
that is not color 0. Also known as transparency mode.

Bit 4 is 'solid' mode. Only the color indicated by the mask is blitted.
Note that this just creates a rectangle unless bit 3 is also set, in which
case it blits the image, but in a solid color.

Bit 5 shifts the image one pixel to the right. Any data on the far right
jumps to the far left.

Bits 6 and 7 only blit every other pixel of the image. Bit 6 says even only,
while bit 7 says odd only.
 
Last edited:
that makes sense. then i'm going to assume the ram must be slower than spec, nowadays. what you'll notice on robotron is brains that get "stuck" and don't fire. or tank waves where hardly any shots are fired before you pick them off at high levels. makes the game kind of boring actually.....

my one buddy that has a normal speed robotron is wanting to go for some 5 man tournament runs from the other friend's "slow" robotron. can't see why that wouldn't be "legal" per TG.

This is the reason I was looking for a consensus that there is no change in the speed of anything on-screen. The last thing I need to so go through all this trouble to find out down the line that something was changed.

I just need a reliable board that is "legal". It will be played/practiced on by the previous tournament record holder(Abdner Ashman) once he gets serious about getting his record back.

Darren Harris
Staten Island, New York.
 
Back
Top Bottom