Hardware Expansion (Sep 19, 2008)

From: "Neil Morrison" Sep 19, 2008
From: "Jeff" Sep 20, 2008
From: "Jeff" Sep 20, 2008
From: "Neil Morrison" Sep 20, 2008
From: "John R. Hogerhuis" Sep 20, 2008
From: "Jeff" Sep 21, 2008
From: "Jeff" Sep 21, 2008
From: "Cyrano Jones" Sep 22, 2008
From: "Jeff" Sep 22, 2008
From: "Cyrano Jones" Sep 22, 2008
From: "Cyrano Jones" Sep 22, 2008
From: "Jeff" Sep 23, 2008

Subject: Hardware Expansion

From: "Jeff" <fyberoptic1979@...>

Sep 19, 2008

Hiya folks, been a while since I posted here. My work on the
Mailstation a=
nd FyOS pretty much got sidetracked by other things, and I
never did get ba=
ck to it for quite some time.

When the Mailstation did start to pique my =
interest again about a month
ago, I came back to the same conclusion as bef=
ore: ROM locked into the
lower 16KB of address space was a nuisance. FyOS =
was going to be CP/M
compatible, but it would only ever be able to do so to=
a certain degree.
Any CP/M application would have to be recompiled at the =
very least
before it would ever work. That almost defeated the purpose in =
my eyes,
because many programs that a person might want to =A0actually run =
(like
Zork) don't necessarily have source available. =A0Disassembling and
m=
odifying apps to run at a different starting offset would be quite a
chore.=

So since the Mailstation has basically just been laying here collecting
d=
ust, I decided to take the plunge and modify the hardware. If I
damaged it=
, then so be it. =A0At least I'd still have a keyboard and
LCD to use for a=
nother project, right?

Luckily, that didn't happen!

In a nutshell=
, when the Mailstation starts, everything is as it always
was. But if ROM_=
TOGGLE is brought high, the code flash ROM is disabled,
and the second 16KB=
page of SRAM is put into the 0-16KB slot of the
Mailstation. I made it us=
e the second 16KB SRAM page because the first
page is already in use in the=
Mailstation's 48-64KB address area. =A0
So basically this means that the e=
ntire 64KB of address space of the
Mailstation can be set to RAM. And it m=
eans a true CP/M can be run on
it, as well as normal applications. =A0Keep =
in mind though that if one
were to port the original CP/M, they'd still hav=
e to write a BIOS module
to compile into it to support the Mailstation hard=
ware, so it's not as
easy as just dropping a new OS onto it. =A0But I plan =
to continue
developing FyOS now to allow CP/M apps to be run, now that they=
actually
can be.

