Installing latest 49g+/50g (emulator) ROM on a 49G
in [HP48]
|
From: manjo on 20 Dec 2006 16:20 > So they should be on *EVERY ROM* > Perhaps we will have a HP 50GS (S for Spreadsheet) > with a 4MB Flash ROM, 2MB for OS and 2MB for the user > OS could then include in one bank a new extable 3 > with also the Spreadsheet & Geometry package > supported entry points included > :-D There you go VPN -again with lagrer Flash and RAM :-) Hehe is it your whish, your dream or a nightmare ? :-) manjo
From: Veli-Pekka Nousiainen on 20 Dec 2006 16:59 "manjo" <not-available-spam(a)rocketmail.com> wrote in message news:emc99b$lts$1(a)ss408.t-com.hr... >> So they should be on *EVERY ROM* >> Perhaps we will have a HP 50GS (S for Spreadsheet) >> with a 4MB Flash ROM, 2MB for OS and 2MB for the user >> OS could then include in one bank a new extable 3 >> with also the Spreadsheet & Geometry package >> supported entry points included >> :-D > > There you go VPN > -again with lagrer Flash and RAM :-) > > Hehe > is it your whish, your dream or a nightmare ? :-) The product clearly needs several upgrades They can be also gradual since the component prices decline differently Flash is cheap so I do wonder why not design a new "motherboard" SRAM is more expensive so care is needed for the upgrade moment and also a study if it really is needed The options always need a view of the market as a whole One can't just support a bunch of enthusiastics but a leadership is also needed (since HP *is* the best - after all) I just pray the God Allmighty that I could do something about it -- Happy Chrustmas!
From: manjo on 20 Dec 2006 18:01 > The product clearly needs several upgrades > They can be also gradual since the component prices decline differently > Flash is cheap so I do wonder why not design a new "motherboard" > SRAM is more expensive so care is needed for the upgrade moment > and also a study if it really is needed > The options always need a view of the market as a whole > One can't just support a bunch of enthusiastics > but a leadership is also needed (since HP *is* the best - after all) > I just pray the God Allmighty that I could do something about it > -- > Happy Chrustmas! Actualy... no need for major changes in motherboard. RAM and FLASH can be expanded by soldering second chip on top of the existing one and feeding new set of CE and OE signals (address and data lines are shared anyways) Main concern would be to lead out all those usefull signals out of processor and make them accessible like test pods or something. You would solder more ram and/or more flash, lead corresponding CE, OE, RW signals and everything could be doubled in notime. Maybe in future versions soldering pads for RAM to be for 1 MB chip (one could solder full size 1 MB or adopt 512 kB to it) Intelligent keyboard overlay ? -front faceplate would come off as a single (or 2) modules similar to some cell phone skins (keys may be separate from faceplate) -then you would attach for example QWERTY overlay with apropriate face cover and keys -by means of contacts / switches (or optics) calculator would recognise the type of overlay and adjust accordingly -there would be 4 major overlay types: 1. standard (like it is now) 2. oldfashion (with large enter key -two nearby keys would act as one) 3. developer/querty-like (not realy a querty keyboard, but keyboard with key arrangement optimised for text and numbers entry rather than calculator operations) (or maybe landscape-oriented screen and qwerty keyboard) 4. user defined I'm i dreaming or what :-) ? manjo
From: John H Meyers on 20 Dec 2006 21:34 On Wed, 20 Dec 2006 08:38:11 -0600, James M. Prange wrote: > But there *is* new Saturn+ code in the HP part of the ROM > for the actual 49g+/50g, but not in the ROM for Emu48. How do you see that? Are you using the "Nosy" library? Have you compared ROM byte by byte between emulator and hardware, and found that no code has been relocated by even a single nibble between these platforms, but only a couple of bytes have here and there been altered? According to your time-stamp research, this must mean that any such changes (such as overlaying the start of extremely common ML "Loop" code by one such instruction that is *interpreted* by the ARM emulator as meaning to do this particular whole sequence faster) are applied *afterwards*, while making a file to be used for an ARM calc ROM update (which combines ARM OS and Calc OS). IIRC, the extremely commonly used supported ML return point GETPTRLOOP (at 05143 in both 48 and 49 series), whose "Loop" part at 05149 is one of those very frequent code snippets that can be accelerated, as was detailed in a newsgroup post not too long ago, didn't actually get accelerated at all in 2.09 -- anyone curious can compare with "Nosy" in emulator vs. hardware for the same ROM version, and see whether any particular "Loop" code got accelerated or not, but no harm occurs if any were missed, except for a little less than maximum warp speed :) Evidently the Calc OS compiler/assembler is fed only a language that it's always known, and outputs what has always run on emulators (or on what's being emulated), as might be expected by the fact that the ARM OS is just another emulator, doing a good job of making an identical environment that runs the original ROM code, this being the entire basis of the almost complete compatibility, preserving and lengthening the profitable lifetime of the original product line, and the massive collection of third party software which also enhances its value. But of course this is of only academic interest, for people who want to play with emulators, and has nothing to do with the mouse who lived under a granary, under a small hole, until the widening of the hole attracted the attention of the farmer, who then permanently boarded it up. -[ ]-
From: James M. Prange on 24 Dec 2006 22:52
John H Meyers wrote: > On Wed, 20 Dec 2006 08:38:11 -0600, James M. Prange wrote: > >> But there *is* new Saturn+ code in the HP part of the ROM >> for the actual 49g+/50g, but not in the ROM for Emu48. > > How do you see that? Are you using the "Nosy" library? No, at least not yet, but anyone is welcome to do some research with Nosy. > Have you compared ROM byte by byte between emulator > and hardware, and found that no code has been relocated > by even a single nibble between these platforms, > but only a couple of bytes have here and there been altered? Well, I've now had a better look, but please understand that I've been using a *text* editor with some limited binary/hex editing capability added in, not an editor designed "from the ground up" mostly for working with binary/hex files, so there's some doubt as to the thoroughness and even the accuracy of this. Working with nibbles instead of bytes is rather difficult in any PC-based editor that I've ever tried, and ROMG+.49G seems to consist of bytes with values from 00 through 0F. I surmise that nibbles have been expanded into bytes for ROM+.49G, which would make sense for using it with a PC. My process was to expand the nibbles in a copy of the 1264KiB 4950_92.bin to bytes, resulting in a 2528KiB file. Comparing this modified file with a copy of the ROMG+.49G, it turns out that the first 480KiB isn't present in the ROMG+.49G file; I suppose that it's for loading the file on the calculator and running the Saturn+ emulator. Editing out that first 480KiB gave me a 2048KiB (2MiB) file. ROM+.49G is 4MiB, but the last 2MiB (and then some) appears to be padding, so I edited that out. Now both 2MiB modified files have some padding, but it turns out that they're *mostly* the same, with a few bytes "here and there" different. The other bytes aren't "shifted"; they have the same offsets into the modified files. From here on, I'll refer to the bytes in the files as "nibbles", as it's more convenient and the high-order nibble in each byte is always 0. The most frequent difference is that in several (but far from all) places, the nibble sequence 142 in the Emu48 file has replaced by 81B in the calculator file. To put this into context, 142 isn't replaced except where it's the beginning of 142164808C or 142164131, and not always even there. Of the 412 occurrences of 142164808C, 393 have been replaced by 81B164808C, and the other 19 have been left as is. 17 other changes, 1 place each: 80A203400100805340 -> 80B040100100805340 (1 of 2 places) 8AE4003D -> 80B2401D 340000C80580580580 -> 80B140180580580580 (1 of 2 places) 427D91 -> 81BE91 13706D90620D18718 -> 81BA6D90620D18718 142164131 -> 81B864131 8ADAC -> 81B9C 146132C21345B -> 81BB32C21345B D214EC6132C2134161 -> 81BCEC6132C2134161 (1 of 2 places) D9136184142132D8E7 -> 81BD6184142132D8E7 (1 of 3 places) CF43D1 -> 80B301 CE4C480 -> 80B7001 CE49480 -> 80B6001 20818F2 -> 80B8001 7F40152 -> 80B2001 808240CE -> 80B1001E 20340CA30D -> 80B40CA30D Some of the above replacement sequences already exist elsewhere in ROMG+.49G. 8 changes (1 place each) that come just before what looks like padding -- ends of blocks? CRCs? 87640FFF... -> A74D0FFF... 7788FFFFFF000... -> 0836FFFFFF000... E58100FF000... -> BDD300FF000... 079200FFF... -> 175C00FFF... F4290FFF... -> 1F670FFF... F77FFF... -> C81FFF... C40FFF... -> 3BFFFF... 9FCF00FFF... -> 572600FFF... I haven't researched what all of these changes accomplish, but it seems to me that a reasonable guess would be faster execution. I suppose that some of them might not make much sense without analyzing what the contiguous code does. It may be that some of the potential replacements that seem to fit the (limited) pattern but weren't done wouldn't actually work. > According to your time-stamp research, this must mean > that any such changes (such as overlaying the start of > extremely common ML "Loop" code by one such instruction > that is *interpreted* by the ARM emulator as meaning > to do this particular whole sequence faster) > are applied *afterwards*, while making a file to be used > for an ARM calc ROM update (which combines ARM OS and Calc OS). Well, I wouldn't call it "research"; I just happened to notice that the time-stamp on the calculator ROM is a little later than the time-stamp on the Emu48 ROM. This suggests to me that maybe the calculator ROM was made from the Emu48 ROM, or perhaps both from shared source code, but of course there could be many other reasons for those time-stamps. Based on my "closer look", it looks to me as if it was a matter of replacing certain sequences of nibbles (I guess still expanded to bytes) in the compiled version of ROMG+.49G. My guess is that these changes were easy to make to a copy of ROMG+.49G and resulted in some improved performance. > IIRC, the extremely commonly used supported ML return point > GETPTRLOOP (at 05143 in both 48 and 49 series), > whose "Loop" part at 05149 is one of those very frequent > code snippets that can be accelerated, > as was detailed in a newsgroup post not too long ago, > didn't actually get accelerated at all in 2.09 -- > anyone curious can compare with "Nosy" > in emulator vs. hardware for the same ROM version, > and see whether any particular "Loop" code > got accelerated or not, Okay, some potential "accelerations" weren't done; I don't know why. Perhaps they would've required shifting other code, or making changes elsewhere, or maybe the developers just didn't bother. After all, sometimes "good enough" really is good enough, and there's are lot to be said for a "don't fix what ain't broke" policy. > but no harm occurs if any were missed, > except for a little less than maximum warp speed :) Indeed, all hardware Saturn (or Emu48) code should run on the emulated Saturn+ processor in the ARM-based models. > Evidently the Calc OS compiler/assembler is fed only > a language that it's always known, > and outputs what has always run on emulators > (or on what's being emulated), > as might be expected by the fact that the ARM OS > is just another emulator, doing a good job > of making an identical environment > that runs the original ROM code, Feel free to follow my procedure for finding the changes, and then modify a copy of ROMG+.49G to match, and try it out on Emu48 or a real 49G. > this being the entire basis of the almost complete > compatibility, preserving and lengthening the > profitable lifetime of the original product line, > and the massive collection of third party software > which also enhances its value. > > But of course this is of only academic interest, > for people who want to play with emulators, > and has nothing to do with the mouse who lived under a granary, > under a small hole, until the widening of the hole > attracted the attention of the farmer, > who then permanently boarded it up. -- Merry Christmas! James |