SYSTEM 5+ BBC MODE


Mijn System 5 heeft een plusteken achter de naam staan omdat er een extra mode op de CPU kaart zit. Door in de CPLD een bitje om te zetten, verandert wordt de geheugenindeling die de indeling van de BBC computer benadert. Dat wil zeggen:



De belangrijkste verschillen zitten dus in de plaats van het video-geheugen en de I/O ruimte is groter dan in de oorspronkelijke Beeb. Echter, uit de MOS ROM kan een heleboel code geschrapt worden omdat in dit systeem alleen maar mode 7 beschikbaar is. Dus vrijwel alle grafische routines kunnen vervallen. En dat komt mooi uit, aangezien er een paar kB minder beschikbaar is.


Ontwikkelomgeving

De broncode van de MOS ROM is inclusief wat beperkt commentaar beschikbaar op mdfs.net. Deze kan geassembleerd worden met beebasm. Dat maakt het aanpassen al makkelijker. Aangezien de MOS ROM in RAM geladen kan worden hoef ik dus niet voor elke aanpassing een nieuwe ROM te programmeren. Aangezien ik al een WiFi kaart in mijn System 5 heb zitten kan ik dus vrij eenvoudig een bestand downloaden vanaf mijn ontwikkel laptop en dan kopiëren naar de RAM. Dus geen gedoe moet fysiek wisselen van floppen of andere datadragers. Dat voorkomt een hoop mechanische slijtage. Maar dan, hoe ga ik dat debuggen? De meest voor de hand liggende manier is natuurlijk via mijn ICE-T65 (Godil) maar daar kleven twee nadelen aan:


  1. Je moet telkens op de juiste adressen een breakpoint instellen als je niet elke routine stap voor stap wil doorlopen.

  2. De data-overdracht voor WiFi is onbetrouwbaar als ik de Godil gebruik; dit komt doordat ik dan een extender print moet gebruiken en dat levert corrupte data op.


Om toch efficiënt te kunnen debuggen heb ik een aantal assembler routines geschreven die ik op een aantal plaatsen in de broncode kan oproepen, zoals:



Maar dat werkt natuurlijk niet als de schrijfroutine voor MODE 7 nog niet werkt. Ook hier komt de WiFi kaart weer van pas. Er is namelijk een extra seriële poort beschikbaar en die gebruik ik om de debug-informatie naar buiten te sturen. Met een terminalprogramma op mijn laptop kan ik dan de uitgestuurde debug-informatie uitlezen en zo weet ik precies tot waar de processor komt tijdens het booten van het systeem in BBC mode.


WiFi kaart niet gezien in BBC mode

Tot zo ver dan de theorie. De praktijk bleek weer wat weerbarstiger. Om te beginnen zag ik alleen de debug-berichten terwijl de computer nog in System-mode stond. Direct na het omschakelen viel de communicatie stil. Na diep nadenken kwam ik er achter dat ik natuurlijk wel even de basisadressen van de UART moet aanpassen. Deze staat in de BBC memory map op adres &FC30 en niet meer op &0B30. Maar ook na die aanpassing werkte het nog niet. Met een hexdump programma zag ik zelfs helemaal geen I/O op &0B30 en ook de paged RAM op &FD00 was niet zichtbaar.


Na een nachtje slapen schoot me te binnen dat de 1 MHz bus print eigenlijk gemaakt is voor de Atom, en dat die min of meer toevallig ook werkt in de System 5. Deze print zorgt er voor dat er twee beschikbare pagina’s in de I/O ruimte naar de BeebWiFi kaart worden doorgegeven onder de namen nPGFC en nPGFD. De BeebWiFi weet dus niet in welke pagina hij aangesproken wordt en dat is verder ook niet van belang. Wat wel van belang is, is dat deze pagina’s verschillen in System- en BBC mode. En daar is de 1 MHz bus print niet voor gebouwd. Die heeft door middel van een GAL en wat jumpers een vaste adresbereik.


De oplossing is gelukkig vrij simpel te realiseren: op de System-bus (en ook in de Atom) is een selectie-signaal aanwezig dat actief laag wordt als de I/O ruimte aangesproken wordt. Dit signaal heet BLK0 en wordt actief als de adreslijnen A12 t/m A15 allen ‘0’ zijn. Op mijn CPU kaart heb ik rekening gehouden met de BBC mode en wordt dit signaal in BBC mode actief in het adresbereik &F400 – &FEFF. Maar dan moet de aangesloten hardware natuurlijk wel gebruik maken van die I/O selectie-lijn. De VDU en FDC kaarten doen dat ook keurig. Die zie ik ook terug in de memory map, maar de 1 MHz b
us print doet dat niet (die selecteert op basis van de genoemde adreslijnen) en daar is dus een aanpassing voor nodig. Gelukkig is deze aanpassing vrij eenvoudig zoals je in onderstaande foto kunt zien:


Op de print zit een EPROM socket die bij een Atom gebruikt kan worden om een EPROM op adres #E000 te plaatsen. Deze socket wordt hier niet gebruikt dus kan ik het Chip Enable lijntje gebruiken om het BLK0 signaal naar de GAL te leiden. De GAL hoeft dan alleen maar aangepast te worden dat deze pin geen uitgang is, maar een ingang. En verder moeten de selectie-signalen dan afgeleid worden op basis van BLK0. Dankzij de GAL kan dat allemaal zonder extra solderen en krassen. Heerlijk, die programmeerbare hardware.


Met deze aanpassing werkt de BeebWiFi kaart ook in BBC-mode. Nu kan het echte werk beginnen.



En daarmee heb ik dus nu wat ik wil; ik kan informatie tonen over de status in het systeem nog voordat de video-routines werken. Op dit moment ben ik zover dat de sideways ROMs geïnventariseerd worden en het videogeheugen wordt gewist. Het printen van de start-up banner werkt nog niet; de OSWRCH vector is dus de eerstvolgende die onder de loep genomen gaat worden.


Toetsenbord

Los van de BBC mode implementatie ben ik ook nog bezig geweest met het toetsenbord. Zoals eerder beschreven gebruik ik een Atom als toetsenbord. De software die ik daarvoor geschreven heb is sterk afgeleid van de Atom toetsenbord-routines. Op zich geen slechte gedachte omdat het immers op een Atom draait. Maar in de praktijk werkt dat niet soepel. Het intypen van karakters moet niet al te snel gebeuren want dan mist de computer regelmatig toetsaanslagen. Ook de MPAGD implementatie waar Kees van Oss aan werkt, heeft moeite met dit toetsenbord.


Tijdens de regiobijeenkomst van regio Oost in februari had ik Bas gevraagd om zijn System 5 toetsenbord en een scoop mee te nemen, zodat ik eens kan meten hoe de “echte” signalen er uit zien. Dit leverde al snel een ander beeld op. Als op het System 5 toetsenbord een toets ingedrukt wordt dan verschijnt de ASCII waarde van die toets op de uitgang, waarbij bit 7 laag gemaakt wordt als teken dat er een toets is ingedrukt. Als die toets na 500ms nog steeds ingedrukt is dan treedt de auto-repeat in werking. De toets wordt dan met een frequentie van 10 Hz herhaald; met andere woorden, het strobe bit wordt 50 ms laag en dan weer 50ms hoog waardoor het voor de computer lijkt alsof de toets losgelaten en weer ingedrukt wordt. Automatische herhaling dus. Deze manier van werken heb ik in een vernieuwde versie van mijn toetsenbordroutines op die Atom ook toegepast en nu werkt het toetsenbord veel prettiger. Voor de liefhebbers staat de broncode op https://github.com/AtomicRoland/AtomSys5Keyboard.


Dat gecombineerd met een automatische start van het toetsenbord, gewoon door het programma onder de naam ‘MENU’ weg te schrijven op de SD-kaart en de autostart optie aan te zetten, maakt de Atom een prima alternatief voor het niet verkrijgbare System toetsenbord.


Tot zover weer deze aflevering van mijn System-5. Hopelijk kan ik in de volgende aflevering meer vertellen over de vorderingen van de BBC MOS in de System-5.