Emulators - Write them in Java!



#2

This is a proposal for all the specialists creating emulators for our calcs:

Rewrite them to use Java instead of operating system dependent code!

The GUI part of a typical calculator emulation is relatively straight forward and could be easily ported to the Java 1.1 AWT (which is the least common denominator and would even run on a Psion 5mx).

Regarding CPU emulation: Real calculators are slow machines. I believe that any decent PC will outperform any real calculator, if the CPU were emulated in Java.

What are the benfits?

1.) Java is a well designed language for complex applications, object oriented, with stable exception handling, built in multitasking and decent development environments.

2.) Java code is very portable and runs unchanged on many platforms. If you stick to an older API level, e. g. 1.1, the possible number of targets increases further (think of mobile devices like the Psion PDAs).

3.) In form of an applet, the emulation could even be added to a web page for evaluation or occasional use.

Any drawbacks?

Yes, of course: If the target platforms (e. g. the HP 48 series or most PocketPC devices) do not support Java, you have to resort to other environments.

Why am I proposing all this?

My main operating systems are neither Windows nor Linux nor PocketPC (I run OS/2 on my PC, EPOC on my PDA and I've got a Mac recently; I do have access to Windows, Linux and Windows CE but it's always an additionial step to use them.) Portable emulators would make life easier for me.

I'm a (professional) Java programmer myself and I have learned to prefer it to other environments.

Marcus


#3

I am an IBM host dinosaur and too old to ride a younger horse. <G>

Ciao.....Mike

#4

I love Java very much myself -- for most professional programming tasks, it is definitely the environment of choice... But it also suffers from high memory overheads, slow speed, and slow start-up times. Those things are not an issue for your typical enterprise-class application or heavy-duty GUI, but for a desk-accessory type app like a calculator emulator?

Free42, written in C and C++, has a memory footprint of about 500 kilobytes (not counting shared libraries). Java eats 20 times that just to start the JVM, never mind doing anything!

Of course, portability is a worthy goal, but that can also be achieved using C/C++, by using POSIX and relying on POSIX-compatibility environments (MKS Toolkit, Cygwin, the Windows POSIX-compatibility APIs, etc.). For example, the Unix version of Free42 builds on Cygwin with only one or two minor Makefile tweaks, and with the new multi-window mode in the Cygwin XFree86 server, you barely notice that you're not working with a native Windows app -- and it's still just as efficient as a native app would have been (apart from the X server, anyway). Beats the hell out of Java, if you ask me... But of course it won't do you any good if you're using an OS for which no POSIX compatibility environment is available.

PalmOS is a separate story -- weird API, no POSIX layer, no filesystem, no Java for older and low-end models -- that's always going to be extra work, but if you structure your code with portability in mind, it's not so bad (Free42: 30,000 lines of common code, plus about 6,000 lines of OS-dependent code for each of the three versions).

Just my $0.02...

- Thomas


Edited: 13 May 2005, 11:59 a.m.


#5

Quote:
Free42 has a memory footprint of about 500 kilobytes. Java eats 20 times that just to start the JVM, never mind doing anything!

ON the average PC, you are right. I just started a Java App on my Psion netBook, and the memory usage was near 2MB instead of 10. With a hypothetical "Java Free42" loaded that footprint wouldn't change too much. If you focus on the mobile java edition, memory demand is even less (but the GUI is different!)

Startup time is just a few seconds, as long as you don't start a Java word processor. That's a standable delay. If you use the emulator often or for extended periods, it will stay open.

I can't believe that the actual performance of the emulation is an issue at all, given the original speed of the emulated devices.

Quote:
Of course, portability is a worthy goal, but I would suggest using C or C++, and targeting a well-standardized API like POSIX, and relying on compatibility environments (MKS, Cygwin, the Windows POSIX-compatibility APIs, etc.).

As soon as you leave the typical command line utility (stdin->stdout) area, compatibility between platforms comes to an abrupt end. There is no standard way of multitasking and no common GUI (apart from GUI libraries with the size and complexity of a complete JVM.)

Installing and configuring the above mentioned compatibility environments is another story. And in order to be honest you must add the memory demands of these environments to those of the application.

There is still one point left: A C/C++ port must be done by an expert or even the auther of the software. In a pure Java environment, it's just a matter of installing the software on any platform the user chooses.

Marcus


#6

JAVA IS NOT SLOW!
I remember someone saying:"people make example programs to show a language is slow and complicated, but in fact their examples are programmed to run slowly." It is the same with JAVA.
A modern JAVA hotspot vm can even beat C. That is not a generalization, but depending on the test-program, Java can be faster then C.

Java numbers are still the primitive types like in C - they overflow without throwing an exception, but they can be mapped to the actual hardware.

But any programming language is just a tool for the programmer, and he has to choose the right tool for the task.


