PROMEL 6064 - EPROM Emulator

[ELTompa]

PROMEL 6064 - EPROM Emulator
Efter ha provkört min gamla och egenutvecklade CRED 6809 utvecklingsplattform från sent 80-tal så triggas lust att kanske göra ett bygge i dess anda. Men ska man få fart på nått sånt så skulle en EPROM emulator vara till god hjälp. Jag vet att jag hade en Dataman S3 på den tiden som både kunde bränna och emulera EPROMar. Vore kanske bättre att bara köpa någon rustik sak på Tradera som kan detta el motsvarande. Har sett att efterföljaren Dataman S4 ibland dyker upp.

Eller så bygger man själv en mojj bara för att det är ett kul projekt helt enkelt
Det låter som ett ganska kul projekt och det viktigaste är kanske inte att kunna bränna EPROMar utan att kunna emulera dom. Det var det som var grejen med S3an så jag fokuserar mina tankar på den funktionen.

Går det att få tag i viktiga delar?
Måste kolla först att det går att få tag i viktiga delar så att projektet kommer bli som jag föreställer mig.

• Det ska ju vara en sån där kabel med klämd DIP28 kontakt som kan kontaktera där EPROMet normalt sitter. AliX = CHECK!
• Det behöver finnas en ZIF 28p så att man kan läsa av befintliga EPROM. Eget Lager = CHECK!
• Kretskortkontakt så man kan skilja emulatorn från kabeln och byta den vid behov. Electrokit CHECK!

Det verkar också finnas gamla EEPROMar som skulle kunna passa måldatorn som ett alternativ till att bränna EPROM. Även en del FLASHPROMar man kan fixa med adapters så visst går det att hitta den Flinta-teknik som behövs för projekt som är i behov av en EPROM emulator.
Tänker mig ett koncept baserat på en PIC MCU. Tycker dom är roliga att jobba med och jag tycker jag kan Midrange 8-bitarsmodellerna ganska bra. Varför inte förnya sig och ta en ny modernare variant.
Mojjen ska köra RS232 till datorn och behöver kunna ta emot och sända Motorola S1 HEXfiler. Mina gamla 6809 projekt brukade köra XON-XOFF så det skulle man ju kunna knöa in i PICen.
Ja å sen kanske man ska göra den 3v3 kompatibel ifall det skulle komma lite modernare alternativ än HMOS från 70-talet

Funderar också lite på den mekaniska utformningen, kanske en 3Dprintad låda typ nått sånt här



Jag ritar på ett schema utifrån detta. Det blir ju en hel del grejjor.



Jag brukar ju bygga en prototyp först men denna är för trasslig att tråda upp på verokort så jag ritar ett mönsterkort istället och beställer.

Noll kända fel
Brukar vi säga när en kortbeställning lagts. Känns alltid bra!


.

[ELTompa]

Mönsterkort hemma på rekordtid - Tack JLCPCB
Då ere bara att börja bygga. Jag funderar en stund, detta är ju ett prototypkort. Så det är nog bästa att bygga del för del och prova på resans gång att allt är som det ska.
jag börjar med att bygga DC-DC 5V kretsen. Den fungerar direkt som den ska. Bygger därefter på med 3v3 LDOn och den funkar också fint



Riggar för att göra belastningsprov. Jag vet inte riktigt hur mycket grejjorna kommer att dra. 5V DCDCn är tänkt att Max ge 1A men så mycket tror jag inte kommer behövas.
Huvuddelen av elektroniken kommer gå på 5V. Det enda som kan komma köras på 3V är utgångsbufferten, den som låtsas vara EPROMet. Men som standard går den ju också 5V.



Jag belastar 5V med 0.8A och 3V3 med 0.15A. Kollar med värmekameran och temperaturerna överstiger inte 70C, det känns bra



Inget nämnvärt rippel eller annat på utgångarna.



Denna del funkar fint!

[ELTompa]

Nästa steg, att få fart på MCUn
Till detta projekt väljer jag en modernare Midrange PIC än dom jag jobbat med förut. Varför... Ja mest på kul och för att lära sig mer och nytt men ändå en som är relativt lik. Det är ju det som är så härligt med den här hobbyn, det kommer nya komponenter man kan prova. Valet blir en PIC16F19176.



Jag passar på att uppgradera mitt PICkit till nr5



