[petrus bitbyter]

Really? Ugh - confusing!


Same board, yup (well, same design, same manufacturer, etc).


Same GAL type: GAL16V8D - not sure what speed or brand he used though
as he's not replying to his emails.


I'll quote from the chap who came up with the JEDEC:

"All ROM and RAM on this Memory Board is initially decoded by the
82s153 FPLA at location U10. The FPLA enables address decoders based
on the upper 3 address bits of the address bus. Additionally, the FPLA
prevents ROM and RAM access during certain system processes including:
refresh cycles, active resets, I/O requests and a architecture
specific signal called /BUZOFF. The FPLA contains 5 address inputs and
7 status line inputs. Outputs of the FPLA are 4 decoder enable lines
and 1 transceiver direction select line. The enable line for ROMs X1
through X4 (74LS139 at U8, pin 1) is selected on addresses x0000-x3fff
( !a15, !a14). The 4 ROMs are then selected off of a13 and a 12 by the
lower half of the 139 decoder at U8. All the other selects work
similarly. The second half of U8 (pin 15, enable) selects ROMs X5-X8
(a15, !a14), the lower half of U9 (pin 1, enable) selects the ROMs at
X9 and X10 (a15, a14, !a13)and the upper half of U9 (pin 15 enable)
selects one of the 4 RAMs (a15, a14, a13) based on address lines a11
and a12).

The FPLA also selects the direction of the 74ls245 transceiver at U17.
On a write, pin 1 of U17 is held high to allow data to flow from the
processor data bus to the RAM/ROM board data bus, on a read the line
is held low and the data flows in the opposite direction. Most of the
additional circuitry on the ROM board deals with selecting the RAM at
X21 for high score and setup information. The three 74ls244s at U16,
U15 and U 11 are all used as line drivers with all of their select
lines tied low permanently.

The original FPLA used is a Signetics 82s153, which is now obsolete, a
modern replacement is a Signetics pls153, however I have not been able
to get a good copy of one so I had to write a replacement using a PLD
(GAL16V8D)."


Here it is from the guy's site:

http://web.archive.org/web/20020331203553/http://my.erinet.com/~jamesm/tech/roto/roto.jed


I don't know how to extract a page or two from a PDF, but the whole
manual (12 MBytes! with schems at the end) can be found in this file:

http://arcarc.xmission.com/PDF Arcade Manuals and Schematics/Robby Roto.pdf

you'll need to look at the for the 'Memory Board'. The device in
question is the PLS at location U10

BTW, the quality of the schems is poor in places, but just about
readable.


Many thanks.

I'm really puzzled. Had a look at the schematics. The device is supposed to
do straight forward address decoding. No latches, no tricks no reason to
think the GAL to be too fast. Had a look at the JEDEC as well. Did not check
it out up to the last bit but as far as I can see it is programmed to do
what the GAL guy said. What's more, a correctly programmed GAL should be
pin-compatible with the original 82S153. There's only one nasty possibillity
I can think about: there have been GALs on the market that did not meet the
full specs due to a mask fault. The company made new masks and sold the old
ones to another firm that used them to made there own GALs, including the
flaw. I never had a problem myself so it's only hearsay. Besides I'm not
sure the D-types were effected, but you may have run into this old problem.

You can make some hardware to compare the 82S153 and the GAL16V8D. An EPP
printerport, some LS364 latches and a LS245 buffer on a breadboard is all
you need. Feed the DUT with a counter, read back all outputs and save the
results on disk. Read the next device and compare the results.

Can't you find someone with a programmer that can read the old 82S153? It's
only combinatotial logic and FAIK they had no security bit. Somewhere I
still should have the software to make equationfiles from the JEDEC. It's
easier then building hardware.

petrus bitbyter

 

[matt]

I'm really puzzled. Had a look at the schematics. The device is supposed to
do straight forward address decoding. No latches, no tricks no reason to
think the GAL to be too fast. Had a look at the JEDEC as well. Did not check
it out up to the last bit but as far as I can see it is programmed to do
what the GAL guy said. What's more, a correctly programmed GAL should be
pin-compatible with the original 82S153. There's only one nasty possibillity
I can think about: there have been GALs on the market that did not meet the
full specs due to a mask fault. The company made new masks and sold the old
ones to another firm that used them to made there own GALs, including the
flaw. I never had a problem myself so it's only hearsay. Besides I'm not
sure the D-types were effected, but you may have run into this old problem.

