Hypothetically - How would you flash a 35s?



#28

If you had unlimited time and resources, how would you write data to a HP 35s from a computer (i.e. program data)?

Ditto for the 33s.


#29

You can't the CPU has ROM inside and it cannot be rewritten.

- Pauli


#30

A perfect example of the dangers of cheaper 'mask' devices.


#31

IMHO, this is not a matter of "cheap" devices. It's just that mask ROMs are the right choice for any product which is intend for large-volume production. Mask ROMs were used in the HP-35, and in many -- if not all -- HP calculators. All the Classics, Woodstocks, Spices, Voyagers, Pioneers use masked ROMs.

Joel Setton


#32

Quote:
IMHO, this is not a matter of "cheap" devices. It's just that mask ROMs are the right choice for any product which is intend for large-volume production. Mask ROMs were used in the HP-35, and in many -- if not all -- HP calculators. All the Classics, Woodstocks, Spices, Voyagers, Pioneers use masked ROMs.

Joel Setton


Of course this is right. I should have emphasized that if you're going to commit code to a mask, you can't be cheap about testing it. I think that's what crept into 35s, and goes along with the physical cheapening of some models. In my own experience, the steady move to 'bottom-line' management of development has pushed out even obvious quality and technical considerations.

#33

Ha, don't be put off by these negative nellies ;), with hypothetically unlimited time & resources, anything is possible.

Option 1: dig out the CPU die from under the resin blob (if you find an ingenious method of doing so without destroying stuff you need to keep, let me know), get a new CPU die, programme it and put it in place of the old one (again if you find an ingenious method of doing so with hobbyist tools, let me know).

Option 2: cut out the resin blob and some surrounding parts, create a piggy-back board that replaces what you cut out (including a new programmed CPU) that "pins-out" onto the cut tracks.

Option 3: Get (make ?) a blank complete 35s PCB, populate it with the neccessary components (including a new programmed CPU) and replace the one in the 35s.

Moral of the story: it requires replacement of the CPU as it contains built-in 256K ROM - not EPROM, FLASH or any re-programmable memory.


#34

Quote:
Ha, don't be put off by these negative nellies ;), with hypothetically unlimited time & resources, anything is possible.

You'll need less than 1/2 of it: sufficient time will do ;^)
Quote:
Option 1: dig out the CPU die from under the resin blob (if you find an ingenious method of doing so without destroying stuff you need to keep, let me know)...

Just sit in front of the PCB and wait until the CPU tunnels through - just some pi times 1E16 s d:-)>

Edited: 18 Jan 2010, 7:33 a.m.


#35

A couple of years ago, I had some smalltalk with another physicist in an elevator. I asked about the probability to end up somewhere else in the universe. You know, the usual things to kill time. He replied that his major concern would be *how much* of us would end there.


#36

I would be concerned *how many* of us would end up in the same place. ;)


#37

Oooh, probability is very low that two of us will meet this way d;-)


#38

In my book anything below 1E-9 is "extremely improbable" and "considered not to occur". 1E-16 is so many orders of magnitude less than that and so close to zero, that as an engineer I say "close enough to zero to = zero" :-)


#39

Extremely improbable events take place around us all the time.

Want something with a probability less than 1E-9? Toss a coin thirty times recording the results in order. My 15c tells me that that was a 9.3E-10 probability event.

Want to get to 1E-16? Toss the coin some more (twenty four more times).

1E-100? 333 times.


- Pauli

#40

Quote:
Just sit in front of the PCB and wait until the CPU tunnels through - just some pi times 1E16 s d:-)>

Hunger and the need for caffiene would be more likely to drag me away :)

Edited: 18 Jan 2010, 11:07 a.m.


#41

I guess my first thought of a solution to this isn't so far off: Stand in front of the cpu wearing only a towel, then take off the towel. HP-35S flashed.


#42

Hmm, I tried that in the office today and it didn't work. Fortunately HP is shut down for a holiday so nobody saw. . . :-D

TW

Edited: 18 Jan 2010, 7:57 p.m.

#43

Interestingly enough, someone at Digitial Equipment Corporation (DEC) agreed with you. Back in the early 1980's, I was working with DECUS (DEC's User Society) and was on the board. I remember hearing from DEC about a group that was tasked with essentially accomplishing ANY project that came their way. Literally. The mission from Ken was to accept any job, any task and any project. With seriousness and sincerity.

The catch was that the group was allowed to couch all responses in terms of time, money and resources. If someone wanted to go to Mars, it might cost them $80B, take 100 years and half the USA propulation, but they would work on a way to make it happen.

I don't remember them ever actually beginning any project, but I know that they did respond to a few companies with proposals. I'm sure that if they still existed, they could take on this project too. :)

thanks,
bruce

#44

I found DMSO dimethyl sulfoxide would dissolve epoxy. I use it freely on my body, it is used by vets. You would not need the pure product to dissolve the blob. Sam

#45

Quote:
If you had unlimited time and resources, how would you write data to a HP 35s from a computer (i.e. program data)?

Ditto for the 33s.


I think you mean user programs, not flashing the ROM. In that case, I'd investigate a machine to press the keys to enter whatever you want. For starters, I'd try modifying a desktop pen plotter. The pen moves in two dimensions and can be made to go up/down. Sounds like a mechanical finger to me!

You'd need some sort of jig to hold the calculator in exactly the right place. Plus software to parse the input file and output the plotter movement commands. You'd need to be mindful of timing issues to avoid getting ahead of the calculator.

Option 2: kidnap Cyrille and force him to use a TI 83 until he agrees to put some form of external I/O on the 35s. :)


#46

Hi David,


Quote:
I think you mean user programs, not flashing the ROM. In that case, I'd investigate a machine to press the keys to enter whatever you want. For starters, I'd try modifying a desktop pen plotter. The pen moves in two dimensions and can be made to go up/down. Sounds like a mechanical finger to me!

Several years ago, I had given some thought to doing just what you proposed - for programming a HP-42S. Unfortnuatelly, I never ran across any usable old pen ploters at the ham radio flea markets or the Trenton Computer Fest. If I could find a small letter size pen plotter, I figured I'd cut out a rectangular the size of the calculator in the middle of the plotter, put some foam backing in it, and then use the plotter to program the calculator. Getting the key pressure right would be the hardest part - would hate to destroy a good HP-42S.

Another though I had, was using one of those single board robot arms that were around several years ago. I had one many years ago, and if I remember right, was programmed using the FORTH language.


Bill


#47

Quote:
Several years ago, I had given some thought to doing just what you proposed - for programming a HP-42S. Unfortnuatelly, I never ran across any usable old pen ploters at the ham radio flea markets or the Trenton Computer Fest. If I could find a small letter size pen plotter, I figured I'd cut out a rectangular the size of the calculator in the middle of the plotter, put some foam backing in it, and then use the plotter to program the calculator. Getting the key pressure right would be the hardest part - would hate to destroy a good HP-42S.

Another though I had, was using one of those single board robot arms that were around several years ago. I had one many years ago, and if I remember right, was programmed using the FORTH language.


Just get yourself a Lego Mindstorms kit. If it can solve a Rubik's Cube (http://www.youtube.com/watch?v=3QOvEG27Gt4) then you can probably make it program your calc. I have not looked into the NXT, but the first gen could be programmed with FORTH (pbForth) and C. I used LegOS (now BrickOS) on mine with an H8 C cross-compiler. That was much better than using the native macro programming.
#48

I know this thread is mostly in jest, but to use a pen plotter as described would entail a lot of work to reprogram it to for the required motions. To begin with, the normal up and down range of motion of the pens is probably not sufficient for the task.

I recall watching these things work, processing AutoCAD drawings, and they often exhibited seemingly very odd behavior. For instance, it might write some text, drawing the outline of the characters, then go and draw lines for 15 minutes, then come back and fill in the outline of the characters. Surely this was caused by AutoCAD, not the plotter itself. But it caused me to wonder what strange algorithm might be used.

In any event, by the time you figured out how to program the plotter, wrote a program to translate characters in a program listing into correct pen motions corresponding to the calculator's keys, made the physical modifications to the plotter, debugged it ... well, you get the idea.

Still, there are stranger things folks spend time on. Like responding to inane comments in a calculator geek forum...


#49

Quote:
I know this thread is mostly in jest, but to use a pen plotter as described would entail a lot of work to reprogram it to for the required motions. To begin with, the normal up and down range of motion of the pens is probably not sufficient for the task.

Yes, that would probably make the suggestion useless. But it got people thinking, and Egan's idea of using the Lego system is probably workable.

Quote:
I recall watching these things work, processing AutoCAD drawings, and they often exhibited seemingly very odd behavior. For instance, it might write some text, drawing the outline of the characters, then go and draw lines for 15 minutes, then come back and fill in the outline of the characters. Surely this was caused by AutoCAD, not the plotter itself. But it caused me to wonder what strange algorithm might be used.

I acquired a large surplus HP plotter for free many years ago. It turned out that the Windows printer driver had a nasty habbit of drawing thick lines like this:
--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +
| | | | | | | | | | | | | | | |
+-- +-- +-- +-- +-- +-- +-- +--
instead of like this:
---------------------------------------+
+--------------------------------------+
+---------------------------------------
In other words, it would draw the width of the line, move forward one pen-width, and draw the next width. It would be substantially faster to draw the length of the line, then move over one pen width and draw another length. In a fit of frustration I decoded the plotter language, worked out the geometry, and created a filter program that detected the case and converted from one format to the other.
Quote:
In any event, by the time you figured out how to program the plotter, wrote a program to translate characters in a program listing into correct pen motions corresponding to the calculator's keys, made the physical modifications to the plotter, debugged it ... well, you get the idea.

I'm not so sure. If any commercial outfits have large software programs for the 35s, something like this could be a real time saver.

Quote:
Still, there are stranger things folks spend time on. Like responding to inane comments in a calculator geek forum...

No argument there!! :)


#50

For most plotters today, I agree that the up/down motion probally would not be enough to do the key presses. But I seem to remember that some of the early plotters had a pretty good pen motion up/down.

I don't think programming the plotter would be that difficult. Just program it to make a "DOT" at a specific x-y location. Map the x-y locations to the specific key of the calculator.

As to AutoCad plotting, we had noticed the same thing at our office. I think they try to optimize the total pen movement - also, if it is a multi-pen plotter, then you want to minimize pen changes. Optimizing it would be like the traveling salesman problem.

A friend of mine has a computerized sheet metal forming shop and his machine exhibits the same behaviour as the plotter. It'll move the sheet metal back and forth and do punching, cutting, folding in a seemly random order.

The Lego Mindstorms look like a great idea. And a lot of fun!.

Bill

#51

I recall the old hp plotter language (HPGL) to be very simple with instructions like PU (Pen Up) PD (Pen Down) And a pretty simple X/Y coordinate system for positioning. I'm not sure the plotter would have the force required to depress the keys. The pens are very light and pressing hard would rip the paper.

That said, the real thing to find to do this would be a small SCARA robot but it would be much more costly.

#52

Ah, yes, I see now, the reference to "flash" in the title mislead me.

I had been thinking of using some transistor controlled unit connected in parallel to the keyboard lines (this would also prevent keypad wear). This would be easier on the 35s than on the Pioneers, as the 35s can be easily opened. However, it may still take hours as one has to ensure enough delay between "keypresses" to prevent the missed keys problem (could use feedback from the "busy" annunciator line?).

This does not provide backup - although I do most of my developing in spreadsheets anyway so have copies of the code.


#53

I don't have a 35s, and given the long bug list, if I had one I would want a ROM re-program if I could get one.

Now that I have admitted my prejudice, it might be understandable why I wouldn't do much work to add automated programming on 35s, but maybe if you could override some of the bugs with user code it would be worthwhile.

#54

Thanks guys.
Very interesting responses.


Possibly Related Threads...
Thread Author Replies Views Last Post
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 481 12-04-2013, 11:14 AM
Last Post: Barry Mead
  PRIME: re-format the flash drive to recover the operating system Harold A Climer 2 361 11-06-2013, 12:22 AM
Last Post: Michael de Estrada
  Bad Flash in HP Prime Han 11 811 09-27-2013, 12:38 PM
Last Post: Han
  Flash Flood Warning: 9/16/2013 (One Week from HHC13) Eddie W. Shore 8 652 09-17-2013, 09:20 PM
Last Post: Craig Ruff
  FLASH? command Andrew Nikitin 1 306 06-18-2013, 01:02 AM
Last Post: Walter B
  [EXCLUSIVE FLASH] Infos about new HP Prime ! Mic 16 905 04-02-2013, 11:06 AM
Last Post: Frank Boehm (Germany)
  No luck getting flash disk to work in 95lx Harald 7 731 03-18-2013, 08:11 AM
Last Post: Harald
  [41CL] Repairing an image in Flash Monte Dalrymple 0 196 01-24-2013, 07:01 PM
Last Post: Monte Dalrymple
  DIYx flash bootloader Eric Smith 11 533 09-19-2012, 07:01 PM
Last Post: Eric Smith
  DIYx flash bootloader Eric Smith 2 232 09-10-2012, 02:27 AM
Last Post: Walter B

Forum Jump: