UpdateSoftware Flowcharts (Apr 28, 2004)

(home)
  1. From: "John R. Hogerhuis" Apr 28, 2004
  2. From: "jmareksr" Apr 29, 2004
  3. From: "John R. Hogerhuis" Apr 29, 2004
  4. From: "Cyrano Jones" May 17, 2004
  5. From: "Neil Morrison" May 17, 2004
  6. From: "jmareksr" May 17, 2004
  7. From: "Cyrano Jones" May 22, 2004
  8. From: "John R. Hogerhuis" May 22, 2004
  9. From: "jmareksr" Jun 1, 2004
  10. From: "John R. Hogerhuis" Jun 1, 2004
  11. From: "Cyrano Jones" Jun 2, 2004
  12. From: "John R. Hogerhuis" Jun 2, 2004
  13. From: "John R. Hogerhuis" Jun 2, 2004
  14. From: "Cyrano Jones" Jun 8, 2004
  15. From: "John R. Hogerhuis" Jun 8, 2004
  16. From: "Manny A. Wise" Jun 9, 2004
  17. From: "a_b_aldus" Jul 4, 2004
  18. From: "John R. Hogerhuis" Jul 5, 2004


Subject: UpdateSoftware Flowcharts

From: "jmareksr" <jimmarek@...>

Apr 28, 2004

I remember when a flowcharting template was a standard tool for
programmers, so when I started trying to follow the flow through the
code that reflashes the code pages, I regressed to using a familiar
tool. I have uploaded a pdf file called UpdateSoftware-0-1.pdf that
flowcharts the code at locations 8581 to 86C7 in code page 1. The
file is in a folder called "Code Analysis" and in a subfolder of that
called "rom-v253yr".

I gave the code the name UpdateSoftware because seemed to describe it
well, but I hold no illusions of any rights to name anything. I think
it might be helpful for someone to start a thread that discusses a
naming convention for the code that we interpret.

I continued to flowchart the functions that "UpdateSoftware" calls,
but I have not finished. Nor have I understood some of those routines
well enough to name them. I did name the code at 81F0 and 825C after
the descriptions posted by John in message #43 (and #44).

The "0-1" in the file name is for version 0.1, indicating something
not really ready for release. I'm sure there are errors in the charts
because I have already found one. I will post an update that corrects
it and includes any corrections you notice.

The flowcharts are intended the show the algorithms expressed in the
code, so sometimes 10 or 20 bytes of loading, pushing, popping, and
adding are reduced to a decision block with "Yes" or "No" paths out
of it.

I will try to finish this, but I covet your inputs,
Jim


1: Subject: Re: [mailstation] UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

Apr 28, 2004

Man, you are a master of documentation and reverse engineering. We covet
your outputs :-)

I scanned through it, I'll look closer later. I didn't see how
UpdateSoftware gets triggered. Perhaps you haven't found that yet?

Also, what program did you create this pdf file with? Can you upload the
source so we can edit it as the group discovers more names for routines
or should we just email them to you?

Thanks!


On Wed, 2004-04-28 at 11:53, jmareksr wrote:


2: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "jmareksr" <jimmarek@...>

Apr 29, 2004

wrote:

It gets called by the code that Cyrano found at 1BC0 (see messages
#52 and #60). The code at 1BC0 jumps to location 8000 which contains
a jump to "UpdateSoftware".


Do you know the saying, "Everything looks like a nail to a guy with a
hammer?" Well, my "hammer" is Adobe FrameMaker. I have used it for
almost 10 years, hated it for the first one or two, and now use it
for all but the most trivial of documents, for which I use Word,
Wordpad, or Notepad. Anyway, I would be happy to upload the
FrameMaker document if anyone can use it. In the meantime, I'd be
willing to maintain UpdateSoftware and the other routines at 8000
based on y'alls input.

Jim


3: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

Apr 29, 2004

Frame... well I guess you'll be maintaining that document ;-)

I have a copy for Winders somewhere, but I doubt anyone else does. We
can just send you updates to make.

Later,


On Thu, 2004-04-29 at 08:18, jmareksr wrote:


4: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "Cyrano Jones" <cyranojones_lalp@...>

May 17, 2004


Below are some of my notes on the update routines. UpdateSoftware
sounds like a good name to me. I didn't name all of the functions,
some are just descriptions of what the function does. I am open
to suggestions for better or more "correct" names for any of them,
but I am kinda partial to "send_tribble" and "recv_tribble". ;^)


81F0 actually writes a whole "logical" sector of bytes (256 bytes).
And it seems that the only time the actual hardware sector
size is used, is during erase. So I would propose that the
word "sector" means 256 bytes, and use "hardware_sector"
when refering to the physical sector. Or maybe "physical_sector"
is better, hell I dunno.


I'm sure there are errors in my info below, too. I always seem
to notice one right after I press "send". I'm not sure just
how many hours it took to type/edit it, but it was too many.
It's funny how notes that are good enough for personal use
seem to need so much editing before publishing. I probably
could keep polishing them forever. But I am determined to post
this tonight, so I will stop, and instead rely on a disclamer:
"This info might be all wrong. Turn back now.
You have been warned." :-)

this line should appear indented.

;; Page #01 of the ROM goes in Z80 slot #4000-7fff. [#0001:4000-7fff]
;; The first #0F43 bytes are copied to ram at Z80 #8000 before execution! [RAM page #05, aka #0105:8000]
;; Addresses in the first #0F43 bytes are org'ed #8000, even though the rom is at #4000.
;;
;; Most of the routines in the "Update code" are clones of non-update mode routines, repeated here so they get copied
;; to ram, making them available to the actual update code, functions [1] & [11].
;; After erasing flash, the only code available will be rom #4000-#4F43, (running in ram at #8000-#8f43).
;; Optionally, pages #00-03 can be left un-erased, but the update routines never call them.
;;
;; #01:4000-4062 Jump table to the various routines.
;; #01:4063-4239 Low level subroutines to access flash roms, and power tests.
;; #01:423A-4580 Strings.
;; #01:4481-4B21 Main firmware update routines, update-host interface, LCD display interface.
;; #01:4B22-4F41 Font data.
;;
;; [function] [called by]
8000 JP #8581 ;; [1] [external]UpdateSoftware() This is the entry point for codeflash update
8003 JP #8901 ;; [2] [4 & 8] HL = Shift_right(DE,HL)de shifted right hl bits (used for flash addressing)
8006 JP #8063 ;; [3] [5] Write_dataflash(pagesector, offset, n, @buff)
8009 JP #8135 ;; [4] [3 & 6] Split_and_clip(ix=@params, bc = "n") (conv addr to pg:sect, clip n to sect)
800C JP #81B8 ;; [5] [1] Write_modeflag (HLBC) (#1F:3F:00 in dataflash )
800F JP #815C ;; [6] [7] Read_dataflash(pagesector, offset, n, @buff)
8012 JP #81D4 ;; [7] [1] HLBC = Read_modeflag().
8015 JP #81F0 ;; [8] [11] Write_codeflash_sector(BC = sector, ix = @buff) (256 byte sector)
8018 JP #825C ;; [9] [1] Erase_codeflash_hardwaresector(B = sector) (64k byte sector)
801B JP #82CB ;; [10] [1] Calculate_codeflash_checksum()
801E JP #86C8 ;; [11] [1] Download_software()
8021 JP #8784 ;; [12] [1 & 11] Recv_sector() (from update host)
8024 JP #8801 ;; [13] recv_word() (from update host)
8027 JP #8817 ;; [14] recv_byte() (from update host)
802A JP #8843 ;; [15] recv_tribble()
802D JP #887D ;; [16] busy_send_byte(H) (raises busy, then calls send_byte)
8030 JP #8887 ;; [17] send_byte(H)
8033 JP #88A2 ;; [18] send_tribble(A)
8036 JP #88D6 ;; [19] tribble_timer()
8039 JP #830E ;; [20] [x] Low_battery_detect() (not called in code update) (p9.5 and p9.6)
803C JP #82FC ;; [21] [1] Wall_Adaptor_detect() ret 1 if +6 volts exists, 0 if not (port9.7).
803F JP #89B0 ;; [22] Render_string_to_lcd_buffer(@string, length, pixel_row)
8042 JP #8A6D ;; [23] Copy a scanline of rendered char to lcd_buffer
8045 JP #8A9A ;; [24] Update the LCD from the lcd_buffer
8048 JP #8AB7 ;; [25] Update banked in lcd-half from lcd_buffer
804B JP #8ADE ;; [26] Clear lcd_buffer
804E JP #8AED ;; [27] Render the char in B to single_char_buffer
8051 JP #8947 ;; [28] Convert word(HL) to hex string(HL)
8054 JP #8917 ;; [29] Copy null terminated string (hl) to (de)
8057 JP #8922 ;; [30] Strcat(de, bc).
805A JP #8936 ;; [31] hl = Strlen(hl).
805D JP #88F4 ;; [32] 2 or 3 second_delay
8060 JP #8987 ;; [33] Display_string(hl=@string, C=pixel_row, A=flag)

