De Iyonix PC logeerde begin februari bij regio Oost.

Helaas wegens ziekte wat later dan gepland, maar hier is hij dan toch, het verslag van de belevenissen met de club Iyonix PC bij Big Ben Club regio Oost, in de periode 31 januari t/m 7 februari 2003. Om de regio voor te bereiden op wat komen ging, was ik al in een vroeg stadium op zoek gegaan naar de andere locaties waar de machine eerder werd getoond. Zo heb ik op 28 december 2002 in Amsterdam het verhaal van Paul Porcelijn en Charles Deckers gevolgd, en diens verslag goed bestudeerd. Ook die week daarna op 2 januari bij regio Den Haag was zeer interessant om er de nodige kennis van op te steken. Wat daar voor primeurtjes werden getoond (snelle utp-verbinding b.v.) zal hopelijk nog in een verslag verschijnen.

Op donderdagavond 30 januari 2003 mocht ik de machine overnemen van Kees Grinwis van de werkgroep Acorn-NL. Omdat dit een avond bijeenkomst was, kwam ik natuurlijk pas op vrijdagmorgen vroeg thuis ;-). Helaas vrijdag overdag toch met problemen begonnen. Het werken met diskettes bleek zo falikant fout te gaan dat de gehele machine regelmatig compleet hing, floppies softwarematig werden beschadigd, en dat over meerdere dagen, tot ik de oorzaak ontdekte (zie verderop).

Wat me wel opviel was dat na het ingeven van een commando met de muis, zoals start verify, er een duidelijk merkbare vertraging optreedt (zeker in vergelijking met de RPC) voor het commando aan de slag gaat. Bij een 2e poging ging het weer wel snel. Op deze manier krijg je wel heel duidelijk het gevoel met andere hardware te werken. Echter Capslock en Numlock zijn niet van status te veranderen, na diskerrors. Het zou heel goed kunnen dat inderdaad ShareFS (netwerk software) de boel laat hangen. Dat komt op andere machines ook heel regelmatig voor. Vanaf het begin van aansluiten heb ik een crosscable tussen de netwerkpoort van de Iyo gehangen die naar m'n RPC loopt. Toen maar even aan de RPC-zijde netwerk software opgestart (ik gebruik de !Ant internet stack, vandaar.) En even op de Iyonix van diens harddisk naar de ramdisk op de RPC copieren ging vlekkeloos. Dit noem ik "brengen". Je kunt ook bestanden gaan "halen". D.w.z. op de RPC de gesharede schijf van de Iyonix openen en daarvandaan iets ophalen en op een lokaal opslagmedium (HD, Jaz, Ram) plaatsen. En ook dat ging prima. Nu het netwerk goed draait, toch eens kijken of op flop zetten nu wel goed gaat? Nee dus... Ook maar eens zonder netwerk proberen, want ik heb al vaker het vermoeden gehad dat ShareFS regelmatig voor moeilijkheden zorgt. Hielp niets.

Uiteindelijk kwam ik erachter dat een van de vorige testers de USB-kaart in een ander PCI slot had geplaatst. Op zich zou dat toch moeten kunnen? Kennelijk bij PCI niet dus. Je bent verplicht altijd in een vast slot te beginnen en alle volgende kaarten er achtereenvolgens naast te zetten. Er mogen dus geen onbezette PCI-sloten tussen meerdere kaarten in zitten. De videokaart zat nog steeds in slot 1. Dus de USB-kaart van PCI-slot 4 naar slot 2 verhuisd en alles werkte weer ok. Ook was het voorheen zo dat de USB toetsenbord-stekker en de USB-muis-stekker persé in een bepaalde connector moesten zitten als je b.v. met shift-break wilde booten. Dat zijn de USB-aansluitingen op de PCI kaart zelf achterin de machine. Met de komst van RISC OS 5.02 maakt de keuze van de connectoren niet meer uit, al heb ik daar incidenteel nog m'n twijfels over.

