Keresés

Részletes keresés

MMSZoli2 Creative Commons License 2019.12.05 0 0 9207

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
  

Pákás Creative Commons License 2019.12.05 -3 0 9206

1-- 192 KB-os a 2 lemeze, miért lett neked 184 KB-os? https://files.scene.org/view/parties/2014/evoke14/wild/rocketscience.zip

É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.

http://singularcrew.hu/idedos/perf.php

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.

https://csdb.dk/release/?id=3681

 

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..

Előzmény: MMSZoli2 (9205)
MMSZoli2 Creative Commons License 2019.12.04 0 0 9205

Hello,

 

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.

 

 

Pákás Creative Commons License 2019.12.04 -2 0 9204

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.

Előzmény: siz (9203)
siz Creative Commons License 2019.12.04 0 0 9203

Hát bocs, DirMaster-ben nem tudok neked segíteni. Sose használtam még, ezután sem fogom, mert nincs rá szükségem.

Előzmény: Pákás (9202)
Pákás Creative Commons License 2019.12.04 -1 0 9202

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.

Előzmény: siz (9201)
siz Creative Commons License 2019.12.04 0 0 9201

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.

Előzmény: Pákás (9200)
Pákás Creative Commons License 2019.12.04 -1 0 9200

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.

PC-n is megnézhető a DirMaster V3-mal. https://style64.org/release/dirmaster-v3.1.3-style

É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

https://www.youtube.com/watch?v=zE-M2FnhWMA

Előzmény: siz (9198)
O.R. Creative Commons License 2019.12.04 0 0 9199

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):

 

http://youtube.com/watch?v=bK04hl8OKto

 

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.

siz Creative Commons License 2019.12.04 0 0 9198

> 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.

Előzmény: Pákás (9197)
Pákás Creative Commons License 2019.12.04 -1 0 9197

Ú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ó:

https://www.youtube.com/watch?v=NbBwN7lgrE0

Ezek is jók voltak: https://csdb.dk/release/?id=100510    https://csdb.dk/release/?id=100511

 

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.

Előzmény: siz (9196)
siz Creative Commons License 2019.12.04 0 0 9196

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)

Előzmény: Pákás (9195)
Pákás Creative Commons License 2019.12.04 -1 0 9195

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 9187-9188-ban írt dolgokat se használták ki.

Előzmény: O.R. (9194)
O.R. Creative Commons License 2019.12.03 0 0 9194

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.

Előzmény: MMSZoli2 (9193)
MMSZoli2 Creative Commons License 2019.12.03 0 0 9193

Egy kicsit ON és OFF is leszek itt:

 

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)

 

 

 

 

Pákás Creative Commons License 2019.12.03 -2 0 9192

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.

Először elég lesz itt az interlace.zip. https://sites.google.com/site/h2obsession/CBM/C128/Interlace

Előzmény: O.R. (9191)
O.R. Creative Commons License 2019.12.03 0 0 9191

A Programmer's Reference Guide-ban minden le van részletesen írva:

 

http://pagetable.com/docs/Commodore%20128%20Programmer's%20Reference%20Guide.pdf

 

http://pagetable.com/?p=620

 

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.

Előzmény: Pákás (9190)
Pákás Creative Commons License 2019.12.03 -2 0 9190

Ha gondolod átmehetünk a C128 témával a C64 games topikba, inkább oda való. https://forum.index.hu/Article/showArticle?t=9022724

 

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?

 

Az MMU 16 féle RAM/ROM átkapcsolást (bank 0-15 parancsok) már én is nézegettem, tényleg áthelyezhető a nulláslap is. 8-10. oldal: https://www.cubic.org/~doj/c64/mapping128.pdf

Ezt miért nem használta eddig senki?

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.

http://old.pinouts.ru/Motherboard/ExpansionC128_pinout.shtml

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.

Előzmény: O.R. (9189)
O.R. Creative Commons License 2019.12.03 0 0 9189

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:

 

http://sites.google.com/site/h2obsession/CBM/C128/Interlace

 

É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.

Előzmény: Pákás (9188)
Pákás Creative Commons License 2019.12.03 -2 0 9188

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.

Előzmény: O.R. (9187)
O.R. Creative Commons License 2019.12.03 0 0 9187

Továbbá a C128-ban lévő VIC-IIe is több potenciált tartalmaz a C64-eséhez képest eleve, hisz két colour RAM közt válthatsz (ugye 64-esen egy komoly korlát, hogy ez fix) és két 64K-s memóriabankod 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 +30%-ot sebességben, valamint a VIC-IIe "test bit" révén elérhető némi interlace vagy színmódosításos trükk.

