Kb 300 baud volt a normál sebessége, ha jól tudom 5-7x volt a gyorsítása, tehát igazad lehet. Engem a blutooth eddig nem nyűgözött le túlságosan.
A pénzes csókák telefonjáról tényleg hiányzik az audio kimenet, de szerintem azok akiknek mindig a legújabb telefon kell, nem is vacakolnak régi retro cucokkal.
Egy kábelt azért egyszerűbb összebarkácsolni, mint blutrooth illestőt passzolni max 232-vel a User portra (ami ráadásul nincs is a C16 / 116-on)
Grafika:
ez nem furcsaság, nem vagyunk egyformák. -PETSCII nekem is tetszik, tavaly az Arok-on én is PETSCII grafikával indultam.(Rainbow Eye), kifejezetten memóriahatékony. Kíváncsi leszek, mikor jön ki egy shooter game korrekt PESCII grafikával C64-en az Evil Skull szintén karakterképes (igaz az ECM és módosított karakterkészletes) https://csdb.dk/release/viewpic.php?id=160360&zoom=1
-George-nak is segítettem összehozni a wireframe 3D engine-jét, elsősorban tesztekkel, ötletekkel. az is tetszik, de nagyon hiányzik hozzá a rendszerből egy aritmetikai társprocesszor
-Emellett viszont érdekel, hogyan lehet grafikailag a legtöbbet kihozni ebből a szériából pl FLI módszerekkel.
Magyarul mindeféle grafika érdekel és szívesen foglalkozom vele.
Egyedül a teljesen grafikamentes kalandjátékok nem hoznak lázba. Van az a szöveg, hogy "amit saját magam elképzelek a leírás alapján, az mindig jobb, mint amit a szerző csinálhat". Pl a könyv. BS.
Szerintem meg inkább a játék szerzőjének a lustasága vagy fantázia/tehetségének a hiánya. Mennyivel gyorsabb és egyszerűbb leírni 5-8 sort egy helyszínről, mint rajzolni egy korrekt képet.
Nekem aztán tényleg menne, szófosás a munkám jó része, és elég jó vagyok benne. (vevőnek kell elmagyarázni aprólékosan, miről szól az akciónk, mit lát a képen, stb)
Playing audio through the headphone jack -> 2% per hour;
Playing audio over bluetooth -> 3.4% per hour.
Grafika. Lehet, hogy én vagyok fura, de ezek az agyontrükközött grafikák sosem tetszettek. Az Elite/Mercenary vonalrajzai és pl. a Castle Matcher talán gyári karakteres képei ugyanakkor rendben vannak. :)
Audio jack nem jó, mert a pénzesebb ügyfelek telefonján nincs ilyen, meg amúgy is bizonytalan lenne az egész a DAC-ADC miatt: bluetooth lesz. Na, mehet a Kickstarterre? :)
1-- Az SD1541-II nekem nem éri meg a TC64 mellett, S-Jiffyt is tud, amaz nem tudja.
2-- Túl drága lett volna a Sound expander a Plus/4-hez, ki vette volna meg? A Plus/4 bukását nem a SID, vagy a Sound expander hiánya okozta, hanem hogy semmiben nem volt kompatibilis a C64-gyel. A C128 kompatibilis volt a C64-gyel, mégse írtak normális, a 64 KB-nál több RAM-ot kihasználó C128 módos programokat. Még ma is C64 módban használja 99%-ban mindenki a gépet.
3-- A RAMLink egy RAM bővítő és SCSI HDD vezérlő, de értelmetlen a CMD HDD-t megvenni (ma már több 100 €), mert 20-40 MB-os HDD-k voltak hozzá, 12-es egységszámmal. Az 50 KB/s gyorsnak tűnhet, de az alap IDE64 is tudja ezt a sebességet, az alap itt is a 12-es. A RAMLinknek külön 9VDC 1A tápja van, de csak a RAMLinket és a RAM portba dugott eszközt táplálja, a RAMLink pass-thru portja a teljes C64 bővítőportja, ezt a C64 táplálja. Aki rendesen akarja használni a C64-et, amúgy is erős, kapcsolóüzemű, védelmekkel bíró tápot vett hozzá. Akkum is volt hozzá, lehetetlen volt feltölteni, és úgyis mindent be kell tölteni a RAMLink RAM-ba, ami sok idő még Jiffys FDD-vel is, hiába tárolja az akksi utána. SCPU-val működik, gyorsabb, ezzel 2×16 MB is lehet, de a RAMLink már IDE64-gyel is összeakadt részben a regiszterterületnél, eleget teszteltem ezeket. Az IDE64-et felkészítették a SCPU-ra, külön volt hozzá IDEDOS, a SCPU-t és a RAMLinket ugyanaz gyártotta, nyilván működtek együtt, de a RAMLink+IDE64 kicsit problémás. Tehát a SCPU+IDE64 volt a szuper, brutál gyors, 331 KB/s. C64-nél ez a csúcs. De azért működik a SCPU+RAMLink+IDE64, mert a Metal dust (1581 lemezeken vettem meg) játékot így is használtam FDD nélkül, a játék a RAMLinket támogatja, az IDE64-et nem. Először az IDE64-ből RAMLinkbe kellett másolni az 1. 1581 lemez tartalmát, aztán RAMLinkből indítani a játékot, ami a SuperCPU RAM-ba másolt át mindent, és innen töltögette be játék alatt. Működik. Persze nem éri meg csak 1 játék miatt 2500+ €-s hardvert tartani (SCPU128 volt 16 MB-tal, ez drágább, 2000+ €), ezért ezeket eladtam.
4-- 1994-ben is volt 256 KB bővítő. http://plus4world.powweb.com/hardware/SRAM_Card_256Kb Sima SRAM cartridge, nem kell a gépet sehová küldeni, nem belső bővítés. Hol vannak az ehhez írt programok? 2019 van. A mostani bővítésed 512 KB-os, hol van ez a 16 MB-hoz képest?
5-- A sok Plus/4 szín csak a MicroMorph0s1s videóban tetszik, de olvastam sok meló volt összerakni az egészet, külön hardvert építeni hozzá, stb.. Ez kb. olyan, mint a C64-nél az IDE64-ről olvasni az adatokat, itt is CF kártya van, de csak kb 50 KB/s lehet. Van más megoldás is, a 16 MB-os 1764 REU-val a nuvie videók. Ez sokkal egyszerűbb, mert az 1764-ben eleve van DMA kb. 1 MB/s adatátvitellel. Csak el kell készíteni a képkockákat, összerakni egy max. 16 MB-os file-t, rá az SD kártyára TC64-hez, bekapcs, SD-ről REU-ba másolni az adatokat, és mehet a nuvie player.
A 9217-re: Az SFD-1001-re írt játékok jók lettek volna a maga idejében, ma már túl késő ezzel foglalkozni. Csinálhatott volna a Commodore cég 1987 körül (amikor az 1581 kijött) 1 MB-os 5,25 DD lemezes 2 fejes meghajtót, de nem tették. Az SFD-vel megoldották az 5,25-ös lemezen 2 oldalasan az 1 MB-ot mikor, 1982-ben? Miért Jiffyvel akarod gyorsítani az SFD-t? Az IEEE alap protokollt is lehet gyorsítani (te is írtad), ezzel is elérhető lehet a 10-szeres 1541= Jiffy sebesség. A párhuzamos adatátvitelt jobb gyorsítani.
Igen, a Legyél Te is Burzsuj is SD2IEC-ről futott, de a többség a fizikai oldschool floppy-t preferálja. Pedig igaza van a szerzőnek ,el kellene kezdeni használni ezeket a háttértárakat.
Na de ez mind tök felesleges, hiszen az SD2IEC megjeleníti neked az SD-kártyán lévő teljes FAT32 fájlrendszert, ahol egy mappából korlátlan mennyiségű PRG fájlt tudsz betölteni villámgyorsan Jiffy-vel (C64-en közel 20-25x a sebesség, de gondolom, a Plus/4-en is hasonló), vagy ennek megfelelője a VICE emulátorban a virtual file system, ami meg a Windows natív fájlrendszerét jeleníti meg, és még gyorsabb (igaz, asszem ez utóbbi pont a Plus/4 emulációval nem működik, de a többi géptípussal igen).
Felhőből TAP? Nagyon jó ötlet! Az androidos ZX Spektrum emulátor a worldofspectrum oldalról húzza le a kiválasztott programot. Nagyon kényelmes.
ha ilyesmi működne a telefon audio kimenetére biggyesztett konverter kábellel (mondjuk a jobb oldal a cassette input jele, a bal oldal a vezérlőjel lenne) meg lehetne hajtani... Persze lehetőleg turbos játékokkal. :-)
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.
