I warned you.

I am in posession of an industrial cpu card from a $100,000 spark eroder whose manufacturer is extinct. The card has chip dates around '9644' so 1997 is a reasonable estimate of manufacture. It's coming up with an error saying there isn't a system on drive B:, insert a floppy, etc. I'm trying to fix the thing.

The installation has no disks, but runs from 2 1Mx8 eproms, and a battery backed ram is in there also, which dies reliably at 10 years old. I think it's a Mostek chip, which is another headache.

It's apparently running 16 bit, but I can only recover is as 2x8bit. 16 bits x 1 meg is enough for a dos system, and some software.

Problem 1 is: how do I take files 8 bits wide and transmogrify them into a single file 16 bits wide?

Problem 2 is: This thing has '486DX' and an AMD '586-133 P75 cpu. That I am familiar with - it is a souped up '486 which fits '486 sockets & runs at 133 Mhz and equals the processing power of a p75. Does that use 3.3V? If so, where the <expletive deleted> do you connect 3.3V on a 16 bit ISA bus. There's NO power plugs on the cpu board.

Do you have any other information and pictures of it? I would love to see how this thing looks like....

As you see it there: On the left is the ram; top left under the fan is the '586 cpu;

/begin skippable technobabble
Under that is an ALi m1429 (Northbridge?). Next column has Battery ALi something (Southbridge?), a Benchmarq (rebranded Dallas Semi?) battery backed ram thing and an ami bios eprom. Right hand column has dip switches labelled Printer; 2 x 27c040 Eproms labelled "1.3C2 R01" & "1.3C2 R02" which I take to be OS, and control program for the spark eroder; Next is a Sony CXK581000AP-10LL - probably 10nS Sram; And the bottom chip is labelled AMIKEY-2.
On the back is an assortment of special purpose ics, an SMC FDC337C665 an mx28f1000L (prom), and a UM61256FS-15 - a hell of a lot of extraneous 8 bit crap :-(.
/end skippable technobabble

Ports are: ps/2 serial, primitive video. Can't find a gpu worthy of the name. No hard disk, floppy, nada. although the board has sockets for ide0, ide1, & fd. Even in 1997, this was a retro pc.

EDIT: Eureka! Finally spotted the LX8385-00CP - a low drop out regulator. The data sheet shows the one application as 5V - 3.3V

Attached Thumbnails

 

Picture is kinda blurry, but I can definitely make it out. That's some old school stuff right there my friend. So pretty much you want to reflash it, or what?

And as going from 8 bit to 16 bit, you could probably whip it some C code to convert over, and then go from there. You going to try to dump the 8 bit segments straight from it?

1 members found this post helpful.

While you don't necessarily have to do that to solve your problem, you could do various operations of this kind with an eprom programmer, which you probably do need.

Haven't heard much from them recently; didn't they get taken over a few years back, or am I just getting them confused with someone else?

I was looking for some kind of primitive video controller, but FDC makes it sound like a Floppy Disk controller.

There looks to be some kind of bus connector; does the voltage regulator get its power from there?

I'm guessing that you don't have source code.

1 members found this post helpful.

I should have access to eprom programmers (I'm in university currently) but I've never seen one that adds two eproms

AFAICT just about EVERYONE got taken over since I started. Everyone who made those battery backed rams seems to be gone when they wear out. Mostek, Benchmark, Dallas Semi. . . am I leaving anyone out? Surprisingly the bq3287 (battery backed thing) hails as an rtc and was made at some point by TI, who still exist.

Yes to both questions. The FDC37C665 eludes a quick google, which seems to bear out your disk controller theory. Standard thing with Industrial PCs is an isa or pci bus (this is isa) and that supplies power to things. Then the pc card drives it. There were even versions that would sit into a 8088 box, give the 8088 the middle finger, take control, and run everything itself.

The video could be very primitive - 80x25 text. I don't think they went to any bother.There is an unnamed ali chip

ROTFL. Source Code? No, they would have guarded that until the death.

The idea is to get the machine working. Whether that's the old pc stood up or a new one, whatever will work. I had thought of addressing both the eproms together, and reading the 16 bits. I gave all this up in 2006, and sold off my equipment; my edge is dull, whereas I was a fairly sharp techie. This is for an old customer, and I (weakly) said I'd try, but they didn't even know there was a pc in it when they called me! First try will probably be with the bios to see if I can stand this up. Simply power it and look at the video. I'm thinking whatever it has will not read a disk, so I would need to replace the OS, or find a final reason why it's all impossible.

So have you powered this beast up yet?

Just thinking, it has to be stand up the old pc.
The eproms will have absolute addresses coded in. Chances are, this will jump to the wrong place if I put a different OS on there, and the code will crash. It's very probably being pointed at the base of the eproms which appear somewhere in the I/O of the PC, and it's told "Execute that stuff there." That will be sensitive to it's position in memory space. If this puts the eproms starting @ 0xF000, for example, and I start them anywhere else, It crashes :-((.

EDIT: I'll stick 5V on this tomorrow, rely on the regulator for 3.3V and see what the video gives.

Oh ok. Watch it power up without a hitch

1 members found this post helpful.

Top Data I/O programmers from about 1980 onwards do this...it isn't necessarily very obvious, and you may have to read the appendix to the manual to work it out. And everyone else wanted to say '...and ours are as good as Data I/O, but cheaper...' so I would have guessed that there was a good chance. So if you find otherwise incomprehensible functions like data shuffle, that's what they are about. If you think about it, when you download a hex file and you want to do anything other than load exactly that data into a linear memory array, you have to be able to do things of this kind.


Battery backed rams are a bit of a pain to make...the chips themselves are nothing special, but packaging the battery in with the memory chip is a bit of a pain, because you can't really do it on your standard packaging line. And then they die...

Very likely for an industrial controller. there were quite a few people who did this kind of stuff, back in the day, who have probably mostly gone away or been bought out by now.


...and then they died....

Anyway, if you don't have the source code, the only thing that you can do is run on something that looks exactly (from the point of view of the executing software) like the original board. And the only code that you've got is in the EPROMs, and they die, too.

1 members found this post helpful.

@corp769: It didn't power up here without a hitch. There must be a separate isa video card buried in there somewhere, something I can't replicate here. In the machine it looks for a system on drive B: and hangs there. Drive B?:-//. Near infinite memory jumpers. A,B,C, 2 position jumper sets for MEM1, MEM2, & MEM3 nowhere near the ram, but beside the various roms.

You'd like to be able to do that sort of thing, but I'm sure my university definitely bought the cheap option. [They are teaching robotics with Lego NXT Mindstorms and a piece of software more suitable for kids].

The eproms are hex. Read into 2 hex files, and I need one byte from each in turn. There has to be a way to do this with head, tail, cut & friends.


I would have stopped at "Battery backed rams are a bit of a pain!", but as we noted, it's an rtc. The sky won't fall in over an rtc.

Even worse. I followed the monitor cable back to find the pc. They told me firmly there was no pc involved, but I saw 'ami bios' on the startup screen and found it:-D.
There must be a separate (isa) video card @%$£! It's just 2 serial ports instead of graphics & serial. And here I was consulting pinouts ready to power the beast, only stopped by the lack of a video output.

:-). True

You are feeling cheery, today - we note the passing of everything/everyone :-P. /waxes poetic
William Butler Yeats wrote his epitaph:"Cast a cold eye on life and death; Horseman, ride on!"
/cops on
Isn't there some address translation wheeze in the northbridge or southbridge which allows programs to run at a nominal address and yet be wherever the pc feels like putting them?

True enough, but I wasn't taking this particularly downbeat approach until I read this thread. Ignoring the stuff about the transiency of organisations, anything with a battery in it has a very definitely finite lifetime. And do people design so that the procedure for the time when that fail comes is easy and straightforward...well, you can answer that yourself.

Additionally, eproms don't have an infinite lifetime; poor, if the initial programming was inadequate or the devices were inadequately erased prior to programming. And depending on temperature, voltage and environmental conditions, and worst-case data a data lifetime (before the first bits start becoming corrupt) of 10 years isn't ridiculous.

There is in PAE, but that's probably only in later chipsets that the one that you are looking at. I don't know of any such thing in chipsets of the age that you seem to have, but then I wasn't really taking much notice, at that time.

I hope we haven't bored people indulging ourselves and swapping observations on the transience of electronic components, companies, corporations, latest things, etc ad nauseum. Let me restate the remaining question, in case anyone is actually reading this drivel.

I have 2x8bit eproms masquerading as a 1x16bit eprom. Can I without special punishment to these (as we have noted) transient components run them on a modern 32 bit cpu? The fact that they ran on an amd '586 doesn't impress me much. My scanner software of similar vintage ran on the '586 (= souped up '486) but definitely barfed on an AMD k-6 & higher.

Can someone give me a command line of linux utilities (head, tail,cut, twist & hack etc.) to take one byte from this input, then one byte from that input, and pipe them off to a third file? Telling me to roll something clever doesn't cut it.

Me again. The memory kicks in occasionally.

Based on memory of running 16 bit dos systems into the ground, the last thing that would read 16 bit from cold was a trueblooded p5 (586) processor. So any later replacement is a dead duck. All this out-of-order execution and fancy stuff killed dos dead. I'll get that pc, try fixing that, or send himm away crying.

Marking this solved. Buying a true '586 is a bit like trying to buy a penny farthing bicycle.

Thanks to all who contributed whatever they contributed, trips down memory lane and hard facts.