Tag Archives: SOFT

Ghidra ir PDP11 (2 dalis) ir kiek apie AI

Rašiau metų pradžioje, kad pradėjau rašyti Ghidra modulį skirta PDP11 procesoriui. Jau atėjo 11 mėnuo ir projektas beveik baigtas. Dalį kodo rašiau pats, dalį kodo (ypač Java) rašė ir tikrino AI. Per tą laiką galiu dar ir pridėti, kad AI stipriai pasikeitė per tuos nepilnus metus. Į gerą pusę, kad ir kaip tai baisiai neskambėtu. Metų pradžioje haliucionavo ir kūrė kvailystes kurios netgi nesikompiliavo. O metų pabaigoje jis pat netgi pačia Ghidrą emuliavo savyje. Tipo po kažkiek laiko, aš sakau, va Basicas veikia, o žaidimas neveikia. Jis pasiūlė pakeitimus. Po pakeitimų basicas neveikia, o žaidimas pradėjo veikti. Sakau- sugadinai man basicą…

Ir tada įvyko baisiausias dalykas. Matau jis rašo:

nusikraunu SIMH1, paleidžiu basicą2, pasitikrinu rezultatą. Pasileidžiu ghidros emuliacija... tikrini skirtumus tarp SIMH ir Ghidros. Patvirtinu bugo atsiradimą. Lyginu pokyčius. Keičiu pokyčius. Leidžiu SIMH, leidžiu Ghidra. Va jums rezultatas- jūs buvo dalinai teisus dėl punkto A ir B, bet dėl C, D, E tikrai darosi kitaip.

Paleidžiu… Basicas veikia, žaidimas veikia. Sakau, gal dar gali java parašyti remiantis esamom programom, kad Ghidra emuliuotu PDP11 kompiuterį tiesiai į COM portą. Sako, imk… ir bl… veikia. Man biški baisu. Gerai, kad aš nesu programuotojas.

Čia dvi programos. Ghidra ir rusiškas VT52/15ИЭ-00-013 emuliatorius. Ghidra prisijungusi prie COM2, terminalo emuliatorius COM1. COM sujungti virtualiai.

Dar paprašiau, gal dar pertraukimus padarom, sako no problem. Man net kiek gėda pasidarė. Atsijungiau nuo tos Klaudijos….

Žaisti galima, bet dar liko kažkokie bugai. Ir kompiuteris Ghidroje per greitai veikia.

Taigi, galite apsiraminti. Kogero dabar jau ilgai neliesiu aš tos Ghidros ir nekvaršinsiu galvos su tuo sintetiniu PDP. O su realiu PDP visdėlto dar noriu jus panervuoti. Nes aš surinkau net kelius procesorius, kelius terminaliunius ir RAM blokus. Pripirkau panašių lizdelių. Noriu visdėlto sukonstruoti kiek labiau pilnavertišką kompiuterį.

Pats projektas GITHUBe: https://github.com/kaunomedis/PDP11

  1. SIMH tai open source archainių minikompiuterių emuliatorius. ↩︎
  2. Yra popierinė perfojuosta, DEC-11-AJPB-PB (PDP-11 BASIC V007A), su šiuo basic. Ir dar ši programa gana stipriai išnagrinėta ir dekompiliuota internetuose. ↩︎

Užpiso skanerių softas arba mano kova su korporacijom

Nupirkau čia neseniai keletą printerių su skaneriais ir teko pavargti instaliuojant softą. Pasirodo, seno, draugiško softo nebėra. Atsirado viskie “smart”, “AI”, “Claud”, “not so free” ir “unsupported” dalykai. Daėjo iki tokio, kad skaneris pajungtas per USB per windows scan skanuoja į pdf. O kai perjungi skanerį per tinklą, pdf opcija dingsta.

Nebėra galimybių jungti, išmesti, pasukti individualius lapus, įterpti kokią nuotrauką ar screen shotą. Užtat programos dabar sveria pusę gigo ir dar reikalauja susikurti accountą kokiam HP. Arba mokėti 7.99 mėnesinį mokestį už licenziją. Arba tik 14.44 už lifetime licenziją vienai buhalterei ar printeriui/skaneriui. Ir dar ne su visais skaneriais dar ir veikia.