O.R. Creative Commons License 2019.12.03 0 0 9186

Annyival még árnyaljuk a képet, hogy míg C64-en és Plus/4-en az ilyen technikák agyonterhelik a CPU-t és/vagy felélik a memória nagy részét a gépben, addig a C128/VDC esetén a VDC chip hardverből nyomja az interlace-t és a dedikált videomemória elérése is a CPU-tól független (akár belső adatmozgatásra képes), így mind a proci, mind a rendes memória tökéletesen tehermentesítve van (sőt, kikapcsolt VIC mellett még badline sincs, a proci full 2 MHz-re átkapcsolható).

 

Ha egy-egy állóképen való meditálás helyett valamilyen konkrét célra használná az ember, rengeteget számít ez a különbség. (Pl. a GEOS-128 még a 640x200-as felbontásban futtatva is sokkal gyorsabb, gördülékenyebb, mint a 64-es verzióval való kínlódás.)

Előzmény: MMSZoli2 (9184)
MMSZoli2 Creative Commons License 2019.12.03 0 0 9185

no a képet nem töltötte fel...

 

A szürkeárnyalatos szerintem C64en majdnem ugyanígy nézne ki, persze HFLI-ben:

https://i.imgur.com/7cPky0P.jpg

 

MMSZoli2 Creative Commons License 2019.12.03 0 0 9184

Hello,

 

pontosan ahogy siz mondja!

A VDC Challenge csak 320x200 felbontású HFLI (nem váltott-soros) képeket használ, tehát egy kép, viszont az FLI trükk miatt minden második sorban új színpaletta van a karakteren belül.

Én a 320x200-as (H) felbontást preferálom a normál FLI helyett, mivel sokkal részletgazdagabb a kép 320x200-on, mint 160x200-on (viszont kevesebb színt használhatok egy karakterhelyen belül)

 

A I-s Interlace-es képeknél új színek alakulnak ki, mivel a két kép nem egyforma, és a szem tehetetlensége miatt kiátlagolja az egymás mögött levő gyors ütemben váltott pixeleket.

Larry elsősorban a kontrasztra és a színek egymáshoz képest észlelhető fényességére helyezi a hangsúlyt (mivel kétszer több érzékelő van ebből a szemünkben), míg én inkább a színekkel operálok.
(az én elméletem az,hogy a több színnel finomabb átmeneteket és természethűbb képeket lehet csinálni, ehhez viszont a jobbik felbontás dukál - ez a VDC-nél jön ki leginkább, aminek hiába van remek felbntása, a 16 szín hazavágja. Érdemes megnézni az EGA képeket is, hasonló teljesítményre képes a C128 VDC is, csak itt még a teljes paletta is 16 szín, nem 64 mint az EGA-nál)

 

Mindemellett megjegyzendő, hogy az összes Plus/4 FLI módot ki kell "hivatalosan" egészíteni egy D betűvel, mivel szemben a C64-el, itt csak minden második sorban lehet palettát váltani.

Ennek az ok az, hogy a szín+fényerő külön állítása és memóriába másolgatása nem fér bele egy raszteridőbe.

Theát a C64 FLI, a Plus/4  DFLI


A C64 ebből a szempontból jobb, ilyet viszont nem nagyon lehet összehozni rajta: 

 

 

Az igazsághoz hozzátartozik, hogy a szürkeárnyalatos képeknél a C64 és a Plus/4 között nincs akkora különbség.

