Jazz 50G and SysRPL Debugger updated
in [HP48]
|
From: John H Meyers on 29 Jun 2010 20:17 On 6/29/2010 6:18 PM, Andreas Möller wrote: > As a matter of fact EMU49 and the 50g use different ROMs > (you know that :-) The only difference between my Emu48 and my [ARM] calculator ROMs is that at various locations which call a few very common ROM functions (mainly to shift large chunks of memory and to return to RPL), the [ARM] calculator ROM has an overlaid "hook" to invoke an ARM-based function having the same exact result, where Emu48 (and my old HP49G) still follow the original Saturn code -- again, with identical result, the purpose of these "hooks" being simply to speed up those few (but frequently called and time-consuming) functions even more than going through the normal Saturn emulation. I call this "identical" > and also the emulation of the original Saturn is not the > same. The carry flag inside of the emulated Saturn behaves different, > but don't ask which is right or wrong. Miraculously enough, no program that I have ever used (or written), nor apparently all of the programming in the ROM itself, has ever behaved the slightest bit differently between all of my calculators and Emu48, so this must not have so great a significance as it sounds ;-) You are just one rare programmer who has managed to write things so deeply dependent that it may affect your own program(s). > Conclusion: If one wants to write new software for the ancient Saturn > one must know the differences depending on where you want to run your > code. www.hpcalc.org contains (how many? thousands?) of programs for the HP49G/49G+/50G series -- how many don't run identically between calculators and emulators, other than by virtue of bugs involving things like not checking for screen height, or other issues equally irrelevant to the one you raise? And the entire ROM itself -- does anything in it (other than the beeper :) not work when emulated by Emu48, or by the ARM emulator? I guess this is an unending chat between us, where you eternally assert this problem of yours, while I eternally remind everyone of how little it matters to anyone else. Like "kryptonite," it seems to affect no one else but Superman himself :) [r->] [OFF]
From: Han on 29 Jun 2010 20:24 > There must be some misunderstanding here. FlashBanks were introduced > with the49G, the 48GX has no FlashBanks but uses a technique called > "covered ROM" which is still present in the 49G. "Covered ROM" I was referring to the technique of covering and uncovering memory. From a programmer's point of view, a flash bank is no different from a RAM card, ROM card, built-in ROM, etc. They're all just blocks of memory that are either configured or not configured, and viewable or not viewable. The technique of covering and uncovering memory has been around for some time. > contains built-in libraries which means that you can take over them by Covered ROM could contain anything, or even nothing (such as the block of ROM covered by hardware I/O addresses). As I understand it, covered memory is just a configured block of memory (RAM/ROM/Flash/etc) with lower priority than some other memory device/block with higher priority. Theoretically, it should be possible to program your own OS, write the the data to a specific flash page available to users, then configure that page to cover the ROM in the #00000 #3FFFFF range, and have your new OS take over. This, of course, would much more difficult than simply replacing some built-in libraries. Your new OS would have to have its own interrupt system, handle the configuring and unconfiguring of flash pages, etc. > exchanging the hash table (but be aware of the STO bug in the 49G Are hash tables actually exchanged? I thought this could be accomplished simply by repositioning the library address and configuration address within ROMPTAB (so that the modified library's configuration information appears before the built-in one). It's the same idea as with covering memory. Or is this what you meant by exchanging hash tables? > which zeroes this pointers everytime something is stored in a port). Is this bug only on the HP49G? Or does it affect the 49G+ and 50G? When you store something into a port, I was under the impression the OS has to reconfigure the ROMPTAB to account for what may possibly be a new library that just got stored into port. Each entry includes an address pointing to the library id, and an address to the configuration routine. When it rebuilds this table, most built-in libraries have higher priority. I believe that the code first checks the visible memory blocks for libraries, then it starts to look for libraries that are in covered memory blocks. So many of the built-in libraries get their configuration address set to 0 to signify that CONFIG/UNCONFIG is not necessary to access the library contents. Or were you referring to a different set of pointers? > I think that emulators and debuggers should all simply "follow the ROM"; > otherwise the results are not what will really happen in the calculator, > but instead will be results which can occur only in the emulator or debugger. I'm not sure I can wholeheartedly agree here. The point of an emulator is to emulate -- be as close to the real thing as possible. The point of a debugger, though, is to try to find bugs that the user created. When there is a bug in the ROM, that is not a bug created by the user's source files. If the debugger emulates the ROM exactly, then the user's results may be wrong -- but not because of a bug within his own code. This was why I was debating whether SDB's emulation of CK&DISPATCH1 (and hence, all related dispatch entries) should duplicate the bugs in ROM. In the end, I decided that it was better to just warn users about the bug in the ROM, and write the CK&DISPATCH1 emulation to behave as it is supposed to (without bugs). That way, users won't get a wrong result and wonder if there's a bug in SDB itself, let alone the ROM =)
From: Andreas Möller on 29 Jun 2010 20:59 Hello, > Of course, all versions through 2.10 also run fine on HP49G, > although getting the 49G updated needs an emulator's help, Thanks again for telling me what I described first in this newsgroup, although a detailed explanation based on my post was given by James M. Prange. > Miraculously enough, no program that I have ever used (or written), > nor apparently all of the programming in the ROM itself, > has ever behaved the slightest bit differently > between all of my calculators and Emu48, > so this must not have so great a significance as it sounds ;-) There are two possible reasons for this: 1. You have never written an advanced Saturn-ASM program 2. You did not dig deep enough in the ROM, maybe you do not want to awake the Balrog as the dwarfes did when they dug to deep in Khazad- dûm I could show you both but most likely it would not make a difference to you. Some examples for programs that rely deeply on the underlying microprocessor: Compiler/Decompiler (Jazz) Compressors/Decompressors (BZ2) Memory movement/access to covered ports (usually part of program) SOL-replacements (MLP) ML-code making decisions based on the state of the carry flag (advanced speed up for ML programs) etc. > You are just one rare programmer who has managed to write things > so deeply dependent that it may affect your own program(s). All programs that I have written behave correctly to the original physical Saturn (which also contains some bugs which can be used as a feature). Forgive me if I corrected bugs in the ROM that I encountered when I developed my software. And IMHO a bug is not a matter of how many use or not use an existing API. As a matter of fact I had to adopt/change parts of it for the emulated Saturn. > I guess this is an unending chat between us, > where you eternally assert this problem of yours, > while I eternally remind everyone of how little it matters to anyone else.. There is no problem of mine, except that I dug to deep, even deeper than the original developers. Or, if you like that more, it is just another prove that is impossible to write bug free software but a better quality control on HP's side wouldn´t hurt. And also you might want to check Hrast programmers site for additional trouble with the Saturnator: http://www.hrastprogrammer.com/hp49gp.htm But I aggree with you: If you argue that it does not matter because the majority of the programs does not use this *then* arguing is pointless. Most likely the majority of the 50g users do not program at all, so why bother ? But for something as advanced as Jazz it might be helpful to know all possible pitfalls. Regards, Andreas http://www.software49g.gmxhome.de
From: Andreas Möller on 29 Jun 2010 21:18 Hello, > Covered ROM could contain anything, or even nothing (such as the block > of ROM covered by hardware I/O addresses). Of course you are right. What I was trying to say was that covered memory in 48GX is accessed through ACPTR whereas in the 49G the FLASHPTR configures the memory and then usually a PTR is called and therefore the FLASHPTR is faster but can not be exchanged as easily as there is no RAM "hook". As always the devil is in the details ;-) > Are hash tables actually exchanged? This can be used to replace commands of a library while still using the rest of the original library, an example is my advanced CAS help in the MLP. Also I am planning to do this with my GUISLV (if I find the time for it) to exchange the slow stuff and the unsupported display size. That way I could use my improved code together with the original routines that I do not want to replace (saves time and space). > Is this bug only on the HP49G? Or does it affect the 49G+ and 50G? This bug is present in the ROM from the very first one until today. A detailed presentation about this was given at HHC 2008 by me. If you do not have it mail me and I will send it to you. > When there is a bug in the ROM Bugzilla still list a lot of bugs for the 50g... Regards, Andreas http://www.software49g.gmxhome.de
From: Han on 29 Jun 2010 21:43
On Jun 29, 8:18 pm, Andreas Möller <andreas_moellerNOS...(a)gmx.de> wrote: > Hello, > > > Covered ROM could contain anything, or even nothing (such as the block > > of ROM covered by hardware I/O addresses). > > Of course you are right. What I was trying to say was that covered > memory in 48GX is accessed through ACPTR whereas in the 49G the > FLASHPTR configures the memory and then usually a PTR is called and > therefore the FLASHPTR is faster but can not be exchanged as easily as > there is no RAM "hook". As always the devil is in the details ;-) > > > Are hash tables actually exchanged? > > This can be used to replace commands of a library while still using > the rest of the original library, an example is my advanced CAS help > in the MLP. Also I am planning to do this with my GUISLV (if I find > the time for it) to exchange the slow stuff and the unsupported > display size. That way I could use my improved code together with the > original routines that I do not want to replace (saves time and > space). > > > Is this bug only on the HP49G? Or does it affect the 49G+ and 50G? > > This bug is present in the ROM from the very first one until today. > A detailed presentation about this was given at HHC 2008 by me. If you > do not have it mail me and I will send it to you. > > > When there is a bug in the ROM > > Bugzilla still list a lot of bugs for the 50g... > > Regards, > Andreashttp://www.software49g.gmxhome.de I would love to have a copy of the talk -- I wish I had been able to attend instead, though =) |