Intel ICE Documentation

[Jon Hales]

All

I have uploaded the (additional) material I have to Google Drive. The link to access the directory is:

https://drive.google.com/drive/folders/16Mh5yoxsDJWrTNzrRoFfmfeQLyBtQB3k?usp=share_link

At the top level there is a jpg image showing the directories and the volume of data. There is also a spreadsheet with a partial list of photos.

Some notes:

I have assumed that anyone wishing to add items from this collection to a repository will re-package the material according to their conventions. I have tried to avoid uploading items already available - with Mark Ogden's collection as my point of reference.

The material consists of:

- scanned schematic drawings

- scanned documentation

- firmware (notes below)

- photos of boards and other components

Firmware. Most of the EPROMs are 2716s. I read them using the Martin Eberhard ME2700 programmer. Dumps of data are exported over a serial link. I captured the listings as log-files in TeraTerm. In some cases, I also converted the data to HEX files.

Documents. I included some manuals relating to Intel's I2ICE system and some UPI-41A items.

Photos. Most were obtained for logging of items with a record of which system had contained the boards. Where available, I have shown multiple boards of the same type. In a couple of cases, I have included photos obtained from web sources. Additional photos could be provided if required.

It would be relatively straightforward to expand the information to list 'known-knowns' about the ICE systems.

Regards

Jon

[Bill Beech (NJ7P)]

Jon,

Thanks!  I have sent you a request for access from my gmail account.

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CANPXPJ%3DxnBsVRp0%3Dw4TmpKPRufm8YcX30idydrQ_gLS%2BHEKEww%40mail.gmail.com.

[Vale, Martyn]

 

Hi Jon,

 

A great collection of ICE stuff Jon thanks.

 

I’ve added the MCS-48 ICE Reference card you scanned for me a while back to the ICE-49 directory as I couldn’t see it in Mark’s repository and it’s quite useful as there’s currently no full manual for the ICE-49.

 

I’m currently working on a couple of ICE-49’s and one is almost fully working now bar an issue with Breakpoints which only work on page boundaries. I’ve been making notes as I go on how to use the Emulator Instruction Set and I’ve uploaded the current version as Usage Notes.txt.

 

The original ICE-49 Control Board has only three eproms and the third socket is empty in both the boards I have. I think the fourth socket is only occupied in the upgraded ICE-49A.

 

The diagnostics for the ICE-49A only partially work on the ICE-49, so these aren’t really much use when testing.

 

Bye

Martyn.

 

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Jon Hales
Sent: 10 March 2023 12:20
To: intel-...@googlegroups.com
Subject: {SPAM?} intel-devsys Intel ICE Documentation

 

⚠ Caution: External sender

[Royce Taft]

Where did all the ICE-49 information end up? I found the schematic on Mark Ogden’s site, but I haven’t found where the EPROM dumps landed. I’m not finding them on Bill’s Google Drive. 

I picked up an ICE-49, and the pod has a sticker stating it was tested as an ICE-49A. Of the two boards in the set, one has four EPROMs, and the other board has an 8749 (UV erasable variant of the 8049). I would like to dump its contents if there isn’t a backup already available. If there is a backup, I’d like to dump mine to compare its contents. Same with the ROMs. 

I’m surprised the Xgecu T48 programmer (a successor of the TL866) isn’t compatible with MCS48 ICs. I’m not sure exactly how I’ll dump the 8749, but I haven’t put much thought into it yet. 

Royce

[Royce Taft]

Also, are there dumps for the 4-bit PROMs at location A28 (missing label on mine) on the emulator board (PWA 1002464) and locations A48 (labeled 101510-001 on mine) and A68 (labeled 10509-001 on mine) on the control processer board (PWA 1002433)?

For those interested, the 8749 at A61 on my emulator board is labeled 163699-001 over the UV window.

Royce

[Royce Taft]

Unfortunately, all four of the EPROMs on my control processor board are bad (A3-A6) as most have large portions reading 0x00 or 0x80, and none of them provide repeatable results on successive reads.  That's surprising since they all have stickers shielding their UV windows.  I hope they didn't fail due to static discharge during shipping, because I'm certain other ICs would follow suit...

[Herbert Johnson]

Here's some moral support, this is unfamilar intel tech to me.

Are you sure your PROM reader is reading 2716's correctly? Do you have
other 2716's around to read off to verify your setup?

Sounds like disabled PROMs. If they failed, likely the boards have
problems. Unlikely it's "static discharge". There's other less likely
scenarios.

You might put a 'scope on the 2716 pins and watch as your PROM reader
read them off: see if you get funny logic-levels that suggest some kind
of electrical damage per pin. And to verify the PROMs are enabled and
getting good addresses.

At worst, you could breadboard them and put logic signals on them, look
for logic responses with simple driven LED's. Kind of a desperate act....

What you call "4 bit proms" A28 A48 A68? Seem to me to me fused 8 X 256
ROMs, if I read the schematics correctly. Those are not likely to fail.
YOu could do worse than run them on a 8-bit counter and capture the
outputs. In the short term, worry about the 2716's first.

Mark has the ICE-49 schematics under "docs" on his site., from which I
tried to identify your chips.

Regards Herb Johnson

--
Herb Johnson, New Jersey USA
http://www.retrotechnology.com or .net
preserve and restore 1970's personal computing
email: hjohnson @ retrotechnology dot com
or try later at herbjohnson @ comcast dot net

[William Beech]

Royce,

What you talk about on the EPROMs we call "bit rot"  I have been battling with it as have others on this group.  EPROMs are not permanent storage.

We have very little documentation on the 8048/49 and 8041/42 hardware or software.  We have the original data sheets, but little more. 

Most of the programmers never handled the Intel chips like those mentioned above along with the 8755 and others of that time.  Nor the ROMs used in the early Intel hardware.

I have the software to add devices to the old SuperPro/Z programmer.  I have several of them that all have problems.  I am in the process of reverse engineering the hardware and software to see if I can read and/or program the old Intel devices.  Others on this group may have the ability to read these devices and offer their services.  We need to grab this code while we can.

Bill

On 2/10/2025 8:59 PM, Royce Taft wrote:

Unfortunately, all four of the EPROMs on my control processor board are bad (A3-A6) as most have large portions reading 0x00 or 0x80, and none of them provide repeatable results on successive reads.  That's surprising since they all have stickers shielding their UV windows.  I hope they didn't fail due to static discharge during shipping, because I'm certain other ICs would follow suit... --

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 visit https://groups.google.com/d/msgid/intel-devsys/fd22a70f-99ae-4e23-ba55-c4b7f3d9d127n%40googlegroups.com.

[Herbert Johnson]

On 2/10/2025 11:59 PM, William Beech wrote:
> Royce,

>
> Most of the programmers never handled the Intel chips like those
> mentioned above along with the 8755 and others of that time.  Nor the
> ROMs used in the early Intel hardware.
>

The intel UPP handled some of these, but it's unwieldy to use a UPP today.

https://www.retrotechnology.com/restore/int_upp.html

https://www.retrotechnology.com/restore/upp1_2716_1.jpg
https://www.retrotechnology.com/restore/upp_promb_8748.jpg
https://www.retrotechnology.com/restore/upp1_3604_1.jpg

The 2716's are running 8080 code, that's the processor on that board.
The 8748 is the UV version of the 8048. I don't recall how the 8X49 is
different. The 3604 is 512 X 8 but also fused.

also, a correction to my previous post. The 3601's are 4-bits out, 8
address bits in, two active low chip-selects. A28 on the emulator bd,
A48 A68 on the control processor board. These board are busy! there's a
pair of 74181's doing business on one board.


A found Intel data sheet includes a 3601 manual programmer schematic.

https://archive.org/details/intel3601programmablereadonlymemory/mode/2up

- Herb

[craig andrews]

The needham emp-20 is always my programmer of choice for these sorts of things. 

On Feb 10, 2025, at 9:01 PM, William Beech <nj...@nj7p.info> wrote:

 Royce,

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/09f457e7-8bc4-47ae-b114-19a23a34d93d%40nj7p.info.

[Jon Hales]

Hi Royce

I have located a backup of some limited ICE-49 information including a directory in which there are dumps of three 2716s. These are saved as '.log' (txt) and as 'hex' - derived from the ME2700 reader and captured over a serial link. I can't explain the 2015 date of these files - it may have been the date on the old Thinkpad I used to communicate with the ME2700.

I have added photos (dated 2021) of the two ICE-49 boards that I had some time ago. The EPROMs are numbered 9100285, 9100286 and 9100287 - which suggests the board was an early version. These are in a sub-directory 'JH_Photo_ICE49'.

Another photo I copied from a search shows a board on a pink plastic bag with three EPROMs labelled 163702-001, 163702-002 and 163702-003. That board had a fourth EPROM numbered 163249-001. I'm fairly sure these are NOT the EPROMs I dumped.

These are now on my Google Drive with the link:

https://drive.google.com/drive/folders/1n1WpX6K6USzINQhnXPPivaN4eduIDO-N?usp=drive_link

To be clear, my Google Drive usually isn't intended a repository - it's a place for me to post material temporarily. If others want a copy, they need to be quick.