A C64 5 szürke árnyalattal rendelkezik (fekete és fehérrel együtt, a Plus/4 9-el, viszont a fehér nem olyan szép fehér mint a C64-é, inkább csak nagyon világosszürke.

siz Creative Commons License 2019.12.02 0 0 9183

Az I-vel kezdődő (interlaced) képmódok általában 2 képet váltogatnak, tehát villódzik (kivéve 100Hz-es megjelenítőn, ott tökéletes)

Előzmény: IEC-ATA (9182)
IEC-ATA Creative Commons License 2019.12.02 0 0 9182

A konvertált kép hány darab kép? Egy, vagy a "villogásból" összeadott képek összege!? Nem ismerem az eljárást és nem is értem minek képet váltani. Ha egy kép is közel olyan "megjelenésű", mint az eredeti verzió. Köszi

Előzmény: MMSZoli2 (9181)
MMSZoli2 Creative Commons License 2019.11.29 0 0 9181

Az Amiga VS Plus/4 HFLI összevetést nem érzem annyira merésznek.

 

Az IHFLI váltott kép segítségével újabb színek jönnek létre virtuálisan, a szem tehetetlenségénél fogva. (Larry slideshow-i erre épülnek, meg a luminance over chrominance elvre)
A C64 esetén ez pár tucat új színt eredményez, Plus/4 esetén több ezer képződik.


Egy kicsit túltoltam a ditheringet, de azért nem rossz egy "referencia" Amiga HAM6 kép Plus/4 konverziójáról

 

 

 A C64 és C128 (még VDC magas felbontásaival együtt is) csak limitáltan képes fotókhoz hasonló képeket generálni.
Egyszerűen nincs kellő mennyiségű szín az átmenetek leképzéséhez, furcsa "szürreális" palettákat kell használniuk még a legnagyszerűbb képekhez is (a C64 grafikusok képességeivel kapcsolatban nincsenek kérdőjeleim, néha eszméletelen minőségű képeket tesznek le az asztalra, akár HIRES  vagy MC formátumban - vajon mire lennének képesek Plus/4-en?)

MMSZoli2 Creative Commons License 2019.11.28 0 0 9180

Tegnapról lemaradt (pontosanbbban eltűnt a hozzászólásom, mikor egy képet akartam becsatolni):

egyébként ha meg demoról van szó, a színkezelésben a Promised Land nagyon király.
Bár korábban is gyártottak nagyon szép plazmákat plusz/4-re, de ennek a palettái fantasztikusak. 

 

Szerintem 11:00-tól és 16:30-tól kezdődő részeknél kezdenek igazán bámulatosak lenni az effektek, de az előtte levő gömb, toroid és háromszögek is baromi jók.
Remekül passzol az igen egyedi zenéhez, amit akár meg is hallgathatsz itt:
https://www.youtube.com/watch?v=NmDLh3MmooY

 

 

MMSZoli2 Creative Commons License 2019.11.27 0 0 9179

9174 vagy mi :-)

 

Az SJIFFY ugyanarról az NLQ.de oldalról érhető el, aki az általam nagyon sztárolt IEC2IEEE Atmel interface-t tervezte. (Jochen Adler)

Elvileg a IEC2IEEE cucc Jiffy kompatibilis, és akkor Jiffy sebességgel tudná az IEC-re akasztott SFD-1001-et kezelni (C= 1MB/lemez, egy komplett C64 Pool of Radiance játék elfér egyetlen lemezen. Lenyűgöző!), de sajnos az én adapterem nem akarja a sebességet, mindig lefagyott.  (egy hasonló PET-es cuccnál írták, hogy a Jiffy-hez 16MHz-es verzió kell, ez meg csak 8MHz körül mozog, és így elveszíti a szinkront az egyik gyorsan adagolt vezérlőjellel)

 

Ráadásul az Arokra szállítás közben gallyra ment az SFD-1001-em is. :-( 

Úgyhogy maradt 1db amerikai MSD SD-1 floppy-m 1541 kapacitással, de IEEE csatival (és 1541 sebességgel).

Ha a fenti IEC2IEEE adapter tudná a Jiffy sebességet, akkor ezek a brutál IEEE eszközök sima IEC parancsokkal üzemeltethetőek, és szinte "végtelen" a kapacitásuk és még gyors is lenne.
elvileg az IEEE egységek még annál is gyorsabban tudnak dolgozni, mint amit az IEEE-488 engedélyezett a számukra.

Nekem örök kedvencem a"porsche dizájnos" C= 8250LP dual floppy drive, gyönyörű. (bár tudom nem sok köze volt a Porsche-hez) De 100ezer forintot sajnálnék rá, pláne ha még lassú is.
Valami ilyesmi kellett volna a Plus/4-hez az 1551 helyett az IEC kompatibilis 1541 mellé, ha már mellécsapták azt a bazi nagy adaptert, lehetett volna IEEE-488 (jah, meg a Sound Expander :-) )
 

MMSZoli2 Creative Commons License 2019.11.27 0 0 9178

Huh, annyi külön post lett hirtelen... Inkább témánkét írok, mert már így is túl sok a szám az életemben :-)

 