I've tried three different types of GALs now (all different speeds
too) but the results are the same. So presumably that means I don't
have a faulty one - or do you mean that the guy who came up with the
original JEDEC was maybe using a faulty GAL?

You can make some hardware to compare the 82S153 and the GAL16V8D. An EPP
printerport, some LS364 latches and a LS245 buffer on a breadboard is all
you need. Feed the DUT with a counter, read back all outputs and save the
results on disk. Read the next device and compare the results.

I wouldn't know where to start there I'm afraid - not without a
schematic (and no, that's not a hint

Can't you find someone with a programmer that can read the old 82S153? It's
only combinatotial logic and FAIK they had no security bit. Somewhere I
still should have the software to make equationfiles from the JEDEC. It's
easier then building hardware.

Very true - I'll ask around.


Thanks for your help.

 

[matt]

To follow-up on this - firstly I haven't made up that 'slowdown'
circuit yet, as I've finally managed to contact the guy who came up
with the JEDEC and it transpires that he used a 10ns GAL, so I guess
my 25ns may be too slow?

I've also tried 7ns and 15ns GALs but to no avail.

Perhaps I need to get hold of and try a 10ns GAL?

BTW, is there a JEDEC editor for Windows that a GAL 'dunce' like me
could use?

 

[[email protected]]

The board is okay as it works with the original 82S153 (which I can't
dump and don't have a replacement for - I'm testing the GAL on this
board but it will be going on another board (same type) as that one
has a bad 82S153).

I'm guessing that that guy who created the JEDEC file (a few years ago
now) used a slower GAL.

Maybe your board isn't actually the same as his. There might have been
some minor change.

Maybe you could send the other guy one of your surplus of programmed
GALs and ask him to test it, or even reprogram it for you?

Since you have the working chip, this really would be a good time to
build yourself a truth table extractor using a parallel port - perhaps
even use one of your extra GALs as an I/O expander. Good project,
you'll learn a lot, and likely find a way in which the file you
programmed your GAL with does not duplicate the functionality of the
original.

 

[matt]

Maybe your board isn't actually the same as his. There might have been
some minor change.

That's possible, but I'm not aware of any changes made to this
particular PCB (Robby Roto was never a popular arcade game).

Maybe you could send the other guy one of your surplus of programmed
GALs and ask him to test it, or even reprogram it for you?

Hmmm, yes - good idea.

Since you have the working chip, this really would be a good time to
build yourself a truth table extractor using a parallel port - perhaps
even use one of your extra GALs as an I/O expander. Good project,
you'll learn a lot, and likely find a way in which the file you
programmed your GAL with does not duplicate the functionality of the
original.

To be honest I wouldn't know where to start - although some schematics
would help. Do any exist on the 'net - a quick search doesn't turn up
anything.

 

[[email protected]]

That's possible, but I'm not aware of any changes made to this
particular PCB (Robby Roto was never a popular arcade game).

