Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!eru!luth!sunic!tut!santra!kampi.hut.fi!jmunkki From: jmunkki@kampi.hut.fi (Juri Munkki) Newsgroups: comp.sys.handhelds Subject: Re: Re: HP-48 Emulator Message-ID: <1990Mar11.111425.16008@santra.uucp> Date: 11 Mar 90 11:14:25 GMT References: <6724@hydra.gatech.EDU> <21580014@hpcvra.CV.HP.COM> Sender: news@santra.uucp (Cnews - USENET news system) Reply-To: jmunkki@kampi.hut.fi (Juri Munkki) Organization: Helsinki University of Technology, FINLAND Lines: 63 randys@hpcvra.CV.HP.COM (Randy Stockberger) writes: >Given a 32 bit CPU like a 68000 or a 80386 and an operating system >which allows perhaps a megabyte and a half or more for the necessary >data structures and code space without having to worry about segment >registers it would probably be faster. However, what percentage of us >are running UNIX on a 68000 with all the freedom and access that we >have with our PCs? Or would the 386 and Xenix be a better choice for >the host environment? First of all, let me say that I don't think that speed is all that important with the emulator. Given the strange architecture of the Saturn processor, I don't think that we even need the emulator. It might be best to write a debugger that uses the serial line. The original Macintosh debugger used two macs, where one executed the code and the other displayed windows with registers and dissassembly. There are a few basic blocks that need to be written with portability in mind: 1) A macro-assembler. 2) A dissassembler that understands symbol tables from the assembler. Someone could write symbol tables for the most common sections of the ROM. I don't know if the Saturn processor directly supports a trace or step mode, but one could probably be emulated with some code that looks out for branch instructions and emulates those. Breakpoints should be easy enough to set in RAM-based code. This step/trace unit would then communicate (using the serial port) with the main computer. If you use the supplied kermit protocol packets, this system could be extremely portable (and probably slow too.) After these three (separately usable) blocks have been written, some machine-dependent code could be written to glue them together. At this point, I would probably write a Macintosh interface for the whole assembler/debugging system and someone else could write a PC or unix interface. All this assumes that the assembler and disassembler are written in a high level language. (If you use C, please allow for 16 or 32 bit integers.) The 68020 (or 30) would probably be quite well suited for the emulator, since it has bcd arithmetic and bit-field instructions. The reverse nibble addressing scheme might best be emulated by negating every bit field address before use. This would require some further adjustment, but you could move directly to and from memory with very little overhead. Once the bitfield address is set up, reading the whole 64 bit word would take only two or three instructions. (A 16Mhz 68020 with 2 wait states can emulate a 4.77Mhz 8088.) The emulator requires a lot of work and still isn't quite as useful as the assembler+disassembler+trace+user interface combination that I described. I'd like to write some arcade games for the 48SX. Tetris will probably be the first. With the IR link, it could be interesting as a two player game. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^