Subject: Hardware Expansion

From: "Jeff" <fyberoptic1979@...>
Date: Fri, 19 Sep 2008 19:23:40 -0000

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.  Disassembling and
modifying apps to run at a different starting offset would be quite a
chore.

So since the Mailstation has basically just been laying here collecting
dust, I decided to take the plunge and modify the hardware.  If I
damaged it, then so be it.  At least I'd still have a keyboard and
LCD to use for another 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 use the second 16KB SRAM page because the first
page is already in use in the Mailstation's 48-64KB address area.  
So basically this means that the entire 64KB of address space of the
Mailstation can be set to RAM.  And it means a true CP/M can be run on
it, as well as normal applications.  Keep in mind though that if one
were to port the original CP/M, they'd still have to write a BIOS module
to compile into it to support the Mailstation hardware, so it's not as
easy as just dropping a new OS onto it.  But 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 various windows of
opportunity I get, I've been putting a board together to hold the three
logic chips used in my design (1 inverter, 1 AND, 1 OR) so that it can
be tucked back inside 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 the toggle of ROM_TOGGLE.  Currently,
it's a physical action on my part to enable the SRAM.  I tried
connecting it to various output pins of the Mailstation's CPU, but the
Mailstation OS must be toggling and setting up these things during its
initialization (thereby switching ROM out of the address space and
crashing it), because it never starts up.  The only solution here
that I can think of is to go ahead and replace the Mailstation software
too, to avoid the hardware initialization on whatever pin I want to use.
 But 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.  

I'll actually be able to test new startup code by writing it into RAM,
then resetting the Mailstation.  It'll then boot off of my code
instead of the ROM as long as ROM_TOGGLE is enabled.  Once 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 software, so I'm hoping to have that done over
the weekend.  It's just three chips, but cutting, stripping,
arranging, and threading wires onto the board takes more time than the
actual soldering.  If I had the money, I'd have just paid to have a
PCB made, just to avoid dealing with the wires!  

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
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 the hardware if I didn't
explain everything.  I can give a detailed explanation of how it
works if necessary.  I can also export a circuit schematic if anyone
is interested in building it.  But keep in mind that it will require
cutting traces on the Mailstation board!

---

From: "Neil Morrison" <neilsmorr@...>
Date: Fri, 19 Sep 2008 13:07:43 -0700

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

----- Original Message ----- 
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.

---

From: "Jeff" <fyberoptic1979@...>
Date: Sun, 21 Sep 2008 00:41:02 -0000

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

Kinda 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.

Downside is, I'm still activating the ROM toggle manually, which at the
moment means wires sticking out of the back from the battery compartment
<http://www.fybertech.net/mailstation/img/ms_backwires.jpg> . But it'll
have to do for now, because as I mentioned before, none of the output
pins from the CPU that I tried will work without crashing it at startup.
I can devise 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 I ended up with a bit of a wire jungle
<http://www.fybertech.net/mailstation/img/ms_wirejungle.jpg> . It all
fits back in the case though, just requires 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_TOGGLE 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 it 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.  But this
works for now.

---

From: "Jeff" <fyberoptic1979@...>
Date: Sun, 21 Sep 2008 00:49:08 -0000

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.

--- In [email-masked], "Neil Morrison" <neilsmorr@...>

---

From: "Neil Morrison" <neilsmorr@...>
Date: Sat, 20 Sep 2008 17:57:06 -0700

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

----- Original Message ----- 
From: Jeff

---

From: "John R. Hogerhuis" <jhoger@...>
Date: Sat, 20 Sep 2008 20:29:02 -0700

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.

-- John.

---

From: "Jeff" <fyberoptic1979@...>
Date: Sun, 21 Sep 2008 19:41:18 -0000

I ran into a somewhat unexpected snag for one of the things I wanted 
to try, 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 into the 0-16KB slot), that I'd be able to reset 
the Mailstation and then boot 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.

My 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 back 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 
optimizations to ensure), and disassembled the resulting binary to 
make sure 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 expected.

To make absolute sure there wasn't some hardware problem with running 
code from the 0x0000 slot when set to RAM, I modified the test app 
with 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 once and use a JP to loop the program, then end up in 
the 0x000 slot (also SRAM page 1) to continue execution.  And, as 
expected, it continued to execute 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 pushing the button by modifying it somehow?  I 
haven't traced the connections from 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 would greatly 
improve the chances of not bricking it.

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

---

From: "Jeff" <fyberoptic1979@...>
Date: Mon, 22 Sep 2008 01:46:54 -0000

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

Turns out my test code was in fact running out of RAM at startup.  
But me trying to toggle the LED in that state 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 discovered this when looking through Mailstation firmware init 
code, seeing what it did to each port during initialization, and 
noticed the P2 direction register.  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 
wonder again about what pin could be attached to my ROM_TOGGLE line.  
Currently 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 the back of the board, not connecting to 
anything else, which makes me wonder why they connected that one to 
something but not the others.  But hopefully it'll be usable for my 
purposes when the Mailstation code isn't fiddling with it.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Mon, 22 Sep 2008 04:04:51 -0000

> default, hence the LED never coming on.

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

> Currently 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 switch
circuit.  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 pulse 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 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 ram chip in the socket.
The boot code loaded mbug into ms RAM, then swapped
the socket in, giving me a mailstation with mbug 
loaded, and RAM in place of 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 worked with this setup, too!!!)

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

CJ

---

From: "Jeff" <fyberoptic1979@...>
Date: Mon, 22 Sep 2008 06:36:44 -0000

--- In [email-masked], "Cyrano Jones" 
> and then set the dir to output.

I ended up doing 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 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, 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 
startup 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 connected to ground, those three 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 = RAM enabled).  I kind of have some fuzzy ideas as to 
why that happens, but I'm not versed well enough with analog 
electronic concepts to fully explain it.  But I'm assuming that 
having three inputs connected together could be why I ended up having 
to use such a low resistor value.  I just hope it's not problematic 
in terms of power consumption or something, since pull-downs are 
usually 10k or 47k as far as I understand.

> I kluged in.  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 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, 
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 whole 
mess, connected with a switch.  Not sure what resistor value would 
work 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 regardless of P28.3 being an input at startup, and I'd be 
able to boot from the RAM 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 connected to something set as 
an input).  I dunno if it's good to leave those inputs floating or 
not though, if it's even still considered floating when multiple 
inputs are connected like that.

> code.  (Breakpoints worked with this setup, too!!!)

Having 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 many 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 one that doesn't get used except in 
certain circumstances.  I mostly only need the Mailstation to be able 
to get into the Yahoo apps menu and run stuff at this point.

> and d6-d7 were in use as a bit-bang serial port.

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.  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 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) can be used 
in 8-bit data transfer mode from what I understand.  I'd have to 
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 then I wouldn't have to try implementing some kind of 
special file system for the dataflash to avoid wearing it out.

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Tue, 23 Sep 2008 02:39:01 -0000

> startup when using these other values, as if ground weren't connected

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

> anything (high = RAM enabled).

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

I looked at your pictures, 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.

> I kind of have some fuzzy ideas as to

Not analog, it's just the design rules are different for
TTL than CMOS.  Unconnected TTL inputs "float high", and have
to be actively pulled low.  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 float low as hi,
and an unconnected CMOS input will pick up enough influence
just out of the air to flutter back and forth between lo and hi.
As such, a CMOS input can be pulled lo or hi with a resistor.

> 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 more.)

> But that way, by flipping the switch, ROM_TOGGLE could be

Might want to make switch select pull-up or pull-down
(use one res, and spdt switch to select +5 or gnd).
That would avoid possibility of having p28.3 pegged to
+5v when it is in output mode driving low.

> inputs are connected like that.

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

> myself, but so many wires involved.  I think I'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.

> to get into the Yahoo apps menu and run stuff at this point.

Offhand I can't say what 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 page, and just
reflash the other three pages with code from your dump?

> bits of the parallel port for something.

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.
And now that I think about it, the way mine works
you could print to your hearts content, and the
flip-flop is gonna stay flipped.  And you won't
even get a glitch on your printer when flipping
the bank, 'coz bank switching does not activate
the printer port strobe!

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

> One could interface an SD

That would be pretty 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. things that my girlfriend (and family)
have been nagging me about.  :-(

CJ

---

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Tue, 23 Sep 2008 03:28:31 -0000

> 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 the html page, instead of embeded image...
 
http://tech.ph.groups.yahoo.com/group/mailstation/photos/view/535c?b=2&m\
=f&o=0
<http://tech.ph.groups.yahoo.com/group/mailstation/photos/view/535c?b=2&\
m=f&o=0>

CJ

---

From: "Jeff" <fyberoptic1979@...>
Date: Tue, 23 Sep 2008 05:07:45 -0000

> the cpu is CMOS.  I would replace the LS parts with

Oh wow, somehow I got it into my head that the LS parts were better 
than CMOS!  I've mostly messed with older electronic devices, since 
they're usually the only things easily modifiable for me at this 
point.  And I don't even 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 something else (to better 
warrant the shipping costs and all), since 74LS is 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 the pull-up resistor.  I tried a 4.7k at 
first, which only half-worked.  When I used it to force the 
ROM_TOGGLE line high, I watched my test app displaying bytes from a 
slot 0 memory address, and they constantly jittered back and forth 
between devices.  I ended up using a 1k here too, which appeared 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 
passing ~2.5v into ROM_TOGGLE, unless the P28.3 and the three TTL 
chip inputs affect that in ways I don't realize.

I don't really care for using these parts 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 eliminate from 
a design.  A board I was making for my NES before would end up using 
less than half the chips!

> the vias for attaching the wires.

That's yours?  I didn't realize due to the 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 get a 
clean wiring job like that!  I used long wires that twisted onto 
wires 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 even sure if what I was doing was going to work, after 
all.  It was a relief 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 something 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.

> reflash the other three pages with code from your dump?

I did notice that 16K chunk.  I was just afraid I might write code to 
erase and rewrite it, but have some unexpected 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 enough to run the 
loader app.  I guess I'll just take the plunge sometime and see how 
it goes!

> have been nagging me about.  :-(

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 tried to work with it via a PIC once to talk to a PC, but 
the protocol confused me at the time.  I haven't looked at it in a 
long time since then.  I should learn more about it though, because 
interfacing things with USB could be neat.

Another thing I thought about in regards to disconnecting the modem 
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 
have 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 parallel port pins working together properly, 
particularly since some of them are inverted.  If I ever had to write 
code for a parallel port communication 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 serial port, I guess the problem that arises is how 
one would deal with flow control and timing.  You'd probably need an 
entire UART and not just some simple level conversion and junk.  
Using a PIC or an AVR might accomplish such a task, but it's starting 
to add in more complexity and power consumption than it might be 
worth.