Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!usc!apple!snorkelwacker!ira.uka.de!fauern!fauern!news From: news@medusa.informatik.uni-erlangen.de (News Administration) Newsgroups: comp.sys.apple2 Subject: Re: Apple ][+ emulator Message-ID: <2602@medusa.informatik.uni-erlangen.de> Date: 29 Mar 90 15:27:25 GMT References: Organization: CSD, University of Erlangen, W-Germany Lines: 33 From article , by pnakada@oracle.com (Paul Nakada): > Like I said, though... It's really a novelty.. it's real slow on a > sparc, but then again, it make's cross development and debugging a > cinch on a sparc... anyone know of any debuggers for the Apple ][+? > :-) it'd be a breeze to implement a single step/breakpoint debugger on > the emulator... > > enough rambling.. what do you all think about this "novelty"? Quite interesting. Of course to make it interesting, one has to do quite a few things too. Some ideas for improvement: - make many of the routines inline, and use gcc to compile, a cray will help too, for faster execution. - Output should really be generated for bitmap displays, so one could implement LORES, HIRES... - Disc i/o could be implemented by counting cycles in the interpreter, so one knows what to return, when someone accesses the DISC II I/O addresses. Using this scheme one could even run copy protected software from the emulator (hua, hua). Given the estimation of 0.3mips (for the 6502 at 1mhz, it should be possible to run the emulator at full speed on a >= 10mips machine (30 instructions should be enough to simulate one instruction). Seems that with a Sparc or 88k machine one can simulate an apple // rather good (A '040 would do too - Apple come one, make a full fleshed apple // emulator standard on your next series of Mac's !!). -- Toerless Eckert Internet: eckert@informatik.uni-erlangen.de X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/