Svenska ElektronikForumet

Nu funkar brännande som tänkt
Nu har jag implementerat EPROMbränningen så jag tycker den fungerar. Den kan bränna 27c64, 27c128, 27c256 och 27c512. Den kan också bränna 27128 NMOS så jag tror den kan andra NMOS varianter också. Och en EPROM som var kass och drog för mycket ström detekterades också utan att någon rök släpptes ut


Hur är det med kravuppfyllnad runt EPROM-bränning
Jag behöver ta en titt på tidigare inlägg vad som står om kraven. Jag har ju mest bara kodat på och meckat senaste tid för att det är kul.

ELTompa skrev: ↑14 juli 2024, 20:16:32

ID	Förväntning	Uppfyllnad	Valideringssmetod	Resultat
Förväntan-13	Emulatorn förväntas kunna bränna EPROM alá 27c64/128/256/512.		Praktiska prov

Programmering
Krav-1301: Det skall gå att programmera en 27c64 EPROM
Krav-1302: Det skall gå att programmera en 27c128 EPROM
Krav-1303: Det skall gå att programmera en 27c256 EPROM
Krav-1304: Det skall gå att programmera en 27c512 EPROM

Ja, dom här kraven är testade nu under utvecklingsfasen så dom kommer nog passera kommande verifiering.

Men jag gjorde en kravjustering i september, hur ser det ut med den då?

ELTompa skrev: ↑9 september 2024, 17:27:45

ID	Förväntning	Uppfyllnad	Valideringssmetod	Resultat
Förväntan-13	Emulatorn förväntas kunna bränna EPROM alá 27c64/128/256/512 och motsvarande NMOS-varianter.		Praktiska prov

Denna förväntan får direkt minst ett nytt systemkrav att verifiera mot
Programmering
Nytt krav:
Krav-1305: Det skall gå att programmera en ST 27128 NMOS EPROM

Ja jag ser ut att jag inte avvikit från planen. Men det syns här att jag tog ett uppehåll i projektet under hösten. Det finns ju fler roliga saker att mecka med så man får alternera lite.

Hur ser det ut nu då med brännfunktionen
Jo med autodetekt och verifiering som görs även med under och överspänning så ekar terminalen förloppet såhär för en 27512 EPROM.
Jag har inte mätt programmeringstiden men det går ganska fort. Typ 10 sekunder tror jag.



En brägård skickas till terminalen för var 2kbyte som har avverkats.
Tycker detta funkar mycket bra om jag får säga.
.

Nu funkar EPROM emuleringen
Så har jag nu fått in emuleringskoden också. Ja det är ju inte så mycket kod det handlar om utan mest att styra några IOpinnar så att RAMet i Promel kopplas om till Target-datorns bus.
Men först kompletterade jag med det sista kretsarna som sköter just detta. Schemat ser ut såhär.



Jag hade lite olika ideer på hur jag skulle göra probe-kabeln. Men jag minns inte jag satte ner foten och det blev tydligt nu för jag hade inte numrerat IDC Headern enligt DIL pinnarna så det fick bli en liten korskopplingslåda på kabeln. En sån hade jag nog ändå tänkt att göra för att lite snyggare komma ut med Target RESET ledningen men nu fick den ju inhysa korskopplingen som annars bara hade gått rakt igenom. Hur som, det blev ganska bra ändå.



Jag har ju bestyckat ett av mina CRED 6809 mönsterkort från 1989 och fått fart på men en enkel kod. Visas i Tråden CRED 6809 - Projekt från förr.
Kopplar ihop Promel med CRED 6809 kortet. Den oranga kabeln är Target Reset ledning.



Samma enkla kod som testats med EPROM på Cred 6809 kortet och som bara initiera PIAn och togglar PORTA med 0x00 / 0xFF får utgöra målkod för att testa emulatorfunktionen i Promel.
Jag laddar den med Promel kommandot down



När man laddar HEXfilen så ser man vilka adressområden som programmeras lite rudimentär men funkar som feedback
Nu blir man ju lite nyfiken och vill se att koden hamnar i minnet där det är tänkt på adr 0xF000



Och det ser ju helt rätt ut.
Men hur är det med reset och avbrottsvektorerna?



Ser ju också OK ut att dom hoppar till där koden är, alltså 0xF000
Då kör vi igång emuleringen.



WoW det funkar!





Om man stoppar emuleringen, funkar det?



Yes, och om man startar igen



Funkar också att Stoppa och Starta igen.

Edit: bilder som kom i fel ordning

Seriecom med Xon - Xoff
Jag började optimera lite i koden så processen som processar inkommande HEXfiler snabbare betar av inbufferten. Det fanns flera optimeringar att göra och med gott resultat.

Jag har sedan en tid haft problem med att kommunicera på 115kb. Lite skumma problem när jag ekar kommando till terminalen så jag har kört 57kb istället och det har funkat stabilt.
Felet vid 115kb ter sig som att ett flertal tecken, oftast i rad, under vissa stunder inte alls tas emot. Kan se ut som på bilden nedan där rad två förväntas avslutas med " 64k OK"+CR+LF+">" men bara CR och ">" verkar komma fram



Nu när inbufferten betas av snabbar så vill jag få 115kb att funka så jag började mäta lite och då ser man att TX signalen från Promel verkar begränsas till ca -4,9V av serieporten i datorn



och kopplar jag ur Seriekabeln till datorn så går spänning till -7,5V direkt.
Så jag provar med en USB<->RS232 dongel istället och det fungerar så klart perfekt med drygt ±7V sving.



Så nu går det bra att pumpa på HEXfiler i 115kb Skönt att reda ut vad som var felet. Jag ogillar skarp oklara fel.

Xon-Xoff
Tycker mig se att promel hänger sig lite då och då vid 115kb och laddning av HEXfiler men inte vid 57kb så jag lägger till lite kod för Xon-Xoff. Grundkoden var redan förbered för det som det var en smal sak att få till.
Mäter sedan på skoj hur ofta den skickar Xoff till terminalen men inte då...

MiaM skrev: ↑16 juli 2024, 00:14:16 Behövs xon-xoff? Typ finns det saker som tar extra tid, typ skriva till fler register osv, som inte hinns med i t.ex. 115200 bps?

Jag har nog gjort lite fler fixar i mjukvara så nu går den fort nog för att hinna med precis, som MiaM förutsåg redan tidigare.
Laddning av HEXfiler funkar nu stabilt. Det känns tryggt!
.

Alla kommandon på plats
Tror jag har fått till alla kommando som krävs plus sånna som nog behövs. Det blir en helt gäng kommando.
Ett misstag (eller saknad funktion ska man nog säga) i min rörförstärkare EL384SEUL - Hifirörförstärkare med subbasslutsteg är att inte kunna få en hjälptext som gör att man kommer ihåg kommandona och syntax/parametrar. Det har jag byggt in i Promel. Med kommandot "Help" så listas samtliga kommandon



Och för varje kommando kan man skriva ett frågetecken som parameter och då få en beskrivning av parametrarna för just detta kommando, tex såhär



Det är extra bra för en del kommandon som kommer i flera smaker, tex såhär



Implementerade kommandon
































.

Ganska gravt sidospår, men en smula relaterat till tråden:

Det finns ju en hel del cykelexakta emulatorer för äldre datorer skrivna i mjukvara (typ t.ex. MAME osv), och det finns några få som emuleras cykelexakt med FPGA, och specifikt så finns t.ex. Commodores diskdrive 1541 cykelexakt emulerad i mjukvara så att den ansluter hårdvarumässigt till en C64.

