Re: emu48 running on Linux
Ponure Zacietrzewienie
<k...@fr.invalid> wrote on this group:
> Here it is, after some minor modifications in the sources of emu48,
> emu48 is working correctly. The *only* thing you need to run the
> executable is the library libwine.so
>
> So now, emu48 can run on any UNIX platform :)
>
> If you want the patch, please ask me (replace the .invalid with .fr in
> my mail address)
Khanh-Dang, your email seems to be invalid, so i'm asking here - could
you give me the patch? Pretty please ;-)
--
If you cut off my head, what would I say? Me and my head, or me and my body?
Khanh-Dang
> Some time ago (Tue, 20 Jul 2004 13:31:09 +0200) Khanh-Dang
> <k...@fr.invalid> wrote on this group:
>
> > Here it is, after some minor modifications in the sources of emu48,
> > emu48 is working correctly. The *only* thing you need to run the
> > executable is the library libwine.so
> >
> > So now, emu48 can run on any UNIX platform :)
> >
> > If you want the patch, please ask me (replace the .invalid with .fr in
> > my mail address)
>
> Khanh-Dang, your email seems to be invalid, so i'm asking here - could
> you give me the patch? Pretty please ;-)
Sorry, I cannot find the patch anymore. I might have lost it somewhere
in my hard disk.
However, did you try to launch emu48 with wine ? You are likely to use
freebsd on x86, so wine is available for your system and should emulate
more or less flawlessly emu48.
To emulate a hp49, you should use a special version of emu48 which
can also emulate a HP49G+. I am using emu48 v1.38+, which is
available in the latest Debug4x package available on hpcalc.org. You
can try to use a legacy version of emu48, but the screen will certainly
not be emulated correctly.
There is no problem with emulating a HP48 ROM through.
If you don't need the powerful debugger of emu48, you can try the
emulator saturn, available on hpcalc.org.
Here are some articles I wrote, in case you need to emulate a HP38 (or
HP39/40):
- Emulating a HP38 calc with saturn:
<http://perso.wanadoo.fr/kdntl/hp49/saturn_38.html>
- Transfering a file to a HP38 emulated by wine:
<http://perso.wanadoo.fr/kdntl/hp49/transfer_to_emu38.html>
Maybe someday, I will write an up-to-date article about emulating HP
calcs on UNIX systems.
Ponure Zacietrzewienie
>> <k...@fr.invalid> wrote on this group:
>>
>> > Here it is, after some minor modifications in the sources of emu48,
>> > emu48 is working correctly. The *only* thing you need to run the
>> > executable is the library libwine.so
>> >
>> > So now, emu48 can run on any UNIX platform :)
>> >
>> > If you want the patch, please ask me (replace the .invalid with .fr in
>> > my mail address)
>>
>> Khanh-Dang, your email seems to be invalid, so i'm asking here - could
>> you give me the patch? Pretty please ;-)
>
> Sorry, I cannot find the patch anymore. I might have lost it somewhere
> in my hard disk.
OK, i managed to compile it using winelib. There is still one 'small
issue', though - most of the display (everything except the top - one
where 'alpha', shift etc markings appear) is black all the time ;-)
Also, i have problem with ROM images - trying to load most of them,
including these known to work in x48, results in 'Packed ROM image
detected!' error.
> However, did you try to launch emu48 with wine ? You are likely to use
> freebsd on x86, so wine is available for your system and should emulate
> more or less flawlessly emu48.
Same problem. I'll try again with different wine version.
> To emulate a hp49, you should use a special version of emu48 which
> can also emulate a HP49G+. I am using emu48 v1.38+, which is
> available in the latest Debug4x package available on hpcalc.org. You
> can try to use a legacy version of emu48, but the screen will certainly
> not be emulated correctly.
I was trying (with effect described above) with these sources:
http://privat.swol.de/ChristophGiesselink/Emu48/e48sp41.zip.
> There is no problem with emulating a HP48 ROM through.
>
> If you don't need the powerful debugger of emu48, you can try the
> emulator saturn, available on hpcalc.org.
Right now i'm using x48. Works very well - including receiving
files from host using 'serial over pseudoterminal' - but has no
(working) debugger. And no HP49 emulation.
> Here are some articles I wrote, in case you need to emulate a HP38 (or
> HP39/40):
> - Emulating a HP38 calc with saturn:
> <http://perso.wanadoo.fr/kdntl/hp49/saturn_38.html>
> - Transfering a file to a HP38 emulated by wine:
> <http://perso.wanadoo.fr/kdntl/hp49/transfer_to_emu38.html>
>
> Maybe someday, I will write an up-to-date article about emulating HP
> calcs on UNIX systems.
Thanks ;-)
Khanh-Dang
[running emu48 with wine]
> OK, i managed to compile it using winelib. There is still one 'small
> issue', though - most of the display (everything except the top - one
> where 'alpha', shift etc markings appear) is black all the time ;-)
Yes. This is a known issue. That's the reason why I adviced you to use
the emu48+ version. Just extract the emu48.exe file in the Debug4x
archive: <http://www.hpcalc.org/details.php?id=5441>
> Also, i have problem with ROM images - trying to load most of them,
> including these known to work in x48, results in 'Packed ROM image
> detected!' error.
I am not sure, but there is a unpack script in the x48 package, or the
saturn (see below) one, I can't remember.
> > To emulate a hp49, you should use a special version of emu48 which
> > can also emulate a HP49G+. I am using emu48 v1.38+, which is
> > available in the latest Debug4x package available on hpcalc.org. You
> > can try to use a legacy version of emu48, but the screen will certainly
> > not be emulated correctly.
>
> I was trying (with effect described above) with these sources:
> http://privat.swol.de/ChristophGiesselink/Emu48/e48sp41.zip.
You should try the emu48+ executable, as stated above.
> Right now i'm using x48. Works very well
I can't remember why and how, but I sometime got a frozen x48, so I
don't use it anymore.
> - including receiving
> files from host using 'serial over pseudoterminal' - but has no
> (working) debugger. And no HP49 emulation.
Yes. Using a terminal is really powerful, and useful too. There is a
native Unix emulator that can emulate HP49. It's called saturn:
<http://www.hpcalc.org/details.php?id=4382>
I find saturn really great. The only missing function is the debugger.
Egan Ford
>native Unix emulator that can emulate HP49. It's called saturn:
><http://www.hpcalc.org/details.php?id=4382>
>
>I find saturn really great. The only missing function is the debugger.
Is there any interest in a GTK front-end to Saturn with KML support?
I use x48 on my Linux workstation and Zaurus PDA
(http://sense.net/zc/x48) with a lot of success, but would like some
type of skin support. For future development I am leaning toward
Saturn over x48 becasue Saturn overhead is much less--important for
embedded devices.
I have already explored porting EMU48 to Linux twice--it is
non-trivial and WINE is not an option for non-x86.
What is of more interest, GTK/KML support for Saturn or x48? Is this
good enough or is EMU48 for Linux the only answer? Would a community
support Saturn and make it better than EMU48?
Khanh-Dang
> >There is a
> >native Unix emulator that can emulate HP49. It's called saturn:
> ><http://www.hpcalc.org/details.php?id=4382>
> >
> >I find saturn really great. The only missing function is the
> >debugger.
>
> Is there any interest in a GTK front-end to Saturn with KML support?
I don't know for others, but I'm using emulators only for debugging
purposes, so I don't really need KML support.
> I use x48 on my Linux workstation and Zaurus PDA
> (http://sense.net/zc/x48) with a lot of success, but would like some
> type of skin support.
> For future development I am leaning toward
> Saturn over x48 becasue Saturn overhead is much less--important for
> embedded devices.
Did you made some experiments, such as CPU load measures and so on?
Having some figures would be interesting.
> I have already explored porting EMU48 to Linux twice--it is
> non-trivial and WINE is not an option for non-x86.
Yes. I don't know anything about win32 programming, but what would be
really difficult to port is likely to be the threading system.
Note that there are some interesting ports of Emu48. All I can remember
is a port for MacOS, written by Pierre Tardy. There is also a port for
the old pocket handheld Psion. Maybe you should consider converting one
of these two ports?
> What is of more interest, GTK/KML support for Saturn or x48? Is this
> good enough or is EMU48 for Linux the only answer? Would a community
> support Saturn and make it better than EMU48?
Unfortunately, I think there is no community. How many users really
need a HP4x emulator running on Unix or Linux, especially on non common
architectures?
Egan Ford
>> Saturn over x48 becasue Saturn overhead is much less--important for
>> embedded devices.
>
>Did you made some experiments, such as CPU load measures and so on?
>Having some figures would be interesting.
I built x48 for Zaurus and Nokia 770. The performance of x48 on the
770 makes it useless (as reported by 770 users).
I used strace with x48 and saturn to compare activity when the
emulator is idle. x48 has orders of magnitude more system calls than
Saturn with gettimeofday in the lead. I believe this overhead has an
impact on performance.
I tested a UserRPL Savage benchmark. Saturn was 20+ times faster than
x48.
If you want raw data let me know, I didn't save it, but it would only
take a few minutes to generate it.
>> I have already explored porting EMU48 to Linux twice--it is
>> non-trivial and WINE is not an option for non-x86.
>
>Yes. I don't know anything about win32 programming, but what would be
>really difficult to port is likely to be the threading system.
>
>Note that there are some interesting ports of Emu48. All I can remember
>is a port for MacOS, written by Pierre Tardy. There is also a port for
>the old pocket handheld Psion. Maybe you should consider converting one
>of these two ports?
I have looked at the MacOS code. It is out of date. Porting it is
not worth the effort. However I have been looking at the differences
between MacOS and Windows versions to find the differences to make
porting easier. Time is the real issue.
I'll have to look at the Psion source. It may be dated as well.
>> What is of more interest, GTK/KML support for Saturn or x48? Is this
>> good enough or is EMU48 for Linux the only answer? Would a community
>> support Saturn and make it better than EMU48?
>
>Unfortunately, I think there is no community. How many users really
>need a HP4x emulator running on Unix or Linux, especially on non common
>architectures?
Unsure, that is why I asked. It is "common" for "non common
architectures" in the embedded marketspace. An efficient emulator for
embedded devices will have demand, but how much demand is the
question.
Khanh-Dang
> Unsure, that is why I asked. It is "common" for "non common
> architectures" in the embedded marketspace. An efficient emulator for
> embedded devices will have demand, but how much demand is the
> question.
For embedded devices, the debugger is not so that useful, the only
thing the legacy user want is to use its handheld as a HP calc.
Porting Emu48 is not worth the effort, then.
I think a port of Saturn would be the best, as you claim Saturn is
really lighter than x48. If I remember well, the graphical part of
this program is based on the Motif library. I don't think Motif is
widely used on embedded Linux devices, so converting it to any other
common API should be considered.
Veli-Pekka Nousiainen
news:447c72d8$0$20145$8fcf...@news.wanadoo.fr...
How about running it on Symbian (Communicator)
Christoph Giesselink
news:44785c93$0$21285$8fcf...@news.wanadoo.fr...
> Ponure Zacietrzewienie <trasz...@buziaczek.pl> wrote:
> [running emu48 with wine]
> > OK, i managed to compile it using winelib. There is still one 'small
> > issue', though - most of the display (everything except the top - one
> > where 'alpha', shift etc markings appear) is black all the time ;-)
>
> Yes. This is a known issue. That's the reason why I adviced you to use
> the emu48+ version. Just extract the emu48.exe file in the Debug4x
> archive: <http://www.hpcalc.org/details.php?id=5441>
>
I checked this problem on SuSE Linux 9.1 and it's definitely a Wine bug in
the BitBlt() implementation.
I replaced
BitBlt(hWindowDC, nLcdX, nLcdY, 131*nLcdZoom, nLines*nLcdZoom,
hLcdDC, Chipset.boffset*nLcdZoom, 0, SRCCOPY);
with
StretchBlt(hWindowDC, nLcdX, nLcdY, 131*nLcdZoom, nLines*nLcdZoom,
hLcdDC, Chipset.boffset*nLcdZoom, 0,
131*nLcdZoom, nLines*nLcdZoom, SRCCOPY);
and then Wine worked with the correct colors.
For those who are not familar with these commands, in this special case
BitBlt() copy a device independent bitmap from hLcdDC to hWindowDC.
StretchBlt() works quite similar like BitBlt() but has the additional
advantage to make bitmap size conversations from source to destination. In
my special example of StretchBlt() source and destination has the same size,
so the stretch factor is 1 and this is equal to the working of BitBlt().
So why using BitBlt() instead of StretchBlt()? BitBlt() is much faster!
- Emu48 generate the source LCD bitmap with the wanted Zoom factor manually
and then copy this bitmap with BitBlt() to the destination.
- Emu48+ generate the source LCD bitmap always in Zoom factor 1 and then
copy and stretch this bitmap with StretchBlt() with the wanted Zoom factor
to the destination.
I haven't timing differences for Emu48 here, but I remember some timings on
Emu28. Emu28 emulates a HP28C with a 137x32 pixel display. The Zoom factor
was 2, so the display on desktop has 274x64 pixel size. The test PC was a
P4/2.4GHz with Win2k.
The public available Emu28 v1.10 need ~110us for complete display update. My
current Emu28 v1.11beta1 needs longer because of better display emulation so
you can't compare the new timings with the v1.10 version.
1) Emu28 v1.11beta1 with Zoom factor 2 in source LCD bitmap and BitBlt()
copy to destination
Complete display update: ~210us
2) Emu28 v1.11beta1 with Zoom factor 1 in source LCD bitmap and StretchBlt()
copy to Zoom factor 2 destination
Complete display update: ~ 8600us !!!
So quite all of my emulators use BitBlt() for display update. The only
exception is Emu48 for Pocket PC, because I found it too hard to do all the
stretching manually for portrait and landscape mode. The complexity of the
manual (faster) solution was IMHO the reason for CdB using the much easier
StretchBlt() solution in the Emu48+ implementation.
So I think it's on you (as wine users) to make the necessary pressure to the
wine development team, or much better find the bug in the wine BitBlt()
implementation and send the bugfix to the wine development team.
Regards
Christoph
Raymond Del Tondo
"Khanh-Dang" <khanh...@w.fr.invalid> schrieb im Newsbeitrag
news:447c72d8$0$20145$8fcf...@news.wanadoo.fr...
> Egan Ford <eg...@sense.net> wrote:
>> Unsure, that is why I asked. It is "common" for "non common
>> architectures" in the embedded marketspace. An efficient emulator for
>> embedded devices will have demand, but how much demand is the
>> question.
>
> For embedded devices, the debugger is not so that useful, the only
> thing the legacy user want is to use its handheld as a HP calc.
> Porting Emu48 is not worth the effort, then.
>
I don't agree here.
I use Emu48 for nearly any of my HP-48 related sw development tasks,
but I rarely use the debugger.
Actually, the last time I used the Emu48 debugger was a few years ago.
So at least for me, a port of Emu48 (to the 770) would really be
appreciated.
To Egan: The Psion used WCE.NET , so Emu48CE would be the starting point,
not the 'real' (full-blown) Emu48;-)
Regards
Raymond
Khanh-Dang
> > For embedded devices, the debugger is not so that useful, the only
> > thing the legacy user want is to use its handheld as a HP calc.
> > Porting Emu48 is not worth the effort, then.
> >
> I don't agree here.
>
> I use Emu48 for nearly any of my HP-48 related sw development tasks,
> but I rarely use the debugger.
> Actually, the last time I used the Emu48 debugger was a few years ago.
>
> So at least for me, a port of Emu48 (to the 770) would really be
> appreciated.
What I meant is that it would be much easier to port an emulator already
running with Linux. x48 and saturn are running with Linux, but it seems
x48 is still too slow. Porting saturn may be easier than porting emu48,
assuming you embedded device is a linux-based one.
For me, saturn works flawlessly and is fast enough, even on my old
machines. The only missing thing is the emu48's powerful debugger,
which is really a great tool for debugging ASM routines. That's why I
asserted that people who don't need the debugger might be more
interested in a port of saturn, rather than emu48.
Khanh-Dang
> I checked this problem on SuSE Linux 9.1 and it's definitely a Wine
> bug in the BitBlt() implementation.
> and then Wine worked with the correct colors.
Thank you so much Christoph for having taken a look to the wine
problem!!
> So I think it's on you (as wine users) to make the necessary pressure
> to the wine development team, or much better find the bug in the wine
> BitBlt() implementation and send the bugfix to the wine development
> team.
Yes, I do agree. I submitted a bug report about emu48 and wine some
months ago. I've just modified the bug report so that the wine users
would know what to do.
For those who are interested, the bug is there:
<http://bugs.winehq.org/show_bug.cgi?id=4140>
Ad thank you again Christoph :)
Khanh-Dang
> "Christoph Giesselink" <no_...@swol.de> wrote:
> > So I think it's on you (as wine users) to make the necessary
> > pressure to the wine development team, or much better find the bug
> > in the wine BitBlt() implementation and send the bugfix to the wine
> > development team.
>
> Yes, I do agree. I submitted a bug report about emu48 and wine some
> months ago. I've just modified the bug report so that the wine users
> would know what to do.
>
> For those who are interested, the bug is there:
> <http://bugs.winehq.org/show_bug.cgi?id=4140>
I finally submitted another bug for the BitBlt() function:
<http://bugs.winehq.org/show_bug.cgi?id=5329>
Perhaps some wine developpers will take a look at it.
Jean-Yves Avenard
> So quite all of my emulators use BitBlt() for display update. The only
> exception is Emu48 for Pocket PC, because I found it too hard to do all the
> stretching manually for portrait and landscape mode. The complexity of the
> manual (faster) solution was IMHO the reason for CdB using the much easier
> StretchBlt() solution in the Emu48+ implementation.
>
I Christoph.
I have a different recollection, I thought you were the first one to use
StretchBlt which made the code much smaller than my original code for
Zooming.
JY
Christoph Giesselink
[..]
> I have a different recollection, I thought you were the first one to use
> StretchBlt which made the code much smaller than my original code for
> Zooming.
That's wrong. The first usage which I can remember is in one of the Emu48CE
versions. Maybe CdB has this solution from there, because I know that he
worked on Emu48CE quite a long time ago (perhaps at your common ACO time?).
With Emu48PPC on the Axim X50v (VGA display resolution) I have trouble with
the StrechtBlt() solution. The quite long taking display update time cause
sometimes trouble with skipping timer2 values which is very annoying when
writing to port2 on the HP49G. But because I'm lazy, the StrechtBlt()
implementation is still in there with several workarounds in the timer2
implementation.
On the other side I like the easy implementation with StrechtBlt(), so it
was an option when I added Zoom 3 to Emu48 v1.41.
Cheers
Christoph