To hurtige, nysgerrige spørgsmål.
Kan den forstærkede processor give problemer i ældre spil og programmer, på samme måde som man kender det fra DOS maskiner? Hvor mange spil var kodet til CPU'ens hastighed direkte, og ikke til en internt clock?
Der er meget få programmer og spil der kun kan køre med en bestemt kickstart ROM.... De større 680x0 CPUere er dog fuldt bagudkompatible... så 99.9% af alle spil og programmer kan køre fint.
Amiga maskiner har fra start af ikke været defineret som en standard modsat fx IBM PC eller MSX. Jeg kender ikke til nogen programmer der kører for hurtigt på en hurtigere CPU. Problemet var kendt fra IBM verdenen da de første Amigaer udkom, og det var allerede på det tidspunkt dårlig kutyme at lave CPU-bundne programmer. Langt de fleste spil eller programmer er derfor ikke bundne til clock'en.
Workbench, som de fleste "boot"-spil og programmer booter igennem, har sin egen API til tidsstyring som er uafhængig af CPU-hastighed. Jeg mener denne har en opløsning ned til ½ millisekund. Denne API, ligesom andre Workbench-komponenter kan frit vælges eller vrages alt efter hvad man har brug for i sit projekt. I den forstand minder Workbench lidt om .NET, hvor du vælger fx. System.DateTime til tidsstyring, samt System.Windows.Forms til GUI vinduer... Disse standardbiblioteker kan så frit stykkes sammen til at lave en custom Workbench der kan boote, loade og køre dit program fra fx. diskette eller direkte fra en fuld Workbench instans du selv har bootet op.
Det fungerer meget som Windows' .DLL filer, men er meget mere fleksibelt
Afhængig af sproget programmet er skrevet i er det enten svært, dumt eller direkte umuligt at binde et program direkte til CPU-hastigheden. BASIC og ARexx er som regel helt underlagt Workbench. Andre sprog som fx. AMOS har sin egen veldokumenterede metode til dette. I Assembly er det muligt at binde sig til CPU, men igen er det (for) nemt at tage libraries enten fra Workbench eller noget der er leveret med assembleren selv.
Så i sidste ende gør du det blot langt sværere for dig selv at binde din kode direkte til CPUens hastighed
Hvordan gør du brug af den ekstra diskplads? Er den store partition direkte brugbar af Amiga'en, eller er den til at mounte diskbilleder vha. et program eller lign?
4GB begrænsningen ligger i filsystemerne OFS og FFS, der er standard og da Workbench er indrettet til begrænsningen, vises pladsen ikke altid korrekt i fx HDTools.
For at bruge mere diskplads, skal man patche driveren scsi.device der er driver for både SCSI og IDE drev. Det er fordi driveren ikke tjekker om der skrives til et område over de første 4 GB, og laver et buffer underflow/roll-around, med fare for data der ligger i de første 4 GB.
OFS/FFS virker fint på partitioner på op til 4 GB, men igen er partitions/formateringsværktøjer til Workbench ikke indrettet til mere end 4 GB.
Med en særlig "Direct SCSI" driver kan man tilslutte en SCSI harddisk på op til 8 GB dog.
Vil man have en sammenhængende partition, kan man formatere med et 3.parts filsystem; fx. PFS eller SFS, der kan klare diske over 4 GB natively. Sammen med en patched scsi.device driver der kan læse større diske kan man omgå begrænsningen. Der findes dog en del metoder til at bruge større diske.
Det sidste link under "nyttige links" forklarer det lidt mere i detaljer end jeg kan
GUI'en i Workbench 2.1 og 3.1 har dog også lidt problemer med 4GB+ da tælleren også "underflower". Fx vises noget i stil med "2,753M total" (den ekstra plads udover de 4 GB). Men tælleren for brugt plads virker korrekt, så du kan få en situation hvor vinduet for et drev viser "2,753M total, 5,600M used". Situationen kan også ses i et screenshot i det link jeg nævner.
Harddiskcontrolleren og Kickstart i oprindelige Amigaer har dog en hard limit på 128 GiB/137 GB, som i alm. PC'ere indtil starten af 2000'erne, fordi Kickstart indlæser harddiske med 24-bit LBA. Større lagermedier end det er derfor helt udelukkede.
Selve partitionen fungerer som almindelig harddisk som man kender det fra Windows. Programmer kan ofte bare kopieres direkte over i en mappe (eller en skuffe som det hedder i Workbench). Det samme kan man gøre med nogle spil... de fleste spil er dog bootable, beregnet til at blive startet op med maskinen udenom Workbench.... men disse kan også installeres med Installer og WHDLoad programmerne.
Disk images (.adf og .iff oftest) kan man ikke mounte som fx. med Daemon Tools som på Windows. Ikke under Workbench i hvert fald... Har du derimod en computer med AmigaOS 4 kan det lade sig gøre da disse har ressourcerne til det. Et alternativ til alle Amigaer der indlæser diskette images via hardware er floppy-emulatorer, fx. Gotek drev.
Da en Amiga diskette har enten 880KB eller 1770 KB (dem der kan tage HD disketter), og en standard Amiga ofte har et sted mellem 512 KB og 4 MB RAM har indlæsning af images på denne måde ikke været mulig med software. Selvom en 68030 eller endda en 68060 CPU er ret hurtig ift. 68000'eren, er de dog ikke hurtige nok til at emulere hardwaren samtidig med at fx. et spil afvikles.
Har man brugt XCopy på ægte, stock hardware og et enkelt diskettedrev kan man godt se grunden til det. Kilde- og kopi-disketten skal byttes 3-4 gange, da XCopy indlæser en bid af kildedisketten der svarer til den ledige RAM, ofte et sted mellem 192 og 384 KB på en stock A500.