Frågan är hur krångligt det skulle vara att göra en sådan emulering av de klassiska Data I/O Unisite osv? Tänker att man bygger hårdvara som kan fungera som deras PIN drivers, och sen emulerar resten, och kör deras mjukvara. Det är ju förstås copyrightskyddad mjukvara, så skulle man göra en sån produkt som open source eller rent av kommersiellt projekt så måste man ju skriva nån helt egen mjukvara också, om än rudimentär, för att motivera projektets existens på ett lagligt sätt så att säga (även om det är nog osannolikt att Data I/O, vad det nu blivit av dem, skulle ge sig på hobbyister).

Promel får låda
Jag har sen en tid tillbaka uppgraderat till en 3Dskrivare som har filament-magasin och som då kan skriva ut i flerfärg. Det var väl kanske inte det jag fokuserade på vid inköpet utan mer att den kan skriva ut avbrottsfritt och byta filamentrulle själv utan min medverkan. Men då kom jag på att om man tänker till lite så kan man ju skriva ut med transparent filament och på så sätt göra LEDlinser som är integrerade i själva kåpan. Jag hade först tänkt att skriva ut lösa linser och limma dessa i kåplocket men efter att ha överlistat slicern som hela tiden ville göra ett ogenomskinligt top-lager så blev det ju riktigt bra.
Nytt med detta bygge är också att jag provade matt PLA. Det blir väldigt fint.



Men matt PLA fäster mycket hårdare mot byggplattan så den blir "vitningar" i plasten när man lossar från byggplattan. Jag hade hoppats på att ytan skulle bli fint mönstrad som med blankt PLA men men, det blev ganska bra ändå.
Jag hade sen en tid redan funderat ut att skriva text med en annan färg och det visade sig funka ganska bra det med.



Jag behöver justera höjden på ZIFen så jag löder på en list av svarvade IChållarben som kommer ge lagom höjd. Kortet fästes sedan i lådbotten med distanser och distanserna får sedan agera muttrar till skruvarna som håller locket. Blir ett kompakt byggsätt där lådan bara mäter 4mm mer än kortet runt om.



Locket på lådan får utskuret för kontakterna runt om.



Och med EPROM emulatorproben ser det ut så här. Jag är riktigt nöjd med resultat



Och så funkar det mycket bra det lilla jag ännu hunnit prova. Här är samma testkod som förut på mitt nybyggda CRED 6809 kort



Och inte glömma att man kan bränna EPROM också.



Edit: Texter justerade

Nu börjar det ju se ut som en riktig produkt.

Jag är riktigt imponerad!

Snyggt!

Proben skulle kunna heta PROBEL

Hahaha, rolig idé MiaM, att jag inte tänkte på det.

Tack för feedback och kul att höra ni läser tråden.

Om koden
Ur XC8asm får man en liten minnesåtgångslista. Det är bra men lite oöverskådlig att försöka se hur man ligger till med kod i de olika bankerna.
Så jag gjorde ett litet verktyg där man kan klistrar in listan från XC8asm och som sedan generera en grafisk bild över minnesbankerna.



Detta hjälper när man ska flytta runt kod i olika banker för att få plats.

Lite kod statistik
Assemblerkod = 7k9 minnesadresser
Teststrängar = 4k3 bytes
EPROM databasen = 2k bytes tillgängligt (32bytes/EPROM)
Senast använda kommandolista = 256 bytes
RAM = 1k bytes
EEPROM = 12 bytes


Om inställningar
Det finns ett fåtal CVn (Configuration values) och dessa spara i EEPROM och de läses och skrives med get/set kommandon



EPROM listan
Jag kom på att jag ville ha ett kommando fr att lista vilka EPROMar som EPROMdatabasen innehåller så jag gjorde ett till "info" kommando



Bäst att fixa med kod nu när man har det färskt i minnet.
.

Just ja, förslag på en funktion som antagligen sällan kommer behövas men som kan vara bra att ha:
Möjlighet att bränna ett specifikt område av en fil/dump.

Tänker specifikt på att ändra konfigurationsområden i EEPROM och liknande.
Jag har dock råkat ut för strul, vet inte om det är mjukvara, hårdvara eller dåliga EPROM, där en ALL-03 bara orkade skriva 2732 ordentligt på andra försöket, och den ger upp efter varje block om 256 bytes. Så det var bara att köra programmeringen 17 gånger i rad för att få all data att fastna, och då brände den ju samma data 17 gånger istället för bara två gånger i första delen av EPROM:et. (Men jag fick till slut spela Pacman-klonen Jelly Monsters på min VIC 20, precis som jag gjorde när jag var liten )

Jag har gjort en variant på det, eller det är en del av brännrutinen i säg. Då RAMminnesinnehållet är 0xFF så hoppas bränningspulsen över för den byten. På så sätt går det ju snabbare att bränna EPROMar med låg fyllnadsgrad om dom ska vara fyllda med 0xFF, vilket är önskvärt om man vill bränna på mer saker senare.
Haken med den lösningen, om jag förstår ditt förslag rätt, är att verifieringen efter att hela EPROMet har bränts, kommer klaga om det inte är 0xFF i EPROMet där RAMet säger det ska vara det men man bränner bara dom ställena som ska brännas så man slipper 17gg i onödan som du beskriver.

En variant på detta kan vara att bränningen först gör verifiering för att avgöra om det behöver brännas eller inte, och om det skiljer så bränner det.

Typ kombinerad blank-check+verifiering, som mer kollar om det går att bränna vad man vill bränna snarare än att kolla att EPROM:et är blankt. Kanske.

Rent tekniskt skulle det fungera tror jag. Men databladen för EPROMarna som jag läst pekar flera på att inte göra avsteg från föreslagna programmerings-sekvenser och timing. Något datablad till och med avråder från att använda "hemmabyggen" för att garantera datahållbarheten i minnena.
Man skulle ju kunna göra en speciell algoritm som man kan använda som gör som du föreslå och aktivera den med separat kommando. För jag är tveksam till att införa det som standardförfarande.

Verifiering mot uppsatta krav
Ok, kanske ska gå igenom kravspecen och till vilken grad den uppfylls. Under resans gång har det väl gjort 1st lite större förändring och några lite mindre. Den större var den att införa EPROM bränning och några av dom mindre är väl att ha en EPROM databaslista och att minnas de senaste kommandona. Så här när dessa är införda tycker jag det helt klart varit värt att göra dessa då det gjort produkten betydligt mer användbar. Också roligt under resans gång lära sig lite nya saker här och där.

Systemkrav - Funktionella och värdekrav blandade

Emulering

Krav ID	Kravtext	Uppfyllnad	Verifieringsmetod
Krav-1001	Det skall gå att emulera 27c64	?	Genom test
Krav-1002	Det skall gå att emulera 27c128	?	Genom test
Krav-1003	Det skall gå att emulera 27c256	?	Genom test
Krav-1004	Det skall gå att emulera 27c512	OK	Genom test
Krav-1005	Emulatorn skall kunna sätta måldatorn i Reset	OK	Genom test

Kommunikation

Krav ID	Kravtext	Uppfyllnad	Verifieringsmetod
Krav-1101	Det ska finnas en RS232 port att kommunicera med en terminal	OK	Per design
Krav-1102	Det ska gå att ställa baurate till 115k2	OK	Per design
Krav-1103	Det ska gå att ställa baudrate till 57k6	OK	Per design
Krav-1111	Det skall gå att ställa baudrate till 19k2	OK	Per design
Krav-1104	Det skall gå att ställa baudrate till 9k6	OK	Per design
Krav-1105	Flödeskontroll ska kunna ske med XON-XOFF	OK	Per design
Krav-1106	Seriekommunikationen ska ske med 1 stoppbit och utan paritet	OK	Per design
Krav-1107	Emulatorn skall ha en kommandopromt och styras an användaren via kommandon	OK	Per design
Krav-1108	RAMinnehåll skall kunna laddas ner till Emulatorn via Motorola S-records	OK	Per design
Krav-1110	RAMinnehåll skall kunna laddas ner till Emulatorn via Intel Hex 8-records	OK	Per design
Krav-1109	RAMinnehåll skall kunna laddas ur Emulatorn via Motorola S-records	OK	Per design

ZIF

Krav ID	Kravtext	Uppfyllnad	Verifieringsmetod
Krav-1201	Det skall finnas en ZIF sockel med 28pin	OK	Per design
Krav-1202	Det skall gå att göra ZIFsockeln strömlös på pin28	OK	Genom test
Krav-1203	Det ska gå att kopiera innehållet från en 27c64 EPROM till RAM	OK	Genom test
Krav-1204	Det ska gå att kopiera innehållet från en 27c128 EPROM till RAM	OK	Genom test
Krav-1205	Det ska gå att kopiera innehållet från en 27c256 EPROM till RAM	OK	Genom test
Krav-1206	Det ska gå att kopiera innehållet från en 27c512 EPROM till RAM	OK	Genom test
Krav-1207	Det skall gå att läsa av EPROM ID (Adr9-ID)	OK	Genom test

Programmering

Krav ID	Kravtext	Uppfyllnad	Verifieringsmetod
Krav-1301	Det skall gå att programmera en 27c64	OK	Genom test
Krav-1302	Det skall gå att programmera en 27c128	OK	Genom test
Krav-1303	Det skall gå att programmera en 27c256	OK	Genom test
Krav-1304	Det skall gå att programmera en 27c512 EPROM	OK	Genom test
Krav-1305	Det skall gå att programmera en ST 27128 NMOS EPROM	?	Genom test

Programmering

Krav ID	Kravtext	Uppfyllnad	Verifieringsmetod
Krav-1401	Det ska visuellt gå att se om emulatorn är på	OK	Per design
Krav-1402	Det skall visuellt gå att se om emulering pågår	OK	Per design
Krav-1403	Det skall visuellt gå att se om programmering pågår	OK	Per design
Krav-1404	Spänningar i Emulatorn ska kunna rapporteras till terminalen	OK	Genom test
Krav-1405	Emulatorns mjukvaruversion ska kunna rapporteras till terminalen	OK	Per design

Administrativa egenskaper

Krav ID	Kravtext	Uppfyllnad	Verifieringsmetod
Krav-1501	Användarens inställningar skall bibehållas om emulatorn stängs av och därefter slås på	OK	Per design
Krav-1502	Användarinställningar skall kunna återställas till leveransläge, så kallat "Factory Default"	OK	Per design
Krav-1503	Minnestest av RAMminnet skall kunna utföras	OK	Per design
Krav-1504	Emulatorn skall ha inbyggt ett hjälpsystem med hjälptexter	OK	Per design
Krav-1505	Innehåll i RAM skall kunna listas i HEX format till terminalen	OK	Per design
Krav-1506	Innehåll i RAM skall kunna listas i 7bit-ASCII format till terminalen	OK	Per design
Krav-1507	Senast använda kommandon (minst 8st) skall kunna återställas	OK	Per design

Tillbehör

Krav ID	Kravtext	Uppfyllnad	Verifieringsmetod
Krav-1601	En 5V USB nätdel skall finnas	OK	Per design
Krav-1602	En 5V USB-A -> 2.1mm Power plug adapterkabel > 1m skall finnas	OK	Per design

Summering
Mycket av kraven tycker jag har landat i bra systemlösningar. Restlista att ta med framåt får bli:

1. Det finns vissa gap i verifieringen. Bland annat att kunna emulera de mindre minnena på rätt sätt. Jag tänker jag får fortsaätta med det under resans gång i användandet av Promel för jag känner på mig att det kommer uppstå skarpa situationer när det blir lämpligt.

• Dom NMOSminnen jag har fungerar att bränna med 100us puls så jag har ännu inte hittat några kretsar i min ägo som kräver 500us / 1ms pulser. När jag får fatt i sådana som kommer jag mecka algoritmerna för dessa. Det är ganska enkelt att bygga in fler algoritmer sålängde dom följer de vanliga programmeringsscheman.

.