I doubt the board is unique to Robby Roto. It's probably used in a
whole range of games from that maker. More interesting question is if
they made all the Robby Roto's at once, or if a Robby Roto consist of
Assy-547, Assy-628, Assy-71 (with rom #521) etc... and could be put
together from these more generic stock components at any time over
several years. You might also have a replacement for a failed original
memory board?

To be honest I wouldn't know where to start - although some schematics
would help. Do any exist on the 'net - a quick search doesn't turn up
anything.

Read up on parallel port interfacing. Start by learning to turn some
LED's on and off under software control. Learn to read the state of
the status inputs. You may not have enough bits for all the inputs and
outputs, in which case you have the option of using a switch for the
unused input and manually changing it partway through the run. You can
also change the inputs back to the computer - maybe only read half the
chip outputs at a time. Or you can program one of your GALs to
multiplex the signals, but that's a more involved project.

By the way, this is easier with a windows 98 (or dos) or earlier PC,
though there are dirvers such as giveio which will let you program the
parallel port in windows XP.

 

[matt]

I doubt the board is unique to Robby Roto. It's probably used in a
whole range of games from that maker.

In this case it is as Robby Roto and a few others all shared four of
the stacked boards, while there were two other boards in the rack that
are unique to each game. In this case it's the Memory Board that I'm
having problems with which is unique to Robby Roto.

More interesting question is if
they made all the Robby Roto's at once, or if a Robby Roto consist of
Assy-547, Assy-628, Assy-71 (with rom #521) etc... and could be put
together from these more generic stock components at any time over
several years. You might also have a replacement for a failed original
memory board?

It's definitely an original - matches the schems, serial nos, etc.

Read up on parallel port interfacing. Start by learning to turn some
LED's on and off under software control. Learn to read the state of
the status inputs. You may not have enough bits for all the inputs and
outputs, in which case you have the option of using a switch for the
unused input and manually changing it partway through the run. You can
also change the inputs back to the computer - maybe only read half the
chip outputs at a time. Or you can program one of your GALs to
multiplex the signals, but that's a more involved project.

Sounds simple.

By the way, this is easier with a windows 98 (or dos) or earlier PC,
though there are dirvers such as giveio which will let you program the
parallel port in windows XP.

Thanks - yes, I'm on XP Pro.

 

[Sambo]

In this case it is as Robby Roto and a few others all shared four of
the stacked boards, while there were two other boards in the rack that
are unique to each game. In this case it's the Memory Board that I'm
having problems with which is unique to Robby Roto.




It's definitely an original - matches the schems, serial nos, etc.

Hmm, was wondering if the ram or rom wasn't different speed.

If the other person used 10ns chips and it worked, then 7 or 15ns should be close enough for a 1.8Mhz design.
Sounds like logic check is in order. What programmer are you using.
Why can't the programmer be used to read the truth table, unless it is something hobby grade as the galblast I found on the net.

Cheers

 

[petrus bitbyter]

In this case it is as Robby Roto and a few others all shared four of
the stacked boards, while there were two other boards in the rack that
are unique to each game. In this case it's the Memory Board that I'm
having problems with which is unique to Robby Roto.


It's definitely an original - matches the schems, serial nos, etc.


Sounds simple.


Thanks - yes, I'm on XP Pro.

Checked out the JEDEC and the schematic as far as I can and found no
contradictions. The memory map looks like:

0000-3FFF X1-X4
8000-BFFF X5-X8
C000-CFFF X9-X10
E800-FFFF X22-X24 Write
E000-FFFF X21-X24 Read

Apparently X21 will not be written, that is to say, not by using this
address decoder.

The more I see about it, the more I get the feeling your GAL is not
correctly programmed. Do you have any possibillity to read back your GAL by
another programmer and check whether the JEDEC is read back correctly? If
not, the best you can do is building the hardware I mentioned before. But,
drawing a schematic is no big problem. Not to me. But... then it has to be
build and hooked up to a PC. I would fire up an old DOS machine and write a
quick and dirty GWBASIC or maybe TURBOC program to read the components.
That's a lot of work, guess at least a full day. So if you want the
schematic, just say it.

BTW to learn about parallel port programming (and many other things) look at
http://www.beyondlogic.org/

For your application I like to use the EPP-port best.

petrus bitbyter

 

[matt]

Hmm, was wondering if the ram or rom wasn't different speed.

All the 6116's on the board are HM6116LP-4

If the other person used 10ns chips and it worked, then 7 or 15ns should be close enough for a 1.8Mhz design.
Sounds like logic check is in order. What programmer are you using.

A Galep-4 .....

http://www.conitec.com/galep4.htm

Why can't the programmer be used to read the truth table, unless it is something hobby grade as the galblast I found on the net.

Read it from the original 82S153 you mean? If so, afraid it can't
handle that device.

Thanks

 

[matt]

Checked out the JEDEC and the schematic as far as I can and found no
contradictions. The memory map looks like:

0000-3FFF X1-X4
8000-BFFF X5-X8
C000-CFFF X9-X10

Almost - it's C000-DFFF for X9-X10 - a fault in the JEDEC perhaps?

E800-FFFF X22-X24 Write
E000-FFFF X21-X24 Read

Apparently X21 will not be written, that is to say, not by using this
address decoder.

The 6116 at location X21 is battery backed and used to store high
scores, game settings, etc.

The more I see about it, the more I get the feeling your GAL is not
correctly programmed. Do you have any possibillity to read back your GAL by
another programmer and check whether the JEDEC is read back correctly?

Afraid not, no.

However, it verifies okay with the existing programmer - a Galep-4,
details here on that programmer:

http://www.conitec.com/galep4.htm

If
not, the best you can do is building the hardware I mentioned before. But,
drawing a schematic is no big problem. Not to me. But... then it has to be
build and hooked up to a PC. I would fire up an old DOS machine and write a
quick and dirty GWBASIC or maybe TURBOC program to read the components.
That's a lot of work, guess at least a full day. So if you want the
schematic, just say it.

Thanks for the kind offer - I don't though want to put you to any
unnecessary trouble so let's see how it goes as to alternative
solutions.

BTW to learn about parallel port programming (and many other things) look at
http://www.beyondlogic.org/

For your application I like to use the EPP-port best.

Many thanks.


Cheers

 

[petrus bitbyter]

Almost - it's C000-DFFF for X9-X10 - a fault in the JEDEC perhaps?


The 6116 at location X21 is battery backed and used to store high
scores, game settings, etc.


Afraid not, no.

However, it verifies okay with the existing programmer - a Galep-4,
details here on that programmer:

http://www.conitec.com/galep4.htm


Thanks for the kind offer - I don't though want to put you to any
unnecessary trouble so let's see how it goes as to alternative
solutions.


Many thanks.


Cheers

C000-CFFF X9-X10 must be C000-DFFF X9-X10
no JEDEC fault, a petrus typo.

The conitec site seems to have problems at the moment. But FAIK the Galep is
a decent programmer. Guess you kept your software up to date. I'm out of
ideas for the moment

petrus bitbyter

 

[matt]

C000-CFFF X9-X10 must be C000-DFFF X9-X10
no JEDEC fault, a petrus typo.


The conitec site seems to have problems at the moment. But FAIK the Galep is
a decent programmer. Guess you kept your software up to date. I'm out of
ideas for the moment

Hmmm, I can access the site okay.

Yes, the Galep is a decent programmer so I would have thought it would
be okay.

Here's a thought - if I was to get the 82S153 dumped, what would be
involved in turning it into a JEDEC?

 

[Sambo]

All the 6116's on the board are HM6116LP-4




A Galep-4 .....

http://www.conitec.com/galep4.htm

hmm. the one I have been dreaming about for 2 or 3 years. Over time I guess I transposed verifying devices to reading any device truth table.

Read it from the original 82S153 you mean? If so, afraid it can't
handle that device.

Thanks

Perhaps this is a good time to fire a message to them to provide a program that
can be configures for input/output pins and reading truth tables and then I'll purchase it.

 

[matt]

Perhaps this is a good time to fire a message to them to provide a program that
can be configures for input/output pins and reading truth tables and then I'll purchase it.

Would that be relatively easy to code?

 

[Sambo]

Would that be relatively easy to code?

With their "UNIVERSAL PIN DRIVER TECHNOLOGY" should be a piece of cake.
This could be also used for testing regular logic ICs.

 

[Sambo]

Would that be relatively easy to code?

With their "UNIVERSAL PIN DRIVER TECHNOLOGY" should be a piece of cake.
This could be also used for testing regular logic ICs.

I have read some time ago about one of those new programmable chips ( little more analog than the rest ) and said to myself "this would be perfect for the heart of a programmer".
If one of those is the heart of Galep....
I emailed them asking about their plans to provide at least basic program that configures power , input and output pins and sends test pattern and reads the outputs, will see what they say. I have seen other programmers in the past, claming to be able to test TTLs and even RAMs.

Cheers

 

[matt]

With their "UNIVERSAL PIN DRIVER TECHNOLOGY" should be a piece of cake.
This could be also used for testing regular logic ICs.
I have read some time ago about one of those new programmable chips ( little more analog than the rest ) and said to myself "this would be perfect for the heart of a programmer".
If one of those is the heart of Galep....
I emailed them asking about their plans to provide at least basic program that configures power , input and output pins and sends test pattern and reads the outputs, will see what they say. I have seen other programmers in the past, claming to be able to test TTLs and even RAMs.

Any reply yet?

 

[Sambo]

Any reply yet?

Not a peep and I just realized that it is another product that suffers from devolution.
6 AAA? That does not sound like more power than 2x9V which should be about the same
space if not less. I know there are cons to putting batteries in parallel but nothing a WARNING and double pole switch couldn't fix