Oefenen met logic analyzers

Ik zie al twee drie gemakkelijkere oplossingen in dit draadje....
Rondvragen op het net voor binaries en als dat niet lukt een auto ritje en:

Guido, niet helemaal. Ik heb wat vragen uitstaan maar het ding lijkt aardig zeldzaam te zijn. Daarnaast moet de eigenaar ook nog in staat zijn die roms te copieren en dat te willen.

Ik heb er twee manuals bij. Het oudste heeft het niet over signature analyse, het nieuwere wel. Mijn LA zit qua serienummer tussen beide in.

Mijn LA heeft U2, dat is ROM#6 en dat is volgens de partlist optional. Vandaar dat de zelftest hem niet ziet.

Het autoritje is 200km op 1 dag. Dat red mijn rug niet anders had ik het gelijk gedaan. Zo'n Tek is erg mooi. Vooral nu ik beter begin te snappen wat LA's kunnen. Of beter wat je er mee kunt.

Er is iets belangrijkers dan makkelijk, dit is een hobby projectje met de bedoeling er wat van te leren. Het was alleen niet helemaal de bedoeling dat ik met een LA in een LA ging meten maar het is een leerzaam oefen object. Dus meet ik vrolijk verder ook al weet ik dat de kans op succes heel klein is en de oplossing waarschijnlijk niet ideaal.

Maar ik heb hulp nodig want ik doe wat fout denk ik.
Ik heb rom#6 eruit gehaald en daar een "connector" op waardoor ik de zeroplus of scoop kan aansluiten op de adreslijnen. Na de error melding komt voert hij steeds een loop uit van iets van 80 adressen
Maar ik doe wat fout. Ik verwacht dat de adressen toch enigszins op volgorde zijn. Dus bv 5 min of meer opeenvolgend dan een jump ergens heen, weer een paar bij elkaar in de buurt etc.

Nu gaan ze van hot naar her en er zitten adressen tussen die midden in een opdracht landen. Ik heb op de LA Adreslijn HAB0 tot HAB10 in de zelfde volgorde aan de LA gehangen. Toen een bus daarvan gemaakt en gedecodeerd in hex. Daarna ze allemaal over geschreven en de gedeassembleerde rom files erbij.

Maar ik weet dat er vaak nogal vreemd gewerkt wordt door rare volgorden te gebruiken waarbij de eerste byte de laatste is (LSB en MSB) Leuk bij 16 bits maar ik heb er maar 11 op die eproms, dat deelt wat lastig in 2 dus ik denk dat ik daar al de fout in ga.
Maar hoe weet je nu hoe je die volgorde moet maken ? Ik heb de file opgeslagen dus ik denk dat ik gewoon met de traces kan schuiven.

Ik vond een 8080 programmeer cursus maar die doet alles octaal ipv hexadecimaal. Mijn casio fx880p kan in hex rekenen converteren maar niet octaal. Ben nu met intel's programmers manual bezig en dat is makkelijker (voor mij dan) want dat gaat meer om de hardware relatie.

Heb ik het goed dat rom0 van 0 tot 0800H gaat, rom1 van 0801 tot 1000H etc en dan daarna bv de RAM ic's. Of kan de hardware bouwer ook eerst 3 Roms dan 1 ram en dan weer 2 roms doen ?

En als in Rom0 in de code een jump naar bv rom3 adres 1805H wordt gedaan dan enabled de processor microcode automatisch rom3 en weet dat hij dan naar 0005H moet ?

Leren werken met een LA en zo'n single board 8 bitter bouwen vult elkaar mooi aan (hoewel het bouwen nu door werk stil ligt)

Maar ik weet dat er vaak nogal vreemd gewerkt wordt door rare volgorden te gebruiken waarbij de eerste byte de laatste is (LSB en MSB) Leuk bij 16 bits maar ik heb er maar 11 op die eproms,

Dat speelt hier op hardware niveau geen rol. Als je naar de pinout van mij afbeelding kijkt dan zie je dat de adreslijnen en datalijnen op een vaste plaats zitten. Daar kan niet meer gerommeld worden. Dus hardware matig met aansluiten op de LA is er maar 1 volgorde.

