From: "jhogerhuis" <jhoger@...>
Apr 22, 2005
Well as a proof of concept I ported CamelForth to the Tandy WP-2, a
Z80 based word processor, not too different from the MS. I did the
WP-2 since I've been planning it for a while and it has a built in
serial-connected disk driver that I happen to have a good emulator for.
I had to do a few things:
a) Use the Z180 port of CamelForth, since it can compile with the
Zilog assembler/linker. The original Z80 CamelForth is compatible with
some CP/M assembler.
b) Remove hardware specific stuff in the Z180 port. Nothing difficult,
just deleting some things.
c) Create a WP-2 compatible "header" for the file.
d) Implement EMIT, KEY, and KEY? EMIT outputs a character to the
terminal, KEY blocks reading a character from the terminal, and KEY?
just scans for the currently depressed key.
e) Use the HEX2BIN utility of sourceforge to convert Intel hex to binary.
f) Load it up and test my implementations of EMIT, KEY, and KEY?
Anyway, it works! The MS shouldn't be too different, at least if we
are using its routines. But for stand-alone (ie no dependence on Cidco
code) we'd need a little bit more, since we'd be generating characters
ourselves, and we'd have to do all the bootloader stuff. But it might
be easier to experiment with that kind of thing if we just get
CamelForth booting first, then we can play with all the hardware
interactively. I have some ideas for a simple flash file system if we
get tired of loading code at the keyboard or over the parallel port.
CamelForth is about 6K, there are instructions burning it to ROM
available (so it doesn't create any variables in program space). Or we
could just load and run it in RAM for now via MAILBUG.
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 23, 2005
Cool!
[...]
Does the z180 code run on a z80? If it does, what makes it a z180
port?
Just curious.
[...]
Did you use existing terminal routines in the WP-2?
So far, all I have found in ms is the raw scancode key buffer
routines.
Won't be "too hard" (heh, there I go again) to convert to ascii.
On the output side it might be a little more work. I have some
quick and dirty code that writes whole strings to LCD. I used
the existing message display function from the update code.
Its easy to set the line it writes on, but it always wants to write
starting at the left edge of the screen.
Probably the most straight forward way to do a better
terminal would be to restore the font page in codeflash,
and then use the LCD code in page #00 of the codeflash.
But I don't know if there is a "text mode" cursor. Might
have to keep track of that ourselves.
Mailbug can load intel .hex files! :-)
(It's one of the few thing that did work right in version posted.
Is anyone waiting for the fixed version?)
It's always fun when "it works"!!!
[...]
Yeah, it seems like you would need to store your program files
somewhere, even if the forth interpreter is in rom. And a text
editor to write programs, or is that part of forth already?
[...]
CJ
From: "John R. Hogerhuis" <jhoger@...>
Apr 23, 2005
On Sun, 2005-04-24 at 01:28 +0000, Cyrano Jones wrote:
I haven't seen anything special. The only thing about this port that I
needed was that it assembles with the Zilog assembler/linker instead of
some CP/M assembler/linker. Seems to run fine on a regular Z80 chip.
Yes. And of course now I'm finding that the charout is buggy on some
WP-2 ROMs when you get to the screen scroll. So I may have to do it
myself at least for the last character on screen.
Yeah that sounds like not a big deal. Are they even encoded? In the
WP-2, for example, they are two bytes, one that has the ascii code and
the other has bits set for various shift and function keys.
Fixed width fonts aren't hard to make in any event. Better to use
something without the Cidco copyright on it.
At the momemnt cursor doesn't work all that well on WP-2, but I can get
along ok without it. Will add one soon, just not my top priority.
I'd like a new version :-) That's one of the reasons I've been poking
around with WP-2 instead of MS, I know you said there are some bugs in
the released code.
Good point on the editor... then WP-2 is a word processor in ROM so I
get an editor for free. On the MS, once we get Forth loaded there are
lots of block editors around, and I believe there are also full screen
editors. I've seen at least one complete forth word processor source
code, we could use that if can't find something smaller.
In any event we could just redirect I/O to the parallel port and
interact completely over a terminal session. Then to upload code just
use the terminal program. Then we could bootstrap our way to a
filesystem.
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 29, 2005
When I said that last Saturday, I thought it was ready...
Then, before uploading, I thought I might actually test
it! The new flash code was working "pretty good", but
when flashing large blocks, it would sometimes get a
timeout error. This was quite puzzling, because until then,
the laplink code had been working flawlessly.
It took me quite a while to figure out just *what* was happening,
and then even longer to understand *why*. I'm pretty sure I
have it fixed now. I will do some more testing tonight,
and if all goes well, I'll upload it.
(This is just a fix to ver 0.0.2, not the "next version", so
it is still just for the older models.)
CJ
From: "John R. Hogerhuis" <jhoger@...>
Apr 30, 2005
On Fri, 2005-04-29 at 22:23 +0000, Cyrano Jones wrote:
So what are the changes to the new rev? Bugfixes only?
In any event that should allow me to get CamelForth going. Might have to
render characters myself, but that isn't too hard.
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 30, 2005
"load", "save" and "verify" should all work properly now. They
each had the same problem with address calculations. (Apparently,
when I modified them to use 32 bit address, I didn't really test
the change.) Load only loads into RAM, but save should be able to
save the protected pages of the codeflash to disk.
Codeflash erase and write ("erase" & "zap") are working fine
now, too. Writing codeflash is quite a bit slower now, due
to the fact that flash algorithm runs on the PC now, not on
the mailstation. It takes 35 seconds to flash a 16k page,
versus 4.2 seconds with older method. I have another method
in mind that would be much faster. (maybe in future revision???)
After I figured out what was wrong with old method (using code
in same rom you are writing is not allowed), I was gonna add
flash erase and flash write commands into mbug. Then I realized
that the flash algorithm could be implemented on either side of
the laplink cable. So I moved it over to the mailbug side. It
is slower now, because the flash commands have to be sent to the
codeflash for each byte over the laplink.
Most (all???) of the commands now can be cancelled with esc key.
Several minor changes, that I can't think of right now.
There is a new .zip file with (hopefully) all the files
you need. You need at a minimum the new mailbug.exe, and
the matching mbug.rom. They should work fine with the old
mboot.rom if you already flashed it. You should be able to
unzip it on top of the old files. I added scancode.hex, and
a newer version of hello.rom. The "crunch.dat" file may be
newer, too (not sure). crunch.dat holds the type info for
the disassembler.
I started making up some instructions for how to use it,
but I haven't got very far with it yet. If anyone has
questions, just ask.
Oh, yeah, I added a "blank check" for codeflash, but forgot
to add it to the menu. It's ctrl-b and it will prompt for
which pages to check.
CJ
From: "apple2ebeige" <apple2ebeige@...>
Apr 30, 2005
Could somebody say what mailbug works with now amongst the various MSxx0, DETx,
and firmware models? What models may work in the future? What models might never
work?
Thanks.
-Dave
From: "John R. Hogerhuis" <jhoger@...>
Apr 30, 2005
On Sat, 2005-04-30 at 13:29 +0000, Cyrano Jones wrote:
Cool.
Of course it can, but besides being slow as you've found, it is probably
not the safest way to do it. If the connection breaks during burn (more
likely since it takes longer) you could end up, say, with a
half-programmed boot block. Or is this code intended only for burning
outside of the boot block?
Probably the best thing would be to a) download a checksummed chunk of
manageable size b) checksum it c) if it matches, burn it in.
Actually flash block burns should probably not be interruptible.
Can it be used to update existing mbug.rom?
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 30, 2005
The old brown non ergonomic case models,
firmware ver 2.22r, 2.53yr, 2.54.
These old models before the mailstation/mivo 100
did not have a "number". Possibly some of the
mailstation/mivo 100 with firmware 3.xx???
I think John H. flashed one of those and it
worked.
I expect that sooner or later, all up to 250.
They are all quite similar.
350. It has different cpu (not z80).
AFAIK, nobody is working on it.
Esentially would be a different project
from this one.
CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
Apr 30, 2005
That is a very good point, that I had not considered.
The first reason I thought of for doing it this way was to remove
the possibility of accidently erasing/flashing, which was a problem
in the past. :-)
The second reason was that it was way easier to code it in Pascal
than z80 assembler! ;^)
Right up until the last moment, I had locked out the ability to erase
the boot blocks. I wanted to add a special function that would
erase and reflash the boot code all in one operation. But I
compromised
in the spirit of just getting it uploaded. So now it issues a
"stern warning" if you ask it to erase boot code. You can only
continue by typing "I dont't care" at the prompt. :^O
Sounds reasonable to me. Maybe even send a whole 16k page, in
the case of the boot block, and then let it burn it all at once.
They're not, at least after you let it start. But if you hit the
key for, say, erase (or load, or save, etc.), when it is asking you
*what* to erase (load, save ,etc.), you can just skip it.
I do want to add the ability to abort some commands without
finishing (for instance blank checking all 64 codeflash pages
can get tiresome). But reflashing of the boot block
would definitely be one you would not want to be
interruptable.
(I know you mean mboot.rom, I can't keep them straight myself,
and I named them!)
Yes. But you will have to answer the warning with
"I don't care" (including the ' in don't) to erase the old
mboot.rom, and then flash the new - _without_rebooting_mbug!
But the neat thing about it is you should seldom need to
reflash a new mboot.rom. That is why it is seperated into
mbug and mboot. Mbug is a file on the PC disk, that gets
loaded over the laplink to mailstation RAM. It is what
the debugger (mailbug) uses to interface to mailstation.
It is a trivial matter to make change to mbug, reassemble,
and test. If you made a mistake, no problem, it's just
in RAM. Edit, assemble, and try again.
Mboot is the part that is flashed into mailstation.
It's only job is to run when mailstation reboots,
and load the current mbug into ram.
We need a better mboot.rom for the 120/150 etc.
Eventually, I want to split the code that runs on
the mailstation into three parts:
1) Seldom changing boot code (mboot.rom), either loads mbug,
or executes rom monitor if not connected to PC (mailbug).
2) Changeable-without-fear-of-hosing rom-monitor, that
runs automatically when not connected to mailbug.
3) Latest greatest interface to debugger (mbug.rom, but
it is not really burned to rom)
If this doesn't make any sense, it is probably due to the fact
that I have been up since yesterday. I really need to
sleep now...
CJ