TED zene VS SID: a TED gyengébb. pont. A HVSC csak a C64 SID-ekkel foglalkozik a HVTC meg csak TED-en futóakkal. A Plus/4 SID zenék általában valahonnan "lettek", általában van szerzőjük is, csak nincs jelölve ("music is ripped from C64"). A Promised Land abból a szempontból különleges, hogy Plus/4 platformhoz írták a SID zenéit, a CSDB viszont "C64-náci" (ahogy ezt egy lengyel kontaktom írta), tehát semmit nem raknak fel, ami nem fut direktben C64/C128-on, nem írható be ilyen demo/projekt.
Tehát a Promised Land-ben használ Celtic Design zenéi a szürke zóna, legjobb esetben bekerülhet a HVSC-ba, CSDB-n nem túl esélyes.

 

A hardverekről annyit, hogy a fekete házas (!!!) Sound Expandert is a Plus/4-hez kellett volna kihoznia a Commodore-na (Yamaha IC-vel), nem a C64re, mert abban már volt SID. Nem is értette senki a lényegét, hogy ez most minek??? Ugyanígy a fekete házas (!!!) IEEE-488 cartridge, amiből egy sem készült Plus/4-re, és van egy halom C64-re. Rá lehetett volna kötni a brutál PET háttértárakat.
1985-ben hozták ki! https://www.c64-wiki.com/wiki/Commodore_Sound_Expander

 

Memóriabővítők:

Mivel van egy C64 RAMLINK-m 16MB gyors háttértárral, D64, D71 és D81 emulációval, saját Jiffy-vel, tehát nagyjából tudom miről maradt le annó Plus/4 társadalom. (bár RAM bővítőm nincs)
Egyébként ehhez bármilyen külső erősebb 9V táp megfelel, tehát nem kell egy erősebbet 2-3A-es C64 specifikus tápot hajszolni, mint pl REU esetén, mert lehal a gép és a táp. Ennél nem. Ráadásul ráakasztható egy külső akkumulátor, amivel megtartja a beállításait és a 16MB-ba töltött programokat. Nagyon kafa. Nem használom, mert rengeteg helyet foglal mire összerakom az egész cuccot.

Addig őrizgetem, míg nem ér majd legalább negyed misit :-)

Én a Lotharek-től mostanában kapom meg a 256K Hannes belső RAM bővítővel ellátott 6502 modulomat (sajna nem volt lelkierőm kivárni a többi ígéretes fejlesztést). Ennél nagyobb memóriát semmi nem
kezel Plus/4-en (játék csak kettő, pár utility), a GEOS meg a többi még ennyit sem, mert nincs rá felkészítve. De szerintem felesleges is ennél nagyobb egy ilyen képességű géphez. Remélem a 2A-es tápom elbírja, de ennek érdekében épp most szerzek be modern EPROM és PLA készletet, ami kb 0,2 -0,3 A-el csökkenti a gép áramfelvételét (és a képződő hőt)

 

Plus/4 gyűjtemény:

Most jutott eszembe, hogy kettőt is kaptam. Az egyik a SD/1541-II-höz járt , és alig volt benne valami C16-os. 

A másikat az 1541/II-mbe integrált microIC-hez kaptam, az jó bő volt eredetileg is, elkezdtem létrehozni a Toplista alapján a saját gyűjteményemet (külön könyvtár a konvertált, Top40, stb), de de csak félkész, mert elég kevés a munka+család kombó mellett időm.

Most 1150 állomány van benne (PRG és D64 vegyesen), 28MB. Szívesen megosztom, ha ez segít.

Csak hová lehet az ilyet feltölteni? Az IMGUR-t használom általában, de az képekre jó.

 

Mi használja ki a színeket?

erről eszembe jut a 8 Shades of Black demogyűjtemény, amiben van egy rész, amit Mermaid jegyez. a lenti videóban 1:16 "Lone Fly"

Egy madár repül, alatta házak, parallax scroll, sok szín, raszter háttér és ég, baromi jól néz ki. Kár hogy csak demo maradt, 2007-es.

Szerintem ez az egyik legszebb nem konvertált "majdnem játék" a gépen. Egy Agony jellegű lövöldözős játékot simán ki lehetett volna belőle hozni, persze hogy miképp mozogna a madár valódi háttér előtt (color clash?) szoftver sprite emuláció és színkezelés kérdése.  Jah, és a zenéje is eléggé rendben van, mert igen sok effekt le van kezelve benne, sajna nem tudom kinek a műve.
https://www.youtube.com/watch?v=WMUVaY6SigU

 

 

 

Előzmény: Pákás (9177)

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