Mini vMac

Mini vMac er en åpen kildekode, fri grafisk programvare som er implementert i C og designet fra offset til å fungere som en emulator for Macintosh Plus datasystemet som ble opprettet av Apple, kjører på Linux, BSD, Microsoft Windows og Mac OS X operativsystemer.

Å være en av de tidligste Macintosh-maskinene designet av Apple, kjører Macintosh Plus bare gammel Mac-programvare, som selvfølgelig ikke fungerer på nyere Macintosh-maskiner. Derfor hjelper Mini vMac-programvaren til å bevare historien. Den er designet for å være så enkel å bruke, bærbar og enkel som mulig.

Hvis du vil bruke Mini vMac-programmet på GNU / Linux-systemet, må du sørge for at du laster ned den binære pakken som tilsvarer datamaskinens maskinvarearkitektur, lagrer arkivet et sted på datamaskinen, pakker ut det og dobbeltklikker på kjørbare .

Programmet åpnes, og informerer deg om at et ROM-bilde av Macintosh Plus-systemet ikke kan plasseres. Dette betyr at du også må oppnå en vMac.ROM-fil (flere detaljer finner du på prosjektets hjemmeside) og legger den i samme mappe som Mini vMac-kjørbar.

Etter at du har fått Macintosh Plus ROM-bildet, må du lukke programmet og åpne det på nytt. Hvis ROM-filen er gyldig, starter systemet automatisk og lar deg bruke det som om du vil bruke et annet virtualisert operativsystem.

Denne programvaren er faktisk en spinn av vMac-applikasjonen, som ikke har blitt oppdatert i mange år. For enkelhets skyld blir den distribuert som pre-built binære pakker for de nevnte operativsystemene, og støtter både 64-biters (x86_64) og 32-bits (x86) instruksjonsarkitekturer.

Kilden til applikasjonen er også tilgjengelig for nedlasting, for de som ønsker å optimalisere programvaren for en bestemt maskinvareplattform eller operativsystem.

Hva er ny i denne utgivelsen:

• Dagens Mini vMac 3.5.8 oppdaterer den stabile versjonen for å løse et problem på PowerPC OS X, og løser også et problem som påvirker Variasjonstjenesten. Mini vMac 3.5.8 på andre plattformer enn PowerPC OS X ('mach') og x86-32 OS X ('imch'), bør være identisk med Mini vMac 3.5.7, bortsett fra versjonstrengen og modifikasjonsdatoen.
• Det ble rapportert at "Mini vMac 3.5.7 vil ikke kjøre på PPC G3-systemer". Det viser seg at GCC-flagget "-macacx-versjon-min" bør spesifiseres for alle filer kompilert, ikke bare plattformavhengig kode. Det påvirker ting som nødvendig CPU. Å gjøre denne endringen skjer for å ha ingen effekt på Mini vMac for x86-64 OS X, det er noen effekt for x86-32 OS X, og den største effekten er for PowerPC.

Hva er nytt i versjon 3.3.3:

• Nye funksjoner i standardkompilering:
• Flere operativsystemer støttes offisielt av Mini vMac:
• FreeBSD på x86-32 (Bruke "-t fbsd" i byggesystemet)
• FreeBSD på x86-64 ("-t fb64")
• OpenBSD på x86-32 ("-t obsd")
• OpenBSD på x86-64 ("-t ob64")
• NetBSD på x86-32 ("-t nbsd")
• NetBSD på x86-64 ("-t nb64")
• Dragonfly BSD på x86-32 ("-t dbsd")
• Dragonfly BSD på x86-64 ("-t db64")
• OpenIndiana på x86-32 ("-t oind")
• OpenIndiana på x86-64 ("-t oi64")
• Linux på ARM ("-tarm")
• Linux på SPARC ("-t lspr")
• Minix 3.2 ("-t minx")
• Disse portene tilpasser den samme X-vinduekoden som Linux-porten, og bør ha samme funksjonalitet, bortsett fra for øyeblikket ikke lyd for noen. X86-64-versjonene er for tiden langsommere, for manglende monteringsspråk-tweaking, og bør ikke brukes hvis x86-32-versjonene skal fungere.
• X-versjonene kan nå spille av lyd ved hjelp av Open Sound System (OSS) API. (Vanligvis bruker kompatible implementeringer på hvert operativsystem, i stedet for den offisielle OSS selv.) Lyd er nå aktivert som standard på FreeBSD og NetBSD. Lyd kompilerer uten problemer (bruk "-ound 1") på Dragonfly BSD og OpenIndiana, men jeg har ikke klart å teste på disse ennå. Å få lyd på Dragonfly BSD synes å kreve noen manuell oppsett. OpenIndiana synes ikke å produsere noen lyd i det hele tatt i VMware Fusion. Lyd kompilerer også uten problemer på OpenBSD, men det virker ikke - innstilling av den ønskede samplingsfrekvensen mislykkes. Minix synes ikke å støtte lyd enda. Det er også mulig å bruke OSS API på Linux, ved hjelp av den nye "-snd-api" bygge systemalternativ.
• X-versjonene vil nå prøve å se i mappen inneholder programmet for ROM-bildet, som Macintosh og Windows-versjonen gjør. (Og også for disk1.dsk og så videre filer.) Hvis søknadskatalogen ikke kan bestemmes, brukes gjeldende katalog som før. Dette er implementert for Linux, FreeBSD, NetBSD, Dragonfly BSD og OpenIndiana, men ikke OpenBSD og Minix.
• X-versjonene har nå et nytt kommandolinjealternativ "-d [directory_path]", der [directory_path] brukes i stedet for applikasjonsmappen når man ser etter ROM-bildet og disk1.dsk og så videre filer .
• X-versjonene har nå et nytt kommandolinjealternativ "-n [app_name]", der [app_name] brukes i stedet for programnavnet for tittelen på Mini vMac-vinduet.
• X-versjonene støtter nå en sentral ROM-mappe som Macintosh og Windows-versjonene har. Hvis "~ / .gryphel / mnvm_rom" eksisterer, vil Mini vMac se etter ROM-bildet. Hvis det ikke er der, vil det se ut i programkatalogen. (Og alternativet -r kommandolinje vil overstyre begge.)
• Endret oppførsel i standardkompilering:
• Tegning av den emulerte skjermen til den virkelige skjermen er mer effektiv. Når fargedybden er 4 biter eller mindre, i stedet for å konvertere hver piksel, er det et bord med 256 oppføringer for å konvertere en byte om gangen. Det er også mer forsiktig med kun å konvertere piksler i rektangelet som begrenser det endrede området, i stedet for hele skjermen.
• Linux-versjonen laster dynamisk ALSA-biblioteket for å spille av lyd, slik at Mini vMac fortsatt kjører uten lyd, selv om ALSA ikke er installert. (Denne teknikken ble sett i SDL.) Som standard er Linux-versjonen nå kompilert med lyd, som samsvarer med Mac- og Windows-versjoner.
• I Linux-versjonen, når du spiller lyd med ALSA, blir ikke snd_pcm_delay kalt lenger. Forsinkelsen til en prøve blir spilt er ikke særlig relevant. Hva Mini vMac trenger å vite er tid til å buffer underkjøring. Så Mini vMac ser nå bufferstørrelsen minus ledig plass i bufferen, noe som kan være mer nyttig, med det formål å forhindre bufferunderkjøring mens minimering av latens blir
.
• X-versjonene bruker nå rådgivende låsing for å nekte å åpne for å skrive et diskbilde som har blitt åpnet for å skrive av en annen kopi av Mini vMac. Tidligere kunne X-versjonene av Mini vMac åpne et allerede åpnet diskbilde, som sannsynligvis ødelegger bildet. Hvis Mini vMac bare kan åpne en skrivebeskyttet disk, for eksempel fordi brukeren har låst filen, blir ikke den rådgivende lås brukt, og flere kopier av Mini vMac kan bruke den.
• X-versjonene prøver nå å bruke programnavnet til å angi tittelen på vinduet, som Macintosh og Windows-versjonene har. (Hvis applikasjonsnavnet ikke kan bestemmes, brukes "Mini vMac" som tidligere.) Dette er funnet samtidig med programkatalogen, og er implementert for de samme operativsystemene.
• Kommandolinje argumenter blir nå skannet før du leter etter disk1.dsk og så videre filer. Dette er nødvendig for den nye "-d" alternativ til arbeid, og har bivirkningen at hvis diskbilder er spesifisert på kommandolinjen, vil de bli åpnet først. Hvis det er bilder på kommandolinjen, vil Mini vMac ikke bry deg om å lete etter disk1.dsk i det hele tatt.
• "-l" (eller "/ 1" på Windows) kommandolinjevalg er fjernet. Den "-speed z" alternativet til byggesystemet bør brukes i stedet. Kommandolinjevalget var fra før byggesystemet eksisterte, og beslutningen ble gjort for å favorisere bygge-tidsalternativer i løpet av kjøretidsalternativer.
• Feilrettelser i standardkompilering:
• Windows-versjonen kartlegger nå Enter-tasten på talltastaturet til Macintosh Enter-tasten. Det kan nå skille den nøkkelen fra Enter-tasten på hovedtastaturet, som er kartlagt til Macintosh Return Key. Det var tidligere ingen måte å skrive inn Macintosh Enter-tasten. Takket være "Alex" for å påpeke dette problemet.
• I Windows-versjonen, i fullskjermmodus, er kontrollen for om en nøkkel nedhendelse en autorisert nøkkel feil. Så potensielle nøkler kunne ha blitt ignorert når de ikke burde vært. Jeg har fjernet sjekken, siden det ikke er klart hvordan du gjør det riktig (når du bruker en "lavt tastaturkrok"). Dette påvirker ikke Macintosh-emulering, siden det er en ekstra sjekk for overflødige hendelser. Det kan påvirke kontrollmodus, for eksempel når du holder nede Control-M.
• Windows-versjonen reagerer nå på WM_QUERYENDSESSION-meldingen, slik at hvis du prøver å slå av datamaskinen med Mini vMac kjører (med monterte diskbilder), vil Mini vMac klage og stoppe nedleggelsen.
• I Linux-versjonen, ved å bruke ALSA til å spille av lyd, ble snd_pcm_start kalt før du lagde noen lydprøver i ALSA-bufferen. Dette kan føre til stamming i begynnelsen, eller i henhold til en rapport, forhindrer at lyden fungerer i det hele tatt. Mini vMac venter nå til den private bufferen er full, og overfører så mye som passer inn i ALSA-bufferen, og begynner deretter å spille av lyd.
• Når Linux-versjonen er kompilert for ARM, inkluderer den en sjekk at resultatet av snd_pcm_avail_update ser rimelig ut, og hvis det ikke kalles snd_pcm_status_get_avail i stedet. Dette virker rundt hva som synes å være en feil i Raspbian for Raspberry Pi.
• Den emulerte klokken ble ikke riktig initialisert, og var bare korrekt etter den første "andre" avbryter.
• Hvis det emulerte skjermbildet er for stort til å passe på den virkelige skjermen (når autoscroll er tilgjengelig), hvis området på det emulerte skjermbildet som er endret, ikke skjærer det synlige området på det emulerte skjermbildet, var et ugyldig rektangel det brukes til tegning. Jeg oppdaget dette når jeg prøvde Vector Linux 7, som synes å ha noen ekstra feilsøkingstester.
• I usannsynlige tilfeller kan ikke autoscroll i fullskjermmodus bla for å vise den siste raden med piksler nederst eller den siste kolonnen av piksler til høyre.
• Hvis vertsmaskinen ikke er rask nok til at Mini vMac skal kjøre med 1x hastigheter, vil Mini vMac ikke løpe jevnt og pausere i noen få sekunder med jevne mellomrom. Testen for denne situasjonen var feil, og en byte-teller ville overflyte. (Har slike tellere så små som mulig gjør det lettere å oppdage feil som dette.)
• I X Window-versjoner av Mini vMac, når du bruker Mini vMac-utvidelsen til å lage en fil på vertssystemet, for eksempel med ExportFl, blir ikke en lagringsdialog implementert. Tidligere ble filen enkelt opprettet i søknadskatalogen med den søkte etter navn. Dette var ikke trygt, i verste fall lar det et program kjøre i Mini vMac for å erstatte Mini vMac-applikasjonen. Så nå vil filer istedet bli opprettet i en mappe med navnet "output" i katalogen som inneholder søknaden. Denne mappen vil bli opprettet hvis den ikke eksisterer.
• I Microsoft Windows-versjonen, hvis en bane til et diskbilde overføres til Mini vMac på kommandolinjen som er lengre enn det som er lovlig for en bane, resulterer en bufferoverløp.
• Windows CE-versjonen fikk litt rot. Den samler nå og fungerer i hvert fall på Microsoft Device Emulator med Windows Mobile Version 5.0. Jeg har ingen anelse om det fungerer på ekte maskinvare. Er det noen som bryr seg? (Windows Mobile ble utgått og erstattet av Windows Phone.) Denne porten begynte å forstyrre å opprettholde hovedvinduversjonen, og valget var å fjerne det helt eller gjøre det vedlikeholdbart.
• Nye funksjoner som ikke er i standardkompilering:
• Alternativet for nytt byggesystem "-lt" gjør Mike Forts LocalTalk-emulering mulig. Det er for tiden noen begrensninger. Det er bare implementert for OS X. Det kreves å kjøre kommandoen "sudo chmod ugo + rw / dev / bpf * & quot; for å tillate Mini vMac (og alle andre) tilgang til all nettverkstrafikk. Den "-lt" Alternativet kan også føre til at Mini vMac kjører i bakgrunnen som standard, fordi Mini vMac ikke kan være en riktig LocalTalk-node hvis den ikke kjører. Og du må manuelt slå AppleTalk i velgeren. Jeg kan sette PRAM-flaggene for å starte opp med AppleTalk allerede, men det virker ikke riktig.
• Et nytt byggealternativ for systemet "-lang pol" velger en polsk oversettelse av brukergrensesnittet av Przemyslaw Buczkowski.
• X-versjonene har opprinnelig støtte for farge (for Mac II-emulering). X versjonen har hittil bare støttet 24 bit "TrueColor", og har noen andre begrensninger på formatet. Jeg tviler på at alt annet enn TrueColor brukes på moderne maskiner, og sannsynligvis ikke støtter de andre alternativene. Andre dybder som 15, 16 og 32 biter kan brukes, og så sannsynligvis skal støttes, hvis jeg kan finne en måte å teste dem på.
• Et nytt system for byggesystemer "-mf" tillater endring av forstørrelse fra standard 2. For eksempel, "-mf 3" setter forstørrelsen til 3. Alternativet "-mf 1" deaktiverer forstørrelse (fjerner Control-M-kommandoen). Forstørrelsesfaktoren må være et heltall.
• Endret oppførsel ikke i standardkompilering:
• Standard fargedybde for Mac II-emulering er "-depth 3" i stedet for "-depth 0".
• For Macintosh II-emulering er AutoSlow nå deaktivert som standard "-as 0". AutoSlow kan trenge litt ytterligere tuning for å fungere godt med Mac II-emulering.
• I X-versjonene blir resultatene av fwrite og fread på diskbilder nå sjekket for feil, som stopper kompilatorvarsler i nyere Ubuntu.
• Feilrettelser ikke i standardkompilering:
• Løst en feil i DIVS.L instruksjonen rapportert av "AP". (En 68020 instruksjon som brukes i Mac II emulering.)
• Fiks BFFFO instruksjonen, som ble helt ødelagt, som rapportert av "AP". (En annen 68020 instruksjon som brukes i Mac II emulering.)
• Bitfeltoperasjoner på et register bruker nå rotere i stedet for skift. De valgte bitene kan ikke være sammenhengende, som påpekt av "AP", og bekreftet av dokumentasjonen. (Bitoperasjonsfelt ble lagt til i 68020.)
• Bitfeltoperasjoner på minnet prøver nå bare å fungere på så mange byte etter behov. Tidligere opererte den alltid på 5 byte, noe som kunne ha uønskede effekter hvis den opererer på en minnekortet enhet, som påpekt av "AP".
• "MoveP.L, Dn" instruksjon blandet rekkefølgen for skifting og maskering, og så ble det helt ødelagt, som rapportert av "AP".
• Hacken som tillater ekstra store mengder Video RAM i Macintosh II-emuleringen fungerte ikke på riktig måte fordi en rekkefølge som ble brukt for adresseromoversettelse i CPU-emuleringen ikke ble allokert stort nok. Nå velger byggesystemet tildelingsstørrelsen. (Dette problemet ble observert for 1024x768 med millioner av farger.) Ytterligere detaljer: Hvert NuBus-kort får bare 1M adresserom når datamaskinen er i 24-biters modus. Og en Mac II synes vanligvis å tegne i 24-bit modus. Når mer video RAM er nødvendig for de ønskede kompileringstidsalternativene, bruker Mini vMac adresserommet fra tilstøtende NuBus-spor.
• Fast "-min-extn" bygge alternativ i Linux-versjonen.
• Bygg system:
• Lagt til bygge systemalternativ "-api cco" å bruke Apples kakao-API for OS X i stedet for den utdaterte Carbon API. Men kakao-porten til Mini vMac er ennå ikke vurdert som helt klar til å bli offisielt støttet, og derfor brukes Carbon-versjonen fortsatt.
• Lagt til bygge systemalternativ "-api sdl" å bruke Simple DirectMedia Layer 1.2 API. Dette ble lagt til som en stepping stone til Cocoa-porten - ved å kombinere kildekoden for SDL med kildekoden for en SDL-port av Mini vMac, og deretter fjerne alt som ikke trengs, og deretter mye rydde opp til en opprinnelig innfødt kakao porten dukket opp. SDL-porten kan imidlertid brukes som til port til andre plattformer som støttes av SDL. Men dette er ikke (ennå) offisielt støttet.
• Tilleggsbygg systemalternativet "-t mx64" for Apples X11-implementering på x86-64. (Tidligere ble x86-32 og PowerPC støttet.)
• Tilleggsbygg systemalternativet "-t cygw" for Cygwin / X for Microsoft Windows. Cygwin kan også brukes til å kompilere den vanlige Microsoft Windows-versjonen med "-t wx86 -e cyg".
• Tilleggsbygg systemalternativet "-t irix" for IRIX av Silicon Graphics, Inc., takket være John Perkins.
• MinGW kan brukes til å kompilere Mini vMac med bygge system alternativet "-t wx86 -e mgw". Siden Bloodshed Dev-C ++ er basert på MinGW, "-t wx86 -e dvc -cl" vil tidligere gi lignende resultater.
• Endret rekkefølge av argumenter til koblingskommandoen når du bygger Linux-versjonen. Det viser seg at det er en konvensjonell rekkefølge for hvordan bibliotekene skal spesifiseres, som jeg ikke visste siden jeg ikke hadde kommet over en linker som brydde seg til Ubuntu 11.10.
• Byggesystemet skal nå fungere skikkelig i andre emulatorer som SheepShaver. Det ble anonymt rapportert at byggesystemet ville krasje emulatorer. Testen for om byggesystemet kjørte i Mini vMac (slik at det resulterende arkivet kan eksporteres til verten) var ikke godt nok.
• Byggesystemet undertrykker nå varslingsmeldinger som ble generert ved kompilering av Macintosh II-emuleringen med Microsoft Visual C ++, takket være en rapport fra William Grana.