From: "jhogerhuis" <jhoger@...>
Apr 16, 2004
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@...>
Apr 16, 2004
I'm going off the notes on (URL)ttp://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
From: "jhogerhuis" <jhoger@...>
with
From: "John R. Hogerhuis" <jhoger@...>
Apr 16, 2004
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.
From: "jhogerhuis" <jhoger@...>
Apr 16, 2004
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.
wrote:
Other
bank
with
Modem,
the
data)"
space!
the
From: "jhogerhuis" <jhoger@...>
Apr 16, 2004
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@...>
Apr 16, 2004
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: "jhogerhuis" <jhoger@...>
runs
being
From: "Neil Morrison" <neilsmorr@...>
Apr 16, 2004
From: "jhogerhuis" <jhoger@...>
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@...>
Apr 16, 2004
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
Modem,
flash
From: "jhogerhuis" <jhoger@...>
Apr 16, 2004
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?
the
really
are
would
in
From: "Neil Morrison" <neilsmorr@...>
Apr 16, 2004
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?
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@...>
Apr 16, 2004
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!
wrote:
8000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#C000.
swappable,
seems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
in
in
runs
calls
up
(as
From: "jhogerhuis" <jhoger@...>
Apr 17, 2004
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@...>
Apr 17, 2004
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
From: "Cyrano Jones" <cyranojones_lalp@...>
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 18, 2004
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.
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@...>
Apr 18, 2004
4000
My guess is whenever its needed. But I also wondered if maybe
it is cached in ram to save wear & tear on the flash???
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@...>
Apr 18, 2004
#03:451C
#06:45F9
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@...>
Apr 18, 2004
Actually, rogblake posted this quite a while ago.
look here:
(URL)
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@...>
Apr 18, 2004
From: "Cyrano Jones" <cyranojones_lalp@...>
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.
could
know about
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@...>
Apr 18, 2004
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.
On Sun, 2004-04-18 at 06:10, Cyrano Jones wrote:
...
From: "Neil Morrison" <neilsmorr@...>
Apr 18, 2004
From: "John R. Hogerhuis" <jhoger@...>
Sounds reasonable.
times
to
Microcontrollers
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@...>
Apr 18, 2004
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