From: "Jeff" <fyberoptic1979@...>
Aug 21, 2007
So since I can hook/replace the interrupt fairly easily via
software,
I t=
hought it might be worth trying to hook the startup procedure
too. This w=
ay one could test code that they might one day decide to
flash onto codefl=
ash page 0, without so much of the risk to bricking
the thing by a silly m=
istake. Only problem is that this of course
means flashing it to some deg=
ree in order to place the hook.
There appears to be 33 empty bytes at the =
start of page 0. Now I
know that these are probably left that way in cas=
e a RST command is
sent. But are these ever even used by the MS? That se=
ems to be the
real kicker here. If at any point they do get executed, I'd=
be in
trouble. We know it sets interrupt mode 1 at startup, so at least =
they'd never get triggered in that manner.
But, assuming they're never us=
ed, it should be easy to make a
signature test on a section in ram, and if=
it verifies, then you
jump
to your code in ram. If the bytes didn't ver=
ify, then normal
Mailstation startup would carry on instead. This means y=
ou could
use
a normal Mailstation Yahoo-style app to load your code, then=
as long
as the power was never removed, your code should remain intact un=
til
overwritten or power is lost. So you'd be able to reboot the MS and
=
test your startup code, and if for whatever reason it had a problem,
you'd=
just have to pull the power to kill the ram contents.
33 bytes isn't a lo=
t to work in, but it seems to be enough with a
couple to spare for doing a=
three byte signature. The MS only does
two bytes for checking its own da=
ta at startup, but since this is
code, I figure three might be better. Wh=
o knows! I mostly just
decided on three to use my initials. ;) I figure=
this should do
the
trick:
org #0000
di ; disable interrupts, in=
case
we jump here
ld a, 1 ; set ram page 1 into
slot8000
out (#08=
), a
out (#07), a
ld hl, #8003 ; Test first byte
ld a, SIGBYTE1
cp =
(hl)
jr nz, code_end
inc hl ; Test second byte
ld a, SIGBYTE2
cp (h=
l)
jr nz, code_end
inc hl ; Test third byte
ld a, SIGBYTE3
cp (hl)
=
jr nz, code_end
jp #8000 ; Code seems good, jump to
it
code_end: =
; Code not valid, normal boot
This fits into 30 bytes. It assumes you =
load your code at #8000 on
ram
page 1 on slot8000, with a JP taking the f=
irst three bytes, and then
the next three being your signature. But that =
can be changed around
to suit one's needs of course.
But again, the worry=
is the RST bytes. If I fill them up, and then
it executes one at some im=
portant point, I might possibly have
bricked it. So I'm mostly wondering =
if it was ever confirmed as to
their usage. It just seems like there'd re=
ally be no reason for them
to ever do so, considering they can jump to #00=
00 for the same
effect.
From: "Jeff" <fyberoptic1979@...>
Aug 21, 2007
Holy cow, my formatting didn't look messed up like that in the
preview! H=
opefully the message still makes sense.
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 21, 2007
Holy cow, my formatting didn't look messed up like that in the
Hopefully the message still makes sense.
Not quite wysiwyg, huh??? :-)
=
On the group web site there is (now) an option to view
messages with a fix=
ed-width font, which puts the
message inside <pre> </pre> tags.
That will=
make columns line up again.
To bad you can't just select that when you po=
st.
But if you use the rich text option to compose a
message, I think you c=
an force message to keep
cols lined up.
It used to be you had to hit reply=
button, and
quoted msg would have the cols lined up in the
reply box. So=
Yahoo has always been keeping
the original (correctly formatted) text. It=
's
just that they assume formatting does not matter,
a bad assumption, part=
icularly on a programming
oriented group!