I recommend the Matt Millman 'MCS-48' programmer / Reader - which can deal with 8749s and can read 8049s. I've placed in the ICE-49 directory a PDF (June 2023) of the web pages where his project is documented. This board is used on an Arduino Mega. The design files are available. I may have a couple of spare boards - available for cost of postage - ask if interested. I didn't have the MCS-48 reader at the time I read the EPROMs.

Regards

Jon

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/2acaa81c-5759-4143-851e-44049f192efdn%40googlegroups.com.

[William Beech]

Craig,

I just bought one.  And I found a project to create the family module boards for most of them at: https://github.com/schlae/EMP-20Module?tab=readme-ov-file.  This handles all the microprocessors, but not the 8755 or the 36XX ROMs.  But may be able to create a family module for those things!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/93F2C2F0-662D-4499-B296-6A1CA6022C12%40gmail.com.

[craig andrews]

Hi Bill,

The 8755 uses module 02A, the same as the 874x and 875x families

I don’t dabble in 36xx ROMs, so I’m no help in that regard.

Jon mentioned the Matt Millman 8755 programmer, I usually have some bare boards if anyone in the states needs a set.

Regards

Craig

On Feb 11, 2025, at 2:52 PM, William Beech <nj...@nj7p.info> wrote:

 Craig,

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/6f5bf2c7-f8ee-4a51-8249-e2d5d18a0f8d%40nj7p.info.

[Vale, Martyn]

Hi Royce,

 

I’ve done a fair bit of work on a couple of ICE-49 systems and unfortunately the only documentation is the schematic and a quick reference card, both located by Jon a few years ago.

 

The original ICE-49 has three ROMs on the Control Board whereas the ICE-49A has four ROMs on the control board, so I’m guessing your control board may have been field upgraded to an ICE-49A. I’d be interested in some high res pictures of your boards to see if it’s possible to identify the changes from ICE-49 to ICE-49A, obviously the contents of the ROMS would be very useful as well if you ever manage to read them successfully.

 

As I understand it when the ICE-49 was supplied from Intel it came with two processors for the Emulator Board an 8049 and an 8048 each contained what Intel referred to as a “Monitor” program which presumably interacts with the hardware on the Emulator Board. I have a couple of the 8049’s but have yet to come across the 8048.

 

Between the short form documentation and the quick reference card you can work out most of the commands and I do have some notes attached if you get yours going if it might be any help.

 

Diagnostic wise you should note the ICE-49A diagnostics do not work fully with the ICE-49, I can’t remember off had which tests fail on the 49 but quite a few of them do.

 

Thanks

Martyn.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/48ec640a-1bbc-4b3b-bf35-15c83fe17050n%40googlegroups.com.

[Royce Taft]

Thank you all for chiming in!

I agree with Martyn's assessment that this kit must have been field upgraded to an ICE-49A.

The EPROM labels on my board match those in the photo of the board on the pink plastic bag Jon provided in his Google Drive.  That board must also be for the 49A.

It seems like the T48 programmer must not be fully compatible with the Intel D2716.  As an alternative, I tried a nice and slow homebrew EPROM reader I put together years ago which gives the EPROMs 1000 ns for their data outputs to stabilize, and it did much better.

Unfortunately, we're still contending with bit rot.  For three of the EPROMs, there are a number of bytes which vary by a bit or so over each successive read.  I provided 10 successive dumps for these EPROMs in Bill's Google Drive.  I don't suppose it would be a trivial task to attempt to run this ROM through a disassembler such as Ghidra and, while keeping track of the locations with dubious bits, try to deduce what the values must be for the code flow to make sense.

The good news is that one EPROM spits out the exact same data each time I read it, so I assume I have a good dump for this one.  This is the EPROM in location A4 labeled "163702-002".

As for dumping the firmware in the 8749, I'm interested in a spare board for the Matt Millman programmer / reader, and I would be happy to reimburse for packaging, shipping, and time.  I'm located in the U.S. in Northern California.

Martyn, if you have the ability, it would be very helpful if you can dump the firmware in the 8049 on your emulator board.  I suspect the 8749 on my board could have the same or similar firmware, but I would like to confirm this.  Thank you for the notes and reference card scan.  Once I get my MDS system up (still working my way to get to that project), I'll put all of this to work.

For those 4-bit PROMs, I'm going to breadboard them up one at a time to my homebrew EPROM dumper.  They have open collector outputs, so I'll be sure to use pull up resistors on the data lines.

I uploaded high resolution photos of both sides of the pair of boards to Bill's Google Drive.  I didn't take any pictures of the pod / buffer board, but it doesn't look like it could vary much.  It's the typical blue box labeled "ICE-49".  The only thing of note is a pink sticker stuck to the bottom of the outside of the enclosure with "TESTED AS 49A 8/10/83" written in pen.

While I had my wife's camera set up, I took some photos of both sides of an iSBC-040EX I picked up last year as well. 

For convenience, here's a link to my subfolder in Bill's Google Drive: https://drive.google.com/drive/folders/1QfFTaCK2yXnCkYhN740UtpYuzrbYIV_-

Regards,

Royce

[Royce Taft]

I think I have the 1024-bit (256 x 4-bit) PROMs dumped.  At least they all provide consistent data at each successive dump.  I uploaded those to the Google Drive folder as well.  The PROM data exists in the lower nybble of each byte in the binary files.  I wired the upper nybble of the data pins on my EPROM dumper to ground, so those are all zeros.  I used 1K pull up resistors on the four data pins connected to the PROMs.

Royce

[Herbert Johnson]

Kinda late for me so I'm just throwing error codes here....

On 2/16/2025 11:45 PM, Royce Taft wrote:>
> It seems like the T48 programmer must not be fully compatible with the
> Intel D2716.  As an alternative, I tried a nice and slow homebrew EPROM
> reader I put together years ago which gives the EPROMs 1000 ns for their

> data outputs to stabilize, and it did much better.\

It may be 1) read time and 2) programming time. The oldest 2716's were
slower than the more recent ones, as a rule. Look closely for
brand/model of 2716s and confirm you are reading or programming them at
the right speed (if you can find specs). Also: 3) programming pulse
voltage. Many cheap programmers don't produce or sustain the
specification-proper voltage for the (write) programming pulse. Doesn't
matter for read.

It's possible that ROMs read slower with severe age, but I am not sure
of this.

> Unfortunately, we're still contending with bit rot.  For three of the
> EPROMs, there are a number of bytes which vary by a bit or so over each
> successive read.  I provided 10 successive dumps for these EPROMs in
> Bill's Google Drive.  I don't suppose it would be a trivial task to
> attempt to run this ROM through a disassembler such as Ghidra and, while
> keeping track of the locations with dubious bits, try to deduce what the
> values must be for the code flow to make sense.

I and others (not in this group) have second-guessed lost bits. If it's
a single bit error, disassembly and eyeball of results can guess most of
the lost bits. Easier if the bit is in the same byte-bit-position (a
stuck data line). But this is painful.

Try reading the 2716 with whatever programmer setting (2716 brand/model)
gives you the *longest read time*. But make sure all the pin-voltages
and signals are correct. In that Stone Age of ROMs, there were a lot of
variations among brands and production runs.

Extra credit: if you have schematics, guess the read cycle time for the
ROMS in use in the ICE-49. see how slow they were *really* read.

> The good news is that one EPROM spits out the exact same data each time
> I read it, so I assume I have a good dump for this one.  This is the
> EPROM in location A4 labeled "163702-002".

How is that EPROM different from the others? pardon me for not fishing
up the photos of the boards for the ROMs. Also the details may be under
any labels.

Regards Herb (yawn)

[Herbert Johnson]

Pardon me for what appears to be quick assessments, followed by tedious
descriptions and blunt strategies. But I suggest what I see based on my
experiences and information given. The ROM compares I did, took some
tedious eyeball time, they were not quick; reports produced took even
longer, as did writing this email.

These are all real-time results and so I'm showing my work (and my
errors) as I go. The point is to find where the trouble is, to find
strategies to work around it; and to explain my work to inform others
for their analysis. - Herb

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

Speed: The 8080 board is running from an 18MHz crystal on an 8224
oscillator/divider so the 8080 clock is 2MHz. That's an instruction
4-clock cycle time of about 500KHz - plenty of time to read PROM bytes,
2ms roughly.

Date: The PROMs are marked Intel D2716 with only a copyright date which
is not a production date. (There may be a production date on the bottom
of the PROMs). Older production usually equals slower read speed. The
board itself has chips from 1978 1979 but also some from 1983. It's
possible the board was produced in 1979 and rebuilt in 1983, or produced
in 1983 with lots of old-stock TTL chips.

Intel data sheets for D2716 no markings like -2 -1 etc, give a read
cycle time of 450ns. But it's possible Intel used too-slow ROMs for
their own products. Not the first time a factory used chips they didn't
sell to the customers.

The A6 PROM dumps consistently show zeros in the lower nybble, and not
much variability in the upper nybble. So it's easy to say "bit rot" and
give up. But I suggest running that ROM read *even slower* than 1ms and
looking at the outputs. Evidence of slow ROMs, is in finding single-bit
errors in the A3 EPROM (explained shortly).

(action item 0) Pure static testing of A6 would be the final test, like
this. Put the ROM on a breadboard, jumper addresses in, put
7404-buffered LEDs on the data line. Look for data out. Use toggles on
the addresses to change them faster. This may seem futile but frankly
the A6 ROM is a loss anyway, pardon me, so seeing if *any* data can be
extracted is a benefit. I'll return to A6 after reviewing A3 as below.

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

I did not examine the A5 PROM dumps.

The A3 PROM dumps as given are ten trials of binary results, apparently
from a 1000 us read-cycle reader. A hex file tool I have permits
two-file comparison reports of differences. I saw some consistent
results and no more than 20 differences per file-pair. I've produced
pairs of reports (trial 1 vs 2, 2 vs 3, .... 9 vs 10). Then I combined
the reports into one.

The final report is a table of *all* addresses which showed *any*
differences between pairs of files. Do *not* read the table literally,
because I made a tactical error initially. (This may be confusing, if so
skip to "bottom line".) I backfilled earlier results when later results
showed a difference. I then realized leaving the test empty was more
informative and not-disputable.

The bottom line, is that the final report is a set of suspicious
addresses, where (by visual inspection) there's *consistent* single-bit
errors in the ten-read data. Many of the errors are in bit 1 (from bits
0 to 7) but many are in bit 0. "many" is by visual inspection.

Three action items emerge from these findings.

1) use of the "final report" would be in disassembly. The addresses
listed, contain data which at one time produced an identified single-bit
error. In disassembly you can make informed decisions about the correct
8080 instruction or the correct data.

I and others performed this very analysis in disassembly of
single-bit-error 1802 ROMs: the disassembly *very very closely matched*
a later read of another ROM from another 1802 computer of the same kind.

2) the discovered fact of intermittent single-bit errors, distributed on
intermittent addresses, suggests that the ROM was read "too fast".
Consistent evidence for this, is that one of the other ROMS read
consistently on the same reader: so the reader was "slow enough" for
that ROM. More evidence, is that the 8080 is running 2MHz and so reading
ROMs much slower than 1000 usec on the reader.

Therefore, an even slower reader *might* resolve a consistent read of
ROM3A.

3) Alternative conjecture: ROMs read faster when cold. I recommend
*chilling the A3 ROM* before repeated read. Simply put it on ice, in the
freezer if not in the refrigerator. The proof will be in consistent
results or fewer bit errors.

If the data is still "there", a better extraction would save a lot of
disassembly head-scratching.

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

That's a lot of text. "If I had more time, I'd have written a shorter
letter." But the bottom lines again are, try more ways to read the ROMs.
Easiest action item 3) is to chill ROM A3 and try another run of reads.
harder is item 2) to find a slower reader for ROM A3. Item 1) is a lot
of disassembly work.

If ROM A3 can be consistently recovered, try these strategies for ROM A6
which shows almost no data. If items 1 2 3 above fail, last strategy
(action item 0) is to create manual breadboard testing of ROM A6 to see
if there's *any possible data* in the ROM. Again: if it's already dead,
no harm in trying.

Regards Herb Johnson

> https://drive.google.com/drive/folders/1QfFTaCK2yXnCkYhN740UtpYuzrbYIV_- <https://drive.google.com/drive/folders/1QfFTaCK2yXnCkYhN740UtpYuzrbYIV_->
>
> Regards,
>
> Royce

>
> --
> 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 visit

> https://groups.google.com/d/msgid/intel-devsys/CAEO2EXxb6PjWJ4FBXiQUM_PPzGvkog8UNWFHk0OJhwvVJ%2BMETg%40mail.gmail.com <https://groups.google.com/d/msgid/intel-devsys/CAEO2EXxb6PjWJ4FBXiQUM_PPzGvkog8UNWFHk0OJhwvVJ%2BMETg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Royce Taft]

Herb,

Thank you for looking into this.  I really appreciate your time.

The date code beneath all four of the EPROMs are the same:  33rd week of 1983.

One correction regarding the homebrew tool I used to read the EPROMs: It was only waiting 1000 nanoseconds, not 1000 microseconds, for the EPROM to provide its data.  I thought this would be enough time as I believed the ICs to be somewhere between 450-650 ns access time.  Good call that they are read much slower in the system, so I should be reading them at least as slowly.

I made some programming changes on my EPROM reader, adding a slow-read mode to really stretch things out, and it works as follows: the desired address is provided to the PROM, just over 1000 microseconds (1ms) delay, chip enable is brought low, just over 1000 microseconds (~1ms) delay, output enable is brought low, just over 2000 microseconds (~2ms) delay, the data is read, brief ~500 nanosecond delay, CE and OE are brought high, next address... 

This change appeared to make no difference for A3.

Next, I popped A3 into the freezer for not more than 5 minutes.  After reading the chilled A3 a couple of times and comparing the dumps, there were 319 differences.  After coming back up to room temperature and reading a couple more times, A3 is back to only ~20 differences.