;; [8000/8581] [1] UpdateSoftware() This is the entry point for firmware update, after update code is copied to ram.
;; After checking that the powerpak is connected, it receives a single byte "erase command", of which there are
;; two options: #05 = whole thing, #35 = don't erase first 64k. If erase command received (and ack'ed) ok, then
;; a dummy sector is received. Any error up to this point, it loops back to the powerpack test, and tries again.
;; If no error receiving dummy sector, it sets a flag in dataflash indicating "codeflash invalid" (if not already set).
;; Then, right after the message "Software is updating, please wait...", it erases the codeflash.
;; This is the point of no return. Up until you see this message, you can just turn the power off, and nothing is
;; changed. After you see this message (by the time you read it), the codeflash is blanked, and you really want to
;; finish reflashing sucessfully, 'cause I don't think you will get a second chance, even if you left the first 64k
;; intact. One of the things the init code in page #00 does is jump up to page #06, which would seem to completely
;; defeat the purpose of protecting the first 64k (pages #00, 01, 02, 03). Actually, I don't know how long it takes
;; to erase, and it starts at the end and erases toward begining, so maybe you can interrupt it and restart?????
;; When you see the message "New software is downloading, please wait...", it is done erasing, and it calls
;; "Download_software" to load the new code. If there is error, it loops up to just after the powerpack test.
;; I guess that after erasing codeflash, it won't quibble over the power source, and you can load new code on batteries. ;^)
;; If download is ok, it sets the flag in dataflash to "codeflash valid", and then sets a flag in ram, which I am
;; guessing means "ram invalid" (variables won't match new code). Next a checksum is calculated and displayed, and
;; finally, it jumps to #0000 and reboots. I am supposing that the ram invalid flag forces a "cold boot". Also, it
;; sure looks like the checksum is just displayed, and not tested for any particular value.

;; [801E/86C8] [11] Download_software() Does the whole thing, during a single call here.
;; This routine interacts with the update host, receiving new code, and writes it to previously blanked codeflash chip.
;; It calls "Recv_sector" once for each block of 256 bytes of new code, toggling the mail LED every 4 sectors.
;; When a sector with endflag = sector + 1 is received, it returns successful. Any data in this ending sector is ignored.
;; Duplicate sectors are ignored. If you did not erase the first 64k, then any sectors received in that range are
;; ignored. Otherwise the sector data is written to the codeflash in the sector indicated by the packet header.
;; For some reason, after loading pages #00 and #01, it displays the message "Continuing download, please wait...".
;; If any error is encountered while downloading or writing, it returns unsuccessful.

;; [8021/8784] [12] Recv_sector() (params in global ram)
;; This routine drops busy, then receives a "packet" from update host. If there is any error during recv of packet,
;; it sends a "NAK", tries again after first 3 naks, and after 4th it gives up and returns errcode. If packet received
;; ok, it sends "ACK". After sending "ACK" or "NAK", busy is left up. It drops busy the next time it is ready to recv.
;; The data field of the packet is the new code for a single 256 byte sector of the codeflash. Even though it is
;; erased in 64k byte sectors (what I call "hardware sectors"), it is written (by write_codeflash) in 256 byte sectors.
;;
;; Format of received sector packet:
;; esc_char (1 byte)
;; endflag (2 bytes) endflag = sector + 1, means done with code update
;; sector (2 bytes) this is "sector #", or hi 2 bytes of 3 byte address
;; n (1 byte) here, #00 means 256 bytes in data field (data update chokes on n=0)
;; data (n bytes) data for the sector
;; checkbyte (1 byte)
;;
;; The sequence of packets looks like this:
;; #1B, #FFFF, #0000, #00, 256 data bytes, checkbyte
;; #1B, #FFFF, #0001, #00, 256 data bytes, checkbyte
;; #1B, #FFFF, #0002, #00, 256 data bytes, checkbyte
;; ........
;; #1B, #FFFF, #0fff, #00, 256 data bytes, checkbyte
;; #1B, #0000, #ffff, #00, 256 data bytes, checkbyte
;;

Cyrano Jones


5: Subject: Re: [mailstation] UpdateSoftware Flowcharts

(top)

From: "Neil Morrison" <neilsmorr@...>

May 17, 2004

I just got a 120 and a 150. FWIW I suspect the differences are more software
than hardware. One thing the manual says is that when you dial in via the
800 number it will figure out where you are and will usually substitute a
local number. This means that some updating can be done via the phone line,
even if only the phone number.

Neil

From: "Cyrano Jones" <cyranojones_lalp@...>

...


6: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "jmareksr" <jimmarek@...>

May 17, 2004


Wow! Thanks, I'll get to work on updating the flowcharts. I picked up
a copy of TurboCAD 8.0 at a used book store for about $20. I'm
considering converting the flowcharts and putting out the TurboCAD
files in addition to the PDF. Would that be useful?

Jim


7: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "Cyrano Jones" <cyranojones_lalp@...>

May 22, 2004

...

You're welcome.

TurboCAD 1.0 was one of the first (and few) programs I ever bought.
I didn't even have a computer that could run it 'till a year or two
later. I never really used it for much, but it sure was neat watchin'
it draw the "oilrig" demo!!!

If it can render the drawing in a gif or bmp format, it might work
better than pdf for others to edit or add to. Otherwise, pdf is
probably easiest to view for most.

My tool of choice when I need to see a flowchart has been
the "manual graphite display generator". :-)

Cyrano Jones


8: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

May 22, 2004

Free tools you might consider are dia, xfig, sodipodi, ooimpress
(ooimpress is like powerpoint, can read some powerpoint files, it's part
of openoffice.org)

These are all available for Linux, maybe Cygwin. But if I have anything
to add I can just send you comments if you would rather. Just as long as
you produce PDF or GIF or something readable via Free tools.



9: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "jmareksr" <jimmarek@...>

Jun 1, 2004

Cyrano,

I have been reviewing and incorporating your notes, but I have some
questions. Would you prefer to discuss them here or by email? My
address is published (fool that I am), so if you want to discuss by
email, send me a note.

Jim


10: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

Jun 1, 2004

Unless you are nitpicking his code (which I doubt) the list is a
perfectly good forum for this kind of thing.

We're a long way from a noisy list :-(


On Tue, 2004-06-01 at 17:19, jmareksr wrote:


11: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "Cyrano Jones" <cyranojones_lalp@...>

Jun 2, 2004

Hi,

I can't think of any reason to not use the list, other than
not making it too easy for any nitwit to reflash his mailstation.
I'm certainly not worried about annoying the 99% who just
want free email!

My email is this id, at yahoo.com if you want to use that.

Use your judgement, I don't mind using the list. It's probably
the fastest way for me, since I go for days without reading
any of my email boxes. For that matter, a note to the list
to check my mailbox wouldn't hurt (me) if you want me to see
it sooner! I check the web archive of this list more often
than email, usually.

I have been thinking (but not really doing anything) about
what to flash into my mailstation. The reflash code erases
most of the mailstation code, and I wanted to figure out how
to back up the existing code first, if possible, so it can
be patched. I know that if I want v2.53yr, that is moot.
But I still thought it would be good to be able to reflash
without needing to download the code.

Hopefully whatever you flash will allow reflashing again,
and one of the first things I think needs to be fixed is
the all or nothing nature of the existing reflash code.
If you are willing to wipe out the mailstation code, you need
to replace it with something. Maybe a rom monitor, or the
remote code for a remote debugger, or else a whole new app.

Or maybe a new OS? Has anybody here ever heard of UZI???
It is a unix for z80, written many years ago, by Doug Braun.
I don't know if/how he handled the lack of a protected mode.
(URL)

There is a newer version, called uzix, for the MSX computer.
MSX is a z80 system that was popular (I hear) outside of the US.
(URL)

Cyrano Jones



12: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

Jun 2, 2004

I have some ideas on what to put there.

For development purposes, a remote target monitor/debugger like NoICE
would be ideal.

Eventually, what should go there?

Porting CP/M to the mailstation would open up the gigantic library of
CP/M software to the mailstation. My NEC 8500 and NEC Starlet ROMs might
be a starting point, or perhaps just going from CP/M source code which
is available on the web. There's an active CP/M mailing list of folks
who would give profuse thanks for the ready availability of a new CP/M
laptop. The unused portion of flash becomes a flash disk for CP/M to use
as a drive or drives. There are plenty of CP/M compilers (Pascal, C)
which could then be self-hosted on mailstation. There's also Wordstar,
and other popular programs available that could be run without even
porting them (generally CP/M programs do all console I/O to a terminal
emulation).

Some folks on the Model 100 mailing list, including myself are
interested in the Mailstation as an upgrade path from Model 100, so
another track is to get the Model 100 BASIC ROM running on Mailstation.
The Model 100 uses 8085, which is almost identical to 8080 in
instruction set, so it should work on Mailstation. There is also the
WP-2, which is a word-processor feel-alike to the Model 100. It uses
Z-80, and might make an interesting port to Mailstation.

Another idea is an ANS Forth environment like CamelForth loading on the
Mailstation. This would allow programming on the mailstation itself, and
porting Forth to any system is as easy as it gets.

Unix for Mailstation... I suppose that could work. Would open up
possibility of compiling some open source software for mailstation. My
only argument with that is that a most of that stuff is written for more
powerful machines. If you went with CP/M or BASIC or Forth, which were
tailored to 8 and 16-bit systems from the get-go, we'll get much better
performance. The disadvantage is less new software.

I do try to echo progress on Mailstation on my bitchin100.com web site.
Folks here might want to check it out to see what my angle is...



13: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

Jun 2, 2004

Oh another thing you might consider running eventually is the Z80 port
of Contiki.

This has an email client, web browser, VNC server, web server, TCP/IP,
CSLIP for 8-bit machines.

If we added PLIP, it would be ideal for Mailstation since it only has a
parallel port. And we all now have laplink cables I'm sure...



14: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "Cyrano Jones" <cyranojones_lalp@...>

Jun 8, 2004

wrote:

I have been working on a version of my remote debugger for
flashing into an unmodified mailstation. I will post it when
it is ready. (I had hoped to have it before now, but there
have been many distractions...)


I am interested in this, too. The CP/M BIOS should be all you
need to port. That, and you would need to write/find a terminal
emulator.

CP/M likes to have ram in low memory area, so you might
need to make a small mod to the mailstation hardware,
since the mailstation normally has fixed rom in slot #0000.

I have written CP/M BIOS code for console keyboard matrix
scanning (for Megatel Quark hardware), and a ramdisk driver
(for custom 512k bankswitched ram mod on Quark). A driver
for a flashdisk shouldn't be *too* much trouble. :-)


Licence?

[...]
[...]

Multi-boot!

[...]
[...]

Hmmm... I wonder if your ReMem would fit inside the mailstation? :-)