Todėl trūko plionkė, ir pasinaudojęs savo darbdavio mokamu AI, sugeneravau minimalistinę programą skanuoti į pdf. Mūsų mielom buhalterėm, apskaitininkėm ir šiaip moterim. Šį programa bus nemokama, atviro kodo (kol MS leis) ir minimali. Dabar gal mažiau megabaito, neskaitant MS runtime, kuris susiinstaliuoja automatiškai. Ateityje bus galima sukurti ir “fat” portabilią versiją.

Taigi – nemokamas offline scan to pdf. Biški pasidaryk pats, bet vėliau bus ir “publish”.

Namie neturiu skanerio, todėl demonstracinė iliustracija su įkeltu paveiksliuku.

Programai tik 3 valandos, todėl ji nesugeba teisingai skanuoti iš ADF. Išbandžiau su Windows 10 ir Windows 11. Su įvairaus senumo HP ir Lexmark kombainais (printeris+skaneris), pajungtai per USB ir per tinklą.

Tikiuosi projektas nenumirs. Tai pagelbės ne tik buhalterių gyvenimui, bet ir IT specialistams. Ir taip, pas mane chytresni skaneriai skanuoja tiesiai į serverį.

Iš gerumų- programos nereikia instaliuoti. Ji gali pasileisti kad ir iš USB flešiuko. Iš blogumų- programa be parašo, todėl windowsams ji atrodo kaip labai labai baisi.

2026.09.28

Pilnai veikianti versija githube: https://github.com/kaunomedis/Offline-Scanner-pdf/releases
Ką ji daro? Ogi skanuoja iš visų įmonėje esančių skanerių (ir nuo stiklo ir per ADF tiektuvą) į pdf failus. Ir iš tinklinių,ir iš per USB. Gal vienintelis dalykas, kad nepadaryta- tai dupleksinis abipusis automatinis skanavimas. Rodos turim vieną tokį skanerį, bet jo neišbandžiau, nes dėl senumo, jis vos vos įtraukia popierių.

Softas maždaug 30 kartų greičiau pasileidžia nei originalus HP. 🙂 Ir pilnai atlieka tas funkcijas kurios reikalingos buhalterėm. Ir net skanuoja greičiau. Kai kurie mandresni skaneriai iš ADF skanuoja be pauzių- tik spėk kišti.

Source code visiškai atviras ir jo auditas galimas per keliolika minučių. Tikrai nėra jokių užslėptų reikaliukų (nebent patys pasidarysit).

AI? Gėris, blogis… pinigai ir MCP

Viskas prasidėjo kaip visada- nuo pykčio, honoro ir noro kažką įrodyti. Vienas žmogus aiškino man, kaip “žinovui” apie visokius AI ir kaip tam AI reikia MCP serverio. Aš tik lingavau galvą, nes nenorėjau pasirodyti, kad nieko nesuprantu. O vėliau pradėjau aiškintis kas yra tas “MCP serveris”. Ir pasiaiškinau, kad joks tai ne serveris, o pragrama (ar grupelė programų) parašyta bet kokia kalba ir veikianti viešame web serveryje. O kitą dieną tas žmogelis man aiškino, kad aš neteisus, kad čia tikras serveris ir reikia mokėti pinigus… ir čia suveikė honoras kažką įrodyti. Taip gimė pirmas konceptas php kalboje- mikro MCP serveris.

Po demonstracijos kalba tapo tokia- va tau Klaudijus mokamas, “Carte Blanche” ir padaryk tu man kai ką. Per nepilnas dvi savaites. Nes Klaudijus neturi tiesioginių jungčių, o esamos komercinės kažkokios netokios ir brangokos ilgalaike prasme.

Ir gimė dvi nesąmonės:


ir

Taigi, Klaudijus gavo prieiga prie verslo valdymo sistemos, google appsheetų ir dar kai ko. Galutinio Klaudijaus produkto demonstracija buvo gana įspudinga. Iš esmės, Klaudijus pasidarė Klaudija, sekretorė-referentė su finansisto pagrindais. Giliau aš nekapsčiau, bet užsakovas buvo laimingas. O aš irgi gavau materialinės laimės bei tebeliko Klaudijus. O jis dabar man padeda programuoti PDP11 kompiuteriuko emuliatorių Ghidroje. Ir dabar galima paleisti gana daug popierinių juostų su 1970 metų softu.