I think I'll try warming A3 up a little (120 degrees F or so?) to find out if that helps or hinders us.  I can also throw in a longer delay before asserting OE.

Similar to your recommendation for breadboarding and manually providing addresses to A6, I think I'll add a mode to my EPROM dumper where I can enter a single address for it to present to the EPROM, assert CE and OE, then pause.  I'll probe suspected data bits at suspected addresses for A3 from your notes to see how the data pins look.  The same can then be done for A6 to see if it's totally dead.

Speaking of A6, I tried reading it again but slowly, and the results are similar (0s in the lower nybble and inconsistencies in the upper nybble between reads), but in the sea of zeros in the lower nybble I noticed a 1 or 2 here and there.  I'm not sure I would call that a great improvement, but I thought it was worth noting.

Regards,

Royce

[William Beech]

Herb and Royce,

This is a very good point about the read speed.  I will try and add it into whichever old EPROM reader I settle on using. 

We need to find and recover as much old code as we can before it all dissolves into the ether.  I am willing to host whatever code you can find and place into binary files.

Thanks!

Bill

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

[Royce Taft]

I think I had some success this week.

I warmed up A3 in a 140F oven for 10-15 minutes, and this resulted in two successive reads which matched exactly.  As the EPROM continued to cool back to ambient temperature, more and more inconsistencies became present between reads.  The binary dumps are found here: https://drive.google.com/drive/folders/13PiRkQkF4zDY10124rC46BrrWzFyZvG9?usp=drive_link 

I assume that "A3 WARM 1.bin" is a valid dump of the data, but I have no means to prove that beyond comparing against a known good dump which we don't have at the moment.

I tried the same approach for A5, but the increased temperature seemed to have an adverse effect on the consistency of the read data.  Cooling A5 in a freezer had a similar negative effect.  Next I tried increasing the applied voltage using a benchtop power supply.  Fortunately, when I built this little ROM dumper, I included a jumper for selecting VCC between a USB UART adapter and an ISP header.  Removing the jumper allowed me to apply an off-board adjustable power source.  Increasing the supply voltage from 5.0V in increments of 0.1V led to incremental improvements in read data consistency.  I included the results for 5.5V and 5.6V here: https://drive.google.com/drive/folders/1IOkwvr5YDt-q9mDzg4xuikm4bHJZDumi?usp=drive_link.  I assume that "A5 5.6V 1.bin" is a valid dump as it is identical to successive reads.

That still leaves A6.  I attempted higher and lower supply voltages on this EPROM to no avail.  I have yet to try heating or cooling it, but my hopes aren't high.  Next will be manually specifying addresses and observing the data pins on my oscilloscope.

I put A3-A5 through the Ghidra Disassembler which seems to have disassembled completely.  I haven't done much analysis on the disassemble code, but the fact that Ghidra didn't run into blocks of machine code which it couldn't logically disassemble is a very good sign.  Interestingly, there doesn't seem to be a jump nor a read to anywhere in the address range for A6, so I'm not sure how this EPROM is used.  That may indicate that the disassembly is no good, which would be due to bad EPROM data.  A text file containing Ghidra's disassembly is in my folder here: https://drive.google.com/drive/folders/1Jk6OQaLon4BfEIRyB12JmgFxFq_dPzb6?usp=drive_link

I did a little reading, and apparently the cheap T48 programmer I had originally tried to use to read these EPROMs is not capable of reading them with the Intel "M2716" profile selected.  Others have had success with the T48 for these EPROMs only with the Atmel AT28C16 profile.  More about it here: https://forum.vcfed.org/index.php?threads/read-2716-uv-eprom.1241971/post-1301877

While composing this message, I just now attempted to read all four EPROMs using the T48 with the AT28C16 profile, and I'm surprised to find that multiple reads are all identical.  I'm even more surprised that the A3, A4, & A5 binary dumps from the T48 programmer (which were done at room temperature (70F) with whatever the supply voltage is on the T48) match the dumps I produced using my homebrew EPROM reader exactly!  I don't understand why I had to go to such extremes (temperature/voltage) to get a proper read with my homebrew reader at quite a slow speed, while this cheap Chinese product worked, albeit with a workaround.  I'm at a loss for what the difference might be.  Maybe logic level tolerance differences between what's going on in the T48 versus the AVR microcontroller I'm using in my ROM dumper?  The T48 dumps are here: https://drive.google.com/drive/folders/103QigtG7E8GC8U-G2T1uzT_wi7A9DqEr?usp=drive_link

The T48's dump for A6 seems to have good data for the first 0x00CB addresses.  Beyond that, the rest of the file is 0xFFs.  I'm unsure if this is how Intel programmed it or if this EPROM has a bad case of bit rot.