#7

JAVA IS NOT SLOW! I remember someone saying:"people make example programs to show a language is slow and complicated, but in fact their examples are programmed to run slowly." It is the same with JAVA. A modern JAVA hotspot vm can even beat C. That is not a generalization, but depending on the test-program, Java can be faster then C (emphasis mine -- ThO).

Sure, depending on the test program, everything can be made to look better or worse than anything else. But I challenge you to give me one single example of a task that Java can do faster than C. The best hotspot JVM still emits the exact same stuff that a C compiler does, namely, native machine code -- and every JVM is burdened by the overheads caused by Java's bloated data structures. (I once had to troubleshoot a seemingly simple Java GUI that kept running out of memory... I discovered that there were dozens of bytes of overhead for each key/value pair in a HashMap. If the keys and values themselves are just short strings, this overhead is HUGE, and Java is rife with this kind of inefficiency.)

Anyway, I agree that different tools are suitable for different tasks. Java is great for some, C++ is preferable for others. But a remark like "Java can beat C" is something I cannot just ignore. :-)

- Thomas


#8

Full ack!

I'm not a professional Java developer,

but I also have some basic experience with the language

and some tools to create progs, like NetBeans and Eclipse.

A few years ago, when working as a DB developer,

I used the Oracle Enterprise Manager,

which was converted from Oracle Forms to Java

from Version 8.x.x on , to be portable.

Man, that was a drawback in performance!

The EM for Oracle 7.x.x ran fast and well

even on a Pentium I with 166 MHz,

but the Java Enterprise Manager

would not run on machines slower

than 500 MHz and 128MB RAM,

and then still in slow motion.

Ok, PCs are faster now,

but the old EM did the same as the new one,

and it may be questionable to buy a new machine

only to be able to do the same tasks with

adequate performance than before,

only because the app has dramatically slowed down.


Last year we began a Java-based project,

so I learned not only to use Java apps,

but working with the language itself.

Of course there are significant differences

regarding the performance of a Java app,

which can be seen by simply comparing

NetBeans with Eclipse.

Both are free, but I would suggest using Eclipse;-)

To get back to the point performance:

My experience with even very simple Java

apps is that the user interface is VERY slow.

I wrote some simple apps using AWT and Swing,

a container with menu bar and some menu entries,

even with no menu actions associated.

Man, you can *see* the menu scroll down,

and there's always a small delay when

moving from one menu entry to another.

The look and feel of the emulated UI controls

is slower than everything I saw during the last years.

This is understandable as there is always an

additional software layer behind the control

to adapt the Java action to the actual OS,

until the action takes place.

But if you're used to applications which react

instantly then Java UIs are not for you so far;-)

Background:

For developing apps, we used Centura SQLWindows for years,

which also relies on a runtime library,

but the resulting applications ran very

fast even on very slow PCs (166MHz) .

No waiting for key or menu reactions,

regardless how complicated the UI was.


Don't get me wrong, this is no Java bashing,

only my observations.

I was mildly shocked that the Java environment and

the resulting apps ran so much slower on my PC than

my much more complicated UIs made with Centura.

All on the same PC, a ThinkPad X31 with Pentium-M and 1GB RAM.

I'm sure Java has its advantages,

but the performance of user interface controls

doesn't seem to be the strongest point;-)

Raymond

#9

In theory, Java can be faster then C because it can do optimizations at runtime - not just compile time. In reality every graphical Java program I've seen runs like a slug.


#10

Quote:
In theory, Java can be faster then C because it can do optimizations at runtime - not just compile time. In reality every graphical Java program I've seen runs like a slug.

I know next to nothing about Java, having had formal training in only Fortran and C, with some limited experience in MS Visual Basic. However, My own observations with one Java app are consistent with the above quote.

I've been using a major commercial "power flow" program on the job for a few years. The previous versions utilized Hummingbird Exceed software to produce graphical displays in the Windows environment. These ran very well with instant response, although the displays sometimes "blanked out" when focus was taken away, and failed to automatically refresh.

The newer versions are Java-based, and I could not believe how slow and unresponsive the graphical display of data tables was. Sometimes, seven seconds elapsed between pressing a key and the display of the results of the operation. I continued to use the older version for inteactive work on the 2000-vintage dual 650-MHz PC I had.

When I recently received an upgrade to a new 3-GHz PC, the Java program ran much better, but still not as quickly as the older "Hummingbird" version.

This made me wonder whether the Java-version developers had fully optimized the production software for speed during compilation. Users could do this for Fortran and C apps with major-vendor compilers.

-- KS


#11

Java applications, particularly those with Swing-based GUIs, sometimes run horrendously slow on remote X servers. I remember one case where a Java installer took minutes just to draw the splash screen (this was also using Hummingbird eXceed). The software's installation guide actually even warned against running the installer on remote X servers.

