WIFI op de Acorn System 5 (2)

In de vorige *Asterisk kon je lezen dat ik een manier gevonden had om mijn bestanden makkelijk naar Bas te sturen zodat hij de software kan testen. De overdracht van de bestanden werkt op zich goed, maar de software zelf was niet aan de praat te krijgen. Dan zit er maar één ding op: in de auto stappen en naar Made rijden. En zo geschiedde op een zonnige zaterdag in augustus...

Gewapend met een scoop en ICE-T65 (een In-Circuit Emulator voor de 6502 processor) gingen we aan de slag. Al snel bleek dat toch de AB-Connector net in de verkeerde rijen van de 1 MHz print zat. Onbegrijpelijk want op de ROX had ik dat al gecontroleerd en aangepast. Blijkbaar dus verkeerd want nu bleek echt dat de connector in de verkeerde rijen zit.

De print is zo opgezet dat je de rijen van de AB connector makkelijk kunt omzetten. Dat is vooral handig bij de Atom waar PL6 en PL7 elkaars spiegelbeeld zijn. Door een extra rij op de print te zetten los je dat probleem op. Wij moesten dat probleem dus wel nog even fysiek oplossen en de makkelijkste manier was om de connector er af te knippen en dan de gaatjes een voor een open te maken. Dit klusje was gelukkig relatief snel geklaard. Nieuwe connector er op en wederom testen. Op de print blijkt nog een klein foutje te zitten en dat is dat de labels nPGFC en nPGFD verkeerd om staan. Als de jumpers eenmaal goed staan, dan maakt dat verder niets uit.

Na het wisselen van de connector werd de interface print weer op de computer aangesloten. Deze hing zich echter op. Nu had ik op mijn Atom al ervaren dat de afsluitweerstanden op de BeebWiFi print meer goed dan kwaad doen dus deze haalde ik in eerste instantie ook hier van de databus af. Dit leverde geen verbetering op. Pas na het verwijderen van de weerstanden op de adresbus kwam er weer leven in het systeem. Achteraf gezien best logisch want het CPU board van de System 5 heeft een weerstand-netwerkje van 2k2 op de databus staan. Het parallel schakelen van nog eens een netwerk van 4k7 verlaagt de effectieve weerstand naar ca 1,5kΩ waardoor de datalijnen te zwaar belast worden en de spanning voor het hoge niveau in de gevarenzone komt.

Het *VERSION commando liet van zowel de software als van de ESP8266 firmware de versie informatie zien. Er was communicatie met de ESP module en dat is een goed teken: de hardware wordt gezien en werkt.

Daarna had ik nog enkele kleine issues in de software, maar die waren minimaal, aangezien ik de commando’s al op mijn System 5 emulatie had draaien. Alleen de ChatGPT client wilde niet werken. Het programma start wel op en toont een prompt, maar na het invoeren van een vraag gebeurt er een tijdje niets en dan komt opeens de prompt weer terug. Normaliter betekent dat, dat de host (in dit geval dus ChatGPT) niet (tijdig) reageert. Maar die reactie was er wel, die kon ik met het *PRD commando in de Paged RAM zien staan. Ik bespaar u de details hoe ik de fout opgespoord heb, maar in grote lijnen komt het er op neer dat ik een debug-feature in de software heb gebouwd waarbij ik alle verzonden bytes op de B-poort van de 16C2552 UART op het WiFi kaartje doorstuur naar de A-poort. Die is vrij beschikbaar en met een laptop kan ik dan zien wat er verzonden en ontvangen wordt. Zo heb ik dus monitoring mogelijkheden. Daaruit bleek dat de prompt twee keer naar de ChatGPT API gestuurd werd. Echter, na de eerste keer was het "kanaal" afgesloten waardoor er een "Link is invalid" foutmelding terug komt van de ESP8266. En de software ziet dat niet zo zeer als een fout, maar meer als een teken dat er nog geen data terug ontvangen is. Na de time-out keert deze dan terug naar de prompt.

Nu dit symptoom gezien was, ging ik speuren in de software. Debuggen, zelfs met ICE-T65, van dit soort communicatie is zeer lastig omdat de data in burst verzonden en ontvangen wordt op een snelheid van 115 kb/sec. Tegen de tijd dat ik het eerste ontvangen byte gezien heb, is de rest al verdwenen door een overgelopen buffer. Met zo hier en daar een print commando en een breakpoint heb ik uiteindelijk toch het probleem kunnen vastpinnen op een JSR instructie die eigenlijk JMP had moeten zijn. In het hoofdprogramma staan de volgende instructies:

jsr tcp_connect        \ setup tcp connection to server
jsr tcp_send           \ send the command to the (proxy)server

En het einde van tcp_connect ziet er zo uit:

lda #&08                    \ load driver function number
ldx #((cmdbuf+3) mod 256)   \ load high byte parameter block
ldy #((cmdbuf+3) div 256)   \ load low byte parameter block
jsr wifidriver              \ execute wifi function and return
.tcp_send	\ Send the data
\ Copy POST command to cmd buffer
ldx #0                      \ reset read pointer (postcmd)
ldy #0                      \ reset write pointer (cmdbuf)
sty writelength             \ reset data length

Met basiskennis 6502 assembler weet je al dat na het uitvoeren van de taak in de WiFi driver, het programma verder gaat met .tcp_send. Echter, na het uitvoeren van tcp_send komt het programma weer terug in het hoofdprogramma en doet dan een jsr tcp_send. Dat is dan dus de tweede keer! De JSR instructie in de gele regel moet een JMP instructie zijn. Geheel logisch, maar het is mij een raadsel waarom ik daar op de Atom - waar dezelfde fout in de software zit - geen last van heb.

Na het herstellen van deze fout blijkt de client nu ineens wel goed te werken en kan Bas nu ook op de Acorn System 5 met ChatGPT aan de slag. Er restte echter nog een foutje: het WGET commando werkt niet betrouwbaar. Met het downloaden van software en die vervolgens uitvoeren gaat het eigenlijk altijd fout. Met debuggen en inspecteren blijkt dat:

1. het inlezen van tekstfiles altijd goed gaat
   
2. de data correct door de webserver verzonden wordt
   
3. de data ook correct in de ESP8266 aan komt (gezien met de monitoring op de A-poort, zie boven)
   
4. de data fout in het Paged RAM gezet worden.
   

Nu bleek dat het oversturen van een blok van 256 &FF bytes altijd goed ging, maar een blok van 256 bytes oplopende van &00 - &FF altijd willekeurige fouten vertoonde vanaf &D0. Uiteindelijk bleek de oorzaak te zitten in een te lange flat cable. De data legt een nogal lange weg af van de 16C2552 UART tot aan de processor: via de data bus drivers op de WiFi kaart door een 40cm lange flat cable, gevolgd door een tochtje over een extender board naar de System bus en zo weer door een bus driver richting 6502. Dat was iets te lang. Na het verwijderen van het lange pad was dit probleem ook verholpen.

WiFi werkt nu dus ook op de Acorn System computers, inclusief de ChatGPT client. Eindelijk eens een project afgerond binnen de geplande tijd ;-)

Alle benodigde bestanden en broncodes zijn te vinden in mijn GitHub account, zie: https://github.com/AtomicRoland?tab=repositories

Ik begrijp dat je na het lezen van deze artikelen natuurlijk ook dolgraag zo’n System 5 wil hebben, deze zijn echter nogal schaars. Wellicht dat er hier of daar nog ergens een exemplaar onder een keukentafel of in een zolderhoekje ligt, maar de kans dat je die vindt is erg klein. Daarom ga ik binnenkort eens uitzoeken of ik een kloon wil maken om zelf een System 5+ op te zetten. Uiteraard kan je al bij Chris Oddy (theoddys.com) een set printen bestellen en direct aan de slag gaan met replica’s van de originele printen. Deze printen zijn relatief prijzig maar wel van goede kwaliteit.