Write-Protected? My foot!
Philippe Teuwen
Hi everybody,
You can write on a write-protected card!!!
(I don't know if it's new for you but for me yes!)
Everywhere, men and books said me:
If you want to make dangerous things (like ML or SysRpl)
take a RAM card and write-protect it.
What I've done in fact is I've added some chips (->384k on my G)
and write-protected them.
But in some very big crashes, my port1 and/or my port2 were corrupted.
Because of that, I've thought to make a routine to write on a
protected card.
In fact, I've just decompiled the HP routines and breaked the
read-only test.
Here is the result: STOLIB can store a lib(and only a lib) in a port
#2: library In fact it works only on my port2
#1: real (port) but not on my port1 (->makes a reset and it's all)
PURGLIB can purge a lib in a port
#2: real (Nr of the lib)
#1: real (port)
I hadn't any memory corruption but take obviously care in using these progs.
You see what I mean (No Warranty ...)
If someboby can try them on a real card and give me the results,
it'll be very pretty.
Here follows the UU version and the ASC one.
section 1 of uuencode 5.15 of file stolib by R.E.M.
end
sum -r/size 21933/243 section (from "begin" to "end")
sum -r/size 6193/158 entire input file
section 1 of uuencode 5.15 of file purglib by R.E.M.
end
sum -r/size 9740/154 section (from "begin" to "end")
sum -r/size 48110/93 entire input file
ASC Version of STOLIB
"D9D20D8A812BF81119201F800D9D201DF60D9D201EC269314076D362FF402C23
0ED1804423032230D9D20FEF303D816B7290D9D205923016A26CAF062C23092A
3699016D9D202BAA04C0164C0162FA30B9F06FDD362FF405AC26B21302A17088
13028BA0EE1709EF805E17000327A852632230520905AC2621D36EFF407EE06B
BF066B4364C016EB090B2130B2130B2130B2130B213025B9"
ASC Version of PURGLIB
"D9D20D8A812BF8199040D9D201DF60D9D207F491881309314076D362FF40FEF3
03D81665490D9D20D9D202BAA04C0164C0162FA30B9F06FDD362FF405AC26B21
304D39048916F1490722B0B2130B2130B2130B213028BD"
--
SIGNATURE
.=cccccccccccccc ..ccccccccc ..=cccccccc ..ccccccc ..ccccc .cc .cc
:::"$$$$$$$$$$$$$$$b ::$$$$$$$$$$$$b::"$$$$$$$$:$$$$????$b:$$????$b`:"$cc$"
`:::"$$$$""""""""$$$$b:"$$$$""""""$$$b:"$$b''''::$$b:'''''::$bשש`:$b `:$"$b
`:::"$$$bשששש`:::"$$$b:"$$$bששש`::"$$b:"$$$$$$b::$$b .cc$b:$b `:$b.$?`:$b
`:::"$$$b `:::"$$$b:"$$$b `::"$$b:"$$b:::'::$$b ''c$b:$b$$??"`:' `''
`:::"$$$b `:::"$$$b:"$$$b `::"$$b:"$$b `::$$bccc$$?`:""::''
`:::"$$$b `:::"$$$b:"$$$b `::"$$b:"$$bccc$$:???"""::' `''
`:::"$$$b `:::"$$$b:"$$$b `::$$$b:"$$$??"":`:::''
`:::"$$$b `:::"$$$b:"$$$bccc$$$$$"`:::::'''
`:::"$$$b `:::"$$$b:"$$$$$$??"":'
`:::"$$$b .cc$$$$$$`:::""::::''
`:::"$$$$$$$$$$$$??"' `''''
`:::"$$$$??""".:::'
`::'.:::::''''
`::'''
Dave Arnett
I'm replying by e-mail, and by post to comp.sys.hp48. This topic
touches on some issues of general interest as to how HP48 card
slots operate. This information has been discussed on the newsgroup
before, but not in this context.
Thanks for asking, Philippe.
[bits deleted]
I found you post quite interesting, as I thought through
what you did. Let me give you some background on memory card
write-protection and then discuss your message.
BACKGROUND
-----------------------------------------------------------------
The HP48SX had three layers of write protection:
1. The Seiko-Epson memory cards contain write protection.
Seiko-Espon is the OEM manufacturer for HP brand cards. They
developed the format, connector and pin definitions for the memory
card interface. We have a slightly modified version of their
standard card where the low battery alarm limits are changed
slightly.
On an HP-branded RAM card, if you move the write-protect switch
to the Protect position, two things happen. First, the card itself
ignores write cycles. This is the first layer of defense for data
integrity. The card also changes the voltage level of one of its
output pins to tell the HP that it is write-protected.
2. The HP CPU chip detects the write protect indicator line of the
card. If it is reporting as unwriteable, the hardware locks out
write functionality from the CPU chip. This is the second layer of
defense. If this Card Detect line reports as writeable, then write
transactions are permitted in hardware. If the Card Detect line
floats, the hardware reports that no card is installed.
3. The HP system firmware checks the status of the write protection
bits before writing to a memory card. If the status bits indicate
that the card is unwriteable (ROM or protected RAM), then the system
code refuses to write to the card.
In developing the HP48GX, we changed card handling in some
significant respects. I have recently posted information to the
newsgroup on how the upper half of ROM and the card slot 2 are
controlled through one pin of the Yorke CPU IC in a multiplexed
fashion. There are some details about the Yorke chip related to how
various Saturn Bus deviced configure and unconfigure which required
me to make the following hardware assignment changes:
Hardware Resource HP48SX HP48GX
CE1- Card Controller 1 Card 1 Bank Select Controller
CE2- Card Controller 2 Card 2 Card 1
CE3- Card Controller 3 Unused Card 2
CDT1- Card Detect 1 Card 1 Card 2
CDT2- Card Detect 2 Card 2 Card 1
Clearly, we had to assign Card Controllers and Card Detects in
pairs, as much as possible. Otherwise the hardware lockout
would make a mess of things.
A write protected RAM card in GX slot 1 has hardware lockout
protection, since CDT2 can lock write actions to CE2.
A write protected RAM card in GX slot 2 does not have the same
HP hardware protection. CDT1 is hardware coupled to CE1, which
drives the Bank Select Controller. Some may have wondered in my
recent posts why the protocol for setting up bank settings uses
READ operations rather than WRITE operations. Now you know: A
WRITE operation to the Bank Select Controller would be ineffective
if a ROM or Write-Protected RAM card is in Slot 2!
The closest approximation to hardware write protection lies in
the BEN (Bank Enable) line, which is bit 6 of the Bank setting.
Unless BE is set high, all attempts to access slot 2 are forbidden.
BEN is pin 10 of the 74HC174 chip. This line goes to pin 5 of the
NAND chip to prevent Card Pin 21 from going active.
The protocol in the HP48GX RPL Opertaing System implementation is
to always leave BEN low, unless slot 2 activity is needed. BEN
should be set low again after card access is complete.
So an HP48GX has three levels of card write protection as well:
1. The card should prohibit Write activity if the protection switch
is set.
2. Slot 1 has the same hardware lockout as in the SX. Slot 2 has
a multi-step process necessary to enable access.
3. The RPL system code checks the write-protect status before
writing to a card. It understands that CDT1 and CE3 map to card 2.
END OF BACKGROUND MATERIAL
-------------------------------------------------------------------
I will have to guess about some things not clearly detailed in your
message, Philippe.
How have you handled the three levels of protection?
1. You apparently aren't using a memory device that implements
Write Protect. If you did, the HP could not write to it. I
assume that when you say you Write Protect your RAM chips, you are
really only asking the HP to not write to them by changing the
setting on the CDT lines. To truly write protect your RAMs you
should also drive the NWE (or WE) line of the RAM device
appropriately, and not give the HP control.
(Remember c.s.hp48 folks, this is a home-modified HP48G, not a GX)
2. Your STOLIB code does not affect your virtual Card 1, but it
does get to your virtual Card 2. This shows the difference between
the two hardware lockout techniques. I expect that BEN is set
during the early part of the process so that the system can read
from the card in slot 2, which is why the write action is permitted
in hardware.
3. You deliberately disable (skip) the read-only test, so this third
level of protection is taken out of play.
So if we are looking at comparable corruption of a write-protected
memory card during a system crash, we have to:
A. have the card's protection hardware fail or be missing;
B. be in the middle of a slot 2 interaction, run code which sets BEN
deliberately, or have a crash which happens to access the right
stuff to set BEN during the crash;
C. have the crash write into the CE3 memory space.
The protection scheme on the HP48 is not completely pefect; no data
protection scheme is perfect. I think it is fairly robust.
Dave.
-----
I don't speak for HP when I post here.
I do not recommend that users modify the hardware of their
HP48 products.
I'm glad we have such a technically competent and motivated customer
base that users do all kinds of things, including hardware mods,
and end up asking these kinds of questions. You folks constantly
amaze me!
I'm happy to provide unofficial information to help you folks.
Please use this information with appropriate skepticism; I do make
mistakes, and I do not consider myself a competent RPL programmer.