There used to be a lot of inefficiency in things like scrolling (where megabytes of bitmap data would travel from the server to the client, get manipulated trivially, and then travel back -- instead of scrolling locally on the server). This aspect of Java & Swing performance has gotten a lot better starting with version 1.4.

- Thomas

#12

ON the average PC, you are right. I just started a Java App on my Psion netBook, and the memory usage was near 2MB instead of 10. With a hypothetical "Java Free42" loaded that footprint wouldn't change too much. If you focus on the mobile java edition, memory demand is even less (but the GUI is different!)

Yes, Java really starts eating memory when you initialize a GUI. But then again, most emulators will need one!

Startup time is just a few seconds, as long as you don't start a Java word processor. That's a standable delay. If you use the emulator often or for extended periods, it will stay open.

On a PC, I agree. On a slow, single-tasking PDA, it's different. Even two seconds is slow enough to be really annoying on a Palm. (I thought I could get away with slow startup in Free42, but I couldn't stand it myself, so I spent a lot of time optimizing that part of its performance. I could never use Power48 because it takes forever and a day to start up!)

I can't believe that the actual performance of the emulation is an issue at all, given the original speed of the emulated devices.

Probably not, but for emu/simulators like Free42, which allow you to take advantage of more RAM than the original device, it may be different. If you're working with large matrices, for example, you want all the speed you can get. Also, things like SOLVE and INTEG become much more useful when they're fast -- I have used them in ways in Free42 that are simply not practical on a real HP-42S.

As soon as you leave the typical command line utility (stdin->stdout) area, compatibility between platforms comes to an abrupt end. There is no standard way of multitasking and no common GUI (apart from GUI libraries with the size and complexity of a complete JVM.)

No, I was talking about POSIX, not just the standard C library. A good POSIX compatibility library gives you file I/O, sockets, threads, etc. Throw in an X server and you have everything you need. And, the CPU and memory cost of an X server plus a few smallish DLLs is very little compared to a JVM running a GUI.

There is still one point left: A C/C++ port must be done by an expert or even the auther of the software. In a pure Java environment, it's just a matter of installing the software on any platform the user chooses.

I disagree. I'm talking about software that was written to be portable from the start; this has been the standard way of doing things in the Unix world for decades. All you have to do if you have downloaded a source distribution is things like "configure", "make", and "make install"; with a binary distribution, it's even simpler. No C/C++ expertise needed.

- Thomas

Edited: 13 May 2005, 1:56 p.m.


#13

Quote:
Yes, Java really starts eating memory when you initialize a GUI. But then again, most emulators will need one!

Let's compare the GUI of a calc emulator to something like NetBeans or JBuilder (see the discussions within this thread.)

  • You'll need a single window, probably a second one for printer emulation.
  • The main window will be a single graphic image for the keyboard and a simulated b/w LCD. Resolution of the LCD is limited.
  • If you want some comfort (visual feedback), you'll have overlay images for pressed keys. If you want less, you just use the default buttons of the AWT.

I don't see a need for using Swing and I would stronly discourage its use for this kind of project (because of the responsiveness and memory footprint.)

Just the opposite: Stick to Java 1.1 and the AWT!

Quote:
Startup time is just a few seconds, as long as you don't start a Java word processor. That's a standable delay. If you use the emulator often or for extended periods, it will stay open.

On a PC, I agree. On a slow, single-tasking PDA, it's different. Even two seconds is slow enough to be really annoying on a Palm.


I agree, PalmOS isn't designed for that, at least not in its 16 bit version. But Symbian or PocketPC based devices offer proper multitasking and enough memory.

Quote:
I can't believe that the actual performance of the emulation is an issue at all, given the original speed of the emulated devices.

Probably not, but for emu/simulators like Free42, which allow you to take advantage of more RAM than the original device, it may be different. If you're working with large matrices, for example, you want all the speed you can get. Also, things like SOLVE and INTEG become much more useful when they're fast...


All the slugginess of Java apps discussed in this thread is related to poor GUI performance and the Java memory management. Your case is different: The caculator working memory can be reserved in one chunk and kept active to avoid garbage collection, and the computing power of a JVM, especially if run on a powerful PC, isn't too bad, either.

Quote:
No, I was talking about POSIX, not just the standard C library. A good POSIX compatibility library gives you file I/O, sockets, threads, etc. Throw in an X server and you have everything you need. And, the CPU and memory cost of an X server plus a few smallish DLLs is very little compared to a JVM running a GUI.

POSIX and X are available on many platforms but they have to be explicitly installed on others (Windows) or aren't available at all (Symbian/EPOC, PocketPC). Installing Cygwin isn't a task for the average PC user...

