Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!border1.nntp.aus1.giganews.com!nntp.giganews.com!nntp3.aus1.giganews.com!bin2.nnrp.aus1.giganews.com.POSTED!news.clear.net.nz!not
From: Jonathan Purvis <n...@this.address>
Newsgroups: comp.sys.hp48
Subject: Re: Port EMU 48 to Palm OS?
Organization: http://homepage.mac.com/fluke/
References: <F6D08.97920$va.45585798@news2.rdc1.mi.home.com> <a21mff$j3g$1@casey.uvic.ca> <88fc1a21.0201152256.35a260cb@posting.google.com> <aapvtf$covop$1@ID-88878.news.dfncis.de> <460a25b9.0205081451.5b394132@posting.google.com>
User-Agent: MT-NewsWatcher/3.2 (PPC Mac OS X)
Message-ID: <not-0F7A7E.22470512052002@news.clear.net.nz>
X-Original-NNTP-Posting-Host: 203-167-148-5.dialup.clear.net.nz
X-Original-Trace: 12 May 2002 22:47:10 +1200, 203-167-148-5.dialup.clear.net.nz
Lines: 47
NNTP-Posting-Date: Sun, 12 May 2002 05:47:13 CDT
X-Trace: sv3-saqmbB4qWl36oQryL8pJ1+vYtF9FcUCCVxEOpUu1U+t/EGu0FsbcUjP5Vl0SWCyXVcMA0ceEg1MJ+S2!RYFA3Gf7J0XF0CwpixFFTphXif+FdKlRIg7SFj2svYcNt5E280QEZDRmJGncfMGhuPrlvTa36aDN!otNbzrU=
X-Complaints-To: abuse@GigaNews.Com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-Info: Please be sure to forward a copy of ALL headers
X-Abuse-Info: Otherwise we will be unable to process your complaint properly
Date: Sun, 12 May 2002 10:47:13 GMT

In article <460a25b9.0205081451.5b394...@posting.google.com>,
 rgd...@aol.com (Dylan Stewart) wrote:

> "HPhreacker 2002\(?\)" wrote in message:
> >  If we can compact the rom [sic] ...
> 
> This would be fairly hard to do.  Apparently, you are limited to 256kB
> of heap, and I am guessing that the ROM of a 48 is more than 512kB. 
> It would be nearly impossible to get 50% compression for something
> that is not very redundant.  You could use a sort of paging system,
> but that would be excessively annoying.
> 
> I am guessing that the biggest part of the OS, other than the normal
> math operations, is the UI, so it could be contained in one image and
> the other stuff in the other image.  You do not exactly need most of
> the UI to be running when you are running a program (ex. filer, y=
> editor, etc.).  If you page between the UI and the rest of the ROM,
> there should be little overlap.  A better idea might be to make the
> math part of it as a data file.  The emulator could lookup what to do
> as it encounters various math operations.  This would make the
> emulator slower, but it would not require paging as much.
> 
> Is the 256kB limit there is asm?  If not, an emulator could be written
> in it and the entire ROM could be used.

PalmOS divides RAM into two sorts, dynamic and storage.  The dynamic 
heap is used for program stack, global variables and anything the 
program allocates on the fly.  It's 256KB on an 4 or 8MB device (128KB 
on a 2MB device), though, the OS takes around 64KB of that.  The storage 
heap is used to store databases and is write-protected by the hardware.  
To write to the storage heap, you have to go through OS functions which 
check you're not overwriting anything you shouldn't be.  Whilst you 
couldn't allocate enough dynamic heap space to emulate more than a 48G+, 
you can store the ROM image in a database and have full read only access 
to it.  In fact, i have 48G and 38G rom images stored on my TRGpro (8MB 
PalmOS device with CF slot, see http://handera.com) and wrote a program 
to check the CRCs.  It takes about 20s to check one, but i'm sure it 
could be speed up with some assembly language.  (The C code uses about 3 
dereferences, a test and a shift/mask per nibble.)

Email me at (jon AT purvis DOT co DOT nz) if you'd like a copy of the 
source.


Later...

        Jon