Vrijdagavond (31 januari) even de !Boot onderzocht: Er kunnen 28 CD-Rom-drives worden geconfigureerd ;-) Wat opvalt is dat je er geen IDE-discs kunt configureren. Dat gebeurt in de Iyonix volautomatisch. Ook is het niet meer nodig om de jumpers van interne IDE-apparaten op master en slave te zetten, maar op cable select. De Iyonix zoekt het dan verder zelf uit. Helaas is er geen support voor andere E-IDE/ATAPI loopwerken dan CD-Roms en CD-branders aanwezig. Op 8 februari in Zaandijk hebben we de ATAPI E-IDE Zip 100 MB drive getest, maar die zag hij in het geheel niet, ook niet op de 2e IDE-bus. Toen hebben we ook de interne harddisk en Sony IDE-brander op de 2e bus geprobeerd, en dat werkte wel in een keer vlekkeloos. Iomega ZIP drives (parallel, E-IDE/ATAPI, of SCSI) zijn op de Iyonix voorlopig dus nog niet bruikbaar. Een parallelle poort ontbreekt. Voor de interne IDE/ATAPI ontbreekt de software, en SCSI is ook nog niet mogelijk, niet via podules en niet via PCI-sloten. Een en/of beide SCSI methodes zal in de toekomst zeker wel mogelijk worden. In ieder geval heeft Paul Reuvers ons de hardware bezwaren van Paul Porcelijn kunnen weerleggen. D.w.z. er komt een zigzag-podule-backplane en ook de connectoren van alle interne aansluitingen zitten net niet in de weg als je goed kijkt, gelukkig maar dus ;-).

Configuratie

Bij Screen bleek het scherm standaard op de AKF50 te staan. Die wilde ik dus even resetten naar de Lite On 170 TFT LCD monitor die voor de Iyonix is gekocht, maar op dat instellen zit een time-out, niet voor iedereen even prettig. Maar wellicht is dat gedaan om inbranden bij een verkeerde keuze te voorkomen? Daarnaast bleek de monitor definitie file voor de Lite On onvolledig te zijn. Deze opnieuw aangemaakt en van uitgebreid commentaar voorzien.

Bij Window setup mis ik Desktop Shutdown warning on y/n. Dat vind ik toch wel essentieel als je per ongeluk op Shutdown hebt geklikt. Textured menus, maar dat willen niet zo veel mensen, is dus geen gemis. Alternative menu texture ontbreekt ook, is minder erg. No iconboxes in windows ontbreekt. No iconboxes on pinboard. Het niet meer kunnen uitschakelen van de 3D window borders (2D dus) vind ik wel een groot gemis. Voor velen niet maar ik wil graag rust in beeld, dus liever 2D dan 3D. Ook voor de visueel gehandicapten speelt dat. Maar wellicht is daar nog iets anders aan te doen. Ja, dat lukte met een aanroep: $.!BOOT.Choices.Boot.PreDesk.Config2D | 2D icons in windows i.p.v. 3D t.b.v. slechtzienden. *ToolSprites <Boot$Dir>.Resources.Configure.2DTools werkte perfecto ;-).

Zaterdagmorgen 01-02-03
Paul Reuvers heeft een mooie 32bit serial blockdriver (Internal32) gemaakt, op basis van versie 10a en heeft die (helaas) versie 11 genoemd. In de RISC OS wereld bestonden al de versies 11, 11a, 11b en 12. Hij is daarvan nu op de hoogte en zal het tzt aanpassen. Daarnaast komt er in de toekomst nog een serial blockdriver voor de 2e interne seriële poort en voor een ESB naar serieel verloopkabeltje.

Hoe mooi die serial blockdrivers werken en geïnstalleerd kunnen/moeten worden blijkt uit het prachtige programma !Enigma van Paul Reuvers. Zie daartoe het Choices window en de interface-keuzes. Zo kan het dus ook, i.p.v. zoals bij !Hearsay en !Arcfax ergens diep in de applicatie een tekstbestand aan te moeten passen als men van een andere seriële poort gebruik wil maken. Ik heb enorm veel bewondering voor de hoeveelheid achtergrondwerk die in Enigma moet zijn gaan zitten.

Op ons verzoek heeft Paul Reuvers RISC OS 5.02 in de eeproms van de club Iyonix geflashed. Tja waarom van de website afhalen als de dealer op bezoek is ;-). Paul heeft ons toen met behulp van een beamer en groot scherm vele geheimen van de Iyonix getoond. Zelfs de testversie van Aemulor werkte al. Ook heeft Paul ons aan de hand van de geopende computer uitgelegd hoe het moederbord is opgebouwd, waarom men bepaalde keuzes heeft gemaakt. Zo zijn losse insteekvoeten met de hoge snelheden van tegenwoordig gewoonweg niet meer mogelijk.

Een ander punt van vele vragen was het onderwerp USB. Op het moederbord is inderdaad een USB chipset aanwezig. Waarom dan toch een PCI-USB-kaart er in gezet? Antwoord: De fabrikant had een 64 bit USB gemaakt, waarvan de bovenste 32 bits niet werden gebruikt. Volgens de regels horen zulke niet gebruikte bits dan altijd een vaste waarde (allemaal nul, of allemaal een) te hebben, maar niet zwevend zoals nu gebeurd is. Castle had toen twee mogelijkheden: uitkijken naar een andere chipset en daarmee het project met zeker zes maanden vertragen, of een PCI USB kaart installeren. Ook heel erg mooi vond ik het programma !USB van Paul Reuvers wat perfect alle verbindingen van de USB hosts en clients laat zien. Zelfs het hot pluggable inprikken van b.v. een USB naar parallelle printer-interface kabel is dan direct in schema vorm te zien. Zie ook het bijgaande plaatje.

Je ziet dan bij de printerkabel dat je kunt kiezen uit uni-directioneel en bidirectioneel. Printen met die kabel gaat overigens uitstekend. Het enige wat men goed moet weten is hoe men de systeemapplicatie !Printers goed moet instellen. Men moet gewoon naar een bestand printen. Ik kan de exacte naam nu niet meer nakijken daar de machine elders vertoeft op het moment dat ik dit intyp. Nieuwe ronde, nieuwe kansen zullen we maar zeggen ;-). Zelfs remote (= op afstand) printen via het utp ethernetwerk gaat perfect. D.w.z. op de Iyonix een printopdracht uitvoeren naar een gesharede printer op een andere machine zoals een Risc PC. Andersom vanaf een Risc PC een printopdracht uitvoeren naar een op de Iyonix gesharede USB printer werkt ook prima. Zo zou men dus met Impression Publischer op de Risc PC toch z'n bestanden naar een (USB) printer die aan de Iyonix hangt kunnen afdrukken ;-).

Simon Voortman heeft het uitstekende idee gelanceerd en ingevoerd om een updates logbestand bij te gaan houden met wat er geupgrade is en wie wat gedaan heeft. Uiteraard heb ik met veel plezier hier ook een bijdrage aan geleverd. Zie het bijgevoegde textbestand: Updates. Hieruit blijkt dat een nieuwe machine nog erg veel systeem onderhoud vraagt.

Toen de Iyonix PC voor de 1e maal in Amersfoort was (op zaterdag 15 februari 2003) heb ik de meest recente Big Ben Club software toegevoegd. De door Simon Voortman reeds vastgestelde bug dat je geen ramdisk kunt aanmaken via de Configure optie heb ik intussen ook weten te traceren. Het komt omdat alle bestanden in de directory: $.!Boot.RO500Hook.Res.Configure.!DiscSetup de Access vlaggen LR/r hebben. Daardoor zijn ze beveiligd tegen overschrijven. Dat moet natuurlijk WR/r zijn, in ieder geval het bestand: $!Boot.RO500Hook.Res.Configure.!DiscSetup.Blank. Toen de Iyonix PC voor de 2e maal in Amersfoort was (op zaterdag 15 maart), heb ik dit hersteld, en het werkte nu inderdaad wel zoals het hoort. Op die datum heb ik ook de recente *Asterisk 21.2 er op gezet.

Hoe meer bestanden ik vergelijk, hoe meer ik tot de conclusie kom dat men bij Castle Ltd. niet de allerlaatste versie van de RISC OS !Boot structuur bestanden en programma's heeft gebruikt die ze zelf in huis hadden, afgezien van de naar 32 bit omgezette versies dan. Immers ook in deze !Discsetup applicatie waren mijn eigen RISC OS 4.03 bestanden van de RISC OS 4 install CD Second Editon recenter (=van 1999) dan die door Castle gebruikt op de Iyonix PC (=1998). En zelfs de nieuwere toolbox modules van 2001 hadden er in 2002 toch ook op gekund? Of zie ik nu iets over het hoofd?

Updates ophalen...
Internet configureren (met de gegevens van mijn eigen provider HCCnet) en daarna inloggen en webbrowsen werkte in een keer! Wat me verder erg opviel was dat de bestandsnamen van alle updates niet zo erg logisch in elkaar steken. Men gebruikte meerdere dateringssystemen door elkaar. Daardoor is het lastig vast te stellen of je alles wel hebt. Op vrijdag 7 februari 2003 heb ik geprobeerd om met de Iyonix PC de meest recente software updates op te halen. Op de site (afgeschermd gedeelte) stond wat er allemaal beschikbaar was. Maar helaas kreeg ik maar 3 van de 4 groepen te zien. Namelijk alleen !Iyonix, disc update en Roms, maar niet de !Boot. Daarvan stond 20030122USB.zip en 20030125Update.zip (printers) reeds op de harddisk. Maar ze waren niet zichtbaar om (alsnog) te downloaden. 20030202Up10.zip uit !Boot kon ik dus ook niet bij, en was ook nog niet op disk aanwezig. M.a.w. die had ik graag willen ophalen. Deze laatste gaat over nieuwe sprites en het beschermen van ROMsprites. Waarom dit niet lukte is me niet duidelijk. Zal waarschijnlijk nog wel even overleg per e-mail met Castle vereisen.

Zoals uit dit verslag blijkt heb ik ook de mogelijkheden om buiten de regio Oost periode de machine op andere regio's te bekijken flink benut. Wat me daarbij opviel is dat er flink veel van internet gedownload wordt, en helaas dan niet wordt bekeken of het al ergens op de machine aanwezig is. Zo bleek dus 48 megabytes updates te zijn opgehaald, wat (mijn) voorgangers en ik een maand eerder ook al gedaan hadden. Juist om dat te voorkomen was het update bestand van Simon Voortman in de rootdirectory bedoeld. Maar nog veel erger is, dat men directorynamen gaat veranderen en/of verhuizen, zonder over de consequenties na te denken. Want dan werken de updates van de fabrikant niet meer. Ook is het update-logbestand dan moeilijker te vinden, met het bekende gevolg. Om deze reden bestaat het voornemen dat begin april 2003 Paul Porcelijn en ik alles nakijken en opschonen en weer goed zetten zoals de fabrikant het wil. Niet dat wij die (fabrieks-)indeling zo leuk vinden, maar we willen immers de update procedures in de toekomst werkend houden. Op een prive-machine liggen de zaken iets anders ;-).

Onze algehele conclusies is: een leuke machine, maar een die toch iets minder waar aan snelheid geeft, dan gezien de technische specificaties verwacht zou mogen worden. Daarnaast bevat hij nog diverse kinderziekten die eerst moeten worden opgelost (systeemsoftware updates b.v.) Zo is het geluidssysteem nog niet af, de podule backplane nog niet beschikbaar, als ook SCSI nog niet klaar. Ook loopt de machine iets vaker vast dan we van RISC OS gewend zijn. Gezien deze status vinden wij bij regio Oost dat de machine in deze versie alleen geschikt is voor doorgewinterde gebruikers die weten wat ze doen, en helaas nog niet voor beginners of voor onbekenden met RISC OS. Ook moeten er nog veel software-pakketten naar 32 bit worden omgezet om met een goede mix van mogelijkheden voor diverse typen van gebruikers geschikt te zijn. Daarnaast kunnen de financiën een flinke drempel zijn. Immers men moet nu b.v. min of meer verplicht tegen betaling z'n oude software upgraden of zelfs op compleet andere pakketten overstappen (!Ovation versus !Impression Publischer b.v.).

Zelf ben ik gematigd positief. Wanneer de kinderziektes eruit zijn en er meer softwaretitels beschikbaar komen om een Iyonix aan te schaffen. Ook kan ik me voorstellen dat velen uitkijken naar de Omega, vooral om te vergelijken. Maar zelf heb ik veel meer behoefte aan een portable RISC OS machine, met minimaal de mogelijkheden van een Risc PC. We wachten intussen af en op naar de 2e testronde... En voor regio Oost begint die morgen, op zaterdag 29 maart. Lekker spannend in het weekend dat de zomertijd in gaat ;-). Wordt vervolgd...

Met een vriendelijke groet van Henri Derksen, hardwaretester regio Oost.