From: Brad Fayette <bfayette@...>
Mar 19, 2005
I should have figured that out about the power. I guess there is some
work left to do :-)
I am running it on a Toshiba T4700CS laptop, 50mhz 486, Win 95. Runs
fine in a dos window.
I am seeing comments when I disassemble. I assume the code is coming
out of the mailstation, and the comments out of a file. I guess this is
something to be aware of in case you change something.
Do you have any advice on how not to trash the mailstation when
writing/loading/running applications?
Does the mailstion 250 have a Z80? I have a 350, but it has some
toshiba 16 bit processor, so I'm getting rid of it. The interesting
thing is that for wireless devices, the FCC has tons of stuff online,
like schematics. All you need is the FCC Id. Maybe some of it for the
250 would apply to other devices as well.
CJ, where are you located? I'm in North Carolina, USA.
Regards,
Brad Fayette
"The geeks shall inherit the Earth."
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 20, 2005
wrote:
It won't be hard to get it to shut off, I just
haven't tried. Actually, I don't think it ever
really shuts itself off in "normal" use, I think
it just "goes to sleep".
Try "G 1AC0"
That will execute what I believe the ms does
when it "turns off". My screen went blank when
I tried it! I thought I would have to power cycle
or reset to get it back, but the power button
wakes it up!!!
I actually leave mine on most of the time, running
with the wall-wart. (And that has been how I
killed 3 of the 4.) If you are using batteries, I
guess you need to take them out to get it
completely off.
That's cool. I hadn't even thought about that end
of the spectrum. :-) How much ram is in it?
The debugger allocates over 3 meg of buffers,
and it probably should run with a disk cache
(win 95 provides one, right???) because the comment
files are not buffered inside of the program
(and it reads them from the beggining every
time screen scrolls.)
Right. If you installed the v2.53 files, and converted
to .rom files, then you can use the "ram" target, and
browse the disassembly/comments, and the code
will be read from pc ram, and it is noticeably
faster. I started to add the concept of "projects"
so you could have different versions use different
comment files, but that is not done yet.
I'm just distributing the comment files, without
the disassembly, because I don't want to
worry about any copyright issues.
If you use command ^h it will render the disassembly
and comments to a hyperlinked .html files. I don't
know how long it will take at 50 MHz to do pages
00 thru 3f, but you can tell it to do just page 00.
(I recommend using ram target for this. But it
should work from mbug, just slower.)
The first one I trashed was due to me asking the
debugger to erase a page that held part of the
then-current bootup code. The only way to avoid
that is to be careful. :-) :-)
The second and third were due to changes I
made to keep the mailstation from getting locked up
when rebooting the PC. Previously it had
been thru countless reboots, with the
only ill effect being that it was unresponsive to
commands, and required a hard reset.
I was getting tired of having to
poke a pencil in the reset hole. I
figured what was happening was that
either windows or the PC firmware was
"printing" some garbage to the parallel port
during boot up (you know how a printer will
sometimes print garbage when a PC is booting.)
So, I added some error detection, making
the remote code restart whenever it got
a command that didn't make sense. All I
can figure is that what happened is that
I gave the gibberish a fresh shot from
the start everytime it sent nonsense,
making it much more likely to hit on the
command "erase page 00" eventually.
The first time it happened I really didn't
know what had happened. I grabbed a
new mailstation, and installed the very same
version of mboot. Within a week that one
was toast, too. I figured it must have something
to do with the most recent changes. So
I decided I should fix it before wrecking
another mailsation. In the meantime, I
was fiddling with a stock mailstation
(without my code) trying to read the serial
number thru the laplink (that works!).
But I left the thing connected (and powered)
when I was done. Several days went by,
with several pc reboots, and then one day
I noticed that this *stock* mailstation
had apparently gotten erased. Live and learn.
I now *unplug* the laplink when I quit
the debugger (It now displays a
reminder when quitting!)
I actually thought I had fixed it
so this couldn't happen, but as I
look at the code now, it appears that
the reminder is how I fixed it.
If only I had the time to do everything I
want to...
But I havent had any problem since
December. The next version should
have a better safeguard.
There really is no way to prevent
a haywire program from finding the reflash
code, other than removing it completely.
I mean, even if you thought you had
a secure lockout, what if the program
running amok jumps in right after the lock?
But I don't think we really need to worry
about that. Just unplug the laplink when
you are done, for now! And brown
mailstations are real cheap on ebay. :-)
Yes. It's essentially the same as the
brown/white/100's. Except for the
modem, and the radio circuitry. And
keyboard. And callerid chip. But the
cpu/ram/codeflash/dataflash are the same.
I'll bet you can get over $100 for it on
ebay. I've seen several sell in the $130 range.
The 350 appears to use some other
protocol (if any) for it's update function.
Yes! Where is the search page? I saw the link
on linux hacker for the 350 data. But I can't
find a search page that will return that page.
Is there any reason we shouldn't look at this,
like with the patent info?
We already have most of the port/pinout/address info
courtesy of rogblake, and one friendly panther
(who I understand almost went blind tracing the circuit).
I'm in the Detroi..... Uh, I mean I'm in my ship, hovering
500 miles over the Detroit area, safely out of reach of
any Earth regulations such as DMCA (or even YMCA!)
Don't let my ip address fool you, I'm attached to
some earthlings open wi-fi link. Yeah, that's it.
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 21, 2005
I got source for mailbug some time back, and I've built it for Linux.
No luck burning mbug into the flash though.
Do I have to put the MS into a special mode before running the flash
burn software?
Fn-Shift-T gets me to a diagnostics menu, but there is no entry there
regarding flash programming (just various tests).
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 21, 2005
Linux.
Great! How did you handle the port permission issue???
No, just turn it on. As far as I can tell, the ms can
be on any screen when you kick it into the update mode.
You do not need to touch the mailstation (other than
to turn it on, and connect the laplink).
The PC will make the ms enter/leave update mode
via the laplink. The only commands you need to
type are on the PC keyboard.
When the update is done, the ms reboots to the
main menu, unless you erased the ms code.
Make sure you can read out the serial number
before you try to flash. That will tell you if
you are sending and receiving ok. Each time
you read sn, it will enter update mode, display
sn on pc screen, and then the ms reboots when
the update mode exits.
Maybe there exists a need for some documentation??? ;^)
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 22, 2005
On Tue, 2005-03-22 at 03:13 +0000, Cyrano Jones wrote:
uses oldlinux;
iopl(3);
ioperm (888,2,1);
Crap... I was afraid of that... that means one of the following:
1) laplink cable problem (I bought a manufactured cable) or
2) Timing issue or
3) The bytes aren't really making it out the port or
4) There's something broken about my serial port
Uh, well that would help. Also if you have any debugging ideas, that
would be cool.
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 22, 2005
I don't think you need the iopl(3),
just the ioperm(888,2,1). 888 is the decimal address of lpt1,
the 2 means 2 consecutive ports, and I believe 888 & 889
are all I used. And the one means "grant access", right???
And I think you have to be root to do the ioperm.
Are you USEing the plain "linux" unit (I think that is the name)???
None of the examples I see mention the "oldlinux",
and I think ioperm is in "linux". Maybe it just a newer
version than in "oldlinux". What's the scoop on why
oldlinux is necessary???
As far as I can tell, after the ioperm, you can use the ports
unit, and that's what unit_tribbles uses for port access.
Do you know for sure what the port address is for your
parallel port???? 888 is the most common, but there
are others. I think we have another candidate for the config
file!!!!
[snip]
Can you test the port with some other software? (And
a printer).
Are you sure it is Parallel Laplink and not serial???
They make both!
What do you get on your screen??? Any timeout errors?
You could try making a simple test program that
toggles the dataport pins, and check with logic
probe (or LED port tester thingy), and see if
that works (eliminates cable and mailstation from
the equation).
But the first thing I would try is skipping oldlinux & the iopl(3).
I think we are figuring out the docs as we go!!! We
can compile the questions, or at least answers into
some kind of manual.
CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 22, 2005
OK. I see what the oldlinux is about. They did away
with the linux unit. And replaced it with a handful of
other units. I found the new ioperm in unit "X86".
But apparently "oldlinux" *IS* the "linux" unit, renamed.
And it should work. But I found this in the oldlinux
manual:
IoPL
Set I/O privilege level
Declaration
Source position: linuxold.inc line 1558
function IoPL(
Level: LongInt
):Boolean;
Description
IoPL sets the I/O privilige level. It is intended for completeness
only, one should normally not use it.
How do you call ioperm??? Does it return error???
It should return "true" if it worked, and "false"
if it failed. Do you check it???
writeln('gonna ask for ioperm...');
if not (ioperm(888, 3, 1)) then
begin
writeln('didn''t get it. damn. gonna halt now.');
Halt(1);
end;
writeln('Hot dang! We got it!!!');
delay(1000);
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 22, 2005
On Tue, 2005-03-22 at 07:32 +0000, Cyrano Jones wrote:
It didn't work until I put the iopl in. I didn't think I needed it
either, but I was getting access violations until I put it in.
Yeah I was ignoring the return code. Your way is better in case someone
decides to run it and they aren't root you can give them an error
message.
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 24, 2005
Any luck yet?
You meant parallel, right??? :-)
It just occured to me that the port tester I used was
for rs232. All 25 pins go straight thru, and the 9
lines used by rs232 have leds.
7 of the 10 laplink signals fall on a line with led,
and the 5 laplink-out bits are on the first 5 leds.
I eventually modified it so all 10 laplink signals
were monitored with a led, but it was extremely
useful even before mod.
The PC will use pins 2, 3, 4, 5, 6 to talk *to* the
mailstation. 2, 3, 4 are the 3 bit tribble, 5 is busy,
and 6 is strobe to mailstation. pin 5 ("busy") will go
high when the pc is talking to mailstation.
The mailstation talks back to PC using pins
15, 13, 12, 10, 11. 10 is ms busy, 11 is strobe
to PC.
Both sides raise busy when they want to talk, and
both sides also raise busy briefly to acknowledge
they have been strobed.
You mentioned you had a rs232 tester, right? It
will tell you if your bits are getting out of the box,
as long as it has leds for pins 5 & 6.
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 24, 2005
On Thu, 2005-03-24 at 07:53 +0000, Cyrano Jones wrote:
Nope.
I did buzz out my laplink cable; does this look correct/sufficient?:
1-1
2-15
3-13
4-12
5-10
6-11
8-NC
9-NC
10-5
11-6
12-5
13-3
14-14
15-NC
16-16
17-17
18-NC
19-NC
20-NC
21-NC
22-NC
24-NC
24-NC
25-25
My serial mini-tester when hooked in doesn't show any activity. but it
is only wired to show CD, DSR, RTS, TD, DTR, CTS, RD
I tried just probing with a multi-meter... what should I should I hold
the ground (black) probe to? I've just been touching it against the
outer part of the connector.
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 24, 2005
OOPS! I was wrong when I said it worked unmodified.
Your question about ground made me wonder what my tester
was using for it's ground reference, since rs232 ground
is pin 7, and pin 7 is not ground on the parport.
I forgot about another little change I had made, before
it worked at all.
The common of the resistor pak in my rs232 tester was
originally tied to pin 7 of the db25 (rs232 signal ground).
I cut the trace between that common resistor pin and
db25 pin 7 (it is connected to pin 7 of both db25's,
so if you do this, make sure you cut it loose from both).
Then I added a piece of kynar from that common resistor
pin to one of the db 25 pins that is ground on the
parallel port (I used pin 24, but pins 18 thru 25 are
all ground on the PC parport.)
I made some annotations on your pinout, below.
Recheck those two, maybe its OK.
My cable does not have the * connections, but
several pinouts found on the 'net do. I thought
it odd that the pin 1's would be connected straight
thru, since pin 1 is an output on both sides.
It turns out that those 4 pins are the control
port (outputs). I understand that they are
open collector, so tying together is ok, and
you can read as an input as long as you set
the coresponding out bit high.
(Mailstation doesn't use them)
Here is how the laplink maps to a serial tester
(need to make the ground mod to tester).
At the PC end, the outputs to mailstation are:
data 0 = pin 2 = TD
data 1 = pin 3 = RD
data 2 = pin 4 = RTS
busy = pin 5 = CTS
strobe = pin 6 = DSR
The inputs do not fall on either of the other two LEDs.
pin 8 = CD
pin 20 = DTR
I don't know if the shell of the connector is connected
to the signal ground??? Likely is, but I am not sure.
Pins 18 thru 25 are all signal ground though, so I would
put black on one of them.
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 25, 2005
Well I've made a temporary retreat. Dealing with Linux and an unmodified
mailstation is adding to many variables at once.
I rebuilt my laptop with win98 and am using your current released binary
from albatross.zip.
So I run mailbug, enter u, then S
I get "Mailstation did not ACK the dataflash command"
So I was very brave and typed
^f
This does something!
"The software update process is ready to start, please wait"
appears on the mailstation screen, then immediately afterward it changes
to "Please check that the mailstation cable is properly connected and
try again."
On the laptop DOS box I see
Here we go....
No codeflash command ACK, moderesult: 79
Can't enter codeflash mode.
The firmware revision on this unit is V3.03a. Nothing got hosed by the
failed update attempt. The unit still works fine.
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 25, 2005
Is this the same machine you were trying the Linux version on?
If you type Ctrl-t (toggles debug mode) you will get more
verbose info from most commands. Here you would get
the value of whatever the pc receives as acknowledge
to the "enter dataflash mode" command. The two
values the ms might send are either #06 (ascii ACK),
or #15 (ascii NAK).
For codeflash mode, it displays the byte it receives in response
to the command without "debug on", but it is in decimal here.
Just one of many rough edges left to be smoothed.
79 = #4F = x01 001 111 is what you got,
when we are expecting either
ACK = #06 = x00 000 110 or
NAK = #15 = x00 010 101
where the x represents the unused bit of the third tribble.
(bytes are sent as three groups of three bits.)
Maybe it is a problem with the settling time on the port bits???
Your cpu could be fast enough to read the port before they
have had time to stabilize???? OR! It could be that your
low order bit of the three data bits is pegged high?????
ACK is x00 000 110 and if you set the lowest bit of each
tribble high you get x01 001 111 = #4F = 79 dec.
This will be easy enough to check. Maybe I should add a
loopback test??? Then you could make up a plug to feed
the outs back into the ins on the parallel port.
That way we can be sure we're talking to the port, without
the mailstation (or cable) in the loop.
I would not try to flash anything until I could read the
serial number out reliably. The SN command requires
sending 12 bytes in (with checksum) and receiving
18 bytes back. With no danger if it fails.
Erasing the codeflash takes just two bytes in.
Also, until we see the code in 3.03a, we don't know if
we are putting mboot in a location where it will be called
for sure. I had an idea to create an image that fills
every high page with nops, and a jump to mboot at the
end. That way, wherever it jumps/calls will run mboot.
HEY!!! I just looked up the pin for your stuck bit, and it
is 15, and that is one of the two that were wrong in
your cable pinout. Maybe your cable *is* bad!!!
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 25, 2005
WIth Ctrl-T, and S (serial number) request I get
Entering Dataflash mode...
dataflash mode ack: 4F
Mailstation did not ACK the dataflash command
With ^f I get:
Here we go........
codeflash mode ack: 4F
No codeflash command ACK, moderesult: 79
Can't enter codeflash mode.
Interestingly, if the mailstation is in this state "please check that
the parallel cable..."
And I do ^f again, I get
Here we go........
codeflash mode ack: 5D
No codeflash command ACK, moderesult: 93
Can't enter codeflash mode.
On Fri, 2005-03-25 at 12:18 +0000, Cyrano Jones wrote:
No. This is my athlon 1.3Ghz (I think) laptop.
Crap, I think you're right... one way it's 15-2, the other way it's
15-NC. Of course that would mean that behavior should be different
connected the other way. Have to try that...
Anyway I guess I'll build a damn cable. That's what I get for buying
this 4 months ago and not doing anything with it...
From: "John R. Hogerhuis" <jhoger@...>
Mar 25, 2005
OK, better now.
With Win98, I can now get the serial # from the unit. I bought a new
laplink cable from Fry's, and this one doesn't have a dead 15-2
connection so it works :-)
As to Linux, I haven't tried it yet, but I have some theories: one, I
don't know why I didn't think of this, but maybe the print server (lpd)
is holding onto the port in some way. Which would cause some kind of
problem. The deal is that I am able to share the printer port with my
Rio PMP300 player, so I guess I didn't think about possible consequences
of reusing the port.
Alternatively, maybe I am writing to the port, but perhaps it is in some
non standard mode, like epp mode? Does unit_tribble set the mode of the
port?
Now, I haven't tried the reflash command. 3.03a... not as brave now that
I know I'm actually communicating... do you think I should just give it
a shot, or do you have some ideas for an image that is more likely to
work?
From: "John R. Hogerhuis" <jhoger@...>
Mar 25, 2005
On Fri, 2005-03-25 at 13:57 -0800, John R. Hogerhuis wrote:
Never mind; I just went for it, and mailbug seems to be running now
quite happily.
Now what can I put on it... have as anyone tried compiling any programs
for it? I was thinking about compiling some C code with sdcc and trying
to run it on there.
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 25, 2005
Great!!! :-) :-) :-)
programs
trying
So far, I have only used assembler, and not much more
than the "hello world" (hello.asm & hello.hex)
W hello.hex
L 4000
G 4000
The source (and an assembler) is in the mbug directory.
The mbug/mboot source is there, too. I think I even
zipped up the .bat file to build them. The bat files
need the dir set, I do that by just making "shortcuts"
to the bat files (set properties to "close on exit").
If you put the .hex or .rom files in the 253yr dir, you
can load them without typing a path. The bat files
output the .hex or .rom's to 253yr, and .lst to mbug dir.
I have started on a "next version" of mboot, but I am
finding a few bugs in mailbug. Load didn't work right
always. If you try to load a .rom over 256 bytes, it
puts the bytes past 256 into the next page!!! I got that
fixed in mine. I also discovered that the write to flash
(Z) is broke. I am still trying to get to the bottom of it.
There has been a lot of change in the code since the last
time I used Z command, so I am not sure how I broke it.
I'd really like to fix that too, and then post a new
mailbug.
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 25, 2005
On Sat, 2005-03-26 at 03:44 +0000, Cyrano Jones wrote:
Thanks for your help debugging my setup :-)
It looks like you've put together an excellent programmer's tool! I look
forward to whatever improvements you can provide. For now though at
least we all have a way to load code!
I will let you know if I get the linux version working, maybe we can get
some more people hacking on the MS if we get a stable set of tools for
target development under Linux. From my end, I'd also like to get a
"device" target (basically a C standard library) developed under sdcc.
Sdcc can already generate Z80 code, but there of course is no MS target
yet.
Maybe in a few months we'll be able to completely replace the MS
hardware access routines with our own.
From: "Cyrano Jones" <cyranojones_lalp@...>
Mar 28, 2005
wrote:
[...]
You're welcome! Glad I could help!!! :-)
[....]
[....]
I have it figured out now.... Apparently you can't use code
in one part of the flash to write to another part. I thought
as long as it was in a different sector it would be ok. In
retrospect, it seems kinda dumb to even try it. I think
the flash chip may be busy running it's internal programming
algorithm, and all you are supposed to do is try to read back
the byte you are attempting to flash. You probably cannot
access any other location till it's done!
In the earliest versions, I just copied the rom to ram,
like the ms does, and then I called the sector write
from mbug.
While experimenting with writing text to the LCD, I had
mbug map the update code directly into Slot8000 (the only
fonts left after reflash are in that update code).
The LCD routines worked fine that way, running directly
from the rom. (I have a halfway-decent scrolling text
screen, now!)
It only seemed natural to just use the sector write the
same way...
I was lazy, and didn't want to rewrite what seemed good
enough. I think the right way to do it now is just add
the actual flash code into mbug.
look
:-)
I may have something better in a few days, but for now, if anyone is
tying to use it, as far a I can tell the hex file load is working ok
in the old version (what number did I post, 0.0.1 or 0.0.2 ????).
You can assemble a file (orged #4000) to a .hex file, load it
at #4000, (L 4000) and then execute it with the go command
(G 4000).
I have a hunch you were closer than you realized!!! ;^)
for
sdcc.
target
[.....]
I am looking forward to seeing what other people might be able
to get going. As far as the C standard library, I think that is
what most of the low level mailstation code is.
I have done some experiments where I have made calls to
several of the low level routines. I've been imagining making
an include-file for the assembler, with the EQU's for the
usefull addresses. Is this the kind of thing you would
use a c "header file" for???
CJ
From: "John R. Hogerhuis" <jhoger@...>
Mar 31, 2005
On Tue, 2005-03-29 at 01:08 +0000, Cyrano Jones wrote:
Interesting. I guess I never realized that about industrial flash
chips... now that I think about it, the only time I've ever written to
it was while running from RAM. So I'd say this behavior kind of stinks,
but I don't doubt it to be the case. Certainly you would think that
other sectors would be unaffected by a write to another sector, but I
guess they aren't that sophisticated.
Cool!
I agree.
[...]
Yes, I agree. But it will be nice to have a complete independent set of
firmware, then we will know we have a foundation that can't be changed
under us.
Yes, a header file and possibly a C wrapper library to go with it,
depending on the calling conventions of the low level routines.
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 1, 2005
[....]
to
stinks,
I
The datasheet doesn't directly say that you can't do this,
but it is the only explanation I can think of. The symptom
was that mbug rebooted when I tried either erase or flash
operations. The sector would be erased ok, but when trying
to flash, only one byte would be flashed. Thats consistent
with what I would expect if the cpu lost access to the code
it was running after issuing the erase or byte program commands.
[....]
I uploaded my test program here:
(URL)
It reads the keyboard, and displays the key scancode on the LCD.
That I'm lazy, or about the right way to do it??? :-) :-) :-)
[...]
CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 8, 2005
wrote:
I wasn't as lucky. I went to office max last nite, and grabbed
a few of the $9.00 150's. Just now, my curiosity got the better
of me, and I flashed the 0.0.2 mbug into one of them.
It seems that it flashed it ok, but when it rebooted, I got a
streak of bits written to the lcd (approx the top half inch of
the lcd). That might indicate that the loader ran, and copied
the mboot code to ram (it gets loaded into what normaly is the
lcd buffer). But it is not supposed to write the buffer to the
lcd. And it never turned on the "new mail" LED (one of the first
things mboot does when it starts running after being copied to ram.
Or, it could just be the cpu walking thru the screen ram. The
pattern does not seem to match the mboot code.
I stopped thinking about the idea of a "safer" image after your
success with 3.03a, but maybe I will have to get back to it.
CJ
From: "John R. Hogerhuis" <jhoger@...>
Apr 8, 2005
On Fri, 2005-04-08 at 11:30 +0000, Cyrano Jones wrote:
Hmm... what version is in the 150? Mine is something like 4.x.
Anyway, I guess the good news is the reflash code is there, so at least
they can talk. Just need to remove the debugger's dependency on the boot
rom.
From: "Neil Morrison" <neilsmorr@...>
Apr 8, 2005
From: "John R. Hogerhuis" <jhoger@...>
I gather there's no code in the ROM to dump the ROM out?
Neil
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 9, 2005
wrote:
It was 4.somethin D, but it's kind of hard to tell now! :-)
I have another that is 4.05D, so I imagine that first one was, too.
Right, it does seem to use the same reflash protocol.
I have been thinking about just how to organize the next version
of the mbug/mboot code. (mboot is what I have been calling the
code that gets flashed into the ms codeflash, mbug is code that is
loaded into ms RAM via laplink, and mailbug is what I am calling
the debugger that runs on the PC at the other end of the laplink.)
It seems it would be good to minimize the number of times you had
to risk losing access when flashing new code, but it would be nice
to be able to make changes, too.
The old code does this by loading the latest version into ram from
the PC host. (Which also means you need the PC attached whenever
you reboot the mailstation.)
But eventually it would be nice to be able to run without the
PC/laplink.
I am thinking that the next step might be a simple ROM monitor that
would let you run code at arbitrary locations in the codeflash, from
the ms keyboard, as well as connecting to the PC based debugger.
And to allow you to develop new versions of the monitor, and flash
them without the white knuckles, that it would be seperated into
two parts. The first would go in page #00 and remain unchanged
mostly. It would be able to automatically jump into the second
stage, which would be in a higher page that was eraseable separately
from the first stage.
Then, if (or should I say when!) you hosed that second stage with a
careless change, you could hold a key on the ms keyboard while
rebooting it. That would make the first stage skip the auto-jump,
and instead let you load mbug into ram, so you could fix the second
stage with the debugger.
CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 9, 2005
wrote:
That's right. At least a way has not been found yet, without
desoldering the chip, or doing other board surgery.
There is really no reason that the manufacturer would ever
need to dump the rom, so the function is not there.
That makes it more dificult to interface to the existing code, but
not impossible. I expect that before long we will be able to load
and run our own code in all except the 350's. (Not that it would
be impossible, just that as far as I know, nobody is even working
on the 350.)
CJ
From: "John R. Hogerhuis" <jhoger@...>
Apr 9, 2005
On Sat, 2005-04-09 at 11:06 +0000, Cyrano Jones wrote:
OK, I'll try to use those names.
Yeah, most systems I've worked on have a boot sector/loader that almost
never changes. Comes up in bootloader, looks around a flash file system
for the application, loads it to RAM, checksums it, and if its OK, jumps
to it.
You have to add some kind of override... keyboard in our case, that
allows you to erase a bad application, so that you don't get into a bad
situation if the application is 'bad' even though the checksum is ok.
Yes a a simple standalone debugger would be nice. Another possibility is
to integrate this Forth interpreter:
(URL)
Then high level code can be written on the MS itself, a simple Forth
assembler could be integrated, etc.
To adapt a Forth usually all you have to do is adapt KEY and EMIT to the
system so you do I/O. If we want to run the Forth directly from ROM
rather than RAM, we might be able to get some pointers from the Z88
CamelForth project since it can run directly from ROM.
Yeah a simple boot loader that can either find a second stage and
checksum it, or load and checksum an app directly to RAM if the second
stage either doesn't checksum or the user intervenes. I guess MBUG
qualifies as a loadable app, and mboot is the boot loader. Mailbug is
pretty much your typical target debugger. But if we can get Forth loaded
on there as the loaded app, I think it might be cool to develop new code
right on MS.
Yep. With the addition that we should probably checksum the second
stage.