En grej som jag aldrig blir riktigt överens om med MPLAB X IDE/IPE är det här med valet att strömförsörja target från PICKIT-lådan. jag vill strömförsörja mina kopplingar från egen nätdel. Man vet aldrig va som kan hända med sånt man byggt själv och jag vill inte bränna PICKIT-lådan. Fine, det finns en inställning för det så den aktiverar man ju. Men då serru får man felmeddelandet att Target inte är stömsatt och då tänker inte MPLAB fortsätta ladda kod och köra program. För någon utvecklare på MPLAB har bestämt att det ska minsann kollas att det finns VDD och vill därför att jag kör in min strömförsörjning i PICKIT-lådan, vilket jag inte vill.



Så lösningen får alltid bli att ställa in MPLAB på att strömförsörja från PICKIT-lådan men jag klipper av VDD sladden så ingen ström kan flyta den vägen. Det hela känns helt bakvänt men så får det vara för då går det mycket riktigt att ladda kod och köra debuggern utan felmeddelande.



Men vad har dom gjort med Assemblern?
Jo från version 6 eller så har stödet för MPASM upphört och nu måste man koda enligt XC8 asm. OK det blir till att lära nytt. All gammal kod måste skrivas om en hel del för att funka. Framtiden får utvisa hur bra det känns. Just nu bara ovant. Det tar typ 3timmar att få den enklaste kod i världen att 1. Assemblera. 2. Exekvera korrekt.
Men skam den som ger sig och nu har jag en fullt fungerande MPU med utvecklingsmiljö som tillåter att jag skriver och laddar kod som funkar även om den första koden är så banal att den bara genererar en fyrkantvåg ut.

Så nu funkar även detta steg av PROMEL-prototypen


.

[hcb]

Detta är lika snyggt och väldokumenterat som vanligt. 9/5 klippta VDD-sladdar i betyg

[ELTompa]

Få fart på UARTen
Då är det dags för att testa RS232 drivkretsen. Den bjuder inget motstånd utan levererar +-9VDC när den får +5V att köra på.

PICen bjuder på mer motstånd. Ja eller det är ju jag som inte lärt mig varken XC8 asm eller den nya MCUn ännu. Det tar lite tid att förstå det här med PSECT och hur dessa ska användas. Men det bli mycket enklare när jag fått igång generering av .lst fil så man kan prova och se var saker allokeras i minnet. Det här med relocaterbar kod är jag helt för men i dessa små PICar där jag ändå inte tänkt annat än att ladda på en fast kod så känns det något överambitiöst.



PROS/CONS med nya MCUn och XC8asm
+ Inget bankat programminne
+ 32MHz klocka utan PLL. Det har ioförsig inte varit ett problem förutom att man måste vänta lite på PLLen att svänga in. Sån kod behövs inte längre.
- Innan Periferals kommer ut så måste man sätta upp pinassigment via kod. Jag trodde ett tag att de fanns en "default" som gällde med för UARTen så kom det inte ut någon TX förens jag mappat upp en portpinne. Detta är kanske inte något dåligt tekniskt utan mer en otydlig dokumentation. Jag upplever generellt att databladet ger utrymme för tolkningar i högre grad än för äldre MCUer. Eller så är det bara jag som läser dåligt
- XC8asm stödjer inte att infoga strängar som constanter i programminnet utan man måste dela upp dom i en radda bytes alá 'M','y',' ','s','t','r','i','n','g',0 Det här är ju en rejäl försämring gentemot MPASM

Men tillslut så får jag igång UARTen. Då ser jag att jag glömt vända på RS232 TX/RX. Trots att jag ritat dom korsat på schemat för att fixa till de så missade jag det.
Men nu så rapporterar PICen som den ska till Terminalen

[ELTompa]

Det saknade stödet för att deklarera const strings stör mig
Alltså det här att det inte i XC8asm går att deklarera strängar som konstanter i programminnet retade jag mig på igår. Kanske jag har missat läsa på något men jag orkar inte leta mer i frågan. Den här applikationen kan behöva ett gäng strängar/texter för att prata via RS232 så jag kan inte hålla på att skriva kommaseparerade bytes inom fnuttar. Jag kommer bli galen på det!!