Windows gelmės

Buvo blogai įkištas USB kištukas ir Windows pradėjo mėtyti keistas klaidas. Čia per FAR klaida parodyta, tačiau patikėkit, tokia pat klaida buvo ir pas windows failų kopijavimą (windows explorer, error 800700221).

Klaida skamba keistokai “The wrong diskette is in the drive. Insert %2 (Volume Serial Number: %3) into drive %1.“.

Kas pirmiausia keista- kada skaitytojai paskutinį kartą naudojo disketes, tuo labiau kokias nors instaliacijas kai buvo naudojamos keliose disketėse įrašyti failai? Čia į “sexy” galite nekreipti dėmesį- aš mėgstu naudoti “neteisingus” pavadinimus. Mano darbo kompiuteryje galima rasti ir “xxx” ir “porno” folderius. Matyt kažkoks paaugliškas protestas.

Antras keistumas- tie “%2”, “%3”, “%1”. Tai FormatMessage() komandos parametrai, panašiai kaip printf.

Vadinasi kažkur giliai giliai, kokio nors kernel32.dll gelmėse tupi Windows NT3.x klaidų pranešimai (win32) kurie kiek nesuderinami su šiuolaikiniais reikalais, tokiais kaip USB šokinėjimas tarp 3-2-1 standarto esant blogam kontaktui. 🙂

Visus kitus klaidų pranešimus moderni sistema “perima” ir perrašo į kažką panašaus į “The printer is out of paper.” ar “The system cannot read from the specified device.”, o štai šio specifinio niekas ir nepastebėjo. Todėl modernūs windowsai neradę klaidos pranešimo, krapšto savo “atbulinį suderinimą” ir iškasa tokį antikvarą.

O problema pasitaisė pasmaukius už USB laido.

  1. 0x80070022=0x80070000+0x22, ERROR_WRONG_DISK=0x22?, HRESULT The operation completed successfully= 0x80070000. Ir sumoje klaida “The wrong diskette is in the drive. Insert %2 (Volume Serial Number: %3) into drive %1.”. Paprasčiausiai OS nenusiuntė klaidos sukelėjų pavadinimus, arba dar giliau, disketės skaitytuvas negali būti su kokia nors “E” raidė ir gal “volume serial number” pasidarė žymiai didesnis nei buvo kokias 1993 metais. Far manager naudoja kitą API, bet klaida lieka ta pati. Trumpai sakant, kažkas užmiršo 0x22 klaidą. ↩︎

pamišusiems:

#include <windows.h>
#include <stdio.h>

int main(void)
{
    DWORD err = ERROR_WRONG_DISK; //dec 34 = 0x22, tas pats kur su %1, %2, %3
    LPVOID msgBuf = NULL;

    DWORD flags =
        FORMAT_MESSAGE_ALLOCATE_BUFFER |
        FORMAT_MESSAGE_FROM_SYSTEM |
        FORMAT_MESSAGE_IGNORE_INSERTS;

    DWORD len = FormatMessageA(
        flags,
        NULL,
        err,
        0,              // kalba: 0 = automatinė
        (LPSTR)&msgBuf, // čia Windows įdės tekstą
        0,
        NULL            // argumentų nėra, todėl %1, %2 liks neišpildyti
    );

    if (len == 0) {
        printf("FormatMessage failed: %lu\n", GetLastError());
        return 1;
    }

    printf("Klaidos tekstas:\n%s\n", (char*)msgBuf);

    LocalFree(msgBuf);
    return 0;
}

Čia AI parašė. O rezultatas:



Klaidos tekstas:
The wrong diskette is in the drive.
Insert %2 (Volume Serial Number: %3) into drive %1.


C:\Users\User\Documents\Visual Studio 2022\FormatMessage\x64\Debug\FormatMessage.exe (process 11468) exited with code 0 (0x0).

National Instruments GPIB-USB adapteris

Kadangi mano HP loginis analizatorius neturi “pastovios” atminties, kiek užknisa kiekvieną kartą perkonfiguruoti visus nustatymus. Vienintelis būdas automatizuoti konfiguravimą- naudoti GPIB jungtį ir viską pumpuoti per ją. Pradžiai galvojau pasidaryti tą adapterį savo rankelėmis, bet ten reikia dviejų specialių mikroschemų, kurios kažkaip nepopuliarios. Konstruoti kažką diskretiško patingėjau. Nors ir pradėjau teorinį projektą ir susiradau visą softą jam (STM32F mikrokontroleriui). Ir dar softą perrašiau iš “arduino” į generic C. Tačiau galu gale nusprendžiau nusipirkti pramoninį variantą- National Instruments adapterį.

Atvykęs iš kinijos adapteris pareikalavo registracijos NI puslapiuose. Tačiau, kaip ne keista, NI pripažino jį originaliu ir visas softas pasileido. Tačiau softas visiškai netinkamas HP 1630A analizatoriui. Seniau, kai dar nebuvo visokių windows, ir net nebuvo DOS operacinės sistemos, tokie prietaisai valdydavosi iš BASIC programos. Todėl nutariau kiek pažaisti programuotojais. NI duoda draiverius ir biblioteką prietaiso valdymui (jis nepasimato kaip koks nors “generic” USB prietaisas). Todėl čia bus trumpa instrukcija man, kol neužmiršau kaip pradėti dirbti su National Instruments GPIB-USB-HS adapteriu.

Pirmiausia reikia prijungti bibliotekas prie projekto- references:

Ar reikia abiejų “reference” aš nežinau. Bet sudėjus abi, tikrai veikia.

Toliau reikia kogero “importuoti”:

Imports NationalInstruments.NI4882

Įrenginį “atidaryti”:

Private Sub OpenGPIB()
        Dim board As Integer
        Dim primary As Byte
        Dim secondary As Byte
        board = My.Settings.Board
        primary = My.Settings.pAdr
        secondary = My.Settings.sAdr
        Try
            dev = New Device(board, primary, secondary, My.Settings.TimeOut)
            dev.DefaultBufferSize = 14000
            dev.Reset()
            status("GPIB Open")
        Catch ex As Exception
            status(ex.Message)
        End Try
End Sub

Čia iš komentarų – buferis pagal nutylėjimą yra vienas kilobaitas. Jei prietaisas išspjauna daugiau informacijos nei telpą į buferį gali kilti problemos ir vargai. Dabar kai turim daug atminties, rekomenduoju buferį padaryti didesnį nei maksimalus galimas atsakymas iš prietaiso ir nereikės sukti kiaušų. Todėl buferį darom gal 10K ar daugiau. O štai timeout rašomas ne mikrosekundėmis, o kvailu kodavimu:

disabled
10 µs
30 µs
100 µs
300 µs
1 ms
3 ms
10 ms
30 ms
100 ms
300 ms
1 s
3 s
10 s
30 s
100 s
300 s
1000 s

čia tipo enum ar panašiai- 0 tai disabled, o 13 tai dešimt sekundžių.

Skaitymas ir rašymas:

    Public Function QueryHP1630A(command As String) As String
        Dim response As String
        If dev Is Nothing Then
            OpenGPIB()
        End If
        Try
            dev.Write(command)
            ' Read response (this will block until termination or driver-defined timeout)
            response = dev.ReadString()
            status("OK")
        Catch ex As Exception
            response = ""
            status(ex.Message)
        End Try
        Return response
    End Function
    Private Sub nuskaityti()
        Dim a(3000) As Byte
        If dev Is Nothing Then
            OpenGPIB()
        End If
        Try
            gpibstatus = dev.LastStatus
            dev.Write(txtResource.Text + vbCr) 'komanda
            a = dev.ReadByteArray 'baitų masyvo nuskaitymas
            status("OK")
        Catch ex As Exception
            gpibstatus = dev.LastStatus
        End Try
    End Sub