waarbij de eerste byte de laatste is

Dit speelt in de software wel een belangrijke rol vooral bij een 16bit getal. Maar dit moet je in de manual van 8080 kunnen vinden of er in de micro code eerst het hoge byte of het lage byte gebruikt moet worden.

En als in Rom0 in de code een jump naar bv rom3 adres 1805H wordt gedaan dan enabled de processor microcode automatisch rom3 en weet dat hij dan naar 0005H moet ?

Het korte antwoord is NEE. De adres decoder Enabled rom 3 en daar weet de 8080 helemaal niets van.
Als er in de code een jump staat naar 1805H dan word heel simpel het adres achter de jump direct op de adresbus gezet. Het leest daarna de data in op dat adres en voert na het decoderen van deze data de opdracht uit. Die opdracht kan dan weer een jump zijn naar 0005.

Nu gaan ze van hot naar her en er zitten adressen tussen die midden in een opdracht landen.

Maar hoe weet je nu hoe je die volgorde moet maken ? Ik heb de file opgeslagen

Je leest nu enkel de onderste 11 bit van het adres. Dan is mooi om het eerste deel van het programma te monitoren. De bovenste 5 bits gaan naar de adres decoder. Voor het complete adress moet je alle 16 bits hebben.

Ik verwacht dat de adressen toch enigszins op volgorde zijn.

Dat verwacht ik ook. Zonder de exacte assembler taal van 8080 te kennen zijn er voor een jump minimaal 2 leesopdrachten achter elkaar nodig.
De eerste leesopdracht bevat bv de opdracht jump. Maar dat hoort dan nog een adres bij of relatieve verplaatsing. Dat betekendan spring vanaf het adres waar je nu zit xx plaatsen omhoog of omlaag. De waarde van xx staat dan in het 2de byte.
Een voledige jump over de hele adresbus neemt dan minimaal 3 leesopdrachten in beslag. 1ste voor de opdracht en dan 2 en 3 voor het complete adres.
Dus de 8080 kan niet op elke klokpuls op een ander adres zitten.

Kan je niet tussen de 8080 1 of meerdere voeten zetten zodat je wel de mogelijkheid hebt om direct daar te meten. Want als de 8080 echt maar wat heen en weer sprint op rom6 maar niet niet zelf dan gaat het niet goed.

Heb ik het goed dat rom0 van 0 tot 0800H gaat, rom1 van 0801 tot 1000H etc en dan daarna bv de RAM ic's. Of kan de hardware bouwer ook eerst 3 Roms dan 1 ram en dan weer 2 roms doen ?

JA die vrijheid heeft de systeembouwer. Je hooft ook niet de gehel ruimte van het 16 bit adres te gebruiken dat mag ook veel kleiner zijn. HEt aansturen van alle losse ram en rom en eprom chips gebeurt door de adres decoder.
Het is zelfs mogelijk om met maar 16 bit adrs ruimte meer dan 65k byte aan te sturen. Dat werd zo ongeveer gedaan bij de opvolger van 8080 de 80286. Dat was natuurlijk niet de directe opvolger maar wel nog steeds gebaseerd op deze chip.

Je moet inderdaad naar alle 16 lijnen kijken. Dan kan je zien of de code in ROM wordt gelezen, of iets wordt gelezen/geschreven in RAM, of er iets met een IO chip wordt gedaan. Etc. Als je alleen naar 11 lijnen kijkt, dan komt van alles voorbij.

Een adres is pas geldig voor een ROM/RAM/IO IC als de chip select lijn laag gaat. Anders worden adres en data lijnen genegeerd. En de adres decoders zorgen ervoor dat dit gebeurt. De processor heeft geen idee of het 1 grote ROM is of meerdere. Ding zet alleen maar een adres op de adresbus. Idem voor RAM etc.

In dit geval: ROM 0 gaat t/m 7FFF, ROM 1 t/m 0FFF. Tellen begint bij 0. De memory map kan idd worden ingedeeld naar believen. Maar aan de hand van de adres decoder (138) kan je zien dat 0000 t/m 2FFF allemaal ROM is. Had ik al eerder gepost.

Een voorbeeld van zo'n memory map: https://en.wikipedia.org/wiki/Acorn_Atom. ROM zit daar op een andere plek, vanaf A000. Dat lijkt wellicht wat raar, maar de reset is wat ingewikkelder. Programma begint niet vanaf 0000, maar vanaf een adres wat de processor weer inleest vanaf FFFE en FFFF. Dat is dan weer een adres in ROM. Vandaar dat de ROM ´bovenin´ zit.

Op 2 november 2017 21:23:38 schreef benleentje:Het is zelfs mogelijk om met maar 16 bit adrs ruimte meer dan 65k byte aan te sturen. Dat werd zo ongeveer gedaan bij de opvolger van 8080 de 80286. Dat was natuurlijk niet de directe opvolger maar wel nog steeds gebaseerd op deze chip.

Dat kan ook met zo'n antieke processor dmv bank switching. Doen we met de Atom ook. Schakelkaart met meerdere ROMs en RAMs op A000. Branquart schakelsoftware anyone? @Fred, snel vergeten. Hier niet van toepassing bij de ROMs.

Op 2 november 2017 20:59:00 schreef fred101:
[...]
Na de error melding komt voert hij steeds een loop uit van iets van 80 adressen

Een loop van 80 adressen. Lijkt erop dat er inderdaad wat code is om te kijken of er moet worden doorgegaan (toetsen, jumper, whatever).

Of het is een watchdog/ISR routine. Kijk eens of je iets ziet van pulsjes op de INT lijn (14) als de processor in de loop zit.

