From: "FyberOptic" <fyberoptic@...>
Jan 15, 2010
As recently discovered, the Mailstation emulator seems to be returning a di=
fferent checksum value for the firmware than what you get on the real hardw=
are. I've been digging through the disassembled code, trying to figure out=
why.
From what I can tell, the firmware does a checksum of each 16K page =
of the codeflash (just adding all the bytes together), then adds it to an o=
verall total as it goes through each page. I made a simple C util to mimic=
this, printing out the current and total checksums for each iteration of t=
he loop. I then also set a trace (via the emulator) on the address in the =
v2.53 firmware where the addition takes place, so that I could see both the=
current checksum and total checksum in its CPU registers. Each loop itera=
tion's values match in both the firmware and my util. Final checksum value=
s also match.
So, unless I've missed something, which is seeming less like=
ly the more I dig into the overall checksum function, then it's looking lik=
e it might not be an emulator issue. If this is the case, then what could =
possibly be the cause of two different people dumping two different firmwar=
e versions with incorrect checksums?
If anyone has a way to debug this in =
the actual hardware, that'd be even more helpful. In v2.53, the checksum f=
unction starts in page 2 (if you start at 0), at 0x5e2c. This all calls on=
0x2731 in page 0 to do the checksum of each page. The addition of each pa=
ge checksum into the total happens at 0x5e79 (I was tracing at 0x5e7a after=
the addition took place).
Dunno if there's anyone still here who can do=
hardware debugging, but it's worth a shot!
From: "cyranojones_lalp" <cyranojones_lalp@...>
Jan 15, 2010
=
a different checksum value for the firmware than what you get on the real h=
ardware. I've been digging through the disassembled code, trying to figure=
out why.
6K page of the codeflash (just adding all the bytes together), then adds it=
to an overall total as it goes through each page.
That sounds like what=
I remember, but what I don't get is,
64 pages x 255 max value an 8 bit byt=
e can hold =3D 0x3fc0 max
value the checksum could be. Seems like both the=
hardware
and emulator are getting higher values!!! I guess I
need to take=
a look at that calc.
From the values both you and I got last week, the
=
diff between hardware and emulated was 0x0011 & 0x0055,
IIRC. I find it cu=
rious that the differences are
so low, and one is exactly 5x the other.
I made a simple C util to mimic this, printing out the current and total ch=
ecksums for each iteration of the loop. I then also set a trace (via the e=
mulator) on the address in the v2.53 firmware where the addition takes plac=
e, so that I could see both the current checksum and total checksum in its =
CPU registers. Each loop iteration's values match in both the firmware and=
my util. Final checksum values also match.
I assume you mean you ran th=
e test on PC (without emulator).
Can you run it on the mailstation hardware=
?
re I dig into the overall checksum function, then it's looking like it migh=
t not be an emulator issue. If this is the case, then what could possibly =
be the cause of two different people dumping two different firmware version=
s with incorrect checksums?
If the code in hardware mailstation matches th=
e code emulator
is running, and gives different results, it seems it has to=
be
a problem in emulator, or maybe the z80 emulation.
For what it is wort=
h, last few days I have been messing with
trying to run an app on emulator,=
without much success.
One problem I found is the mailstation apparently o=
nly
uses the low 4 bits of the "device" byte, and when
accessing "apps" fro=
m dataflash, it uses one of the high
4 bits of device as a flag. I added a=
printf to emulator,
and the device is sometimes "0x13" when accessing apps=
.
I added "& 0x0f" to the address calc in emulator, but I
still was not abl=
e to run an app. Without the "& 0x0f"
it the emulation locked up, and with=
it, it reboots.
I decided I wanted to step thru the code, and since the
"=
docs" for z80em (and I use the term "doc" very loosely
here) mentioned a b=
uilt in debugger, I set out to try
to enable it. Unless I am missing somet=
hing here,
there is not really a debugger, rather just a "trace",
and you c=
an set the address you want to start tracing
at. The trace is not very hel=
pful, unless you can
actually see it, and it flys by faster than the retrac=
e
on my monitor can keep up with.
Have you tried to use it??? Maybe I mis=
sed something?
I did not see any way to single-step.
I imagine I could red=
irect trace to a file, but I did not
do that yet. I have been wondering if=
it would be
worth the trouble to add some real debug capability,
or if it =
would be easier to use a different emulator
that already had one. (MAME/ME=
SS comes to mind, but I
have zero experience with it.)
ay to debug this in the actual hardware, that'd be even more helpful. In v=
2.53, the checksum function starts in page 2 (if you start at 0), at 0x5e2c=
. This all calls on 0x2731 in page 0 to do the checksum of each page. The=
addition of each page checksum into the total happens at 0x5e79 (I was tra=
cing at 0x5e7a after the addition took place).
ne still here who can do hardware debugging, but it's worth a shot!
It's b=
een quite a few years now since I had that stuff set up.
I still have the m=
odded mailstation, but I am sure a wire or
two has come loose. I would lik=
e to be able to set it
up, but I have a severe lack of empty horizontalness=
here.
And, prolly the main holdup, I don't use the computer it
ran with an=
ymore. I had started to do a new version of
the "mailbug" stuff, that ran =
on XP, but I never finished
it. I would like to resurrect it, and get it r=
unning on
Linux now, just have not had time.
CJ
From: "FyberOptic" <fyberoptic@...>
Jan 16, 2010
p@...> wrote:
s,
the checksum could be. Seems like both the hardware
tting higher values!!! I guess I
We=
ll see, for each page it's just adding each individual byte together to a 1=
6-bit value. For example, if every byte was 0xFF, you'd end up with a page=
total of 4,177,920 (16384 bytes in page * 255). But since it's 16-bit it =
wraps around several times (you'd get a value of like 49,152 instead). Tha=
t resulting page value is then added to the overall checksum value each tim=
e through the loop, so the total checksum also wraps many times. So the ch=
ecksum could be any 16-bit value.
this, printing out the current and total checksums for each iteration of th=
e loop. I then also set a trace (via the emulator) on the address in the v=
2.53 firmware where the addition takes place, so that I could see both the =
current checksum and total checksum in its CPU registers. Each loop iterat=
ion's values match in both the firmware and my util. Final checksum values=
also match.
or).
Yeah the test app w=
as a standalone program on the PC, which did a checksum of whatever firmwar=
e file I specified on the command line. On the Mailstation side, I was let=
ting it do its normal checksum routine from the test menu, but had a trace =
set on a particular address in that function so I could witness each additi=
on operation during the checksum calculation.
e mailstation matches the code emulator
esults, it seems it has to be
lation.
My assumption was that the code quite possibly didn't match betwee=
n the emulator and hardware. I especially started thinking this when my st=
andalone utility was giving me the same checksum as the emulator.
or what it is worth, last few days I have been messing with
an app on emulator, without much success.
mailstation apparently only
when
f device as a flag. I added a printf to emulator,
times "0x13" when accessing apps.
emulator, but I
=
I'd be curious to t=
ry that app out myself to see if I can figure out what the problem is.
0em (and I use the term "doc" very loosely
bugger, I set out to try
e,
et the address you want to start tracing
ul, unless you can
e
I missed something?
What I did=
was recompile z80em with debug enabled. I then added a command-line switc=
h to specify a breakpoint address, which I set into the Z80_Trace variable.=
When the emulator hits the address, my debug function prints the page/dev=
ice, prints the registers and some stack, dumps the ram to a file, and give=
s me a basic prompt on the console window. I can hit enter to progress lin=
e by line, or hit C to continue with emulation (until it hits the breakpoin=
t again). Unfortunately it doesn't display the assembly code instruction w=
hen stopped, which I don't think is even possible using this emulation core=
(though libz80 could!). But it was fine for my purposes. I knew what lin=
es were what based on the disassembled source in my text editor. I just ne=
eded to see register values and ram.
Still can't peek/poke memory or I/O o=
r anything like that, but it shouldn't be hard to add at this point. This =
will all be in the next version I release I guess, whenever it gets cleaned=
up. I've been poking a bunch of junk in for my own purposes as of late.
=
I may modify the z80em core to be capable of multiple breakpoints too, whic=
h would be useful. And I can probably do memory and I/O breakpoints in the=
normal handler functions for those.
to a file, but I did not
be
be easier to use a different emulator
omes to mind, but I
Z80em should be fine =
with maybe some minor updates. I can write in a function to decypher the n=
ext opcode to text myself if I want a more advanced debugger, it'll just ta=
ke a little work.
So, now to what I've done since my last post. After=
digging for ages trying to find my laplink/interlink cable again just to s=
end code to the Mailstation (I put things where I'll remember them later, t=
hen forget where I put them), I wrote a Mailstation test program to work ve=
ry similar to the one I wrote on my PC. It does the checksum of a codeflas=
h page, displays the value of that, along with the current total checksum v=
alue, looping through all 64 pages (with a pause between each one). I'm st=
ill using a checksum function from the firmware to do this, which is 0x2731=
in v2.53, and 0x2724 in v3.03a. No need to rewrite something so small whe=
n it's easy to see exactly what it does in the disassembly. It's called fr=
om the larger function which calculates the total firmware checksum.
Any=
how, with this, I was able to match up page checksums displayed on the Mail=
station screen to the ones from my PC equivalent of the program (not in the=
emulator, mind you). From a glance, it seemed like the page checksums all=
matched, until it got to the end. I then saw the same alternate total che=
cksum value that I get in the maintenance tests on the hardware.
So I incr=
eased the delay between outputs so that I could confirm each individual pag=
e checksum. It started out good, until it got to page 17. Instead of 0x7c=
6e which I get on the PC, I got 0x7c5D. But then, oddly, all the rest of t=
he pages matched up perfectly. So only page 17 had the problem. That's th=
e 0x11 byte difference in the overall checksum I was getting between hardwa=
re and emulator.
This shows that it's apparently not the emulator after =
all, and is something different between the firmware and my dump of it.
Ne=
xt step is to redump just page 17 to my computer and see if transfers wrong=
again, but that'll take more assembly code, and I'm off to bed for now. Y=
et I have a feeling I'm going to get the same alternate version of the page=
, in which case I'm going to have to break that page down into pieces to se=
e what's going on. We'll see.
From: "randy129" <randy129@...>
Jan 19, 2010
s like what I remember, but what I don't get is,
ue an 8 bit byte can hold =3D 0x3fc0 max
st adding each individual byte together
Yeah. I jumped to conclusion tha=
t "checksum8" was returning 8 bit checksums.
st few days I have been messing with
without much success.
ently only
sing "apps" from dataflash, it uses one of the high
a flag. I added a printf to emulator,
13" when accessing apps.
or, but I
t the emulation locked up, and with it, it reboots.
try that app out myself to see if I can figure out what the
=
I got it working. :-)
I'll post some stuff soon, but helloapp.rom is in =
file area.
Just paste it into your dataflash image with a hex editor,
and t=
weak the "app directory" in page 8.
The app I was having trouble with is a=
sort of frankenstein
app, with a bunch of tests of various widgets from
th=
e mailstation firmware.
Turns out it was a problem with sdcc linking the w=
rong putchar.
I don't remember doing it, but it probably happened a few mon=
ths ago
when I was switching between various snapshots of sdcc. I had
comm=
ented out the custom putchar in my makefile!!!
I have not actually used =
sdcc for anything since feb 2008, but
I joined their mail list back in '07.=
Since then, there have
been a few problems others were having
(with the =
z80 port of sdcc), that I remembered having myself.
One in particular wa=
s that -o just did not work
with the z80 linker. I had learned to work aro=
und it myself,
and I even looked into fixing it, but never got to the botto=
m of it.
So, though I was not presently using sdcc, when yet another
was l=
earning of this bug the hard way (~ Sept 2009), I took another
look at it. =
This time I saw what the problem was,
and patched it.
In the process of t=
esting, I was recompiling a mailstation app,
and I guess I got tired of del=
eting the "putchar" from sdcc's
z80 lib in various sdcc snapshot versions. =
I knew at the time
that the standard putchar would not work on the mailst=
ation,
but since I was not actually gonna try to run the code (or so I
tho=
ught!) it did not matter. When I got done with the
patch, I forgot to put=
the putchar back in my lib.
I don't really have a lot of experience with =
c libs, but I
seem to recall that the sdcc manual states that it will use
t=
he version of a lib from the first place it finds it on the
lib search list=
. IIRC, I had to remove the standard putchar,
but not getchar, to get my c=
ode to link. Likewise with crt0.
Anyone care to comment on what the stand=
ard behaviour is in this
regard? And by standard, I guess I mean "what doe=
s gcc do?".
oned a built in debugger, I set out to try
issing something here,
race",
he trace is not very helpful, unless you can
ys by faster than the retrace
Have you tried to use it??? Maybe I missed something?
y way to single-step.
d. I then added a
which I set into
That is essentialy what I di=
d, too.
the page/device, prints the registers and some stack,
file, and gives me a basic prompt on the console window.
er to progress line by line, or hit C to continue with
it hits the breakpoint again).
Sounds like you replaced the built in "Z80=
_Debug(Z80_Regs *R)" with
your own, 'coz the built-in one does *not* stop.
=
topped,
Sounds like you replaced the built in "Z80_Debug(Z80_Regs *R)" wi=
th
your own, 'coz the built-in one *does* display the disassemled inst.
which I don't think is
ibz80 could!).
See one comment above. ;-)
purposes. I knew what lines were what based on the
in my text editor. I just needed to see register
till can't peek/poke memory or I/O or anything like that, but it shouldn't =
Nothing is "hard" about it, except mayb=
e finding the time to do it.
ase
unk in
to be capable of multiple breakpoints too,
can probably do memory and I/O breakpoints
ons for those.
Yeah, I made some changes to it myself, but I wonder if it =
might be
better to keep it "as is", and extend it on the msemu side.
One id=
ea I had was to change how you call it, so it only executes
a single inst o=
n every call (and of course mod the interrupt emulation
to compensate).
As=
far as the number of breakpoints, in my experience, the only
time I ever r=
eally needed more than one was when single stepping
over conditional branch=
es, where you drop a breakpoint for both
possible "next" cases. And that i=
s only when debugging on hardware,
where you need to modify the code at the=
"breakpoints". With an
emulated cpu, you don't need to do this, you can j=
ust execute a
single instruction, and it will stop whichever way it branch=
ed.
if transfers
ff to bed for now.
nate version of the page,
page down into pieces to see
Can't you just dump the=
whole rom again (with existing code)?
When you say 17, do you mean decima=
l 17, or 0x17?
CJ
From: "FyberOptic" <fyberoptic@...>
Jan 21, 2010
guess I got tired of deleting the "putchar" from sdcc's
s sdcc snapshot versions. I knew at the time
would not work on the mailstation,
to run the code (or so I
with the
really have a lot of experience with c libs, but I
he sdcc manual states that it will use
t place it finds it on the
andard putchar,
rt0.
=
I recently=
updated my SDCC as well and ran into this problem again. All I do though =
is delete their version of putchar.o from the LIB then include my own versi=
on on the command line when I link a program (along with my custom crt0). =
I could add it to their system library and all, but I like to keep my code =
separate from theirs. If one regularly updates their SDCC from the snapsho=
t, then it should be easy enough to make a script to take care of deleting =
putchar.o from their LIB automatically.
They don't use the SDCCLIB utility=
anymore for the system libraries, which threw me off a bit at first till I=
read the updated manual. They use the standard binutils "ar" command now.=
Though to create the index the normal "ranlib" doesn't work, so you have =
to use "asranlib" that comes with SDCC.
e address, my debug
ers and some stack,
pt on the console window.
r hit C to continue with
).
h
Yeah Z80_Debug in =
the z80em header is just a placeholder, you have to create your own functio=
n to handle it.
der if it might be
side.
a single inst on every call (and of course mod the interrupt emulation
o compensate).
Well, if you only want to execute one instruction at a time=
without modifying the z80em source, you could enable Z80_Trace, and then i=
t calls your debug function regularly. That just slows you down in the end=
, though, unless you're only using it during debugging.
ust dump the whole rom again (with existing code)?
you mean decimal 17, or 0x17?
I meant decimal 17.
I finally g=
ot around to redumping my codeflash. As it turns out, I must have just had=
a bad dump all along. On this one, my checksum utility now returns the sa=
me value as the emulator which also returns the same value as the hardware.=
As for what's in page 17 where I was getting the checksum difference, I h=
aven't looked. I never had any problems out of my previous dump aside from=
that checksum, so maybe it was either code I was never executing or some g=
raphical data or something.
I just never assumed it was a dump issue, beca=
use usually whenever those happened it threw the whole dump off (and then u=
sually stopped just short of 100% of the total data). I guess if I ever im=
plement anything involving parallel port transfer (which I started writing =
into FyOS before), I'll definitely be including some kind of checksum on th=
e data packets.
From: "cyranojones_lalp" <cyranojones_lalp@...>
Jan 22, 2010
recall that the sdcc manual states that it will use
b from the first place it finds it on the
to remove the standard putchar,
k. Likewise with crt0.
d behaviour is in this
oes gcc do?".
blem again.
he LIB
In the older versions of SDCC, the libs were not archives, they ju=
st
had all the .o's in the lib directory. I really did not want to get
sid=
etracked learning how to remove the putchar from the z80.lib
archive file. =
So, I just commented mine out in the makefile for
my library!
lude my own version on the command line when I link a program
I did take =
the time to learn how to make a library, and I can't find
where the instruc=
tions are now, but (~fall 2007, whatever version of
sdcc might have been cu=
rrent then) the info I found then suggested
just leaving the .o's in your l=
ib's dir, and creating a .lib file
in same dir,
where this .lib was just =
a list of the .o filenames that make up your
library.
So, I created a libr=
ary for mailstation apps, with putchar & getchar
(which I only use for debu=
gging), and also a custom crt0 for
mailstation apps. Also the header and =
.s wrappers for the firmware
calls. And a few other functions, like "tribl=
ink", etc.
The main thing different about crt0 for apps is I left the call=
to gsinit out, because the app is not a standalone program, it
is just a s=
ingle "eventhandler" function. I let that eventhandler
call the gsinit for=
the app when it receives the "init" event
from the mailstation. That way =
my globals don't get re-init
for every event, just once when app is "inited=
".
This is similar to a standard program calling gsinit as the
very first =
thing. Just I don't want to call it every time code runs.
y custom crt0). I could add it to their system library and all,
ike to keep my code separate from theirs.
Right, I like to keep mine sep=
arate, too.
I really think they should remove the putchar, getchar,
and=
crt0 from the z80 lib, because they are not
appropriate for all z80 syste=
ms. In fact they are only
appropriate for whatever system the default cod=
e works on.
(And just what system is it, anyways?????????)
Those 3 funct=
ions belong in a lib specific to a particular
system. They should separate=
them out into z80.lib and
generic system_demo.lib. Then it would be a lot=
clearer
what parts you needed to customise for your particular hardware.
=
I imagine *everyone* who uses sdcc needs to remove those
from the system l=
ibrary.
I suppose most people are more familiar with programming
on a PC, =
where the people who create the lib can make
assumption that you are compil=
ing for same type of system
the compiler is running on, and those function=
s can be
part of the lib that comes with compiler.
I know I am used to tak=
ing that kind of stuff for granted.
I don't think I realized there was even=
any "startup"
code linked when on PC, but I guess it is standard (with
c a=
t least???) I suppose I always thought that whatever
it needed to set up, =
it did at the start of "main", before
my code.
After playing with sdcc, I =
took a look at avr-gcc, and
it has startup code, too! A different startup=
for each
type of AVR chip.
the snapshot, then it should be easy enough
re of deleting putchar.o from their LIB automatically.
I think that when I=
get farther up the sdcc learning curve
I will figure out how others are do=
ing this. I suspect that
you are supposed to "install" even the snapshots=
, but I still
don't know exactly how to tell it where. And more important=
,
where it puts the library. I don't want it to install in
the default loc=
ation, because I want to have more than one
version available at same time,=
so I can just change
SDCCPATH in my projects makefile, to pick which to u=
se.
I thought I knew how to do this. I was running the snap
from exactly =
where "make" put the bin's. And I thought it
was using the right library, =
too. But the snaps after
2.9.0 seem to not find the lib. Actually, it see=
ms it
is using the lib installed in usr/local/whatever, iow
the lib that in=
stalled with 2.9.0.
I'm *sure* the older versions were finding lib relativ=
e to
the executable. I wish they would quit changing this stuff! :-)
hey don't use the SDCCLIB utility anymore for the system libraries, which t=
hrew me off a bit at first till I read the updated manual. They use the st=
andard binutils "ar" command now. Though to create the index the normal "r=
anlib" doesn't work, so you have to use "asranlib" that comes with SDCC.
I=
t seems the old way still works, too, coz my lib is still working.
CJ
(I=
think Yahoo has a bug, where it grows blank lines at top
of your post ever=
y time you "preview". I just deleted 3 or 4
lines, so this should be ramme=
d right to top. We'll see...)
From: "cyranojones_lalp" <cyranojones_lalp@...>
Jan 22, 2010
he page/device, prints the registers and some stack,
o a file, and gives me a basic prompt on the console window.
hit enter to progress line by line, or hit C to continue with
ion (until it hits the breakpoint again).
d the built in "Z80_Debug(Z80_Regs *R)" with
n one does *not* stop.
aceholder, you have to
No, I did=
n't create one, I used the one in Z80Debug.c.
Did you find documentation t=
hat said you need your own?
From the comments in Z80Debug.c:
/*** This fi=
le contains a simple single step debugger which is called ***/
/*** whe=
n DEBUG is #defined and Z80_Trace is true ***/
And=
it implements the function
void Z80_Debug(Z80_Regs *R);
that is prototy=
ped in Z80.h.
But I agree 110 percent that you need to create your own, co=
z this
one does not do what the comment says it does!!!
But It DOES disass=
emble the instructions. It just does not stop,
it keeps going, pouring out=
the disassembly from the point that you set
with the trap var. I tried r=
edirecting to a file, and you don't know
what fun IS until you have tried t=
o open a 1.5 gigabyte text file!
And that was only running a second or so =
past the trap point. I
knew it would be a large file, but this is ridiculo=
us!
But I did find where my code went haywire and started executing
from t=
he low address of 0000:0008. There was a "rst 8" right
before that, and I =
checked the address of the function with
the rst 8 in in it, with the .map =
file, and it was putchar.
That rst 8 looked mighty familiar at that poin=
t, just like
the "standard" putchar!!!! It all came back to me soon
afte=
r that...
ight be
One idea I had was to change how you call it, so it only executes
ngle inst on every call (and of course mod the interrupt emulation
ompensate).
e without modifying the z80em source, you could enable Z80_Trace, and then =
it calls your debug function regularly. That just slows you down in the en=
d, though, unless you're only using it during debugging.
Yeah, you could d=
o it that way too, but then you need to leave out
Z80Debug.c that comes wit=
h z80em.
But if you just set the "Z80_IPeriod" to 0, then I think it will
=
single step, and you can handle it in msemu. I don't know if
it is better,=
just how I think I would do it. of course you
would need to mod the inter=
rupt emulation, too. (iow, you
need to time them yourself, if z80em is now =
checking for
int after every instruction.)
The way it is now, you *can't*=
get an interrupt except
once every millisec.
That is probably good enoug=
h, though. Particularly for the
1 ms interrupt. But when is the 1 sec in=
t happening????
Is it stealing one of the 1 ms ints on those cases????
W=
hat about other interrupts, like the ones you found for kbd &
power button?=
??? I imagine 1 ms period is ok there too, but
it is not really an interru=
pt if it can only happen at a particular
time. Not that it really matters=
.
Perhaps it will do all the pending interrupts on each 1 ms beat???
I'm=
not sure just how it is working now.
imal 17, or 0x17?
ping my codeflash. As it turns out, I must have just had a bad dump all al=
ong. On this one, my checksum utility now returns the same value as the em=
ulator which also returns the same value as the hardware. As for what's in=
page 17 where I was getting the checksum difference, I haven't looked. I =
never had any problems out of my previous dump aside from that checksum, so=
maybe it was either code I was never executing or some graphical data or s=
omething.
If you start at 0, and mean page 0x11, then it looks like it
is =
all related to address book functions, either the address
book app itself, =
or the address book functions in "inbox", "outbox",
"create new", or "sent=
" apps.
er those happened it threw the whole dump off (and then usually stopped jus=
t short of 100% of the total data).
So, you are saying it happens often?=
;^)
I still need to get to the bottom of my checksum "anomally".
I an us=
ing the data from the 253yr dump in file area, not my
actual 2.53yr mailsta=
tion. I probably should get around to
making room to set up old pc, and du=
mp actual code. Or maybe
I need to figure out how to run it on Linux??? I=
can run
it under a dos emulator (for what it's worth, that pegs cpu
at 10=
0% too). But I don't know how hard it is to get access
to par port??? Ma=
ybe if I run as root? heh heh heh!
Everywhere I look, more learning cur=
ves. And only one lifetime. sniff.
g involving parallel port transfer (which I started writing into FyOS befor=
e), I'll definitely be including some kind of checksum on the data packets.=
I know it makes some cringe, but I did not put any checksum
in the tribb=
lelink code, and I never noticed a hiccup.
Doesn't mean it didn't, but I =
never noticed any, and I
was using it A LOT. I was loading the ms firmwar=
e into RAM,
and verifying whenever I thought I should, and NEVER
was there =
a problem. And all the commands to mbug
went over it. Heck, even mbug got=
loaded over it!!!
[ouch, I think I dislocated my shoulder...]
CJ
From: "FyberOptic" <fyberoptic@...>
Jan 22, 2010
...> wrote:
ins a simple single step debugger which is called ***/
G is #defined and Z80_Trace is true ***/
t implements the function
rototyped in Z80.h.
ur own, coz this
t It DOES disassemble the instructions. It just does not stop,
going, pouring out the disassembly from the point that you set
trap var.
Aha, you found out something I didn't even realize. I didn't =
know it was capable of displaying the instruction in ascii. I'll have to a=
dd this into my own debug function.
The reason I never noticed this is bec=
ause I never included z80debug.o when building msemu. Going by the makefil=
e, it's not built into z80.o automatically. I'm sure if I included this ob=
ject file in mine and commented out my debug function, I'd get the same res=
ult as you.
So the solution is to just dump including z80debug.o and write=
your own version of the function. Or wait forever until I get around to r=
eleasing another version, I suppose!
d you don't know
text file!
When I was using libz80 and capturing all its disassembly ou=
tput (along with my custom debug stuff too) to a file, I had me some fun ti=
mes as well. Eventually I changed it to start outputting to a separate fil=
e after hitting a certain keypress (this was before I had breakpoints or an=
ything), which helped somewhat. But UltraEdit can handle big files relativ=
ely well without keeling over, fortunately.
I lost my ability to print o=
ut disassembled code when switching to z80em, but now that you brought that=
capability to my attention, I'll have to see about adding that in. I don'=
t really need disassembled output at the moment, particularly after getting=
a CPU library that's not full of bugs, but it could be handy to have later=
.
ms interrupt. But when is the 1 sec int happening????
one of the 1 ms ints on those cases????
The Z80_Interrupt function is b=
eing called 64 times a second (when z80em runs out of t-states to execute e=
ach time). This function triggers the "keyboard" interrupt to the Mailstat=
ion every time, as long as it's enabled in the interrupt mask (P3). Also i=
nside the Z80_Interrupt function is a counter up to 64, at which point it t=
riggers the 1-second "time16" interrupt (again, if enabled in the interrupt=
mask).
The "interrupts_active" variable acts as the value that the Mailst=
ation gets when it reads P3. So at the end of the Z80_Interrupt function, =
it checks if any of these device interrupts are currently active, and if so=
, it causes the emulator to execute an actual cpu interrupt (which runs the=
Mailstation's handler).
I assume in the actual hardware that P3 is some=
how also connected (OR'd) to the Mailstation's interrupt pin, so that's wha=
t this simulates. If any bits of P3 aren't toggled during the interrupt, t=
hen they will just cause an interrupt to happen again next time. Though it=
won't happen immediately, as would happen on the hardware, I just realized=
. But they'll happen at the next execution of Z80_Interrupt.
I know tha=
t they definitely happen in quick succession on the hardware, because I had=
it happen in my interrupt hook before when I didn't toggle the bits in P3.=
The interrupt just kept happening over and over.
terrupts, like the ones you found for kbd &
ms period is ok there too, but
nly happen at a particular
haps it will do all the pending interrupts on each 1 ms beat???
ure just how it is working now.
Only two of the hardware interrupts are=
being emulated right now, as mentioned above. I didn't bother implementin=
g the physical power button and keypress interrupts I found before, since t=
he Mailstation software doesn't use them. I will at some point though, in =
order to stay hardware-accurate. I was mostly concerned about getting the =
firmware running properly first and foremost.
In my current version though=
I've been emulating the modem interrupt, because I actually have emulated =
enough of the modem chip that the Mailstation starts sending ascii characte=
rs to it. I've managed to get the initialization string to come through so=
far. I now need to emulate the chip sending data back, to do an "OK" and =
"CONNECT" and all when appropriate.
I'd just like to get the modem emulate=
d so that eventually my own Mailstation software can communicate with the P=
C over that connection, freeing up the much more useful parallel port for o=
ther capabilities. Like an SD card reader or something.
ver assumed it was a dump issue, because usually whenever those happened it=
threw the whole dump off (and then usually stopped just short of 100% of t=
he total data).
Not often=
I suppose, but my cable does run past various wires, including electrical,=
so the potential for problems always exists in my case.
ed to get to the bottom of my checksum "anomally".
om the 253yr dump in file area, not my
ably should get around to
ode. Or maybe
=
o). But I don't know how hard it is to get access
if I run as root? heh heh heh!
I've never done it personally under Lin=
ux, but it does seem somewhat straightforward (permissions aside). I'm tem=
pted to try it sometime just for curiosity's sake.
Here's you a potentiall=
y helpful resource which I've looked over before:
(URL)
/Linux-mini/IO-Port-Programming.html
I'd say if Linux is your OS of choice=
these days then it's worth learning. Lots of things you can do with it ou=
tside of just Mailstation-related, after all.
I don't know if your origi=
nal code is in C or not though, so that might make porting it over a little=
more complicated. But the maildump utility I wrote is in C, if you ever w=
ant it.