I looked at Contiki.
(URL)
They mention z80 ports, but I can't find any (working) links to
any. (They say there is a gameboy port, and gameboy is z80 based.)

It seems that Contiki will only run apps that are written as
"Contiki apps" (state machine style multitasking). But the
Contiki Tool-Kit might be the easiest way to get a GUI on
the mailstation.

Cyrano Jones


15: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

Jun 8, 2004

On Mon, 2004-06-07 at 22:47, Cyrano Jones wrote:


Looking forward to it!


Sounds like you're the expert... and therefore the stuck-ee ;-) I'm just
learning about CP/M


I've written some flash code here and there. I could definitely handle
that. I need to write one for ReMem anyway which could be used in both
places.


Alas, running the 100 ROM is a cool trick but I wouldn't recommend mass
producing it ;-) or leaving a ready binary for download. I think it
would be sufficient for the developers to each have a genuine
non-operational Model 100 motherboard.

The software to be produced would be a "patch" against a real Model 100
ROM. The end user could apply it themselves. They would be responsible
for never using their mailstation and their Model 100 at the same
time...


If we want to make a mod to the mailstation it is possible. However, the
mailstation is already a pretty capable machine, especially once we turn
it into a general purpose laptop (insofar as a model 100 is considered a
laptop). Probably should at a serial port, possibly make it a USB slave
emulating RS232 behavior over USB... power would come from the host.
Maybe IR to talk to wirelessly to cell phones and printers. The parallel
port is fine for I/O to PC's though.

