Keresés

Részletes keresés

György barát Creative Commons License 2020.03.03 0 0 9532

Ha több RAM-ba több programot teszek, akkor azokat csak külön-külön futtathatom (mindet az elejéről). 

 

Ellenben minden programnak a (füzér- és szám-) változóit elhelyezhetem egy tetszőleges RAM szeletre. 

 

Előzmény: siz (9530)
ergoGnomik Creative Commons License 2020.03.03 0 0 9531

Én úgy értettem azt akarja csinálni, hogy a KERNAL rendszer inicializáláskor minden 64 k-s lapra, azonos címre beír valahová kódot, amivel kezelni tudja az átváltást a memóriatartományok között. Valami olyasmit, hogy felkészülés lapváltásra; LDA #lapszám; STA lapregiszter; kód ami kezeli hogy "átesett" egy másik lapról. De így legfeljebb a két index regiszterben meg talán a veremmutatóban tud adatot átvinni a lapok között, ami soványkának tűnik.

Előzmény: siz (9530)
siz Creative Commons License 2020.03.03 0 0 9530

Majd még azt áruld el, hogy ha memória lapozást csak ROM-ból lehet végezni (mert az egész RAM-ot kirántod alóla), akkor milyen szoftverrel fogod használni a bővítést? Betöltesz egy programot, meghívod a ROM-ot, hogy lapozza el a RAM-ot, aztán ... ? "Eltűnt" minden, amit betöltöttél.

Előzmény: György barát (9529)
György barát Creative Commons License 2020.03.03 0 0 9529

[9528]: értettem elsőre is. 

 

Tegnap még kacifántot emlegettem, de már pedzettem a megoldást. Elalvás előtt aztán meg is találtam. Így minden külső "lepedő" azonos értékű a beépített memóriával. 

Ma reggel pedig – a szükséges koffein- és nikotinszint elérése után kitaláltam a vetítés módját is. (Ennek ellenére nem látok semmi fantáziát a kütyümben.) 

 

[9527]: 

1. A KERNAL módosítása nem jelent gondot (csak az EPROM-égető hiánya). Lubickolnék a témában. 

2. A gurukkal természetesen össze kéne jönnöm, a két I/O címet már kiválasztottam. 

3. A verem: lapozás előtt a veremmutatót le kell tenni az aktuális nullás lapnak egy üres címére. Visszatéréskor fölvenni. A belapozott memó szeleten új, teljes értékű verem van, a saját veremmutatóját kezelni kell. 

4. Az NMI hiánya egyszerűsíti a helyzetet. Az IRQ pedig egy SEI, CLI opkód párossal elintézhető. (IRQ tiltás, megengedés.) 

+. A ROM-bővítőm "szépsége" az 1985-ös színvonal. Nincs benne semmi a későbbi évekből. 

 

 

Előzmény: ergoGnomik (9527)
ergoGnomik Creative Commons License 2020.03.03 0 0 9528

Az új nullás SZVSZ lap Helyesen: Az új nullás lap SZVSZ

Előzmény: ergoGnomik (9527)
ergoGnomik Creative Commons License 2020.03.03 0 0 9527

Nos, ennek a programozási modellje eléggé közelíti a rémálom kategóriát. Szükségtelenül rugalmatlan a rendszer, az egyes memóriaterületek közötti nagyobb tömegű adatmozgatás hatékonysága valószínűleg elképesztően alacsony, ráadásul módosítani kell hozzá a KERNAL-t is, hogy egyáltalán használni lehessen.

 

A gép úgy működik, hogy minden busz órajel ciklusban van kettő memória hozzáférés (a [7|8]360 és a [7|8]501 minden ciklusban mindig végez memória műveletet!), amit a TED vezérel. Azt mindig lehet tudni, hogy melyik aktív eszköz óhajt a buszhoz férni, mert az órajel egyik fele a TED-nek van fenntartva, a másik felén a TED és a CPU osztozik aszerint, hogy a CPU /AEC bemenetét a TED éppen milyen szinttel hajtja. Éppen ezért igazából teljesen szabadon és függetlenül lehet konfigurálni mindkettő számára a 64 kilobájtos memória "ablakot", hogy melyik részén egy nagyobb tárterület melyik részét lássák. A régi belső bővítők ezt úgy használták ki, hogy a natív címteret felosztották 16 kB-os szeletekre, és azokba bizonyos szabályok szerint kiválasztották egy 256 kB-os bővített címtér négy 16 kB-os szeletét. A megvalósítások kapcsolási rajzait még fel lehet lelni az interneten. Az egyik ilyen emlékeim szerint szinte csupa 74-es sorozatú logikai IC-kből van felépítve, a másikban főként egy GAL-ra van építve a rendszer, aminek a logikai programját is dokumentálta a készítő.

 

Elvileg a feladat annyi lenne, hogy ezt a megoldást kombinálod a 64kB-os külső memóriabővítők adatbusz "eltérítő" megoldásával, és kinézel (esetleg konzultálsz erről a hardver gurukkal) az I/O címtartományból a vezérlésnek néhány címet.

 

Ja. És a procy adat- meg adatirány regiszterét sem írom, olvasom. Az új memóriában viszont megint elérem. Van új nullás lap is. Ellenben a veremhasználat nem célszerű - az NMI miatt. 

 

Az elég meglepő lenne, ha az új memóriában nem érnéd el a processzor integrált portját. Az új nullás SZVSZ lap csak akkor előny, ha rugalmasan tudod konfigurálni a memóriát. Másként inkább hátrány. A verem használat* nem az NMI miatt nem célszerű, mivel ilyen nincsen a rendszerben, hanem mert azt is folyton ellapozod. De éppen ezért megszakítást (IRQ) sem érdemes csak igen megfontoltan használni. *Ami – lássuk be – megint csak elég "érdekes" programozási stílust igényel.

Előzmény: György barát (9522)
MMSZoli2 Creative Commons License 2020.03.02 0 0 9526

A teljes 64K-t nem lehet és nem szabad kicserélni, mert vannak benne a rendszer által használt címek, épp milyen állapotban leledzik a rendszer.
Ha a teljes 64K-t kicseréled egy teljesen új üresre, az összes pl- kernal által épp használt memória tartalma megy a levesbe, és vélhetően összeomlik a gép.

 

Szerintem kicsit olyannak érzem, mintha kirúgnád alóla a lábát, de lehet hogy csak én nem értek valamit, nem vagyok szaki :-)

 

A PC-n elérhető és említett EMS nem egy rossz megoldás, és a Plus/4-en is 16K-s laponként be lehet lapozni a ROM helyére anyagokat a Hannes megoldás szerint (ha jól tudom)

A ROM helyére való belapozás és onnan való kép/videó megmutatása baromi gyors, egy külső MMU megcsinálhatja.
Ha nem FLI üzemmódban vagy, a processzornak gyakorlatilag semmi dolga, a TED mutatja a multi vagy hires képet, mögötte meg pedig a külső egység baromi gyorsan cserélgeti e képet.

(Az adott címre másolást a külső eszköz a 8501-től függetlenül csinálhatja  saját sebessége alapján, figyelve arra, hogy amikor a kereten van a TED, akkor legyen frissítve a kép)

 

Persze nem fog úgy kinézni, mint a MicroMorph0s1s, vagy az Evo Lution, de ha mozog a kép, vagfy gyorsan váltakozik, a szem kevésbé észleli a hibákat.


Írható memória esetén persze a sebesség is más, de pl. a GeoRAM a C64-en se túl gyors (viszont a méretéhez képest olcsó volt).

https://vintageisthenewold.com/rc2018-04-4mb-georam-development-part-1/

MMSZoli2 Creative Commons License 2020.03.02 0 0 9525

"Gonoszkodom, tehát vagyok" :-)  
Egyébként nem volt igazán semmi hozzáadott értéke, csak egy gyengébb viccecskének szántam. Elnézést!

Nos, egy kicsit értelmesebb dolog:


Gyerekkoromban Commodore 16-al kezdtem, és személy szerint sokkal jobban szerettem a klattyogós billentyűzetét, mint a Plus/4-ét, ami a havernak volt a szomszéd házban.
(A gyári tápegysége a C16nak viszont egy olcsó hulladék az alultervezett graetz híddal, amikor már 64K memória volt benne, kétszer is megpunnyadt)
Most már talán ki lehet jelenteni, hogy a billentyűzete tartósabb, mint a Plus/4-é, és a melegedés szempontjából is kedvezőbb a szellős ház, főképp ha egy tartós táp van mellé biggyesztve.

Azóta, hogy a BME-n eladtam a C16+C64+sok periféria kombót egy PC-nyi pénzért, nem volt C16-om, csak Plus/4-em.

Viszont nem akartam senkinek a munkáját szaporítani (és szabadidejét csökkenteni) azzal, hogy veszek egy C16-ot, majd szívességből valakivel felbővíttetem (a külső bővítőkről meg eleget beszéltünk már)

 

Így amíg nem volt olyan 64K+ bővítés elérhető, amit nagyobb faragások nélkül én magam is be tudok rakni egy C16-ba, addig hanyagoltam a gép beszerzését.

Miért nem elég a sima C16? Vannak jó és klasszikus C16 játékok, de nekem Pigmy, TFCS és MB játékok jelentették elsősorban az igényes játékot gyerekkoromban (a többiek munkáját annyira nem ismertem).
(persze C64-en is játszottam mindenfélét, de a 264 szériához jobban kötődtem)

Az elmúlt 1-2 év elég mozgalmasan alakult a 24 hardverek szempontjából.
Így tavaly a szülinapomra beszereznem egy közel  tökéletes állapotú C16-ot dobozban (datasette-el, igaz táp nélkül) egy ismerőstől, szintén rokonlélek.

A cuccot Németországban lecsekkolták, működött, úgyhogy nagy rizikót nem vállaltam.
(a töredezett, lyukas styropolokat majd kitalálom, hogyan lehet megjavítani :-) )

Tegnap rászántam magam, hogy a Commodore 16-omat kinyissam és felbővítsem, mivel végre sikerült rendes, multiméter szerint is korrekt tápot szereznem.

Szereztem időközben (hja, költséges dolog a hobbi...):
-TED alá szerelhető 64KB-os SRAM bővítőt
-Jiffy DOS eprom a sebességért (ki tudjam használni 264-en is az SD kártyás cuccaim sebességét)  
-új PLA (ha esetleg megdöglik)
-új, kis fogyasztású BASIC EPROM (ha esetleg megdöglik)
-Lotharek 6502 alapú 8501 CPU helyettesítő + 256KB (512KB-ből ennyi látható)
-és végül egy 1.5A-es stabilizált 9V táp

Lényegében egy felextrázott és hidegebb/stabilabb C16-ot akartam összehozni (a belső microIEC meghajtó megvalósítását sem zártam még ki teljesen, van benne hely, faragni viszont nem akarok a házon. (olyan lenne, mint egy HDD :- ) )

Nagyon rá voltam izgulva a Lotharek féle 6502 kártyára, de végül nem szereltem be.
Ehhez ugyanis ki kell szedni az alaplapi memória IC-ket, és sajnos a 2 memó IC nálam nem foglaltban csücsül... Nem vállalkoztam rá, mert nincs sem ónszippantóm, de óneltávolító harisnyám (még). Jah, meg foglalatom sincs (bár nem mintha kellene). Meg baromi rosszul forrasztok, aggódtam az alaplap állapotáért. Kicsíphettem volna őket, de az ocsmányul nézett volna ki.

 Egyelőre beraktam a SRAM-ot, amihez még az eredeti RAMokat sem kell eltávolítani, ráadásul annyit emel a TED-el, hogy a EMC védő fémburkolat (ez nem aluval borított papír, hanem felcsavarozott rendes fémlemez) szinte a teljes felületen felfekszik. tettem alá egy kis Noctua hővezető pasztát (a 8501-en még nincs semmi). Beraktam a JiffyDOS-t.

 A magyar SD-1541/II-vel töltöttem be a lemezeket és programokat, a lemezes gyorstöltőkkel összeakad, máskülönben baromi gyors.

Úgyhogy 64K+gyors is. SZUPER!

Nagyon vártam, hogy a Jiffy-vel mennyire lesz gyors az SD-1541/II-m. elég gyors, de vannak furcsaságok. (majd később kifejtem, ha teszteltem egy keveset)

Egy 121 blokkos program betöltése:
-Normál:    1:05 perc
-DLOAD:    0:15 (bekapcsolt képernyő, mutatja a feltöltött memória mennyiségét)
-Jiffy:        0:14  (kikapcsolt képernyő)

 

Még annyit, hogy elég szellemképes a composit képe, az Svideo kimenet pedig tragikus. Legalábbis az én TV-men. Akikor ugyanazt a CVBS jelet egy másik kábellel SCART-ba dugtam, jobb lett egy kicsit.
Lehet, hogy a kábel? Pedig elég jónak tűnik, jó vastag az SVideo kábele.
Na mindegy, még próbálkozom a képminőség javításával.

 

A két kisebb módosítás után (JiffyDOS kapcsoló a tuner melletti gyári kivagásra került egy csepp forróragasztóval. nem szép, de legalább csúnya :-) )

 

 

 

György barát Creative Commons License 2020.03.02 0 0 9524

Ez nem egy pozitív hozzá(m)szólás.   😢 

Hol a baki, kérlek, azt írd le! 

 

Előzmény: kisbetu (9523)
kisbetu Creative Commons License 2020.03.02 0 0 9523

Az egy dolog, hogy itt kimagyarázod.

A processzornak magyarázd meg, hogy hogyan kéne működnie szerinted.

Előzmény: György barát (9522)
György barát Creative Commons License 2020.03.02 0 0 9522

Rosszul fogalmaztam. Nem "hívok be" semmit. Procy és TEDdy alatt kicserélem a lepedőt [RAM-ot]. Ezért kell a rutinokat a külsőkre kiírni. 

A CPU regiszterei nem változnak. Az utolsó "belső utasítás" beállítja a programszámlálót, ott kell lennie a folytatásnak. És fordítva - visszatéréskor. 

Elromlik a képernyő [egy műveletnyi ideig] mert a TED a kinti RAM-ot látja. Ám utána visszajön - és ki is lehet kapcsolni. 

Ha odakinn bármi programocskát akarsz futtatni, az jóval kacifántosabb, de megoldható. 

Ja. És a procy adat- meg adatirány regiszterét sem írom, olvasom. Az új memóriában viszont megint elérem. Van új nullás lap is. Ellenben a veremhasználat nem célszerű - az NMI miatt. 

 

Csak kérdezz, én kimagyarázom.   😀   Bár nem értem.   😔 

 

Előzmény: ergoGnomik (9521)
ergoGnomik Creative Commons License 2020.03.02 0 0 9521

Nem értem hogy mit szerettél volna csinálni. Mit kell azalatt érteni, hogy egy memória címre behívsz egy memóriaterületet? Ráadásul a nullás cím nagyon rossz ötlet, mert ott a processzor port adatirány regisztere van.

Előzmény: György barát (9520)
György barát Creative Commons License 2020.03.02 0 0 9520

??? 

 

Előzmény: ergoGnomik (9519)
ergoGnomik Creative Commons License 2020.03.02 0 0 9519

???

Előzmény: György barát (9518)
György barát Creative Commons License 2020.03.02 0 0 9518

0000 címre akartam behívni 64 KB-ot, a belső RAM helyett. 

Hátránya, hogy RESET-kor minden külső lapra ki kell írni az adatmozgató- és átkapcsoló rutint. [Mint a C=128-ban.] 

 

Előzmény: ergoGnomik (9517)
ergoGnomik Creative Commons License 2020.03.02 0 0 9517

Hát ezért nem építenek így ma már semmit. Ha értenék az elektronikához, akkor keresnék batár nagy SRAM-okat, valamilyen CPLD-t a logikának, és az egészet szintillesztőkkel kapcsolnám az eredeti géphez. Ez utóbbit lehet gyári tokozottat is találni, illetve vannak egyszerű tranzisztoros kapcsolások is, amiket szerte az interneten meg lehet lelni.

 

Ami viszont nem világos, az az hogy milyennek is képzeled el a bővítést. Eddig azt hittem, hogy többé-kevésbé transzparens lenne, a vezérlés nagyjából tetszőleges helyre be tudná lapozni a belső RAM helyére a külső tár szeleteit. Most meg úgy tűnik, mint ha valami PC-s EMS-re hajazó dolgot terveztél volna. Vagy mit értettem félre?

Előzmény: György barát (9516)
György barát Creative Commons License 2020.03.02 0 0 9516

Szevasztok! 

 

Péntekre összeállt [a fejemben] a külső dRAM bővítőm. Ám végtelen szomorúsággal olvastam, köztetek nemhogy labdába rúghatnék, de még szedegető sem lehetek. A kütyüm csak a beépített memóriával együtt teszi ki a ... 16 MB-ot.     :-( 

 

És jött a hétvége. Az agyam kitisztult [az alkoholos átmosás után].     :-)

Mire is lenne jó ez az EXTRAM? 

– Nincs az az eszement programozó, aki gépi kódú rutinokkal teleírná. 

– Elhelyezhető [lenne] 1500 színes vagy 1800 fe-fe kép. Ezek moziban 60~70 másodpercet adnak. Ám hol az a DMA, amely a 1,8~2,0 MHz órajelen vetíteni tudná? 

– Marad[na] a képregény. Csakhogy, ott van éppen elég idő lemezről töltögetni a következőt [miközben a monitoron lévőt az olvasó/néző földolgozza]. "GETKEY"-re címváltás. A lemezcsere is rövidebb, mint gyerekkoromban a Füles jővő heti érkezése. 

– Még egy kis "apróság": a NYÁK íróasztal méretű, az alkatrészek száma ezres nagyságrendű [még akkor is, ha az eredeti 4164-eseket 4464-esekkel helyettesítem], és még villanyórát is kell[ene] cseréltetni. 

 

Nos: ez volt a szovjet emberes Hold-program. 

 

Kellemes napot kívánok: 

György 

 

György barát Creative Commons License 2020.03.01 0 0 9515

A különbség egy vöDör vitriol.   😨 

 

Előzmény: ergoGnomik (9514)
ergoGnomik Creative Commons License 2020.02.29 0 0 9514

Nem értem. Mi a két állítás között a különbség? Az egyiket siz mondja saját magáról, a másikat te sizről. Az eredmény logikailag megegyezik. Sz'tem.

Előzmény: MMSZoli2 (9513)
MMSZoli2 Creative Commons License 2020.02.28 0 0 9513

> Minden általad ismert DRAM mátrix szervezésű és multiplexelt címzése  :-)

siz Creative Commons License 2020.02.28 0 0 9512

> Minden általam ismert DRAM mátrix szervezésű és multiplexelt címzése

Előzmény: siz (9511)
siz Creative Commons License 2020.02.28 0 0 9511

Ne add a szavakat a számba. :)

 

Amit mondani szerettem volna:

 

> Minden általam ismert DRAM mátrix szervezésű

Előzmény: Törölt nick (9510)
Törölt nick Creative Commons License 2020.02.28 0 0 9510

Amit mondani szerettél volna, helyesen:

 

A "legtöbb" hagyományos(!) DRAM multiplexelt címzésű :) 

 

Valójában minden nagyobb memóriachip belül mátrix szervezésű. A romok promok és sram-ok is.

 

Anno a kevesebb kivezetés, kisebb tok miatt (is) alakult ez a ram-oknál így, illetve a frissítésnél is kedvezőbb valamelyest.

 

Később már "így maradt", ..és bizony, ebben a "kisgépes korszakban" sokszor teljes elmebaj  ez.

Plusz alkatrészek, sorrendi dram vezérlő logikák, multiplexerek amiatt, ami végül összesen sokkal jelentősebb költség, mérnöki ráfordítás, mint a dram gyártónak több kivezetés, nagyobb tok, más külső címzési logika lenne.

 

Azután a chipsetek (és ez még nem PC, lehet korai amiga vagy atari vagy bármi) kvázi áltlánossá válásával megint kedvezőbb volt a kevesebb címvonal, kevesebb nyákterület, kivezetés, kontakthiba-lehetőség, a szükséges logika meg úgyis a chipset teljes bonyolult "lelkének" tizezered, százezered része, nincs számottevő jelentősége, költsége.

 

Előzmény: siz (9509)
siz Creative Commons License 2020.02.27 0 0 9509

Nem terveztek mást. Minden DRAM mátrix szervezésű, ahol előbb oszlopot majd sort kell választani. A multiplexerek csak eldöntik, hogy éppen melyiket kell címezni.

Előzmény: György barát (9508)
György barát Creative Commons License 2020.02.27 0 0 9508

Teória: 

 

A Négyeskében használt RAM-ok belső szervezése miatt az U9-U10 testvérek össze-vissza kócolják a biteket. 

A CPU viszont párhuzamosan tolja azokat. (Fölteszem, más RAM-okat terveztek eredetileg.) 

 

 

Előzmény: ergoGnomik (9506)
IEC-ATA Creative Commons License 2020.02.27 0 0 9507

Igen, ez nekem is megvan! 

Előzmény: siz (9505)
ergoGnomik Creative Commons License 2020.02.27 0 0 9506

Miért tenne ilyet? Erre való az U9 és U10 multiplexer. Vagy nem?

Előzmény: György barát (9504)
siz Creative Commons License 2020.02.27 0 0 9505

Nekem egy ilyen poszt van bekönyvjelzőzve a témában: https://forum.index.hu/Article/viewArticle?a=128478516&t=9006036

 

Előzmény: IEC-ATA (9503)
György barát Creative Commons License 2020.02.27 0 0 9504

(TED) MUX > (CPU) GATE IN 

 

Ennek hatására tolja a proci a fölső címbájtot A0-A7-be (RAM műveletnél).

 

IEC-ATA Creative Commons License 2020.02.27 0 0 9503

A Gate-in jelről lehet egyáltalán bárhol olvasni valamit. A nagy Plus/4-es könyvben csak egy odavetett mondatra emlékszem, ami nekem nem mondott sokat, igaz én nem is értek hozzá. Mondjuk meg lehetne szkópolni, hogy van-e egyáltalán rajta bármi, és az vajon milyen viszonyban van a többi vezérlőjellel?

 

Ez van a nagykönyvben:

Ráakasztom a gépre a logikai analizátort aztán megnézem! :-)

Előzmény: ergoGnomik (9497)

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!