Virtuele CMOS batterij vervangen.

door Henri Derksen

cmos sprite Het komt helaas voor dat Virtual RiscPC SE en/of SA op zowel een Windows machine als ook op een Apple Mac (Belgische ervaring) de virtuele machine een keer goed is gecrashed, VA-RPC SE of SA niet meer goed op wil starten. Alle bestanden zijn aanwezig, en ook de instellingen (aan de hostzijde) zijn het zelfde gebleven, maar toch start VARPC na de geheugen check niet verder op en gata hangen. En het erge is, je krijg ook geen * prompt, zodat je nog wat zou kunnen uitrichten met *Configure CMOS-instellingen e.d..

Hee, CMOS, daar zit wat in. De batterij is een zaak van de baas (lees Windows op Apple (fruit-)machine). Maar hier is sprake van een virtuele CMOS batterij die de instellinge vasthoudt. Nee, niet in een echte chip, maar in een bestand. En bij een crash is nu net dat CMOS.RAM bestand defect geraakt. Weggooien en dan VARPC SE of SA opneiuwe opstarten geeft je weer een *prompt, maar dan ben je wel al je cmos instellingen kwijt. Kan dat anders? Ja gelukkig wel.

Maak onder het gast operating system Windows 2000/XP/Vista/7 of Apple MacOS een copie van het bestaande CMOS.RAM bestand. Na een crash hoef je dan alleen maar dat CMOS bestand terug te copieren naar z'n originele naam. Dit CMOS bestand kan op 4 plaatsen voorkomen:

VARPC SE:

  C:\ProgramFiles\VirtualAcorn\VirtualRPC-SE\Models\ARM7RISCOS4(Jit)\cmos.ram

VARPC SA:

  C:\ProgramFiles\VirtualAcorn\VirtualRPC-AdjustSA\Models\ARM7RISCOS Adjust(Jit)\cmos.ram
  C:\ProgramFiles\VirtualAcorn\VirtualRPC-AdjustSA\Models\ARM7500 RISCOS Adjust(Jit)\cmos.ram
  C:\ProgramFiles\VirtualAcorn\VirtualRPC-AdjustSA\Models\StrongARM RISCOS Adjust(Jit)\cmos.ram

Vanwege RISC OS 4.02 en RISC OS 4.39 Adjust 1i2 zijn er ook nog andere combinaties van paden mogelijk met VARPC-SE en VARPC-SA. En om het nog fraaier te maken, is natuurlijk ook nog RISC OS 6.20 Select 6i1 mogelijk op al deze varianten. Maar dat is softloadable aan de RISC OS kant derhalve en voor dit onderwerp niet als eerste van belang. Maar ook daarin wordt natuurlijk een (softwarematige) cmos file aangehouden, maar dat staat los van de "hardwarematige" cmos file behorende bij de VA RPC SA of SE emulator aan de hostzijde, in casu Windows of MacOS.

Om de zaak naar je zin fijn te slijpen kun je op je meest favoriete machine eens de CMOS gegevens opvragen met *STATUS, en die ook op je VARPC SE of SA machine hetzelfde gaan configureren, en daarna die backup van cmos.ram maken naar b.v. cmos.bak o.i.d.. Je hebt dan bijna direct de meest gewenste situatie weer terug, of toch niet? Nee helaas, want nu wordt de klok onder RISC OS niet goed bijgehouden, en staat het jaartal 1902 aan te wijzen ;-(. Die moet je na het terugzetten van de CMOS.RAM backup file dus altijd even aanpassne met !Alarm o.i.d.

En als we toch bezig zijn met veiligstellen, dan is een copie maken van HardDisc4.hdf (image) ook wel een idee. Daar moet je echter wel de ruimte voor hebben, want die image is redelijk groot.

Zo wie zo is het slim om ook een copie te maken van de aangeschafte VARPC CD-Rom, want dit is een CD-R (uniek gebrand exemplaar) en die is altijd kwetsbaarder dan ene geperste CD-Rom. Daarnaast is ene copie van de UnLock Code van belang voor als je ooit echt eens ee volledige herinstallatie zou moeten doen. Zeer zeldzaam, want ik heb dat in de ruim zes daar dat ik VA RPC SE en SA beiden heb nog nooit hoeven doen. CMOS.RAM terugzetten wel helaas. Het komt b.v. ook voor als de accu van de laptop leeg raakt en Windows plotseling wordt afsgeloten terwijl VARPC nog draaide. De keer daarop is dan die inmiddels beruchte CMOS.RAM file defect. Deze wordt namelijk in elke sessie aangepast.

Ik hoop dat hiermede uw batterijen weer voldoende zijn opgeladen om de zomer door te komen? Anders moet u toch echt aan een zonnepaneel gaan denken voor de accu van uw laptop ;-).

Veel echt- en virtueel plezier gewenst door Henri.