[Bericht gewijzigd door guidob op vrijdag 3 november 2017 00:37:29 (12%)

Dat kan ook met zo'n antieke processor dmv bank switching. Doen we met de Atom ook. Schakelkaart met meerdere ROMs en RAMs op A000. Branquart schakelsoftware anyone? @Fred, snel vergeten. Hier niet van toepassing bij de ROMs.

Klopt, dat kan niet want de HP heeft geen shift return toetsen

Ik heb het schema erbij gepakt. Het kwartje begint te vallen. Samengevat:
De processor zet 16 bits op de bus. 11 worden voor de roms gebruikt. De overige bits worden gebruikt om rom of ram te selecteren. Ik moest even omschakelen naar wat er nu echt gebeurd. Een bit zetten is niets meer dan een spanning op een gate. Het zal de processor worst wezen wat er aan hangt, dat kan een enable lijn van geheugen zijn of een ledje, of een mosfet die een motor aanzet.
De hardware ontwerper bedenkt iets en geeft de programmeur een geheugen map waardoor deze weet welke adressen voor ROM en RAM gebruikt mogen worden. De hardware decodering zorgt er dan voor dat het IC bij dat behorende adres geactiveerd wordt en de 11 bits kan uitlezen.

Maar nu hangt ik mijn LA aan 16 adres lijnen hoe decodeer ik die 16 bits nu ? De LA geeft de hexcode van 16 bits maar de waarde (het adres wat de programmeur gebruikt) wordt bepaald door de volgorde daarvan. Laat ik hem van boven naar beneden decoderen bv 01100101 of van beneden naar boven dus 10100110 of dmv LSB en MSB dus 0101 en 0110 of 0110 en 0101 (even 8 bits voor het idee)

Kan je niet tussen de 8080 1 of meerdere voeten zetten zodat je wel de mogelijkheid hebt om direct daar te meten. Want als de 8080 echt maar wat heen en weer sprint op rom6 maar niet niet zelf dan gaat het niet goed.

Ik heb rom6 eruit gehaald omdat deze optioneel is en de zelftest niet beinvloed. Zo kon ik makkelijk alle rom adresbus lijnen proben zonder solderen

De hoeveelheid adreslijnen hangt af van de grootte van het geheugen IC. Als je ipv twee maal een 2716 één 2732 gebruikt, dan moet je de dubbele hoeveelheid geheugen kunnen adresseren. Dus een adreslijn erbij. Vergelijk maar de datasheets. De RAM ICs zullen wel kleiner zijn als 2k. Dus minder adreslijnen per chip. En meer adreslijnen naar de adres decoder logica.

Het kan ook voorkomen dat ICs dubbel in het geheugen zitten. Als je bij een embedded bordje toch zeker weet dat je niet meer RAM/ROM nodig hebt, dan kan je daardoor de adresdecoder logica simpel houden. Zo ook voor I/O, waarbij je anders een paar addressen helemaal moet uitdecoderen.

tellen gaat van LSB naar MSB, van A0 naar A16. Processor begint bij adres 0000, dan 0001 (A0=1) enz. Kijk maar eens op je LA bij een reset van de machine.

Of het is een watchdog/ISR routine. Kijk eens of je iets ziet van pulsjes op de INT lijn (14) als de processor in de loop zit.

Heeft dat zin ? Pin 14 van de processor hangt permanent aan gnd (volgens schema)

Ik ben weer verder. Ik heb de lijn volgorde omgedraaid en toen zag ik de adressen mooi oplopen. Daarbij werd steeds de zelfde loop van 11 commandos doorlopen.

008D   mov a,b      zet inhoud b in a
       add m        tel de data in adres HL bij a op
       mov b,a      zet de nieuwe inhoud van a terug in b
       inx h        h = h+1 dus het adres in HL wordt +1
       mov a,h      h gaat naar a
       rlc          rotate a left 
       rrc          rotate a right
       rrc          dit zet a weer terug maar nu met omgekeerd sign
       add c        a=a+c
       cpi 07H      a=a-07H als dat 0 is wordt zero bit hoog gezet
       jnz 00H 8DH  begin opnieuw als de zerobit niet hoog gezet is

Volgens mij doet dit niets anders als ergens een getal vandaan halen en kijken of dat getal 07H is, zoniet dan begint het opnieuw.

Wat de inhoud moet zijn weet ik niet maar als ik die jump bij zero opdracht vervang door 3 x nop dan slaat hij deze test over? (hoop ik)

Een checksum betekend letterlijk vertaald controleer de som.
Er kan dan bv alle even bits die 1 zijn optellen of zomaar een paar data punten uit de rom enz.

De bedoeling van chechsum is om te controleren of de inhoud van de rom nog goed en betrouwbaar is. Hij lijkt dus te hangen op de checksum zelf omdat die niet de juiste waarde opleverd.

Je kan daar inderdaad 3x NOP plaatsen en dan gaat het gewoon verder met het volgende deel en de rest van het programma.
Nu maar hopen dat het programma voor de rest normaal werkt want anders word je Logicanalyser ineens een netwerk analyser .

Een checksum betekend letterlijk vertaald controleer de som.

Een checksum van een EPROM/ROM wordt toch gedaan door alle data met elkaar te X-OR-EN ?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka911…

Dat kan er zijn heel veel mogelijkheden voor een checksum.

Resultaat van de mod, error in rom #1, 2, 3, 4, 5, 6

Weer de LA erop om te kijken dat werkt best goed. Ik zie nu wel het voordeel van zo'n ding voor programmeurs (in ieder geval destijds)

Daarna weer een jump aangepast, dat gaf knipperende onzin. Toen heel drastisch hem naar het laatste adres van rom 0 laten springen vanaf adres 0005.

Ik heb het idee dat Rom 0 alleen maar de zelftest is. Er zitten heel veel korte routines in die op het eind een conditionele jump hebben en dan blijven loopen of naar de volgende doorgaan.

Daarna kreeg ik een hoop geknipper en onzin karakters, maar daar zaten wel normale traces tussen.

Ik denk dat ik het zo mbv een LA het uiteindelijk wel goed zou kunnen krijgen. Want zo kan ik waarschijnlijk ook de werkelijke fout vinden. Lijkt me ook leuk om te proberen. Ik hou van puzzelen, maar niet met eproms. Dat gewis steeds is erg tijdrovend.

Kan ik er zo 1 op 1 een of ander eeprom in zetten ? Zo ja welke ?

Een andere, waarschijnlijk makkelijkere manier zou een 8080 emulator zijn. Ze zijn er tegenwoordig voor ZX81, C64's, oude apples etc. Maar dat zijn computer sims, geen processor sims.

Nogmaals, dit is doe ik om wat te leren en omdat ik het leuk vind. (en ook omdat ik het een mooi apparaat vind. Alleen al de kabeltjes, pods en klemmetjes. De kwaliteit spettert er van af.

Je hebt ook eprom emulators of hoe dat ook mogen heten. Die zet je in plaats van je rom. In de emulator zit gewoon normaal ram geheugen die je dan zelf makkelijk steeds kan herprogrammeren.

Je hebt ook nog de 29xx family dat is eeprom maar ik kan je niet vertellen hoe dat werkt of dat ook kan. Die 29xx moet je dan ook nog steeds uit het voetje halen en apart programmeren.

Inderdaad, EPROM emulators. Ik heb nog een elektuur exemplaar hier liggen. Maar ik denk dat die niet geschikt is voor 2716s. Net als gangbare EEPROMs. Is een boardje met RAM en een parallele poort om het ding te kunnen vullen. Ook één van mijn Arium logic analysers heeft zoiets, maar ik heb daar de pod niet voor.

Dan zal je toch wat meer moeten hacken (zes ROMs vervangen door 1 emulator of EEPROM bijvoorbeeld).

Hardware emulator voor een aantal processors is idd al een paar keer hier langs gekomen. Maar die kan geen 8080 aan. Denk niet dat je die snel gaat vinden. Het zou trouwens goed kunnen dat ze meer dan de processor in zo'n emulator hebben gepropt. b.v. ook het ROM geheugen, zodat je dat ook kan emuleren, dus snel kan wijzigen. Als je goed met FPGAs overweg kan, dan zou je dat boardje zelf kunnen omhacken naar een 8080 emulatie

Ik denk dat er ook hardware initialisatie in ROM0 zit. En die sla je nu over...

INT lijn aan massa, dus geen interupt service routine.

Ik heb ondertussen twee manieren om te oefenen. Na niet te missen hints van Guido toch maar in de auto gestapt en nu ben ik de trotse bezitter van een heel mooie complete Tek 1241 met een Tek "reistas" vol accessoires en boeken.
Het mooie is dat er twee workboeken met uitgewerkte meetvoorbeelden bijzitten welke de daarvoor aanwezige interne patroon generator gebruikt. Een bizarre hoeveelheid kanalen en verrassend gebruiksvriendelijk.
Enige wat nog wat TLC nodig heeft is het keyboard, de triggerknop blijft regelmatig hangen, die moet ik dan even een beetje opzij duwen.

Het tweede is een een oefenbord. Ik heb heel lang geleden een easypic 3 gekocht van een COer. Ik kon er echter niks mee doen bij gebrek aan kennis. Deze zag ik van de week weer liggen. Ik heb er 1 pic 16F84A bij. Vanmiddag de software van de CD geinstalleerd op een oude laptop met XP. Tot mijn verrassing ging de installatie soepel. Ik probeerde toen basic maar nu koos ik C.

Dat ding is net een mega-grote Arduino. 2x16 Display (ik mis alleen de grafische), tempsensor, adc, 4 digit 7 segment led display, bergen schakelaars en leds, USB, rs232, PS2 aansluitingen en headers voor elke pin zodat ik er zo een LA aan kan hangen. En geen gedoe met bootloaders. Er kunnen diverse maten Pics op. De IDE werkt net zo makkelijk als een Arduino. Build compileert de boel en het branden gaat ook met 1 druk op de knop.

Heb nu een soort loopkrant gemaakt die het alfabet langs laat komen zodat ik met de LA kan zien of ik alles goed doe.