Azon túl, hogy ez itt témaidegen, úgy gondolom a VDC alá kell betenni, és nincs szükség más módosításra. Ennek SaRuMan-VDC a neve. Meg kellene keresned a kitalálóját és vele egyeztetni a továbbfejlesztésről.
Nem volt övön aluli, mert nem a Z80 és a blokk mozgatási képessége volt a téma, hanem a rugalmas memória lapozás. Azt meg mindegy milyen processzoros rendszerben valósítják meg, a lényeg a memória szabad átszervezhetősége.
Egyébként bár nem vagyok teljesen képben a Z80 programozásával, de egyszer mintha olvastam volna valahol olyasmit, hogy a blokkmozgató utasításoknál lehet gyorsabbat írni, és ott is talán a PUSH-sal trükköztek valamit.
Speed kód alatt általában azt értjük, amikor a rendszerint ciklusba szervezett műveleteket "kigörgetjük" (unrolled loop), vagyis a ciklus magot többször (sokszor) egymás után lekódolod úgy, hogy a ciklusszervezésre "elpocsékolt" időt megspórold.
A C=128-ban kijelölheted, hogy a 2×64 KB memóriának valamennyi része közös legyen. De a nullás lap és a verem áthelyezésére nem emlékszem. Ugyanúgy a speed kódra sem. Írnál ezekről néhány mondatot? (!!!)
Ellenben az 1750-es bővítőben a DMA gyorsan tölt, ment, cserél. Ugyancsak érdemes átkapcsolni a beépített Zilogra, ha nagyobb területet akarsz mozgatni (és nincs bővítőd). Ha pedig 128R féle géped van, akkor a VDC-ben is tudsz egynéhány képet váltogatni.
A fadados módszert (hogy az egész 64K-t átkapcsolja cakkumpakk) a CBM-II sorozatban használták, és nem véletlen nem vált be. Építettek köréje egy nyakatekert Kernal-szintű környezetet, ami 2-4 bankkal eléggé jól elboldogul a Basic interpreter céljaira (az egyes változótípusokat szétosztja ez egyes bankokba, így csak a Basic programkódnak fennmarad egy teljes 64K egyben), de azon kívül bármilyen más célra alkalmazni rémálom.
Azonban a C128-ban ehhez képest rengeteget finomítottak, és ott nagyon rugalmasan kihasználható - viszont ahhoz pedig kellett már egy komplett MMU vezérlőchip, ami nagyon bonyolult. Azzal megteheted például, hogy a nulláslapot átirányítod az egyik bankba, a vermet meg egy másikba, majd azután LDA $xx / PHA utasításpárokkal és speed kóddal egész gyorsan lehet adatokat mozgatni a kettő közt (vagy a képernyőt is átteheted másik bankba stb.). Programozás szempontjából csúcs, ám igen komoly hardverháttér dolgozik meg érte mögötte.
Hát, a Hannes bővítő gyakorlatilag egy-az-egyben a C64-es +240k bővítés plus/4 implementációja. Anno inkább az volt a szempont, hogy minél kevesebb TTL áramkörből kihozzák.
Jah, megint tanultam pár dolgot, köszi Mindenkinek!
A teljes 512K -nak külön örülök, majd lehet hogy összehozok egy képnézegetőt a Conan képregényből, ami az egyik első (nem túl sikeres) slideshow próbálkozásom volt :-) (még mindig sokkol, hogy mint az Apple Macintosh, mind az Atari ST ennél kevesebb memóriával került a piacra az indulásnál, de talán az Amiga 1000 is)
(egyébként leszámítva a Lotharek cuccot, nem került olyan sokba a dolog (ami azért egy elég fájó pontot érint, szerintem a megpusztul 8501 miatt halott gépek benne vannak a top3-ban))
A RAM bővítésről:
Ha ez együtt jár egy ROM bővítéssel együtt, ami ezt az egészet lekezeli (X helyre belapozva), az ott elhelyezett dedikált rutinok el tudják végezni a műveleteket a teljes RAM csere esetén/után is. Szerintem ebben az összefüggő nagy blokkos memória felosztásban a plus/4 kifejezetten jó, nincs úgy szétnyirbálva, mint a C64-é.
Ha már kompatibilitás, Hannes/Csory és egyéb bővítések nem csak úgy ad hoc módon lettek összelapátolva, volt koncepció mi hová menjen összeakadás nélkül (a MIDI inteface azért érdekelt volna mit tud...): http://plus4world.powweb.com/kb.php?id=500249
$FD00-$FD0F ACIA-chip (6551/8551) $FD00-$FD03 Effective range for ACIA $FD03-$FD0F Mirrors of $FD00-$FD03 $FD10-$FD1F Userport 6529B-chip (original) $FD10 Effective adress for 6529B (original) $FD10-$FD1F Mirrors of $FD10 (original) $FD10-$FD1F Userport-area (plus/4 with expansion) $FD10 6529B-chip from userport $FD11-$FD12 Centronics-printerport $FD13-$FD14 Low-/high-switching for OS96 $FD15 Register for CSORY-RAM-expansion $FD16 Register for Hannes-RAM-expansion $FD17 Register for EPROM-/sRAM-expansion $FD18-$FD1F Free (best for internal expansion) $FD20-$FD2F Used by different hardware, decoded by PLA (pin 18) $FD30-$FD3F 6529B for keyboard $FD30 Effective adress for this 6529B $FD31-$FD3F Mirrors of $FD30 $FD40-$FD5F SID-card, area for SID-chip $FD40-$FD5D SID-chip $FD5E DAC on digiblaster add-on $FD5F ADC on digiblaster add-on $FD60-$FD7F Area for expansion-userport $FD60-$FD63 ACIA on card 1 $FD64-$FD67 ACIA on card 2 $FD68-$FD6B ACIA on card 3 $FD6C-$FD6F ACIA on card 4 $FD70-$FD73 6529B-emulation on card 1 $FD70 Effective adress for 6529B-emulation $FD71-$FD73 Mirrors of $FD70 $FD74-$FD77 6529B-emulation on card 2 $FD74 Effective adress for 6529B-emulation $FD75-$FD77 Mirrors of $FD74 $FD78-$FD7B 6529B-emulation on card 3 $FD78 Effective adress for 6529B-emulation $FD79-$FD7B Mirrors of $FD78 $FD7C-$FD7F 6529B-emulation on card 4 $FD7C Effective adress for 6529B-emulation $FD7D-$FD7F Mirrors of $FD7C $FD80-$FD8F Joyport on SID-card $FD80 Effective adress for joyport $FD81-$FD8F Mirrors of $FD80 $FD90-$FDCF Free $FDD0-$FDDF Area for ROM-banking $FDE0-$FDE1 MIDI-interface $FDE2-$FDEF Free $FDF0-$FDFD Free $FDFE Register on EPROM-card $FDFF Register on sRAM-card $FE00-$FE7F Free (best usage for a RAM-drive...) $FE80-$FE9F SID-card, mirror from $FD40... for hungarian-compatibility $FE80-$FE9D SID-chip $FE9E DAC on digiblaster add-on $FE9F ADC on digiblaster add-on $FEA0-$FEBF Free (?) $FEC0-$FECF Floppy 1551, device 9 $FED0-$FEEF Free (?) $FEF0-$FEFF Floppy 1551, device 8
Ennyire talán nem rugalmasak. A Hannes 4db 64k-s lapból dönti el, hogy melyiket látod a váltási határ (4k vagy 16k) fölött, a váltási határ alatt mindig az alapértelmezettet. A Csory-nál meg a 64k-s címtartomány 1db 16k-s lapjára mondhatod meg, hogy a 16db 16k-s lapból melyiket látod ott. Tehát egyszerre van 3 alapértelmezett és 1db lapozott szegmensed.
(és egyébként MMS-nek info: a Lotharek féle bővítőn tudod használni mind az 512k-t, tehát ott 8db 64k-s lapból választhatsz, a leírás csak arra vonatkozik, hogy a vezérlése kompatibilis a Hannes 256k-val)
De például az Enterprise 64/128 számítógép is pont így csinálja, hogy bárhová be tudod lapozni a tetszőleges 16 kB-ot a lehetséges 4 MB-ból. De a 128 k-s ZX Spectrum is azt csinálja, hogy két lapra ki lehet választani, hogy milyen memória legyen ott. Legjobb tudomásom szerint.
Tudtommal a Hannes és a Csory memória bővítés. A Hannes-féle lehetővé teszi hogy a négy 16 k-s lapra egymástól függetlenül belapozd valamelyik 64 k megfelelő lapját, de az alsó nem tudom mennyi memóriát fixen belapozva tartja. A Csory-féle pedig biztosítja, hogy a négy 16 k-s lapra a 256 k bármelyik 16 k-s szegmensét belapozd. Amennyire én tudom. Ez rugalmas, de nem nagyon támogatja az eredeti BASIC. Talán az OS92/OS96 ki tudja használni.
Már bocsi! De ki csinálja másképp? Én (és a C=128) csak és kizárólag az akku tartalmát tudom mozgatni. X regiszter a lapkód, Y pedig a számláló – indexeléshez.
É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.
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.
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.
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.
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).
"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 :-) )
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.
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.