I can't solder anytime I want around here, so in the va=
rious windows of
opportunity I get, I've been putting a board together to h=
old the three
logic chips used in my design (1 inverter, 1 AND, 1 OR) so th=
at it can
be tucked back inside the Mailstation. Using it with the breadbo=
ard is
currently too fragile to really do much with it, so I haven't gone f=
ar
beyond the hardware aspect, other than writing a test app which
continuo=
usly writes three bytes into a particular spot in the lower
16KB, and then =
prints out those locations to the screen. When
ROM_TOGGLE is low, naturall=
y it will return three bytes from the ROM.
But when it's high, I get back =
the values I had been writing to the
location (since it's now RAM).

One pr=
oblem at the moment is the toggle of ROM_TOGGLE. =A0Currently,
it's a physi=
cal action on my part to enable the SRAM. =A0I tried
connecting it to vario=
us output pins of the Mailstation's CPU, but the
Mailstation OS must be tog=
gling and setting up these things during its
initialization (thereby switch=
ing ROM out of the address space and
crashing it), because it never starts =
up. =A0The only solution here
that I can think of is to go ahead and replac=
e the Mailstation software
too, to avoid the hardware initialization on wha=
tever pin I want to use.
=A0But I'll take that one step at a time, because =
screwing up the code
flash means a ton of work to wire into the MS board to=
reflash it. =A0

I'll actually be able to test new startup code by writing=
it into RAM,
then resetting the Mailstation. =A0It'll then boot off of my =
code
instead of the ROM as long as ROM_TOGGLE is enabled. =A0Once I'm sure
=
my code is good, I'll work on writing it into the code flash.

Anyway, as I=
said, I still need to finish the circuit board before I
really get back in=
to the software, so I'm hoping to have that done over
the weekend. =A0It's =
just three chips, but cutting, stripping,
arranging, and threading wires on=
to the board takes more time than the
actual soldering. =A0If I had the mon=
ey, I'd have just paid to have a
PCB made, just to avoid dealing with the w=
ires! =A0

I was going to wait to post about it until I had the board made =
and the
Mailstation running a CP/M app, but with the renewed interest and
p=
osting in this group lately, I thought I'd go ahead and chime in, since
I'm=
excited about where it can go now.

And feel free to ask any questions abo=
ut the hardware if I didn't
explain everything. =A0I can give a detailed ex=
planation of how it
works if necessary. =A0I can also export a circuit sche=
matic if anyone
is interested in building it. =A0But keep in mind that it w=
ill require
cutting traces on the Mailstation board!

Hiya folks, been a while since I posted here. My work on the Mailstation a=
nd FyOS pretty much got sidetracked by other things, and I never did get ba=
ck to it for quite some time. When the Mailstation did start to p=
ique my interest again about a month ago, I came back to the same conclusio=
n as before: ROM locked into the lower 16KB of address space was a nuisance=
. FyOS was going to be CP/M compatible, but it would only ever be able to =
do so to a certain degree. Any CP/M application would have to be recompile=
d at the very least before it would ever work. That almost defeated the pu=
rpose in my eyes, because many programs that a person might want to =A0actu=
ally run (like Zork) don't necessarily have source available. =A0Disassembl=
ing and modifying apps to run at a different starting offset would be quite=
a chore.So since the Mailstation has basically just been laying her=
e collecting dust, I decided to take the plunge and modify the hardware. I=
f I damaged it, then so be it. =A0At least I'd still have a keyboard and LC=
D to use for another project, right?Luckily, that didn't happen! =
jpg">

(URL)
es.jpg">

(URL)
board.jpg"> In a nutshell, when the Mailstation starts, everythin=
g is as it always was. But if ROM_TOGGLE is brought high, the code flash R=
OM is disabled, and the second 16KB page of SRAM is put into the 0-16KB slo=
t of the Mailstation. I made it use the second 16KB SRAM page because the =
first page is already in use in the Mailstation's 48-64KB address area. =A0=
ilstation can be set to RAM. And it means a true CP/M can be run on it, as=
well as normal applications. =A0Keep in mind though that if one were to po=
rt the original CP/M, they'd still have to write a BIOS module to compile i=
nto it to support the Mailstation hardware, so it's not as easy as just dro=
pping a new OS onto it. =A0But I plan to continue developing FyOS now to al=
low CP/M apps to be run, now that they actually can be. I can't s=
older anytime I want around here, so in the various windows of opportunity =
I get, I've been putting a board together to hold the three logic chips use=
d in my design (1 inverter, 1 AND, 1 OR) so that it can be tucked back insi=
de the Mailstation. Using it with the breadboard is currently too fragile =
to really do much with it, so I haven't gone far beyond the hardware aspect=
, other than writing a test app which continuously writes three bytes into =
a particular spot in the lower 16KB, and then prints out those locations to=
the screen. When ROM_TOGGLE is low, naturally it will return three bytes =
from the ROM. But when it's high, I get back the values I had been writing=
to the location (since it's now RAM).One problem at the moment is t=
he toggle of ROM_TOGGLE. =A0Currently, it's a physical action on my part to=
enable the SRAM. =A0I tried connecting it to various output pins of the Ma=
ilstation's CPU, but the Mailstation OS must be toggling and setting up the=
se things during its initialization (thereby switching ROM out of the addre=
ss space and crashing it), because it never starts up. =A0The only solution=
here that I can think of is to go ahead and replace the Mailstation softwa=
re too, to avoid the hardware initialization on whatever pin I want to use.=
=A0But I'll take that one step at a time, because screwing up the code fla=
sh means a ton of work to wire into the MS board to reflash it. =A0I=
'll actually be able to test new startup code by writing it into RAM, then =
resetting the Mailstation. =A0It'll then boot off of my code instead of the=
ROM as long as ROM_TOGGLE is enabled. =A0Once I'm sure my code is good, I'=
ll work on writing it into the code flash.Anyway, as I said, I still=
need to finish the circuit board before I really get back into the softwar=
e, so I'm hoping to have that done over the weekend. =A0It's just three chi=
ps, but cutting, stripping, arranging, and threading wires onto the board t=
akes more time than the actual soldering. =A0If I had the money, I'd have j=
ust paid to have a PCB made, just to avoid dealing with the wires! =A0<=
P>I was going to wait to post about it until I had the board made and the M=
ailstation running a CP/M app, but with the renewed interest and posting in=
this group lately, I thought I'd go ahead and chime in, since I'm excited =
about where it can go now.And feel free to ask any questions about t=
he hardware if I didn't explain everything. =A0I can give a detailed explan=
ation of how it works if necessary. =A0I can also export a circuit schemati=
c if anyone is interested in building it. =A0But keep in mind that it will =
require cutting traces on the Mailstation board!

1: Subject: Re: [mailstation] Hardware Expansion

(top)

From: "Neil Morrison" <neilsmorr@...>

Sep 19, 2008

True, but Infocom/Zork is one that isn't a problem - we have good clones.

However the best bet would be to add a BASIC (like Microsoft's old one) in
an unused segment - no problem relocating that.

I wouldn't bother with CP/M.

Neil

From: Jeff

Hiya folks, been a while since I posted here. My work on the Mailstation and
FyOS pretty much got sidetracked by other things, and I never did get back
to it for quite some time.

When the Mailstation did start to pique my interest again about a month ago,
I came back to the same conclusion as before: ROM locked into the lower 16KB
of address space was a nuisance. FyOS was going to be CP/M compatible, but
it would only ever be able to do so to a certain degree. Any CP/M
application would have to be recompiled at the very least before it would
ever work. That almost defeated the purpose in my eyes, because many
programs that a person might want to actually run (like Zork) don't
necessarily have source available.

2: Subject: Re: Hardware Expansion

(top)

From: "Jeff" <fyberoptic1979@...>

Sep 20, 2008

Welp, I finished it, and it worked on the first try!

Kinda got flash-b=
linded there but you get the idea. I also covered the
back and a small bit =
of the front with a strip of tape so that none of
the exposed metal would t=
ouch anything when inside the Mailstation case.

Downside is, I'm still act=
ivating the ROM toggle manually, which at the
moment means wires sticking o=
ut of the back from the battery compartment
tation/img/ms_backwires.jpg> . But it'll
have to do for now, because as I m=
entioned before, none of the output
pins from the CPU that I tried will wor=
k without crashing it at startup.
I can devise a test now though to determi=
ne if it's actually the MS
firmware causing it.

I wanted a lot of slack on=
the wires so that I could work with it
without pulling things loose, but I=
ended up with a bit of a wire jungle
/img/ms_wirejungle.jpg> . It all
fits back in the case though, just require=
s a minor squeeze to make it
go together to put the screws in.

So once I =
get the Mailstation software issue dealt with, so that I can
tie the ROM_TO=
GGLE pin onto a cpu pin and toggle it via software, it'll
be pretty spiffy.=
For now I'll probably try to wire a switch into those
three wires to make =
it easier to use, then just put up a prompt for
whenever I need to switch i=
t to RAM.

The funny thing is, if I could afford a GAL programmer, I could =
have
done all of this with a single chip and tons less hassle. =A0But this
=
works for now.

Welp, I finished it, and it worked on the first try! <IMG src=3D"htt=
p://www.fybertech.net/mailstation/img/msboard_front.jpg"> <IMG src=
=3D"

Kind=">(URL)
a got flash-blinded there but you get the idea. I also covered the back and=
a small bit of the front with a strip of tape so that none of the exposed =
metal would touch anything when inside the Mailstation case. Downsid=
e is, I'm still activating the ROM toggle manually, which at the moment mea=
ns wi=">(URL)
res sticking out of the back from the battery compartment</A>. But it'll ha=
ve to do for now, because as I mentioned before, none of the output pins fr=
om the CPU that I tried will work without crashing it at startup. I can dev=
ise a test now though to determine if it's actually the MS firmware causing=
it. I wanted a lot of slack on the wires so that I could work with =
it without pulling things loose, but (URL)
ilstation/img/ms_wirejungle.jpg">I ended up with a bit of a wire jungle</A>=
. It all fits back in the case though, just requires a minor squeeze to mak=
e it go together to put the screws in. So once I get the Mailstat=
ion software issue dealt with, so that I can tie the ROM_TOGGLE pin onto a =
cpu pin and toggle it via software, it'll be pretty spiffy. For now I'll pr=
obably try to wire a switch into those three wires to make it easier to use=
, then just put up a prompt for whenever I need to switch it to RAM.=
The funny thing is, if I could afford a GAL programmer, I could have done a=
ll of this with a single chip and tons less hassle. =A0But this works for n=
ow.

3: Subject: Re: Hardware Expansion

(top)

From: "Jeff" <fyberoptic1979@...>

Sep 20, 2008

I was pretty much just going to replicate the CP/M BDOS functions,
which w=
ould allow the various applications to run. I dunno if I'll
actually go a=
s far as duplicating the command processor itself. The
biggest reason bei=
ng because I've hardly ever used CP/M, so I don't
know most of the command=
s! I know my way around DOS well though, and
figured I'd probably base th=
e command line more on that. DOS 1
practically was CP/M anyway.

And as=
a bonus, I've already had some experience of working with
DOS's older fun=
ctions which CP/M used (like the File Control Block
interface) when I as w=
orking on making a DOS clone recently. So
that'll come in handy.

As for =
BASIC, I've never tried implementing a version of that on
anything. Makin=
g one work on a stock MS would be interesting to try
sometime. I just wou=
ldn't know where to start though without looking
through the source.

- In mailstation@yahoogroups.com, "Neil Morrison" <neilsmorr@...>
wrote:

cl=
ones.
ld
one) in
n't bother with CP/M.

4: Subject: Re: [mailstation] Re: Hardware Expansion

(top)

From: "Neil Morrison" <neilsmorr@...>

Sep 20, 2008

Most of us old TRS-80 guys have a disassembled copy (or two) of the 12 K
basic with comments. IIRC, there are spare memory blocks in the MS which
could hold this.

Neil

From: Jeff

I was pretty much just going to replicate the CP/M BDOS functions,
which would allow the various applications to run. I dunno if I'll
actually go as far as duplicating the command processor itself. The
biggest reason being because I've hardly ever used CP/M, so I don't
know most of the commands! I know my way around DOS well though, and
figured I'd probably base the command line more on that. DOS 1
practically was CP/M anyway.

And as a bonus, I've already had some experience of working with
DOS's older functions which CP/M used (like the File Control Block
interface) when I as working on making a DOS clone recently. So
that'll come in handy.

As for BASIC, I've never tried implementing a version of that on
anything. Making one work on a stock MS would be interesting to try
sometime. I just wouldn't know where to start though without looking
through the source.

5: Subject: Re: [mailstation] Re: Hardware Expansion

(top)

From: "John R. Hogerhuis" <jhoger@...>

Sep 20, 2008

I think CP/M is the way to go. This will give lots of applications
(Wordstar, etc.) and compilers right out of the gate.

A Xilinx CPLD might be the right way to do the hardware mod. That's
what was used for Remem and REX, which are memory/flash upgrades for
the TRS-80 Model 100/102/200.

My understanding is that you can program it in-circuit with a JTAG
cable, no stand-alone programmer necessary.

6: Subject: Re: Hardware Expansion

(top)

From: "Jeff" <fyberoptic1979@...>

Sep 21, 2008

I ran into a somewhat unexpected snag for one of the things I wanted
to tr=
y, it would seem. I was thinking that I could just write some
code to the=
SRAM, and while my ROM_TOGGLE hardware was active
(putting ram page 1 int=
o the 0-16KB slot), that I'd be able to reset
the Mailstation and then boo=
t code directly out of the RAM for
testing purposes.

Well it seems that=
when I push the reset button in, the thing just
locks up or something.

M=
y test code is a simple app which disables interrupts, turns the New
Mail =
LED on, loops through reading port 0x10 to wait 1 second, turns
the LED ba=
ck off, waits 1 second again, then loops the program. I
tested it via the=
Mailstation Yahoo app loader method and it works as
expected from there. =

I was only using JRs instead of JPs (which I had to disable assembler
o=
ptimizations to ensure), and disassembled the resulting binary to
make sur=
e it was doing exactly as I wrote. So the code was portable
to any memory=
location, but resetting the Mailstation didn't execute
it at startup as e=
xpected.

To make absolute sure there wasn't some hardware problem with run=
ning
code from the 0x0000 slot when set to RAM, I modified the test app
w=
ith an ORG 0x0000 and a JP at the end. That way, after it was
loaded via =
the Yahoo loader app (into 0x8000, SRAM page 1), it would
blink the LED on=
ce and use a JP to loop the program, then end up in
the 0x000 slot (also S=
RAM page 1) to continue execution. And, as
expected, it continued to exec=
ute just fine from the first slot. So
it wasn't the hardware apparently.
=

So my assumption at this point is that maybe pressing the reset
button is=
erasing the contents of the SRAM? If this is the case,
what method would=
be available to reset the system to a default state
without causing that?=
And/or would it be possible to stop it from
erasing the SRAM when pushin=
g the button by modifying it somehow? I
haven't traced the connections fr=
om the button to see what all they
do yet.

I mostly just want to be able =
to get the system into a default
startup mode when executing my code from =
the SRAM. That way anything
I write will be in the same conditions as it =
would be whenever I
decide to write that code into the code flash, which w=
ould greatly
improve the chances of not bricking it.

I'm running off of a=
n AC adapter and not batteries, if that possibly
makes a difference.

7: Subject: Re: Hardware Expansion

(top)

From: "Jeff" <fyberoptic1979@...>

Sep 21, 2008

Nevermind, I ran into one of those "gotchas" that results from trying
to u=
se the hardware from the reset state.

Turns out my test code was in fact r=
unning out of RAM at startup.
But me trying to toggle the LED in that sta=
te wasn't working because
the P2 direction bits hadn't been initialized.

=
All it took was adding in:

ld a, #FF
out (#0B), a

I discovere=
d this when looking through Mailstation firmware init
code, seeing what it=
did to each port during initialization, and
noticed the P2 direction regi=
ster. I assume P2 is all inputs by
default, hence the LED never coming on=
.

Having to initialize directions for some of the ports has made me
wond=
er again about what pin could be attached to my ROM_TOGGLE line.
Currentl=
y I think P28.3 is my best bet. It's apparently caller ID
related, but my=
Mailstation has no caller ID. All other caller ID
pins aren't connected =
to anything from the cpu on mine. Even P28.3
just goes out to a pad on th=
e back of the board, not connecting to
anything else, which makes me wonde=
r why they connected that one to
something but not the others. But hopefu=
lly it'll be usable for my
purposes when the Mailstation code isn't fiddli=
ng with it.

8: Subject: Re: Hardware Expansion

(top)

From: "Cyrano Jones" <cyranojones_lalp@...>

Sep 22, 2008

seeing what it did to each port during initialization, and
P2 direction register. I assume P2 is all inputs by
LED never coming on.

Yeah, I think all the ports are input by default.

Having to initialize directions for some of the ports has made me
again about what pin could be attached to my ROM_TOGGLE line.
y I think P28.3 is my best bet.

Add a resistor to pull it to your default=
state when it
is set as an input. Then set the bit to the same state,
and=
then set the dir to output.

I used bit D5 of the par port for my bank swi=
tch
circuit. IIRC, I connected d5 to the clock on a flip-flop,
and connect=
ed the ms reset line to the ff reset.
A hi then lo pulse on d5 would flip t=
he bank. I
used a toggle switch to control whether the normal
(reset) sta=
te was the ms codeflash, or the socket
I kluged in. Clocking the flip-flop=
swapped in
the other.

At first I used a boot-rom (mboot) in the socket
to=
get mailbug going. Later I put the boot code
in the ms rom, and a big ra=
m chip in the socket.
The boot code loaded mbug into ms RAM, then swapped
t=
he socket in, giving me a mailstation with mbug
loaded, and RAM in place o=
f the codeflash chip.
Then I could load whatever I wanted into that RAM.
I =
used this setup to run modified versions of the ms
code. (Breakpoints work=
ed with this setup, too!!!)

I used d5 because d0-d4 are used for the updat=
e protocol,
and d6-d7 were in use as a bit-bang serial port.

CJ

9: Subject: Re: Hardware Expansion

(top)

From: "Jeff" <fyberoptic1979@...>

Sep 22, 2008

wrote:
pull it to your default state when it
it to the same state,

I ended up doin=
g exactly that, except I forgot to set the port
direction on P28 at first =
so it wasn't working. Doh! I had
forgotten that the MS init code only se=
ts a couple of P28 to outputs,
not all of them (not sure why, since they'r=
e all actually outputs as
far as I know). But now I have P28.3 connected =
to my ROM_TOGGLE
signal, and can enable or disable the RAM easily from the=
port.
Hooray.

What is kind of confusing me though is the resistor value=
I had to
use for the pull-down. I ended up using a 1k, since a 4.7k and =

higher wouldn't work (ROM_TOGGLE was apparently behaving as 'high' at
sta=
rtup when using these other values, as if ground weren't connected
at all)=
.

Pull-down aside, there's three inputs on the logic chips all
connected =
together which make up the ROM_TOGGLE input signal. When
ROM_TOGGLE is co=
nnected to ground, those three inputs are low of
course, and so ROM is ena=
bled. But when I disconnect from ground,
they automatically pull themselv=
es high without me connecting them to
anything (high =3D RAM enabled). I =
kind of have some fuzzy ideas as to
why that happens, but I'm not versed w=
ell enough with analog
electronic concepts to fully explain it. But I'm a=
ssuming that
having three inputs connected together could be why I ended u=
p having
to use such a low resistor value. I just hope it's not problemat=
ic
in terms of power consumption or something, since pull-downs are
usual=
ly 10k or 47k as far as I understand.

r my bank switch
op,
on d5 would flip the bank. I
he normal
. Clocking the flip-flop swapped in

That sounds like a good =
method too, since it resets properly. Now
that I'm wired into a CPU port =
to do my switching, pressing the MS
reset button resets P28 as an input an=
d automatically brings the ROM
back into slot 0. In many respects, this i=
s good, since it behaves
like yours does. But that also means I can't boo=
t from the RAM now,
which was one of the things I wanted to be able to do =
easily.

What I think I'll do though is maybe combine a pull-up into the wh=
ole
mess, connected with a switch. Not sure what resistor value would
wo=
rk at the moment considering there's already a pull-down present
too. But=
that way, by flipping the switch, ROM_TOGGLE could be
forced high regardl=
ess of P28.3 being an input at startup, and I'd be
able to boot from the R=
AM again when I wanted to test boot code.

Or I dunno, maybe it'd be better=
to just put the switch between the
pull-down and ground, since ROM_TOGGLE=
seems to automatically go high
when not connected to anything (or when co=
nnected to something set as
an input). I dunno if it's good to leave thos=
e inputs floating or
not though, if it's even still considered floating wh=
en multiple
inputs are connected like that.

rom (mboot) in the socket
e
d mbug into ms RAM, then swapped
ith mbug
load whatever I wanted into that RAM.
ersions of the ms

Ha=
ving an external socket would really reduce the worry of messing up
what's=
written to the MS codeflash. I thought about adding one
myself, but so m=
any wires involved. I think I've seen enough to last
me for a few days!

=
While I'm thinking of it, what would be a safe 64K sector of the
codeflash=
to erase to test writing to it? I perused mine and noticed
there doesn't=
seem to be an empty sector anywhere. I only have one
or two pages of the=
disassembled/well-commented codeflash, so I dunno
what's in those others =
without lots of digging. But surely there's
an unimportant section, or on=
e that doesn't get used except in
certain circumstances. I mostly only ne=
ed the Mailstation to be able
to get into the Yahoo apps menu and run stuf=
f at this point.

tocol,

I thought abo=
ut using a pin from there initially when the others I
tried didn't work (o=
r more accurately, I didn't know how to make them
work at the time), but t=
hen I thought that I might want the full 8
bits of the parallel port for s=
omething. One could interface an SD
card into it or some such, since they=
're fairly shy on pin usage.
You'd need a 5v to 3.3v conversion on power =
and data pins though,
which is the biggest inconvenience. I doubt the Mai=
lstation has a
3.3v source available.

I also considered disconnecting the=
modem's chip-select and
connecting address/data/modem CS lines to an IDE-=
to-Compact Flash
adapter. CF cards (ones abiding by standards at least) c=
an be used
in 8-bit data transfer mode from what I understand. I'd have t=
o
check CF power requirements though to make sure it wasn't a big
strain =
on the Mailstation. But having removable storage would be
nice, because t=
hen I wouldn't have to try implementing some kind of
special file system f=
or the dataflash to avoid wearing it out.

10: Subject: Re: Hardware Expansion

(top)

From: "Cyrano Jones" <cyranojones_lalp@...>

Sep 22, 2008

n input. Then set the bit to the same state,
utput.
direction on P28 at first so it wasn't working. Doh! I had
hat the MS init code only sets a couple of P28 to outputs,
m (not sure why, since they're all actually outputs as
ut now I have P28.3 connected to my ROM_TOGGLE
disable the RAM easily from the port.
ng me though is the resistor value I had to
ed up using a 1k, since a 4.7k and
pparently behaving as 'high' at
if ground weren't connected

I was gonna say you should check f=
or a pullup resistor
hiding on the ms board somewhere, but read on below...=

d together which make up the ROM_TOGGLE input signal. When
connected to ground, those three inputs are low of
enabled. But when I disconnect from ground,
mselves high without me connecting them to
).

Ook!!! Sounds like you are using TTL logic!!!

I looked at your pictur=
es, and sure enough, I see 74LS parts.
When I said "Add a resistor to pull =
it to your default
state", I was assuming CMOS logic. I don't even know if=

driving TTL is within spec for the ms cpu. I assume that
the cpu is CMOS.=
I would replace the LS parts with
HC or HCT.

ideas as to

three inputs connected together could be why I ended up having
ch a low resistor value. I just hope it's not problematic
wer consumption or something, since pull-downs are
far as I understand.

Not analog, it's just the design rules are different =
for
TTL than CMOS. Unconnected TTL inputs "float high", and have
to be act=
ively pulled low. You usually will not pull a TTL
input low with a resisto=
r (passive). You either drive it low
with a TTL output, or peg it directly=
to gnd. CMOS inputs
don't float high, they are just as happy to float low=
as hi,
and an unconnected CMOS input will pick up enough influence
just ou=
t of the air to flutter back and forth between lo and hi.
As such, a CMOS i=
nput can be pulled lo or hi with a resistor.

port for my bank switch
a flip-flop,
then lo pulse on d5 would flip the bank. I
trol whether the normal
et
hat sounds like a good method too, since it resets properly. Now
m wired into a CPU port to do my switching, pressing the MS
resets P28 as an input and automatically brings the ROM
In many respects, this is good, since it behaves
that also means I can't boot from the RAM now,
s I wanted to be able to do easily.
e combine a pull-up into the whole
re what resistor value would
dy a pull-down present

If you change to HC or HCT, then 47k might b=
e good.
I have used 1M when I didn't want to run batteries down
too fast!

=
If you stick with LS, then I would change circuit so
your default was "pull=
ed up" state. I don't remember
what a typical LS pullup value is. (IMO, L=
S has been
obsolete for like 20 years or more.)

g the switch, ROM_TOGGLE could be
n input at startup, and I'd be
ted to test boot code.

Might want to make switch select pull-up or pull-do=
wn
(use one res, and spdt switch to select +5 or gnd).
That would avoid pos=
sibility of having p28.3 pegged to
+5v when it is in output mode driving lo=
w.

pull-down and ground, since ROM_TOGGLE seems to automatically go high
en not connected to anything (or when connected to something set as
put). I dunno if it's good to leave those inputs floating or
if it's even still considered floating when multiple
d like that.

I learned you should not trust ttl to float hi, you
should al=
ways use a pullup. I think it is less succeptible
to noise with pullup. B=
ut when experimenting, letting
them float hi always seemed good enough!

. Later I put the boot code
ocket.
et in, giving me a mailstation with mbug
e codeflash chip.
nts worked with this setup, too!!!)
lly reduce the worry of messing up
thought about adding one
ve seen enough to last

It's not so bad!

(I dunno if =
above embeded image is gonna work. If
not, you can see it in group's photo=
section.)
I found the little gold test points to work better than
the vias=
for attaching the wires.

