Subject: mbug

From: "John R. Hogerhuis" <jhoger@...>
Date: Mon, 21 Mar 2005 15:51:31 -0800

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).

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Tue, 22 Mar 2005 03:13:00 -0000

> I got source for mailbug some time back, and I've built it for  
Linux.

Great!  How did you handle the port permission issue???

> Do I have to put the MS into a special mode before 
> running the flash burn software?

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@...>
Date: Mon, 21 Mar 2005 21:58:23 -0800

> Great!  How did you handle the port permission issue???

uses oldlinux;

iopl(3);
ioperm (888,2,1);

> sn on pc screen, and then the ms reboots when

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

> Maybe there exists a need for some documentation???   ;^)

Uh, well that would help. Also if you have any debugging ideas, that
would be cool.

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Tue, 22 Mar 2005 06:59:28 -0000

> > > No luck burning mbug into the flash though.

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!!!!

> > No, just turn it on.  
[snip]
 
> 4) There's something broken about my serial port

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).

> Uh, well that would help. Also if you have any debugging ideas, that

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@...>
Date: Tue, 22 Mar 2005 07:32:10 -0000

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@...>
Date: Mon, 21 Mar 2005 23:56:26 -0800

> And it should work.  But I found this in the oldlinux

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.

> writeln('Hot dang!  We got it!!!');

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.

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Thu, 24 Mar 2005 07:53:28 -0000

Any luck yet? 

> 4) There's something broken about my serial port

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@...>
Date: Thu, 24 Mar 2005 02:26:09 -0800

> Any luck yet? 

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.

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Thu, 24 Mar 2005 20:54:21 -0000

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 did buzz out my laplink cable; does this look correct/sufficient?:

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)
 
> 1-1     *
> 12-5    should be 12-4
> 14-14   *
> 15-NC   should be 15-2
> 16-16   *
> 17-17   *

> 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

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 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.

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@...>
Date: Fri, 25 Mar 2005 01:36:49 -0800

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.

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Fri, 25 Mar 2005 12:18:53 -0000

> I rebuilt my laptop with win98 and am using your current released binary

Is this the same machine you were trying the Linux version on?

> I get "Mailstation did not ACK the dataflash command"

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).

> Can't enter codeflash mode.

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.

> failed update attempt. The unit still works fine.

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@...>
Date: Fri, 25 Mar 2005 12:02:02 -0800

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

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.

> Is this the same machine you were trying the Linux version on?
No. This is my athlon 1.3Ghz (I think) laptop.

> your cable pinout.  Maybe your cable *is* bad!!!

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...

-- John.

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Fri, 25 Mar 2005 13:57:21 -0800

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?

-- John.

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Fri, 25 Mar 2005 16:27:56 -0800

> a shot, or do you have some ideas for an image that is more likely to

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.

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sat, 26 Mar 2005 03:44:58 -0000

> Never mind; I just went for it, and mailbug seems to be running now

Great!!!  :-)   :-)   :-)

> for it? I was thinking about compiling some C code with sdcc and 
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@...>
Date: Fri, 25 Mar 2005 20:53:19 -0800

> > Never mind; I just went for it, and mailbug seems to be running now

Thanks for your help debugging my setup :-)

> I'd really like to fix that too, and then post a new

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.

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Tue, 29 Mar 2005 01:08:18 -0000

--- In [email-masked], "John R. Hogerhuis" <jhoger@p...> 
 wrote:
[...]
> > > Never mind; I just went for it, and mailbug seems to 
> > > be running now quite happily.
> > 
> > Great!!!  :-)   :-)   :-)
> 

You're welcome!  Glad I could help!!!  :-)

[....]
> >      I also discovered that the write to flash
[....]

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.

> least we all have a way to load code!

:-)

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 will let you know if I get the linux version working, 

I have a hunch you were closer than you realized!!!    ;^)

> maybe we can  get
[.....]

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@...>
Date: Thu, 31 Mar 2005 00:40:52 -0800

> access any other location till it's done!

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.

> from the rom.  (I have a halfway-decent scrolling text

Cool!

> the actual flash code into mbug.

I agree.

[...]

> what most of the low level mailstation code is.  

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.

> use a c "header file" for???

Yes, a header file and possibly a C wrapper library to go with it,
depending on the calling conventions of the low level routines.

-- John.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Fri, 01 Apr 2005 07:48:04 -0000

[....]
> guess they aren't that sophisticated.

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 have a halfway-decent scrolling text screen now!)
> 
> Cool!

I uploaded my test program here:
http://groups.yahoo.com/group/mailstation/files/Mailbug/scancode/

It reads the keyboard, and displays the key scancode on the LCD.

> > the actual flash code into mbug.

That I'm lazy, or about the right way to do it???  :-)  :-)  :-)
<LMAO>

[...]

--
CJ

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Fri, 08 Apr 2005 11:30:44 -0000

wrote:
> > 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?
> 
> Never mind; I just went for it, and mailbug seems to be running 
> now quite happily.

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@...>
Date: Fri, 08 Apr 2005 19:00:31 -0700

On Fri, 2005-04-08 at 11:30 +0000, Cyrano Jones wrote:

> success with 3.03a, but maybe I will have to get back to it.

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.

-- John.

---

From: "Neil Morrison" <neilsmorr@...>
Date: Fri, 8 Apr 2005 19:15:43 -0700

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

> they can talk. Just need to remove the debugger's dependency on the boot

I gather there's no code in the ROM to dump the ROM out?

Neil

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Sat, 09 Apr 2005 11:06:20 -0000

> Hmm... what version is in the 150? Mine is something like 4.x.

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.

> 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.

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@...>
Date: Sat, 09 Apr 2005 11:19:45 -0000

--- In [email-masked], "Neil Morrison" <neilsmorr@h...> 

> I gather there's no code in the ROM to dump the ROM out?

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@...>
Date: Sat, 09 Apr 2005 11:18:01 -0700

> the debugger that runs on the PC at the other end of the laplink.)

OK, I'll try to use those names.

> to be able to make changes, too.

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.

> But eventually it would be nice to be able to run without the 

Yes a a simple standalone debugger would be nice. Another possibility is
to integrate this Forth interpreter: 

http://www.zetetics.com/camel/

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.

> stage, which would be in a higher page that was eraseable separately

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.

> and instead let you load mbug into ram, so you could fix the second 

Yep. With the addition that we should probably checksum the second
stage.

-- John.