From: "Jeff" <fyberoptic1979@...>
Aug 3, 2007
After finally realizing the simplest of bugs which was keeping my app
to t=
ransfer code from the pc to mailstation ram from working (didn't
realize 1=
6-bit dec didn't set the zero flag, doh), I've finally
gotten to mucking a=
round much more. Particularly since it doesn't
require typing in hex code=
anymore!
But I found something strange. Basically, with interrupts disab=
led,
whenever I have the LCD set to accept the current column with the cas=
bit in port 2, and then write my column, the lcd goes blank. When I
wri=
te to it without cas, it just kind of flickers I think. But
commenting ou=
t that simple 'di' instruction makes everything work
like a charm again.
=
More tinkering seems to reveal that I can still update the screen and
ever=
ything behind the scenes, then when I reenable interrupts again
afterwards=
, the screen shows up again properly, with all the data I
set while it was=
"off".
Anyone know why the lcd goes away without'em enabled?
From: "Jeff" <fyberoptic1979@...>
Aug 4, 2007
I thought this was LCD-related enough to reply to my own topic. The
circl=
ed emoticon is coincidentally pretty much the expression I had once
I was f=
inished writing the code both to convert the original CGA 8x8
font into an =
assembly include file (thanks to Perl). =A0That, as well
as all the other h=
ours of code on the PC and Mailstation side today in
order to easily transf=
er code back and forth, to allow me to start
writing LCD routines for a tex=
t mode (to use less ram for a video buffer
than in "graphics" mode).
Anyho=
o, I got a chuckle out of it, nonetheless!
rcled emoticon is coincidentally pretty much the expression I had once I wa=
s finished writing the code both to convert the original CGA 8x8 font into =
an assembly include file (thanks to Perl). =A0That, as well as all the othe=
r hours of code on the PC and Mailstation side today in order to easily tra=
nsfer code back and forth, to allow me to start writing LCD routines for a =
text mode (to use less ram for a video buffer than in "graphics" mode).<BR>=
://www.fybertech.com/lab/mailstation-O_o.jpg"><BR><BR>
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 5, 2007
After finally realizing the simplest of bugs which was keeping my app
transfer code from the pc to mailstation ram from working (didn't
ze 16-bit dec didn't set the zero flag, doh),
Computers can be awfully ni=
t-picky, can't they? :-)
more. Particularly since it doesn't
I'm working on an app that will load other apps, if I get
enough time th=
is weekend....
ts disabled,
th the cas
When I
e a charm again.
Are you using the port 2 shadow var???? And, it just occ=
ured
to me as I typed that, I don't know if we know it's address in
3.03a. =
Port 2.7 needs to be "1" to keep the LCD on.
eveal that I can still update the screen and
s, then when I reenable interrupts again
again properly, with all the data I
While ints=
are disabled, the mailstation gears pretty much stop
turning. After you =
reenable them, it won't be long till ms writes
something to port #02, and i=
t will use the shadow that has
bit 7 set??? Just a guess.
why the lcd goes away without'em enabled?
I don't particulary recall this =
behavior, and I do think I
have had display on while ints were disabled.
-=
-CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 5, 2007
I thought this was LCD-related enough to reply to my own topic. The
cled emoticon is coincidentally pretty much the expression I had once
He l=
ooks as if he has been staring at tiny pixels for too long, kinda
bleary ey=
ed???
x8
as all the other hours of code on the PC and Mailstation side today in
der to easily transfer code back and forth, to allow me to start
LCD routines for a text mode (to use less ram for a video buffer
"graphics" mode).
I uploaded a rendering of the ms fonts and icons.
http:/=
/tech.groups.yahoo.com/group/mailstation/files/Mailbug/253yr/
The fonts ar=
e probably mostly the same, if not exactly, for
all versions???? There's=
both an eMessage icon, and Mailstation
icon in this 2.53yr rom.
I also r=
ecently uploaded some assembler code to
(URL)
/mailstation/files/Mailbug/include/
There is code for the "tribble link" i=
nterface, and another
file with a bunch of equ's for the ms firmware routi=
nes
that I have been using, and some scrolling text output code, too.
Hey,=
how did you embed the graphic??? I didn't think we could
post html to the=
list?
From: "Jeff" <fyberoptic1979@...>
Aug 5, 2007
Jones" <cyranojones_lalp@...> =
wrote:
=
Port 2.7 needs to be "1" to keep the LCD on.
led, the mailstation gears pretty much stop
them, it won't be long till ms writes
use the shadow that has
I'm not using t=
he shadow bit (which is at 0xDBA5 on 3.03a), but I
made sure to set all th=
e bits correctly when writing to port 2. The
LCD bit is kept on at all ti=
mes. As I said before, the screen
doesn't actually go off until I attempt=
to write the current column
to the LCD during cas. Until I do that, the =
LCD is still on, even
after I setup port 2 and cas, and even with interrup=
ts disabled.
It's just when writing the column that makes it turn off whe=
n the
interrupts are disabled. When I remove only the "di" instruction
f=
rom my code, it all works just fine again. This is why it doesn't
make se=
nse to me.
I thought about trying to use my trick to steal the interrupt r=
outine
and just immediately ei/reti without handling anything, just to see=
if it's something in there causing it. Maybe I'll also try using the
sh=
adow bit, just in case. Anything's worth a shot.
Also, speaking of the LC=
D, it seems the list I had been using of
Mailstation devices (from I-Appli=
ance) isn't quite accurate. It says
device 2 is the right half of the LCD=
, and the left half is device
4. It appears to be the opposite, from my e=
xperience. I also
checked the disassembled code of the three firmware ver=
sions I know
of, and it seems to be the same across the board. Device 2 i=
s the
left half, updated from the buffer at 0xC010, and device 4 is the
r=
ight half, updated from 0xCA10.
From: "Jeff" <fyberoptic1979@...>
Aug 5, 2007
Jones" <cyranojones_lalp@...> =
wrote:
ch.groups.yahoo.com/group/mailstation/files/Mailbug/253yr/
re probably mostly the same, if not exactly, for
e's both an eMessage icon, and Mailstation
Ah =
that's a nice list. It makes me ponder trying to replace the big
CIDCO lo=
go with one of my own. Though it seems I don't start up my
Mailstation no=
rmally enough to see that logo most times. I almost
always end up doing a=
"hard" restart, either by pulling the
batteries, or jumping to 0x0000. I=
n the test code I've been working
with, for example, after it does its mai=
n task, it goes into a loop
where it just constantly checks for new keyboa=
rd scancodes. If it
detects #1 (the Back button), the loop ends, and it j=
umps to 0x0000.
I'm not really sure yet how to "properly" restart the Mai=
lstation via
software, to get the logo and all. I always end up at the sc=
reen
asking me if I want to erase the flash memory. I assume during
shut=
down, the Mailstation is setting some value to designate that it
was turne=
d off properly via the power button, and when you turn it on
next, it's ch=
ecking if that was set.
to
includ=
e/
with a bunch of equ's for the ms firmware routines
g, and some scrolling text output code, too.
More code to look through is =
always useful!
we could
Well when I'm typing a message here =
on the Yahoo Groups page, there's
something along the top just above the "=
To:" field that says "New!
Compose your message with Rich-Text Editor (Bet=
a)". I realized I
couldn't embed images here, so I clicked that. It take=
s you to a
different text entry form, with a checkbox at the bottom below =
the
message body area. When clicked, it puts your messages into raw html =
mode. I went in there just long enough to add my img tag.
From: "Jeff" <fyberoptic1979@...>
Aug 5, 2007
Welp, I tried using the shadow byte, and crazily enough, it worked
fine wi=
th interrupts disabled.
The values I was originally writing straight to po=
rt 2 were 0x93 to
start CAS (turning bit 3 off), then writing my column ad=
dress,
followed up by writing 0x9B to port 2 to toggle CAS back.
Assuming=
this is still all accurate:
7-lcd_on, 6-callid_data, 5-not_modem_power, 4-=
yougotmail_LED, 3-
LCD_cas, 2-callid_data_rdy, 1-keyrow_9, 0-keyrow_8
The =
0x93 I wrote is 10010011. lcd_on is obviously enabled. I was
also turnin=
g on the LED to know when I got to this point. Bits 0 and
1 are high beca=
use that's where the interrupt routine keeps them, and
only pulls them low=
when reading from that row of the keyboard
matrix. 0x9B is 10011011, wit=
h the only difference being the CAS bit.
Oh ho! I just found something! =
Instead of the values I had been
writing, I decided to write 0xF7 (111101=
11) to start CAS, wrote my
address, then wrote 0xFF (11111111). It worked=
fine! I then traced
it down to exactly which bit needed to be on: bit 5=
. If bit 5 is
not on when you write your column address during cas, the L=
CD goes
off. Why do you suppose that is??
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 6, 2007
lso, speaking of the LCD, it seems the list I had been using of
ion devices (from I-Appliance) isn't quite accurate. It says
s the right half of the LCD, and the left half is device
to be the opposite, from my experience.
I made a "datasheet" for the cpu=
, and updated it with your info,
and also formated it a bit nicer.
(URL)
tech.groups.yahoo.com/group/mailstation/files/part%20files/RSDRD_3SI176_0A.=
txt
I added some info on the RTC ports, and fixed another mistake
while I =
was at it (+6 volt good and +5 volt good were reversed
on the pinout).
Th=
ere are two bits that relate to battery state, I think one is
"battery gett=
ing low", and other "battery is almost dead".
They might be reversed, I'm=
not sure which is which.
-CJ
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 6, 2007
almost
Wh=
y noy just return? If you are running your app from the
menu, then I gues=
s your whole prog runs when it receives
the "init" event. So, to prevent i=
t from running again
for every event the ms sends (I think there will be at=
least
3 or 4???) you would want to check the sig param, and
just return i=
mmediately on any other sig.
test code I've been working
ask, it goes into a loop
d scancodes. If it
jumps to 0x0000.
Why not check for a "back key" event, and handle it, to=
o?
king me if I want to erase the flash memory. I assume during
the Mailstation is setting some value to designate that it
f properly via the power button, and when you turn it
ing if that was set.
If jp #0000 gives that menu even with batteries in, t=
hen you
probably do need to set a state var, and it is prob that first
var =
that is saved in the routine called "Init" on your disassembly.
I'd tell yo=
u the location, but it might be different on your 3.03a.
Try setting that =
var to #5A before reboot. The "moreinit"
routine checks for that value, an=
d sets a different "app mode"
depending if that var was #5A. I don't know =
what the difference
is, though. Maybe it is whether or not you get that me=
nu (seems
like a good guess).
If that doesn't work, I just don't know what=
else is involved.
When I run code from mailbug, I end with a ret. If all=
goes
well, mbug gets control again, and I can issue more commands.
Otherwi=
se, I hit the reset button (I leave a jeweler's screwdriver
sticking out of=
the reset hole, 'coz I need to hit it often!)
I rarely have batteries ins=
talled, and I thought that was why
I was seeing that message all the time.
=
Another thought I just had was that the mailstation does not boot
up from =
scratch when you turn it on with power button. That's
because it doesn't r=
eally shut off when you push power button.
It just goes to sleep. So, when=
you push button to "turn it on"
you are really just waking it up. Maybe i=
t always asks that
question when it boots up from #0000?
essage with Rich-Text Editor (Beta)". I realized I
s here, so I clicked that. It takes you to a
with a checkbox at the bottom below the
d, it puts your messages into raw
Cool! I've used the rich=
-text mode, just never noticed that
checkbox!
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 6, 2007
Welp, I tried using the shadow byte, and crazily enough, it worked
with interrupts disabled.
to port 2 were 0x93 to
olumn address,
_modem_power, 4-yougotmail_LED, 3-
, 0-keyrow_8
d. I was
s 0 and
, and
matrix. 0x9B is 10011011, with the only difference being the CAS bit.
Bot=
h those values are turning the modem on, too. Bit 5 is
active-low.
o! I just found something! Instead of the values I had been
decided to write 0xF7 (11110111) to start CAS, wrote my
rote 0xFF (11111111). It worked fine! I then traced
which bit needed to be on: bit 5. If bit 5 is
our column address during cas, the LCD goes
t is??
Maybe there is a bus conflict if the modem is on when you are
tryin=
g to talk to LCD??? Just why it goes away if int's are
enabled is a bit o=
f a mystery.
From: "Jeff" <fyberoptic1979@...>
Aug 7, 2007
Jones" <cyranojones_lalp@...> =
wrote:
p/mailstation/files/part%20files/
RSDRD_3SI176_0A.txt
o on the RTC ports, and fixed another mistake
good and +5 volt good were reversed
its that relate to battery state, I think one is
nd other "battery is almost dead".
which is which.
Hey awesome, I was wondering if anyone had dis=
covered what any more
of the ports were for yet. Those RTC ones should be=
of use for
something or another.
From: "Jeff" <fyberoptic1979@...>
Aug 7, 2007
Jones" <cyranojones_lalp@...> =
wrote:
nu, then I guess your whole prog runs when it receives
So, to prevent it from running again
nk there will be at least
m, and
for a "back key" event, and handle it, too?
I pretty much have tried to=
avoid depending on all Mailstation
functions as much as possible, particu=
larly its whole message loop
system. The only thing I'm currently dependi=
ng on with code I'm
working on is getkeycodefrombuffer, until I write a ro=
utine to handle
scanning the keyboard matrix myself. Seems easy enough, I=
just
haven't gotten around to it, from trying to deal with text output
f=
irst.
I've gotten routines in place for a decent text-mode interface, with=
a 640-byte buffer to hold 40x16 characters. I can either write to
the m=
emory buffer and then run a routine to update it all at once, or
I can upd=
ate it one character at a time (which also writes to the
buffer, but is be=
tter for printing strings instead of updating the
whole display). It also=
tracks the cursor x/y position to know where
to put the next character.
=
I just need a routine to map scancodes to keys, track whether shift/
caps l=
ock is on, etc, and I'll have my own basic i/o routines to work
with.
Act=
ually I just remembered, I just recently started using a second
Mailstatio=
n function: powerdownmode. I tried emulating what it's
doing, but someti=
mes the thing just resets instead of fully staying
off. Haven't figured t=
hat out yet. It certainly appears like bit 1
of port 28 seems to play an =
important part in shutting down, though.
But now, Back resets me to #0000=
, while the power button turns it
off. Pushing any other button prints it=
s scan code (and status of up/
down/shift/capslock below), and prints the a=
scii representation of
the scancode on the screen (and incrementing the cu=
rsor position
along the way). This will be neater when it's actually disp=
laying
the corresponding letter to the key I'm pressing!
As mentioned bef=
ore I think, I was trying to stray from using
Mailstation code when possib=
le so that I never have to rely on any of
it in the event that I replace i=
t. Relying on Mailstation code also
means relying on where it locates thi=
ngs in ram, and trying to avoid
writing over any of it.
gives that menu even with batteries in, then you
a state var, and it is prob that first
called "Init" on your disassembly.
t be different on your 3.03a.
t. The "moreinit"
pp mode"
a good guess).
Yeah this was something I found out when reading over that =
nice
disassembled/commented page 0. I can't try it until I find out the
=
v3.03a location though, as you mentioned. But if I'm possibly
messing up =
"important" Mailstation ram at some point, I wonder if
it's really safe to=
let it think the system is still okay by slipping
the #5a in myself, or i=
f I should just intentionally let it reboot
completely.
I actually think =
it's faster anyway, since the Cidco logo takes a
second go to away, where =
as I just need to tap enter to get past the
other one.
ode from mailbug, I end with a ret. If all goes
again, and I can issue more commands.
I leave a jeweler's screwdriver
ed to hit it often!)
I saw that button when I was messing with it the othe=
r day, but
wasn't sure just what exactly it might do if I press it. I did=
n't
want to go and erase the dataflash or anything.
atteries installed, and I thought that was why
all the time.
not boot
=
goes to sleep. So, when you push button to "turn it on"
ust waking it up. Maybe it always asks that
rom #0000?
I've used the same set of batteries in it since I first started=
mucking around, and I only once saw a low battery warning at startup,
an=
d that was when I forgot and left it running for a few minutes in
an app I=
was testing (since no auto-shutoff). It's surprisingly good
on batteries=
, especially considering it never truly goes off. I
still haven't replace=
d them, either.
This also means the ram retains its contents, which could =
be a useful
method of code storage. A ram drive, of sorts. Would let you=
avoid
writing to the flash unless necessary.
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 8, 2007
've gotten routines in place for a decent text-mode interface, with
0-byte buffer to hold 40x16 characters. I can either write to
y buffer and then run a routine to update it all at once, or
e it one character at a time (which also writes to the
tter for printing strings instead of updating the
so tracks the cursor x/y position to know where
r.
That's sounds pretty cool. :-)
I have wondered myself if the lcd buff=
er provids any real benefit,
or if it was just there to let the progrmmers =
defer thinking about
how to get image on the screen (possibly defer to ano=
ther team?).
I don't see any particular timing issue.
For that matter, t=
he ms code doesn't even copy directly from
the font data to lcd buffer. E=
ach character is copied to a
"char buffer", and then copied to the lcd buf=
fer. Seems like
it would be much more efficient to just copy from font di=
rectly
to lcd, and skip both buffers!
codes to keys, track whether
y own basic i/o
Keyboard events have both scanco=
de and ascii fields.
Why reinvent the wheel? :-) :-) :-)
y I just remembered, I just recently started using a second
function: powerdownmode. I tried emulating what it's
mes the thing just resets instead of fully staying
that out yet. It certainly appears like bit 1
an important part in shutting down, though.
If you look at the code for=
"powerdownmode", it is bit 0
that shuts it off. Oh wow! I was just look=
ing at the
disassembly. I thought you were saying "powerdown" which
is a=
t 1AC0 in 2.53yr.
"powerdownmode" is just a wrapper that sets bootstate to=
5A,
and then calls "powerdown"!!! I didn't even remember that
was there=
, but I must have seen it, 'coz I named it! There
is just too much to rem=
ember about this thing. :-)
And, unlike "powerdown" , which might float a=
round in
different versions, "powerdownmode" has one of those handles
in =
that real long jump table.
So, I bet you can call powerdownmode at #0A6B =
in all versions.
I seem to recall that jumptable is at same address in th=
e
versions I looked at.
But what I started to say was, if you look at the=
code for
"powerdown" @1AC0 in the 2.53 disassembly, you'll see that
it i=
s toggling P28.0
P28.0 is connected to the power control flip-flop (74c74 =
chip)
via a 600 ohm resistor. I don't completely understand circuit,
ther=
e are several caps and resistors, and 2 stages of D type
flip-flop, but the=
gist of it seems to be that a pulse on
P28.0 sets the flip-flop to the "p=
oweroff" state, after a
short delay. I think the delay is there to give c=
pu time to
execute up to the "halt" inst before removing power from the
c=
odeflash chip. (I'm talking about RC time-constant delay
of pulse, NOT th=
e delay loop in the code. That delay loop
is just timing the pusle width.=
) I don't know if the cpu
loses power here or not.
I made a mistake when=
I identified callid dataclock as
P28.2, it is really P28.1. The "xor 02=
" instruction
is flipping bit 1, but my brain seems to have trouble
grasp=
ing that, and wants to call it bit 2. That led to
all the P28 bits being =
jogged over 1 bit. I changed the
datasheet in groups file section, eventu=
ally I need to
update linux-hacker, too.
00, while the power button turns it
s its scan code (and status of up/
the ascii representation of
g the cursor position
ually displaying
So, =
what is ascii code for F1 key??? We had a rather
short thread on that sub=
ject 2 years ago (holy crap,
2 years???). I came to conclusion nobody her=
e really
cared about pursuing "getchar()".
(URL)
oup/mailstation/message/392
The "moreinit"
pp mode"
ce
like a good guess).
ver that nice
d out the
's really safe to let it think the system is still okay by slipping
#5a in myself, or if I should just intentionally let it reboot
y.
I was just now looking to see where "powerdownmode" is
called. It is =
from keyscan, which I guess makes some
sense, if you think of powerbutton =
as a special "key".
I'm not really sure offhand what happens at poweron, =
though. Does it continue from the "halt", or start
over at #0000? I nee=
d to look at databook, and it's
not handy right now.
How much ram do you =
need? The lcd buffer is 5k, and you
reduced yours to 640 bytes, so you go=
t 4.4k right there.
The modem buffer is where I have been sticking the mb=
ug
code. That should be safe, as long as modem is not used.
Did you see =
the RAM "disassembly"? It's not really
disassembly, but I put some notes=
in the comment file
for rampage #00. (ms always has rampage #00 mapped
=
into slotC000.)
I also tagged the data types by hand for the vars that =
are known.
(URL)
53yr/ms253yr_80.html
Then there is the stack. You can allocate space for=
*any* routine that needs local vars, by just calling
the same routine th=
at the compiled c code uses. I
named it "localize" in the disassembly, be=
cause it
was creating a local context for each function.
In addition to al=
locating stack for local vars,
it also saves all the regs for you.
You =
just load DE with number of bytes you need for
locals, and call localize. =
Then you can access your
locals relative to the stack pointer.
The fir=
st local byte is at sp+8. Any params are at
sp+8+n+4 (iow, last local ad=
dr + 5).
The cleanup is automatic, your code just needs to "return".
saw that button when I was messing with it the other day, but
e just what exactly it might do if I press it. I didn't
erase the dataflash or anything.
It just asserts the CPU's reset pin, so p=
retty much
the same as power cycle, or "jp 0000" . I think reset
also se=
ts i/o ports to initial state (0 for most???),
but they all get init befor=
e use anyway, no matter
which of the 3 methods you use.
From: "Jeff" <fyberoptic1979@...>
Aug 14, 2007
Jones" <cyranojones_lalp@...> =
wrote:
efit,
don't see any particular timing issue.
Well from my experience, it would p=
robably be slower to write
directly to the lcd all the time, because of th=
e math involved to
translate pixel coordinates. You have to figure out wh=
ich lcd device
to swap into the slot, which column you need to activate, t=
hen which
row inside of there to write the bit to, and then which bit insi=
de
the byte is the particular pixel you're wanting to change. You then
h=
ave to pretty much do these calculations for all the pixels you're
writing=
, because you don't know when one will cross into another
column, or even =
into the other lcd device.
The math to just draw this stuff on a buffer wi=
th standard x/y
coordinates would be simpler, and then doing one big incre=
mental pass
across the lcd columns/devices after you've drawn all you need=
to the
buffer would likely take less time in the long run.
This is parti=
ally why I chose an 8x8 font size to work with in what
I've been messing w=
ith, because it's always aligned to a particular
lcd column. I just have =
figure out which column the character needs
to be written to, and then the=
starting row inside of there, and dump
8 bytes of font data in.
r that matter, the ms code doesn't even copy directly from
to lcd buffer. Each character is copied to a
opied to the lcd buffer. Seems like
just copy from font directly
I didn't qu=
ite get this at first either, but then I realized that it
probably makes s=
ense for when they're wanting to modify the text in
some way. Particularl=
y to invert the color. You wouldn't really
want to try and invert the fon=
t once it hit the actual lcd buffer,
cause you might invert bits to other =
graphical data around/underneath
the character you just wrote.
oard events have both scancode and ascii fields.
? :-) :-) :-)
Well, I did finish my routines to scan the matrix, det=
ect changes,
and put the scancodes of those changes into a buffer. But th=
en I
found that certain letters on my keyboard are twitchy and sometimes
=
trigger too many presses/depresses. I then realized that all the
extra st=
uff the MS code was doing was likely debouncing the keys.
Since I'm almos=
t tired of just writing keyboard routines for now (and
have gotten distrac=
ted away from it lately as well), I'm thinking I
might just pull all their=
routines I need out for now and put them in
my own code to possibly be re=
written later, so that I can move onto
more interesting stuff.
The proble=
m with just leaving them in the Mailstation code is the
page swapping requ=
ired to get to them. One of those "wormhole"
functions in page 0 might he=
lp keep it from being a problem in some
respects, but if I ever tried to h=
ijack the interrupt for example, it
could be a problem yet again. So I'd =
prefer to just keep my own
pages activated when possible, by just copying =
out their code.
r
I came to conclusion nobody here really
.
Back in =
my DOS days I seem to remember that pressing any of those
sorts of keys (s=
uch as the arrows) would produce two bytes out of a
getchar type of functi=
on. The first byte was a particular value to
indicate an extended key, an=
d the following byte would indicate which
button.
I wrote a brief C progr=
am just now using getch() (not getchar, since
it waits for enter to be pre=
ssed) to see the values, and pushing F1
gets me 0,59 for example. Pushing=
up gets 224,72. F1-F10 always
return a 0 first, and F11-F12 and the othe=
r buttons (arrows, home/end/
etc) always return a 224 first, it seems.
rs to 640 bytes, so you got 4.4k right there.
I have been sticking the mbug
dem is not used.
Well my intention was to preferably have the entire up=
per 32K as ram
for my own use (OS, running applications, etc). That'd bas=
ically
make a 32k machine, while using slot4000 for paging the lcd/datafla=
sh/
ram (for a ramdrive perhaps) for I/O. It also works out well to
start=
the OS code at the 32k point, because then if I ever tried to
convert any=
CP/M apps, for example, I'd mostly only need to toggle
the upper address =
bit in any spots where they accessed memory.
I only wish I knew more about=
when an NMI interrupt hit, because if
it rarely or never happens aside fr=
om like modem use (which I'll
never use), then I could use all the page 0 =
ram without worry, by
just turning off maskable interrupts, or hijacking t=
he routine.
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 15, 2007
...
e, it would probably be slower to write
, because of the math involved to
Yeah, I realized that about half a seco=
nd after I sent that.
I just meant I don't think there is any need to sync=
hronize
writes with any video-like timing (retrace), or any wait states
gen=
erated.
When painting whole screen, it can be faster to use buffer,
partic=
ularly if you are doing graphic stuff, like line drawing.
But if you are d=
isplaying text, I don't think the overhead of
accessing the LCD directly i=
s that big a deal, compared to
copying the whole screen, particularly if yo=
u are just updating
a small area, such as a "writeln". You would just hav=
e the
X coord overhead once per char, (with your 8x8 font).
If you were u=
sing proportional font, you could buffer two 8x8
or 8x11 pixel areas, and =
copy each to LCD after curor moves past.
That would save the 5KB used for =
current LCD buffer.
Also, scrolling the LCD would be faster directly on =
LCD. And
clearing screen, too. (But the question may be moot, see below.=
)
e font data to lcd buffer. Each character is copied to a
", and then copied to the lcd buffer. Seems like
e efficient to just copy from font directly
ers!
it
t to try and invert the font once it hit the actual lcd buffer,
u might invert bits to other graphical data around/underneath
ter you just wrote.
I think I figured out an even better reason for what a=
t first
seemed like a lot of needless copying, not only in LCD routines, bu=
t
a lot of other places: The bank switching!!!
Since they chose a banking=
scheme where the codeflash, dataflash,
and LCD (and modem, too) all use sl=
ot4000, you can't copy
directly between two of them! Same problem as my or=
iginal
helloapp had with the foldertabtext. :-)
both scancode and ascii fields.
:-)
,
ound that certain letters on my keyboard are twitchy and sometimes
er too many presses/depresses. I then realized that all the
the MS code was doing was likely debouncing the keys.
Yes. Debouncing. =
And probably key repeat. All free!!! ;^)
...
aving them in the Mailstation code is the
to them. One of those "wormhole"
from being a problem in some
e interrupt for example, it
to just keep my own
their code.
I'd have to check to be sure, but I think the keyboard code mi=
ght
all be in page 00?
And, even if you do want to use a function from one=
of the higher
pages, you don't need to do the bankswitching, you just cal=
l them
through the handles in page 00, and the bankswitching is done for
yo=
u, including puting your page back before they return.
But, as we have see=
n recently, it does pay to be aware of the
fact that slot4000 is not fixed!=
!! :-)
I seem to remember that pressing any of those
arrows) would produce two bytes out of a
first byte was a particular value to
following byte would indicate which
I think pascal (well, turbo=
& freepascal, at least) rets a 0 for
the first byte of extended codes. I =
just could not find any docs
for c that said what it returned. Maybe it i=
s not part of c, but
rather part of your particular OS spec???
a brief C program just now using getch() (not getchar, since
r enter to be pressed) to see the values, and pushing F1
r example. Pushing up gets 224,72. F1-F10 always
F11-F12 and the other buttons (arrows, home/end/
4 first, it seems.
I didn't even know the right name. I have been away fr=
om c for
quite a while. (hey, "away from c", does that make me a landlubbe=
r???)
I used it in school a bit, and again when I started using Linux,
but=
I was not impressed with it's compile speed (gcc). Perl was
a lot more fu=
n!!!
I have recently been re-learning c, though (winavr). I think my
com=
puter is faster now, and maybe my programs are smaller, too.
ram do you need? The lcd buffer is 5k, and you
ytes, so you got 4.4k right there.
een sticking the mbug
not used.
er 32K as ram
sically
flash/
=
nvert any CP/M apps, for example, I'd mostly only need to toggle
er address bit in any spots where they accessed memory.
I see. You are go=
nna need to change the isr, then, either with your
nifty method, or reflash=
ing codeflash page 00 (unless your os can work
around the ram that existing=
isr uses).
ecause if
ll
just turning off maskable interrupts, or hijacking the routine.
My hunch i=
s there is no NMI, but I could be wrong.
I had thought about reflashing =
page 00 to put a hook into isr so I
could borrow it. Find a free RAM loca=
tion (maybe move stack down
4 or 8 bytes) and init it to "jp oldisr" (with =
a patch to init in
page 00). Then patch the existing jp oldisr in page 00=
to jump to
that new jp in ram.
But what I really need more than the ISR =
is to borrow one of the
"restarts", for the breakpoint mechanism. Not exa=
ctly rocket science.
just haven't got "a round tuit".
Probably 'coz I sp=
end too much timewatching stuff like this:
(URL)
oot.mov
From: "Jeff" <fyberoptic1979@...>
Aug 16, 2007
Jones" <cyranojones_lalp@...> =
wrote:
t
one of the higher
st call them
e for
Yeah t=
he keyboard stuff is in page 0, but the problem is that it
still uses piec=
es of ram way up in the C000-FFFF range. So I pulled
all the keyboard rou=
tines out of the disassembled listing, fixed them
up and re-labeled them s=
o that they'd assemble again, and created the
variables in memory where I =
wanted. But I'm having problems with
it.
The topmost function the inte=
rrupt calls seems to be the one at
0x2FE3 (keyscan). So I'm calling that,=
then calling my pulled
version of getkeycodefrombuffer, and looping these=
if it doesn't find
a key (which is how I did it with the built-in routine=
s before, just
minus the call to the 0x2FE3 one, since that's done in inte=
rrupt). I
can get the power and back buttons, since it handles them separ=
ately,
but it either doesn't read anything else, or reads a bunch of
gibb=
erish for a moment and then stops reading anything (aside from
back and po=
wer).
I'm calling my pulled init_keyboard and clearing a couple of the
va=
riables the functions use before I get there, but I dunno, maybe
I'm missi=
ng something. There might be some initialization called at
startup in pag=
e 6 of codeflash that I don't know about. I don't have
any commented vers=
ions of that page, so it's tough to go through.
I'm almost tempted to jus=
t forget it and write my own debouncing code
for what I already have. See=
ms like it might be easier at this point
than trying to debug that entire =
mess, unless you have any ideas.
n when I started using Linux,
peed (gcc). Perl was
I use Perl a lot myself since it=
's so easy to use, and generally
works fine cross-platform for testing and=
debugging and such
(depending on the modules). For C, I got that Dev-C++=
thing before
for Windows, but ended up not really caring for the GUI, so =
I just
setup the environment variables to it so that it's pretty much just=
back to basic gcc/g++ and 'make' from the command line. I keep it
all i=
nstalled since it has a package system in the GUI that lets me
update it a=
nd other libraries fairly easily.
could be wrong.
The keyboard routines seem to get called from an NMI (s=
ince NMI and
maskable interrupts apparently go to the same place), but I f=
ound
that I never get keyboard input (using the mailstation's built-in
fu=
nctions) with interrupts disabled. So you could be right, there
may just =
never be one, or never one unless using the modem or some
such thing that =
I'll never do.
into isr so I
ck down
hat new jp in ram.
I'm kind of afraid of trying anything like that, but=
it seems like
the best way to deal with doing anything with the thing in =
the long
run. I fear that I'll write code, but not take into account some=
sort of initialization aspect that the MS does, and then when my code
go=
es on there, it'll just be a brick.
I'm also not exactly sure what process=
I'd go about using to flash
any of it.
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 18, 2007
(keyscan). So I'm calling that, then calling my pulled
eycodefrombuffer, and looping these if it doesn't find
ow I did it with the built-in routines before, just
e 0x2FE3 one, since that's done in interrupt). I
back buttons, since it handles them separately,
ad anything else, or reads a bunch of
ops reading anything (aside from
That looks like right=
address in 2.53yr. I was wondering if
calling in a loop might not give e=
nough settling time for row
select? I can't look at it right now (won't be=
home till tues),
but does ms scan whole matrix each time 2fe3 is called?
=
Or just one row??? I seem to remember wondering why
row address was set w=
hen it was, and extra settling time
was my only guess as to why. If that =
is prob, maybe doing
a 1ms delay in your loop would help.
y pulled init_keyboard and clearing a couple of the
ons use before I get there, but I dunno, maybe
here might be some initialization called at
sh that I don't know about.
As far as I could see (I looked at keyboard =
code last night,
before I left) the keyscan vars are not init to anything b=
eyond
the zeroing of ram in init. The page 6 init relating to keyboard
is =
mostly for the reading of buffer, andconverting to key events.
They also en=
able keyboard int, which you wouldn't need, and
make a call to keyboard ini=
t, which you probably do need. I
am not sure what param is for, but they p=
ush #0000 on stack
before calling keyboard init. I think keyboard init is =
neccesary
for initing keybuffer.
of that page, so it's tough to go through.
That is next one I will post=
. There are some mistakes I was correcting,
and alway seems there is new d=
etails to add. The most interesting
stuff in page 6 is the event loop, and=
related queue, and event
generating.
Also, the app table is init there, a=
long with the widget stuff.
I did some experiments the other night, settin=
g bootstate =3D 5a
before jp 0, and it worked (didn't get the "memory testi=
ng", or
"reset system data" menu. AFAICT, the ram gets completely
zeroed e=
ither way, only difference is what app/screen you get to
on bootup (splash,=
or mem test). Seems the "ram valid" is
only used to determine if it will =
look at "bootstate" or not.
I wonder if the memory test is for the flash??=
? Seems like it must
be, if they are gonna init the ram either way???
'm kind of afraid of trying anything like that, but it seems like
st way to deal with doing anything with the thing in the long
ar that I'll write code, but not take into account some
zation aspect that the MS does, and then when my code
ll just be a brick.
But think of the rush you get when it works!!! :-)
A =
bricked mailstation is a pretty low price to pay, and you might
get it righ=
t the first try. If only *all* the mistakes we make
could be limited to th=
e cost of a new mailstation!!!
d go about using to flash
I started writing patch, but did n=
ot finish yet. Basic approach
would be:
1) create patch.
1.5) save rom =
image to file, if you don't already have one.
2) load rom image into RAM ta=
rget of mailbug.
3) apply the patch.
4) save image to file (you need pa=
ges 0, 1, 2, & 3, 'coz you have to
erase that much).
5) using MBUG target, =
erase pgs 0, 1, 2, 3.
5.5) don't reboot mailstation!!!!!!
6) still using mb=
ug target, write patched image to codeflash.
7) successfully reboot your pa=
tched mailstation.
8) stand up, raise two fists in air, and sing chourus of=
"I've Got the
Power".
9) remember to *not* spike your mailstation in endzo=
ne!
(OK, I usually do step 8 while still seated.)
From: "Jeff" <fyberoptic1979@...>
Aug 20, 2007
Jones" <cyranojones_lalp@...> =
wrote:
efore I left) the keyscan vars are not init to anything beyond
g of ram in init. The page 6 init relating to keyboard
reading of buffer, andconverting to key events.
d int, which you wouldn't need, and
ou probably do need. I
0 on stack
ary
I ended up disassembling it a second time=
since I thought I might
have messed up during my labeling process, but it=
turned out to just
be some minor issues elsewhere. I was declaring my 'k=
eybuffer'
variable as just 32 bytes instead of 64, and had to set 'keycols=
tate'
and 'keycolstate2' to #FF during init.
So basically my entire key=
board initialization is:
- Activate all keyboard rows (MS appears to do it)=
- Set 'flagz', 'keyscanstate', and 'anotherkeyvar' to 0 (I don't see
MS d=
oing this, but I figure it's best to do it)
- Set 'keycolstate' and 'keycol=
state2' to #FF (if set to 0, they
trigger a power button press)
- call ini=
t_keyboard
This lets all of the keyboard routines I pulled out of the firm=
ware
work properly, using my own variables as well, so that none of the
a=
ctual firmware code or variables are needed anymore.
For anyone that might=
be interested, here's some variable locations
in the v3.03a firmware that=
I jotted down along the way:
flagz equ #D631
kbd_last_up_keycode equ #D=
A46
keybuffer equ #E5AF
keybuffin equ #E5EF
keybuffout equ #E5F0
keycols=
tate equ #E5F1
keycolstate2 equ #E5F2
anotherkeyvar equ #E5F3
keyscansta=
te equ #E5F4
keytable3 equ #E5F5
keytable2 equ #E5FF
keytable1 equ #E60=
9
p2shadow equ #DBA5
p3shadow equ #DBA6
but did not finish yet. Basic approach
om image into RAM target of mailbug.
age to file (you need pages 0, 1, 2, & 3, 'coz you have to
h).
tation!!!!!!
.
wo fists in air, and sing chourus of "I've Got
to *not* spike your mailstation in endzone!
while still seated.)
I have to admit that I haven't used mailbug yet s=
ince it apparently
needs DOS. But I can pull my laptop out and try it on =
there if I
decide to patch, since it boots to a few different OS's.
Out=
of curiosity, what process are you using to initiate a code
flash? Is it=
like a trigger over the parallel port, or are you
loading some software o=
nto the MS and doing it with internal
functions?
I noticed my MS did some=
thing weird the other day when the power was
fluctuating some during a cod=
e transfer (my power jack and AC adapter
are a bit wiggly). It prompted m=
e to do a firmware update, but then
failed almost immediately. I'm fairly=
sure there's no way I could
accidently screw it up in such a manner thoug=
h, since it does I CRC
check and stuff I think from what I've seen in the =
code.
And yes, alas, I finally went to an AC adapter. Those batteries I=
had been using finally spewed their last scancode to the screen,
until i=
t started to gripe at me nonstop about them being low and
force itself off=
again when I'd try to start it up.
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 22, 2007
ard rows (MS appears to do it)
rkeyvar' to 0 (I don't see
t)
igger a power button press)
The vars are all set to=
0 in "init".
In 2.53yr disassembly, look at 0000:3890, a call to "memfi=
ll"
that zeroes #C000 thru #FBFF.
"flagz" is also explicitly set to 0 at =
0000:1B75.
I'm gonna make a guess that the reason you need to set
"keycols=
tate" & "keycolstate2" to #FF is because the
real vars are set that way (at=
least the bits that matter)
when you press the power button to turn ms on.=
iow,
your keyscan is init after the power has already been
turned on. Th=
e real keyscan would have seen that
button press and flipped some bits in t=
he real state vars.
Or, maybe all it is seeing is the button release, since=
that
will happen after the init code runs. It can't really see
button dow=
n transition, can it? ;^)
ed out of the firmware
that none of the
=
:-)
...
rently
I use win 9=
8. Mailbug 0.0.4 won't work with NT, 2000, or XP, due
to the restriction o=
n port access. Mailbug 0.0.5 uses the same DLL
you used, and I imagine it =
will work with XP and friends, when it
is done. But it won't even compile =
now, and I don't know what
I broke. It is nowhere near done anyways, ther=
e is a LOT that needs
changing to make it a real windows app. I have not =
had any time to
tinker with it lately.
I compiled 0.0.4 (and earlier) as d=
os app, because freepascal
did not allow port access in windows, even if yo=
u were running
on win 98. I don't know if anyone is actually running it un=
der
dos. (I really don't think anyone is running it, period.) It
may not=
run under dos without changing the default paths & filenames
to 8.3 form. =
But I would go with win 98.
g to initiate a code
, or are you
l
This does not use the native reflash mode at all.
Mailbug=
just accesses the addresses in the pattern that unlocks the
flash, writes =
a byte, and watches for the write to complete. Same
as if the flash was R=
AM. Earlier versions loaded the flash
algorithm into ms RAM, and sent it t=
he data to flash.
I removed the actual flash code from the ms side due to =
the
fact that it was too easy to change flash by sending nonsense
bytes. T=
his happens more often than you might think, when
the ms and mailbug are no=
t in sync.
It is a bit slower now, but not a big deal IMO. I realize
ther=
e are ways that would make it safer without incurring
as big a speed penalt=
y, but this way struck me as a particularly
easy way to make it safer.
I noticed my MS did something weird the other day when the power was
ctuating some during a code transfer (my power jack and AC adapter
bit wiggly). It prompted me to do a firmware update, but then
lmost immediately. I'm fairly sure there's no way I could
rew it up in such a manner though, since it does I CRC
think from what I've seen in the code.
Actually, it is pretty easy to s=
crew it up this way! :-)
It sounds like your ms app that was interfacing =
with your PC
was canceled by a power-on reset, and the PC kept sending byte=
s
which then were received by the native reflash monitor.
That checksum =
calc happens *after* it erases and rewrites the
codeflash. And for that m=
atter, it just displays the checksum
for the operator to read, it has no id=
ea of right or wrong
checksum.
dapter. Those batteries I
code to the screen,
eing low and
Hmmmm.=
.. I tried running on batteries for a while, myself, in
last week or so. =
One problem was I had to dig up my reset-button
poker, coz I couldn't jus=
t pull plug to reset. No big deal.
But there was another issue which escap=
es me right now (It's way
past bedtime!), but something was not acting righ=
t, and I
determined it was because the battery was low. I think that I
w=
as leaving it running for long periods with code that did not
know how to g=
o to sleep, and drained batteries extra fast.