Mailtstation Emulation (Dec 27, 2009)
(home)- From: "fyberoptic1979"
- From: "Donald H"
- From: "FyberOptic"
- From: "Donald H"
- From: "FyberOptic"
Subject: Mailtstation Emulation
From: "fyberoptic1979" <fyberoptic1979@...>
Dec 27, 2009
Hiya folks, been a while since I checked here. Nice to see there's at
leas=
t been a few posts recently, though!
Anyhow, I was trying to get a version=
of CP/M written a while back for
the Mailstation, and even did that hardwa=
re mod for banking out the
first 16KB of address space with ram just specif=
ically for that. But
then a combination of distractions as well as the lof=
ty goals of writing
like a storage system for the Flash memory and everythi=
ng just kind of
pulled me away from Mailstation work.
Part was laziness to=
o though, I admit, since it's tedious to write code
on the PC, compile, tra=
nsfer it to the Mailstation, see if it works. If
not, try to debug what ha=
ppened by trying to write things to the screen,
etc. And even then you're =
not getting all the information you might
want for debugging purposes, espe=
cially if you crashed it. Definitely a
pain.
So recently, when the notion=
of messing around with the MS again started
rattling around in my head, I =
realized that the only reasonable way for
me to continue developing anythin=
g elaborate was to emulate the hardware
on the PC. More lofty goals!
But =
the more I thought about it, the more I realized that the hardest
part was =
going to be the CPU. And as luck would have it, I found
something called l=
ibz80 to do the job for me. It has hooks for
reading/writing memory and I/=
O, which works great for all the
device/page switching that the Mailstation=
does.
Well, turns out, libz80 has a ton of emulation bugs, which were mes=
sing
me up for a few days. I've corrected many of them in the source (it's=
very well written and easy to modify compared to another z80 emulation
lib=
rary I saw), and notified the author, who seemed eager to get a fixed
versi=
on up as soon as possible.
So now, after much debugging and digging throug=
h assembly output, I've
successfully gotten to what appears to be a Mailsta=
tion error screen,
and then the cpu is intentionally halted. =A0Here's an i=
mage:
I have no idea what is resulting in the behavior at this point, bu=
t it's
the first visible indication of progress so far, so I thought I'd sh=
are
it for anyone interested.
As for the technical details:
- The Mailsta=
tion memory map is properly emulated, with codeflash page 0
in the first 16=
K, and RAM page 0 in the last 16K.
- Device/page switching via I/O ports is=
functional for the middle two
16K slots
- Devices emulated so far: RAM (re=
ad/write), Codeflash (read), Dataflash
(read/write), LCD (write)
- Dataflas=
h has sector-erase and byte-program chip functions emulated
- LCD is curren=
tly written into buffers (one for each LCD half), and
later dumped to separ=
ate files. =A0The LCD CAS bit is properly emulated
to make this possible. =
=A0I've written a separate utility to convert
the raw binary files into vie=
wable BMP images.
I've started writing in PDCurses support to give a deb=
ugger interface.
Though I've also done /raw and /silent command line switc=
hes. The
former dumps disassembly and debug output straight to the screen,=
which
can be redirected to a file. The latter disables all output, speedi=
ng
emulation up considerably. I've actually done 100% of my debugging so
f=
ar by using /raw and dumping to a text file, which has grown upwards to
200=
MB! I'm hoping to get the debugging interface working eventually to
avoid =
this roundabout way of doing it.
Another possibly interesting tidbit is th=
at I'm modifying the codeflash
at emulator startup, and changing the Mailst=
ation's delay() function to
simply RET immediately. It was outputting tons=
of useless information
during that call. I don't think this will hurt my =
emulation at all,
especially since I'm not even emulating interrupts/timers=
yet.
I'm running on the Mailstation v2.53 firmware for this, with a dataf=
lash
dump I made from my v3.03 firmware. I have no idea if this will cause=
issues, but it's the only dataflash image I have. The reason I'm using
th=
e 2.53 firmware is because I have a very commented disassembly file of
code=
flash page 0 for that version, which has helped a ton in debugging.
I woul=
d love to have more disassembled pages with comments like this, if
anyone h=
as them! I've spent a lot of time commenting some of the later
pages mysel=
f to the best of my ability, which has slowed me down a lot.
Anyhow, the n=
ext biggest thing is to get the LCD actually emulated
visually in real-time=
. In order to make it all as cross-platform as
possible, I might be able t=
o do it with SDL, but I'll have to see what I
can do.
The other big thing =
is to track down why the Mailstation is halting
after showing this screen. =
It'll take a lot more digging through
disassembled Mailstation source I gu=
ess, since the initialization
routine it was running was in another page of=
the codeflash. But I'm
still making progress, albeit slowly!
Hiya folks, been a while since I checked here. Nice to see there's at leas=
t been a few posts recently, though!<BR><BR>Anyhow, I was trying to get a v=
ersion of CP/M written a while back for the Mailstation, and even did that =
hardware mod for banking out the first 16KB of address space with ram just =
specifically for that. But then a combination of distractions as well as t=
he lofty goals of writing like a storage system for the Flash memory and ev=
erything just kind of pulled me away from Mailstation work. <BR><BR>Part w=
as laziness too though, I admit, since it's tedious to write code on the PC=
, compile, transfer it to the Mailstation, see if it works. If not, try to=
debug what happened by trying to write things to the screen, etc. And eve=
n then you're not getting all the information you might want for debugging =
purposes, especially if you crashed it. Definitely a pain.<BR><BR>So recen=
tly, when the notion of messing around with the MS again started rattling a=
round in my head, I realized that the only reasonable way for me to continu=
e developing anything elaborate was to emulate the hardware on the PC. Mor=
e lofty goals!<BR><BR>But the more I thought about it, the more I realized =
that the hardest part was going to be the CPU. And as luck would have it, =
I found something called libz80 to do the job for me. It has hooks for rea=
ding/writing memory and I/O, which works great for all the device/page swit=
ching that the Mailstation does.<BR><BR>Well, turns out, libz80 has a ton o=
f emulation bugs, which were messing me up for a few days. I've corrected =
many of them in the source (it's very well written and easy to modify compa=
red to another z80 emulation library I saw), and notified the author, who s=
eemed eager to get a fixed version up as soon as possible.<BR><BR>So now, a=
fter much debugging and digging through assembly output, I've successfully =
gotten to what appears to be a Mailstation error screen, and then the cpu i=
s intentionally halted. =A0Here's an image:(URL)
ybertech.net/mailstation/img/lcdfull.png"><BR><P>I have no idea what is res=
ulting in the behavior at this point, but it's the first visible indication=
of progress so far, so I thought I'd share it for anyone interested.</P><P=
ly emulated, with codeflash page 0 in the first 16K, and RAM page 0 in the =
last 16K.<BR>- Device/page switching via I/O ports is functional for the mi=
ddle two 16K slots<BR>- Devices emulated so far: RAM (read/write), Codeflas=
h (read), Dataflash (read/write), LCD (write)<BR>- Dataflash has sector-era=
se and byte-program chip functions emulated<BR>- LCD is currently written i=
nto buffers (one for each LCD half), and later dumped to separate files. =
=A0The LCD CAS bit is properly emulated to make this possible. =A0I've writ=
ten a separate utility to convert the raw binary files into viewable BMP im=
ages.<BR></P><P><BR>I've started writing in PDCurses support to give a debu=
gger interface. Though I've also done /raw and /silent command line switch=
es. The former dumps disassembly and debug output straight to the screen, =
which can be redirected to a file. The latter disables all output, speedin=
g emulation up considerably. I've actually done 100% of my debugging so fa=
r by using /raw and dumping to a text file, which has grown upwards to 200M=
B! I'm hoping to get the debugging interface working eventually to avoid t=
his roundabout way of doing it.<BR><BR>Another possibly interesting tidbit =
is that I'm modifying the codeflash at emulator startup, and changing the M=
ailstation's delay() function to simply RET immediately. It was outputting=
tons of useless information during that call. I don't think this will hur=
t my emulation at all, especially since I'm not even emulating interrupts/t=
imers yet.<BR><BR>I'm running on the Mailstation v2.53 firmware for this, w=
ith a dataflash dump I made from my v3.03 firmware. I have no idea if this=
will cause issues, but it's the only dataflash image I have. The reason I=
'm using the 2.53 firmware is because I have a very commented disassembly f=
ile of codeflash page 0 for that version, which has helped a ton in debuggi=
ng. I would love to have more disassembled pages with comments like this, =
if anyone has them! I've spent a lot of time commenting some of the later =
pages myself to the best of my ability, which has slowed me down a lot.<BR>=
ally in real-time. In order to make it all as cross-platform as possible, =
I might be able to do it with SDL, but I'll have to see what I can do. <BR=
ter showing this screen. It'll take a lot more digging through disassemble=
d Mailstation source I guess, since the initialization routine it was runni=
ng was in another page of the codeflash. But I'm still making progress, al=
beit slowly!<BR><BR><BR><BR><BR></P>
1: Subject: Re: Mailtstation Emulation
(top)From: "fyberoptic1979" <fyberoptic@...>
Dec 29, 2009
I've made some progress, after muchhhh firmware disassembly, tracing
throu=
gh the startup procedure. =A0
First up, I've gone to SDL for graphics, so =
now the LCD can be updated
in mostly real-time (not too often though or it =
slows down emulation
considerably).
I emulated the power and battery bits =
of port 9, so that it actually
thinks it's not about to burn out. =A0This g=
ot rid of the previous
screen I was seeing (which I assume was a low batter=
y warning, despite
the missing text), and now simply displayed the logo ins=
tead (without
the blank message box on top) before halting.
So after a whi=
le of more tracing through things, I realized that maybe I
just needed to w=
arm-boot the system, since it does have a cold-boot
procedure too, and it s=
eemed to be running this every time (messing with
dataflash, setting up ram=
, etc). =A0So upon receiving the CPU halt, I
told it to simply reboot autom=
atically instead (keeping ram/dataflash
changes intact). =A0Then, low and b=
ehold:
Same shot as above, except from the v3.03 firmware:
I th=
ink maybe an interrupt automatically wakes it back up normally
instead of h=
aving to push the power button again? =A0I'll have to look
into it more. =
=A0
Anyway, I tried the v3.03 firmware again to see if that would make a
=
difference due to the dataflash image I'm using, but I still get the
reset =
menu. =A0Which I later remembered is what normally happens when
you cold-bo=
ot a Mailstation. =A0
I also tried setting the "bootstate" ram byte to 0x5=
a at startup to
avoid all the cold-boot initialization stuff, to maybe get =
straight to
the main menu, but it just perpetually reboots then. =A0I'm obv=
iously
missing something it needs/wants to work properly in that respect.
=
So it looks like the next step is to properly emulate keypresses, in
order =
to get past this screen! =A0That'll require triggering an
interrupt too. =
=A0Only part I'm worried about is that I seem to recall
the key scanning fu=
nction relies on a timer to know how long you've held
down a key, and I don=
't know if I'll ever be able to emulate that with
complete accuracy (especi=
ally since the Z80 cpu library I'm using just
emulates instructions, not cl=
ock cycles). =A0But we'll see.
through the startup procedure. =A0</P><P>First up, I've gone to SDL for gra=
phics, so now the LCD can be updated in mostly real-time (not too often tho=
ugh or it slows down emulation considerably).</P><P>I emulated the power an=
d battery bits of port 9, so that it actually thinks it's not about to burn=
out. =A0This got rid of the previous screen I was seeing (which I assume w=
as a low battery warning, despite the missing text), and now simply display=
ed the logo instead (without the blank message box on top) before halting.<=
/P><P>So after a while of more tracing through things, I realized that mayb=
e I just needed to warm-boot the system, since it does have a cold-boot pro=
cedure too, and it seemed to be running this every time (messing with dataf=
lash, setting up ram, etc). =A0So upon receiving the CPU halt, I told it to=
simply reboot automatically instead (keeping ram/dataflash changes intact)=
. =A0Then, low and behold:
mailstation/img/msemu_scanningdata.png">
rtech.net/mailstation/img/msemu_resetdata253.png"><BR><BR>Same shot as abov=
e, except from the v3.03 firmware:
(URL)
et/mailstation/img/msemu_resetdata303.png"></P><P><BR></P><P>I think maybe =
an interrupt automatically wakes it back up normally instead of having to p=
ush the power button again? =A0I'll have to look into it more. =A0<BR></P><=
P>Anyway, I tried the v3.03 firmware again to see if that would make a diff=
erence due to the dataflash image I'm using, but I still get the reset menu=
. =A0Which I later remembered is what normally happens when you cold-boot a=
Mailstation. =A0</P><P>I also tried setting the "bootstate" ram byte to 0x=
5a at startup to avoid all the cold-boot initialization stuff, to maybe get=
straight to the main menu, but it just perpetually reboots then. =A0I'm ob=
viously missing something it needs/wants to work properly in that respect.<=
/P><P>So it looks like the next step is to properly emulate keypresses, in =
order to get past this screen! =A0That'll require triggering an interrupt t=
oo. =A0Only part I'm worried about is that I seem to recall the key scannin=
g function relies on a timer to know how long you've held down a key, and I=
don't know if I'll ever be able to emulate that with complete accuracy (es=
pecially since the Z80 cpu library I'm using just emulates instructions, no=
t clock cycles). =A0But we'll see.</P><P><BR></P><P><BR></P>
2: Subject: Re: Mailtstation Emulation
(top)From: "Donald H" <donhamilton2002@...>
Dec 30, 2009
Looks like nice work.
ARe you running this emulator under Linux or Windows=
?
don
79@...> wrote:
see there's at
s trying to get a version of CP/M written a while back for
n, and even did that hardware mod for banking out the
ss space with ram just specifically for that. But
distractions as well as the lofty goals of writing
for the Flash memory and everything just kind of
station work.
s to write code
f it works. If
to the screen,
n you might
efinitely a
h the MS again started
ly reasonable way for
emulate the hardware
hought about it, the more I realized that the hardest
e the CPU. And as luck would have it, I found
do the job for me. It has hooks for
ch works great for all the
s.
sing
's
gging through assembly output, I've
o be a Mailstation error screen,
. =A0Here's an image:
havior at this point, but it's
o far, so I thought I'd share
echnical details:
ith codeflash page 0
- Device/page switching via I/O ports is functional for the middle two
K slots
taflash
-program chip functions emulated
(one for each LCD half), and
AS bit is properly emulated
rate utility to convert
ace.
=
can be redirected to a file. The latter disables all output, speeding
mulation up considerably. I've actually done 100% of my debugging so
by using /raw and dumping to a text file, which has grown upwards to
MB! I'm hoping to get the debugging interface working eventually to
d this roundabout way of doing it.
is that I'm modifying the codeflash
e Mailstation's delay() function to
tting tons of useless information
ill hurt my emulation at all,
errupts/timers yet.
this, with a dataflash
a if this will cause
he reason I'm using
disassembly file of
ton in debugging.
ments like this, if
some of the later
ed me down a lot.
ually emulated
latform as
see what I
station is halting
ing through
tion
m
3: Subject: Re: Mailtstation Emulation
(top)From: "FyberOptic" <fyberoptic@...>
Dec 30, 2009
r Windows ?
I'm compiling/running it under Windows at the mom=
ent, though I'm thinking it won't take much in terms of tweaks to make it r=
un in Linux. I've never tried writing an SDL-based app in Linux, though, s=
o at this point I don't know if it involves anything extra or not.
4: Subject: Re: Mailtstation Emulation
(top)From: "Donald H" <donhamilton2002@...>
Dec 30, 2009
=
:
r Linux or Windows ?
er Windows at the moment, though I'm thinking it won't take much in terms o=
f tweaks to make it run in Linux. I've never tried writing an SDL-based ap=
p in Linux, though, so at this point I don't know if it involves anything e=
xtra or not.
I am new to emulators, so this would act as a learning tool=
.
Will you be making your code available ?
Thanks
don
5: Subject: Re: Mailtstation Emulation
(top)From: "FyberOptic" <fyberoptic@...>
Dec 30, 2009
l you be making your code available ?
Yeah I don't =
see why not. I released all the source to Mailstation things I've written =
before and all. Right now it's a mess though, full of lots of debugging st=
uff that would only make sense to me. Not to mention, it's not very functi=
onal just yet!