From: "Jeff" <fyberoptic1979@...>
Aug 25, 2007
So while we have some very detailed info on many of the Mailstation
ports,=
there's still a lot we don't know. So I decided to just poke
around, and=
found a bit of stuff that was interesting, and some not
so much, but coul=
d lead to more later. HERE GOES:
These three ports were assumed to contr=
ol the RTC, but I'm thinking
they control a hardware timer.
Port #1d
- S=
etting bit 2 triggers interrupt 5 (not sure why yet)
- Setting port to #FF=
only reads back as #0F
Port #1e
- Set to #FF returns 0
Port #1f
- Sett=
ing bit 1 freezes Mailstation (endless interrupt?)
After finding out that =
I could make very high-speed interrupt 5's
happen by fiddling around with =
#1d and #1f, I looked in the
Mailstation code, and they used some similar =
code to what I was doing
to make it happen:
xor a
set 2, a
out (#1d), a
=
ld a, #0e
out (#1f), a
ld a, #0c
out (#1f), a
With this, interrupt 5 hap=
pens repeatedly, and much faster than the
keyboard interrupt (which happen=
s 64 times a second), but I couldn't
measure it because time16 apparently =
stops working when this is in
progress. I tried to measure it inside the =
keyboard interrupt, but
it seemed to fluctuate so much that I couldn't get=
a result. I'm not
sure if that's due to the interrupt itself fluctuating=
, or perhaps
the cpu not being able to keep up to get a proper measurement=
.
However, I think that you're supposed to set an interval for this
someh=
ow. Maybe there's a bit somewhere that possibly makes P10-P1C
set timer l=
ength instead of RTC?
Port #0b
- Clearing bit 3 distorts the lcd in var=
ious ways, and makes it seem
to draw certain columns in different places t=
han usual. Bits 0-2
seem to affect how it does this. I have no idea what=
this is doing
at the moment, but it makes the LCD pretty much unusable.
=
- Clearing bit 7 turns off LCD
Port #0d (CPU clock rate control)
- Setti=
ng bits 0-2 makes it run noticably slow. Variations seem to
make it simil=
arly slow. I'm positive that this is slower than 8mhz.
Could be 4, or ev=
en less. I'd have to come up with some sort of test.
Port #2f
- Setting=
bit 2 makes odd speaker noise + LED flicker (I thought I
clocked somethin=
g too high and burned up a chip or something at
first!)
- Setting bits 4,=
6 makes time16 interrupt 2x slower (kbdmax =3D 128)
- Setting bits 5,6 mak=
es time16 interrupt 4x slower (kbdmax =3D 256)
- Setting bits 4,5,6 makes =
time16 interrupt 8x slower (kbdmax =3D 512)
- When bit 6 is clear, but 4, =
5, or both are set, time16 interrupt
doesn't seem to ever occur.
kbdmax i=
s the variable I used before to detect how many times
interrupt 1 (keyboar=
d handler) occurred in between time16's.
Normally, kbdmax has a value of =
64 when a time16 interrupt occurs,
just for reference with the above.
The=
following info regarding port #2f was found in codeflash page 3,
in a fun=
ction at #4349:
- Bits 6,7 are enabled by firmware when it sets the port
=
- Bits 0-2 are cleared by firmware when it sets the port
- Bit 3 is passed=
along from p2Fshadow
So basically, 11xxc000, where xx bits controls how m=
uch to slow down
time16, while c is unknown to me. I'm not even sure what=
use this
port is, since changing the cpu speed doesn't seem to affect the=
interrupt speeds.
Here's some slightly useless info for the moment, bu=
t it shows that
some of these are quite possibly used for something:
Port=
#0c
- Setting #00 returns #05
- setting #FF returns #E3
Port #20
- Set=
ting #FF returns #40
Port #29
- Setting #FF returns #0F
These seem enti=
rely useless:
Ports #04, #22-27, #2a, #2b, #2e
- Setting #FF returns #00
=
And these seem to just not be connected to anything at all:
#30 - #50
-=
returns value of port itself
I stopped testing at #50, but I assume all t=
he rest to #FF do the same
From: "Jeff" <fyberoptic1979@...>
Aug 29, 2007
Don't mind me, I'm just rambling things in hopes that it might make
sense =
to someone smarter!
c1979@...> wrote:
ious ways, and makes it
seem
s than usual. Bits 0-2
what this is doing
able.
Forget what I said here about b=
its 0-2 affecting what bit 3 does,
because I don't really believe that for=
sure now. Particularly since
I discovered what bits 0 and 1 are doing, a=
t least.
When I disable bit 0, keys on keyboard row 8 stop responding. No=
w of
course my determination of them not responding is whether the MS
key=
scan function via the interrupt returns anything from them. Since
it's fl=
ipping the rows on and off and such, who knows how that could
interact wit=
h what bit 0 is doing here.
When I disable bit 1, keyboard row 9 stops res=
ponding. Again, a more
conclusive test would have to be done as to whethe=
r it's entirely
killing that keyboard row, but it certainly stops working =
in my
initial test.
Bit 2 doesn't seem to have any effect on the keyboard=
.
Bit 3 still causes the screen to go wonky.
Bit 7 still causes the LCD g=
o off.
Then I realized, where does this sound familiar? Yep, port 2! I
=
thought maybe this was just a mirror of that port. Bits 0, 1, and 7
certa=
inly seem similar in function. But no, when I tried to enable
the LED via=
bit 4, it didn't work. I even tried a direct test with
interrupts disabl=
ed, in case it was flipping the bit around in the
interrupt too fast to se=
e if the light was on. It never came on, no
matter which way I set the bi=
t.
So I dunno really. Reading back port 0x02 while FyOS is running
shows=
me 0xac, while reading back 0x0b gives 0xff. Maybe they're not
as relate=
d as I thought. But it certainly seems to have some similar-
looking funct=
ionality at this point.
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 29, 2007
use I don't really believe that for sure now. Particularly since
overed what bits 0 and 1 are doing, at least.
ys on keyboard row 8 stop responding. Now of
them not responding is whether the MS
t returns anything from them. Since
nd such, who knows how that could
.
e
illing that keyboard row, but it certainly stops working in my
est.
still causes the screen to go wonky.
f.
=
ertainly seem similar in function. But no, when I tried to enable
ED via bit 4, it didn't work. I even tried a direct test with
s disabled, in case it was flipping the bit around in the
fast to see if the light was on. It never came on, no
I set the bit.
s running
're not
milar-
There is speculation found =
here
(URL)
RD_3SI176_0A.txt
that port #0B is the DDR for port #02.
Keep in mind that=
you can't necessarily expect to be able to
read back the last value you se=
nt to a port. Sometimes the
"in" and "out" for a particular port address =
are even used for
different functions, such as with port #01, where "out" d=
rives
the keyboard rows, but "in" reads the keyboard columns.
That's why t=
hey keep all those "shadow" vars.