In fact I am interested in a case mod to the Tandy M102 that would put a
mailstation into a 102 case. So the question beomes would a mailstation
with whatever additional hardware needed fit into a 102 case. Plenty of
room there, and a much better keyboard.


There are at least two, the PC-6001 and the Z-80. I don't know if the
Apple ran some type of CP/M? Or the Commodore 128?


Well state machine driven stuff is not hard to design. In fact just
about all my programs of any complexity end up having a state machine.

What else do we need besides the default Contiki apps? Some kind of
interpreter, Forth or BASIC. Forth is easy to port. And a text editor.


16: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "Manny A. Wise" <mannywise@...>

Jun 9, 2004

I just got a hold of a mailstation 100 (white) I been
told it can be programed to use my regular
earthlink.net email account...any help will be
appreciated.. Thanks!!!

__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
(URL)


17: Subject: Re: UpdateSoftware Flowcharts

(top)

From: "a_b_aldus" <a_b_aldus@...>

Jul 4, 2004


Hi, everybody,

I'am one of the authors of the UZIX (but, guys, it was so long
ago...). I own the MIVO-100 and I only wanted to completely replace
the software and reuse device as some kind of controlling one for my
hobby needs. It looks like this device is very similar internally
(meaning CPU and page banking) to MSX we targetted the UZIX to. I'm
very impressed by all reverse engineering you (and linux-hackers
guys) did! My question is - is there some clean descriptions of the
box internals or one should go thru forums gathering the info and
erratas?

So - if anybody will be interested, I could contact with the Adriano
(current maintainer of the UZIX) looking for possible porting it onto
Mailstation (as soon as it's Z80 CPU).


18: Subject: Re: [mailstation] Re: UpdateSoftware Flowcharts

(top)

From: "John R. Hogerhuis" <jhoger@...>

Jul 5, 2004

I think it would be great to have a unix like OS for mailstation. The
other possibility is CP/M or a complete Forth environment.

Try this link to I/O map on Linux Hacker, it has proven correct so far.

(URL)


On Sun, 2004-07-04 at 14:17, a_b_aldus wrote: