Subject: How big are the hex dump files supposed to be?

From: "jhogerhuis" <jhoger@...>
Date: Fri, 16 Apr 2004 18:51:08 -0000

The ROM dump hex files encode 32K of binary data each. 
 
Neil's conversion is coming up with 16K binaries, I'm coming up with 
32K (the addresses go to 7FFF. 
 
How big are they supposed to be? 
 
The MBM 29F080A is a 32 64K sectors. Would that mean these flash 
images should actually have 32 64K size files and not 32K (as the 
are) or 16K? 
 
-><-  confused...

---

From: "Neil Morrison" <neilsmorr@...>
Date: Fri, 16 Apr 2004 14:31:14 -0700

I'm going off the notes on http://www.linux-hacker.net Home / Other
I-Appliances / MailStation / MS/Z80 hacking which describe the bank
setup:-

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are 4 slots, of 16k each, at #0000, #4000, #8000, & #C000.
Only slot #4000 & slot #8000 have been observed to be swappable, with
codeflash swapping into #4000, and ram into #8000. Also, it seems
everything except the ram uses #4000 slot. (LCD, dataflash, Modem,
caller ID)

slot #0000 is always codeflash page #00
slot #4000 is codeflash pages #01 to #3f (Or LCD, dataflash, Modem,
caller ID)
slot #8000 is ram pages #1 to #7
slot #C000 is always ram page #00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It seems to me that this is logical but I'm willing to accept
corrections. Don't forget that there is a lot of text material in the
roms along with all the graphics which are used, so any 'code' in
there is irrelevant. I may try to write an 'emulator' which runs
through the roms and maps out the actual code used and the calls
made.

Also, see "U202 - M5M51008-70 ----- 128 kbyte static ram (cpu data)"
which implies that this ram may be bank switched in the C000 space!

Anyone got a service manual for the Mivo 100?

Neil

----- Original Message ----- 
From: "jhogerhuis" <jhoger@...>

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Fri, 16 Apr 2004 15:20:06 -0700

Well, there is real live code above 4000 in the page 0 hex file. It
disassembles fine and doesn't look like data. In fact, I found some code
there which calls the sector erase function I discovered.

The slots are just chunks of the CPU's address space where blocks of
flash and RAM are mapped in via I/O port accesses. The way the hex files
are broken up is an independent issue. Personally I'd like just to see
the raw 1Meg dump, and then I'd feel better.

I have what's there all disassembled and I can grep for IO. That's how I
found the flash byte write, sector erase and parallel port I/O.

Actually, I just looked at the data sheet again, and it seems they just
have a typo. They say on page 4 that there are 32 64K sectors, but it's
a lie. The picture contradicts, as does the math since then we'd have a
2M chip instead of 1M. Okay, I feel better now...

Service manual type information is probably considered by Cidco as a
trade secret and would likely only be available under NDA, but if it's
out there great. My guess is we're on our own. The port map and memory
map from linux-hacker has been very helpful.

They are selling these units possibly at break-even or slight loss in
order to get follow on email subscribers. So unless we're ready to
partner with them they probably don't have much incentive to give out
the info.

-- John.

---

From: "jhogerhuis" <jhoger@...>
Date: Fri, 16 Apr 2004 22:49:31 -0000

BTW, in my disassembly I am seeing call's to addresses in the 8000 
range, so this information from linux-hacker is not completely 
correct. Sometimes at least, code is mapped into the 8000 slot. 
 
-- John. 
 
--- In [email-masked], "Neil Morrison" <neilsmorr@h...> 
wrote: 
> From: "jhogerhuis" <jhoger@p...> 
>  
>

---

From: "jhogerhuis" <jhoger@...>
Date: Fri, 16 Apr 2004 23:18:45 -0000

In fact, this may be useful in that it is conceivable that code runs  
from RAM while reprogramming the flash.  
  
The pages I saw making calls to 8000 addresses are:  
  
Page 0x00,  
Page 0x11,  
Page 0x12,  
Page 0x13,  
Page 0x14,  
Page 0x15  
  
I should be able to figure out soon which code page(s) is(are) being  
mapped to 8000. It's probably either 1 or 0 though.

---

From: "Neil Morrison" <neilsmorr@...>
Date: Fri, 16 Apr 2004 17:02:53 -0700

I suspect that the machine may run with 32K of ram in the top half of
memory, the top 16K being fixed, and that the 512K of flash rom is
used as a sort of disk drive, being banked in and out of somewhere.

We have 128K of ram, 512K of flash rom and 1MB of flash rom all being
mapped into 64K.

Neil

---

From: "Neil Morrison" <neilsmorr@...>
Date: Fri, 16 Apr 2004 17:32:47 -0700

----- Original Message ----- 

> correct. Sometimes at least, code is mapped into the 8000 slot.

Could be when you want to swap rom you jump to the ram and call the
routine that swaps rom banks then jump to the rom. You can't really
be 'in' the rom when it switches because of timing. I note there are
routines that jump to 0000 where there are a series of NOP's.
Possibly a delay?

If most all of the calls and jumps are to 0000 - 7FFF then that would
clinch it. I wouldn't be surprised if there is a little software in
ram here and there for special purposes.

Neil

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sat, 17 Apr 2004 00:43:46 -0000

The first #0F43 bytes of page #01 are copied to RAM at #8000, 
then jumped to.

This is the reflash code.  Since it has to erase the ROM before
loading the new code, it (reflash) can't run from ROM.  So, while
the code may be ORG'ed #8000, the rom holding that code is 
mapped into the #4000-7FFF slot.

The rest of page #01 is ORG'ed to the #4000 slot.  (At #4F44, 
it is re-ORG'ed to #4F44.)

The code that copies reflash to RAM, then jumps to that copy,
is at #1BC0.

The call to #1BC0 is in page #03 (which just happens to also be
mapped to the #4000-7FFF slot.  IOW, page #03 in slot #4000
makes a call to #1BC0 in page #00, which swaps page #01 into
slot #4000, copies part of it to RAM in slot #8000, then jumps to 
that ram.  One of the first things this code running from RAM
does, is erase the codeflash chip.

The SECTORS that it erases are 64K, or 4 pages each.  
There IS at least one typo in the Fujitsu data sheet.  Under the
heading "FLEXIBLE SECTOR-ERASE ARCHITECTURE", it says
"Thirty two 64 K byte sectors".  There are just sixteen 64 Kbyte 
sectors.  16 x 64k x 8 bits = 8 Megabits, and the 29F080 is
an eight megabit chip.  

You can split the files up any way you find convenient (the rom
is really just a 1 Megabyte block of data).  I think that for 
disassembly, 16k files are best.

There are two pages in each of the 32 hex-dump files, where a
page is defined as the chunks that are bank-switched. 

Also, the RAM is eight pages of 16 kBytes each. 
(8 x 16kBytes = 128 kBytes) 

Cyrano Jones

---

From: "jhogerhuis" <jhoger@...>
Date: Sat, 17 Apr 2004 00:48:06 -0000

Quite possible. I'll have to look into that. Anyway the calls are to 
the following addresses (these are ones that had more than one 
'call' to them): 
 
8003 
8009 
800c 
8018 
8021 
8024 
8027 
802a 
802d 
8036 
8048 
804e 
805a 
8060 
8124 
8128 
8228 
83c1 
86e4 
 
There are about 50 more but each of them is only ever called once. 
There might be interesting ones in there as well, but these ones are 
more likely to be general utility functions. 
 
Do you get the feeling this group is dead except for what we're 
doing? 
 
-- John.

---

From: "Neil Morrison" <neilsmorr@...>
Date: Fri, 16 Apr 2004 17:51:57 -0700

----- Original Message ----- 
From: "Cyrano Jones" <cyranojones_lalp@...>

> ....

But surely you should treat it as 64 * 32K where the lower 16K is the
page000 section in each case?

> page is defined as the chunks that are bank-switched.

Which means that for disassembly you need an "ORG 4000h" at the start
and again half way through? I found it easier to deal with in 16K
sections.

Neil

---

From: "jhogerhuis" <jhoger@...>
Date: Sat, 17 Apr 2004 01:03:21 -0000

Curious, did you just figure this out or did you already know 
this... 
My impression was that no one has gotten this far, but 
maybe I'm looking in the wrong places. 
 
Anyway, that's fantastic. Do you know where the parallel 
port monitor which starts the reflash is at? Also, 
do you know if there is a way through the internet 
connection to reflash? That's my immediate goal, is  
to flash the device non-invasively. 
 
Thanks! 
 
--- In [email-masked], "Cyrano Jones" 
> > > Only slot #4000 & slot #8000 have been observed to be 
swappable,  
> > with  
> > > corrections. Don't forget that there is a lot of text material 
in  
> > the  
> > > > Neil's conversion is coming up with 16K binaries, I'm coming 
up  
> > > with  
> > > > images should actually have 32 64K size files and not 32K 
(as  
> > the

---

From: "jhogerhuis" <jhoger@...>
Date: Sat, 17 Apr 2004 05:52:54 -0000

Do you know what the entry point is to the routine in Page 3 that 
calls 1bc0? And who calls it? 
 
And by first 0f43 bytes of Page #1 you mean the beginning of the 
second half (4000 on) of file Page00.hex, correct? 
 
I'm trying to figure out first what sequence of interactions on the 
parallel port and/or keyboard lead to entering the reflash 
procedure. After that is nailed down then I will dive in to the 
reflash itself, assuming no one has already done this.

---

From: "Neil Morrison" <neilsmorr@...>
Date: Sat, 17 Apr 2004 14:30:08 -0700

Couple of questions.

Where does the 512K Flash ROM map into? 4000? 8000? When does this
happen? At shutdown?

Is the printer port fully bi-directional? If so, I assume you could
configure it as a serial port using software.

Neil

----- Original Message ----- 

> ...

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sun, 18 Apr 2004 12:35:04 -0000

--- In [email-masked], "Neil Morrison" <neilsmorr@h...> wrote:
> be 'in' the rom when it switches because of timing.

You are right, you can't switch the bank you are currently executing
code from.  But you can switch the others.  Rom page #00, which is
always located in slot #0000 (#0000-3FFF) has the routines that
handle the bank-switching for slot #4000 (#4000-7FFF), and also
for slot #8000 (#8000-BFFF).

The difficulty with bank switching is that it takes two instructions
minimum to jump to a page that is not already banked in.  One
to select the new page, and another to jump (or call) to it.  If you
try to switch the page you are currently executing from, and you set
the page register with a new page number, the CPU is whisked
away to the new page before it can fetch the jump instuction from
the old page.

The mailstation handles this by making any inter-page calls to
pages #01 thru #3F (in slot #4000) indirectly, going through 
fixed page #00 (in slot #0000).  Code in page #00 handles
saving the old page number for slot #4000, setting the new page 
number, calling the routine in the new page, and on return 
restoring the old page number.

There is a routine at #19AE, with parameters DE=newpage,
and HL=address_in_that_page, that handles this.  There is
also a set of what might be called "page jumps", starting at #003C,
that load DE with a page number, and then jump to #19AE.  You can
think of these as "worm holes" to the higher pages, where HL
holds the address you want to be at on the other side.

Also, starting at #059F there is a really long jump table.
Some of the routines that this table jumps to are in page #00,
and there is just a regular jump to the actual routine.  But
most of the routines are in other pages, so there is a
"LD HL,nnnn" and then a jump through one of page-jump
worm holes.

From the calling routines perspective (slot #4000), a call to this 
jump table is just a call to a routine located in slot #0000, 
even though the actual code will run from slot #4000.

There is also a second bank switch routine, that is almost 
the same as the one at #19AE.  This one is at #1952, and it 
takes it's page & address parameters on the stack.  This one
has an entry in the above mentioned "really long jump table",
at #05ED.  To call an arbitrary page via this method, you
just push the page number and the address on the stack,
after pushing any other params the called routine needs,
and then "CALL #05ED".  I don't know why there are two
ways to do it.

There are other routines in page #00/slot #0000 that access 
the  dataflash, LCD, and modem, by swapping them into
slot #4000, and the ram using slot #8000.

> I note there are

Yeah, that is a bit of a mystery why the code doesn't start
right at #0000.  The z80 "restart's" vector to this space,
could be that they left it open in case they ever wanted to use
them???

Cyrano Jones

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sun, 18 Apr 2004 13:10:03 -0000

--- In [email-masked], "Neil Morrison" <neilsmorr@h...> wrote:
> 
> Where does the 512K Flash ROM map into? 4000? 8000? 

4000

>When does this

My guess is whenever its needed.  But I also wondered if maybe
it is cached in ram to save wear & tear on the flash???

> configure it as a serial port using software.

The data lines are, and I think the control bits are too.  Don't know about
the status bits.  I have seen no evidence of the mailstation using
a serial port, but if you meant writing new code to bit bang it,
sure.  For rs232, you might need to clip the voltages to protect
the cpu.

Cyrano Jones

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sun, 18 Apr 2004 13:55:03 -0000

--- In [email-masked], "jhogerhuis" <jhoger@p...> wrote:
> calls 1bc0? 

#03:451C

>And who calls it? 

#06:45F9

> second half (4000 on) of file Page00.hex, correct? 

Yes.

I think I see where the confusion comes from.  I hadn't noticed that the hex
files were named "page00.hex" etc.

The mailstation switchable "slots" are 16k each, and the "pages" that
are switched in/out of those slots are 16k each.  Since virtually 
nothing was known about the inards of the mailstation when the
dump was made (almost 3 years ago???) you should not infer any
meaning from the sizes/filenames, except the order that the files
map to the rom.

Once again, each of the hex files contains two of the switchable 
pages.  (just making sure we are all on the same "page".)   :^)
((Sorry!  I couldnt help it!!!))

Cyrano Jones

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sun, 18 Apr 2004 14:05:59 -0000

> Curious, did you just figure this out or did you already know 

Actually, rogblake posted this quite a while ago.

> maybe I'm looking in the wrong places. 

look here:
http://www.linux-hacker.net/cgi-bin/UltraBoard/UltraBoard.pl?Action=ShowPost&Board=mswhatever&Post=53&Idle=0&Sort=0&Order=
Descend&Page=0&Session=

I don't know if above link will come through ok.  If it
doesn't, just look up the thread "just deals mailstations"
on linux-hacker.

Cyrano Jones

---

From: "Neil Morrison" <neilsmorr@...>
Date: Sun, 18 Apr 2004 09:44:09 -0700

----- Original Message ----- 

> >When does this happen? At shutdown?
>

That would make sense. You have 128K of battery backed banked ram to
work with and so you can consider the 512K flash rom to be a solid
state disk drive. I gather from other linx hacker comments that the
"sector size" for this rom is 2K but perhaps they map in 16K blocks
to work with.

> sure.  For rs232, you might need to clip the voltages to protect

I see strings in the rom like "38400192009600..." which I suspect are
for some display purpose and not just modem strings to process.

Neil

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Sun, 18 Apr 2004 13:10:17 -0700

AFAIK flash gets neither worn nor torn by reading, just by writing.
Right (yes, I've been wrong before...)?

And even then the real age of a sector I'd think would be how many times
it has been erased (you don't erase a sector every time you write to
it).

I wonder if that custom Z80 has a UART, even if unused? Microcontrollers
often have built in serial ports.

-- John.

...

---

From: "Neil Morrison" <neilsmorr@...>
Date: Sun, 18 Apr 2004 17:56:22 -0700

----- Original Message ----- 
From: "John R. Hogerhuis" <jhoger@...>

> Right (yes, I've been wrong before...)?

Sounds reasonable.

> often have built in serial ports.

Could be. If we can provide a real or simulated serial port we could
connect the machine to other computers, maybe even to a PDD 1 or 2.

Neil

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Mon, 19 Apr 2004 01:31:11 -0000

> AFAIK flash gets neither worn nor torn by reading, just by writing.

I guess maybe cached was not the right word.  What I meant was
more like a ramdisk, where files would only write through to flash
if the ramdisk was full, or on powerdown.  

That way, when you download, read, then delete a message, it
might never touch the flash.  I'm not saying this is likely, 
just a possibility.

The ram is powered, whenever the powerpak is plugged in, or 
batteries are installed.  And it seems to make a difference to the
mailstation if it is turned off with the power button, or the cord 
pulled.  When shut off properly, it comes back on right to the 
main menu.  But if you pull the power cord while it is on, it says
"scanning memory", and goes to a "reset system data" menu.
 
Cyrano Jones

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Mon, 19 Apr 2004 02:14:35 -0000

> "sector size" for this rom is 2K but perhaps they map in 16K blocks

The dataflash (28SF040) has 2048 sectors of 256 bytes each.

And it is mapped into slot #4000 1 page of 16k (or 64 sectors) at
a time.  
 
When any particular page of 64 dataflash sectors
is mapped to slot #4000,
The 1st sector is at #4000
The 2nd sector is at #4100
   . . . . . 
The 64rd sector is at #7F00

Try thinking of it from this perspective:  If there is not 
16k of dataflash occupying the #4000-7FFF memory space,
what else is???

You can think of the #4000-7FFF "slot" as a sliding window on a
much larger address space.  The window is 16k high, and it
slides up and down in 16k increments.

You could design a system that slid the window on 256 byte
increments, and then you could put any arbitrary sector at
#4000-40FF.  In that case, you would need 6 more bits of
"page" address.

Cyrano Jones

---

From: "jmareksr" <jimmarek@...>
Date: Tue, 27 Apr 2004 16:20:49 -0000

> and then "CALL #05ED".  I don't know why there are two
Maybe you have analyzed the other differences since you posted this 
note, but I have noticed one important one: The code at 1952 executes 
completely in the alternate register set, which means that you can 
use it to pass parameters in the registers.

That is, you could push the page number and program address on the 
stack and setup some registers and call 05ED. The registers will be 
preserved through the code at 1952 and will arrive at the called 
routine intact. Any return values are also preserved. This mechanism 
makes the presence of the page switching logic almost transparent.

Jim

---

From: "jmareksr" <jimmarek@...>
Date: Tue, 27 Apr 2004 16:55:30 -0000

> to flash the device non-invasively. 
John,

Studying the code that runs at 8000, as described in other notes, has 
convinced me that "non-invasive" reflashing is realistic if you 
connect a parallel port to the ms. Since you will most likely need a 
computer to generate the new code, connecting it to the ms via a 
parallel port should be easy. The challenge will be to figure out how 
to get that code at 8000 to run, and the exact structure and timing 
of the parallel port protocol.

There was also talk about reflashing via email messages. I read some 
postings on the linux-hacker web site about the process of requesting 
a new password from the ISP. It was reported that the ISP set the new 
password via an email. The email appeared to contain a validation 
string. When people tried to change the parameters themselves, the 
emails were ignored. It seemed that the validation string was content 
sensitive. I could not find this thread last night, but maybe someone 
else recalls it (hamilton?).

Now changing a password is certainly different than changing code, 
but I suspect both capabilities exist. What a great way to fix bugs! 
Alas, what a way to infect ms's all around the country (world?). For 
that reason, I don't intend to pursue that reflash technique. But I 
am working on the parallel port method.

Jim

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Tue, 27 Apr 2004 10:51:24 -0700

Hello Jim --

Finding such a bug in the mailstation that would allow reflashing of the
unit by email would actually be the best way I think, since it is
probably the "normal" path to upgrading the unit.

Also it would detect a security flaw that ought to be fixed. I find it
hard to believe Cidco doesn't have a strategy for mitigating such a
circumstance. That said, even if found I wouldn't recommend publishing
an exploit immediately, but first giving Cidco a chance to respond and
fix the bug. This is how it usually works on the security mailing lists.

My guess is, the normal route of upgrade by email requires the user to
type something at the keyboard (password, whatever). This would preclude
an upgrade being done without permission.

That said, there are probably buffer overflows and other security flaws
hiding in there waiting to be exploited. In any event as long as it is
done "the right way" I don't see any moral or ethical issues in cracking
the mailstation, as long as Cidco gets a chance to respond. Who knows,
the mailstation has been out there a while, the exploit we find may
already be in the wild. Should only the black hats know about it? Better
if it gets fixed. But for me, I'd like to help people upgrade to some
more useful firmware over the net without having to hook up any special
cables (and these days a parallel port cable might be considered
"special" by some, where a phone cord is not special).

Anyway glad to hear you're working on the parallel port hacking. Keep us
apprised. I should be back to hacking that code in a week or two, so you
might beat me to the find.

Later,

-- John.

---

From: "jmareksr" <jimmarek@...>
Date: Wed, 28 Apr 2004 18:08:04 -0000

Read message #69 if you want the context of this reply and John's 
worthwhile points.

John,

Your points ARE worthwhile, and I DO consider myself a "white hat", 
so maybe I'll need to reconsider staying away from the reflashing-via-
the-Internet code. BTW, the reflashing emails were reported to be 
invisible to the end user. According to the reports, they did not 
even show up in the email counts, IIRC.

Jim

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Wed, 28 Apr 2004 11:24:35 -0700

Sweet Jesus! That's insane that the user didn't have to do anything to
allow them in. But I feel the same as you, that the report is probably
correct. Perhaps they are using encryption, that's the only thing which
could save them in this scenario, and even then they are asking for
trouble.

Well if we could get support to do it again, we could be ready with a
setup like the following:

1. Set up a Linux box as PPP server to connect Mailstation to Internet
through ethernet connection. Run tcpdump or Ethereral on the Ethernet
connection
2. have the mailstation dial into that box
3. Call tech support and get them to upgrade the unit.

Voila, we have a nice packet trace of the transaction for upgrading the
unit.

We just need a unit that requires upgrading, a reason to call and some
gumption as far as the Linux setup, but I think there are already setups
described on linux-hacker for the Linux box.

I wonder if anyone has already done this?

-- John.

---

From: "Neil Morrison" <neilsmorr@...>
Date: Wed, 28 Apr 2004 15:37:11 -0700

----- Original Message ----- 
From: "jmareksr" <jimmarek@...>

> of the parallel port protocol.

"Get that code at 8000 to run" .. perhaps when the reflash tool is connected
and you select the setup mode on the MS it recognizes the device and enables
the operation from the keyboard?

BTW, I have seen messages which imply that some limited reprogramming can be
done via the phone line.

Neil

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sun, 02 May 2004 06:28:49 -0000

> else recalls it (hamilton?).

This thread on linux-hacker contains a capture of one of the clipmail
messages:  "Mailstation Hacker $100 Challenge!"
http://www.linux-hacker.net/cgi-bin/UltraBoard/UltraBoard.pl?Action=ShowPost&Board=mswhatever&Post=13&Idle=0&Sort=0&Order=
Descend&Page=0&Session=

I'm pretty sure the clipmail commands are related to the pop protcol
extensions that cause problems with some pop servers.  I seem to
remember that someone else did experiments that showed the
problem was that some pop servers choked on the extra mime-types
that the mailstation recognizes (such as "Content-Type: x-clipmail/text").

> but I suspect both capabilities exist.

There are strings in the code regarding downloading applications,
but I don't know if cidco ever offered any extra apps.  If you can
figure out how to download any executable code, then you
can pretty much bootstap your way up from there.

There is some sort of security key, that would surely need to be
"understood" before you could use this route.

Cyrano Jones

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Sun, 02 May 2004 00:07:16 -0700

Someone in this thread on linux-hacked mentioned they believe the unit
may accept reflash right after reset.

Anyone have a logic analyzer? If we could try throwing some characters
to the unit on the parallel port right after reset and see what
addresses appear on the address bus, this might take us to the parallel
port reflash trigger detection code.

A question for the hardware hackers: should any parallel cable work? And
do we think any PC with bi directional parallel port could drive it?

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sun, 02 May 2004 09:35:52 -0000

--- In [email-masked], "John R. Hogerhuis" <jhoger@p...>
> port reflash trigger detection code.

The test for reflash is at #03:451c, and it seems to be 
called continuously while the mailstation is running.

> do we think any PC with bi directional parallel port could drive it?

It uses a parallel laplink style interface.  I don't know if 
a parallel port can drive a "straight" cable and talk to it. 

Laplink uses 5 data lines (d0-d5) to "talk", and the 
5 status lines to "listen" (crossed, data on one end to
the status on the other).

I have some pascal code that matches the mailstation send/receive
routines.  I'll try to post more soon, but i gotta go to sleep now...

Cyrano Jones