Subject:	Seemingly 'dead' New-generation 497 Handbox
Sent:	Sunday, November 21, 2010 20:59:58
From:	somethingscrooked@uku.co.uk (somethingscrooked@uku.co.uk)
I bought a new model 497 handbox, which the owner claimed worked
perfectly until he killed it by a bad upgrade download from PC.I figured
I could perform a safe-download and get it working again, so got it for
$35.00.

I made a +9v powerup connector for it and tried the safe download
key-combination while turning it on many times, but It has never given
any indication of life no sound or display on powerup and I am inclined
to think it is toast. But, I'm not ready to quit yet.

All the onboard chip resistors, chokes, diodes and transistors also
check out OK and there is +5v at all the proper places so the +9v to 5v
conversion is functional.  When I find my freq counter, I'll check the
clocks too - what I really need is an O-Scope.

I also removed, examined and reseated the display connector and cleaned
off all the keypad-contacts on the boards front side assuming contact
residue may be impairing pressed-key detection but  No change. No beep,
no display, no LEDs.

My question is, does the unit need a functional display to operate?

Since everything is dead, I'm inclined to suspect the MPU. Would my
replacing the MPU require I pre-program the new MC68HC11E1CFn2 chip?

Do you think 'shotgunning' all the other assorted SMD devices would help
at all? Does anyone have the PIC program/code for the 'new' style 497 so
I can reprogram and replace mine if that is the culprit?

Has anyone successfully revived a totally dead handbox by chip
replacement or other means?

Thanks!

From:	richard seymour (rseymour@wolfenet.com)
OK... let's see...

> On Nov 21, 2010, at 20:59, somethingscrooked@uku.co.uk wrote:
>> I bought a new model 497 handbox, which the owner claimed worked perfectly
 >> until he killed it by a bad upgrade download from PC.

>> My question is, does the unit need a functional display to operate?

No.  It just spits commands to the display, it doesn't try to see if
they were accepted.

>> Since everything is dead, Im inclined to suspect the MPU.

Actually, depending upon how/what/why the "bad upgrade" was done, i'd
simply suspect that the previous owner wiped out the SafeLoad
programming.
No useful mc68hc11 code: dead Autostar.

>> Would my replacing the MPU require I pre-program the new MC68HC11E1CFn2 chip?

(a) there is no "Autostar-specific" programming in the MC68HC11.  So
there's nothing to pre-program.
(b) There *is* however, a built-in "boot loader" (not used by the Autostar application) 
that you may be able to employ to reload the main flash memory, especially (or including) 
the boot loader.  The botched upgrade did *not* damage that code (it's deep).
Reading Motorola/Freescale's documentation on the subject would describe it.
it "lives" in the memory space "behind" the on-chip EEPOM.  It can be invoked by tying a 
couple of pins together during reset/boot.
(c) an alternate path would be to reload the Flash Memory itself, and go from there,
but it's probably easier to load the Meade "low memory" code into the Autostar's dynamic 
RAM, and have it "bootstrap" a SafeLoad procedure (since it holds the SafeLoad/Download 
code during an update, anyway)

For starters, read Gene Lynol's adventures in reprogramming a 494 Autostar.
http://home.comcast.net/~lynol1000/as_494_gc/index.html
Since they don't have "SafeLoad" code, he activated the M68hc11's internal "boot loader" 
and took it from there.
The normal Meade ROM file for the 497 contains the SafeLoad code, too.
Starting 4k bytes into the file is/are the data that just gets "laid in" from the bottom 
end of the main FlashRam.

 >> Do you think shotgunning all the other assorted SMD devices would help at all?

I sincerely doubt if they're dead.  (if you know that the previous owner *electrically* 
damaged the Autostar, that's a different kettle of fish)

>> Does anyone have the PIC program/code for the new style 497
 >>  so I can reprogram and replace mine if that is the culprit?

You don't have a "new" style 497 (the "new" unit is a 497EP, and does not have an 
MC68hc11).  From the point of view of everything, the older version of the 497 (wide, 
offset display connector) and the "newer" (but not "new", which usually implies "newest") 
use exactly the same firmware.  The firmware directs the MC68hc11 to look at a jumper pin 
to see if it has a "new" or "old" display module, and it takes proper action based upon that.
The *difference* is truly minor... there are about 8 characters that the "newer" module 
cannot create, so those bits of the firmware are bypassed in the "newer" model.
But the firmware itself is the same in both flavors of 497.

