Elonex 386 battery (again)

Many of them used 80186 CPUs, which is the embedded CPU version of the

8086[1]. In today's terminology it would be close to being a "system on a chip", since it included the functionality of the CPU, Interrupt controller, programmable interval timers, some address decode logic and other stuff. The main incompatibility was the programming of the embedded ancillary devices was not the same as the standalone devices used on the "standard" PC.

(there was also a big bank of registers called the Peripheral Control Block that had to be accommodated in address space somewhere)

On the plus side it dramatically lowered the component count in the days before high integration south and north bridge chip-sets, and by rights should not have mattered if MS-DOS compatibility had followed the roadmap that CP/M compatibility did. Alas applications programmers soon started hitting the hardware directly in order to get extra performance and with an anticipation that the hardware eco system would be less diverse than was the case in the CP/M days.

[1] I have used them in a number of embedded applications, and to be fair they are quite good... (if you want an Intel x86 platform anyway!)
Reply to
John Rumm
Loading thread data ...

They're too flat. Chip removal tools are made from flat metal sheet, not more than 1mm thick.

Andy

Reply to
Vir Campestris

In message , Theo writes

That is extremely kind, and well worth trying. Thank you. Do let me know if you find it. I have managed to get the old chip out, but if the final solution is that I have to dump the 386 and try the hard drive in something else, that will have to do. I do have an XP box lying around somewhere. Be good to get the 386 running though, but certainly not imperative.

Reply to
Graeme

err... Allen keys are too FAT. The correct tools are flat. Oops.

Reply to
Vir Campestris

You haven't any allen keys sub 1mm????

Reply to
The Natural Philosopher

I've probably removed hundreds of DIL chips and modules over the years (some of the products I supported had 12 EPROMS) and typically used just a small flat bladed screwdriver.

It's mostly down to a combination of technique and access (if you can get to at least one end of the socket easily).

Ease the screwdriver between chip and socket whilst keeping hold of it from the top, then once the tip of the driver is under the middle, lever up and / or down slightly whist keeping the chip parallel to the socket. ;-)

We might (firmware) upgrade 10 boxes (X.25 PADS and Switches) on site at one go so ~120 devices. ;-)

Then it would be a big session in the workshop ... peeling labels, erasing, re-programming (Elan 8 way programmer) and testing. ;-)

I think I nearly enjoyed the 'hands on' of all that sort of thing as much as I did the simplicity of just uploading some new firmware from a local PC or remotely.

Cheers, T i m

Reply to
T i m

How many ended-up embedded in your thumb?

Reply to
Andy Burns

;-)

Not many Andy ... like I said, 'if you had the knack'... ;-)

I think the first time I came across a socketed ROM (after my BBC etc) was an early PC of some sort, AT or PS/2 possibly where I managed to swap / copy the BIOS from a different PC and found it worked and gave me access to more features. ;-)

And I couldn't count the number of RAM chips I added / swapped / moved around on PC RAM expansion boards (I guess you remember a full length ISA RAM expansion board *full* of chips)?

I'm not saying I never got a bit blase and bent a pin or two pulling a chip out but nothing that couldn't be 'fixed' using some needle nosed pliers and the alignment tricks mentioned elsewhere. ;-)

At least I could actually see all the chips / pins in those days. ;-(

Cheers, T i m

Reply to
T i m

The good old days! As a young techie when the phone STD codes changed in the 90s I had the job of reprogramming a turnout system for the the fire service- it used PSTN for backup in case the BT private wire failed, and the numbers were hardcoded into EPROMS on the modem cards at the central site, so it was a case of removing them (like you say, with a scredriver....) copying (just in case!), erasing, editing the code by inserting a 1, programming, and re-inserting.

Reply to
Chris Bartram

I've had one or two embedded in my hand.

But not from changing them - from leaving them pin-side up on a table then leaning on it.

Andy

Reply to
Vir Campestris

I think so. I even look back fondly on dial-up modems as not only did they first prove me with the means to connect to all sorts of remote things (BBS's, other kit, other people) but some quite interesting times trying to prove who was conforming to the 'standards' or not re device functionality and interoperability (training sequences etc).

I guess my appreciation for something like the USR 'Sportster' was because of my experience working on 300 Baud modems for BT where there were actually separate modules for the Modulator and Demodulator (and power and control etc) and the thing was the size and weight of a genuine IBM PC!

Excellent. Real field service work ... not just the box swapping much of it became. ;-(

I think I also had to do a bit of basic programming on our programmer for some urgent fix that HQ came up with for a big customer of ours. All a bit like playing 'Battleships' but it worked somehow. ;-)

Cheers, T i m

Reply to
T i m

Reminds me of a project where we were using a 16 bit wide EPROM for the first time on a 80186 CPU card. Try as we might we could not get a successful combination of hex file format and prom programmer load routine that would yield a good EPROM. Most did not load at all, and the one that did, would transpose the high an low bytes. In the end we phoned another building where there was a team who had used the same device on another project. "Oh yes" they said, we had that problem as well. In the end we needed to produce a utility to fix it. "Oh, does it run on the Vax?" we asked. Long pause, slightly sheepish answer - "er no, the Micropros" (the prom programmer).

Turned out to be a stack of DIL sockets stacked on top of each other with all the address pins cut off, and then hard wired to transpose the upper an lower halves of the address bus! So we pinched that from them since it was quicker than writing a program to reformat the hex file ;-)

Reply to
John Rumm

Frustrating if you have a limited number of EPROMS that don't erase instantly. ;-(

Oooerr.

Doh!

I love that sort of solution. Fixes you can touch, see and make on your own. ;-)

Yesterday my mini Low Voltage Disconnect board turned up that I was hoping that that, along with one of those watt/Ah/-o-meters and a bunch of headlight lamps would make an automatic battery discharge / cycle [1] / capacity-measurement jig.

The LVD has a 3 segment LED display and two push buttons, one for the low voltage threshold (so typically 10.5, 11 or 11.5v) and the other sets's the hysteresis on / for the recovery voltage (so say 1V, if the low is 11.5 and you want it to re-enable the load at 12.5V).

Now, I didn't want it switching the load back on at any voltage (as it would over discharge the battery) and when I tested it on the bench PSU, it seemed that once the LV threshold had been triggered, you had to go up past to HV threshold for it to re-trigger but I assumed that meant the typical starting voltage would have to be higher than the HV point?

So, I had the idea of setting the HV point to say 12V (most charged batteries would be above that) and wiring the input and output round the other way (in for out, not + for - ) and then adding a momentary pushbutton across the +ve's (they were the only ones switched by the relay) so that when it disconnected the load (in this case a HD relay), it would also de-power / disconnect itself. ;-)

This would also give me the advantage of a 'Start' button. ;-)

However, testing it again just now (wired conventionally) and with the HV hysteresis set to +4V over LV and the battery voltage way below that, it does seem to fire up and work, so maybe it only needs to see that HV point, *after* it's been past the LV?

The good news though is that if my wiring reversal works, I should have a reasonably cheap and simple solution, avoiding the need to do any programming on an Arduino etc. ;-)

Now, if I want to log the discharge voltage, I have a nice Charger / discharger / cycler that does that but only up to about 30W on discharge. Fine for a small batter but not if you are testing two 75Ah mobility scooter batteries as I was for a neighbour the other day. So, I parallel the discharger with my external load but had to be there to monitor the LV point to disconnect my external load.

Now I've got a 5A effect PCB and I'm hoping to be able to put that in the discharge leads on the fancy logging charger and have that operate a relay to the external load so that is also switched on and off automatically. Ok you can't also display the current and so power / Ah etc that way but the external power meter can do that and even if unattended, the Ah reading will still show.

Cheers, T i m

[1] If I use the LVD board as designed but with a HD *C/O* relay on the output, I should be able to put the charger on the NC relay connection and the load on the NO connection and with the hysteresis voltage set suitably, get the unit to 'cycle' the battery (all be it not as fully charged as it would if left on the charger permanently ... unless I set the upper voltage on the LVD to way over the max on charge and 'sensed' the illumination of the 'Fully charged' LED on the charger and reset the LVD). ;-)
Reply to
T i m

I'd already solved your problem before I reached the end of your post!

Why not program one EPROM then read it back and save the file. Then use THAT file to program all the other EPROMs?

Much quicker than the time taken to go and borrow the other team's hardware solution!

Reply to
Terry Casey

Yup, ISTR we tried that...

Alas when you read the prom to a file, it creates a hex file which if reloaded, would duplicate the prom exactly.

The programmer only supported a limited range of hex file formats for saving, but a much wider range for loading. So you could not get it to generate exactly the same format that it was having difficulty loading.

(I can't actually remember for sure at this juncture if the fault was the prom programmers interpretation of the file, or the Tektronix development system's locator creating a slightly broken hex file).

There were only 5 mins down the road.

Reply to
John Rumm

ISTR that swapped lines, data and/or adress lines, were used as protection against reverse engineering. (Along with such pleasantries as having the designations ground off the chips...)

A quick google shows it may also have been used to ease the layout.

Thomas Prufer

Reply to
Thomas Prufer

Possibly, but not in this case - it was a CPU card designed in house. You could load the hex file into the programmer, and check it on its screen there, and it was already transposed at that point.

Reply to
John Rumm

We never went to 16-bit EPROMs - we just used 2 8-bit devices. It so happens when we designed the first 16-bit CPU the price of the small EPROM we were using was now more than the next size up. So suddenly instead of being tight on space we had 4 times what we needed.

But... we had this problem too, the tools would only produce a hex file with for a single address space. I don't think it took more than a day or so to knock up a a C program to split it into two different files.

Andy

Reply to
Vir Campestris

It turns out the chip in my junk box is a MAX1691CHE515, which is not IBM PC compatible.

However the DS12C887A+ is, and is currently available at the usual suspects:

formatting link
formatting link
(there are also some on ebay, but with old date codes - probably pulls from equipment and likely with flat batteries)

Theo

Reply to
Theo

In message , Theo writes

OK, but thanks for looking.

Perfect. eBay 'bargains' noted, too.

Reply to
Graeme

HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.