From: Steve Sousa <etsteve@my-deja.com>
Newsgroups: comp.sys.hp48
Subject: The How's and Why's to the HP48 Lobotomization and other memory interventions
Date: Wed, 30 Jun 1999 04:29:07 GMT
Organization: Deja.com - Share what you know. Learn what you don't.
Lines: 496
Message-ID: <7lc6ea$47d$1@nnrp1.deja.com>
NNTP-Posting-Host: 209.198.242.35
X-Article-Creation-Date: Wed Jun 30 04:29:07 1999 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt; TUCOWS)
X-Http-Proxy: 1.0 proxy.esoterica.pt(os):80 (Squid/2.1.PATCH2), 1.0 x21.deja.com:80 (Squid/1.1.22) for client 195.22.4.76, 209.198.242.35
Xref: republic.btigate.com comp.sys.hp48:27122

On June 25, Ricardo Jasinski wrote:

> > I think it wouldn't be possible to use only one 684000 chip, as the
> > > 48needs its base memory and it can't be that big. 512k would
> > > only fit on a port (please correct me if I'm wrong!)
> > You can only use that chip for port2+ memory.
> > This happens because internal ram, port1 and port2+ use their own
> > Chip Select signal.

> Hi, thanks for answering! Could you please explain again what is the
> matter with the chip select signal? Is there a third CS signal in the
> connector bus, used for ports other than 0 and 1? If so, can I just
> connect it to the 512k chip, as well as the data and address busses,
> and it will work fine?

Hi Ricardo:
Since this doubts come frequently on this Ng, I decided to pour some of my
brains into electronic form, an this is the result:

THE HOW'S AND WHY'S TO THE HP48 LOBOTOMIZATION AND
OTHER MEMORY INTERVENTIONS:
By Steve Sousa
June 28, 1999 Version 0.01

Disclaimer:
This posting does not encourage anyone to do any physical manipulating
with their own calc. This posting may contain errors and any damage done
to your own machine, room, school, anything you own (or don't), anyone
(including but not limited) to yourself, or your pet(s) is your own
responsibility.
I have no affiliation with HP other than owning some of their products.
This work has excerpts taken from "The HP Journal" August 1994,
whose copyright owner is Hewlett Packard.
Most of the knowledge (if any) expressed here was gained by reading the
Ng postings, on the comp.sys.hp48 forum, the hp48 FAQ, saturn.txt by
Matthew Mastracci and other more generic sources since I’m an electronics
student and hobbyist.
Please note: english is not my natural language.

INTRODUCTION:

The purpose of this document is to explain (some of) the inner workings of
the hp48 calculator regarding it's memory system, and how to use this
knowledge to perform physical interventions such as increasing main or
port memory, and why some memory devices (also know as ram chips)
work or don't, how to choose their size and so.

PART ONE
IN THE BEGINING:

I will assume that you know some electronics, like what is ram, ROM, how
to use them, (that is: what do all of their pins do ;-) ), and that you WILL
read the article "An Advanced Scientific Graphing Calculator" from the Hp
Journal, August 1994, and the Saturn.txt file, you might want to check the
hp48 schematic, also available on www.hpcalc.org on docs/misc.
I will consider the Saturn as an 8-bit microprocessor, since it can be seen as
such in hardware terms. Unless I say otherwise I’m speaking of a GX.
Remember that silicon is dumb, it does precisely what the instruction it
reads tell it to do, he doesn’t understand them, or know if they are wrong,
he just executes them.

To make sure everyone understands what I’m taking about, I’ll start from
ground zero.

As you know, inside your calc there is a chip called the Yorke, and inside
of it lives the calc's processor: the Saturn. Well, this guy called Yorke is
nothing but a bunch of Saturn support chips, shrinked into a single small
chip. If you have ever seen the inside of your computer, you saw your
processor and lots of chips on the motherboard. Imagine that the Yorke is
just like that, a motherboard for the Saturn. It has memory management
chips, Input/output chips, voltage regulation, timers, etc.
Let's pretend that when you open your calc it decompresses his insides into
one such board.
You would see a Saturn processor, standing in front of you, impressing ah?
It certainly has the HP logo on it, but let's get to the point, since this guts-
decompressing calc is designed for prototyping, you will find a
connector on which you have access to all the processor's pins, and guess what?
It doesn't look different from any other processor bus you have ever seen!
it has nineteen address lines A0-A19, eight bi-directional data lines D0-
D7, and a control bus, made of the following signals:Write Enable, Output
Enable, I/O/Memory Select, Maskable Interrupt, Non Maskable Interrupt,
and perhaps other minor stuff, neglected here.

Well, to me this looks like a Z80 or an 8088/6, give it or take a few pins.
And because it looks so common (pardon the expression), we’re feeling
lucky today and are going to take our chance: yank it out!
AHHHRRGGG!!!! POKK! Geezz! They probably used some of the same
glue that the keyboard overlay has! But it is out, we throw it in the air a few
times just to show off, hanging around the corridor, trying to impress the
girls in class with it, saying things like: Hi, have you ever seen a Saturn
processor before? It’s way cool ha? to what they answer (being the
intelligent hp48 users they are), WOOOUUU, how did you get it?, then you
Say: I took it out of MY OWN calc, what do you think? but as they laugh
away down the corridor, you fall back to reality, and get back to work.

You stick it into a prototype board and say to yourself:
I want to run this thing on his own, what do I need?
Power: grab a power supply, set it to 4.5 volts.
A clock: get a 4MHz crystal oscillator.
Memory: ahhh!!! Since you are lazy, you get a 512Kb battery-backed ram,
with a PC connection, and fill it with a ROM-dump.
I/O: this would be a pain, so we connect our processor bus to the
conveniently located LCD controller connector on the calc motherboard.
Do the same with the keys.

Turn the thing on, and after the city lamps get back to full brightness, and a
time delay, (you needed to get out from under the table), you see the: Try to
Recover Memory prompt, you say no.

Now you are on top of the world, the thing works!!
You try 2 enter 2 + a 4 appears on screen, yes! It really works!
So you get clever, you write MINEHUNT enter.. PUFF, your screen
garbles, flashes and finally dies, nothing on screen, but you can see from
the power consumption that the processor is still running, what happened?
When you turned up the calc, it started at address #00000h, found that what
was supposed to be system ram, at 40000h (half of addressing space) was
corrupt, an zapped it, erased it, and wrote the system variables and screen
display data area on what was before you upper ROM dump.
(Lower ROM goes from 00000h to 3FFFFh and from now on would be
referred as Lrom, upper ROM goes from 40000h to 7FFFFh and from now
on would be referred as Urom.)

Don’t feel bad, to cheer you up, think that if you had a SX ROM dump it
would have been fine, since it only had 256Kb of ROM.

How to solve this? You need a way to put ram and ROM on the same
addresses, how do you do it? You choose to take the little steps approach:
first get it working, then solve a problem at a time.
You need at least lower memory and some ram always present at and above
40000h, so you make a decoder that when A18 goes high disables ROM
and enables ram, and viceversa. You decide to make your prototype just
like a real calc, so you get rid of your 512Kb memory-backed ram, and pick
a 32Kb one, and also pick the ROM from the calc and put it in the prototype.
You turn the thing on again, get TTRM, say no, try the tests again, and get
the same result on minehunt. What happened? a variation of what happened
before, since minehunt is located on Urom, the calc tried to access it,
but when it tried so, it read ram because your decoder makes it that way,
but the chip is a 32kb device, it DOESN’T HAVE memory above 32Kb!!,
precisely, it knows nothing of what happens on lines A15 an above,
So it output what corresponded on the lines he has. Something pretty
random for our purposes.

Now you know: you need to disable ram again, after 48000h(half address
space+ram size), adjust your decoder, and assuming minehunt is after
48000h (might not be!), it worked!!
Everything seems to work fine, but you discover that some commands
crash your machine. You get an entry points table as see that they are
located on that tiny 32Kb block that you cannot access.

By now you want a G+ so you change once again the bb-ram and use this
time a 128kb device, set it in place and try it. Minehunt fails again, why?
You have seen people upgrade their calcs just by replacing the main ram
chip, and they made no hardware modifications, you look again to your
circuit and feel stupid, there is no software on earth that can overcome a
hardware restriction, like your decoder makes, or is there?
Well.. your decoder IS hardwired, the only one who can change it is you,
using jumpers, wires or switches, but not by software, which would be
nicer. And this leads us to:

PART TWO:
Memory Controllers

Now you know that the calc has some way of disabling it’s hardware
decoders, and more, they are software controlled.
This looks complicated, a simple complementary decoder, that is, one that
selects EITHER ram OR ROM is just that: too simple. Instead of trying to
make one yourself, you look at the board and see 6 chips labeled: Memory
controller 1 through 6, and you think: SIX!!!!, what do I need SIX decoders
for?!, it goes like this: you need one for each device you expect to have
connected to the bus, and since you need the ability to disable them, it’s
better to have one for each device than sharing them, this avoids conflicts,
adds flexibility and is in fact simpler to implement, since inter-dependency
between devices can be made as a "chain", by attributing them different
priorities.

Quoting the article at Hp Journal:
"The CPU bus architecture first developed for the HP71 and used in all HP
calculators since that time has several useful features. One of the nicest is
its address configuration capabilities. All chips attached to the bus are
required to be able to change, on command of the bus, the range of
addresses that evoke a response from the chips. Such a system eliminates,
once and for all, the inconvenience and headache of configuring jumper
switches on cards designed to plug into the machine. For a consumer
product like a calculator this is not only a nicety, it is a necessity."

That says it all. But don’t think that the memory controllers are only useful
for systems with plug-in cards, as you can see it is also very useful
on a calc without them.

So we have 6 memory controllers, one for each of the following devices:
Memory Mapped Input/Output,
System ROM
System Ram
Port 1
Port 2
Bank Switch

Each one provides a Chip Select signal, when the address on the bus
matches that programmed on it.
Plug the first two on our prototype system, and their output to ROM and ram.
Now everything works fine, magically, the calc’s software is able to disable
or relocate ram in order to access the "covered" ROM, it does so by
pushing system ram up, and increasing the addresses used by the Lrom.

All the memory controllers (mc from now on) have a default start address
and size, so that when power is first applied there are no conflicts.
If two addresses overlap, however, the priority for which device
occupies the
Address space is: MMIO, RAM, Port1, Bank switch, Port2, ROM.

The ROM’s mc is set to 40000h (256Kb) size and start address is 00000h.
The ram-mc is set to 20000h (128Kb) size and start address is 40000h.
Port 1 and port 2 mc size is set to 20000h (128Kb) and start at 60000h.
Mmio and bank switch are located respectively near the beginning of Lrom
and near the end, at 80h and 3F800h, their size is 1Fh (31 bytes) and
800h(2048 bytes).

When the calc starts (I presume) it scans ram to check its size, if it
determines that there is a roll-over every 32Kb it re-configures the ram-mc
for this size and the ROM’s-mc size to the full 512Kb. This is not a
problem, because the "daisy-chain" (priority settings) tell you that ram has
priority over ROM when their addresses overlap.
If it finds a 128Kb ram chip, it leaves everything as is.
For the last 128Kb block of Urom the behavior is identical.

Let’s get physical!

PART THREE
Hands on

By this time you are thinking about getting extra memory on your calc.
When I say extra I mean EXTRA, which translated sounds like the guy at
the shop sold you something you didn’t want, that costs a little extra
and brings you no real benefit.
In practical terms you want more ram, lots more ram, loads of it, you
want
to use the so claimed 4.75Mbytes of ram Hp claimed it could handle.
Oh oh! What a surprise you’re gonna get. You have no chance to develop
your thoughts here, you have to do it THEIR way or you don’t, period.
If you have a G+ or GX there are three ways to do it. Port 1, Port 2 or both.
If you own a G, change your main ram chip to a 128K chip and go back
the previous paragraph.

Let’s start from the G up.
You have 32K main ram, you want more, well.. forget the 64Kb chips, this
size IS NOT SUPORTED by the calc, the calcs thinks it’s a G OR a GX not
a GFX (G frustrated expansion). That’s it, the OS will treat you bad if you
do it. Besides it is not money wise to do so, since the 128K chips are
about the same price. And IT WON’T WORK!!!.

You have now a 128Kb calc on your hands, call it G or G+ the only
difference is the keyboard overlay, nothing else.

So you own a G+ ha? You want more ram? Ok, let’s do it. After all, you
have been trying to give yourself a reason to open the calc.

Find a tutorial on the net. Do it. Done? After removing the overlay my
record is 34 seconds to get inside (calmly).

You want Port1 memory now, yeap, how do you do it?
You can only add 32. 64 or 128Kb on port 1.
Find a tutorial on the net, if you want to add 64 or 128Kb Port 1 memory
you DON’T need any other chips! They are only necessary for Port 2 expansions.
On most (all?) modern chips (that is: made on the last 4 years or so) you
can connect the OE line to ground, to see if this is possible you have to get
the data-sheet, and check to see if the WE line forces a high impedance
when low, if it does, you bought the right stuff if not, FIND ONE!
Connect the chip select line (positive logic) to the CE line on the
Port 1! pads.
If you only have a negative logic CE line, (this is a problem if you are
adding only 32Kb) you need to proceed as the tutorials for port 1 and 2
expansions explain and add the 74HC00 (you don’t need the other one).
Make sure that the tutorial you are reading powers the 74HC00 from the
main ram supply and not from the vcc at the port pad.
Complete, more detailed descriptions can be found on the net, remember
I assumed you DO KNOW WHAT YOU ARE DOING, DO YOU?
Port 2 is nearly the same, except that you have to add a some-lines to
some- lines decoder, chosen according to the size you are going to add and
the number of chips.

PART FOUR
What about alien calcs?

Let me guess you are trying to put a 256 or 512kb ram chip on your calc?
No, no, no..
Better yet, you want to use that same chip for main ram, port 1, and
maybe port2?
Looks like you didn’t read parts one and two.
You CAN’T!!! Well.. it is "technically" possible, if you are willing to
waste all the chip’s capacity above 128Kb.
Why? It goes like this: the hp can handle memory from 00000h to 7FFFFh, right?
Let’s discard the 4 least significant nibbles. We get the last 3 bits,
that is lines: A16, A17 and A18.
A 128K chip has lines up to A16, a 256K chip up to A17 and a 512K chip
gets them all up to A18.
I assume you know binary, but here you have a resume:

Bin-Hex
000-0
001-1
010-2
011-3
100-4
101-5
110-6
111-7

The most significant(left) bit is the state of line A18, the middle is
the state of line A17, and the rightmost is the state of line A16.

Now a little map of HP memory:
(Please check this against figures 7 and 10 of the hp journal article
and see
how it relates to them)

000...001|010...011|100...101|110...111
0       128       256       384     512


You can see the changes of the top 3 address lines can you?
You can also see that a 128k device handles only A16, a 256k A16 and
A17, and a 512k device all three right?
Let’s connect your 256k device on our prototype.
(This time its me who hides under the table)
It is supposed to be 128k main memory and port 1.
In order to make the chip respond to both mc select lines, the one for main
ram and the one for port1, you need to combine both of this signals into
one, (it’s only ONE chip remember?), you need a circuit that goes low
when either of them is low, an AND or a XNOR gate would do it.
You can see from the graphic that the first half of your chip would be
addressed as main ram and the upper as port1, since the chip ignores A18
(it doesn’t have it). Minehunt works, you even store an object o Port 1 and
it works. But what happens when you run one of the commands located on
the lower half of Urom? The calc moves the start of main memory to
60000h but your chip doesn’t think so. From his point of view, he responds
to the state of HIS lines and they tell him to read and write from his upper
half, you say: wait! Wasn’t that my port memory address space?!, you are
right it WAS, now it has somewhere the results of the operation, if you are
really lucky (this is highly unlikely) or it would have crashed because it
read port memory instead of the data it was supposed to receive from the
transfer area at main ram.
Something like this would happen with a 512K chip, the difference would
be that you waste the lower 256k of it and you get an extra way to crash
your calc. This would happen the day you want to run some particular game
or ML prog, that relocates main ram to 00000h, in which case you would
access empty space when relocating. (guess what happens. :-) )
This occurs even if you connect only the main or the port 1 chip enable mc
to your chip, because it still responds to the address lines. The only
way to use such a chip is grounding the A18 and A17 lines and using it for
EITHER function. Or for port 2.. (much better, and wiser).


PART FIVE
The end

I hope this helps (anyone) to understand the delicatessen involved when
you want to change something on the calc's brains.

Please note that I don’t believe that if you could perform most of the steps I
told you when building the "prototype" it would work. It’s almost certain
that several routines of both halves of Urom are used at start up, and more
elaborated ram checks are performed making impossible for the virtual calc
to boot. However all the issues I have addressed related to the memory
addressing are (believed to be) correct, if you accept that all the calcs
startup routines are on Lrom, and minehunt is on the upper half of
Urom ;-)

However it is HIGLY UNRECOMMENDED that you remove your Saturn
processor from the Yorke...

For any comments and/or suggestions, feel free to e-mail me at:
etsteve@xstudent.ua.pt Remove the anti-Spam x from this address before
replying.


Copyright Notice
This text is copyright of Fernando Steve Domingues Sousa
You may only distribute it freely, unaltered, and use it only for non-
commercial use.

Last Change: June 30, 1999, 3:32 GMT