så jag skrev en preprocessor nu på förmiddagen som gör jobbet
Jag älskar Delphi. Snabbt å enkelt att skriva fullfjädrade windowsprogram i utan massa svåra frågor. Pascal är ju från början designat för att parsa strängar så det är som gjort för just att skriva denna preprocessor i. Å sen har jag ju miljön installera, bara att börja koda Programmet tar en infil som parameter och som innehåller strängarna i ett enkelt format. Filen editerar man i IDEn. Hmm, editorn verkar vilja rättstava min nya fil. Kanske skulle döpt den till nått annat än .txt



Preprocessorn startar man i byggkjedjan. Då körs den nu innan man bygger.



Preprocessorn läser textfilen, spjälkar strängen till en kommaseparerad text med varje char inom fnuttar och lägger på en Noll-terminator.



I koden lägger man in en include som tar in resultatfilen i koden.



Efter bygget ser man resultatet i .lst filen



och laddar jag på koden på Target så skriver den snällt ut min sträng. Inkl "ö". Den är bara tänkt att skriva ut std ASCII så man ska nog hålla sig till det.



Funkade ju såå bra! Nu behöver jag inte störa mig på detta mer.

Edit
Blev ju helt klart bättre ge strängfilen efternamnet .inc så blev den färgkodad bra och ingen påtvingad engelsk rättstavning


.

[ELTompa]

En första kommandotolk
Jag tänkte återanvända kommandotolken från min rörförstärkare EL384SEUL men denna implementation ska få en rundbuffer för inkommande tecken för jag tror det hjälper när det ska laddas Srecords/Interlhex filer senare.
Bufferten har två pekare som "jagar" varandra. En pekar på nästa fria adress att skriva inkommet tecken till medans den andra talar om var det finns obehandlade tecken. Ctrl-C, Xon och Xoff läggs inte i bufferten utan hanteras som flaggor. Övriga tecken hamnar i bufferten och kan alltså bearbetas av opertivsystemet eller kommandoprocesser.



I Viloläge läser OSet av inbufferten och bygger upp en kommandorad. Kommandoraden får bara vaniljfunktioner som BackSpace och Enter tills vidare. Det räcker lång för att skriva kommando tycker jag. Bufferten är tilltagen för den kan komma att användas på flera sätt i vissa kommandoprocesser. Framtiden får utvisa hur det kommer te sig.

och om man skriver ett okänt kommand
så svara kommandotolken med "What?"



Och man måste vänta lite på hårdvaran
Det uppstod konstigheter när jag startar PROMEL. Ibland skriver den bara "POMEL" och glömmer "R":et. Lite klurigt fel men det berodde ju på att RS232 spänningsdubblar/neg funktionen inte riktigt fått upp farten/spänningen innan jag började skicka tecken. Med ett delay på sisådär 1ms så fungerade allt ok. Tog en stund innan jag fattade vad som pågick

Och den här nya assemblern då
Jag kommer bättre och bättre överens med den nya assemblern. Tycker den gör jobbet bra men den känns ändå lite ofärdig. Det finns en del direktiv som är i princip värdelösa, text DLABS, ett direktiv som allokerar Linjärt minne på valbar plats. Syntaxen säger:
"DLABS memorySpace, address, bytes [,symbol]"
Ganska användbart om det inte var för två saker. fältet memorySpace kan inte utgöras av EQU deklarerat tal, inte ens en #define funkar utan skall skrivas numeriskt på plats i direktivet. OK men då kan man använda optionen "symbol" för att skapa en adress till det allokerade minnet. Ja, den listas om en adress men det går inte använda adressen i koden att referera till så den fungerar inte som en label. Det här direktivet kanske funkar för C-compilern men ska man skriva ren assembler är den oanvändbar. Linjärt minne får man deklarera på klassiskt sätt med EQU.
Men jag vill inte klaga, bara konstatera att denna assembler känns lite ofärdig
.

[nifelheim]

Satte du PWRT till 1ms eller fuskade du

Tack för att du dokumenterar och delar med dig så snyggt.
Stort nöje att läsa.

[ELTompa]

Jag fuskade, jag har inte lär mig finnesserna i denna MCU ännu. Hade redan Timer1 uppsatt till 1us så låter den räkna till 1000.

[ELTompa]

Adresserbara LEDar
De styrbara LEDarna sitter på en 8-bits latch alá 573a och var tänkt att adresseras och få sin data via den lokala databussen. Bankadressvalet ska skötas av en adressmultiplexer alá 138a. Det visar ju sig inte bra alls. Av lite programtekniska skäl behöver jag kunna få 138an kunna ställas med alla höga(=oadresserade) så en extra CS behövs vilket dras från RE2. Men sen är det ju så att 573ornas LE (CS) är ju faktiskt aktivt höga. Det hade jag inte tänkt på så det fick bli en patch till en ledig IOpinne = RA0.
Då funkar allt som det ska att lägga ut en data på databussen och latcha in den till LEDarna.



Här med tänd LED som visar att systemet håller på att Boota.



Men det är ju 2st till 573or som måste fixas. Att sätta inverterare till dessa är ju en lösning men det leder ju till flera kretsar för det är bara två lediga i 00an. Nä det är bättre att skrota 138an helt och styra 573orna från iOpinna och lika så köra de andra CSen till IOpinnarna som 138 använde. Det blir enklare, färre kretsar och lediga iO finns.



Som sagt, inget att hetsa upp sig för en massa patchning. Detta är ett prototypkort så det är ju hela grejen med detta bygge

[ELTompa]

RAM minne
Då var det dags att få fart på RAMet som ska agera EPROM åt target datorn. RAMet är 128kx8 så det delas upp i två banker. För att PICen ska kunna addressera minnen finns där 2st 8bits Latchar (74HC573). Där finns också en 74HC00 för att både PICen och Targetdatorn skall kunna göra CS (ChipSelect).



Jag skriver en enkel första kod men den spårar ur fullständigt Det kräver en hel del felsökande innan det uppenbara uppenbarar sig. Felet är ju inte där man tror utan att det saknas en subrutin "return" på ett tidigare ställe och som inte gjort sig uppmärksammad men nu skulle ju allt krascha såklart. Men det är nått med dessa PICar. När man hållit på tillräckligt länge så löser det sig.

Men RAMtestet fungera ju inte alls, eller?
Jag mäter på den portpinne som styr OE (Output Enable) och den går inte låg trotts att programmen korrekt skriver till den pinnen. Jag provar med en annan pinne och då går OE låg.
Här är en så där typisk otydlighet i databladet. Det står att RA5 har en output typ men i beskrivingen till höger står att det bara är en inputpinne. Tar en lite stund att hitta detta men läser man så står det ju där. Bra med en förklaring för jag började först tror att jag kanske bränt pinnen.



OK nu kör vi igång RAMtestet. Verkar funka på dom 256 första bytesen. OK, då kör vi hela minnet. Nähe, det gick inte. Det blir RAMfel efter några få 256bytesblock. Det verkar lite random var det händer. Det måste vara nått hårt fel? Och ja det är det, det saknas helt enkelt Pullupmotstånd på en av ledningarna. Med 10k pullup funkar det som det ska och alla 128k adresserna skrivs läses och läses korrekt. Det här problemet kommer kanske mest av att man bygger en del i taget.



Lite olika felfall visas som





Nu har jag starta Promel massor med gånger och ingen gång har det gått fel. RAMtestet är inte särskilt tidsoptimerat men tar just nu ändå bara 7sek så det är OK. Det går att optimera mer senare efter behov.

[MiaM]

Apropå denna 74xx00 osv:
Glöm inte att tänka på vilka logikfamiljer som är kompatibla med specarna för signaler på EPROM:en du ska emulera. Och också: Är det risk att 74HC eller HCT är för långsamma här?

[ELTompa]

Bra synpunkter. När det gäller speed har jag mest tänkte på gamla system alá 6809 med 1MHz bussklocka men vem vet vad som kan behövas emuleras i framtiden. Som sagt, bra synpunkter. Uppskattas!

[MiaM]

Bonusgrej: En bra idé kan vara att ha plats för stiftlister på kortet för att föra över signaler så att man kan bygga ut för att emulera bussbredd på 16 och 32 bitar. Vet inte hur man enklast fixar det, kanske några extra I/O-pinnar för att välja vilken av flera kort man accessar från mikrokontrollern, och sen helt enkelt ha flera exemplar av samma kretskort fast ett gäng komponenter monteras enbart på första kortet?

Vet inte vilket behov det finns av sån emulering iofs. Tänkbara användningsområden är t.ex. att emulera kickstart-ROM (operativsystemet i ROM) till Amiga (16-bit för A1000/500/600/2000, 32-bit för A3000,4000,1200,CD32), eller för den delen för andra burkar från den tiden (Atari ST/TT, och så hade gamla 286/386-PC 16/32-bit bredd på BIOS (medan modernare hade 8-bit som kopierades till skrivskyddat RAM)). Å andra sidan finns ju redan komplett emulering av Amiga och andra burkar från den tiden, så eventuellt laborerande med egna ROM kan man göra i emulator och sen bränna rätt ROM direkt med god chans att det funkar på första försöket.

Ignorera allt jag skriver som kan leda till för mycket featurecreep. Eller kanske en mellanväg, stiftlister för de signaler som kan behöva delas men inte så mycket mer fixat från början?


Också, ifall du vill se hur andra löst det så har både Elektor och Dave som driver EEVBlog gjort varsin nästan likadan konstruktion då det begav sig. Misstänker att dessa också är rätt lika ditt bygge, fast deras byggen använde nog PC-parallellport och hade ingen intelligens utan man tryckte nog bara ut binärdata som om bygget var en parallellskrivare.

[ELTompa]

ADomvandlaren för att mäta interna spänningar
Jag tänkte använda den i PICen inbyggda ADomvandlaren för att mäta de interna spänningarna. Kanske lite överingenjörat men det är ett bra sätt att lära sig. Nya MIDrange-PICar har fått en modernare ADC. Den är 12bitar istället för 10 och den har fått en filterfunktion och en felfunktionsdel med tröskelvärden. Just denna felfunktionsdel har jag inte testat ännu men filterfunktionen är ju väldigt välkommen. Jag tror inte i något av mina tidigare PICprojekt att jag klarat mig utan att göra medelvärdesbildning i någon form. Och då har det bara varit att skriva kod. Men nu så finns där färdiga filterfunktioner som kommer väl till pass.

Burst AVG
Perfekt ide med att ta en serie med ADsamples, accumulera dom och shifta bittarna. Allt programerbart via register. När allt är klart får man klarsignal och det är bara att läsa ut värdet. Detta är en riktigt bra uppgradering på kislet!

Vem har Weak pullup påslaget på analogingångar?
Jag har ritat in potar så jag kan trimma signalen så den ska mäta som jag vill. Men signalen beter sig såå mysko. Ja tills jag kommer ihåg att jag programmerade in weak pullups på analoginångarna under tiden dom inte användes. Det blir ju mycket bättre utan weak pullups!

Det där med potar, det var ju onödigt
Jag kan konstatera en sak. Jag klara ju inte av att förhand trimma ingångarna lika. Inte heller trimma dom bättre än 1%



så det blir ju mycket bättre och enklare med fasta motstånd i spänningsdelaren.



ADn får en 2.048V referens. Det gör det enkelt att mäta 0-20.47V och bara läsa av binära tal och omvandla till decimalt. Men Fullskaleutslag på 12bitar blir ju 4095D. Men då kan man ju bara be det där fiffiga filtret i ADn att skifta en bit till och på så sätt få ett fint 0-2047 talområdet.

Det står att källimpendansen som driver ingångarna ska vara 1k. Jag tänker en konding på 0.01 borde funka för de inre kapacitanserna i S/H och Muxen är i picko-området. Det finns också en "acquisition" delay tid man kan ställa via register så att ADCs väntar av sig själv innan den börjar sampla. Det är ju också fiffigt och en glädjande nyhet.



Men vanudå, varför mäter jag spänning på TargetVcc när inget är inkopplat?
Ahh, jag har för stor läckström i Schottkydioderna såklart. Tänkte inte på det. Min ide med dioderna var att på ett enkelt sätt få automatiskt rätt drivspänning till Databussdrivaren men jag skippar det tills vidare och gör kopplingen enklare. Man får helt enkelt bygla som man vill köra.



Så här ser schemat ut nu



Och en bild på kortet med sina patchar



Lite fler fel och egenheter i databladet för denna MCU. Registret ADPCH listas inte bland BANKerna men ligger nog på adress 9F/bank1 ändå vilket framgår på andra ställen i dokumentationen. Men man blir ju lite nojig när man ena dagen läser fel och andra att uppgifter faktiskt saknas





En annan sak jag tar med mig är att mer kan göras i layouten som underlättar patchning just när det är ett prototypbygge.