The PIC code (if you really needed it) is, to the best of my knowledge, unknown outside of 
Meade.  They've "locked" the PIC chips to prevent readout.  One can -guess- the probable 
functioning of them (simple servo loops, encoder readback, LED calibration),  but the 
actual code is a mystery.

>> Has anyone successfully revived a totally dead handbox by chip replacement or other means?

All of the successfully-resurrected electronically dead ones i'm aware of had other 
simpler (non-PIC) problems: blown traces, dead voltage regulators, etc.
Conversely, over the last decade, i only recall hearing of one or two where it really was 
the CPU chip that died.  There has been a higher number of dead PIC chips, but the damage 
is usually obvious (plastic of chip cracked or scorched, also with trace or other 
component damage).

If the other user tried (for example) to cram the 497EP firmware into the 497, that would, 
indeed, blow away the SafeLoad code and replace it with total garbage (from an MC68hc11's 
point of view).

good luck
--dick

And:

Mike's follow-on message reminded me that we hadn't clarified:

> On Nov 21, 2010, at 20:59, somethingscrooked@uku.co.uk wrote:

>> I made a +9v powerup connector for it and tried the safe download key-combination

Just so it's clear (to other readers of this thread): the SafeLoad key
combination for a 497 is:
Press and hold ENTER and SCROLL DOWN (the lower right-most key).
While holding those keys pressed, apply power to the scope and Autostar.

good luck
--dick

Sent:	Wednesday, November 24, 2010 20:21:20
From:	somethingscrooked@uku.co.uk (somethingscrooked@uku.co.uk)
Update to Seemingly 'DEAD' 497...

I wanted you to know that I haven't been sitting on my hands, althoough it
is a bit chilly here at the moment and the extra warmth would keep my tying
mistakes down... I did some tinkering, replaced the MAX232 i/o 232 chip and
fabricated a '505' and now can communicate with the handbox via serial, but
I am still not able to 'see' any life on it. Setting the parameters to
COM@, 9600, 8, 1 n, n and powering up gives me this:BUFFALO 3.4 (ext) - Bit
User Fast Friendly Aid to Logical Operation
Hitting enter gets me this:>
and hitting ENTER again gives me this:
ASM [<addr>]  Line asm/disasm
 [/,=]  Same addr,       [^,-]  Prev addr,       [+,CTLJ] Next addr
 [CR]  Next opcode,                              [CTLA,.]  Quit
BF <addr1> <addr2> [<data>]  Block fill memory
BR [-][<addr>] Set up bkpt table
BULK  Erase EEPROM,                 BULKALL  Erase EEPROM and CONFIG
CALL [<addr>] Call subroutine
GO [<addr>] Execute code at addr,        PROCEED  Continue execution
EEMOD [<addr> [<addr>]] Modify EEPROM range
LOAD, VERIFY [T] < host dwnld command>  Load or verify S-records
MD [<addr1> [<addr2>]]  Memory dump
MM [<addr>] or [<addr>]/  Memory Modify
 [/,=]  Same addr,  [^,-,CTLH] Prev addr,  [+,CTLJ,SPACE] Next addr
 <addr>O Compute offset,                   [CR]  Quit
MOVE <s1> <s2> [<d>]  Block move
OFFSET [-]<arg>  Offset for download
RM [P,Y,X,A,B,C,S]  Register modify
STOPAT <addr>  Trace until addr
T [<n>]  Trace n instructions
TM  Transparent mode (CTLA = exit, CTLB = send brk)
[CTLW]  Wait,          [CTLX,DEL] Abort         [CR] Repeat last cmd