Seniau kompiuteriai neskirdavo baitų nuo teksto. O dabar tai jau kiek kita kalba. Todėl, paprastas tekstines eilutes nuskaitom su “readstring”, o jei tame tekste paklius koks nors “netekstinis” baitas, tai skaitymas nutraukiamas. Todėl gal geriau skaityti kaip “readbytearray”. Ir tik vėliau konvertuoti baitus į raides.

Per porą vakarų gavosi tokie griaučiai:

O toliau bėda- HP1630A nepasako, kurioje vietoje stovi kursorius. Todėl valdymas per nuotolį netenka prasmės. Dar blogiau- kai žiūrim į nuskaitytus duomenis, kur gražūs grafikėliai- niekas nepersikelia į tekstinį buferį- waveform paišomos grafiniu režimu. Todėl reikia parašyti pačių duomenų perkėlimą ir analizę. O čia jau prasideda nesąmonės- kažkaip instrukcijos pradeda kiek nesutapti su realia geležimi. Gal galima paeksperimentuoti su “grafinio printerio” emuliacija? Tokia opcija numatyta. Kaip ir kasetinio magnetofono ir diskasukio pajungimas. Pasirodo galima įkelti disasemblerį į šitą loginį analizatorių.

Todėl pasilikau dvi užduotis- konfiguracijos saugojimas ir duomenų eksportas. Gal gausis, o gal ir ne. Viskas priklauso nuo pavasario greičio. Šiandien mačiau kaip špokai (varnėnai) vaikščiojo po kiemą. Iš kitos pusės aš turiu HP ploterį su šiuo interfeisu, kurio galimybės didesnės nei Rotringo. Žymiau įdomiau paišyti kringelius su ploteriu nei gilintis į loginio analizatoriaus vidurius.

Generic C grožis arba kaip buvo geriau prie…

Tęsiant temą. Vėl tas pats PDP11, mano amžininkas ir kartu stipriai senesnis už mane. Viskas kažkaip kitaip ir panašiai. Ir toliau bežaidžiant užkniso tie visokie oktaliniai skaičiai, keistos programos (PDPGUI) parašytos Paskalyje ir su kriptiniais vokiškais klaidų pranešimais. Todėl nutariau padaryti dalį darbų old style metodu. Tiksliau- ancient style metodu. Kaip buvo prieš 50 metų ar daugiau…

T.y. renkames gryną “C” kalbą (čia bus kažkuri gcc windowsams) ir iš seno source kodo gabaliukų (archyve.org ir randominiai linkai) ir vajėzaumarija, AI generatorium generuojam naujas C programas.

Ko man reikia:

  • Parašom programą asembleryje ir sukompiliuojam. Gaunam bin failą ir lst. Tačiau čia lst kiek keistas, nes jis labai daug ką ignoruoja, rašo visokius simbolius ir t.t. O man reikia, kad išsistatytu tikras, kanoninis asembleris. Šita funkcija neprivaloma (optional), nes kai kurios programos jau bin.
  • Radau senovinį disasemblerį [disas11, 1991?] kurį pavyko sukompiliuoti. Bet jam reikia COREDUMP failų.
  • Su AI rašom bin -> COREDUMP konverterį. Beja, coredump formatą AI pats atstatė iš dalies disas11 source kodo.
  • Disasembleris duoda keistoką output failą dis, nes teoriškai galimas savaime modifikuojantis kodas. Jis rodo alternatyvini disasemblerio kodą jei prieš tai buvusi komandą pasikeistu. Gerai, kad alternatyvinis kodas pasislinkęs per tarpiukus. Su AI rašom programinę utelę kurį išfiltruoja ir palieka tik pagrindinį kodą.
  • Pagaliau išvalytas kodas visiškai oktalinis. Tam tikslui AI rašo C kalboje kitą utelę kuri konvertuoja visus octalus į hexus.

Ir tik dabar, aš galiu palyginti šešioliktainį disasemblerį su hidros parodymais ir pagaliau suprasti, kad dar reikia apšikti kažkiek žolės, kad gautusi rezultatas.

Apie ką męs čia? Ogi kad męs ne prieš AI. Tai geras įrankis ir teisingai naudojamas veikia. Paprašai parašyti utelę (beja, čia pačio AI pasiūlymas, nes jis pabijojo konvertuoti galbūt užkopyraitintą failą) ir jis parašo. O poto sakai- o tu padaryk, kad skaičiukai būtų su leading zero, išėjimas į failą, o ne stdout ir kad kai kurios specifinės eilutės eitu kitaip. Ir tas AI vergas sugeneruoja. Programos paprastos, bet pačiam rašyti nuo nulio gautųsi gal per daug laiko. Čia atsakymai atėjo per sekundes.

A, ir dar, reikėjo binarinį failą konvertuoti į oktalinį, tinkamą pumpuoti tiesiai į CPU per ODT. Toks bin to ODT text stream konverteris.

o dabar viską sukišim į makefile ir viskas man veiks automatiškai, vieno mygtuko paspaudimu.

Ghidra ir PDP11

Biški užsiciklinau su savo PDP kompiuteriu. Ir nutariau vieną programą kiek kitaip paleisti. O tam reikalui reikia daryti disasemblerį. Tačiau chaotiškam listinge (LST) labai sunku susigaudyti. Tačiau pasaulis išrado gana patogias priemones, kaip Ghidra. Tačiau viena bėda- nėra modulio PDP kompiuteriams. Kažkur githube guli kažkoks tvarinys kuris tipo palaiko PDP11, bet ten pati Hidra sulaužyta dalimis (ir nesikompiliuoja) ir kiek žiūrėjau, pačio PDP modulio (language) nėra. Vėl apgavystė. Todėl biški užpykau ir nutariau pasidaryti savo, “su šliundromis ir pokeriu“. O ten tokia “rogių kalba” (SLEIGH)…

Kol kas darau tik disasseblerį, nes iki kitoko nepriaugau. Ir dar kalnas klaidų nes:

  • Aš nesuprantu rogių kalbos
  • Aš nesuprantu PDP J11 procesoriaus kalbos
  • Aš nesuprantu PDP asemblerio
  • Aš neapkenčiu aštuntainės skaičiavimo sistemos
  • Aš nesuprantu ten kažkokio p-code, kur rašosi { } skliaustukuose

Šiaip procesorius makro CISC ir kogero pilnai Ortogonalus. T.y. visos komandos turi visus adresacijos būdus. Netgi nelogiškus, su visais galimais registrais- pvz operacijos su PC veikia kaip ir su bet kuriuo registru. Tačiau operacijos su PC turi savo sintaksę suprantama žmonėm. Palyginam:

A:	MOV (PC)+,R1
	.word 5
	HALT
B:	MOV #5,R1
	HALT

Atrodo kaip skirtingos programos (A) ir (B). Tačiau listingas rodo:

11 000024 012701                  	MOV (PC)+,R1
12 000026 000005                  	.word 5
13 000030 000000                  	HALT
14 000032 012701  000005          	MOV #5,R1
15 000036 000000                  	HALT

Binarinis kodas visiškai vienodas. Paprasčiausiai iškreiptas parašymas (PC+) programoje (A) sako, kad imk reikšmę sekančia už PC ir naudok, o poto PC padidink. O programoje (B) sako, imk tiesiog skaičių ir naudok. Bet tas skaičius kaip tik ir stovi prie komandos…

O dabar įsivaizduojam, kad komanda MOV turi du parametrus. Tie parametrai gali buti su 7 skirtingom adresacijom su 7 skirtingais registrais ar tiesioginiais skaičiais. Komanda MOV gali užimti ir vieną žodį (1Word=2bytes), ir du žodžius, ir tris žodžius (6 baitus!)…

Bet kad žinotumėt koks kaifas, kaip pradeda biški viskas veikti- smegenių mankšta. Čia jums ne shortus skrolinti youtubėje.

Ai, dar nepabaigtas produktas GitHube: Ghidra PDP11 processor language file/module (slaspec).

P.S. žinokit, ta hidra moka atkompiliuoti gcc programas. Bent jau mano kurybą su STM32 gana gerai atkompiliuoja.

ARM55: TG12864H (ST7565) SPI

Tai dar vienas atmintinukas apie LCD ekraniukus. Tokie ekraniukai kogero eina iš kokio Ali, bet aš juos radau kažkokiuose kasos aparatuose. Iš įpatybių: Read Only, SPI.

Beveik viskas veikia naudojant standartines ST7565 bibliotekas, tačiau yra kažkoks bugas su inicializacija. Kol kas sprendimas- du kartus inicializuoti ekraniuką.

Kadangi nėra galimybės nuskaityti ekrano atminties, norint pasinaudoti grafinėmis funckijomis (taškai, nuskaityti tašką) reikia daryti šešėlinę atmintį (shadow ram) ir ten laikyti ekraniuko ekrano kopiją.

Veikiančios demo programos source code, STM32F103 procesoriukui, STM32CubeMX griaučiai.

Futaba VFD GP9002A01A (ARM)

Nors realiai tai GP9002A02A. Man patinka VFD technologija. Keista spalva, didelis šviesumas ir kažkoks lempinis vaizdas. Todėl jei matau kur nors palaidą VFD ekraniuką, stengiuosi prigriebti. Aišku aš kalbu apie panaudojamus modulius, o ne kažkokius “custom made” iš senoviškų magnetofonų. O kiek kartų mačiau milžiniškus grafinius modulius kurie buvo sudaužyti- stiklinis korpusas neduoda tvirtumo. O šis modulis nukentėjo kitaip- jo trafukas su plonučiais laideliais atitrūko nuo transformatoriaus korpuso. Teko klijuoti ir užsiimti mikrochirurgija- trafukas visgi smd.

Tai grafinis ir tekstinis modulis. Galima pumpuoti binarinę informaciją arba galima naudotis integruotais šriftais ir kiek keistokais šrifto dydžiais. Ekranas kaip ir “grayscale”, bet man nepavyko. Gali būti, kad yra skirtumas tarp “01A” ir “02A”.

Futaba moduliai dažnai būna ne tik lygiagretaus interfeiso, kaip LCD moduliai, bet turi slaptus papildomus interfeisus: asinchroninis nuoseklusis (kaip RS232, tik TTL lygiai) ir SPI (synchronious serial). Asinchroninis dažnai būna per lėtas, net prie 115kbit matosi kaip formuojasi vaizdas. Paralelinis naudoja labai daug laidų, tačiau labai greitas. O štai SPI kaip ir kompromisas. Pas šį VFD maksimalus greitis kažkur 2Mbit. Nauji moduliai dažnai būna USB/HID- tokių dar nečiupinau.

Su STM32CubeMX sugeneruojam programos griaučius. Aš pasirinkau kojeles iš eilės. Procesoriukas- bet koks. Čia konkrečiai STM32F103VBT6. Kur kibirą turiu.

Mums be SPI, reikia CD (command/data), CS (chip select) ir jei norime gražiai animuoti: VFD_INT (čia kadrų sinchroimpulsas). CS – programinis, nes yra biški triukų. Net porą vakarų turėjau praleisti, kol pradėjo teisingai veikti. Trumpai- CS, CD ir SPI sekos svarbios!

Iš datašyto matom, kad SPI nėra defaultinis. Pirmiausia LSB, antriausia netipiniai CLK. Dar žiūrom į C/D.

VFD datasheet SPI

Labai padeda susigaudyti settinguose šis vogtas iš interneto paveikslėlis. Renkam tą kuris panašiausias:

Beveik visos komandos surašytos į programą. Aišku kiek užknisa ekrano atminties organizavimas, bet viską galima apeiti naudojant galingus MCU.

Ir aišku VFD ekrano valdymo source code STM32F103 procesoriui. (ARM-0053).

Blogas GCC arba x86 bėdos

Papuolė į rankas tokia maža ISA PCB su keliais čipais. Su magišku užrašu “Y2000”. Ir iškarto trenkė nostalgija, apie tai, kaip visi panikavo, kad kompiuteriai 2000-taisiais metais išprotės, nes metai tik dviženklis skaičius. Aišku buvo bėdų su tais metais, bet daugelis panikuotojų nepagalvojo, kad technologija smarkiai tobulėja ir kompai pradėjo labai greitai morališkai senti.

O tiems, kurie strigo su sena technika, atsirado visokie BIOS pataisymai. O jei nėra BIOS pataisymo, va jums papildoma plokštė su ROM. (Kitos mikroschemos tik supaprastina ROM pajungimą prie ISA linijų)

Nutariau pažiūrėti, kas tos mikroschemos viduje. Viduje labai mažai kodo, tai buvo kaip tik, kad pasimokinti Hidros (GHIDRA) programos vartojimo.

ISA PCB yra 8 bitų. Vadinasi suderinama su pačiais primityviausiais x86 procesoriais. Vadinasi kiek rimtesni procesoriai turi veikti “REAL MODE” režime. x86 procesoriaus kodas vos vos panašus į Z80 ir tikrai panašus į 8086. Hidra išardė kodą. O internetai padėjo atpažinti- pirmi trys baitai tai 55 AA 10. “55AA” tai signatūra, o 10 tai programos ROM dydis (kart 512 baitų, h100). O nuo 4 baito prasideda pati programa.

Konkreti Y2K PCB darė šitą: išvalo ekraną (rodos), parašo užrašą, nuskaito dalį RAM ir kažką paskaičiuoją ir jei nepavyko, sako error ir išeina, nuskaito RTC per BIOS, nuskaito RTC tiesiogai, palygina, ir jei kažkas gaunasi arba rašo, kad kompas suderinamas su Y2K arba bando (?) pačinti BIOSą. Čia jau spėlioju, nes mano žinio gana trumpos čia.

Kilo mintis padaryti va taip:

Copy-paste kažkiek asemblerio mnemonikų… ir kaip sukompiliuoti? Internetai sako, kad standartinis GCC, su raktažodžiais tipo “-m16 -nostdlib -ffreestanding” turi gaminti x86, 16bitų, REAL kodą. Ir tikrai, kopijuotas kodas iš Hidros susikompiliavo. Toliau teko kankintis su LD.exe ir visokiais loaderiais, kad gautųsi ROM image, o ne exe failas. Tai irgi buvo pilnas nuotykių žaidimas kuris nepavyko iki galo.

Tačiau kodas neveikė realiuose kompiuteriuose.

Ir pasirodo, kad JOKS GCC nesugeba generuoti teisingą 16 bitų, REAL MODE kodą. Iš principo. Binarinių failų palyginimas parodė, kad CALL, RETF ir gal kitokios instrukcijos generuojamas 32 bitų. Tas 32 bitų kodas “kaip ir suderinamas”, bet kai paleidi iš BIOSo, tai tikrai nesuderinamas. Ir nesvarbu koks procesorius- 486DX irgi nesuprato.

Rašyti softą be CALL kaip ir sunkoka. Gerai, kad čia tik kelios eilutės- išvalyti ekraną, per BIOSą (TTY režime) išspjauti tekstą ir nuskaityti ANYKEY iš klaviatūros. Teko viską perrašyti tiesiogiai. Ir rankutėmis įkelti “RETF” teisingą kodą programos gale. Kodu nesidalinu, nes jis baisus, nesuprantamas ir ten per daug POP/PUSH (kopijavau iš tikrų paprogramių, kur išsaugoja registrus). Svarbu veikia.

ROMas turi primityviausią kontrolinę, 8 bitų, sumą. Todėl reikią paskutinį baitą ROMe kaitalioti tol, kol suma nepasidaro 00.

O dar radau keistą PCI plokštę iš Izraelio- kažkoks tipo “security”. Pati PCB tai kastruota tinklo plokštė su BOOT ROM. Jei bus azarto, bus galima pasinagrinėti šitą kodą.

Taigi, be normalaus asemblerio, koduoti ROMą labai sunku. O tiek turėjau planų- panaudoti C kalbą ROMe ir PC kompiuterį panaudoti kaip mikrokontrolerį. Kam? Ogi smalsu. Nebent PCI kompiuteriai jau tikrai valgo 32 bitus ROMe.

O grynai asembleris tai NASM. Jam puikiausiai kompiliuojasi. Tikriausiai komentaruose bus pilnas komplektas NASM kompiliatoriui.

P.S. Originalus Y2000 ROMas.