28 Oct
2011
28 Oct
'11
1 p.m.
Has anyone tried to read the data from the Mostek 3851 PSU (ROM, I/O)
used with the 3850? I am looking to replace these tiny computers with a
modern FPGA or similar...
Thanks,
John :-#)#
29 Oct
29 Oct
9:21 p.m.
On 10/28/2011 04:00 PM, John Robertson wrote:
Has anyone tried to read the data from the Mostek 3851
PSU (ROM, I/O)
used with the 3850? I am looking to replace these tiny computers with a
modern FPGA or similar...
Holy cow, I think you've just found something that a Data I/O UniSite
won't handle. That's, umm, really unusual. (1702s notwithstanding!)
-Dave
--
Dave McGuire
New Kensington, PA
10 p.m.
On 30 Oct 2011 at 0:21, Dave McGuire wrote:
Holy cow, I think you've just found something
that a Data I/O
UniSite won't handle. That's, umm, really unusual. (1702s
notwithstanding!)
At least it's NMOS and TTL-level compatible. I think you could take
a small microcontroller and an evening and get what the thing has to
offer.
--Chuck
10:24 p.m.
On 10/30/2011 01:00 AM, Chuck Guzis wrote:
True. And that'd be more fun. :)
-Dave
--
Dave McGuire
New Kensington, PA
Holy cow,
I think you've just found something that a Data I/O
UniSite won't handle. That's, umm, really unusual. (1702s
notwithstanding!)
At least it's NMOS and TTL-level compatible. I think you could take
a small microcontroller and an evening and get what the thing has to
offer.
10:35 p.m.
On 10/30/2011 01:23 AM, Chuck Guzis wrote:
On 30 Oct 2011 at 0:21, Dave McGuire wrote:
Oh yes, probably. Do you have a part number for those? I've got a
supported device list here...more than twenty thousand entries!
-Dave
--
Dave McGuire
New Kensington, PA
Holy cow, I think you've just found
something that a Data I/O
UniSite won't handle. That's, umm, really unusual. (1702s
notwithstanding!)
How about the IMP-16 CROMs? Again, I think it takes a separate rig
to read those. 
30 Oct
30 Oct
12:13 a.m.
Chuck Guzis wrote:
How about the IMP-16 CROMs? Again, I think it takes a
separate rig
to read those.
Dave McGuire wrote:
Oh yes, probably. Do you have a part number for
those? I've got a
supported device list here...more than twenty thousand entries!
The "generic" part number for an IMP CROM is MM4751 or MM5751, with the
4 vs. 5 designating military vs. commercial, respectively, and with a D,
J, or N suffix designating glass/metal DIP, ceramic DIP, or plastic DIP,
respectively. They rarely had the MMx571 part number stamped on the
package, though. I think I've seen that exactly once.
The actual part numbers (sans the D/J/N package suffix) are:
Military Commercial Description
----------- ----------- -------------------------------------
IMP-8A/420 IMP-8A/520 IMP-8 CROM
IMP-16A/421 IMP-16A/521 IMP-16 basic instruction set CROM
IMP-16A/422 IMP-16A/522 IMP-16 extended instruction set CROM
IMP-16A/423 IMP-16A/523 IMP-16 POWER I/O CROM
IMP-16A/424 IMP-16A/524 IMP-16 Arithmetic CROM
I don't have any definitive reference for the part number of the IMP-4 CROM.
29 Oct
29 Oct
11:56 p.m.
Chuck Guzis wrote:
How about the IMP-16 CROMs? Again, I think it takes a
separate rig
to read those.
You can't easily get all of the microprogram out of those electrically,
because part of the microword is interpreted internally by the
microsequencer. It's probably easiest to read them by decap and
microscope. I've got spares of the basic and extended instruction set
CROMs, so I might do this. I only have one of the "POWR I/O" CROM, so I
don't want to sacrifice it. I haven't ever found the CROMs for the
IMP-4 and IMP-8, unfortunately.
Similarly, the decode PLAs of the CP1611 control chips for the PDP-11
and AM100 (WD16) and the CP2151 control chip of the WD90/900/9000 Pascal
Microengine need to be extracted. Reading the MICROMs (CP1631, CP2171)
is relatively easy.
30 Oct
30 Oct
10:24 a.m.
On 29 Oct 2011 at 23:56, Eric Smith wrote:
You can't easily get all of the microprogram out
of those
electrically, because part of the microword is interpreted internally
by the microsequencer. It's probably easiest to read them by decap
and microscope. I've got spares of the basic and extended instruction
set CROMs, so I might do this. I only have one of the "POWR I/O"
CROM, so I don't want to sacrifice it. I haven't ever found the CROMs
for the IMP-4 and IMP-8, unfortunately.
Looking at the datasheet, I wonder if applying some smarts to the
readout process might get pretty much all that's needed. I'm not in
a position to say either way, as I don't have access to any CROMs--I
just remember them from "back when".
--Chuck
12:06 p.m.
Holy cow, I
think you've just found something that a Data I/O
UniSite won't handle. That's, umm, really unusual. (1702s
notwithstanding!)
How about the IMP-16 CROMs? Again, I think it takes a separate rig
to read those.
6:37 p.m.
Tony Duell wrote:
Or the HP512*8 or 256*16 masked ROMS that were used in the 9800
calculators and HP instruemtns of the early-mid 1970s (there's one in the
59309 digial clock for the HPIB state machine). Theyr'e mostly TTL
compatible, but have enalbe inputs you have to take to +12V, and need a
-2V bias supply.
My experience is that programemrs will only 'officially' read the devices
thay can program, which of course excludes masked ROMs. If a masekd ROM
can be read as some programamble device (say a 2316 which cna be red a a
2716, etc), then the prgorammer will read them. But if there never was a
user-prgoramamble version (as in the case of the above devices), then
it's unlikely that a programmer will be set up to read them.
-tony
I have an early Xeltek SuperPro (had the special PC card) and at the
time bought also their Algorithym Generator program that they were
letting out at the time - and is no longer available as far as I know
(but haven't asked). This program would enable you to set up the
SuperPro to read or write to any device, up to 40 pins, that would match
the programmable parameters of the old SuperPro - which had a number of
pins that it could designate as various Vcc voltages, and others that
could be clock, etc.
Each pin was not completely programable, but I was able to read 6530s on
the device (which is now in storage), and thinking about it, it may be
time to see if the programming program works with any of their later
Superpros...hmm...ANOTHER project. However this one looks like fun!
In case anyone needs it, I do have the ability to both read and write
1702s - I have two burners for that. One is from Andromeda Research -
that can only read 1702s (handy for archiving). The other is a Pro-Log
with the 1702 module, this worked the last time I fired it up - a few
years ago - for a customer.
John :-#)#
--
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
www.flippers.com
"Old pinballers never die, they just flip out"
Holy cow, I think you've just found something
that a Data I/O
UniSite won't handle. That's, umm, really unusual. (1702s
notwithstanding!)
How about the IMP-16 CROMs? Again, I think it takes a separate rig
to read those.
29 Oct
29 Oct
11:51 p.m.
John Robertson wrote:
Has anyone tried to read the data from the Mostek 3851
PSU (ROM, I/O)
used with the 3850? I am looking to replace these tiny computers with a
modern FPGA or similar...
Dave McGuire wrote:
Holy cow, I think you've just found something
that a Data I/O
UniSite won't handle.
That's, umm, really unusual. (1702s
notwithstanding!)
Not particularly unusual. The MK3851 (and F3851) are not
field-programmable devices. There are a zillion non-field-programmable
devices that the Unisite can't read, as it was intended for
field-programmable devices.
I've read 3851 chips in the late 1980s, using an R6511Q 8-bit
microcontroller programmed to generate the appropriate bus signals. I
don't seem to have saved the code I wrote for it.
The more tricky problem was reading the code from an MK3870 single-chip
micro. When I did that, I didn't have a fast enough microcontroller, so
I used a board full of hardwired logic. Now there are plenty of
microcontrollers fast enough, and I have some more MK3870 series chips
that need to be read, so I need to design a new reader.
30 Oct
30 Oct
8:50 p.m.
From: eric at brouhaha.com
---snip---
The more tricky problem was reading the code from an MK3870 single-chip
micro. When I did that, I didn't have a fast enough microcontroller, so
I used a board full of hardwired logic. Now there are plenty of
microcontrollers fast enough, and I have some more MK3870 series chips
that need to be read, so I need to design a new reader.
Hi Eric
If you setup to do the 3870, I have a video brain that I've always wanted
to extract the code from. I believe it had a 3870 as I recall.
Dwight
2 Nov
2 Nov
5:44 p.m.
John Robertson wrote:
Has anyone tried to read the data from the Mostek
3851
PSU (ROM, I/O) used with the 3850?
I've read them in the past. Must have been around 1992 or so. I used a
single-board computer based on the R6511Q microcontroller (6502-based),
and wired the 3851 bus to GPIO port pins. There was simple firmware in
6502 assembly language, and it output the contents in S-record format
out a serial port. The firmware generated all of the control signals
for the 3851, including the clock, by bit-banging. IIRC, there was a
minimum clock frequency spec for the 3851, but I didn't have any trouble
meeting it. I did NOT try to ensure that all clock cycles were the same
duration, which would have required cycle-counting various code paths,
but the 3851 didn't care.
Alas, I don't have the code any more, but that probably doesn't matter
much since it's unlikely that one could find a 6511Q board.
Regrettably I don't have time to develop another 3851 reader, but I
don't recall there having been anything fundamentally difficult about
it. Reading the 3870 single-chip micro is considerably more tricky.
3 Nov
3 Nov
9:41 a.m.
Eric Smith wrote:
John Robertson wrote:
Thanks, I hadn't considered minimum clock speed as a factor. I'll read
the data sheets deeper and check on that. If you could read them with a
6502 based system then I should be able to wire up an adapter for my
Fluke 9010A's 6502 pod to enable me to do a data dump...
Fortunately I have what appears to be the same code in the two 3851s as
in the redesigned 3870 board so reading those should give me useful code
(perhaps with slight address massaging) to work in the 38P70 test CPU.
Then on to designing a replacement for the 3870 once I have good code!
John :-#)#
--
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
www.flippers.com
"Old pinballers never die, they just flip out"
Has anyone tried to read the data from the Mostek
3851
PSU (ROM, I/O) used with the 3850?
I've read them in the past. Must have been around 1992 or so. I used
a single-board computer based on the R6511Q microcontroller
(6502-based), and wired the 3851 bus to GPIO port pins. There was
simple firmware in 6502 assembly language, and it output the contents
in S-record format out a serial port. The firmware generated all of
the control signals for the 3851, including the clock, by
bit-banging. IIRC, there was a minimum clock frequency spec for the
3851, but I didn't have any trouble meeting it. I did NOT try to
ensure that all clock cycles were the same duration, which would have
required cycle-counting various code paths, but the 3851 didn't care.
Alas, I don't have the code any more, but that probably doesn't matter
much since it's unlikely that one could find a 6511Q board.
Regrettably I don't have time to develop another 3851 reader, but I
don't recall there having been anything fundamentally difficult about
it. Reading the 3870 single-chip micro is considerably more tricky.
12:19 p.m.
John Robertson wrote:
Eric Smith wrote:
Ah, worse than I thought. One has to send a sequence of data to the 3851
to read each byte. Gah. I don't have the programming skills to do this,
nor the time to learn right now...
John :-#(#
John Robertson wrote:
Thanks, I hadn't considered minimum clock speed as a factor. I'll read
the data sheets deeper and check on that. If you could read them with
a 6502 based system then I should be able to wire up an adapter for my
Fluke 9010A's 6502 pod to enable me to do a data dump...
Fortunately I have what appears to be the same code in the two 3851s
as in the redesigned 3870 board so reading those should give me useful
code (perhaps with slight address massaging) to work in the 38P70 test
CPU. Then on to designing a replacement for the 3870 once I have good
code!
John :-#)#
Has anyone tried to read the data from the Mostek
3851
PSU (ROM, I/O) used with the 3850?
I've read them in the past. Must have been around 1992 or so. I
used a single-board computer based on the R6511Q microcontroller
(6502-based), and wired the 3851 bus to GPIO port pins. There was
simple firmware in 6502 assembly language, and it output the contents
in S-record format out a serial port. The firmware generated all of
the control signals for the 3851, including the clock, by
bit-banging. IIRC, there was a minimum clock frequency spec for the
3851, but I didn't have any trouble meeting it. I did NOT try to
ensure that all clock cycles were the same duration, which would have
required cycle-counting various code paths, but the 3851 didn't care.
Alas, I don't have the code any more, but that probably doesn't
matter much since it's unlikely that one could find a 6511Q board.
Regrettably I don't have time to develop another 3851 reader, but I
don't recall there having been anything fundamentally difficult about
it. Reading the 3870 single-chip micro is considerably more tricky.
4 Nov
4 Nov
1:20 a.m.
John Robertson wrote:
I hadn't considered minimum clock speed as a
factor.
The 3851 maximum clock period is 10 us (i.e., minimum clock frequency
100 kHz). I think I was probably running the 6511Q at 2 MHz. (Maybe it
was a 6511AQ.) I probably wasn't actually meeting the 3851 maximum
clock period spec; I don't remember what the actual timing ended up at.
At 5V and room temperature, the part will probably operate OK to a fair
bit slower than the spec.
Fortunately I have what appears to be the same code in
the two
3851s as in the redesigned 3870 board so reading those should
give me useful code (perhaps with slight address massaging) to
work in the 38P70 test CPU. Then on to designing a replacement
for the 3870 once I have good code!
Bear in mind that the timer in the 3851 works differently than the timer
in the 3870 series, so any code using the timer may not be portable
between the two. The 3851 timer is a twisted ring counter, so it
doesn't count in normal sequential binary. The count sequence is given
in the documentation. The 3870 counter is a binary counter.
4797
days inactive
4804
days old
16 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
dkelvey＠hotmail.com -
eric＠brouhaha.com -
mcguire＠neurotica.com -
pinball＠telus.net