64K sector of the
ine and noticed
y have one
I dunno
's
in circumstances. I mostly only need the Mailstation to be able
nto the Yahoo apps menu and run stuff at this point.

Offhand I can't say w=
hat part of code you could dump
and still get it to run. I think the last =
16k page
is empty in most versions of firmware (ok, I only
looked at a few,=
but I don't remember any that had
code in last page). Why not use last pa=
ge, and just
reflash the other three pages with code from your dump?

used d5 because d0-d4 are used for the update protocol,
in use as a bit-bang serial port.
there initially when the others I
I didn't know how to make them
t I might want the full 8

Yeah,=
even something like a parallel port! I didn't
make mine with intention of=
it being anything other
than a research tool to learn about ms insides.
An=
d now that I think about it, the way mine works
you could print to your hea=
rts content, and the
flip-flop is gonna stay flipped. And you won't
even g=
et a glitch on your printer when flipping
the bank, 'coz bank switching doe=
s not activate
the printer port strobe!

One downside to callid bits is tha=
t some ms's have
the callid chip, so you would have to disable it
on those,=
I suppose.

they're fairly shy on pin usage.
ower and data pins though,
he Mailstation has a
ecting the modem's chip-select and
to an IDE-to-Compact Flash
at least) can be used
. I'd have to
a big
nice, because then I wouldn't have to try implementing some kind of
ial file system for the dataflash to avoid wearing it out.