For now, everything is in my folder within Bill's Google Drive.  We'll have to wait for another board with these particular EPROMs to surface, so another dump can be compared against.

Royce

[Herbert Johnson]

A point of caution about accessing the Google Drive. While I was reading
a text document (readme) in Royce's subdirectory, I didn't realize that
Google Drive gave me write access! I briefly deleted its content when I
copied it (probably a "cut" command not a "copy" command). Use caution
when working within the Google Drive over the Web/browser interface.

Royce has made great progress on extracting the ROM content as the ROMs
seemed to have limitations due to timing, heat, and voltage. His reports
on methods to work around these limits were both informative and
productive. A3 ROM was resolved with consistent results. HOwever one ROM
A6 was not recoverable.

His readme covers all the contingencies discussed by he and I and
others. These will be useful techniques going forward, if people have
equipment and means to control these variables through constructed
readers for these now-ancient parts.

as time permits I'll look at the 8080 disassembly and see what I can
contribute. He resolved A3 by varying temperature and timing, to
produce several consistent reads.

Offline, I provided Royce with a list of ROM content variances from one
of his earlier reads of the A3 ROM. I'll look for those variances in the
disassembly. For you home-gamers, attached is a report I made. It's
informative to see they are single-bit errors. I did not examine ROM A5
reads, but again Royce obtained consistent results.

regards Herb

On 2/16/2025 11:45 PM, Royce Taft wrote:

> Thank you all for chiming in!

> For convenience, here's a link to my subfolder in Bill's Google Drive: [link]

[Vale, Martyn]

 

Hi Royce,

 

Good to hear you are making progress on the ROMS. From what I can remember the Diagnostic Software for the ICE-49A has a check for on board ROM CRC, so if you can get it running this would confirm to an extent that the reads are good. If you manage to get all four ROMS read then I can try it in one of mine as well.

 

Thanks for the High Res Pic’s very useful. Although I note your Emulator Board has many more ECO’s (bodge wires) than Jon’s picture. From your image it looks like your board is revision 0 ? I can’t tell what Jon’s is.

 

I may be able to read the 8049 on one of my boards I think I can read an 8749, so should be possible.

 

It might be worth noting that both my control boards had faulty scratch pad ram A18/19 Intel 2111A’s. One also had faulty 2114’s as well, but to be fair that one is not in good shape chip wise.

 

I guess also if you don’t succeed in getting the ICE 49A ROMs working then you could substitute the ICE 49 ones, not sure if any of the decoders would need changing as well though.

 

Bye

Martyn.

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Royce Taft
Sent: 21 February 2025 20:17
To: intel-...@googlegroups.com
Subject: Re: intel-devsys Intel ICE Documentation

 

 

I think I had some success this week.

--

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 visit https://groups.google.com/d/msgid/intel-devsys/CAEO2EXyiSiE1g_s1Eu039HKvTs6_aerZvpuCiTBZRN3F4L%3DMwA%40mail.gmail.com.

[Herbert Johnson]

Key question you ask: why did the T48 succeed with ROMS at room temp and
[whatever level of] 5 volts Vcc? While your homebrew ERPOM reader, took
combinations of voltages and EPROM temperatures and speed to get
consistent results that matched? You make good guesses.

I suggest you look at both units at work, with an oscilloscope, at the
voltage levels, rise fall times, and other timing of address and data
and chip enables. If the 'scope scans at the read cycle rate, you will
have seconds to observe. Or you'll freeze sample scans on a storage 'scope.

May as well, you've looked at everything else. ;)

My ancient BP Microsystems EP-1140, verified EPROMs by reading at 5.0V
Vcc, then at 4.5V, then at 5.5V (some levels like that). PROMs are
timing-limited like any digital device. So there's nothing new about
considering variations of conditions. Beyond the TTL logic in the
EPROMs, there's the analog logic of reading silicon cells containing
trapped charges.

- regards Herb

On 2/21/2025 3:16 PM, Royce Taft wrote:
> I think I had some success this week.

[snip]

>
> While composing this message, I just now attempted to read all four
> EPROMs using the T48 with the AT28C16 profile, and I'm surprised to find
> that multiple reads are all identical.  I'm even more surprised that the
> A3, A4, & A5 binary dumps from the T48 programmer (which were done at
> room temperature (70F) with whatever the supply voltage is on the T48)
> match the dumps I produced using my homebrew EPROM reader exactly!  I
> don't understand why I had to go to such extremes (temperature/voltage)
> to get a proper read with my homebrew reader at quite a slow speed,
> while this cheap Chinese product worked, albeit with a workaround.  I'm
> at a loss for what the difference might be.  Maybe logic level tolerance
> differences between what's going on in the T48 versus the AVR
> microcontroller I'm using in my ROM dumper?
>

> The T48's dump for A6 seems to have good data for the first 0x00CB
> addresses.  Beyond that, the rest of the file is 0xFFs.  I'm unsure if
> this is how Intel programmed it or if this EPROM has a bad case of bit rot.
>
> For now, everything is in my folder within Bill's Google Drive.  We'll
> have to wait for another board with these particular EPROMs to surface,
> so another dump can be compared against.
>
> Royce

[William Beech]

All,

I have disassembled each of the 4 ROMs read on the T48 and they all
contain proper ASCII text and code which "appears" correct.  These ROMs
came from an ICE-49A with an Intel 8-bit processor?  8080 or 8085?

Thanks!

Bill

[roger arrick]

An idea:

I used one of the modern USB EPROM programmers last year and had difficulty reading some old 450ns EPROMS.  I never proved it but I suspect the software is reading too fast for the access time. 

This software was likely written by programmers who weren't even born when 450ns was the norm.  And they probably didn't do a lot of testing on 45 year old devices.

Just a thought.

--  Roger Arrick -- Tyler, Texas, USA -- Ro...@Arrick.com --

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.info>
Sent: Saturday, February 22, 2025 1:05 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>

Subject: Re: intel-devsys Intel ICE Documentation

--
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 visit https://groups.google.com/d/msgid/intel-devsys/000a47de-6b99-4753-bf90-372b36e6b5eb%40nj7p.info.

[William Beech]

All,

For your edification.

Bill

[Herbert Johnson]

Good work by Bill. I use a version of his disassembler so it's familiar
to me. After running his source through my "edifier" ;) , I just sent
him a few tweaks of his disassembly that should realign that address
table he obtained and resolve some loose ends.

The following is mostly for Bill but other disassemblers may have this
issue.

An artifact of Bill's disassembler, is that it doesn't resolve
symbol/address references "inside" disassembled code. So if an symbol
addresses into the middle of a 2-byte or 3-byte instruction or 2-byte
table, it doesn't label the disassembled location. Rough example:

lxi H, A1234
....
1233: dw 4567H ;doesn't create a A1234 label here.
1235: dw 7654H
....

So when the disassembled table is misaligned, you lose the symbol
reference. I support his disassembler code too, so I know what this is
about.

I could think about the disassem catching this error and inserting some
warning into the disassembly, like "address [symbol] inside code/table"
or some such. Just enough to tell the reader, to look at the accessing
code and see if the disassem instructions at the destination need to be
realigned. That's what occurred in this disassembly.

But the consequence of this table misalignment, is oddball addresses to
nowhere: easy? to spot as in this case. It's harder to spot when the
symbol-address is inside code, you have to see the code is "broken",
doesn't make sense.

So the disassem issuing a warning would spot these instances, as long as
there aren't so many that it's a nuisance. There's always tradeoffs.

Regards Herb

On 2/22/2025 2:58 PM, William Beech wrote:
> All,
>
> For your edification.
>
> Bill
>
>
> On 2/22/2025 12:05 PM, William Beech wrote:
>> All,
>>
>> I have disassembled each of the 4 ROMs read on the T48 and they all
>> contain proper ASCII text and code which "appears" correct. These ROMs
>> came from an ICE-49A with an Intel 8-bit processor? 8080 or 8085?
>>
>> Thanks!
>>
>> Bill

[Vale, Martyn]

Hi Bill,

It's a 8080 on the Control Board as are all of the Multibus ICE Control Processors I've come across so far.

Martyn.

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of William Beech
Sent: 22 February 2025 19:06
To: intel-...@googlegroups.com
Subject: Re: intel-devsys Intel ICE Documentation

⚠ Caution: External sender

--
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 visit https://groups.google.com/d/msgid/intel-devsys/000a47de-6b99-4753-bf90-372b36e6b5eb%40nj7p.info.

[William Beech]

Martyn,

Thanks!  I figured that out.  Do we have the ISIS-II disks for the
ICE-49A?  or the ICE-85B?  I am trying to figure out how the ROM
software works with the ISIS part.

They sure did some strange programming thru the RST's to make fast calls
to short routines.

Bill

[Vale, Martyn]

Hi Bill,

Yes, they are all in Mark Ogden's Repository under Intel80/ice49 and Intel80/ice49a

I think from memory the Controller Board communicates with the MDS ICE software via a DMA hole in the main MDS memory, I seem to remember around the 7000-8000H region.

Bye

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/1ac086b3-8445-4534-b30c-7bc6b8fee93f%40nj7p.info.

[William Beech]

Martyn,

I found the ICE material on Mark's repository.

Yes, they use "blocks" of RAM to pass messages back and forth.  I will
leave that to you to figure out.  I suspect all the ICE modules use the
same communications protocol.

Bill