Re: [NTLK] [ANN] Einstein Emulator DP3

From: Paul Guyot (pguyot_at_kallisys.net)
Date: Mon Jan 17 2005 - 09:15:58 PST


Aux environs du 17/01/05 à 13:49 +0000, sous le titre "Re: [NTLK]
[ANN] Einstein Emulator DP3", Alexey Danilchenko prit sa plus belle
plume pour écrire les mots suivants:
>Is there any reason why does it have to be so complicated? I mean is it not
>simpler to implement ethernet card driver for virtual NE2000 that will relay
>all the signals to the host? This is the way BasiliskII does it (as far as I
>know).

The former approach is more Einstein Project-like: bypass as many
hardware calls as possible to (a) take as much advantage of the
underlying host system (including drivers for new kinds of hardware)
and (b) speed up development by doing as little analysis of hardware
calls as possible. BasiliskII rather belongs to the class of emulator
trying to emulate as close as possible to the original hardware.

>I was also wondering about graphics. As far as I understand the Einstein is
>currently uses X-server (I am not sure whether it's coded in Xlib calls
>directly or uses some other library).

It does Xlib directly.

>I understand that cross-platform support for the emulator is not
>your primary goal but may be now while it is still at the beginning
>is a good time to think of it? I mean would it make sense to have
>screen (UI) routines done via something like SDL
>(http://www.libsdl.org/) that is a fast and cross platform (supports
>MacOS, variety of UNIXes and Windows). The PowerPC architecture
>emulator uses just this very technology to achieve cross-platformity
>(see in more details here http://pearpc.sourceforge.net/)

The only advantage of SDL over X11 is that it would run on Windows,
something I really don't care about now (if ever). I have an
interface working with both pen and output, I can run the program
directly in the terminal, it's as much I need for both software
development and improvements of Einstein Emulator.

Considering the speed, even if I do X11 with millions of color, it
definitely isn't what takes most CPU.

Moreover, portability would require endianness agnosticism, which
isn't the case yet. Apparently, flash 16 bits accesses are not endian
safe and do not work on little endian platforms (namely linux x86),
thus preventing NewtonOS from booting (the OS detects that there is a
problem and reboots indefinitely).

The emulator will probably remain a resource for software developers,
not a way to access Newton data on a desktop computer. That's another
reason why AppleTalk is more important than TCP/IP. With AppleTalk,
we'll be able to connect the emulator to NTK. TCP/IP is only
important for another part of the Einstein project, namely porting
the OS to new platforms.

As far as low-level debuggers are concerned, they have three drawbacks:
- they rely on the serial port, thus requiring either a virtual
serial port driver in Classic and some bridge to Einstein Emulator in
OS X.
- they suck a lot of CPU (Classic also does), slowering down Einstein
Emulator by as much
- they only work in USR mode, unlike Einstein Emulator (currently
private) monitor mode which is much more powerful for my current
needs (unlimited breakpoints, logging including log of functions
visited, many additional hardware accesses such as view of ASIC
registers and trigger of interrupts, faster mmu interface), even if
it lacks some functions such as stack tracing, memory heap
inspection, newtonscript evaluation (currently being developed).

For licensing reasons, Einstein Emulator monitor mode isn't available
to the public. However, I might have found a way to fix this problem
for next release (basically replace the use of binutils with the use
of NetBSD kernel disassembler).

Paul

-- 
Ministre ultraplénipotentiaire en disponibilité.
Baignoire à vendre.
http://www.kallisys.com/
http://newton.kallisys.net:8080/
-- 
This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries
Official Newton FAQ: http://www.chuma.org/newton/faq/
WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/


This archive was generated by hypermail 2.1.5 : Mon Jan 17 2005 - 11:00:02 PST