That would be p=
retty neat. I have wondered about possibility
of interfacing to USB flash =
drives. If only I had an
infinite supply of time!!! I can't even stay up =
late
putzing with this stuff anymore, 'coz I got me one of
those J.O.B. thi=
ngs that my girlfriend (and family)
have been nagging me about. :-(

CJ

=

gt; is set as an input. Then set the bit to the same state, > &=
gt; and then set the dir to output. > > I ended up doing exact=
ly that, except I forgot to set the port > direction on P28 at first=
so it wasn't working. Doh! I had > forgotten that the M=
S init code only sets a couple of P28 to outputs, > not all of them =
(not sure why, since they're all actually outputs as > far as I know=
). But now I have P28.3 connected to my ROM_TOGGLE > signal, a=
nd can enable or disable the RAM easily from the port. > Hoora=
y. > > What is kind of confusing me though is the resistor val=
ue I had to > use for the pull-down. I ended up using a 1k, si=
nce a 4.7k and > higher wouldn't work (ROM_TOGGLE was apparently beh=
aving as 'high' at > startup when using these other values, as if gr=
ound weren't connected > at all). I was gonna say you should =
check for a pullup resistor hiding on the ms board somewhere, but read o=
n below... > Pull-down aside, there's three inputs on the l=
ogic chips all > connected together which make up the ROM_TOGGLE inp=
ut signal. When > ROM_TOGGLE is connected to ground, those thr=
ee inputs are low of > course, and so ROM is enabled. But when=
I disconnect from ground, > they automatically pull themselves high=
without me connecting them to > anything (high =3D RAM enabled).&nb=
sp; Ook!!! Sounds like you are using TTL logic!!! I lo=
oked at your pictures, and sure enough, I see 74LS parts. When I said "A=
dd a resistor to pull it to your default state", I was assuming CMOS lo=
gic. I don't even know if driving TTL is within spec for the ms cp=
u. I assume that the cpu is CMOS. I would replace the LS par=
ts with HC or HCT. > I kind of have some fuzzy ideas as to <br=
electronic concepts to fully explain it. But I'm assuming that &=
gt; having three inputs connected together could be why I ended up having <=
br>> to use such a low resistor value. I just hope it's not proble=
matic > in terms of power consumption or something, since pull-downs=
are > usually 10k or 47k as far as I understand. Not analog,=
it's just the design rules are different for TTL than CMOS. Uncon=
nected TTL inputs "float high", and have to be actively pulled low.&nbs=
p; You usually will not pull a TTL input low with a resistor (passive).=
You either drive it low with a TTL output, or peg it directly to=
gnd. CMOS inputs don't float high, they are just as happy to floa=
t low as hi, and an unconnected CMOS input will pick up enough influence=
such, a CMOS input can be pulled lo or hi with a resistor. >=
; > I used bit D5 of the par port for my bank switch > > circui=
t. IIRC, I connected d5 to the clock on a flip-flop, > > and=
connected the ms reset line to the ff reset. > > A hi then lo pul=
se on d5 would flip the bank. I > > used a toggle switch to=
control whether the normal > > (reset) state was the ms codeflash=
, or the socket > > I kluged in. Clocking the flip-flop swap=
ped in > > the other. > > That sounds like a good met=
hod too, since it resets properly. Now > that I'm wired into a=
CPU port to do my switching, pressing the MS > reset button resets =
P28 as an input and automatically brings the ROM > back into slot 0.=
In many respects, this is good, since it behaves > like yours=
does. But that also means I can't boot from the RAM now, > wh=
ich was one of the things I wanted to be able to do easily. > >=
; What I think I'll do though is maybe combine a pull-up into the whole <br=
ld > work at the moment considering there's already a pull-down pres=
ent > too. If you change to HC or HCT, then 47k might =
be good. I have used 1M when I didn't want to run batteries down too=
fast! If you stick with LS, then I would change circuit so your =
default was "pulled up" state. I don't remember what a typical LS =
pullup value is. (IMO, LS has been obsolete for like 20 years or m=
ore.) > But that way, by flipping the switch, ROM_TOGGLE could be=
d be > able to boot from the RAM again when I wanted to test boot co=
de. Might want to make switch select pull-up or pull-down (use o=
ne res, and spdt switch to select +5 or gnd). That would avoid possibili=
ty of having p28.3 pegged to +5v when it is in output mode driving low.=
n the > pull-down and ground, since ROM_TOGGLE seems to automaticall=
y go high > when not connected to anything (or when connected to som=
ething set as > an input). I dunno if it's good to leave those=
inputs floating or > not though, if it's even still considered floa=
ting when multiple > inputs are connected like that. I learne=
d you should not trust ttl to float hi, you should always use a pullup.&=
nbsp; I think it is less succeptible to noise with pullup. But whe=
n experimenting, letting them float hi always seemed good enough! &n=
bsp; > > At first I used a boot-rom (mboot) in the socket > =
the ms rom, and a big ram chip in the socket. > > The boot code l=
oaded mbug into ms RAM, then swapped > > the socket in, giving me =
a mailstation with mbug > > loaded, and RAM in place of the codef=
lash chip. > > Then I could load whatever I wanted into that RAM.<=
br>> > I used this setup to run modified versions of the ms > &=
gt; code. (Breakpoints worked with this setup, too!!!) > &g=
t; Having an external socket would really reduce the worry of messing up <b=
r>> what's written to the MS codeflash. I thought about adding one=
h to last > me for a few days! It's not so bad! <img src=
=3D"(URL)
2&m=3Df&o=3D0"> (I dunno if above embeded image is gonna work.&n=
bsp; If not, you can see it in group's photo section.) I found the li=
ttle gold test points to work better than the vias for attaching the wir=
es. > While I'm thinking of it, what would be a safe 64K sector o=
f the > codeflash to erase to test writing to it? I perused mi=
ne and noticed > there doesn't seem to be an empty sector anywhere.&=
nbsp; I only have one > or two pages of the disassembled/well-commen=
ted codeflash, so I dunno > what's in those others without lots of d=
igging. But surely there's > an unimportant section, or one th=
at doesn't get used except in > certain circumstances. I mostl=
y only need the Mailstation to be able > to get into the Yahoo apps =
menu and run stuff at this point. Offhand I can't say what part of c=
ode you could dump and still get it to run. I think the last 16k p=
age is empty in most versions of firmware (ok, I only looked at a fe=
w, but I don't remember any that had code in last page). Why not =
use last page, and just reflash the other three pages with code from you=
r dump? > > I used d5 because d0-d4 are used for the update pr=
otocol, > > and d6-d7 were in use as a bit-bang serial port. &g=
t; > > > I thought about using a pin from there initially =
when the others I > tried didn't work (or more accurately, I didn't =
know how to make them > work at the time), but then I thought that I=
might want the full 8 > bits of the parallel port for something.&nb=
sp; Yeah, even something like a parallel port! I didn't ma=
ke mine with intention of it being anything other than a research tool t=
o learn about ms insides. And now that I think about it, the way mine wo=
rks you could print to your hearts content, and the flip-flop is gonn=
a stay flipped. And you won't even get a glitch on your printer wh=
en flipping the bank, 'coz bank switching does not activate the prin=
ter port strobe! One downside to callid bits is that some ms's have<=
br>the callid chip, so you would have to disable it on those, I suppose=
. > One could interface an SD > card into it or some such,=
since they're fairly shy on pin usage. > You'd need a 5v to 3=
.3v conversion on power and data pins though, > which is the biggest=
inconvenience. I doubt the Mailstation has a > 3.3v source av=
ailable. > > I also considered disconnecting the modem's chip-=
select and > connecting address/data/modem CS lines to an IDE-to-Com=
pact Flash > adapter. CF cards (ones abiding by standards at l=
east) can be used > in 8-bit data transfer mode from what I understa=
nd. I'd have to > check CF power requirements though to make s=
ure it wasn't a big > strain on the Mailstation. But having re=
movable storage would be > nice, because then I wouldn't have to try=
implementing some kind of > special file system for the dataflash t=
o avoid wearing it out. That would be pretty neat. I have wond=
ered about possibility of interfacing to USB flash drives. If only=
I had an infinite supply of time!!! I can't even stay up late =
putzing with this stuff anymore, 'coz I got me one of those J.O.B. thin=
gs that my girlfriend (and family) have been nagging me about. :-(=

11: Subject: Re: Hardware Expansion

(top)

From: "Cyrano Jones" <cyranojones_lalp@...>

Sep 22, 2008

not, you can see it in group's photo section.)
est points to work better than

OK, I f=
iggered why it didn't work, I used url of the
html. The jpg looks like one=
of the protected url's,
and I tire of fighting the yahoos, so I will try j=
ust a
link to the html page, instead of embeded image...

(URL)
roups.yahoo.com/group/mailstation/photos/view/535c?b=3D2&m\
=3Df&o=3D0
p://tech.ph.groups.yahoo.com/group/mailstation/photos/view/535c?b=3D2&\
m=
=3Df&o=3D0>

CJ

onna work. If > not, you can see it in group's photo section.)<=
br>> I found the little gold test points to work better than > the=
vias for attaching the wires. OK, I figgered why it didn't work, I =
used url of the html. The jpg looks like one of the protected url'=
s, and I tire of fighting the yahoos, so I will try just a link to th=
e html page, instead of embeded image...
(URL)
s.yahoo.com/group/mailstation/photos/view/535c?b=3D2&m=3Df&o=3D0"> =
(URL)
p;m=3Df&o=3D0</a> CJ

12: Subject: Re: Hardware Expansion

(top)

From: "Jeff" <fyberoptic1979@...>

Sep 23, 2008

wrote:
your pictures, and sure enough, I see 74LS parts.
istor to pull it to your default
n't even know if
t

O=
h wow, somehow I got it into my head that the LS parts were better
than CM=
OS! I've mostly messed with older electronic devices, since
they're usual=
ly the only things easily modifiable for me at this
point. And I don't ev=
en have any basic glue logic in 74HC,
apparently. I tended to pick up LS =
ones here and there when I'd find
them cheap from somewhere when getting s=
omething else (to better
warrant the shipping costs and all), since 74LS i=
s what I've seen
most of so far (like in the NES).

I already added a pull=
-up into the mix earlier today, with a switch
between the ROM_TOGGLE and t=
he pull-up resistor. I tried a 4.7k at
first, which only half-worked. Wh=
en I used it to force the
ROM_TOGGLE line high, I watched my test app disp=
laying bytes from a
slot 0 memory address, and they constantly jittered ba=
ck and forth
between devices. I ended up using a 1k here too, which appea=
red to
keep the line held solidly. So the pull-up and pull-down use the
=
same values. I guess that means with voltage division that I'm only
passi=
ng ~2.5v into ROM_TOGGLE, unless the P28.3 and the three TTL
chip inputs a=
ffect that in ways I don't realize.

I don't really care for using these pa=
rts on the MS now that you've
made me aware of what a drain they might be,=
but I guess they'll have
to do for the time being. At least I know now! =
Thanks for the
enlightenment.

Eventually I'd like to be able to replace =
all of that with a single
GAL or CPLD anyways, since they seem like they'd=
be interesting to
work with considering how many logic chips they would e=
liminate from
a design. A board I was making for my NES before would end =
up using
less than half the chips!

f above embeded image is gonna work. If
hoto section.)
the vias for attaching the wires.

That's yours? I didn't realize due to t=
he user name. I thought it
was someone who came and disappeared from here=
ages ago.

One thing we've seen at least is that I have a ways to go to ge=
t a
clean wiring job like that! I used long wires that twisted onto
wire=
s coming out of the add-on board because I wanted to be able to
disconnect=
it and return the MS to its original state easily if need
be. I wasn't e=
ven sure if what I was doing was going to work, after
all. It was a relie=
f to see it doing on a breadboard what I had
planned out, but implementing=
that on an actual circuit was another
story. I've never modified somethi=
ng this modern, now that I think
about it. Well, unless you count putting=
a mod chip on a Gamecube,
but I didn't design that of course so it hardly=
counts.

still get it to run. I think the last 16k page
of firmware (ok, I only
ad
er three pages with code from your dump?

I did notice that 16K chunk. I w=
as just afraid I might write code to
erase and rewrite it, but have some u=
nexpected bug maybe and then not
be able to write the 64K back right away,=
and take the chance on
needing that 64K sector to run the Mailstation eno=
ugh to run the
loader app. I guess I'll just take the plunge sometime and=
see how
it goes!

possibility
nite supply of time!!! I can't even stay up late
anymore, 'coz I got me one of
d family)

On the bright side, at least =
you're making money to putz around with
something at some point with!

USB=
is even less pins, but I honestly don't know much about it
myself. I tri=
ed to work with it via a PIC once to talk to a PC, but
the protocol confus=
ed me at the time. I haven't looked at it in a
long time since then. I s=
hould learn more about it though, because
interfacing things with USB coul=
d be neat.

Another thing I thought about in regards to disconnecting the m=
odem
was to replace it with an actual serial port, which would probably be=

much easier to work with than fiddling with the laplink protocol. I
hav=
e to admit that the laplink protocol is something that has messed
with my =
head many times when trying to make sure I had all my data
signals and par=
allel port pins working together properly,
particularly since some of them=
are inverted. If I ever had to write
code for a parallel port communicat=
ion method again, I think that
maybe your serial-like protocol with just a=
couple of pins might be
much easier to deal with.

Anyhoo, as for a seria=
l port, I guess the problem that arises is how
one would deal with flow co=
ntrol and timing. You'd probably need an
entire UART and not just some si=
mple level conversion and junk.
Using a PIC or an AVR might accomplish su=
ch a task, but it's starting
to add in more complexity and power consumpti=
on than it might be
worth.