From: "Cyrano Jones" <cyranojones_lalp@...>
May 2, 2005
I've been working on a new mboot for the unknown
firmware mailstations today, and I just flashed
the first version of "safeboot.rom" into a 150 v4.05D.
I have control of the 150 now, and can load code
and execute it. I can't display anything on the LCD,
but I expected there to be some differences, since it
is a different display that the older ones had.
I loaded my scancode.hex program, and it blinks the
mail LED when I press keys. :-)
I haven't really studied it yet, but large parts of
the page #00 rom code look identical to the older models.
The code in the LCD routine area is definitely different.
I have to quit for now, but I might get back to this later
tonight. I want to test it on some other models, and
maybe make some changes, but I don't expect it will be
long before I can upload a new version.
CJ
From: "mikewarns" <mikewarns@...>
May 2, 2005
Okay, I guess I'll buy two 150s on my way home. I'm nothing if not
adaptable! :-)
Thanks, Cyrano! I appreciate you doing this work so I don't have to
learn how to do it myself.
From: "John R. Hogerhuis" <jhoger@...>
May 2, 2005
On Mon, 2005-05-02 at 21:08 +0000, Cyrano Jones wrote:
Awesome :-)
Given that you're going to be inundated with folks buying 120's and
150's this is a big step!
From: "Cyrano Jones" <cyranojones_lalp@...>
May 2, 2005
Ok, I lied. I'm still messing with it. My curiosity
once again won, and I flashed the clunky first version
into a violet/purple 120 (old) v4.04E. It works!!!
And the LCD works same as in old brown model. :-)
I also flashed a dark grey 120 (new) v4.05E, and it works
similar to the "new" 150. No display yet.
Now where is that 250, I know I left it around
here somewhere....
Maybe later.
In case anyone just got here, don't flash the mboot.rom
from mailbug ver 0.0.2a into any of the 120/150/250 models,
it will not work.
And to prevent any misunderstanding, there is NO software
to flash yet, just the debugger. And for the time being,
any new software will likely be programmed in z80 assembler.
CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
May 2, 2005
Gosh, I don't really know which to advise right now. I expect
both will work fine soon, but for now the "new" LCD requires some
additional work before we can use it. But the newer one might look
better??? Or at least it looks bluer!
:-) :-) :-)
CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
Jun 6, 2005
I have uploaded mailbug Version 0.0.3, and it
works with the new LCD in the latest models.
I have not tried it on the older models, but
I expect it works with them too. I actually have
only installed the current "sboot.rom" on one
unit, a "new" 120 with ver 4.05e firmware.
If anyone installs it, please post to list
what model/firmware version of mailstation, and
if there was any problem (I don't expect any).
I still have not seen the code inside of the 200 or 250,
but I am going on the assumption that it is similar enough
that sboot.rom will work with them, but you never know.
I would suggest that if wrecking a mailstation
would ruin your whole day (or make you want to
sue someone), that you probably should not be
flashing *anything* into it.
I am uploading as separate files this time, mainly
so I can upload the part that is ready, and the
rest later.
I have a draft of a user manual almost ready, but I
haven't uploaded it yet.
From: "kat_skan" <kat_skan@...>
Jun 7, 2005
look
Well, I've got another 120/4.05e that's now displaying "Welcome to
Mbug!" and cheerfully ignoring the power button, so I guess I can
report it works on the platform you already know it works on. Seems
like Mailbug has a tendency to just lock up whenever anything unusual
happens, though. The first time I tried reading the SN I had the lpt
port disabled in the BIOS, and Mailbug hung with a timeout error.
Second time was actually after it finished sboot.rom. That locked it
with no message of any kind.
Now I just need to figure out how to get my own code on the thing. If
I understand things correctly, I need to:
* Create a new project by copying the mbug directory
* Use as80 to assemble my .rom
* Set the (w)orkfile and (l)oad it into RAM
* (g)oto the address where I loaded the .rom
Am I missing anything? And would you mind pointing out any good things
to avoid doing while I figure out how everything works?
This looks like it'll be fun. Thanks for getting this working with the
newer firmware.
From: "Cyrano Jones" <cyranojones_lalp@...>
Jun 7, 2005
Great!
I'd actually be happy to hear from anyone who uses it,
whichever mailstation they are using, known to work already, or not.
Speaking of having the port enabled, I tried (under win 98)
disabling the win 98 LPT1 driver, thinking the direct port
access might conflict. It didn't work at all. Apparently
win 98 is trapping the port writes, and using it's driver
to do the actual i/o. You need the driver in win 98 too
(but only if you are running under win98, of course. Driver is
probably already enabled if you have a parallel port.)
There are a number of things that will get you caught in
timeout hell. This is an area that I know needs work.
I am aware that new users will probably stumble into it,
where I manage too avoid it, just because I know these
roads a little better.
A real old joke comes to mind,
patient: "Doctor, it hurts when I do *this*"
doctor: "don't do *that*!"
(that'll be a $100)
I don't know if I can detect that the port is not enabled,
but I will take a look at what happens after writing sboot.rom,
and see if I can see the hangup. I know that in the very first
version of sboot, there definitely was a problem there, but I
thought it was fixed. But, I have only gone through the
whole procedure once with current sboot.
It probably is a good idea to use the "reboot" command
(3 on pc keyboard) after writing sboot.rom (after leaving
the "update mode"). Which brings up a question, do you
remember if you ever got a prompt back after sboot was
done flashing?
Also, do you remember if the mail LED on mailstation
was lit after flashing sboot? The mail LED will be lit
whenever sboot is waiting for a command, and off after
sboot exec's mbug.
The problem might be that the flash code is waiting
for the *mailstation* code to reboot (and we erased it,
and sboot is what we should look for after the flash).
I probably should change it so you are bounced out of the
update mode automatically after flashing sboot, because
*nothing* in the update mode menu will work after you've
erased the original mailstaion code.
After sboot is flashed, the bootup sequence should go
like this:
1)After any reboot (pc keybd, ms reset button, or jp #0000)
sboot waits for a command, with LED on.
Then, if you give mailbug a command that requires mbug be
running, mailbug will load mbug into ms RAM, and then
execute it. (keyboard command "4" will explicitly load mbug).
This is accomplished with a sequence of commands to sboot:
2)Mailbug issues a "load" command to sboot, which sboot
executes, with LED off.
3)After receiving the first block of mbug code, and writing
it to ms RAM, sboot waits for another command with LED on.
4)Mailbug issues another "load" command to sboot, which sboot
executes, with LED off. For no real good reason, the load
is done 1024 bytes per command, so it takes two loads to
send the entire mbug.
5)After receiving the second block of mbug code, and
writing it to ms RAM, sboot waits for another command
with LED on.
6)Mailbug issues an "exec" command, which sboot executes,
with LED off.
7)Previous command put mbug in control, so LED stays off.
From sboot's perspective, command never finished, but
that's ok, mailbug expects mbug to be in control now.
Any further commands will be handled by mbug.
The three commands happen so fast you will not see the
LED flicker, it looks like LED just turns off.
You can think of the LED as saying "welcome to sboot",
as opposed to mbug's "welcome to mbug" message that is
displayed on the LCD.
Sboot only knows how to "load" and "exec".
Mbug not only knows "load" & "exec", but also "unload",
"iopoke", "iopeek", and a few more (like the breakpoint
commands that will work again one day, I promise).
This is an area open to personal tastes. You can
put your files anywhere you want. The "project"
directory sets the default path, and also sets
where the disassembler will look for comment files,
and where dump files will be written. You can put
all your programs in one project if you want, and
you can even put them in the same project as your
firmware files (assuming you even have the firmware
files).
You don't *need* any of the files from mbug directory in
your project dir, but you might want to copy the
assembler there, just so it's easy to find. I really
hate ever setting something like that in the "path"
environment variable. So I either copy as80 to the
project dir, or use the path in any command invoking it.
That's right.
4000 would be a good place to org your asm files.
Then, assuming slot4000 was holding the RAM page you want,
(I suggest ram pg #01,) l4000 followed by g4000.
Ram pg #01 will be in slot4000 when mbug starts.
If you don't do anything that changes it, you can use
"4000" as the address. If you are not sure what is in
slot4000, then use "1014000" (shorter way of saying "0101:4000")
Hmmmm....
Erasing the bootcode would be something to avoid. :-)
Other than that, nothing comes to mind. Any questions
are welcomed.
More fun than a barrel of rubik cubes!!!
From: "kat_skan" <kat_skan@...>
Jun 7, 2005
lpt
it
It's DOS, but there were two different mechanisms to disable the
parallel port in the BIOS. One's a hardware setting, and the other a
security option. I had the latter set for a while and didn't notice.
I wonder if in that case the lpt port looks like it's there and is
just inaccessable. Tonight I'll see if I get different results if the
hardware itself is disabled.
Actually, I tried this specificly because the manual said it wouldn't
work. I figured reading the serial number would be a reasonably safe
way to determine mailbug's failure mode.
Would it be any easier to just make the procedure more feedbackey? I
couldn't really tell whether mailbug was actually hung, or stuck in a
loop waiting for something that would never happen, or just on the
fourth of five attempts of an operation with a fairly long timeout.
When it finished writing it stayed in update mode, so I tried reading
the SN again and had to reboot. I pulled the power to the mailstation
at the same time, but in retrospect I should have tried communicating
with it once mailbug was back up to see whether the software got into
an unworkable state there, or if the problem was contained to the PC.
It looked like the mailstation did reboot after the update. The
display went blank, at any rate. I'm pretty sure the mail LED lit up,
but I can't remember now whether that was after the update or after I
power-cycled.
It also might be helpful to automatically do something benign that
would demonstrate that mailbug is still able to communicate with the
mailstation now that sboot's in control. After the mailstation
reboots, could mailbug (v)erify sboot automatically?
I assume I'll at least need mbug.rom if I want to use anything that
requires it to be loaded. Or will mailbug find it even if I'm not
using the default project?
From: "kat_skan" <kat_skan@...>
Jun 7, 2005
Okay, here's my initial list of things mailbug doesn't like very much.
On an unflashed Mailstation, get (S)erial number produced the
following error when I had the cable unplugged, when I had the lpt
hardware disabled, and when I had the lpt port locked using the
security features of the BIOS.
sendtribble: timeout waiting for ms to drop busy. (1)
Pressing Esc recovered. Seems I neglected to try that when I was
messing around yesterday.
On the Mailstation that's running sboot, (S) produced a similar error
and the email LED shut off. Esc still recovered, and I could r(3)boot
from the main menu.
sendtribble: timeout waiting for ms to send. (6)
mailstation did not ACK the dataflash command
(S) with mbug loaded was slightly more fun. I got the same error as
when I tried it against sboot, and Esc still recovered, but when I
tried to r(3)boot I got this:
Hmmmm... The mailstation's "busy" signal is stuck high.
That often means the laplink cable is not connected
or that the mailstation is not powered
receivetribble: timeout waiting for ms to strobe. 2 (3)
receivetribble: timeout waiting for ms to strobe. 3 (3)
getack2 sees the bail flag, and exits(false) while waiting for: $
*** Soft reset failed ***
Hit mailstation reset button now. (or hit key to skip)
Power-cycling the mailstation and lo(4)ding mbug recovered.
I'll let you know if I manage to break it in a more interesting way.
From: "Cyrano Jones" <cyranojones_lalp@...>
Jun 8, 2005
I guess the manual was right! :-)
The reason it doesn't work, is that mailbug's serial number read
function is interacting with the stock mailstation's serial
number read function. After you reflash, it is no longer
a mailstation. Some of the low level mailstation code is still
there, even the code that does the serial number read is still
there. But it is no longer active, because the event loop that
waits for the update commands is *gone*.
I'll see what I can do to make it more obvious what's happening.
Most of the time, mailbug will timeout anytime it waits
more than about a second. And any timeout will display
an error message. There are a few cases where
it is normal to wait more than a second, and if it is
waiting one of those places, it could look hung.
(Waiting for a command to complete in "update mode" is
one of those places.)
I think that all of those "long waits" can be aborted by just
hitting <esc> key. But, you don't get a message to that effect,
something I need to fix.
Ok, I just tried it. There is a message on the screen:
These functions require the original mailstation code be running,
and a parallel laplink cable between the pc and the mailstation.
This likely will not work anymore after you reflash, since
the original mailstation code is erased when reflashing.
but maybe it has scrolled off the top after you reflash?
Just for kicks, I ignored message, and hit <s> (serial
num read). The program will wait forever for the sn
read to finish. <esc> key aborts it ok, and then I
hit <q> to leave the update mode.
Back in normal mode, I had to <3> (reboot), because
sending the <s> (sn read cmnd) to sboot left it in
the middle of receiving a command. The shortest
command sboot takes is 3 bytes, and the sn read only
sends 1 byte before it waits for a response.
I looked at the mailbug code, and for some reason I had
used the "read with no timeout" function when asking
the mailstation to enter the dataflash mode, in addition
to the wait after reboot. I changed the wait on entering
dataflash mode it to "read with timeout", and now trying
to read sn on a mailstation with sboot gives 3 timeout errors
(takes 3 seconds) and then you get the prompt back.
I hope there was not a reason it was that way, that I
just don't remember. It seems to work better now, so
I will leave it changed. (I wrote the dataflash code
over a year ago now, before I even started the codeflash
routines.)
That's a real good idea. Thanks!
And I suppose it may be good to verify on entry
that the mailstation responds to the "update commands",
so we know there it is not already reflashed.
Right, mailbug will find it, regardless of project dir.
I have been in habit of using <3> <4> sequence (from the main mode)
to verify communication with mbug. Actually just <4> will verify
mbug is still there. The <3> will put you back to boot code
(either sboot or mboot) and force mbug to reload. But it
happens so fast, I usually just do both <3> <4>.