Monitor ROM

29 views
Skip to first unread message

Bill Beech (NJ7P)

unread,
Feb 26, 2021, 2:53:01 PM2/26/21
to intel-...@googlegroups.com
Guy,

I have created the source code for the iSBC 80/30 version of Monitor
from the disassembly of the ROM image and the source code I had for the
iSBC 80/30 version of the MON830 module.  Some significant changes
between them.  This source code assembles with the Intel assembler and
the code generated is identical to the ROM image!

Now for the Editor and Assembler.

Bill

MON810.asm
MON810.lst

mark.p...@btinternet.com

unread,
Feb 26, 2021, 3:29:58 PM2/26/21
to intel-...@googlegroups.com
Bill
Which versions are the editor/assembler?
It would be interesting to see how different they are from the v1.1 versions I decompiled and place on my Github site.
Regards
Mark
--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/4cf5d53a-fe43-be6b-591d-3b3a1396ce47%40nj7p.info.

Bill Beech (NJ7P)

unread,
Feb 26, 2021, 3:46:24 PM2/26/21
to intel-...@googlegroups.com
Mark,

They are both V 1.2, which we don't have.  But I thought I would use the
V1.1 from the i8SBC 210 ROM image, if we have created source.  OOPS! 
That source is just a basic disassembly.  Do you have reverse engineered
source for the v1.1 editor and assembler?

Bill

Bill Beech (NJ7P)

unread,
Feb 26, 2021, 4:55:57 PM2/26/21
to intel-...@googlegroups.com
Mark,

Oops! the ROM Editor is v 2.0.  The ROM Assembler is v 1.2. Sorry!

Bill

mark.p...@btinternet.com

unread,
Feb 26, 2021, 6:02:08 PM2/26/21
to intel-...@googlegroups.com
Bill
The 1.1 versions are under edasm_1.1 and isis_1.1 contains similar versions
Note both used the older fortran based PLM compiler which is harder to reverse engineer as it takes advantage of non relocate levels code to do minor optimisations, e.g. inr/dcr h and l also mvi l,xx instead of inx/dcx h and lxi h,xxxx
The calling convention is also different and doesn’t use the stack for arg3 onwards
Mark

Regards
Mark
From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Bill Beech (NJ7P) <nj...@nj7p.info>
Sent: Friday, February 26, 2021 9:54:50 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>
Subject: Re: intel-devsys Monitor ROM
 

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 12:24:43 AM2/27/21
to intel-...@googlegroups.com

Mark,

Here is the rough disassembly of the ROM Editor V2.0.  Note there are undefined opcodes 08h, 18h, and 28h in the code.  I handle them with DB's.  But this is in a better version of PLM80, I believe.

If my analysis is correct the ROMs are in the wrong sockets..

Bill

EDIT.asm
edit.lst

mark.p...@btinternet.com

unread,
Feb 27, 2021, 3:22:25 AM2/27/21
to intel-...@googlegroups.com
Bill
Are you able to send the binaries so that I can lioad into IDA as this will make it easier to analyse

Mark

Regards
Mark Ogden
Sent: Saturday, February 27, 2021 5:23:32 AM

mark.p...@btinternet.com

unread,
Feb 27, 2021, 6:15:30 AM2/27/21
to intel-...@googlegroups.com

Bill

I manged to parse the edit.asm to extract the bin file from the hex listing at the top.

I have spotted one byte that I believe has bit rot, specifically location 0C67Bh, which I believe should be 0EBh rather than 0E9h. The pchl (0E9h) doesn’t make sense but the xchg (0E9h) does

Regards

Mark

mark.p...@btinternet.com

unread,
Feb 27, 2021, 6:43:17 AM2/27/21
to intel-...@googlegroups.com

Bill

Another bit rot location 0C4FD, it is 85h, I believe it should be 0C5h, also it looks like quite a few locations around this address are corrupt, for example

At 0C54Dh, the current values are 3Ch, AEh, I believe they should probably be 0BCh, 40h

It may be worth trying to read the image again.

 

Regards

Mark

 

 

 

From: mark.p...@btinternet.com <mark.p...@btinternet.com>
Sent: 27 February 2021 11:16
To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys Monitor ROM

 

Bill

I manged to parse the edit.asm to extract the bin file from the hex listing at the top.

I have spotted one byte that I believe has bit rot, specifically location 0C67Bh, which I believe should be 0EBh rather than 0E9h. The pchl (0E9h) doesn’t make sense but the xchg (0E9h) does

Regards

Mark

 

 

Sent: 27 February 2021 08:22

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 2:05:36 PM2/27/21
to intel-...@googlegroups.com

Mark,

Certainly!  Here you go!

Bill

edit.rom

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 2:09:24 PM2/27/21
to intel-...@googlegroups.com

Mark,

I suspect there may be more bit rot in that file.  I have 08h, 18h and 28h values where they make no sense.  I DB them because the assembler ate 3 bytes for a 1 byte value which really messed things up.  I guess I was lucky on the Monitor ROM.

Bill

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 2:24:38 PM2/27/21
to intel-...@googlegroups.com

Mark,

Okay.  Bit rot confirmed on second EPROM 576.  First EPROM 575 verified against read in programmer.  Second EPROM did not, failing at 21H bytes in.  I sent you several copies of that EPROM.

Bill

104576-001.bin
104576-001-2.bin
104576-001-3.bin
104576-001-4.bin
104575-001.bin

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 2:49:31 PM2/27/21
to intel-...@googlegroups.com

Mark,

I believe this is P009 from plm80.lib...

Bill

Herb Johnson

unread,
Feb 27, 2021, 3:32:12 PM2/27/21
to intel-...@googlegroups.com, Bill Beech (NJ7P)
On 2/27/2021 2:23 PM, Bill Beech (NJ7P) wrote:
> Mark,
>
> Okay.  Bit rot confirmed on second EPROM 576.  First EPROM 575 verified
> against read in programmer.  Second EPROM did not, failing at 21H bytes
> in.  I sent you several copies of that EPROM.
>
> Bill
> I believe this is P009 from plm80.lib...
>
> Bill


When I display hex-dumps of those binaries, and visually switch between
them, I see multiple bytes that change. Qualitatively, they seem to be
single-bit errors, and don't seem to be very consistent. But discerning
a pattern is moot. This is a damaged ROM, the damage is just its
circumstances.

Bill, if you can or have identified the PL/M source, or another binary
ROM, then you have a basis from which to pick off the errors. Otherwise,
it would be a matter of several disassemblies and some informed guesses
as to the correct instructions among them. That would be my strategy.

Regards, Herb

Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT comcast DOT net

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 3:45:08 PM2/27/21
to Herb Johnson, intel-...@googlegroups.com
Herb,

Yes, that ROM is a mess.  But the V2.0 ROM code is probably the last ROM
version created.  I would like to restore t, so I am looking at the
other versions of EDIT.  Since V1.1 is for the old Fortran version of
PLM compiler, I am looking at V1.6 which is about the same length.  Same
length may indicate few changes!?!?

Bill

mark.p...@btinternet.com

unread,
Feb 27, 2021, 3:54:36 PM2/27/21
to intel-...@googlegroups.com, Herb Johnson
Bill
I was able to look at the code and large chunks seem ok.
When I wrote my initial email I did so from memory. Fortunately was not completely correct. The edit 1.0 for isis I was in the old plm dialect, the rom based one is actually in the new version.
One of the key changes is around the I/O which uses a vector approach in the new version rather than directly calling the Bios
Mark 

Regards
Mark Ogden
Sent: Saturday, February 27, 2021 8:44:00 PM
To: Herb Johnson <hjoh...@retrotechnology.com>; intel-...@googlegroups.com <intel-...@googlegroups.com>

Subject: Re: intel-devsys Monitor ROM
--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 4:43:05 PM2/27/21
to intel-...@googlegroups.com

Mark,

I got got tracking in the bad ROM with the ISIS V1.6 1978.  Of course, the OS hooks are going to be different.  Good deal on the 1.1 being in the right PLM compiler version.  It should match right up, except for the addresses used to org each version.  I will take a look at it...

Bill

Herb Johnson

unread,
Feb 27, 2021, 4:50:05 PM2/27/21
to intel-...@googlegroups.com, Bill Beech (NJ7P)
bill, attached are two documents.

1) a hex compare of two of your ROM files. The compares shows of course,
the addressed of differences in the ROM and the differences. There are
68 in number.

1. 104576-001.bin: 2,048 bytes
2. 104576-001-2.bin: 2,048 bytes


2) I took your edit.asm code, and extracted the portion related to the
ROM binary, determined by inspection. The ASM code appears to be
disassembled from the "1." file above. I have hand-disassembled
differences in the early part of that code, based on the entries in the
hex-compare for for the "2." file. My changes are in lower case, use the
addresses in the hex-compare file for guidance.

The results from the "2." file seem to make more sense.

3) Therefore I recommend you also disassemble the 104576-001-2.bin file
and work from that binary. See if that file produces "more sensible"
code, or if my results were a matter of luck.

4) otherwise use the hex-compare report to offer you alternatives to
issues in your edit.asm code.

Regards, Herb

On 2/27/2021 3:44 PM, Bill Beech (NJ7P) wrote:
> Herb,
>
> Yes, that ROM is a mess.  But the V2.0 ROM code is probably the last ROM
> version created.  I would like to restore t, so I am looking at the
> other versions of EDIT.  Since V1.1 is for the old Fortran version of
> PLM compiler, I am looking at V1.6 which is about the same length.  Same
> length may indicate few changes!?!?
>
> Bill
--
Report1.txt
alt.asm

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 5:16:16 PM2/27/21
to intel-...@googlegroups.com
Herb,

I am comparing the V2.0 to the V1.1.  Looks good in the assembler.  I
have included the files for V1.1 for you.

Now comparing these files, we see some small differences in the source
code.

Bill
EDIT.asm
edit.lst
edit.rom

Jack Mcmullen

unread,
Feb 27, 2021, 7:03:28 PM2/27/21
to intel-...@googlegroups.com
Guys,
when you have exhausted ROM read outs may I suggest trying to increase the 5v to the max allowed and maybe a tenth or two higher, same with the other +12or -12 or -5 and see if that corrects the rot bytes. Might get lucky
Jack


-----Original Message-----
From: Bill Beech (NJ7P) <nj...@nj7p.info>
To: intel-...@googlegroups.com
Sent: Sat, Feb 27, 2021 2:15 pm
Subject: Re: intel-devsys Monitor ROM

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/4803c8b4-c2c0-fa5d-d647-505c369e712f%40nj7p.info.

Herb Johnson

unread,
Feb 27, 2021, 7:25:38 PM2/27/21
to intel-...@googlegroups.com, Bill Beech (NJ7P)
There are a number of differences in the two ASM files, as you call them
V2.0 and V1.1. Those differences suggest to me, by visual observation,
that these are as you'd expect, slightly different versions of the same
sources. There are identical routines, almost identical routines, and
then some additional or modified routines.

But the differences are such, that the codes in the two assembly
programms, are not exactly address aligned. Further, the absolute
location of the two codes are 1000H different. These introduce some
additional variation between the binary codes of the two assembled
sources. It is very challenging, to work from the assembled V2.0 versus
the disassembled and known-flaky V1.1.

On a hunch: I hex-compared your 104576-001-3.bin and 104576-001-4.bin.
They are the same. That's informative. They are both different from -2
and the no-dash-number binaries. This suggests to me, Bill, that
something occurred during your read of this rom, from the no-dash, to
-2, to -3; and it did not occur between -3 to -4.

My hypothesis, is not "bit rot inside the EPROM" but "pin rot". That is,
the IC pins on the ROM are corroded; and that repeated inserts and reads
and time may have worked through the corrosion.

In my experiences, I've found MANY more IC's with some kind of corrosion
on the pins, than EPROMS that have flaky bits or lost bits. I'm
astonished by how tenacious EPROMs hold their data.

This suggests a strategy to me. Bill - I suggest you do a cycle of:

loop:
remove EPROM from reader;
clean pins;
insert EPROM into reader;
dump the contents to a binary file of incremented number;
compare that binary file to the previous;
if the compares fail, GOTO loop:

end when you get a stable number of identical reads.
THEN disassemble THAT stable-binary version, and work with that
disassembly source of the EPROM.

That's my suggestion. I continue to poke at the no-dash-numbered
disassembly but now look at the -3/nodash comprision; and glance at the
V2.0 source. But I think a new disassembly as described may be advisable.

Regards, Herb

On 2/27/2021 5:15 PM, Bill Beech (NJ7P) wrote:
> Herb,
>
> I am comparing the V2.0 to the V1.1.  Looks good in the assembler.  I
> have included the files for V1.1 for you.
>
> Now comparing these files, we see some small differences in the source
> code.
>
> Bill

Roger Arrick

unread,
Feb 27, 2021, 7:57:39 PM2/27/21
to intel-...@googlegroups.com
FYI, I have one of those cheapo chip readers from ebay called TL866CS.

It's pretty good and you can't beat it for $60 but it will NOT read my 450ns
2716's reliably. It tries but has dropouts all throughout the data. And it's
different every time.

It's possible they simply goofed on the timing parameter for 2716's and didn't
spec the slowest possible speed but I haven't confirmed that with a scope.
Seems to be just for 2716 in my case, other EPROMS like 2708 and 2732 read fine.

Roger in TX.
> an email to intel-devsys...@googlegroups.com.
> <mailto:unsub...@googlegroups.com.>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/intel-devsys/4803c8b4-c2c0-fa5d-d647-505c369e712f%40nj7p.info.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to intel-devsys...@googlegroups.com
> <mailto:intel-devsys...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/intel-devsys/1376359783.1157779.1614470602834%40mail.yahoo.com
> <https://groups.google.com/d/msgid/intel-devsys/1376359783.1157779.1614470602834%40mail.yahoo.com?utm_medium=email&utm_source=footer>.

Herb Johnson

unread,
Feb 27, 2021, 8:26:29 PM2/27/21
to intel-...@googlegroups.com, Roger Arrick
*2716's!?!?!?*

***2716's***!!!!

That explains it all. Thanks to my friends for calling this out.

2716's are the most non-standard UV EPROM every made. There's multiple
variations of the 2716, from brand to brand. They vary in DC voltages,
even in pinouts. And likely vary within a brand. And - they are only
faster than 2708's and 1702's.

Most modern EPROM programmers, can't even deal with 2716's. And most old
EPROM programmers, have several brand/speed variations to read 2716's.
*And*, if your old programmer has "tired" DC voltages or signals - and
that happens - well, game over.

The only thing worse than reading them, is *programming them*. The
programming pulses and their voltages are just crazy different.

Bill. Bill, listen. Put the EPROM programmer down, and step away from
the table.

What you gotta do, is look hard at the brand and speed of the UV EPROMS
you are reading. Then dig up the specs for that brand and speed. And
look hard at whatever EPROM reader/programmer you are using - as in,
*put an oscilloscope on the pins and check the voltages, especially the
DC voltages, especially during read*.

Our friends figured it out. Faulty voltages and signals on your EPROM
reader are likely contributing to the crap you are reading from this eprom.

So, you have to nail-down all these considerations, and get them right,
to read off this troublesome EPROM.

Speaking for myself, it's painful to look at different hex dumps and two
different sources; decide which single-bit errors produce a desirable
8080 instruction; and hand-disassemble until things make sense. It's a
thing I can do to a point.

But - if the problem is faulty reading of the EPROM, the solution is to
*read the EPROM correctly*.

And all one has to define "correct" is 1) check voltages and signals, 2)
check the data sheets and 3) compare to whatever confirmed sources one
has. We don't have 4) another binary dump unfortunately.

Additionally? My previous advice: read, compare, repeat until *consistent*.

OK? I gotta run. Bill, the ball is in your court. Roger and Jack, thank
you VERY much.

Regards, Herb




On 2/27/2021 7:57 PM, Roger Arrick wrote:
> FYI, I have one of those cheapo chip readers from ebay called TL866CS.
>
> It's pretty good and you can't beat it for $60 but it will NOT read my
> 450ns 2716's reliably.  It tries but has dropouts all throughout the
> data.  And it's different every time.
>
> It's possible they simply goofed on the timing parameter for 2716's and
> didn't spec the slowest possible speed but I haven't confirmed that with
> a scope. Seems to be just for 2716 in my case, other EPROMS like 2708
> and 2732 read fine.
>
> Roger in TX.
>
>
>
> 'Jack Mcmullen' via intel-devsys wrote:
>> Guys,
>> when you have exhausted ROM read outs may I suggest trying to increase
>> the 5v to the max allowed and maybe a tenth or two higher, same with
>> the other +12or -12 or -5 and see if that corrects the rot bytes.
>> Might get lucky
>> Jack

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 10:08:42 PM2/27/21
to intel-...@googlegroups.com
Well, I find only ChipDocs has the B2716 datasheet for a modest $95 a
year.  Fuck that.  I guess I need to charge a dollar a tube on my site
so I make some money! Mercenary assholes!

Guess I will look in my Intel documents!

Bill

Jack Mcmullen

unread,
Feb 27, 2021, 10:47:20 PM2/27/21
to intel-...@googlegroups.com
Who is the 2716 chip manufactor? Most all chips of that ear still have data sheets floating around. Let me know if I can help ya search


-----Original Message-----
From: Bill Beech (NJ7P) <nj...@nj7p.info>
To: intel-...@googlegroups.com
--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/5276bfe1-a275-d298-86ee-3cea85743016%40nj7p.info.

Bill Beech (NJ7P)

unread,
Feb 27, 2021, 11:02:37 PM2/27/21
to intel-...@googlegroups.com

These are Intel B2716s.  So far, the good ones are (c) Intel '77.  The one we are having problems with is an Intel B2716 w/o copyright.  The pins are clean.  I did not remove it from the ZIF socket between reads.  Might be a read timing problem.  I am using a GQ-4x4 with external 9V PS so I can write these old 5V only EPROMS.

Bill

To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/1487936878.1173688.1614484034656%40mail.yahoo.com.

Bill Beech (NJ7P)

unread,
Feb 28, 2021, 12:12:42 AM2/28/21
to intel-...@googlegroups.com

I have tried every 2716 that my programmer supports.  A read followed by a verify always fails.

Bill

Jack Mcmullen

unread,
Feb 28, 2021, 1:50:33 AM2/28/21
to intel-...@googlegroups.com
Do you have a Mulibus board tjat has a monitor or that ISIS can access. Might be worth a try in its old environment
Jack


Jack Mcmullen

unread,
Feb 28, 2021, 1:52:32 AM2/28/21
to intel-...@googlegroups.com
I've got the Arvin U40 programmer. I wish we were close


Jon Hales

unread,
Feb 28, 2021, 5:48:03 AM2/28/21
to intel-...@googlegroups.com
EPROM reader / writer for 2716 and other early devices

I recommend the 'ME2700 Orphan Programmer'. It was designed by Martin Eberhard and he offers the bare board with the pre-programmed PIC18F45K20 for $35.

Here's the list of supported versions of the 2716 class (from the manual)

Type 06: 2716 2048x8 EPROM (Vcc=+5V, Vpp=25V)
AMD AM2716, Eurotechnique ET2716Q, Fujutsi MBM2716, Hitachi HN462716,
Intel 2716, Mitsubishi M5L2716K, MME U2716C, Motorola MCM2716, National
Semiconductor MM2716, NEC uPD2716, NTE NTE2716, Oki MSM2716AS, SGSThomson
M2716, Signetics 2716, Soviet 573RF2, Tesla MHB2716C, Texas
Instruments TMS2516, Thomson-Mostek ET2716Q, Toshiba TMM323D, Toshiba
TMM323DI

Type 07: 2716A 2048x8 EPROM (Vcc=+5V, Vpp=21V)
(No datasheets found)

Type 08: 2716A-fast 2048x8 EPROM (Vcc=+5V, Vpp=21V)
SGS-Thomson M2716A-fast

Type 09: 2716B 2048x8 EPROM (Vcc=+5V, Vpp=12.7V)
AMD AM2716B

Type 0A: 27C16H 2048x8 EPROM (Vcc=+5V, Vpp=25V)
Fairchild NMC27C16H, National Semiconductor NMC27C16H

Type 0B: 27C16B 2048x8 EPROM (Vcc=+5V, Vpp=12.7V)
Fairchild NMC27C16B

Type 0C: TMS2716 2048x8 EPROM (Vcc=+5V, Vbb=-5V, Vdd=+12V)
Motorola TMS2716, Texas Instruments TMS2716

This the only reader I'm aware about that makes it simple to check / adjust voltages. The manual is comprehensive and the software is excellent. Type 00 is the 2704. The device is designed to handle a maximum of 24 pins.

Martin Eberhard is usually approached via an Altair Computer Club (previously on Yahoo, I think now on Google).

Another device you may be interested to know about is the 'Professional Chip Tester' from 8Bit-Museum.de. This has the capability to read EPROMs (including 1702 with an adapter). It is not currently designed to write to devices and it's main purpose is to test whether an IC is functional. The list of ICs it can handle is extensive. The firmware is being developed at pace.

The designer supplies the board with an Atmel 2560 pre-soldered. The user is required to program the firmware.

Best regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/603AEA76.9040601%40Arrick.com.

mark.p...@btinternet.com

unread,
Feb 28, 2021, 6:21:45 AM2/28/21
to intel-...@googlegroups.com

All

A quick morning trawl of the internet lead to the following  data sheets for 2716

 

National Semiconductor DATASHEET SEARCH SITE | WWW.ALLDATASHEET.COM (archive.org)

STMicroelectronics 2716 EPROM Datasheet (futurlec.com)

Thomson IC Datasheet: 2716 EPROM - 2 (archive.org) & NMOS 16 KBIT (2KB X8) UV EPROM (usc.edu)

AMD http://pdf.datasheetcatalog.com/datasheets/1150/500342_DS.pdf & AM2716.pdf (free.fr)

Intel 2716 (sycelectronica.com.ar) & 2716EPROM.pdf (yatho.com) D2716-1 - Datasheet.Directory (ciiva.com) & M2716 Datasheet PDF Viewer. - Datasheet.Directory

NTE nte2716.pdf (nteinc.com)

Texas Instruments TMS2716.pdf (jrok.com)

 

Also a forum discussion on 2716 problems

What's up with 2716 EPROMs? - Page 1 (eevblog.com)

 

And a post about a viable alternative

28c16 EEPROM replacement for 2716 EPROM | Tech: Generic | Pinside.com

 

 

Mark

Herb Johnson

unread,
Feb 28, 2021, 1:13:09 PM2/28/21
to intel-...@googlegroups.com
Summary: Bill has an Intel type B 2716 no dash number EPROM, he can't
read consistently. Databook review suggests type B is just a plastic
package with a window. Intel 2716's are slow (no number = 450ns, slowest
spec is 650ns) and power hungry (100mA max at 5V during read). Those
specs may challenge Bill's EPROM reader. at least it's a 5-volt only
EPROM, no odd DC read voltages.

Bottom line suggestion: Bill should 'scope his EPROM programmer, to see
how fast/slow it runs its 2716 read cycle. Also to see if the DC voltage
5.0V is steady and the logic signals steady during the 2716 read cycle.
My guess is that the programmer is running too fast, or the DC voltages
are sagging due to age of the unit. OScilloscope readings will prove
this out. Details follow.

- Herb

So Bill says:

> These are Intel B2716s. So far, the good ones are (c) Intel '77. The one we are having problems with is an Intel B2716 w/o copyright. The pins are clean. I did not remove it from the ZIF socket between reads. Might be a read timing problem. I am using a GQ-4x4 with external 9V PS so I can write these old 5V only EPROMS.

> I have tried every 2716 that my programmer supports. A read followed by a verify always fails.

> [trouble finding a B2716 Intel data sheet]

So those are the facts we know. One other fact Bill can provide:

A photo of Bill's problem EPROM, both sides of the chip, may be more
informative. We may see a detail, or a date, or something. Also a photo
of the other EPROM, which *can* be read. There may be a difference
that's useful. This is just Hail-Mary stuff.

Suggestions posted and my responses to them.

1) "here's a bunch of Intel data sheets on the Web".

Fine to a point. They will say, here's some Intel 2716's and their
signaling. Sheets covering Intel 2716 during the late 70's are likely
the most relevant. We are only worried about read. The Intel data sheet
I found with the slowest (therefore oldest) 2716's is:

https://amigan.yatho.com/2716EPROM.pdf

Reading one Intel sheet now: Intel touts "single 5V supply". That's
good, no oddball DC voltages, and we aren't programming. Speeds of read:
vary depending on the -(number) spec, from -1 to 350ns to -6 for 650ns.
If there is no number the sheet says 450ns. Those are pretty slow.

https://deramp.com/downloads/mfe_archive/050-Component%20Specifications/Intel/Memory%20Components/1977%20Intel%20Memory%20Design%20Handbook.pdf

Application note for the 2716 is on page 153 of this handbook. It
suggests the (early) 2716 was a power-hog: 57 to 100mA max Vcc current!
And 525 milliwatts power consumption (5V 100mA confirms that). That may
tax Bill's programmer. The sheet discusses a 450ns read cycle; in
production I see how that might stretch to several hundred ns.

https://deramp.com/downloads/mfe_archive/050-Component%20Specifications/Intel/Memory%20Components/1976_Intel_Data_Catalog.pdf

The last pages of the databook describe "packaging information". Package
type B (Bill has a B2716) says :24-lead hermetic dual in-line package
type B". It has a windowed package that doesn't appear to be ceramic
(that's type C) or nonwindowed (that's type D) or plastic (type P).

------------------

Hypothesis: Bill's programmer may not be waiting long enough.

Test: put an oscilloscope on the EPROM during read to measure access time.

hypothesis: Programmer may have marginal signals or voltages.

premise: Old electronics have faulty caps which could cause issues.
premise: the Intel 2716 eats 100mA DC during read.

Test: observe the voltage levels and timing. Check 5VDC during read, see
if it sags. Same with the address and logic signals.

2) "here's a bunch of EPROM programmers Bill could obtain and try"
"wish I could read that EPROM for Bill".

I don't think Bill is gonna buy a specific EPROM programmer anytime
soon. Nor is he likely to mail his only EPROM to someone, I would not.

3) "Do you have a Multibus board that has a monitor or that ISIS can
access."

Bill has something better than that: a number of S-100 computers. He may
have a S-100 card set up for 2716's. Those may be slow enough to read a
slow EPROM. Or he can add a wait state. and they will be old enough to
provide plenty of Vcc current.

Beyond that, I don't know that Bill should jam that EPROM into oddball
boards and equipment. If he has some reliable single-board that supports
2716's, that's another matter. But past some point, this becomes another
project, and I don't think Bill is requesting new projects.

Plan Z

Plan Z would be for me to send Bill an ancient PROM programmer, After i
test it on ancient Intel 2716's I have around. That's all I've got.

Regards, Herb

Bill Beech (NJ7P)

unread,
Feb 28, 2021, 3:06:02 PM2/28/21
to intel-...@googlegroups.com

Well, that might be a good idea.  Just power up this computer and use its Monitor to read the ROMs on the ROM Memory board.  I have that on my todo list, but might raise the priority!

Thanks!

Bill

forjack842

unread,
Feb 28, 2021, 3:14:02 PM2/28/21
to intel-...@googlegroups.com
Like I said use a multibus card in a MDS box. Set jumpers. Use the monitor to read. Since no programming/writing is needed its sraight forward
Jack



Sent via the Samsung Galaxy A11, an AT&T 4G LTE smartphone


-------- Original message --------
From: Herb Johnson <hjoh...@retrotechnology.com>
Date: 2/28/21 10:13 AM (GMT-08:00)
Subject: Re: intel-devsys Monitor ROM - red alert

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

Bill Beech (NJ7P)

unread,
Feb 28, 2021, 3:28:44 PM2/28/21
to intel-...@googlegroups.com

Ah, but with your big move we are farther apart than ever.  But I could ship you the ROMs after I expend all efforts here.

And the ROM in question is one of the (c) Intel '77 EPROMS.  Not that any of that makes a difference.  With clean pins, a ROM that won't verify after a read, means we have a bad ROM, we have a timing problem with the reader, or a voltage problem with the reader.  This reader has worked with everything I have thrown at it to read or write without problem.  But these pesky 2716s are another story.

I have not yet found a datasheet on the Intel B2716.  I wonder what the 'B' indicates?

Bill

Bill Beech (NJ7P)

unread,
Feb 28, 2021, 3:56:08 PM2/28/21
to intel-...@googlegroups.com
But these EPROMS are all brown ceramic.

My GQ-4x4 has an external 9V PS to handle these older EPROMs power
requirements.

At least it is!  650 ns read time might be a problem.

Best idea was from Jack.  Power up the ROM board in something that read
the the multibus and the ROMS.  Like the original machine!  That is the
path I will take at this time.

Bill

mark.p...@btinternet.com

unread,
Feb 28, 2021, 4:00:28 PM2/28/21
to intel-...@googlegroups.com
All
A site with pictures of the 2716 variants
https://www.cpu-galaxy.at/CPU/Ram%20Rom%20Eprom/ROM/Intel%202716%20section.htm
Mark


-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Bill Beech (NJ7P)
Sent: 28 February 2021 20:55
To: intel-...@googlegroups.com
Subject: Re: intel-devsys Monitor ROM - red alert

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/d964e66b-3d6f-5ba3-855b-dfe8377cfb3c%40nj7p.info.

forjack842

unread,
Feb 28, 2021, 4:03:21 PM2/28/21
to intel-...@googlegroups.com
I'd  use amultibuscard in a MDS with correct jumpers setup available. Original environment



Sent via the Samsung Galaxy A11, an AT&T 4G LTE smartphone


Bill Beech (NJ7P)

unread,
Feb 28, 2021, 4:15:15 PM2/28/21
to intel-...@googlegroups.com

That is the "new" current plan.  I get to test the original system.

The suspect ROM is the one out of the socket, second down in Bank B.  On the bottom, it has:

Malaysia
7825

Please note that there is NO WAY these ROMs are in the correct sockets.

So you have all the info I have!

Bill

DSCN1156[1].JPG

Bill Beech (NJ7P)

unread,
Feb 28, 2021, 4:16:23 PM2/28/21
to mark.pm.ogden via intel-devsys
That first one, Malaysia 78XX, is it.

mark.p...@btinternet.com

unread,
Feb 28, 2021, 4:17:16 PM2/28/21
to intel-...@googlegroups.com
Looking at the Memory Component Handbook from Jan83
Intel seem to split packaging i.e. Type B from the 2716 spec.
There appear to be 5 speed variants, see the attached extracted from the handbook
Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/005b01d70e14%24be0348a0%243a09d9e0%24%40btinternet.com.
2761ds.pdf

mark.p...@btinternet.com

unread,
Feb 28, 2021, 4:30:55 PM2/28/21
to intel-...@googlegroups.com
All
An older data sheet which has a paragraph about reading Taken from the 1978 data catalog
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/006201d70e17%2416732300%2443596900%24%40btinternet.com.
2716ds2.pdf

Bill Beech (NJ7P)

unread,
Feb 28, 2021, 4:53:00 PM2/28/21
to mark.pm.ogden via intel-devsys
Okay!  So the 'B' refers to the package.  Also, I suspect these are
early Intel EPROMS.

Herb Johnson

unread,
Feb 28, 2021, 6:56:50 PM2/28/21
to intel-...@googlegroups.com
On 2/28/2021 4:30 PM, mark.pm.ogden via intel-devsys wrote:
> All
> An older data sheet which has a paragraph about reading Taken from the 1978 data catalog
> Mark

an even older data sheet from Intel, shows the other speeds. - herb

Herb Johnson

unread,
Feb 28, 2021, 7:39:22 PM2/28/21
to intel-...@googlegroups.com, Bill Beech (NJ7P)
> On 2/28/2021 1:13 PM, 'forjack842' via intel-devsys wrote:
>> Like I said use a multibus card in a MDS box.

On 2/28/2021 4:13 PM, Bill Beech (NJ7P) wrote:
> That is the "new" current plan.  I get to test the original system.
>
> The suspect ROM is the one out of the socket, second down in Bank B.  On
> the bottom, it has:
>
> Malaysia
> 7825
>
> Please note that there is NO WAY these ROMs are in the correct sockets.
>
> So you have all the info I have! - Bill

Since Bill dumped all these PROMs but only one was intermittant/flaky,
it's plausible to assume the PROM is the problem. But it may be more
readable at slower speed. They are all the same designation - D2716 - so
nominal speed is 450ns.

Bill, I don't see any obvious wait-state jumper/switch on the board.
You'd have to check the board docs to see if it incorporates such a thing.

I still think it's worth checking your EPROM programmer to see how
fast/slow it reads Intel 2716's, see what your time margin is. Just
monitoring the A0 address line or a read-strobe will give you a timing
signal. That's a simple measure.

Regards, HErb

Jack Mcmullen

unread,
Feb 28, 2021, 8:50:31 PM2/28/21
to intel-...@googlegroups.com
For grins I'd check the +5 rail at an adjacent socket and maybe tweak the 5v rail into a centered operating range or tilted a tenth or two off mideange upward, like 5.1 or even 5.2


-----Original Message-----
From: Bill Beech (NJ7P) <nj...@nj7p.info>
To: intel-...@googlegroups.com

forjack842

unread,
Feb 28, 2021, 9:06:23 PM2/28/21
to intel-...@googlegroups.com
Got fingers & toes crossed for ya



Sent via the Samsung Galaxy A11, an AT&T 4G LTE smartphone


-------- Original message --------
From: "Bill Beech (NJ7P)" <nj...@nj7p.info>

Jack Mcmullen

unread,
Feb 28, 2021, 9:41:46 PM2/28/21
to intel-...@googlegroups.com
Repeated reads of the same location, say 5 consecutive, using the 5th might circumvent a slow prom, just a thought. Also there's an ACK from the board which might be able to insert a wait state or more. Whats the MDS2 (8085) typical access speed across the backplane? 
If here's a data sheet on the IO/Memory board I'm betting there's a "set' of compatible chips supported which should have parameter selection. Just thinking 


-----Original Message-----
From: Herb Johnson <hjoh...@retrotechnology.com>
To: intel-...@googlegroups.com; Bill Beech (NJ7P) <nj...@nj7p.info>
Sent: Sun, Feb 28, 2021 4:38 pm
Subject: Re: intel-devsys Monitor ROM - red alert

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/d63ec1ad-9efe-af94-04ea-0631731f1c46%40retrotechnology.com.

Herb Johnson

unread,
Mar 1, 2021, 11:15:12 AM3/1/21
to intel-...@googlegroups.com
Bill, I woke last night with a simple idea. *freeze the PROM*. Put the
chip in the freezer. Logic runs faster cold, it probably improves the
voltage-margins too. Here's some possible methods and issues, just
scattered thoughts.

0) this chip runs HOT. 100ma at 5V is half a watt! It won't stay cold
long. And you have to avoid moisture from condensation (or ice cubes).

1) Freeze spray. That might work but the thermal shock might pop the
window off PROM. Probably not but why risk it?

2) Put the chip in the freezer (in antistat bag). Probably safe. Prepare
the EPROM reader and move chip ASAP from freezer to reader. Read a few
times of course, look for consistent readings. But disassemble the first
few anyway.

3) prepare a thermal mass - a heat sink - and put that in the freezer
too. Something small to sit atop the chip in the PROM reader.

Problem is, the PROM has a quartz window on top. YOu really want to
contact the die through the package. And you don't want to use a metal
mass, might tumble and short the chip. solution - a brick, or some piece
of brick or better stone. Ideally, with a hole the size of the quartz
window, so the rest of the mass contacts the DIP package. You get the idea.

So there's the idea. Cool the chip in some fashion, keep it cold, and
read it cold. Maybe just freezing the chip and taking quick reads will
do the job. Good luck.

regards, Herb

Bill Beech (NJ7P)

unread,
Mar 1, 2021, 3:19:43 PM3/1/21
to intel-...@googlegroups.com

Yes, me too!  It is a bitch typing on the computer in this configuration!

Bill Beech (NJ7P)

unread,
Mar 1, 2021, 3:25:55 PM3/1/21
to intel-...@googlegroups.com

Good thought but not doable without tearing the programmer apart...

Bill Beech (NJ7P)

unread,
Mar 1, 2021, 3:26:31 PM3/1/21
to intel-...@googlegroups.com
Herb,

It is bagged in the freezer as we speak.

I am going to study the local jumps in the other ROMs so I can place
them where they belong on the board.

Bill

Bill Beech (NJ7P)

unread,
Mar 1, 2021, 3:26:32 PM3/1/21
to intel-...@googlegroups.com
Herb,

On 2/28/2021 5:38 PM, Herb Johnson wrote:
> > On 2/28/2021 1:13 PM, 'forjack842' via intel-devsys wrote:
> >> Like I said use a multibus card in a MDS box.
>
> On 2/28/2021 4:13 PM, Bill Beech (NJ7P) wrote:
>> That is the "new" current plan.  I get to test the original system.
>>
>> The suspect ROM is the one out of the socket, second down in Bank B. 
>> On the bottom, it has:
>>
>> Malaysia
>> 7825
>>
>> Please note that there is NO WAY these ROMs are in the correct sockets.
>>
>> So you have all the info I have! - Bill
>
> Since Bill dumped all these PROMs but only one was intermittant/flaky,
> it's plausible to assume the PROM is the problem. But it may be more
> readable at slower speed. They are all the same designation - D2716 -
> so nominal speed is 450ns.
Not sure about the ROMs holding the assembler...
They are all B2716's!!!!
> Bill, I don't see any obvious wait-state jumper/switch on the board.
> You'd have to check the board docs to see if it incorporates such a
> thing.
I have to "assume" the 11 switches are set correctly...
>
> I still think it's worth checking your EPROM programmer to see how
> fast/slow it reads Intel 2716's, see what your time margin is. Just
> monitoring the A0 address line or a read-strobe will give you a timing
> signal. That's a simple measure.
Says you!  My computer is on one side of the room and o'scope on the
other...
>
> Regards, HErb
>
>
>
>
>
> Herbert R. Johnson, New Jersey in the USA
> http://www.retrotechnology.com OR .net
> preserve, recover, restore 1970's computing
> email: hjohnson AT retrotechnology DOT com
> or try later herbjohnson AT comcast DOT net
>
Bill

Jack Mcmullen

unread,
Mar 1, 2021, 4:30:31 PM3/1/21
to intel-...@googlegroups.com
I meant on the MDS


Jack Mcmullen

unread,
Mar 1, 2021, 4:30:34 PM3/1/21
to intel-...@googlegroups.com
I meant on the MDS


Herb Johnson

unread,
Mar 1, 2021, 4:59:23 PM3/1/21
to intel-...@googlegroups.com, Bill Beech (NJ7P)
Funny - when i read your reply, I blurted out "Cool!".
Then I laughed .. ;) Good luck.

About reading the timing on your EPROM programmer. It doesn't matter I
guess, But you could take a frequency counter, carry it over to your
computer with the EPROM reader. Measure address line A0 on any 2716 as
it's being read. If the counter can hold a reading, you'll get some freq
or better a rate. LEt's say it's 1.2 microseconds. Then you know the
PROM was read at .600 microseconds, twice the address change rate. OK?

Regards Herb

On 3/1/2021 3:25 PM, Bill Beech (NJ7P) wrote:
> Herb,
>
> It is bagged in the freezer as we speak.
>
> I am going to study the local jumps in the other ROMs so I can place
> them where they belong on the board.
>
> Bill
>
> On 3/1/2021 9:14 AM, Herb Johnson wrote:
>> Bill, I woke last night with a simple idea. *freeze the PROM*. Put the
>> chip in the freezer. Logic runs faster cold, it probably improves the
>> voltage-margins too. Here's some possible methods and issues, just
>> scattered thoughts.
--

Bill Beech (NJ7P)

unread,
Mar 1, 2021, 5:44:00 PM3/1/21
to intel-...@googlegroups.com

Well, I missed that!  Working on the 3 card chassis with an ATX PS.

Bill Beech (NJ7P)

unread,
Mar 1, 2021, 5:49:05 PM3/1/21
to intel-...@googlegroups.com
Okay, guys.

I have my chip freezing.

I have my three board chassis with ATX supply located (that is tough in
this mess!).  I have the iSBC 80/30 in it with the ROM board on the
extender.  I will power off the card extender before initial processor
board tests.

I need to build an RS-232 cable for the 80/30 board.

Then smoke and fire test...

forjack842

unread,
Mar 1, 2021, 6:12:34 PM3/1/21
to intel-...@googlegroups.com
Go! Go! GO!



Sent via the Samsung Galaxy A11, an AT&T 4G LTE smartphone


-------- Original message --------
From: "Bill Beech (NJ7P)" <nj...@nj7p.info>
Date: 3/1/21 2:49 PM (GMT-08:00)
--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

Bill Beech (NJ7P)

unread,
Mar 3, 2021, 2:58:13 PM3/3/21
to intel-...@googlegroups.com
Guys,

Here are the original ROM image and 5 cold reads.  Freezing did not help
the problem.

I have not analyzed these reads.

My house ate all my IDC parts to make the serial I/O cable. Hopefully,
they will arrive today and I get the machine to operate!

Bill
104576-001.bin
104576-001-1.bin
104576-001-2.bin
104576-001-3.bin
104576-001-4.bin
104576-001-5.bin

Jack Mcmullen

unread,
Mar 3, 2021, 4:59:52 PM3/3/21
to intel-...@googlegroups.com
How did your house eat a cable??


-----Original Message-----
From: Bill Beech (NJ7P) <nj...@nj7p.info>
--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

Herb Johnson

unread,
Mar 3, 2021, 11:14:01 PM3/3/21
to intel-...@googlegroups.com
Are you kidding? My house eats all kinds of things, and hides them, and
they aren't revealed for months or years! - regards, Herb

On 3/3/2021 4:59 PM, 'Jack Mcmullen' via intel-devsys wrote:
> How did your house eat a cable??
>
>
> -----Original Message-----
> From: Bill Beech (NJ7P) <nj...@nj7p.info>
> To: intel-...@googlegroups.com
> Sent: Wed, Mar 3, 2021 11:57 am
> Subject: Re: intel-devsys Monitor ROM - code blue
>
> Guys,
>
> Here are the original ROM image and 5 cold reads.  Freezing did not help
> the problem.
>
> I have not analyzed these reads.
>
> My house ate all my IDC parts to make the serial I/O cable. Hopefully,
> they will arrive today and I get the machine to operate!
>
> Bill

forjack842

unread,
Mar 3, 2021, 11:21:57 PM3/3/21
to intel-...@googlegroups.com
Then you failed the first law of recovery. After a reasonable do diligence effort without success you must repurchase that item. Once purchased you'll find the lost item in 24hours



Sent via the Samsung Galaxy A11, an AT&T 4G LTE smartphone


-------- Original message --------
From: Herb Johnson <hjoh...@retrotechnology.com>
Date: 3/3/21 8:14 PM (GMT-08:00)
--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/ec8bc64a-cac6-cd4a-c1ce-e137fa45cdf2%40retrotechnology.com.

Bill Beech (NJ7P)

unread,
Mar 4, 2021, 12:26:33 AM3/4/21
to intel-...@googlegroups.com

Magical minions come in at night and things disappear!  (Or I put things away and can't remember where I stashed them).  It ate the parts I need to make a cable, not the cable.  Though I remember making this cable (SBC 955) several times.

Bill

To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/1391052137.327472.1614808789467%40mail.yahoo.com.

Bill Beech (NJ7P)

unread,
Mar 4, 2021, 12:27:40 AM3/4/21
to intel-...@googlegroups.com
Yea, usually right after I order replacements.  And then there is the
garage...

Bill Beech (NJ7P)

unread,
Mar 4, 2021, 12:28:16 AM3/4/21
to intel-...@googlegroups.com

Right on!  You understand completely!

Bill

Jack Mcmullen

unread,
Mar 4, 2021, 12:33:58 AM3/4/21
to intel-...@googlegroups.com
Yes! I cant count with an adding machine the number of tools and parts I now have duplicates and better!!!


-----Original Message-----
From: Bill Beech (NJ7P) <nj...@nj7p.info>
To: intel-...@googlegroups.com
Sent: Wed, Mar 3, 2021 9:26 pm
Subject: Re: intel-devsys Monitor ROM - code blue

Yea, usually right after I order replacements.  And then there is the
garage...

On 3/3/2021 9:13 PM, Herb Johnson wrote:
> Are you kidding? My house eats all kinds of things, and hides them,
> and they aren't revealed for months or years! - regards, Herb
>
> On 3/3/2021 4:59 PM, 'Jack Mcmullen' via intel-devsys wrote:
>> How did your house eat a cable??
>>
>>
>> -----Original Message-----
>> From: Bill Beech (NJ7P) <nj...@nj7p.info>
>> To: intel-...@googlegroups.com
>> Sent: Wed, Mar 3, 2021 11:57 am
>> Subject: Re: intel-devsys Monitor ROM - code blue
>>
>> Guys,
>>
>> Here are the original ROM image and 5 cold reads.  Freezing did not help
>> the problem.
>>
>> I have not analyzed these reads.
>>
>> My house ate all my IDC parts to make the serial I/O cable. Hopefully,
>> they will arrive today and I get the machine to operate!
>>
>> Bill

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys+unsub...@googlegroups.com.

Bill Beech (NJ7P)

unread,
Mar 4, 2021, 12:36:52 AM3/4/21
to intel-...@googlegroups.com

And like magic, I found the box of IDC connectors!  Cable tomorrow and then 60 Hz smoke and fire test!

Bill

On 3/3/2021 9:21 PM, 'forjack842' via intel-devsys wrote:

Jack Mcmullen

unread,
Mar 4, 2021, 12:49:40 AM3/4/21
to intel-...@googlegroups.com
Now the disclosure.....did you order replacements or do a decent 24hr do-dilegence


Bill Beech (NJ7P)

unread,
Mar 4, 2021, 1:09:26 AM3/4/21
to intel-...@googlegroups.com

Oh, I ordered replacements via Amazon Prime.  1 or 2 day delivery is ALMOST as good as a Radio Shack still in town. And then I found I ordered one type of connector from China, it will be a few weeks getting here.  I conducted the second search with more do-dilegence!

Bill

Jack Mcmullen

unread,
Mar 4, 2021, 1:19:52 AM3/4/21
to intel-...@googlegroups.com
Aint it amazing....never fails....once the lost is reordered regardless of future delivery time, the lost is found. 
Its as repeatable as rain....and it pisses me off every time!!!
Jack


Vale, Martyn

unread,
Mar 4, 2021, 4:16:16 AM3/4/21
to intel-...@googlegroups.com

We had some building work done a couple of years ago now and I had to clear one end of the garage, afterwards I found everything but an FTDI adaptor which I knew I’d used a month before storing all the stuff. Looked in every box I could find and finally gave up and ordered two new ones resigning myself to the fact I’d never see the original again and then guess what a year and a half later it turned up !

 

Martyn.

forjack842

unread,
Mar 4, 2021, 2:16:08 PM3/4/21
to intel-...@googlegroups.com
There are those items lost that break the typical 24 refind cycle. Those are the ether hinding suckers that defy being found inflicting more anguish on the searcher. Those specific found items, thought lost forever  and replaced long back deserve the death by sludge hammer!

Herb Johnson

unread,
Mar 4, 2021, 6:57:49 PM3/4/21
to intel-...@googlegroups.com
>> -----Original Message-----
>> From: Bill Beech (NJ7P) <nj...@nj7p.info>
>> Sent: Wed, Mar 3, 2021 11:57 am
>> Guys,
>>
>> Here are the original ROM image and 5 cold reads.  Freezing did not help
>> the problem.
>>
>> I have not analyzed these reads.

Well, *I* analyzed these reads. Attached is my analysis and results but
I'll bottom line it. The very first read Bill did, 104576-001.bin, has
evidence that it's the least-flawed dump of the ROM. Bill, I
disassembled it. I suggest you use that disassembly to further guide
your reconstruction of this Version 1 of this code.

Here's why.

1) There's several text strings at the end of the ROM. ASCII dump
reveals this. They are likely just residuals from assembling the ROM and
not integral to the code - but I may be mistaken. Doesn't matter.

2)Visual inspection of those strings across the ROM dumps, suggests to
me the first-dump of the ROM, *has the least damage to the text strings*
relative to the other ROM dumps. If "reading cold" mattered, it makes
sense that the first-read would be the coldest read. The 2716 runs 100ma
at 5V during read!

3) Visual binary compares among the ROM-dumps, suggests mostly
single-bit errors. I've not done statistics since I don't have a "clean"
ROM to compare to.

3) Disassembly of the first-dump binary, only produces several
non-8085-opcodes. There's aren't many such instructions.

4) Disassembly doesn't produce many out-of-hand addresses. For instance,
jumps or calls addresses inconsistent w/ the rest of the code.

5) quick inspection of the disassembled code, doesn't look awful.
There's some nonsense but that could also be cleverness.

In a copy of the disassembly, I've flagged some obvious oddballs with a
<-- string in the comments field. The disassembly - courtesy of a
version of Bill's 8085 disassembler - includes a hex/ascii dump. I've
not included the disassembler, Bill has a later version.

So - Bill has a later version in source of this code, that he shared. I
previously saw that it was relatively consistent with some earlier
disassembled version of a ROM dump of this code. I gave up when I
realized how corrupt the ROM dump was, and pushed for better dumps. I
think this is likely as good as it will get, until Bill builds a system
just to read the ROM s-l-o-w-e-r.

Regards, Herb
104576_results.zip

Bill Beech (NJ7P)

unread,
Mar 5, 2021, 12:32:54 AM3/5/21
to intel-...@googlegroups.com
Herb,

The 104576-001.bin was an early read I did last week.  It appears the
bit rot is just getting worse.  This image is what I am using in my
disassembly.  I have disassembled V1.1 and V2.0, and the compare is
close, thought there are many errors.  The difference between V1.1 and
V2.0 is V1.1 was for the MDS I and II, while V2.0 is for the iSBC
80/30.  This means some routines are different. But I will work through
it and provide assembler source for V2.0 which should operate.

I found I had no 9V batteries for my small multimeter that I use to test
the power supplies. And it appears my room has eaten the crimper for the
IDC connectors.  But I did find a number of RaspberryPI's that were lost.

This has been a fun project - as in "Da Fun" in Chinese which means "shit"!

Bill

Herb Johnson

unread,
Mar 5, 2021, 9:55:01 AM3/5/21
to intel-...@googlegroups.com, Bill Beech (NJ7P)
Well, I've not often seen "bit rot" but this may be such a case. By the
way, is the window on the EPROM completely covered? Lee Hart reminds me,
that incoming light can effect reads - all those phototransistors, right?

But "it is what it is", I see less "rot" on the text inside the early
read than in all your chilled reads. And my own comparisons with your
V1.1 previous and the V2.0 source, confirms they are close.

So Bill, proceed as you advise and test the disassembled binary as best
you can. Don't get over committed to the result until others work the
code as well. Someday someone will find another EPROM and provide better
validation.

Regards, Herb

Bill Beech (NJ7P)

unread,
Mar 5, 2021, 2:43:40 PM3/5/21
to intel-...@googlegroups.com
Herb,

On 3/5/2021 7:54 AM, Herb Johnson wrote:
> Well, I've not often seen "bit rot" but this may be such a case. By
> the way, is the window on the EPROM completely covered? Lee Hart
> reminds me, that incoming light can effect reads - all those
> phototransistors, right?
Not sure.  I suspect it is just loosing programming one bit at a time. 
The fixes seem to all require turning on missing bits.
>
> But "it is what it is", I see less "rot" on the text inside the early
> read than in all your chilled reads. And my own comparisons with your
> V1.1 previous and the V2.0 source, confirms they are close.
Yes, good thing!  There are differences, mainly because of the V2.0
being ported to the iSBC 80/30.
>
> So Bill, proceed as you advise and test the disassembled binary as
> best you can. Don't get over committed to the result until others work
> the code as well. Someday someone will find another EPROM and provide
> better validation.
Well, this was a find what, 15 years after we started this adventure?
>
>
> Regards, Herb
Bill
Reply all
Reply to author
Forward
0 new messages