Obviously, serial I/O is now working.
The next thing I did was DUMP the content of the 68HC11 and attached it as
a document to this email.  Then I went looking for PC_Bug11, and found this
JBug11 instead:http://freespace.virgin.net/john.beatty/jbug11_5_main.html 
DL it, the Manual and the Sourcecode (just in case) and have started
reading the 68HC11 manual found
here:http://www-personal.engin.umd.umich.edu/~nnarasim/courses/ece373/alllabs/labpack.pdf
and here:http://www.xs4all.nl/~hc11/thrsim11/68hc11/literatu2.htm

If anyone has a clue what I should do next, please post.
Thanks!

And:

From:	richard seymour (rseymour@wolfenet.com)
Impressive...

Although i know about the embedded debugger, i've never had to resort to it.

Full documentation for the M68HC11 family is available from
http://www.freescale.com
...the manufacturer.
Search on "M68HC11"  and follow the links...

have fun
--dick

And:

Thanks for the 'Freescale' link.  I found all sorts of tools, docs and
goodies for my 68HC11E1 there:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=68HC11E1&fsrch=1&sr=4
It is a shame that there are only 24hrs in a day, 48 in a good long
weekend, and 72 over some good holidays, eh?

This little utility (http://www.weasner.com/etx/autostar/2005/reset.html)
won't work until I can use the keypad - or BS the O/S to 'think' I have
pressed the requisite keys, and so I am left to figure out where the
'disconnect' between Bootup, Rom forcing a read into RAM or Jump to Flash
of the Autostar may be..... And the 'Test Autostar" info here
http://www.weasner.com/etx/autostar/as_testing.html doesn't return anything
usable - just images of Hearts, Spades.. which aren't an echo of the
CNTL-key I pressed.  sigh.  Maybe it's dropping an ASCII bit in there
somewhere.. Will troubleshoot this theory and if so fix it.

So much to learn... so little time.

Any chance I could get a copy of the code of a known good 497.. or a copy
of the code segment you provided to the gentleman with the dead '494?

Thanks in advance!

And:

Middle things first:
 >> doesn't return anything usable - just images of Hearts, Spades..
 >> which aren't an echo of the CNTL-key I pressed.

Actually, that depends upon the character set your PC is using at the moment.
The Hearts, Spades (etc) are part of the low-end (i.e. control characters) of the original 
IBM PC's  character set.  Modern Windows systems still support it, so that programs 
written in 1981 will still work.
See http://en.wikipedia.org/wiki/Code_page_437  for the character set's listing.


On 11/25/2010 10:13 AM, somethingscrooked@uku.co.uk wrote:

> This little utility (http://www.weasner.com/etx/autostar/2005/reset.html)
> won't work until I can use the keypad - or BS the O/S to 'think' I have
> pressed the requisite keys, and so I am left to figure out where the
> 'disconnect' between Bootup, Rom forcing a read into RAM or Jump to Flash
> of the Autostar may be.....

Actually, the "reset.html" routine requires an (almost) fully-functioning Autostar,
since they're using a routine in the Download code (which is part of the Meade code, not 
part of the M68hc11's buried debugger).  So if it ain't booting, and ain't responding to 
"SafeLoad", the chances are the required code is not there.

> Any chance I could get a copy of the code of a known good 497.. or a copy
> of the code segment you provided to the gentleman with the dead '494?

If you have a 497, the full code load is contained in every ROM file provided by Meade.
So, for 43Eg (for example), fetching http://www.meade.com/support/auto/Build.zip will give 
it to you.
The rom file has a 4kb header, and then the rest is the flash memory's load.
It's divided into 32kb "pages", with "empty" (xFF) zones where the m68hc11's internal 
EEPROM will eventually be "mapped" (seen as xB600 through xB7FF when in use, but as x3600 
to x37ff  when looked at in the ROm file.

have fun
--dick

And more:

OK. I sorta figured that out earlier this afternoon... thanks just the
same.  Have switched to DOS/ASCII charset now - but have not yet retried
the serial access (dinner, dishes and putting kids to bed)

What I wanted to share was that in my readings I came across this: eeprom
$f800 $ffff which specifies the EEProm range on my 68HC11E1 processor, and
that is the only area I can actively modify, or that could have been
accidentally modified by the previous owner, right?
So what that means is that my boot/powerup error can or must be in that
area of code... or it would be nice if it was  ;)

Then I have to ask/beg can someone of you do a similar DUMP of there 497
using Hyperterm as I did, and tell me which bytes of that area don't match?
Or better yet, can the DUMP be dumped (odd) and then saved to a txt file
and emailed to me and I'll do the comparing?  

My aim is to find and correct all glitched bits by re-programming them... 
and get it (my bad 497) working again.

Thanks!

And:

> > What I wanted to share was that in my readings I came across this: eeprom
> > $f800 $ffff which specifies the EEProm range on my 68HC11E1 processor, and
> > that is the only area I can actively modify, or that could have been
> > accidentally modified by the previous owner, right?

I fear you're chasing another red herring... since you're running the "buried" debugger,
*it* controls what you see in the f800 area.

You saw:
FFD0 7E E3 57 00 00 00 00 C4 00 C7 00 CA 00 CD 00 D0
FFE0 00 D3 00 D6 00 D9 00 DC 00 DF 00 E2 00 E5 00 E8
FFF0 00 EB 00 EE 00 F1 00 F4 00 F7 00 FA 00 FD E0 00

If you were running a newish 497 with  43Eg in SafeLoad, you'd see:
ffd0  ff ff ff ff ff ff 07 40 07 40 07 40 07 3c 07 40
ffe0  07 38 07 34 07 30 07 2c 07 28 07 24 07 20 07 1c
fff0  07 40 07 1b 07 17 07 13 07 0f 07 0b 07 07 ba 40
(my ancient 497 has an older version of SafeLoad, so the numbers differ a bit)

If you were running a 497 with 43Eg in "regular" (or Download) mode, you'd see:
ffd0  31 39 ff ff ff ff 2f 76 2f d2 2f ce 2f ca 2e 1a
ffe0  2f c6 2f c2 2f be 2f ba 2f b6 2f b2 2f ae 2f aa
fff0  2e 1f 2f a9 2f a8 2f a4 2f a0 2f 9c 2f 98 b8 6b

> > So what that means is that my boot/powerup error can or must be in that
> > area of code... or it would be nice if it was  ;)

Next red herring:  the addresses in the above dumps contain "vectors", not code.
In your dump, when your m68hc11 performs a "reset", it looks at xFFFE/F
It sees (fetches) E000  ... and sets that value into the Program Counter.
The first instruction that actually *executes* is located there: xE000

The addresses below xFFFE are other vectors... which point to other entry points in the
program.  Yours point to various values ranging from 00C4 to 00FD.

Look at the "real" Meade's code.  Their reset vectors are BA40 (SafeLoad) and B86B
(normal).  The other vectors point to the 07xx area (SafeLoad) and the (mostly) 2Fxx area
for "normal".   When the Autostar is operating normally, the addresses below x8000 are
mapped into the static ram, not the flash.  Part of the boot code copies chunks of
programs from Flash Ram down into Static Ram, and then control is transferred down there.

> > Did you get a copy of the DUMP I did when I got the serial comms working?
> > If not, I am sending it again.

Thanks, having the 2nd copy saved me time.

> > Then I have to ask/beg can someone of you do a similar DUMP of there 497
> > using Hyperterm as I did, and tell me which bytes of that area don't match?
> > Or better yet, can the DUMP be dumped (odd) and then saved to a txt file
> > and emailed to me and I'll do the comparing?

ALL of the xf800 to xFFFF region you sent differs from the normal Meade code.
You're running/seeing the built-in debugger (or someone's built-in), which is never
invoked.  For example, your dump has the string "vbtest".  If you search Meade's 43Eg ROM
file, you won't -see- that string anywhere.

> > My aim is to find and correct all glitched bits by re-programming them...
> > and get it (my bad 497) working again.

Unfortunately, you've got a few steep hills to climb.
The memory used to hold the Autostar's program is FlashRam.
The SafeLoad code contains non-interrupt subroutines for "flashing" that ram.
At boot-time, the SafeLoad code is placed into the Static Ram, and control is transferred
there (this is also true for the "normal" code..but it puts its own routines in the Static Ram).
This allows the code (now in Static Ram) to "map out" the upper 32kb of the address space
with pages of the FlashRam as it "burns" it.  The 1MB of 497 memory consists of 32 32kb
pages.  The first 14 (less two) of those contain "program", and the rest have "data".

The programming you're seeing in the built-in debugger knows *nothing* about the FlashRam.
It doesn't have subroutines to burn it, it doesn't have subroutines to "flip" the pages.

good luck
--dick

And this:

Have fun huh?  

Man have I bit off more than I thought...

Since my 497 won't kickstart, and the Astrostar suite, PEC Editor and a
few orher meade-related comm apps I've tried can't 'see' it, how am I
going to repair what I am sure is corrupt bootstrap eeprom code?  Is the
true code in there 'translated', or just 'shifted' xxx bits or bytes in
memory? - I think that is called offset.

The built-in debugger, Buffalo, is the only method that seems to be able
to communicate with my PC.  Even the JBug and PCBug11 programs can't see
anything on the COM1 port I am using (the only one on this Laptop)...

If I understand correctly, either the EEPROM code to boot the 497 on
powerup and run the sequence of load to RAM and then Jump to AddrXYZ to
start it all...  or the Flash at the jump location AddrXYZ is corrupt,
right?

Can you give me a hint of where and how to begin?  My short term goal
right now is to somehow wake up the handbox.. the longterm goal is to
get 'Safe Download' to work.  I read quite a bit of stuff on the HC11E1
and it seems pretty complicated. At the very least, it requires a
different mindset.

So.. its not possible (or plausible) that someone of you could do what I
did with hyperterm, grab a dump from a known-good unit and use it to
'compare' good dump code to bad? And then, reprogram my 'content' code,
vectors or hex-values to look like it?

Thanks for all your info and help so far! 

And:

> If I understand correctly, either the EEPROM code to boot the 497 on
> powerup and run the sequence of load to RAM and then Jump to AddrXYZ to
> start it all...  or the Flash at the jump location AddrXYZ is corrupt,
> right?

You still haven't quite got it...
There is no on-chip EEPROM *programming* involved with Autostar operations, including boot.
Everything controlling the Autostar comes from the FlashRam.
I suspect "page zero" and/or "page one" (if not more) are corrupt.. probably erased.
(i think) You mentioned an update that went wrong... if, in Download mode, the user 
managed to send  "E0"  (that's an ascii E  followed by a binary zero), the Autostar would 
erase those two pages... *except* the Autostar is programmed to not DO that.
But i haven't looked at the SafeLoad code for a number of years (it may not have the 
"safety" check), and the earliest (1.1, 1.2) versions of 497 code didn't have that protection.
So my suspicion is that either the memory got erased, or (as you've been assuming) some of 
the bytes got overwritten (any "1" bit can be flipped to zero with the right effort).

> Can you give me a hint of where and how to begin?  My short term goal
> right now is to somehow wake up the handbox.. the longterm goal is to get
> 'Safe Download' to work.  I read quite a bit of stuff on the HC11E1 and it
> seems pretty complicated. At the very least, it requires a different
> mindset.

Since you also have to deal with the FlashRam burning, it's far worse.

As i do further digging through my old notes, i become puzzled.
I'm not sure why/what you're seeing in your memory dump that you sent.
The Autostar is wired to have the Parallel Port A  control the memory mapping.
Bytes you write to the first device register (location x0000 after the Autostar boots,
but i forget where they are in the Buffalo state you're seeing), you will cause different 
pages of the Flash Ram to appear in the m68hc11's address space, occupying all of the 
space between x8000 to xFFFF  (although "Buffalo mode" may steal some of that back).
The bits which control the map are the upper 5 bits in that byte.
(you may have to write to the Port's control register to set the lines to "output").
So writing x00 to x00 (or the first device register) maps in Page 0 of FlashRam.
Writing x04 to x00 maps in Page 1
Writing x08 to x00 maps in Page 2
Writing x0C to x00 maps in Page 3
Writing x10 to x00 maps in Page 4
Writing x14 to x00 maps in Page 5
...and so on.

> So.. its not possible (or plausible) that someone of you could do what I
> did with hyperterm, grab a dump from a known-good unit and use it to
> 'compare' good dump code to bad? And then, reprogram my 'content' code,
> vectors or hex-values to look like it?

What zone of memory do you want?
The section of ROM (well, Static Ram) i sent includes the Download code.
It starts at x018A  and continues up to x034D
But it expects to already have the device registers mapped to x00-x3F
It does "polled" serial I/O (instead of interrupt driven), since it expects the FLashRam 
mapping/writing to have made the interrupt vectors unusable.
Unfortunately, it's not "position independent" code, most of the addresses it uses for 
hopping between sections are "direct", not relative or indexed.

Do you have a Hex Editor on your PC?

good luck
--dick

And more:

> Can you give me a hint of where and how to begin?

That depends upon what tools and expertise you have (or are willing to acquire).

For some people, it would be far easier to replace the FlashRam chips
(probably just replacing the one which serves as Pages 0 through 0F would suffice).
By "replace", you could "simply" unsolder the existing chip,
re-burn it with the first half of the 43Eg Build.ROM file,
and solder it back in.
Done! (with luck).

Ask around.. a surprising number of people have access to sophisticated soldering stations.

good luck
--dick
p.s.  pages 00 through 0f exist as addresses 00 through 3ffff  in the Build.Rom file
p.p.s. this "hardware" approach may well be the method i'd choose...

Sent:	Sunday, November 28, 2010 00:07:13
From:	somethingscrooked@uku.co.uk (somethingscrooked@uku.co.uk)
Dick,

Thanks for your continued effort in helping me try to get this working. 
You have really excelled in every way, digging out old notes, reading up on
this controller and grabbing dumps and 'snippets' for me  ;-)

You make it sound like alot of fun to be able (technically and physically)
to fix stuff like this.  I wll try, follow your lead, read and try to pick
up on this stuff, but if all else fails, at least I will have tried... and
there's always Ebay for another  ;-)

I'll keep reading and am also doing a University-level course on the 68000
series of CPU, and dug out an old MPU (MicroProfessor68) a PC-looking
teaching tool with serial and parallel ports, speaker, Leds and a 2-line
display to see if I can a  handle on all this or even figure this out.  The
manual is German  :-)

Anyone have a copy of DASM68 and ASM68?  
Was Freeware 680xx tools by www.BirdComputer.ca... which seems to have
gone under.
*********
asm68.exe

   A cross macro assembler that assembles code for the 680xx using a PC

   Supported Processors: 68008, 68000, 68010, 68020, 68030, 68040,
68EC030, 68EC040, 68LC040, CPU32, 68851, 68881, 68882

   Output: S-record, binary

       * asm68.zip (110k) - assembler, manual, and source sample

dasm68.exe

   A cross dissassembler that dissassembles 680xx binary code using a PC

   Supported Processors: 68008, 68000, 68010, 68020

   Output: text file

       * dasm68.zip (25k) - dissassembler
*********

I have several hundred programming and util CDs from 2000-2005 and will
give them a look too

I'm pretty adept at electronics repair - its the CPU and MPU and RAM/ROM
which I hedge on.

I have a PACE and can probably pick up a new hot-air tip for it for chip
removal/replacement... but I'd rather try exhausting all the other things
first.

At any rate, I'll source out the Flash chips just in case...

Thanks!

On Thursday I broke out my PACE and have ordered the necessary x-Traction
and chip removal bits I'll need - or may need.  I have both WinHEX
(http://www.winhex.com/winhex/index-m.html) and HexEdit
(http://www.mediafire.com/?5ylliymrz2m) on my PC.

Subject:	DEAD AUTOSTAR RESURRECTION TIP 
Sent:	Saturday, December 18, 2010 13:04:32
From:	manuel martin (martinlacave@wanadoo.es)
It appears that the MC68HC11E1 is a E9 with the bit ROMON of the byte
CONFIG (103F) set to off.

In case this bit is on you will see the internal EPROM.

In the #497 I had also dead, that bit was on and I see  the Bufalo 3.4
on it.

After putting this bit to cero, I am able to see the external PROM,s,
but still is not working.

I hope this can help a bit.
Best regards
Manuel Martin