chris@nthropy.uucp (Chris Chauvin) (10/16/90)
Actually, Mac emulation may be more possible than many think. What follows is a posting to comp.sys.mac.announce that appeared about a month ago. > Note: Abacus Research and Development (ARDI), is in no way affiliated with the > ====> University of New Mexico. Abacus Research and Development has had > ====> a UUCP link to the University and since that link still down, > ====> this note is being posted from unmvax, rather than iclone. > ====> Please do not electronically reply to the sender of this message, > ====> as it is a courtesy account and responses will not be forwarded to ARDI > > This post announces the official release of ROMlib-V1.0(tm) for Sun3 > machines. A description of the beta release of ROMlib was posted in February. > Executor(tm) is not yet a product, but a pre-alpha copy is currently being > shipped with each copy of ROMlib sold. It is being included because it is > useful for debugging, it is amusing and it shows where ARDI is headed in no > uncertain terms. > > [two major differences from the information posted when we were looking for > beta sites: the device management code won't be seen in this release and > the memory manager is no longer built on top of malloc (in fact, malloc is > now built on top of it] > > This post has 5 parts: > > Description of ROMlib and Executor > > Technical issues > > Limitations > > Answers to commonly asked questions > > Ordering information > 1. Description of ROMlib and Executor > > ROMlib is a set of C library routines with the same syntax and semantics as > the routines available on Apple Computer Inc.'s Macintosh(tm) Plus computer. > ROMlib-V1.0 provides all the routines documented in "Inside Macintosh" > Volumes I-IV with a few exceptions noted below. Although the first release > of ROMlib-V1.0 is for SUN3s running X11, there is little dependence on X11, > and experimental versions exist that write directly to Sun "bwtwo"s and IBM > PC "VGA"s. The source to ROMlib can be configured to run on DEC Vaxen, > Decstations, Sun4s, DG Aviion, Dupont MacBlitzen and IBM RT, but we don't > have the facilities to support releases on those machines today. ROMlib is > known as a "source compatibility product." > > Executor is a program that has been compiled with a special copy of ROMlib > (it uses different stack frames for some routines and ints are 16 bit). > Executor runs binaries that have traditionally been run on the Macintosh. > It is not a product because there are many things that will make it crash. > I don't know of a single "big ticket" application that runs in entirety under > Executor and some don't even print anything on the screen before they crash. > The reason for most of the crashes are uses of low-memory globals that we don't > understand (we have not disassembled any Macintosh object code, so undocumented > memory locations are a real pain), the use of routines we haven't put in ROMlib > yet (Hierarchical menus, Color) or device level programming (although writes > directly to "screen memory" ARE supported). Executor requires kernel > modifications, which we supply in source form, to quickly dispatch A-line > traps, remap the page 0 memory references, and support the reading and writing > of the Status Register which is normally a restricted operation (we still > disallow altering the interrupt priority). Executor is a "binary compatibility > project." > > ROMlib and Executor do exactly what you tell it. There is no attempt to make > your application look any different than it would on a Macintosh. > 2. Technical Description > > When a program compiled with ROMlib runs, a one bit deep offscreen bitmap is > allocated with sufficient space for a virtual screen (the default is 512x342 > but can be altered with Xdefaults geometry). All drawing is done into this > offscreen bitmap and then the portions of the bitmap that have been changed are > sent via XPutImage to the real screen. Note the reliance on X is minimal. The > first verions of ROMlib wrote directly to the screen, and should someone need > a port to a machine with a different (or no) windowing system, it should be > no trouble as long as there is a way of pushing one bit deep rectangles around. > All the windows that are created by a single application are displayed on the > virtual screen that is automatically created when the application starts. > > All internal data structures that are documented in Inside Macintosh are used > as described therein. ROMlib-V1.0 reads both V1 and V2 pictures, but writes > only V2 pictures. Although none of the calls documented in Inside Macintosh > Volume V are supported, ROMlib will cheerfully ignore color op codes and the > data that follows them in V2 pictures. > > Although for compatibility we support the same internal format of a "region" > as on the Macintosh, we convert it to a nicer intermediate form internally. > We do not use the algorithms described in United States Patent #4,622,545. > Our clipping is performed without the use of a scan line mask as described > on column 10 of that same patent. Although I know of no documentation > concerning the algorithm Apple uses for SeedFill, we clearly use a different > algorithm since they fill horizontally first, where we fill vertically (using > table lookup with a base three encoding to compress the table from 64k to 7k). > Given some free time, someone here will write a paper describing the techniques > used in detail; of course we wouldn't think of patenting such pieces of applied > mathematics. > > The filesystem is a straightforward mapping of Macintosh 2-forked files unto > two UNIX files. Resource forks are stored as separate files within the > subdirectory ".Rsrc" that exists in the directory that the data-fork exists > in. In order to map back and forth between directory names and directory > id numbers, ndbm is used to keep a database of all subdirectories of a given > ROMlib "volume." The volume can be rooted anywhere on the UNIX filesystem, > but only ROMlib programs should move or delete directories unless you wish to > rebuild the mapping information after any changes. A program is provided > to do just that. The resource fork files have 512 bytes prepended to them in > anticipation of eventual TOPS compatibility. However the top-most bytes in > the 512 area are actually used to store information and may conflict with > TOPS (it hasn't been tested yet). Very few of the low-level data structures > are compatible, since UNIX is responsible for doing the actual file > manipulation. Setting EOF is allowed, but don't expect the relation between > logical EOF and physical EOF that is documented in Inside Macintosh to hold > true, files never shrink under ROMlib. > > 3. Limitations of ROMlib (Executor doesn't have as many limitations) > > No Printing Manager, Desk Manager, Device Manager, Disk Driver, Sound Driver, > Serial Driver, AppleTalk, Disk Initialization or SCSI Manager. No routines > introduced past Volume IV (notably no Color, hierarchical menus). > > Currently the standard xDEF code resources are not read out of the System File > by GetResource. This is because there is no trap facility so the > dynamic linking required would be a mess. It is possible to overwrite the > standard definition procs by changing an array that contains the pointers to > the appropriate functions. The level of compatibility is sufficient that > resource forks created on Macs are readable under ROMlib and vice versa. > Unfortunately, not all UNIX machines are big endian, so a utility is > provided to do byte swapping for you, should you be on a little endian > machine (not necessary on SUN3). The byte swapping program doesn't know how > to byte swap pictures, but ROMlib detects byte swapped pictures and handles > them properly. > > SetCursor doesn't allow cursors to invert bits under them because it is not > easy to do under X. > > You must be 32 bit clean. > > The System Error facility is there but the DSAT resource is in an incompatible > form (since we don't read code from resource files). > > The vertical retrace manager and time manager are supported, however the timing > is approximate and not tied to the refresh of the screen. In addition it is a > bit costly to have the kernel signaling your process every 60 seconds, so it is > possible to turn the vertical retrace interrupt off (the clock will continue to > tick). > > N?[GS]etTrapAddress are not supported by ROMlib (Executor handles them > properly). SysBeep calls XBell. Environs pretends that ROMlib is a macMachine > with version 0x75 of the ROM. Restart kills the current process. > > Segment loader Parameters can be passed in on the command line. ROMlib's > segment loader attempts to locate files named as parameters. UnloadSeg doesn't > do anything, but on a virtual memory system that only means that swap space > will continue to be used as the unloaded set gets paged out. > 4. Commonly asked questions > > Q: Don't you expect to be sued by Apple? > A: As ludicrous as it might be to be sued as infringing on ``look and feel'' > by a company whose CEO made it big running Pepsi, the answer is still yes. > Apple has shown a strong tendency to bully potential competitors. ARDI > intends to provide the ROMs for Macintosh "clones." Should a lawsuit be > filed, Apple will in essence be saying that the look and feel of all the > applications that have been released on the Macintosh belong to Apple, > not the author's of the programs. Even if ``look and feel'' suits do hold > up over time it is unlikely that the courts will transfer the ownership of > an application's look and feel from the application's author to Apple. > > Q: Why don't you support [Color, Desk Accessories, ...]? > A: All good things in all good time. > > Q: Any plans for executor on non 68000 based machines? > A: You bet. Emulated cpu technology is a viable option on the fast machines > that are becoming available due to the competition in the UNIX market. > Remember, all the time spent in traps will be executing native code so > things should scream. > > Q: How dependent is ROMlib on UNIX? > A: Currently we require the UNIX filesystem, but we will write a complete > implementation of HFS that can read and write disks initialized by a > Macintosh. > > Q: Are you using inferior algorithms in order to avoid patent infringement? > A: No. Our algorithms are in my opinion better, although we currently don't > blit as fast as the Macintosh, due to the blitter still being in C. > > Q: What do the big players think of ROMlib? > A: There's quite a bit of interest out there. The threat of lawsuit is more > intimidating to a large company than to ARDI. If it's going to happen, > let's get it over with. > > Q: How big is ARDI? > A: Four Programmers, One Lawyer, an Accountant and a Secretary. > > Q: Are you hiring? > A: Not today. > > Q: I'd like a demonstration, how do I get one? > A: When we were in beta the non-disclosure agreement was pretty stifling; > now however if you can find someone on a net that you're connected to > that has ROMlib and is willing to give you a demonstration, their license > permits them to do that (the license agreement listed in the next section). > xhost their machine onto your machine, set the DISPLAY environment variable > and go for it. If you plan to be in Albuquerque give us a call. If you > plan to be in Stockholm on October 13th let me know :-). > > Q: What are the kernel mods? > A: One new system call is added, one new bit in the proc flags is allocated. > The syscall turns on and off 'fast aline dispatching' and 'page 0 mapping'. > The bit is used to determine whether a given process is needs these > features. BusErrors, A-line traps and illegal instructions are trapped > and examined before the kernel sees them. If the currently executing > process has the new bit turned on in the proc flags field and certain > conditions are met then our code handles the exception and the kernel > is never the wiser. This is all relatively trivial since none of the > three things mentioned above are asynchronous events. NOTE: ROMlib > doesn't need any kernel mods, only Executor. > > Q: How hard is it to install the kernel mods? > A: We try to make it as easy as possible, providing a set of mods for SunOS3.5 > and SunOS4.1 with the idea that if you have anything else you can compare > the two and figure out how to fit things to your system. You do not need > the source to the kernel (we don't have it either) to make the mods. We > give you the source to the mods, it's you kernel; you deserve to know what > we're doing to it. > > Q: How similar are the screens produced with ROMlib to those on a Macintosh > A: They will look as similar as we can possibly make them. Currently we > differ wherever approximations are necessary (scan converting lines, > ovals, scaling bitmaps) because we haven't taken the time to figure out > mathematical equivalent for what Apple is doing. We have disassembled > no Apple code, so getting exact pixel matches in the above cases will > take some work. We were able to reverse engineer Random() (Thanks Bill) > by looking at the numbers it produced so we should be able to do the > others. Non-scaled bitmaps should be bit per bit the same. > > Q: Why do your ovals have breaks in them? > A: I've heard several explanations of why Apple's ovals have breaks in them > but we didn't initially set out to duplicate this "feature." However > one day I realized that it was faster to scan convert an oval twice, once > for outer diameter and the second time for inner diameter than it is to > do one scan convert and one inset region. However when you do it the fast > way you get holes in your ovals. So we're compatible there as well. > > Q: What's in the release? > A: ROMlib, Executor, man pages, kernel mods, auxiliary programs, and test > programs that provide examples of how to compile/link your programs. > > Q: How slick's the packaging? > A: This release? Not very. This is our first release. Remember when DEC > documentation was intentionally funny? When Bill Gates lived in > Albuquerque? the Apple I? > 5. Ordering info > > The fee per CPU is $400.00. The license agreement printed below will have to > be filled out, signed and accompanied by a check for $400.00 (+ tax if > ordering from within New Mexico) before we will ship ROMlib and Executor. > The license PROHIBITS the transfer of executables and libraries built with > ROMlib to non-licensed CPUS; as such YOU MAY NOT BUILD PROGRAMS AND SELL > THEM OR GIVE THEM AWAY with this license. We will have a separate license > agreement and fee structure that will allow the distribution of derived works. > When we support more machines we offer an educational network license for > Colleges and Universities. > One concern is the agreement between Apple and NeXT. Would it prohibit NeXT from distributing such a thing? If so, could some one else distribute it? Hmmm....
ls1i+@andrew.cmu.edu (Leonard John Schultz) (01/29/91)
There was discussion several months ago about Mac emulation on the NeXT, the legal and technical difficulties. I just read an article in MacWeek that some of you may find interesting. Included below are a few key paragraphs: ----- RDI Computer Corp. is erecting a bridge from Macs to Sun workstations, announcing software this week that lets users run Mac programs from SPARC-based systems for the first time. Companion, which runs under Sun's SunView or Open Windows operating systems, will work like a Mac SE or Classic by emulating the Mac's 68000 processor, RDI said. .... Companion will be available Feb. 1 bundled with an SBus card that includes a Mac Classic ROM for $1695. A software-only version will be available in early March for $895... ... Schramek added that RDI has not had any legal challenge from Apple regarding its Mac emulation. RDI Computer Corp. is at 6696 Mesa Ridge Road, Building A, San Diego, Calif. 92121. Phone (619)944-6381; fax (619)558-8943. ----- If anyone has any information or speculation on NeXT software for Mac emulation, from RDI or other developers, please email me or post to the net.
finger@evax.arl.utexas.edu (Jay Finger) (01/29/91)
>Companion will be available Feb. 1 bundled with an SBus card that >includes a Mac Classic ROM for $1695. A software-only version will be For that price I'd bet my next pay-check that they actually buy a MacClassic, unplug the (legit) ROMs, put them into their S-Bus card, and then either throw away/sell for parts, etc, the rest of the MacClassic. A couple of years ago a company was selling Mac II "clones" that featured a heavier power supply and more drive bays. It was simply a Mac II motherboard bolted inside a PC tower case. There's nothing wrong with that method; it's just as legit as selling the ROMs out of a Mac that you yourself already own. As for how the software only version could work... -- Jay Finger #include <stddisclaimer.h> finger@evax.uta.edu finger@csun5.uta.edu b645zai@utarlg.uta.edu
sparkie@picard.cs.wisc.edu (Mark J. Horn) (01/31/91)
In article <1991Jan29.013029.6804@evax.arl.utexas.edu> finger@evax.arl.utexas.edu (Jay Finger) writes: >As for how the software only version could work... I assume that the software only version simply means that you have to supply the ROMs yourself. Not that it does ROM emulation in software. However, if you told me that I was wrong, you could very well be right. I haven't a clue! - sparkie -- ___ ___ ___ ___ _ _ _ ___ / __\| . \/ . \| . \| |/ /|_|| _ | sparkie@picard.cs.wisc.edu \__ \| __/| || _ /| < | || _[ - or - \___/|_| |_|_||_|\\|_|\_\|_||___| harier!sparkie@cs.wisc.edu
fozzard@alumni.colorado.edu (Richard Fozzard) (02/05/91)
In article <1991Jan31.050104.6291@daffy.cs.wisc.edu> sparkie@picard.cs.wisc.edu (Mark J. Horn) writes: >I assume that the software only version simply means that you have to supply >the ROMs yourself. Not that it does ROM emulation in software. However, if you >told me that I was wrong, you could very well be right. I haven't a clue! Actually, it does emulate the ROMs in software! I have talked with one of the technical people at RDI. The card is nothing but the ROMs - they just arent done yet with testing the ROM emulation software. They claim it's all legal and Apple hasn't bothered them about it. Of course, who would buy a Sun, then pay $895 more to run a non-multifinder 1 MB Plus? (Though you can run multiple copies of it, they are totally separate machines; different file systems, no copy/paste, etc.) The new Mac Classic street price is less than this, can be upgraded, etc. Clearly it won't steal much business from Apple. Incidentally, they say it runs much faster on a Sun-3 (a 68020) than a Sparc, because they didn't need to emulate the 680x0 CPU. Can you imagine how it might run on a 68040 NeXT? If someone could convince them to port it to the NeXT, it could really take the wind out of the sails of those who complain they won't switch because of their investment in mac software! -- ======================================================================== Richard Fozzard "Serendipity empowers" Univ of Colorado/CIRES/NOAA R/E/FS 325 Broadway, Boulder, CO 80303 fozzard@boulder.colorado.edu (303)497-6011 or 444-3168
lwake@runcible.West.Sun.COM (Larry Wake) (02/05/91)
In article <1991Feb4.211511.1256@csn.org> fozzard@alumni.colorado.edu (Richard Fozzard) writes: >Of course, who would buy a Sun, then pay $895 more to run a non-multifinder >1 MB Plus? (Though you can run multiple copies of it, they are totally >separate machines; different file systems, no copy/paste, etc.) Real estate. I have a Sparc 1+ on my desk. I want to run PC programs. I want to run Mac programs. I don't want to put two more monitors, keyboards and mice on my desk, let alone look for someplace to stash the CPUs, deal with the cabling, buy more hard disk, *power* the whole mishmosh, physically move from one to the other (including all my accessories, such as paperwork, soda, CD player) whenever I switch applications... Since I do UNIX by choice, and Mac and PC only by necessity, I don't need the most whizzo PC or Mac on the block, just something to run that one application I need that hasn't been ported to SPARC yet. (SimCity, for example :-) Cheers from the office that brought you RDI (they cut up one of our demo room IPCs to make their prototype)... -- Larry Wake, Sun Microsystems (larry.wake@west.sun.com) "The first computers were big clumsy machines that used vacuum tubes. By today's standards, they were extremely primitive. For example, they believed the sun was carried across the sky on the back of a giant turtle." -- D. Barry
cnh5730@calvin.tamu.edu (Chuck Herrick) (02/06/91)
this is to announce that the creation of a new newsgroup is being seriously considered. The name of the news group will be comp.sys.next.mac_emulation and the group will be implemented as a pointer to /dev/null. All mac emulation posts can then be directed to comp.sys.next.mac_emulation and not to comp.sys.next -- The opinions expressed herein are mine and are in no way attributed to any of the many people for whom I work. Who they are is irrelevant.
fozzard@alumni.colorado.edu (Richard Fozzard) (02/09/91)
In article <1387@west.West.Sun.COM> lwake@runcible.West.Sun.COM (Larry Wake) writes: >In article <1991Feb4.211511.1256@csn.org> fozzard@alumni.colorado.edu >(Richard Fozzard) writes: >>Of course, who would buy a Sun, then pay $895 more to run a non-multifinder >>1 MB Plus? (Though you can run multiple copies of it, they are totally >>separate machines; different file systems, no copy/paste, etc.) > >Real estate. I have a Sparc 1+ on my desk. I want to run PC >programs. I want to run Mac programs. I don't want to put two more >monitors, keyboards and mice on my desk, let alone look for someplace >... Sorry - I didn't mean to imply that that I thought the emulation was worthless - quite the contrary, in fact. I only meant that it probably wouldn't cause Apple many lost sales, and hopefully therefore, thay wouldn't cause any legal trouble about it. rich -- ======================================================================== Richard Fozzard "Serendipity empowers" Univ of Colorado/CIRES/NOAA R/E/FS 325 Broadway, Boulder, CO 80303 fozzard@boulder.colorado.edu (303)497-6011 or 444-3168