C64 ROM emulálása ESP32-vel

Miniszámítógépek, SBC-k

Szeretnék egy 8KB-os C64 cartridge ROM-ot emulálni ESP32-vel. Találtam egy leírást, amiből az első típusú kártyát építeném meg, csak szimulált ROM-mal. Itt csak 13 bites címbusz, 8 bites adatbusz és még 2 láb csatlakozik a ROM-hoz. Ehhez van 13 input GPIO és 8 output GPIO kapum az ESP-n. A maradék 2 láb valamilyen engedélyezési bit, ha jól láttam, de innentől jönnek a problémáim:

1 - Az ESP jelszintje 3.3V, a buszokon 5V szalad. Az ESP input szinten elviseli az 5V-ot, de ahhoz, hogy az adatbuszra 5V-ot helyezzen, kellene még egy-egy tranzisztor. Azonban attól félek, ennél bonyolultabb a helyzet. Mi van, ha nem az emulált 8KB-os címen van az adatbuszra helyezendő adat? Ilyenkor az igazi ROM csip mit csinál? Gondolom, valahogy elengedi az adatbuszt, hogy egy másik memória csip helyezhesse rá az adatot. Erre való a maradék 2 láb? A kapcsolási rajzon a memória csak a cím alsó 13 bitjét látja. Honnan tudja, hogy a felső biteken milyen jel van? Erről a C64 gondoskodik, és csak akkor olvassa a kártya adatbitjeit, ha a megcímzendő tartományból kér adatot, vagyis nem is kell tudnom elengedni az adatbiteket?

2 - Tehát ha a kártya RL bitje alapján nem kell adatot szolgáltatnom az adatbuszra, akkor el is kell tudnom engedni azt. Ehhez milyen kapcsolás kell az output GPIO kapuk és az adatbitek közé?

  • 857 megtekintés

( igiboy | 2022. 01. 31., h – 08:17 )

Van SPI-os GPIO bővító. Pl. MCP23S17 Lehet ezt lenne érdemes használnod. 
Az ESP32-n van pár láb ami induláskor sem mindegy hogyan áll. Ezenkívűl te is akarod még programozni, tehát jópár láb nem minden esetben használható.

Ha pl. 2db MCP23S17-t használsz IO bővítőként, akkor az ESP-re 5V-os IO-t nem kell illesztened, csak az SPI-t, mert a MCP23S17 lenne 5V-on. 5db GPIO-ot venne el az ESP32-től. Sebességben szerintem teljesen elég lenne ROM-ot emulálni.
3v3 - 5v szintillesztésre egy FET-es kapcsolást szoktak legtöbbször használni. Néhány esetben elég egy pár ellenállás is akár. Vannak kifejezetten szintillesző IC-k is.

Igen lassítja. Meg kell vizsgálni, hogy használható-e még ezzel a sebességgel amit szeretnél.

Ha C64-nek lenne leírása, hogy minek kell megfelelni, milyen időzítések vannak az lenne a legjobb. Ha ez nincs akkor régi "kazettában" milyen EPROM volt és annak az adatlapját megnézni.

Sebességben szerintem teljesen elég lenne ROM-ot emulálni.

Ebben biztos vagy? Legfeljebb néhány 10 ns-od van. Az SPI-s I/O expander nem jó ide. Az RL felől kap egy magas szintet, hogy el kellene engedni a buszt, mire azt feldolgozod, SPI-n elküldöd az I/O expandernek, hogy a lábak forduljanak befelé, addig már rég zárlatban vagy a belső memóriával, vagy a CPU-val, vagy valamelyik perifériával.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt a sebesség dolgot meg kell vizsgálni. Igazad lehet, de az is lehet elég az SPI-os bővítő is rá. Az EPROMOK sem adták ki azonnal az adatot amikor megcímezték, ott is várni kellett, hogy biztosan valós adatot kapj. (emlékeim szerint) Eseleg valami olcsó FPGA vagy hasonló dolog, amit ESP32-vel programozni tudna? Vagy FLASH EPROM amibe a programot be tudja tölteni ESP-vel?

Nem hiszem, hogy a futás közbeni módosítás kellene neki. Tippre régi ROM-okat akar rátölteni, játszani a géppel.

Igen, ez az egesz projekt amit a topiknyito kollega felvetett valojaban egy tok jo tanulopelda lenne FPGA-kra. Verilogban nagyjabol 20 sor egy ilyen ROM modul, es akkor meg gyors is lesz :) Persze nincs az az FPGA amit 5V-ra tudna illeszteni kozvetlenul, szoval a szintilleszto buffer(eke)t nem usznank meg. 

Mint korábban írtam: PSOC5LP. 5V-os, Igaz a Cortex M3 mellett nem FPGA van, hanem csak CPLD + ALU (UDB fejezetet). Persze beszerezni már ezt is csak Kínából lehet.

Most csináltam ilyennel egy 16 csatornás WS2812B led dekódert LCD-re, hogy fejlesztés közben ne kelljen a ledeket bámulni. Szenzációs cucc, és az analóg funkciói még említésre sem kerültek.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Nem, ezt még nem hamisítják. Egyébként Kínában minden van, ami a világ többi részén hiánycikk. Ezek a huncut ferdeszeműek betáraztak mindenből és most jó drágán csepegtetik.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Érdekes egy jószág. Ha jól sejtem meg lehetne vele csinálni, hogy a CPLD-be beletölteni az EPROM-ot, vagyis olyan kapukat tenni bele ami az EPROM-ot szimulálja? USB pedig jó lenne arra hogy akár egy CDC emulációval + soros terminálos fájlátvitellel  egyszerüen rátölthető lenne az EPROM tartalma? JTAG-USB csak fejlesztésre lenne? Ráadásul 5V-os... ha lehetne kapni is. A nyalóka alaku demo board lehet elég is lenne neki.

A CPLD-be nem fér bele az EPROM, azt a flashben vagy ramban kell tárolni. A CPLD-vel megcsinálnám a busz kezelést (A0-15, ROML, ROMH, stb.), ami egyrészt indítana egy DMA kérést a Cortex felé ha adat kell, másrészt vezérelné a 8 bites out regisztert (D0-7) tristate állapotát. Új tartalmat akár USB-CDC-n is lehetne feltölteni, vagy UART-on, vagy amit kivitelezel a CPLD-ben.

"Nyalóka" az Alin is van, igaz már háromszoros áron. Külön IC is van az alkatrész brókereknél. Az árak miatt kicsit ágyúval verébre lenne ebben a formában ez a projekt. Kivéve, ha van a fiókban néhány darab.

Szerintem legegyszerűbben ezt 5V-is parallel NOR flash-el lehetne megcsinálni. A C64-el lehetne programozni.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

( apal v | 2022. 01. 31., h – 08:37 )

Szerkesztve: 2022. 01. 31., h – 08:44

Amit keresel mindket (1. es 2.) problemadra azt ugy hivjak hogy tri-state octal buffer. Az, ha jo sorozatbol valasztod, megcsinalja a szintillesztest is es az RL-es engedelyeztetest is. Ki kell valasztani hogy melyik a jo.  Pl a 74465 variansai elsore jok lehetnek. Vagy a 4000-es sorozatbol a 40244 (pl SN40HCT244). 

Ugyanakkor arra is figyelned kell hogy ez egy aszinkron EPROM chip, az adatlapja alapjan ~100ns eleresi idovel. Azaz az ESP32-n futo programnak brutalgyorsnak kell lennie. Siman lehetsegesnek tunik, igy elsore: az ESP32 instruction set-et nem ismerem, de pl egy STM32F4-es, 160MHz-ra huzott MCU-val szerintem eppenhogy de menne. Kerdes persze hogy a C64 szinkron ROM vezerloje milyen gyorsan varja a jelet, ott milyen orajelen fut az az aramkori resz. Ha csak 1MHz koruli akkor boven van lehetoseged jatszani, olyannyira hogy akarmeg a tri-state dolgot is meg tudod csinalni szoftverbol es nem kell hozza kulon ice ;) 

Hajra! 

Köszönöm, a választ. Ritka élményben volt részem: sikerült olyan keresést indítanom a Google-ben, amire csak 1 db találat volt, és az sem releváns ( "SN40HCT244" ). De találtam egy hasonló IC-t "CD40244 PHI. /74C244/" néven. Ez is jó lehet?

Az ESP-t egyébként 240Mhz-en futtatom. Érzem én is, hogy a sebesség kritikus lehet, de szerencsére a 8KB ROM tartalom simán befér memóriába egy tömbbe, így viszonylag gyorsan tudom megkapni a választ. Több idő, míg kiolvasom a 13 címbitet, és egy indexet csinálok belőle, de ezen még dolgozom.

Azt azonban nem tudom elképzelni, hogy szoftverből hogyan tudom elengedni az output adatbiteket?

amire csak 1 db találat volt, és az sem releváns

Jaj, mert elirtam :] SN74HCT244

Azt azonban nem tudom elképzelni, hogy szoftverből hogyan tudom elengedni az output adatbiteket?

Erre is van GPIO-konfiguracios bit. A legegyszerubb ha output-bol input-ot csinalsz :) Legalabbis STM32F* sorozatban igy kell. 

Igen, az is jo, de annak nehezebb a huzalozasa. Az valojaban ket darab quad tri-state buffer, ellentetes iranyban betokozva az ic-tokba. 

Hat, igen, jo kerdes hogy ezeken az SN74xx-eken most mennyi pupukoint szamolnak. Van meg raktaron a nagyobb disztributoroknal, a kisebbeknel ez se nagyon... 

Lehet, nem használnék buszmeghajtót. RL lefutó élre IT-t kérnék, címet olvasnék, ha kell, shiftelnék, maszkolnék, adatot előszednék, portra tennék, portot kiforgatnék. Zárt ciklusban várnék, amíg RL alacsony szintű. Ha RL magas lesz, azonnal portot beforgatnék, majd IT-ből visszatérnék. Lehet, hogy assembly-ben kellene írni, például a port beforgatására fel lehet készülni konstans regiszterbe töltésével a várakozás előtt, hogy RL magassá válása után nagyon gyorsan beforgassuk a portot.

Szerk.: IT elején mindenféle software-es státusz mentésre nem igazán van idő, tehát vagy assembly legyen a kód, vagy mázlink van, s az ESP megoldja hardware-ből - nem tudom, nem ismerem -, vagy le kell róla beszélni a C fordítót. Státusz elbarmolása nem baj, az alapszinten egy üres cikluson, esetleg valamiféle idle-n kívül nincs más.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem rossz. Csak kerdes egyreszt hogy az  IT mennyibe kerul (ez baromira architektura-fuggo, AVR-ben rohadt olcso, ARM-ben elegge draga, ESP-t nem ismerem). Viszont nem teljesen jo az algoritmus sem, hiszen aszinkoron ROM-nal megteheted azt hogy az /RL alacsony tartasa mellett valtoztatod a cimvezeteken a cimet. Es az sem kizart hogy a C64 el is ezzel a lehetoseggel. Ha egy instruction pipeline lennek akkor biztos elnek ezzel.

Igen, amit írsz, az valós probléma. 6502-t, 6510-et nem ismerem. Z80-on lenne gap, mert egymást követő read ciklusok esetén is emlékeim szerint fél órajelre meg fog szűnni az -MREQ és -RD. Meg kell nézni, mi a helyzet a 6502-vel, illetve van e benne DMA, mert ott nagyobb eséllyel lehet burst-ös read. Akkor kell a címvezetékekre egy I/O change detektálás, és ilyenkor vissza kell zavarni az elejére.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ne feledd el, hogy MCU core clock != periféria IO clock (van maximális határ).
Párhuzamos buszos rendszerben a memória adatlapja alapján ilyesmi szekvencia szükséges:
C64 a master
Cím fix a buszon.
Chip select aktív lesz.
Ekkor IT-ből el kell kapnod a címet (13bit, kikeresned a tömbödből az adatot, kitenni a portra)
Kimenetek beállítása,
Buszmeghajtót aktiválni az adatbuszra.
Chip select passzív lesz,
Ekkor azonnal le kell válni a buszról (Tristate, buszmeghajtó elenged)

Arra kell nagyon figyelni, hogy erre mennyi időd van. Nem mondom hogy lehetetlen, de könnyű elrontani, s az sem biztos, hogy elméleti síkon az ESP32 elég gyors ehhez. Elég 1x lecsúszni az időablakot, mást fog kapni a C64, vagy a következő memória olvasásba rondít bele, egy kint maradt adat. (Vagy esetleg kinyírható vele egy két másik kapuic, ami ilyenkor szembedolgozhat az adatbuszon (H és L szint egyszerre ráeröltetés).

A tönkremenetel nem valószínű, a FET-eknek van csatorna ellenállása, nem lesz merev zárlat. Nyilván, ha hibázik az ESP-vel, fejre áll a C64, ez természetes. Ha elég gyors az ESP, felesleges a buszmeghajtó, ha viszont használ buszmeghajtót, akkor az RL-lel kell vezérelnie a tri-state meghajtókat, de az RL megy az ESP-be is triggernek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ekkor azonnal le kell válni a buszról (Tristate, buszmeghajtó elenged)

Pontosabban: akkor kell levalni a buszrol ha a master azt mondja hogy valj le. Nem biztos hogy egy periferia/ram io/clock ideig kell neki az adat, siman lehet ottan valami apro trukk (wait state, stall, ...).

En ugy csinalnam full sw-bol hogy megnezem azt az input bit-et ami az /RL-hez tartozik, azalapjan engedem/letiltom az outputokat, majd utana johet a tombozes es a data output-ok kihajtasa. 

Több idő, míg kiolvasom a 13 címbitet, és egy indexet csinálok belőle, de ezen még dolgozom.

Nem tudom, hány bites portjai vannak az ESP-nek. Ha 8, akkor két olvasásból, egy shiftelésből és egy maszkolásból megvan az index. Ha legalább 16, akkor egy olvasás és egy maszkolás.

Izgalmasabb probléma, hogy honnan veszed észre, változott a cím? Bár szoktak lenni az MCU-kban port change status bitek illetve megszakítások lenni. Vélhetően RL lefutó élére elegendő triggerelni, ekkor címet olvasni, adatot elhozni táblázatból, portra kitenni, portot kiforgatni kimenetként. RL felfutó élére pedig portot bemenet irányba kell forgatni, az idő többi részében idle. A lényeg, hogy RL változása után viszont borzasztó gyorsnak kell lenni. Rövid kód, de az feszes.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( nehai v | 2022. 01. 31., h – 09:57 )

Szerintem sebességre biztosan elég lesz. Egy 150MHz-re húzott STM32F103 képes egy komplett SID emulációra amiben ugye benne van a cím és adatbusz kezelés is.

Az STM32 jobb választás lenne az ESP helyett, mert nem kell foglalkozni a szint illesztéssel a 5V toleráns IO-k miatt.

Igazi nagyágyú C64 IC-k emulálására a Cypress PSOC5 LP sorozata. Eleve képes 5V-ról is működni, továbbra van benne többek között egy CPLD is, amivel nagyon könnyű megcsinálni a pl. busz kezeléseket is. Akár egy Action Replay cartridge-t is csinálhatsz belőle.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Csak epromégetőm nincs, és ahogy néztem drágább annál, mintsem amit játszáshoz költenék rá. De ez a szoftver emuláció érdekes, és jobban meg is érthetem belőle, hogyan is zajlik ténylegesen a folyamat... Ráadásul ESP-m van itthon ...

Amúgy ha már EPROM, akkor EEPROM, de ahhoz is csak drága égetőket találtam, amit nem is igazán értek. Serial EEPROM egy 5V-tos SOC használatával égethető, a párhuzamoshoz meg ilyen bonyolult szerkezet kell ... Így ebbe az irányba nem indultam el.

Az EPROM égetés nem egy bonyolult protokoll. Középiskolás koromban ZX Spectrumhoz terveztem és építettem EPROM-égetőt, amelyet aztán használtam is. Fejből írom, de kb olyasmi, hogy a Vpp-re valami nagyobb feszültséget kell kötni, 25V vagy kevesebb, katalógus megmondja. Utána cím, adat, húzni kell talán -WR-ot hozzá, várni adott időt. Ha gyors akarsz lenni, 1 ms-onként visszaolvasod, sikerült-e, majd ha igen, utána még ráégetsz néhány ms-ig, veszed a következő címet, és így tovább. Végén visszaellenőrzöd az egészet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak epromégetőm nincs

Már én sem szívesen törnék össze higanygőz lámpát, hogy legyen UV a törléshez. Szerencsére van a 2732 és hasonló klasszikus EPROMokkal teljesen lábkompatibilis EEPROM. Persze a felprogramozásához kell egy mikrovezérlő GPIO-ja, netán egy Raspberry GPIO-ja. Utóbbira itt egy ajánlott látkiosztás: https://content.instructables.com/ORIG/FCC/7C1L/I6HSD23P/FCC7C1LI6HSD23…
És a szoftverek is a cikkben megtalálhatóak: https://www.instructables.com/Raspberry-Pi-Python-EEPROM-Programmer/

A mi időnkben nem voltak kész függvénykönyvtárak, software-ek, azt magunknak kellett magírni a saját tervezésű hardware-hez. A mai napig utálok kész függvénykönyvtárakat, programokat használni, mert úgy érzem, mire megértem azok használatát, addig megírom az egészet magam. Ráadásul az idegen software tartalmazhat bugot, vagy ha valamit nem jól értettem meg, rosszul használom, nem a várt eredmény lesz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem sem erdemes masok fuggvenykonyvtarait hasznalni. En pl. a multkor artam rajzolni es kepet, de szerintem a Gimp tele van hibakkal, szoval inkabb egy kepszerkesztot tervezek irni, igy nem kell hozza hasznalnom a masok altal megirt bitmap konverzios meg ki tudja meg milyen fuggvenyeket sem. Viszont szerintem a C forditok is tele vannak bugokkal, igy arra gondoltam, hogy inkabb assemblyben irom meg elosszor (a C forditot), de errol letettem, mert ki tudja hogyan ertelmezi az assembly a mnemonikokat, szoval szerintem gepi kodon kivul nem erdemes masban irni. De ekkor felmerult bennem, hogy a CPU-ban meg a periferiakban is lehet tervezesi hiba, szoval talan VHDL-ben kellene megoldani - viszont VHDL fordito sincs hiba nelkult, ki tudja mit szintetizalniek le, tehat vegul is a megoldas, hogy tranzisztorokbol, ellenallasokbol, kondenzatorokbol osszeforrasztom (mondjuk meg keresem a megfelelo ont, mert abbol is vannak silanyabb minoseguek). Szerintem hamarabb kesz leszek, mintha a Gimpet felinstallalnam.

:-P

/sza2

Digital? Every idiot can count to one - Bob Widlar

Felreertes ne essek, pont az az ember vagyok, aki szeret a "dolgok melyere latni" - raadasul a munkambol adodoan ez muszaj is. Viszont atesni a lo masik oldalara szinten egy dolog. Amig 100 eve egy kepzett ember elegge le tudott latni a muszaki tudomanyok melyere, manapsag meg feluletes tudast is nehez lenne osszegyujteni minden teruleten mert annyira sokretu lett.

> A mai napig utálok kész függvénykönyvtárakat, programokat használni, mert úgy érzem, mire megértem azok használatát, addig megírom az egészet magam.
Ez azert egy eleg eros mondat.

> Ráadásul az idegen software tartalmazhat bugot,
Csak az idegen software tartalmazhat bugot?

Nyilvan van az a szint ahol az ember meg kepes sajat maga megcsinalni amit szeretne, de amikor a komfortzonajan kivul esik, nem biztos hogy lesz ertelme "alulrol" felepiteni az egeszet. Ha jol tudom, Locsemege kollega is hasznal OpenWRT-t es nem sajat maga irja NAT hardware acceleratort vagy az IPv6 DHCP szervert. Pedig ugye az is csak egy embedded rendszer, amikhez allitolag ert.

Raadasul, azt gondolja, hogy a mit o ir, az jobb mint amit mas (lasd: "idegen software tartalmazhat bugot"). De mi van ha megsem o a legtokeletesebb programozo / aramkor- es NYAK-tervezo?

/sza2

Digital? Every idiot can count to one - Bob Widlar

Értem az iróniát, persze az sem baj, ha te is érted, mit akartam mondani. ;) Ha már itt tartunk, találtam Z80 CPU-ban hardware bugot annak idején. Ha menteni akarod, hogy az IT tiltva vagy engedélyezve van, az LD A, I utasítással a P/V flagbe tudod tenni. Utána DI, a kritikus kód, majd a végén P/V-től függően vagy átugorjuk az EI-t, vagy nem. Eddig egyszerű, de ha épp az LD A, I alatt jön az IT, az IT kérelem már tiltja az IT-t - a kelleténél korábban, az LD A, I még végrehajtás alatt van, ez a bug -, ennélfogva P/V-be 0 másolódik. Az IT végrehajtódik, annak végén EI, RETI - vagy RET -, majd itt az alapprogramban egyből DI. Jön a kritikus kód, majd a P/V alapján nem engedélyezzük az IT-t, hanem helytelenül tiltva marad - örökre. Vagy legalább is EI utasításig, de olyan várhatóan nem lesz. Szóval valójában kétszer kell LD A, I, tárolni kell mindkét értéket, majd a végén némi logika - OR kapcsolat - a tárolt értékek alapján.

Arra gondoltam, hogy egy valaki más által megírt bit bang RS232 stack felhasználása valószínűleg sokkal több szívással jár, mint elölről megírni egyet. Eleve lehet, hogy valamit speciálisan csinálhatsz, nem kell nagyon általánosra. Másrészt amíg más programját belegyógyítod a saját kódodba, nem kevés idő. Mire megérted, hogyan működik, talán megcsináltad sokkal jobban saját magad. Külső kód még csak optimális sem lesz a saját környezetedben.

Nem azt mondtam, hogy ne használjunk oprendszert meg glibc-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jo, nyilvan attol fugg, hogy mit csinal az ember. Szerintem is rengeteg esetben van, ahol van letjogosultsaga a sajat kodnak, mashol meg celszerubb a keszet hasznalni - alkamazasa valogatja.

Ami nekem nem jon be, elutasitani a kulso kod hasznalatat, "mert az biztos rossz" alapon.

/sza2

Digital? Every idiot can count to one - Bob Widlar

A fentebbi hozzászólásodra is válaszolok. A postom rövid és általánosító volt valóban. Távol álljon tőlem, hogy USB stacket implementáljak, egyedül a mid layerébe folytam bele, s írtam teljesen újra az állapotautomatáját az igényem szerint forgatott prioritású, több buffer kezelésére. Most ez egy konkrét eset, munka. És nyilván az is igaz, hogy én is írhatok bugot kódba, csak a saját kódomhoz bátrabban nyúlok, mert tudom, mi a rafinált trükközés, és mi a bug. Idegen kódban találok valamit, amit bugnak gondolok, átírom, majd még hét helyen esik szét az egész, mert az valami nyakatekert varázslás volt. Még az is lehet, hogy tényleg megtaláltam a hibát, de a javítása sokfelé kihat. Meg nyilván nem fogok full assembly-ben nulláról router firmware-t írni, ehhez egy élet kevés lenne, meg iszonyú mennyiségű mérnökóra van már ezekben a software-ekben, amit ennélfogva képtelenség is kidobni.

Viszonylag egyszerűbb esetekben szeretem a saját megoldásokat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Néhány hasznos cucc.a témában:

HUF 8,099.21  5%OFF | 100% Original Newest TL866II Plus Universal Programmer High speed Programmer with Full Adapters + SPI +test Clip PIC Bios
https://a.aliexpress.com/_mL6Rimc

HUF 1,212.24  5%OFF | 5PCS/ 10PCS M27C256-10F1 M27C256B-10F1 M27C256 27C256  M27C256B DIP28 IC EPROM UV 256KBIT 100NS Memory Chips best Quality used
https://a.aliexpress.com/_mLaqcZ6

HUF 7,025.70  16%OFF | High Speed Ultraviolet Eraser Light Erasable Timer Semiconductor Wafer Erase Radiation  
https://a.aliexpress.com/_mrsT8Yo

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Off: Ali napjainkban igencsak belassult. Fénykorában 3 hét alatt volt itt szinte minden, most 2 .. 2,5 hónap. Még mindig úton vannak az október végén rendelt karácsony előttre igért dolgaim. Még hetek kérdése és ideér a vége is.

A minőségi alkatrész kereskedésekben a félvezetőhiány gyöngyszemei szintén kijózanítóak:

Farnell AT27C256R-70PU

Covid előtt 24 óra volt a szállítás. Ma...

7 048 több lesz elérhető ekkor: 2023.01.04.
8 008 több lesz elérhető ekkor: 2023.03.07.

Farnell AT28C256-15PU

51 több lesz elérhető ekkor: 2022.06.28.
504 több lesz elérhető ekkor: 2022.12.15.

NINCS. Várjál türelemmel.

Amit belinkeltél programozó, annál csak a header-ek kerülnek 8000 Ft-ba, a TL866II programozó 19-20 ezer körül van. Azért szúrt szemet az alacsony ár, mert nemrég vettem. De építettem is saját programozót, mert a régi 21V és nagyobb programozófeszültségű EPROM-okat nem tudja programozni alapból a TL866II+, max. 18V VPP-t tud adni. Kis trükközéssel rá lehet bírni, hogy nagyob feszt kapjon az IC.

A használt EPROM/EEPROM-okról annyit, hogy általában régi masinákból emelik ki őket. A chip-et visszaolvasva látszódik, hogy S3 Trio 64 BIOS és ehhez hasonlók vannak bennük. Vélhetően a gyárban 1x felprogramozták és nem voltak sokszor törölve, tehát nem kell attól tartani, hogy agyonhasznált IC-t kap az ember. De szerintem nem is tesztelik őket, vagyis azért mégis zsákbamacska. Nekem eddig az E(E)PROM-okkal szerencsém volt...

Ja, tudom, én is ilyet rendeltem, pont azért linkeltem mert programozó (bár régebben vettem, akkor olcsóbb volt (without áfa) és egy rakat headerrel együtt vettem kb ennyiért) . Az eprom/eeprom-ok egy resze valóban bontott, de jó állapotú, ilyen célra símán használható. 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Egyébként C64-re STM32-vel csináltak már cartridge-ot, kungfuflash-nek hívják. Csak ellenállások vannak az adatbusz felé. Én utánépítettem és nagyon jól működik.

Kapcs.rajz: https://github.com/KimJorgensen/KungFuFlash/blob/master/hardware/KungFu…

Ja, és az STM32F405 beszerzése tényleg nem egyszerű...

Ez egy igen inkorrekt megoldás, bár a ZX Spectrumban is csinálták. Ott a memóriát a CPU ellenállásokon keresztül érte el, az ULA közvetlenül. Ha video hozzáférés kellett, az ULA megállította a CPU órajelét, közvetlenül címezte a RAM-ot, ha pedig nem volt erre szükség, lecuppant a címbuszról, a CPU pedig az ellenállások túlvégéről adta a RAM címet. Legalább is, ha jól emlékszem. Borzalmasan gány megoldás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Rossz ez a világ. Ma már mindent meg lehet kapni készen, de minimum nagyobb modulokból összerakhatóan. Elvették az alkotás örömét. Valahol az is ijesztő, hogy hardware fejlesztő létemre évek óta nem csináltam semmit magamnak, pedig értek hozzá. Beérem a tudattal, hogy meg tudnám csinálni. Elég a kihívás a munkahelyemen, a szabadidőmben inkább csinálunk valami finom kaját, megesszük egy-egy pohár bor mellett, kirándulni megyünk. A szakmai alkotás örömére elég a munka.

Még is mi a fenét csináljak? Villogtassak LED-eket mikrokontrollerrel? Rém izgalmas.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt a gondolatot én is rendszeresen végigvezettem. Most kb. addig megy el részemről, hogy a 8. osztályba járó gyermekemnek átadok alapfogásokat, de csak ami érdekli.
Kb. iskolai fizikatanár módjára modellezzünk le egy rádióvevőt szó szerint kötözgetett deszkamodellen. Ezekből akárcsak egyetlen darabként elkészülő dobozos cucc soha nem lesz. Marad deszkamodellnek.

"Még is mi a fenét csináljak? Villogtassak LED-eket mikrokontrollerrel?"

Már van: HUF 809.46 | DIY Electronic Kit Heart Shape Colorful LED Module Love Water Light STC89C52 Parts & Components
https://a.aliexpress.com/_mObBrEo

:)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Meglatasom ugyanez. Legyen szo foallasu fejlesztesrol vagy hobbi projektrol. Fejben le tudom jatszani, nincs ertelme meg is csinalni. Korabban kaptam dicseretet erte, de mar elmult. El lehetett adni, de a tomegtermeles es kina megolt minden diy es kisszerias dolgot. Foleg a market-maker dolgokat, azaz en talalnek ki valamit. Tok jo dolgokat tudnek epiteni:  uszadekfabol vilagitas, led dizajn lampa. De csak csalad szinten mukodik. Semmire nem koltenek, nekem meg nem fer bele idoben a marketing. 

Meg kiegeszitesnak annyit, hogy a technologia fejlodese is megoli a hobbit. Manapsag egy csomo alkatresz csak iparilag ultetheto / forraszthato be. Otthon nem fogsz BGA, CSP meg egyeb (hobbistaknak) egzotikus tokozast forrasztgatni.

Egyik kedvencem a sajat MGM13S modulunk (130. oldal) - stencillel, (kezi) beultetogeppel, kemencevel tamogatva is dobaltak ki az elso boardokat a kollegaim, kellett jo par proba, mire sikerult rovidzar nelkul, de minden pad-hez csatlakozva beultetni...

Persze nem azt mondom, hogy ne fejlodjon a vilag, az a dolga, de egyre kevesbe lehet otthon butykolni. Ez mar nem a Quad 405 forrasztasa pillanatpakaval korszak ;-)

/sza2

Digital? Every idiot can count to one - Bob Widlar

Sajnos ez is igaz. Én még cégesen is kerülöm a DFN, BGA és efféle őrületeket, mert úgyis csak selejt gyártás lesz belőle. Kell a fenének. Amit el lehet rontani, azt el is rontják. Maradok a TQFP, TSSOP, MSOP, SOT, SO, meg efféle tokoknál, hogy legalább ónszippantó fonott rézszalaggal lehessen rajta segíteni, ha baj van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE