1) 512KB VS 256KB: már megvan miért 256KB-ra emlékeztem. Végignéztem a Lotharek videót, és ott azt mondja, hogy "volt még egy kis hely rajta, és ráraktam 256KB RAM-ot". Eszerint megduplázta, fél mega, nem semmi.
2) Lehet, hogy írni kellene Fehérvárra az SD-1541-II tervezőjének, hogy ilyenre is van igény. :-)
Az a gond, hogy D81 gyakorlatilag egy sem készült Plus/4-hez, tehát ez inkább C128 specifikus kívánság (jelenleg), amivel én nem rendelkezem.
Egyébként ezzel részben visszatértem a SFD-1001 témához is. Miért kell nekem ez a drive?
Régi dédelgetett álmom egy szöveges kalandjáték létrehozása, ami képeket használ.
Nem PETSCII vagy Hobbit szerű rajzolt grafikát. A Hobbit lemezes verziója is igen gyengécske grafikákat használ, sok helynek ugyanazt. (ugye 1-1 HIRES kép 40 blokkot használ) Természetesen ennyi kép megrajzolása elképzelhetetlen méretű munka lenne egy hobbistának. Ellenben képek, fényképek legutolsó technológiákkal készített konverziói már működhetne, lehetőleg HFLI módban Szoftver egér sprite-al (lásd Tass Times), némi interakcióval a képernyőn (ha ismeritek a "keresd meg a képen" játékokat, tudjátok), illetve Jiffy sebesség segítségével akár némi minimális animációt is össze lehet hozni (10KB/sec: 1 HIRES kép/másodperc). A három kép között gombnyomással lehetne választani (full grafikus, osztott grafikus/rövid szöveg, sok szöveg)
Jelenleg egy csomó dolog technikailag nem vagy nehezen megoldható számomra, de tanulgatok. HFLI osztott képernyő? Szoftver sprite a HFLI képernyőn mozgatva? Nincs működő egér...
Ami ehhez kell (még tömörített képek esetén is): nagy háttértár. Egy-egy teljes kép HFLI-ben 35KB körül mozog, tömörítve csak 6KB. ennek ellenére ha van 20-25 helyszíned (ami azért elég limitált) már teli van velük a D64 lemezoldal, és akkor még semmilyen programról, adatról nem beszéltünk. A lemezek cserélgetése, forgatása, akár emulátorból való csereberéje elég problémás, de minimum körülményes, megszakítja a játékélményt.
A D71 egy fokkal jobb (340KB kapacitás megszakítás nélkül), a D81 még jobb (csak senkinek nincs ilyen meghajtója, viszont van rá YAPE emuláció), az SFD-1001 1MB pedig tökéletes.
Ez utóbbi viszont lassú, ezért lenne jó az IEC2IEE Jiffy kompatibilitása. Az IEEE egyébként majdnem pontosan azt a sebességet tudja, mint az 1551, tehát 4.5 - 5 x gyorsabb, mint az 1541.
Jiffyvel talán még gyorsabb is lenne, mint az 1541. Az SFD-1001 a VICE-ban már emulálva van, plus/4 esetén az 1541, 1551 és 1581 oldaható meg, de 1581-t még nem tudtam eddig szerezni (értelmes áron).
Nekem van Pi1541-em (is). Egyszer kipróbáltam, nem voltam elájulva a kezelhetőségétől (de legalább van neki). Az enyém OLED kijelzős, mellette ott vannak a gombok. Amikor utoljára kipróbáltam, akkor az SD2IEC módja (mármint amikor listázni tudod a teljes könyvtárat) eléggé akadozott, de ha megnyitottam egy D64-et, akkor azt tökéletesen használta. Azóta már D81-et is tud. Ami igazán idegesített (de ez kikapcsolható) az a drive emuláció hangja volt, mert csak pittyegett magas hangon egy piezo-speaker, nem digitalizált hangokat játszik le, mint a 1541U2.
De teljesen vállalható floppy emulátor, kompatibilitásban nagyon jó (ROM-ok is cserélhetőek).
Már 10+ éve el van terjedve az SD2IEC és microIEC több verziója, amivel nem is lehet saját (IRQ is) töltős játékokat és demókat használni, azaz a d64-ek nagy része használhatatlan, mert csak a DOS-t emulálja, nem az egész hardvert 6502-vel, 6522-kkel. Inkább ennek nincs értelme. Aki rendes 99,99%-os utántöltési sikert akar elérni, annak vennie kellett 1541 Ultimate-et, vagy Chameleon 64-et, mint én is tettem. A helyzet még mindig ugyanez. A lemonos microdrive sosem lesz kész, ezen kívül csak az SD1541-II és a Raspberrys cucc van, ami az 1541 teljes hardvert emulálja, nem csak a DOS-t. Ezek mind 2xe Ft-os dolgok. Az a szomorú, hogy a ma még Commodore gépeket használók 90%-ának megfelel az SD2IEC. Ők hogyan futtatnak egy egész lemezes demót, aminek saját IRQ gyorstöltője van? Sehogy. Ez miért jó?
Ezért az igénytelenség miatt van az, hogy az összes 1541 Ultimate verzióból kb. 10 év alatt csak kb. 500 db-ot adtak el világszerte, és sokan 2-3 verziót is vettek, és egy részük az Ultimate-64-et is megvette már. A TC64-ből még kevesebbet adtak el, talán 200-at. Az SD1541-ből és az SD1541-II-ből együtt nagy eséllyel még 50-et se adtak el, és nem is lesz változás.
Hiába várok egy rendes, teljes 1541, 1571, 1581 hardvert emuláló, d64, d71, d81-ből mindent kezelő, mindent rendesen utántöltő eszközt, mert nem lesz ilyen, ami csak ezt tudja (semmi REU, stb.), lásd a microdrive-ot.
Nem értem miért nem zavar senkit, hogy min. 20 év alatt még mindig nincs ilyen eszköz. Pont a legfontosabb területen van ez, a programok rendes futtatásához kéne, hogy ne kelljen valódi 1541, 1571, 1581-eket venni, és tartani.
A Raspberrys csak 1541-et és 1581-et kezel, pedig az 1571 is fontos lenne, mert a már említett d71-es VDC demó nem működik 2 db d64-ként. C128D-vel működött valódi 1571-gyel.
Itt jelezném, hogy valójában 512k-s a memóriabővítése ;) Mikor múltkor plus/4 world-ön emlegetted, akkor vettem egyet én is és meglepődtem, hogy a saját ram tesztem, ami Hannes esetén 4 megáig, Csory esetén meg 1 megáig tudja detektálni a memória méretét kiírta, hogy 512k. Leveleztem Lotharekkel és megerősítette, hogy valóban 512k-s RAM van rajta.
5) Folytatás. Színek. A Neon Night Girls slideshow-mnál pont azt szerettem volna elérni, hogy egy képgyűjteményen belül legyen extrém színes és artistic fekete-fehér kép is (persze mind nőből) Szerintem sikerült. Az érdem mondjuk Shane Turneré, aki ezeket kézzel megfestette és megengedte hogy használjam a képeit digitális reprodukcióra.
Az Amigán a 32 és 64 halfbright módok voltak maximum elterjedtek. A HAM6 és HAM8 annyi megkötést tartalmaztak, és hasonlóan lefoglalták a processzort mint az FLI mód a Plus/4-en
Csak hogy látható legyen: a HAM6 üzemmódból működő videó minősége NEM haladja meg a Plus/4 EvoLution és MicroMorph0s1s technikai demókét
Majd teszek 1-2 próbát, hogy ezekből milyen minőségű konvertet lehet csinálni. :-) Persze ezek nem fognak mozogni, ahhoz kevés a processzor, de mosta TED-ről és a színekről, felbontásról beszélünk.
1) hhhm, nemtom, valamit benéztem, most nekem is 192KB. Fogjuk a nyuszira, vagy a sörre :-)
SD-1541-II: igen, a 32KB ROM nem megy benne, de az összes kiadott 1541, 1541-II és Jiffy benne van, meglátjuk majd mit mond erre a lemezképre.
2) Hát pont azért, mert a Plus/4-nek nem volt megfelelő hjgképző chip-je, a C64-nek meg igen. Pont azért nem lett túl sikeres, mert nem nyújtott annyival többet a SID-nél, hogy megérje megvenni. A TED-hez képest viszont óriási előrelépés lett volna. Érdemes elgondolkodni a méreteken: A Sound Expander milyen bután néz ki a C64 mellett, túlnyúlik, nincs síkban, hol jön ki a hangkimenet? Ha melléképzeled egy Plus/4-nek máris értelmet nyer az egész: a magassága a cartridge-nek kb mint a plus/4, a cartridge szélessége annyi hogy még lefedje a User portot, és még épp nem takarja a joystick portot és a majdnem teljesen középen lenne. No meg a szín és a forma.
3) RAMLINK. Ez nem memória, hanem ultragyors háttértár és memóriaillesztő, HDD vezérlővel, JiffyDOS-al. Nem mellesleg feleslegessé teszi a REU-hoz a brutál erős új C64 táp beszerzését, ami önmagában nem kis összeg és akár berakhatod a GeoRAM-ot is mellé.
Valóban SuperCPU-val az igazi (meg egy CMD HDD-vel, aminek érdekes módon pont olyan csatlakozója van mint az ATARI ST külső Floppy-é), de önmagában sem elhanyagolható. Ha rá van kötve egy akku, akkor egy fixen telepített gépnél úgy működik "egyben" a 16MB mint egy HDD háttértár. Ez a SD memóriákból kialakított 16MB több, mint amekkora HDD-t Commodore valaha árult, és még jóval gyorsabb is. 50KB/s az nagyon gyors egy ilyen gépnél, csak képzeld el, hogy a GEOS egy modulja kb 2mp alatt betölt.
4) 256KB on Plus/4. Nem használja ki szinte semmi MÉG. Miért nem volt elterjedt? Mert mind a Hannes, mind a Csory féle 256KB-hez el kellett postáznod a gépet, beépítették, visszaküldték. Legalább 10 éve nem építettek be egy ilyet sem, miért lett volna elterjedt? Ez most megváltozott. Most megrendeled, kis csomagban megérkezik (nem kockáztatod gépet állapotát) és berakod, ráadásul az instabil/túl meleg 8501-et kiváltod egy stabil 6502-re és megjavíthatod vele a megpusztult CPUs plus/4et. Én úgy gondolom, hogy hamarosan igen jó kis cuccok születnek majd 256KB támogatással, mert egyre többen fognak venni. Pláne, hogy egy 8501 (ha hozzájutsz) már közel ennyibe kerül. Ezt a modern, vadizsír CPU-t 256K memóriabővítővel, postával együtt megkaptam 16 ezer Ft-ért, a Vaterán egy használt (működő) 8501 12ezer Ft (+posta). Hmmmm
5) Sok színt használó játékok: no igen, senki nem szeretné ha úgy nézne ki a játéka mint amire kiborult a teljes szinpaletta :-) http://plus4world.powweb.com/forum/39155 Itt pl. ebben a tech-demoban már előkészítettek pályákat, és winter és a night pályák nagyon impresszíven néznek ki (igaz ez utóbbi a C64-en is megvalósítható lenne színügyileg) Csabo Quadrillion nevű játéka elég sok színnel operál, és átültették Atarira is. Annyira színes, hogy Atarin csak a VXBE bővítőkártyával fut :-) http://plus4world.powweb.com/software/Quadrillion
Én is töröltem jobb egérgombbal az új extendedre állított d64 blokkjait a BAM-ban, de 664 free maradt akkor is. Akkor másik programot kell keresnem, mert ez csak bugos. Közben beraktam a TC64 1541 DOS-nak az S-Jiffy 32 KB-ost, és működik. Ez támogatja a 40 sávot, úgyhogy a saját kedvenc programjaimhoz 40 sávot fogok használni, több program elfér.
Az SD1541-II alapból felejtős, szerintem nem kezel 40 sávot, se 32 KB-os DOS-t. TC64 mellett nem fogok ilyet venni. Kár hogy a TC64 belső emulált 1541-éhez nem lehet párhuzamos kábelt csinálni, hogy a 24 KB-os DolophinDOS ROM-mal meglegyen a 25-szörös sebesség. A Jiffy 10-szeres, az S-Jiffy 15-szörös loados.
2-- A 9178-as MMSZoli2-re: Miért gyártottak volna Plus/4-hez Sound expandert? A gépet nem kiváló hangzással tervezték, ezért lett butított a TED hangja, ezért nem terveztek külön hangchipet. Az olcsóság volt a lényeg.
3-- Van 16 MB-os RAMLinked, nekem is volt, tavaly adtam el. Hiába emulálja a d64, d71, d81-et, igazából nem jó semmire sem ez, sem amúgy az egész bővítő. Van natív módja is, amikor közvetlenül kezeled a RAM területet. 500-700 €-ért láttam elkelni. Nem hiszem hogy jelentősen nőne az ára, kár tartogatnod. Csak PAL-ok és GAL-ok vannak benne, nem nagy CPLD, mint a SuperCPU-ban, lehetne sokkal gyorsabb is. Simán 50 KB/s, de SCPU 20 MHz-cel együtt 292 KB/s.
A SuperCPU 16 MB RAM-ját közvetlenül lehet nagy sebességgel használni, a Virtual assemblerrel én is ezt tettem, az egész assembler a SuperRAM-ban fut. A C64 RAM-ját lehet törölni, bármit beletölteni, nem számít, az assembler még működik. Reset után is. Csak egy SYS 54256 utasítás kell az indításhoz (ez egy külön a SCPU és az assembler által használt rész, alapból itt nincs semmi értelmes, csak a VIC regisztereinek a tükörképei), ami egy 24 bites long JMP utasítás, ezzel indul. Nem lehet közvetlenül 24 bites címet SYS-szel hívni.
4-- A 256 KB-os bővítőről és a 6502 modulról írtam már, a RAM-ot alig használja ki valami (a TC64-es 16 MB-os 1764 REU-t több dolog is kihasználja), és inkább 1986+-ban gyártott 8501-et kell szerezni, olcsóbb, egyszerűbb. Én ezt tettem.
5-- A mi használja ki a színeket részre még mindig nem jött válasz. Az, hogy nem lehet a top 100 Plus/4 demó, játék listát egyben letölteni nagyon akadályozza a végignézést, hogy lássam mi van.
6-- A 9179-es MMSZoli2-re: Miért akarsz IEEE-488-as SFD-1001-et Jiffy sebességgel használni? Az IEEE alapból gyorsabb a sima 1541-nél, nem sokkal lassabb a 10×-es Jiffynél, kb. 6×-os sebességű lehet. Nekem is volt pár IEEE meghajtóm régen (SFD-1001, 8250LP, 8050), meg IEEE illesztők C64-hez, valahová felírtam a sebességüket. Sőt CBM 610-em is volt, alapból tudja az IEEE-t. Amúgy nem értem mi értelme a serial portot összekötni az IEEE drive-val, mert ezt teszi az IEC2IEEE. Jó, 1 MB-os az SFD lemeze, IEEE-vel megy, párhuzamos átvitel, de ma már értelmetlenek az IEEE meghajtók. Tele vannak régi, beszerezhetetlen alkatrészekkel, javítani szinte lehetetlen, nagyok, nehezek, 8-10 kg egy 8250LP.
-- Az eleve 40 sávos 1541-nek lett volna értelme, nem értem miért lett alap a 35 sáv, amikor minden mechanika tudja a 41 sávot is. Meg 2 fejes 1541-nek kellett volna lennie 1987 előtt, így nem kellett volna lemezt fordítgatni. Meg nem hibás shift regiszteres 6522-vel kellett volna végig gyártani az összes meghajtót. Ha nem hibás, alapból kb. 6-szoros sebességű lett volna.
7-- A 9181-es MMSZoli2-re: Min. ilyen, vagy még több színű konvertált, IHFLI, meg simán rajzolt képeket várok a Plus/4-től. 8 árnyalat van a főbb színekhez, ez elég a szép színátmenetekhez. Itt van 231 szín: http://plus4world.powweb.com/software/231c Ezzel a VDC színeit is bőven felül lehet múlni, csak a felbontását nem. Az igazi sokszínű dolgokhoz sajnos min. Amiga 500, 1200 kell, bár itt se használtak ki közel se mindent, 4096, meg még több szín is lehet, itt se láttam igazán szép demót, szerintem még 200 szín se volt egyszerre 1 képernyőn.
8-- A segítésem is fontos, önmagában a csevegés kevés. Nem lett meg a válasz több dologra sem. A Promised zenéje még mindig ismeretlen hogy melyik sid az. Még mindig nem láttam ütős Plus/4 demókat 50-121, vagy 231 színnel. A Dirmaster helyett se írt senki jobb programot PC-re a 40 sávos d64 kezeléshez. Stb..
Mivel konkrétan ez nem egy "hogyan segítsünk Pákásnak" nevű fórum, ezért tényleg sok minden egyébről is lehet itt cseverészni, például más jellegű Plus/4 dolgokról :-)
A Dirmaster jó kis program, de szerintem elég bugos. Többször összerogyott nekem könyvtárszerkesztés közben, kezdhettem elölről az egészet.
Szerintem pontosan jól csinálod, de mivel a az alap könyvtárszerkezet nem tudja rögzíteni a 35 track fölötti adatot, ezért lehet "normál módon" nem megy., nem tudja értelmezni a 664 blokk feletti rögzítést. Próbaképp letöltöttem a Rocket Science 185KB-os lemezét, megnyitottam a DirMasterben, majd töröltem az állományokat, de csak 664 block free lett.
Én úgy látom, hogy BAM editorban egyenként engedélyezni lehet a "foglalt" 35track feletti szektorokat jobb egérgombbal, de ettől nem nő meg a kijelzett 664 blokk, és csak simán bemásolni sem enged 664 blokk fölé. De én magam nem is értek nagyon a lemezek szerkesztéséhez. Lehet, hogy csak direkt BAM szerkesztéssel tudod megoldani a dolgot.
C64-en több ilyen tool van, mint pl a Disc Doctor for 40 track, persze ezek is inkább hardveres floppy driveokra, nem SD-re vannak kitalálva.
SD/1541-II-t próbáltad? :-) Az elvileg HW szinten emulál, tehát meg kell ennie a 40 track-es D64-et is. Talán a hétvégén lesz időm kipróbálni Rocket Science-t vele.
Ha nem fontos amit írok, hogy megoldódjanak a problémáim, akkor miért írsz ide? Nem csak a csevegés a lényeg itt. Lehet sokmindenről beszélni, de ha nem jutok előrébb, akkor kár ide írnotok, meg nekem is.
Ezeket eddig is tudtam, a 9200-as problémákra kérem a megoldást, hogyan lehet a Dirmasterrel 40 sávos lemezt csinálni, látszik hogy kezeli a mások által csinált 40 sávost, de a freeben nem látszik, csak a BAM-ban, én nem tudok 35 sávnál többet használni. Töltsd le a Dirmastert és nézd meg amiket írtam. Most nézem hogy amikor az üres d64-be átmásoltam a Rocket lemez A oldaláról az indítófile-t és a 00-08-as file-t, 40 free lett, de a BAM-ot megnézve a 36-40 már tele van, a 35 és 2-es sávokon van még hely, 8, 11 blokk, az 1-es sáv üres, 21 blokk, össz. 40 szabad. Közben a blokkszámokat összeadva 625 jön ki, nem jó az egész. Ha új d64-et nyitok és beállítom az extended tracksot, már most foglalatnak jelzi a teljes 36-40 sávokat. Ezért nem tudok 664 blokknál többet belerakni.
Pont a Rocket science-nél látszanak a file-ok, nincsenek elrejtve, 11 file van az indítófile-on kívül, ezért tudtam összeadni, össz. 709 blokkos. A B lemezén a boot file után 20 file van, össz. 753 blokk. Ez lehetséges, mert a 40 sávosnál 749 free, a 18-asba is lehet rakni adatokat. A BAM már nem ezt mutatja egyik oldalnál se, mind2 lemeznél a 36-os sávon van csak üres hely, a többi tele van 40-ig, de ez nem érdekes.
Az alap CBM (és a Jiffy) DOS nem tudja kezelni a 1541-ben a 35-nél több sávot. A lemezt magát meg lehet ilyenre formázni vele, külön programmal, de a BAM-ban (ami a szabad blokkokat számolja) nem fog szerepelni, ehhez 40-sávos DOS kell (nekem ilyenből a SpeedDOS+40 van, de nyilván másik is volt).
A Rocket Science (meg egy csomó más demó is) meg trackloader-es, ami azt jelenti, hogy normál DOS-szal csak a boot program van tárolva (ami tartalmazza a loadert is) és onnantól a loader tudja, hogy mi hol van a lemezen, ezért ezek a directory-ban meg se jelennek. Így aztán simán lehet 40 sávos a lemez, mert azt csak neki kell tudnia.
Ez az, a tokra-s linkről töltöttem le, az üzikben van. https://csdb.dk/release/?id=44110 Sima d71, semmi trükk, 376 blocks free (952 blokk adat), szerintem működni fog 2 db d64-re szedve.
Érdekes hogy azt írja ott az issuesnél, hogy "Extending a d64 from 35 to 40 tracks...", de hiába jelölöm be a Disk/extensions menüben az extended tracksot, akkor is 664 free van az üres d64-nél, pedig 749-nek kéne lennie, csak az adott d64 fejlécében a filenév mellé tesz egy kis csillagot. Nem is lehet 664 blokknál többet belemásolni. Nem jó akkor se, ha a 192 KB-os Rocket science Plus/4 demó d64-ét (A oldal) nyitom meg, látok minden file-t, össz. 708 blokk, de 0 free. 708-664=44 Ha törlök egy min. 44 blokkos file-t, akkor kezdi el mutatni a free-t, tehát most is 35 sávosan kezeli. Nem enged semmit belemásolni az eredeti d64-be, pedig 192 KB-os (ez 40 sávos adatmennyiség), a 35 sávos csak 171 KB. Miért van ez?
Akkor hogyan lehet 40 sávos, max. 749 blokkos d64-et csinálni? Nem látom. Egyáltalán mivel készítenek 40 sávos d64-eket simán, meg valódi lemezről 40 sávos d64-et? Minden lemezfilenál külön be lehet állítani az extended trackot, ami d64. D71-nél halvány, mert itt nem lehet 40 sáv. Pedig milyen jó lenne a 80 sávos d71 formátum. A TC64 csak 35 sávos d64-eket kezel, simán nem lehetne a 35-40 sávokon lévő programokat betölteni, ehhez a TC64-ben DOS csere kéne pl. 40 sávos Speeddosra, a Jiffy is csak 35 sávos. Az S-Jiffy DOS 32 KB-os, kezel 40 sávot, de nem lehet 16 KB-nál nagyobb a TC64 1541 DOS file.
9199-re: Az RGBI régi CGA felbontás, elvileg régi CGA monitorokra közvetlenül rá lehet kötni, azoknál is dsub 9-es csati van. De kinek van 198x-ben gyártott működő CGA monitora?
Van RGBI-ről analóg RGB-re, meg erről más jelekre (talán kompozitra, svideora) konvertáló eszköz, de minden átalakítás minőségromlással jár, és pont a jó képminőség a szuper a VDC-ben 1084-gyel, sokkal jobb, mint a 40 sávos luma/chroma jel. Ezért sosem vettem, csináltam RGBI-ről valamire átalakítót. Így a jó natívan 1084-gyel.
Van VDC VGA mania, itt RGBI-VGA adapterrel jó csak a kép, amúgy 1084-gyel csak fut a nem 50 Hz miatt, kipróbáltam. https://csdb.dk/release/?id=121912
A VDC-nek igazából mindegy, hány MHz a rendszerbusz, mert saját, külön órajele van, a saját, külön frissítésű DRAM-jával teljesen elszeparált az alaplapon lévő többi eszköztől. Ezért is lehet átprogramozni PAL és NTSC (vagy bármi egyéb) közt szabadon.
Végül is a fő akadály, ami miatt nem népszerű, inkább az, hogy mai kijelzőkre nehéz csatlakozni vele, mert vagy speciális eszköz kell a színes RGB-I kimenetéhez, vagy lehet a kompozit jelét venni, de akkor csak monokróm. A VIC-kel és a TED-del persze nincsen ilyen gond.
Érdekesség: már a MEGA65-ben is van valamilyen szintű VDC chip emuláció (a GEOS-128 portolásához kellett nekik, ezért megcsinálták...), így elvileg ha valaki a 64-es módból kiindulva programozza, akkor talán ott is lehet futtatni az eredményt (kérdés persze, mennyi funkcióját, milyen szinten kezeli):
Ki tudja, még lehet, hogy a jövőben egy korlátozott (nyilván nem 100% kompatibilis, de legalább elérhető) C128 natív módot is valahogy belehekkelnek a C65 mellé? Nem lenne rossz szerintem.
> Meg van egy d71-es VDC képes demó, ez se megy TC64-gyel, mert csak d64-et kezel. Majd szétszedem 2 db d64-be, meglátom mi lesz, jókor kell váltani a 2 között hogy végigmenjen a load.
Ez szerintem nem fog menni, mert a D71-nél egyáltalán nem garantált, hogy egy fájl ugyanarra az oldalra kerül, simán lehet (sőt valószínű), hogy sávváltás-optimalizálás miatt felváltva vannak a két oldalon az adatok. Legalábbis így tud a leggyorsabb lenni.
Úgy tudom hogy a CP/M cartridge sima C64-ben is bizonytalanul működik valami időzítési gond miatt. Sosem volt ilyen cartridge-em, mindig C128-cal teszteltem. Arra emlékszem az eredeti C128 Z80 3-4 MHz-en ment volna, de vissza kellett lassítani valamiért, szerintem a VIC miatt, mert 1 MHz-es 8502-vel tud csak működni, gondolom a Z80-nal is ez van. Már a 2 MHz-es fast módnál sincs képe a VIC-nek, csak szemét van a képen. Érdekes hogy a VDC működik 2 MHz-en is, sőt a chip egyben PAL és NTSC is, míg a VIC-nél külön chip kell ehhez.
Tényleg sokkal többet ki lehetett volna hozni a VDC-ből. Tegnap meglett a 64 KB VDC RAM, kapott C64+128 mód Jiffyt, kipróbáltam TC64 C64-be dugva (Jiffys 1541) + serial kábellel egy halom VDC demót, működnek. Ez is. https://csdb.dk/release/?id=161195 Ez még a V1-esről készült videó:
Annyi hátránya van hogy a TC64-et nem lehet a C128-ba dugni, hogy a REU-s programok nem működnek így, pl. a Wheels 128, hiába van max. 16 MB 1764 a TC64-ben. Meg van egy d71-es VDC képes demó, ez se megy TC64-gyel, mert csak d64-et kezel. Majd szétszedem 2 db d64-be, meglátom mi lesz, jókor kell váltani a 2 között hogy végigmenjen a load.
Kár hogy még mindig nincs új gyártású modern, olcsó 16 MB-os SuperCPU C64 és 128 módhoz is, ezzel száguldott a gép, volt SCPU 128-am, eladtam, mert túl drága volt 2000+ €-ért, hogy nálam romoljon el, és aztán csak 200 €-t érjen. A DCR is régen elkelt, elég nekem most a sima C128, nem akarok újra 1571-et és 1581-et venni, drágák.
Az 1570 is érdekes történet, volt ilyenem is, 1571 DOS van benne, sosem készült külön 1570 DOS, ezért gyárilag alaplapi áramkör átvágásokkal és drótozással butították hozzá az egyoldalas 1541 mechanikát, hogy ne 2 oldalasan akarja kezelni. Vajon mi történne, ha kiadná valaki az U0-M1 parancsot, ami 2 oldalas módra váltást jelent? A DOS érti ezt. Az M0 az 1 oldalas mód.
A Z80 eleve a CP/M miatt került bele és csak azért, mert a marketing beígérte, hogy CP/M kompatibilis lesz a gép, de nem tudták megoldani, hogy a C64-es CP/M cartridge működjön. Ezért is van visszabutítva a Z80 a 8502 órajelére. (8502? most elbizonytalanodtam, de asszem az van benne)
Valahol részletesebben is leírták hogy milyen szuper lett volna az eredeti C128 rendszer, és hogyan, miért butították le annyira, mert először a C64 kompatibilitás se volt benne, de tanultak a Plus/4 bukásból, ezért belerakták a C64 módot rendesen.
Z80-nal miért csak a CP/M létezett? Egy halom más rendszert lehetett volna csinálni Z80-nal.
Annyira nem lehet lassú a VDC, ha a Risen from oblivion demót megcsinálták, pár órája néztem meg újra valódi géppel.
A VDC-t a C900 (csak prototípus állapotig jutott) UNIX workstationhöz tervezték eredetileg, ahol egy 10 MHz-es Zilog Z8001 (16-bites) proci mellett teljesített volna szolgálatot 1024x800 pixel monokróm grafikus felbontásban 128K videorammal és egy extra blitter kártyával is kiegészítve. Mivel ezt a projektet lelőtték (mert jött az Amiga, és arra koncentráltak inkább), a chipet végül is a C128-hoz használták fel lebutítva (kevesebb RAM-mal, blitter nélkül), miután épp készen lett addigra. Ide írtam róla egyszer, ha van kedved és érdekel a téma, olvasd el: http://rosetta.blog.hu/2016/04/11/commodore_900_vagy_z-machine
A regiszterkiosztás a Z80-szerű architektúra miatt lett olyan, amilyen (IN és OUT portok használatához lett tervezve).
A valóságban nem annyira lassú adatokat bevinni, mint ahogy az urban legend tartja. Általános másolóciklusokkal összemérve kicsit több, mint kétszer annyi idő, mint a normál memóriába, pl. lásd itt: normal vs. VDC/load = 17345 vs. 37367 gépi ciklus (1 kilobájt átvitele, átlagban): http://csdb.dk/release/?id=158763
De még ezen jelentősen lehet gyorsítani, mert pl. nem is muszáj minden bájtnál ellenőrizni a ready bitet, hanem elég csupán néhány bájtonként (ki lehet kísérletezni, hogy mennyi fér bele, sőt, ha van mellette REU, azzal akár nagyságrendi ugrást lehet elérni).
Aztán 2 MHz-en járatva a CPU-t, az átvitel is mindjárt duplájára gyorsul ugyebár.
SuperCPU-val 20 MHz-en kb. 6-7-szeresére gyorsul fel.
C128 VS Plus/4: a C128 nem volt bukás. 2 millió darabot eladtak belőle,kétszer annyit mint a jóval olcsóbb Plus/4-ből, és megjelenésekor jóval drágább volt, mint a C64. Sok C64-es választotta a C128-at, mint fejlesztés, de mikor kiderült, hogy annyira azért nem komoly gép, maradtak a jól bevált régi játékok futtatásánál. Magyarul amíg aktív volt a gép eladása, nem nagyon volt igény komolyabb játékokra. A 8502-re írt 128K-s felhasználói programok nem voltak rosszak, és a GEOS is elég jól futott a nagyobb memóriával és a nagyobb felbontáson. viszont a REU már akkor is drága volt, és a gép további belső bővítése nem volt olcsón megoldható.
A többség megmaradt a játékoknál.
Személyesen láttam a szegedi Vízműveknél az informatikusokat, akik épp a friss C128-akaon telepítették a bérszámfejtő és személyzeti nyilvántartó programokat. A C64 már kevés volt, volt numerikus billentyűzete, a processzor gyorsabb volt, a 80 karakteres kijelző igen hasznos volt. (bár BASIC-ben ÁLLÍTÓLAG a folyamatos RAM/ROM lapozás miatt a C128 lassabb volt mint a C64, és konkrétan lassabbak a rajzoló rutinok mint Plus/4-en (mivel VIC-II módban a CPU stabilan 1MHz-en megy, míg a Plus/4 a kereten 1.7MHz-el)
A C128 a teljes kompatibilitásával pontosan úgy járt a C64-el, mint a Plus/4 a C16-al: hogy több programot adhassanak el, ezért a limitáltabb, de több ember számára eladható termékeket gyártották le és adták ki. A C64-ből minimum 10x annyi volt, mint a C128-ból, a C16-ból minimum 2x annyi, mint Plus/4. Mindkettőnek az lett az eredménye, hogy a legtöbb ember által elérhető memóriamennyiségre fejleszettek, ez 64K volt a C64 esetén (mert a C128 úgyis elfuttatja) és 16K a C16 memóriája miatt (a Plus/4 úgyis elfuttatja)
C128-al kapcsolatban: rengeteg potenciál van a gépben, imádom a kinézetét a desktop masinának, az 1571 is csúcs (van is belőle egy), de vannak dolgok, amit igencsak elböktek benne. többek között emiatt nem lett sikeresebb gép, bár a profibb konkurrencia is igen erős volt már akkoriban (mindenki az Amigát várta...)
-A CP/M professzionális használata a Z80 processzor orbitális lassúsága miatt dőlt dugába. Ha jól tudom, a VIC-II és a szűk memória sávszélesség miatt kb 1MHz-en üzemelt (legjobb esetben 2). No ehhez tegyétek hozzá a szövegszerkesztőt és adabáziskezelőt, ezt az adatmennyiség kezelést egy kvázi 1MHz-en működő Z80-nak kellett kiszolgálnia, amit már a ZX Spectrum 48K is kiröhögne a 3.5MHz-ével, a CP/M-et futtató Amstrad CPC-k 128KB val és 4MHz-es CPU-val pláne. Konkrétan leírják, hogy bár a CP/M csak karakteres módban működött eleinte, olyan lassú volt a szövegszerkesztő (talán wordstar?) hogy oldalváltás esetén szó szerint látni lehetett ahogy egyesével kirakja a képernyőre a karaktereket a gép. (a CP/M vagy a multitasking SymbOS mint olyan engem is érdekelt volna Plus/4-en, 1571-el, és erre az eZ80-at szemeltem ki, ami egy gyors modern IC, a leggyorsabb megfelel egy 200MHz-es Z80-nak, van 100% teljesen Z80 kompatibilis módja, kissé hasonlít a SuperCPU agyához. Mivel nincs NMI vonal a 8501-en, ez a bővítés halott ötlet, ráadásul a scene sem támogatta, hogy a Plus/4 kvázi rabszolgasorban egy megjelenítő eszközzé degradálódjon).
VDC: a VDC-t olyannyira nem tervezték arra, hogy grafikát kezeljen, hogy eleinte nem is volt dokumentált ez a módja a CBM részéről, csak mint 80 karakteres kijelzőt reklámozták. (ekkor még csak 16K-s verzió volt belőle, ami 16 független szín mellett (4 bitplane) csak igen limitált 640x200 felbontást tett lehetővé. Hiába mondjátok,hogy a VDC ezt izomból megoldotta. Volt benne blitter, viszont baromi lassú volt a programozása. A 37 belső regisztert egy kontrollregiszteren keresztül lehetett felprogramozni, aminek a programozása tele volt várakozási ciklusokkal. Lassú... A VDC memóriáját ugyanazen keresztül lehetett feltölteni adatokkal, hasonló kommunikációs módon. Hát nem gyors... SZVSZ ez szerintem látszik is. Ha megnézek egy C64 GEOS vagy egy C128 GEOS futtatást, az ikonok lapozása során szerintem a C128 többet gondolkodik, dacára a több memóriának és kétszer gyorsabb processzornak. Ez szerintem csak amiatt lehet, mert az új ikonok képeinek az adatait lassú áttölteni a képernyőre. Vagy nézzétek meg a VDC Mania képernyőtöltését. Nem a kép olyan nagy méretű (hisz max 64KB lehet) hanem amíg ezt az adatmennyiséget átpumpálják a szűk keresztmetszeten.
Nem a VDC-t akarom ekézni, de ahogy a SID-nek volt annyi direkt elérésű programozható regisztere, a VDC-t is sokkal gyorsabbá tehették volna, ha a 37 regiszter direkt elérésű lett volna. De ilyen adatmennyiség áttöltését eredetileg nem tervezték bele, csak a 2KB-os karakteres képernyőnyit.
Az FLI valóban szinte teljesen megfogja a processzort, ebben játékot tutira nem ír senki (?), de azért amit ebből a Plus/4ből ki lehet sajtolni trükkökkel, az nem semmi. Nagyon kevés 8 bites gép volt erre képes akkoriban.
Amit szerintem kihagytak mint ziccert: ZX Spectrum emulátor. A Z80 adott volt, volt kellő memória is, a SID le tudta volna emulálni az AY-t (már ha hozzáfért a SID regiszterekhez a Z80)
Máskor is nézegettem már ilyesmi hosszú guide-eket. 700+ oldalt nem tudok átnézni. Csak az 501-től néztem most bele. Az 537. oldalon a VIC teszt bit az 53296 1-es bit, de az 1-es cím bitjeiről, a színtárról nem ír az 502. oldalon az 1-es címnél. Az 540. oldalon a szokásos 1-es cím bit kiosztás van, mert ez a C64-es kiosztás, semmi nincs a 2 színRAM kapcsolásról.
Nem értem hogy a C64-es profi trükk, demó, játék programozók legalább egy része miért nem tér át egy kicsit a C128-ra, és ír demót C128 módra, a VIC és VDC részre is, mint a Risen from oblivion készítői tették 2001-ben, csináltak VIC-re 60,1 Hz-es képet, stb., meg VDC demót is. Én is programozgattam már sokat, 20 MHz-es SuperCPU-t is, de messze vagyok ezektől, nem tudok csak ezért belemerülni a témába évekre, hogy pár trükköt írjak. A SuperCPU-ból se hoztak ki mindent azzal a nem sok demóval, amit találni. Az nem akadály hogy kevés embernek van valódi SCPU-ja, évek óta elérhető a VICE SCPU emus verziója. Pl. jól néz ki a felső kereten 4×40, az alsó kereten 6×40 karakter szöveg sima betűkkel, össz 35×40 karakter sprite-ok nélkül, csak a 16383-as címet programozva. Ezt felturbóztam sprite-okkal is, meg még az oldalkereteket is megnyitottam, így 4×50 és 6×50 karakter lett csak a kereteken. Néhány hét alatt csináltam tavaly egy 24 részes SCPU demót, ezek is benne voltak, a videót láthattátok tavaly.
Csak sokáig tart végigolvasni, és megtalálni benne mindent (meg a részleteket fejben összerakni persze). Én is ezt nézem meg, ha kell.
Lemon64-et szoktam követni, ott is évről évre mindig előhozza valaki a 128 témát, akkor mindenki pufog egy sort, ötletelnek, aztán megint nem történik semmi. :) Akik 64-en rutinosan fejlesztenek, nem akarnak kimozdulni már a komfortzónából.
Hol van a leírás a C128 1-es címről (színtár kapcsolás) és a többiről, ami más, mint C64-en? Az obsessionon nem találtam. Nem gondoltam hogy az osztott képernyős Graphics parancsnál különböző színtárat használ a nagy és kisfelbontáshoz.
Plus/4-nél is van Graphics parancsos osztott képernyős mód (a BASIC 3.5-től van ilyen), ahol a képernyő alsó 5-6 sorát raszterrel levágja a karakteres módhoz, felette nagyfelbontású mód van. Itt nincs 2 színtár?
Ott van a belső U36 (internal function ROM) és a külső megfelelője, szintén max. 32 KB méretben (external function ROM), csak C128 módban, mégse látok egy C128 módos cartridge-et se. Néhány éve módosítottam egy C64 cartridge-et külső 32 KB-os funkciós ROM-osra (a ROML-t és a ROMH-t egy 74LS08-val AND-oztam össze a 32 KB-hoz, itt 2×16 KB-ot kapcsol), a 8 féle belső U36-ból (Servant is, stb.) 3-4 működött így is.
A többinél gondolom az inic rutint, a ROM kiosztást kellett volna átírnom hogy működjön. Sőt olyat is lehet csinálni, hogy a Servantban a CALL EXROM menüt aktiválni, ilyenkor a külső cartridge funkciós ROM-ot hívja meg, akár az 1750 REU-ban lévő 28 lábú foglalatba rakott ROM is működik így, kipróbáltam annó. De lehetne simán külső cartridge-ben is kapcsolgatni a 32 KB-os ROM-okat.
Ha ennyi mindent tud a C128, amit a C64 nem (meg amiket én írtam az előzőben), meg ott a sok VDC trükk is a Risen from oblivion demóval, meg az obsession oldalon a sok trükk leírása 2007 óta, akkor miért nem használta ki senki 1985 óta? A C128DCR-ben eleve 64 KB VDC RAM és 8580 SID van, 1987-ben jött ki ez a gép. Miért bukott meg a C128, mint a Plus/4-es, ha ennyi mindent tud?
Úgy látszik télen a C128 40 és 80 oszlopos trükkökkel és a Plus/4 színekkel fogok kísérletezni. Gyorsan 64 KB-ra bővítem a VDC RAM-ot, 4416 chipek ki, 4464-ek be, kész. Van 1084-em RGBI bemenettel, kábellel.
Fel kéne hívni a demóírók figyelmét, hogy a C128 dolgokkal is foglalkozzanak. Még ma is sok embernek van ilyen gépe. Ebayen ki lehet fogni működőt táppal 100 € alatt.
Még mindig nem találtam olyan Plus/4 demót, ahol 20-30 színnél többet használtak volna EGYSZERRE a képernyőn. Valaki tud 50-121 színes demót? Van 231 színes trükk is, már írtam itt erről.
A színtárak az 1-es címen kapcsolgathatók (ahol a 64-es üzemmódban a Kernal és a Basic ROM). A két legalsó bit választ ki a CPU és VIC számára egymástól függetlenül egyet-egyet, azaz akár megoldható, hogy a képernyőn az egyik látszik, miközben te írod-olvasod a másikat, majd megcseréled őket (double buffering). Az oprendszere amúgy arra használja fel őket alapesetben, hogy az egyiket a szöveges, a másikat a grafikus képernyőhöz rendeli (pl. osztott képernyőnél praktikus a GRAPHIC paranccsal).
A test bit trükkös: ha beállítod, akkor "elszáll a kép", mert felpörgeti a raszterszámlálót (elkezd nagyon gyorsan nőni, végül megáll nullánál). Ha csak kis időre kapcsolod be, átveri a képernyőfrissítést, és ha jókor/rosszkor kerülsz vissza belőle, a 16 szín árnyalata megváltozik például, mert kiesik a szinkronból (csak CRT-n). Interlace-re itt egy leírás:
És még annyi mindent tud a C128-ban az MMU is (pl. a nulláslap és a verem is átcímezhető, akár másik bankba stb.), rengeteg lehetőség hever parlagon, a programfejlesztők meg lusták voltak kiaknázni évtizedekig.
van (a VIC is mind a kettőt látja, azaz tehetsz grafikát a másodikba is). A CPU-ból ki lehet még nyomni
Hogyan lehet a 8566-os VIC test bitet interlace-re használni?
A C128-ban hogyan használsz 2 színtárat? A gépben egy 2 KB×8 bites SRAM (mint az 1541, 1571-ben) van a C64-es 1 KB×4 bites helyett, ez mindig 55296-on van C64 és 128 módban is, nem lehet áthelyezni. Hogyan használod ki a másik 1 KB-ot színRAM-nak?
Komolyan keresek a C128 felső 64 KB-ját használó programokat, mert ott áll kihasználatlanul, jó lenne valami értelmesre használni. Ha ennyire jól használható lenne a felső 64 KB C128 módban, grafikára is, akkor miért nem írt még senki semmi értelmes demót, vagy csinált akár 4-8 képből és több színtárból álló interlace szuper képet, ami ezt kihasználja? Még sima bármilyen programot se találtam, ami bármire használná a felső 64 KB-ot. A sima C128 BASIC 7.0 is csak változóknak, tömböknek, stb. tudja használni a felső 64 KB-ot, BASIC program nem lehet ott.
Meg ott van a 16, vagy 64 KB-os VDC RAM, ebbe is lehet adatot rakni 40 oszlopos módban, és gyorsan átmásolni a sima RAM-ba. A Servant U36 bővítésben van 1 menetes 1541 lemezmásoló, a 171 KB adatot a 128 KB rendszer RAM-ba és a 64 KB-os VDC RAM-ba rakja. Nem tudok mást, ami használná ezt így. 64 KB VDC RAM-mal már 3×64=192 KB RAM van, nem mindegy. Vagy 64 KB VDC RAM-mal (80 oszlopos mód + fast 2 MHz mód) rendesen kihasználni a 128 KB rendszer RAM-ot, a felső 64 KB-ot is, ilyen programot se találtam.
Akár olyan 40 oszlopos demót is lehet írni, ami saját gyorstöltővel betölt egy egész 1541 lemezoldalt a 192 KB-ba, és onnan használja. Amigánál is vannak olyan sok grafikás demók, amik akár 50 MB fastRAM-ot is igényelnek, előre betöltenek, kicsomagolnak, kiszámolnak sokmindent a fastRAM-ba, ha kész, csak akkor indul a demó, és közben nincs load, már csak a fastRAM-ból kell másolgatni a chipRAM-ba. Mondjuk ezekhez 68060 66+ MHz kell, de ez most nem érdekes.