Quote:
All you have to do if you have downloaded a source distribution is things like "configure", "make", and "make install"

That's true on Linux and some Unixes but on a Mac you'll face the first problems. I've read endless discussions about "configure" on OS/2 and I've decided not to go that route. It's an endless fight against missing utilities, headers, wrong program versions, ...

Pointing your browser to an URL (local or on the Net) and having it load and run an applet ist just less challenging! If you prefer local software, you can still package a Java app(let) for some platforms in an installer and for all the others in a simple ZIP file with some instructions.

Marcus

Author of SmtpAuth, a Java App designed for EPOC devices
http://www.mvcsys.de/doc/smtpauth.html


#14

I don't see a need for using Swing and I would stronly discourage its use for this kind of project (because of the responsiveness and memory footprint.)

Just the opposite: Stick to Java 1.1 and the AWT!

Using plain AWT is better than Swing, but still not great. My minesweeper applet is about as simple as applications get, and uses only Java 1.1 and AWT APIs, and yet if I run it stand-alone, the Windows task manager tells me the JVM is using more than 10 megabytes. (Of course it doesn't tell me how much of that is shared.)

SWT (the toolkit used in the Eclipse project) is probably better, but I can't say I've tried it yet.


#15

Quote:
My minesweeper applet is about as simple as applications get, and uses only Java 1.1 and AWT APIs, and yet if I run it stand-alone, the Windows task manager tells me the JVM is using more than 10 megabytes.

That's even the case for a simple command line utility, at least on Windows. The minimum memory requirements depend havily on the implementation (and the release of the JVM.) On Psion/EPOC, memory consumption is significantly less but compared to the available RAM, it's worse than on Windows.


#16

I just had to check this against the memory usage a couple of my 'simple' command line utilities - nothing came close to 10Mb, even ones I've written in Visual Basic (and I do mean a comand line aplication without a GUI).

On the other hand I beleive OpenOffice is Java based and even though it takes ages to open a document the user interface seems responsive enough, even on my 450Mhz Pentium III under Linux...

I think that any choice of language comes down to what you know and what you are trying to do...

Mike T.


#17

Quote:
On the other hand I believe OpenOffice is Java based and even though it takes ages to open a document the user interface seems responsive enough, even on my 450Mhz Pentium III under Linux...

OpenOffice is written in C++ with some optional Java components. OTOH, the development environment Eclipse is a Java application with some native (C++) code in the GUI.

Both applications are equally slow or fast, depending on the machine they are started on.

Lets come back to my original proposal: I was talking about calculator emulation, not about huge applications!

#18

Thats nice, but why has every java application I've tried to use suffered from really poor GUI speed?

<i>I believe that any decent PC will outperform any real calculator, if the CPU were emulated in Java.</i>.

The HP49 plus has a 75MHz CPU. Good luck.


#19

Quote:
I believe that any decent PC will outperform any real calculator, if the CPU were emulated in Java..

The HP49 plus has a 75MHz CPU. Good luck.


Emulating an ARM based high end calulator is a challenge even in C/C++. Has anybody done that?

Let's keep the discussion down to a more practical level. NonPareil could be a target for a reimplementation in Java. The CPUs it emulates aren't the fastest on earth and the intended use is more curiosity than a real need for a powerful calculator on your desktop.

Marcus


#20

Hi,
For that guys that do not know yet:
http://superwaba.sourceforge.net/cgi-bin/twiki/view/Main/SuperWaba


Possibly Related Threads...
Thread Author Replies Views Last Post
  Emulators Olivier De Smet 5 474 06-23-2013, 09:52 AM
Last Post: Olivier De Smet
  any open source HP 10BII emulators? John 15 1,219 06-12-2013, 09:58 AM
Last Post: Kimberly Thompson
  Selftest of HP-15C in 'emulators' of it Mike (Stgt) 1 293 06-06-2013, 04:27 AM
Last Post: Mike (Stgt)
  Emulators for iOS on sale today Bruce Bergman 3 462 05-24-2013, 03:54 PM
Last Post: BShoring
  New WP34s Emulators with better display pascal_meheut 13 932 04-24-2013, 02:32 PM
Last Post: RalfGeiger
  HP-67 Emulators for iPad BShoring 5 466 03-11-2013, 11:29 PM
Last Post: BShoring
  New emulators for Android Olivier De Smet 8 683 01-28-2013, 09:14 AM
Last Post: Bill (Smithville, NJ)
  More emulators Olivier De Smet 2 284 01-10-2013, 10:41 PM
Last Post: Namir
  Smart phone emulators Brian Walsh 0 225 12-10-2012, 02:17 PM
Last Post: Brian Walsh
  Running 33S and 35S emulators in Win 8 Ed Look 12 911 12-07-2012, 03:24 PM
Last Post: Ed Look

Forum Jump: