Keresés

Részletes keresés

SuperCPU128 Creative Commons License 2018.09.16 -1 0 8872

Nem is írtam 6551-ről. Miről beszélsz? 6522 VIA-ról írtam, amiből 2 db van az 1541-ben, lemezvezérlő, és I/O vezérlő.
Attól hogy olcsósították a C64-et, és Plus4-et csináltak, még nem kéne ilyennek lenni az alaplapnak, meg az alkatrészeknek. A mérnökök is látták a melegedést, miért nem tervezték át? Tudták hogy pár év alatt megfő a 8501 és a 8360.
Nekem volt 1988-as utolsó verziós 8501-em, nem volt ráírva semmilyen rev szám, se Rx, ez nem volt olyan meleg, és nem romlott el. A gyenge 906114 PLA-t is áttervezték, és összevonták sok más chippel, ebből lett a 64 lábú 251715, ami sosem romlik el. Ezt még továbbfejlesztették, a színRAM-ot is belerakták, ez a 64 lábú 252535.
Az IEEE meghajtók 1980-82-ben voltak olyan nagyok és nehezek, 1987-88-ra sokkal kisebbre és könnyebbre tervezhették volna. Nekem is volt 8250LP-m, SFD-1001-em, 8050-em is, sőt még 8028-as margarétakerekes A3 nyomtatóm is, csak ez volt 15-20 kg. Már 1988-ra lehetett volna 1 MB-os 2 fejes 5,25 C64 floppy meghajtó.
Ha az IEEE szabadalmi díjakat nem akarták fizetni, áttervezhették volna a buszt, egy saját csatlakozót hozzá a meghajtókra, meg a gépekre is, hozzá kábelt, és meg van oldva a probléma. A DOS-okat hozzáigazítani már nem nagy szám. Vagy ott van az 1985-ben már létező burst mód, amit a C128+1571-nél, majd az 1581-nél is használtak, az alap 1541 sebességének a 7-8-szorosát tudja, és sima 6 tűs serial kábelen. Az IEEE-488 nem gyorsabb ennél.
Ha 1990-ben jött volna ki a cég a 65816 CPU-s C65-tel, akkor más lett volna az eredmény. Nem kellett volna külön 3,5 MHz-es 4510 CPU-t tervezni a C65-höz. Akár SuperCPU-szerű gép is lehetett volna egy bedugható bővítőkártyán 14 MHz-es 65C816-tal, meg 1-16 MB RAM-mal. Ha a CMD cég meg tudta csinálni, a Commodore is meg tudta volna, max. GAL-okkal, aztán továbbfejlesztették volna CPLD-vel. A CMD RAMLink 1990-es cucc, sima GAL-okkal van minden megoldva, CPLD nincs benne. Az 1996-os SCPU-ban már van CPLD és GAL is.
A ZX Spectrum 128k-nak volt RGB kimenete, erről írtam.

Előzmény: MMSZoli2 (8871)
MMSZoli2 Creative Commons License 2018.09.16 0 0 8871

bocs, az előző kérdés kicsit túl tömör volt, nem értettem.

Ha muszáj :-)

A #8860-ban van pár jogos felvetés, és van pár nem tényszerű kijelentés.

 

-Hibás 6551: jogos

-Plus/4 összecsapott dizájn: mi köze ennek a lap méretéhez? A C64-et OLCSÓSÍTOTTÁK ezért lett kisebb, meg a hőfejlődés miatt kicseréltek IC-ket, amelyek gyakran meghibásodtak (!). A TED elsősorban a joystick portról hiányzó rövidzár védelem, a 8501 pedig a hőfejlődés miatt pusztul meg. A PLA meg pont olyan gyengusz, mint a C64-ben

 

-Az IEEE driveok elég gyorsak voltak, és némelyiknek elég nagy volt a kapacitása is. Viszont a MÉRETÜK sok esetben abszolút nem passzolt az otthoni környezetbe, az első 8250LP dual meghajtó 40 kilós monstrum volt... Talán az SFD-1001 és a felújított Porsche design 8250LP mondható otthonokban is elfogadhatónak. A C= 3040, vagy 4040: komolytalan, hogy bárki ilyet batárt vett volna meg egy hobbiszámítógép mellé.

A fő oka a párhuzas IEEE száműzésének a csatlakozók és a kábelek horrorisztikus ára volt, mivel elsősorban laborokban, mérőműszerekben használták , és ráadásul nem a Commodore-nak termelte a pénzt (mivel a HP-é volt az IEEE-488 licensz). Ma is nagyon drágák, érdemes rákeresni. Csak hogy érzékeltessem, mennyire drága a méréstechnikában MINDEN: a Mitutoyo 20 cm-es alacsony hőtáglású üvegből készült mérővonalzoja (ezzel lehet a projektorokat bekalibrálni) 91 ezer Ft. Nem vicc!  

 

Valóban, mint lejjebb leírtam (és ezzel szerintem válaszoltam is) hogy a TCBM helyett egy IEEE-t kelett volna integrálni fix kábellel az SFD-1001-hez, és az kellett volna hogy legyen az 1551.


-A 65816-ot külön megrendelére az Apple IIGS-be fejlesztették, és 1984-ben volt kész. Gondolom mivel megrendelésre tervezték és gyártották, az Apple kérhette a kizárólagos forgalmazás jogát, amíg az Apple IIGS forgalomban volt (az első verzió pontosan 1990ig futott). Egyébként a kezdetekben elég sok gond volt a processzorral, és emiatt az Apple IIGS bemutatása egészen 1986-ig csúszott. Az Apple IIGS-s sokat kritizálták a tesztek, mert baromi lassú volt a 2.8MHz-es 65816.  Talán amiatt vették vissza a sebességét ennyire, hogy ne haljanak meg túl gyorsan a processzorok (pont úgy, mint a 8501?), talán azért, hogy ne támasszanak belső konkurrenciát Jobbs kedvencének, a Macintosh-nak (ami ráadásul baromira túl is volt árazva)
Csak 1990-től kezdték el mások is gyártani ezt aprocit, pont amikor az első IIGS verzió kifutott. Úgyhogy nagy eséllyel a CPU nem is volt elérhető egészen 1990-ig, amikor a C65-öt elkezdték tervezni, lehet hogy ekkor járt le az Apple-el a szerződés?

-A ZX Specrumnak nem volt RGB kimenete, sőt kompozit sem, csak RF. Azértt tudom, mert csinálnom kellett rá kompozit hack-et, hogy legyen, mivel igen gyenge volt az RF kép. A síma 128K 1985-ben jött ki.

 

 

SuperCPU128 Creative Commons License 2018.09.16 -1 0 8870

A 8860-as üzimre lesz válasz?

Előzmény: MMSZoli2 (8867)
scarabaeus Creative Commons License 2018.09.16 0 0 8869
Előzmény: MMSZoli2 (8867)
MMSZoli2 Creative Commons License 2018.09.16 0 0 8868

Ha a 8086-ról van szó, akkor a CP/M-86 volt az amit elböktek a Digital Research-nél a szerződésnél, mert darabonként 240$-t kértek érte (az PC-DOS, ami az MS-DOS, csak 40$ volt), de ez elérhető. Ezen fut az összes CP/M cucc, viszont kell hozzá hardveres 80 karakteres megjelenítés is (=VDC).
Ebből a szempontból a C128 a nyerő, mert e beépített Z80+VDC alapból tudja futtatni, az 1571 pedig olvassa a MFM lemezeket és még gyors is.

Az egyetlen nagyobb dolog rontja a szép összképet: a Z80 csak 2MHZ-en fut, ezzel még a ZX Spectrumnál is lassabban fut (kb kétszer).
Ami azért profi programok futtatásánál nem egy nagy előny, ha csigalassú a rendszer.

MMSZoli2 Creative Commons License 2018.09.16 0 0 8867

8860? Az meg micsoda?
Ha az i7 prociról van szó, akkor nem ide tartozik :-)

MMSZoli2 Creative Commons License 2018.09.16 0 0 8866

Hi,

 

 csak még annyit, hogy nem tudom, valójában mennyibe került a HW, csak tipelgetek. Pl. azt tudom hohgy azért CompactFalsh van benne és nem SD, mert sokkal egyszerűbb a vezérlése. Cserébe a kártya ma már sokkal-sokkal drágább mint az SD vagy micro-SD
 A zene ha jól tudom azért lett 12 bites (nem 8 bit), mert a DA átalakító valami military grade cucc, csak épp ez volt a polcon... Az nem biztos hogy olcsó :-) 
 És azt sem tudom, hogy BSZ milyen végső funkciókat tervezett még bele. Elvi síkon akár 3D processzor is kerülhetne bele, ha az egység agya ezt képes "on the fly" átalakítani pl FLI-be. Soha nem mondott senki ilyet, de lehetséges lenne

MMSZoli2 Creative Commons License 2018.09.16 0 0 8865

Komment a korábbi Evolution demo mögötti Plus/4 HW-hez, amit BSZ fejlesztett.

Maga a cucc nem tűnik annyira drágának, és mivel alapvetően egy ROM belapozást csinál, és a külső eszköz (az eredeti gép memóriafrissítésétől függetlenül tud dolgozni) nem kell hogy hardweresen kompatibilis legyen a géppel, valójában nagyon komoly fejlesztés.

Persze ehhez progarmok kellenek, meg egy sztenderd felültet, parancsokkal.

Jelenleg leginkább egy teljes képernyős videólejátszónak tűnik 12 bites hanggal, de szerintem ez annál sokkal több.

 Lényegében bármely steam-et (video vagy hang) egy paranccsal lejátszik, és bemásolja a plus/4 grafikus formátumában egy adott 16K helyre, amit a gép megjelenít, illetve a TEDtől függetlenül eljátszik.
 Ha elképzelünk pl egy kalandjátékot osztott képernyővel, csak a felső 20 sort mutatja a gép a megadott grafikus memóriából, a maradék a szokásos helyről menne, üzenetekkel, kijelzéssel, ikonokkal. Jelenleg a FLI üzemmód megjelenítése elviszi a CPU idő többségét, de lehet hagyományos üzemmódot is alkalmazni.
Csak pár ötlet, amit eza HW lehetővé tenne:
 -A legalapabb, hogy a következő helyre átlépve nem hosszú töltögetésekkel jönne be a következő majdnem teljes HIRES képe a helynek, hanem egy szempillantás alatt? Fullscreen animácjó 25fps volt.

 -Az NPC szereplők saját hangjukon, 12biten digitalizálva szólalhatnának meg, azon a nyelven, amit az elején kiválasztott a user (csak fel kell venni ezeket).

 -Egyik helyről a másikra akár folyamatos animációval is átléphet a program, anélkül, hogy ez bele kellene hogy férjen a gép memóriájába.

 -Egy főellenfél megérkezése vagy halála esetén azonnal le tud játszani egy komplex animációt, amit előre lerenderelt és lekonvertált valaki (pl IstvanV grafikus konvertere batch átalakítást is tud, egy hosszabb MJPEG (motion JPEG, ahol minden képkocka 1-1 JPG kép) felvételt egy i7 egy éjszaka alatt átrámol Plus/4 üzemmódba).  
-Nem mellesleg a bővítés 512KB nagyon gyors RAM-ként is használható lenne, 2 darab 16KB-os szeretben lapozva.
És a játék egy Compactflash kártyán és egy floppyn-n elférne.

Hogy BSZ célhardvere (illetve az a kissé bővebb, amit eredetileg tervezett) valahe elkészül-e a közösség számáraelérhető bővítésként, nem tudom, de ha igen, én biztosan vevő leszek rá. Régóta dédelhgetem egy grafikus kalandjáték gondolatát a fejemben, de a hardver okorlátai miatt mindig újra kellett gondolnom a koncepciót (főképp a floppy meghajtó 170KB-os kapacitása zavar)

Még egy észrevétel:

SFD-1001 egy igazán kiemelkedő HW volt (nekem is van egy, egy IEC2IEEE illesztőn keresztül használom Plus/4hez)
Igazából (ha tényleg komolyan gondolták volna a Plus/4 irodai alkalamzását) ezt kellett volna hozzápasszítani a TCBM buszkoz, így a nagyobb sebesség egy drasztikusan nagyobb háttértárral párosult volna.

Aki játszani akart volna, vehetett volna egy soros 1541/II-t (esetleg ebból lehetett volna a fekete 1543), az irodai alkalamzásokhoz  pedig a drabális 1551  nagy sebességgel és 8 bites géphez képest óriási háttértárral, szinte semmit nem kellett volna hozzá fejleszteni, gyakorlatilag leemelhették volna a polcról a C64-hez készített CBM IEEE interface cartridge-et (de volt VIC-20hoz is). A drága IEEE kábelt az 1551hez hasonló direkt illesztéssel lehetett volna megspórolni.
Volt a Plus/4hez fejlesztve egy profi letter minőség nyomtató (DPS-1101), ez egy 1MB-os gyors SFD-1001-el és a SCRIPT/PLUS cartridge-al együtt durva kombo lett volna.

Két dolog még így is hiányzott volna:

-a nagyobb memória (a gyorsabb munkához, kevesebb töltögetés), szerintem a Plus/4 memóriája nagyon nehézkesen bővíthető és nem is volt tervezve

-80 karakteres üzemmód  a szövegszerkesztéshez. 
 

Ezzel kapcsolatban azért lenne észrevételem: számos külső HW meg a VDC chip lett kifejlesztve hogy 80 karakteres képrnyőt lehessen látni, szerkeszteni.
(ez utóbbi a C128-hoz csak később lett huzalozva)

Ha viszont valaki megnézi a Cool News4-et, ennek a 80 karakter széles képernyőnek az olvashatósága, a karakterkészlet, és a kiírási sebesség REMEK. 
(egyébként Gróf Marci ugyanabban az informatikai suliban végzett mint én (pár évfolyammal lejjebb járt), csak nálam sokkal jobb programozó :-) )  
 http://plus4world.powweb.com/software/Cool_News_4  

 
A fenti CoolNews karakterkészlet olvashatósága és kiíratás sebessége sokkal jobb, mint a Kingsoft Soft80-é. Ami azért nem semmi, mert az is egy elég komoly cég volt.
A fenti két példa is mutatja, hogy külön hardver nélkül is meg lehetett volna oldani, hogy a beépített 3+1 80 karakteres üzemmódban szerkesszen leveleket, szoftverből. a Plus/4 sebessége ehhez is elég. TV-n persze nem lehetett volna jól használni, de monitoron igen.

SuperCPU128 Creative Commons License 2018.09.15 -1 0 8864

A 8860-ra valami?

Előzmény: MMSZoli2 (8863)
MMSZoli2 Creative Commons License 2018.09.15 0 0 8863

A 8 bites gépeknél spéci software kell, vagy újraírt programok, hogy működjön, támogatva legyen az adott eszköz.

 

A modernebb rendszerknél, OS-elnél elég egy driver hozzá, hogy működjön a dolog.

Mondok egy példát: egy srác fejlesztett egy User Port-os RS232 egér illesztőt plus/4hez (mivel a joystick porton nincs analog paddle bemenet), én meg ledokumentáltam, illetve egy kicsit leegyszerűsítettem, hogy könnyebb legyen legyártani.

Egy modern OS-nél egy sztenderd illesztőt kell írni hozzá, installálod az oprendszerre, és onanntól minden kezeli. A Plus/4-en a szoftvereket kellene meghekkelni/egyesével átírni, hogy az egérről is lehessen irányítani. Azok, akik ezeket írták, rég inaktívak, vagy már nem is emlékeznek, hogyan csinálták.
Nincs egy OS, ami HDD-ről futna, és indulástól kezdve kezelné. Talán a GEOS van a legközelebb hozzá, de azt sem készítették fő HDD-ről futásra, a floppyk állaga meg csak romlik, és telerakták másolásvédelemmel is, kompex a programozása.

 

Nekem van egy CMD Ramlink2-m 16MB memóriával, a gépen belül kell átkötni két lábat, hogy működjön a hardver a C64-el az MMU.
Ilyet PCn is kellett csinálni (jumperelni, meg hw IRQ-kat állítani a driverben), de utoljára talán a 80as évek végén. Az Amigán meg talán soha.
Talán emiatt fejlesztenek ilyeneket AMigára, mert minden működni fog vele magától.
A 8 bit gépeken meg szinte semmi, hacsak nem írsz hozzá célszoftvert, vagy nagyon macerás minden egyes alkalommal beállítani.

SuperCPU128 Creative Commons License 2018.09.15 -2 0 8862

Nem a SCPU gyártó hibája, hogy a hardverre nem készültek programok. Ez régóta probléma más területen is. Itt van kb. 2000 óta az IDE64, aztán később az 1541 Ultimate, meg a TC64, ezekre is alig van olyan program, ami kihasználja a képességeiket, pl. az IDE64 gyors 50 KB/s loadját, meg az 1541U 16 MB-os REU-ját, meg a TC64 16 MB REU-ját + a kb. 15 MHz-ét.

Írtam hogy a 80-as évek óta bárki csinálhatott volna valamilyen értelmes C64 turbót, amire írhattak volna sok programot, mégse tette senki. Amigáknál még ma is készülnek turbókártyák, RAM bővítők, C64-nél miért nem ez volt?

A TV-knél is ez van, sokkal előrébb járnak a hardverrel, már van 4k, ez ma már az alap, meg 8k, stb., meg OLED, míg tartalom full HD-ra (1920×1080) is alig van, és a kábel TV adások is kisebb felbontásúak a sima full HD-nél. Elég megnézni milyen trágya a képminőség a Telekom IPTV-nél, a HD csatornák se szépek. Erre elég lenne a CRT TV is, de ezt már régen nem gyártják. Erre még a sima full HD-s TV is felesleges.

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

Nem becsméreltem semmit, annyit állítottam, az SCPU is egy "kabátotot a gombhoz" szemléletű dolog volt.

 

Nem is volt igazán sikeres a maga idejében sem, már akkor aránytalanul drága volt, kevés használati értékkel, nem voltak rá dedikált programok, játékok, semmi.

 

Aligalig csinált a C64ből felhasználói szemmel komolyabb gépet, annyi pénzért, amiért már más, sokkal erősebb gépeket is lehetett akkor már venni.

 

Az SCPU éppenhogy a létezés határán innen van, sok sosem elkészült-kiadott cucc (pl a commodore 65) már a határ tuloldalára esik.

 

A hude forradalmi teljesitménnyel semmire nem lehet menni, ha most egy intel I5-öt behuzalozok a plusz4 fenekébe, akkor mi lesz?

Semmi, értelmetlen.

Ha nem építek köré egy kvázi-pécét, amire vannak is programok, akkor viszont nem egy C64 perifériát építettem, hanem a C64et degradáltam egy pécé pixeles képmegjelenítőjévé.

 

Ennyire gondoltam, nem is igazán az SCPU kapcsán, az csak egy példa arra, egyáltlaán kell-e, értelmes-e majd 35 év után bővíteni próbálni egy kisgépet ilyen irányban.

 

Szerintem alig-alig. Még a retro hobby keretein, koordinátarendszerén belül sem. Mert nem ad nekünk semmit, nem fognak tucatjával előjönni a coderek, hogy fejlesszenek egy egyedi valamire, innentől pedig túrós az egész.

 

 

 

 

 

Előzmény: SuperCPU128 (8856)
SuperCPU128 Creative Commons License 2018.09.15 -1 0 8860

Rengeteg lehetőséget elszalasztottak a Commodore cégnél, és sok hibát is elkövettek. Már a 80-as években volt többféle 65C816 és hasonló CPU, nem kellett volna ragaszkodni a 64 KB-hoz, meg az 1-2 MHz-hez. https://hu.wikipedia.org/wiki/WDC_65816/65802

Már 1986-7-ben kiadhattak volna jobb C64-et (amikor a keskeny 250469 alaplapot tervezték), 4-8 MHz CPU, min. 256 KB RAM, stb.. A C65-öt 1990-ben tervezték, ezt kellett volna sokkal hamarabb és jobban megcsinálni.

A Plus4-es hardver össze lett csapva, elég megnézni az alaplapot, még 3-4 évig se gyártották (csak 1-ig 1984-85-ben), hogy letisztuljon, mint a C64-nél volt a szélesről (250407, 250425) keskenyre váltásnál. Ezért döglenek a CPU-k, TED-ek.

Sok lehetőségük lett volna jobb C64-et, Plus4-et, 1541-et, stb. építeni már 1987 körül. Nem értem miért ragaszkodtak az 1 MHz-es 6510-hez 1994-ig, amikor 1985-ben már kijött a C128 a 2 MHz-es 8502-vel, a 4 helyett 2 MHz-en futó Z80-nal, meg a Plus4 CPU is gyorsabb volt 1 MHz-nél. Már 1988-ra lehetett volna sokkal jobb C64, stb.

 

A floppy meghajtókat is lehetett volna jobbra csinálni, de végig a gyári hibás 6522-t használták mindegyik 1541-ben 1994-ig. Ezért lassú az 1541 adatátvitele. Már 1980-ban léteztek az IEEE-488 floppyk, ezek 6-8-szor gyorsabbak voltak a soros 1541-nél. Nem is lett volna szabad soros floppyt tervezni a Commodore gépekhez. Ott volt az IEEE-488-as 3040, 4040, ezek 1541 kompatibilisan kezelték a lemezeket. Meg miért 1 fejes lett? Az SFD-1001 már 1982 körül 2 fejes volt és 1 MB-os lemezt kezelt. Már 1980-ban 2 fejesek voltak a PC FDD-k is, az 5,25-ösek is, a 3,5-esek is. Az 1571 floppy már 1985-ben kész volt 2 fejesen, aztán jött 1988 körül az 1581 3,5-es 2 fejes. Miért kellett 170 KB-os lemezes 1541 1 fejjel? Helyette lehetett volna az SFD-1001 továbbfejlesztett változata. Mindjárt nem kell lemezt fordítgatni, meg cserélgetni. Az Amigákba tudtak 2 fejes 3,5 FDD-ket rakni 1985-től? A1000, A500, stb. Ne mondják, hogy 1 vagyonba kerültek ezek a FDD-k. Meg miért nem lett RGB kimenete a C64-nek? Az Amigánál, stb. ez alap volt már mikor. Sőt a Videoton TVC-nek is volt RGB kimenete, pedig egy pár 1000-es darabszámban gyártott jelentéktelen magyar gép volt. Az Enterprise 128-nak, ZX Spectrumnak is volt RGB-je. Stb., sok ilyet lehetne még írni. Nem valami szuper, hogy 2018-ban a C64 képét kompozit kimeneten nézzék az emberek, mert nincs jobb, az RF rosszabb. A luma/chroma = svideo jelet ma már semmilyen lapos TV sem kezeli. Ha a C64-nek lenne RGB kimenete, analóg-digitális átalakítóval akár HDMI-re is köthető lenne. Ma már HDMI van mindenütt. A C64 VIC függőleges csíkozását nem is említettem, nem értem miért nem tervezett és gyártott még senki jobbat. Annyi mindent fejlesztenek, SID, 906114, 8701, sőt 251715 helyettesítő modern chipeket.

Előzmény: MMSZoli2 (8859)
MMSZoli2 Creative Commons License 2018.09.15 0 0 8859

OFF
Azért, mert 100% 6502 kompatibilis, visszaafelé 8bit-ez is tudó gyors CPUt nem igazán fejlesztettek a MOS bedőlése után.
Pédául az A600-hoz fejlesztettek jópár piggyback CPU gyorsítótó memóriával, ezt a 8bit vonalon senki sem csinálta (engem pl meglepett a Kingsoft TED helyére/alá illetszhető RAM bővítése C16-hoz)

Ezzel pl ki lehetne kerülni a 8501 CPU HALT funciójánaka a hiányát  porton. Csak éppen nincs mit rátenni... Világos, hogy a 8501 magas halálozási arányát a felhúzott freki és melegedésokozza, de ebben masszívan benne van az elavult gyártástechnológia is. (csíkszélesség). Ha maid modern technológiával legyártanának egy 6502-t, szinte láthatatlan lenne  mérete, és 100-200MHz-en futhatna (nem lenne jelentős hőfejlődése). Miért nem csinálta meg senki?
 Ugyanez igaz a 8501-re: ha valaki nem is a mai, de csak a AMD64 15 évvel ezelőtti technológiájával (csíkzélesség, wafel tisztaság) legyártaná, szinte semmi hő nem fejlődne rajta. Méretileg meg a töredéke lenne.

 Pár éve mikor érdekeltek ezek a lehetőségek, bukkantam rá az eZ80-ra (2008-as ). Ezt ugyanaz a Zilog fejlesztette, mint a Z80-at, a víz fölött tudtak maradni az integrált megoldásaikkal.
https://hu.wikipedia.org/wiki/Zilog_eZ80

 

 Az eZ80-nak van 50MHz-es változata, és a pipeline, 16MB direkt címzés, és a 100% visszafelé kompatibilitás miatt optimális jelölt lehetne. Az 50Hzes változat úgy fut, mint egy 200 MHz-es eredeti Z80, és egy az egyben tudja az eredeti kódot futtatni.  A 4Mhzes Z80 kb a Plus/4 sebessége kikapcsolt képernyő mellett. (bekapcsolva a képernyőt a badline-ok és megosztott memória miatt aa Plus/4 csak 10%-al gyorsabb a C64nél)
 Tehát akár egy 20MHz-es eZ80 verzió 20x gyorsabb, mint a Plus/4 8501-e, kikapcsolt képernyő mellett.

 

 Mire lenne ez egyáltalán jó az eZ80? eljutottunk a lenti kérdéshez, hogy egy ilyen fejlesztés után meddig tekinthető ugyanannak a gép? Az SCPU ebbőla szempontból szuper, mert pl a Test Drive, a Driller vagy egy repülésszimulátor szuper folyamatos, real time kalkulációval futhat, de lényegében már semmilyen akciójátékkel nam lehet rajta futtatni, olyan gyors.
 Ebből a szempontból rögtön jöhet a CP/M és az azon futó elég profi programok, de kifejezetten karakteres képernyők nem nagyon menők, bár a profi programozási nyelvek nem lennének rosszak (Pascal, C).

 Viszont van egy nagyon ígéretes modern fejlesztés, a SymbOS, ami már a GEOS lehetőségeit is messze meghaladó tudással rendelkezik. Preemptive multitask, 2GB-os fájlrendszer, 1MB memória címzés, mozgatható, szabadon méretezhető ablkalkok, ebben futó videólejátszás, MP3 codec. Intenet és hálózat támogatás. Egy eZ80+kellő memória illesztése után ez is futhana a gépen, TED garfikus üzemmóddal.
Ebben az esetben aPlus/4 már persze ez "zombi hangya" lenne, amit egy külső eszköz mozgat, és már csak inézetében hasonlítana az eredeti gépre,

A legjobban a megfelelő grafikai képességekkel rendelkező MSX2 gépeken megy, és a 4MHz-es gépeken már kifejezetten jól fut 128KB memória mellett.
 http://www.symbos.de

Jó olvasgatást.
    


 

SuperCPU128 Creative Commons License 2018.09.15 -1 0 8858

Tényleg gyorsabb a SCPU az A500-nál, jó ez az oldal, egyszer már láttam.

Össze tudom hasonlítani a SuperCPU-t a Turbo Chameleon 64-gyel (TC64), mert ilyenem is van. 2 MB-os A500+-om is van 2 MB-os A590-nel, meg turbósított Amiga 1200. Most éppen az A1200-at használom.

 

Rengeteg ideje volt a sok embernek 198x óta C64, 128 turbót fejleszteni, a SuperCPU-t is többen meg akarták fejteni, le akarták másolni, de sosem sikerült senkinek, mert pont az utolsó 5-10% dolgot nem tudták visszafejteni. Sajnos mindig zárt forráskódú marad a SCPU CPLD-k, GAL-ok tartalma.

Senki nem csinált jól használható turbót, kivéve a TC64-ben lévőt. Ezt teszteltem, no limit módban csak kb. 15 MHz-et tud a rasztermegszakításnál, és kb. 17-18 MHz kéne ahhoz, hogy minden karakterhelyet külön programozhassak, mint SCPU-val (20 MHz). TC64-gyel csak minden 2. karakterhelyet lehet programozni. Ez lehetett a fő oka, hogy éppen 20 MHz-re húzták a 14 MHz-es CPU-t a SCPU-ban. Ezért nem 14-16 MHz lett. A VIC használja az alaplapi 17,7 MHz-es kvarc jelét, a CPU-nak is min. ennyivel kéne járnia, hogy minden karakterhelyet programozni lehessen.

 

A C128-nál van 2 MHz CPU lehetőség, de ilyenkor a 40 oszlopos képernyő képe elromlik, mert a VIC csak 1 MHz módban képes együttműködni a CPU-val. 80 oszlopos módban mindig van kép, 2 MHz-nél is. Vannak részben 2 MHz-es 40 oszlopos demók, az alsó-felső kereteken a rasztermegszakítással 2 MHz-re kapcsolják, aztán vissza 1 MHz-re. Lehet még spéci rasztarrutinnal az oldalkeretekre is 2 MHz-et kapcsolni, ezt pár program használja is, de sokkal nem lesz gyorsabb a program, átlagban kb. 1,4 MHz lehet így.

 

Kár hogy sehol sem látszik, hogy a TC64-ben lévőn kívül bárki csinálni akarna C64-hez turbót.

Az 1541 Ultimate II+-hoz, és/vagy az Ultimate 64 alaplapba kéne turbót beépíteni. Vagy az icompos C64 reloaded V2-be, de ők nem fogják megcsinálni, mert ők készítették a TC64-et. Siralmas hogy még mindig több Amiga turbót fejlesztenek ma is, a sokkal kedveltebb C64-hez meg 30 év alatt nem tudtak kihozni semmit.

Előzmény: MMSZoli2 (8857)
MMSZoli2 Creative Commons License 2018.09.15 0 0 8857

Az SCPU egy nagyon komoly fejlesztés volt a CMD részéről.

A cég nagyon komoly fejlesztéseket hozott, kát hogy nem koóperáltak jobban össze a Commodore-al, hogy kész GEO-ok kitteket adhattak volna ki.

(még jobb lett volna ha a C= jobban felkészíti és támogatja a 16MC-t és a SCPU-t  korábbi profibb programokra, mint az Easycalc, Easyscript, mert ekkora sebességgel és memórával már sokkal jobban működik minden, persze a GEOS volt a legkomolyabb ezek közül).

 

A BBC Micro egyébként kapott több processzorkártyát is, amivel jelentősen fel lehetett gyorsítani.

Itt egyébként látható, hogy a SuperCPU bizonyos körülmények között gyorsabb volt mint az Amiga500 a 68000-el.

 

http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html 

SuperCPU128 Creative Commons License 2018.09.15 -1 0 8856

Miért becsmérled a SCPU-t? Ez a 90-es években nagyon nagy durranás volt, mert előtte egyik retró géphez sem készült ilyesmi. Az 1 MHz-es 64 KB-os gépet 20 MHz-es 16 MB-os géppé alakította. A SuperRAM nélküli SCPU is jól működik, nem muszáj SuperRAM, de ezzel van értelme. Pont úgy, mint az Amiga turbókártyákon lévő fastRAM-nak is, e nélkül nem sokat ér a kártya, ha csak chipRAM van.

 

Hány olyan számítógépet tudsz mondani azóta, hogy feltalálták a számítógépet, amibe simán 1 külső kártyát bedugtak, és 20-szorosára nőtt a CPU és a gép sebessége, vagy 256-szorosára (16 MB/64 KB=256) a RAM mérete, vagy ez a 2 dolog egyszerre teljesült 1 kártyával? Még a PC-khez se létezik ilyesmi, még ma sem, és csak 2 paramétert emeltem ki, a többi sok funkciót nem is említettem.
1996-8-ban még PII PC-k voltak 233-333 MHz-es CPU-val és 128-256 MB SD RAM-mal: http://hu.wikipedia.org/wiki/Pentium_II
A SuperCPU a C64-nél azt jelentette, mintha 1997-ben a 300 MHz CPU-s, 128 MB RAM-os PII-be bedugtam volna egy kártyát, amin 6000 MHz-es (=6 GHz) CPU és 32768 MB (=32 GB) RAM van! Ez a CPU sebesség még ma is csak komoly húzással és hűtéssel érhető el. Még ma sem átlagos a 32 GB RAM.
A mai átlagos 3-4 GHz-es CPU-val és 8 GB RAM-mal szerelt PC-nél ez 60 GHz-es CPU-t és 2048 GB (=2 TB) RAM-ot jelentene!

Látjátok már?

Előzmény: Törölt nick (8855)
Törölt nick Creative Commons License 2018.09.15 0 1 8855

Mivel a TED simán olvassa a képet romból is, (épp azért nem lehet a basic grafikus kép a rom alatt, hogy ne kelljen ez a relokációs túró), "nem kötelező" a belső proccesszort és ramot használni.

 

Ja, hogy innentől a gépünket egy megjelenítővé és egy "okosbilenytűzetté", egy 320x200as tévékép-generátorrá degradáltuk?

 

Mért, a "nagy ász" "turbo kaméleon" az micsoda........, nem ugyanez ?:)

 

A CMD eredeti SCPU a C64 belső memóriájában dolgozik, és fut olyankor a 6510? Ja nem, külső gyors sram van a vaskazettában..

...akkor?

Hol a "határ"?

 

Az hobbiszintű "filléres informatika" így 40 év alatt (1980---2020) eljutott oda, hogy lassan az FPGA is kvázi-értelmetlen kisgépes környezetben.

 

Az olcsó párezer ft-os arm-ok olyan gyorsak, hogy szoftveresen 99.9% időhelyesen, a hardverrel "összekeverhetően" "összeházasíthatóan" emulálnak kb. mindent.

 

Softsid, soft 1541, .....határ a csillagos ég....elméletben már van "soft scpu" is.

Alig 10ezer ft, ennyibe kerül most egy raspberry pi 3..

 

Senki nem huzalozta még össze?, mert minek,..

 

.. olyan ez, mint otthoni szinesnyomtatón kinyomtatni a mona lisát és betenni az eredeti keretbe, az emberek 99.99% észre sem venné 3 lépésről nézve a festményt..., .....és..?

 

 

Előzmény: MMSZoli2 (8853)
ergoGnomik Creative Commons License 2018.09.15 0 1 8854

"ezért a külső gyorsítóprocesszorrol le kell mondenunk."

 

Amiről az Evo Lution óta tudjuk hogy nem teljesen igaz. De tény, hogy a mintapéldányon kívül nincs belőle több, és hátrányos tulajdonsága a rendszer feletti teljes irányítás átvételének hiánya/lehetetlensége. Viszont megszorításokkal igenis lehet koprocesszort használni.

Előzmény: MMSZoli2 (8853)
MMSZoli2 Creative Commons License 2018.09.15 0 1 8853

Valóban.

 

Úgy néz ki, hogy CPU HOLD vezérlőjel hiányzik a 264 szériából, ezért a külső gyorsítóprocesszorrol le kell mondenunk.

Cserébe az alapprocesszorunk az egyik leggyorsabb "klasszikus" 8 bites CPU :-) 

SuperCPU128 Creative Commons License 2018.09.14 -2 0 8852

Ezért óriási dolog, hogy C64-hez létezik 20 MHz-es SuperCPU 16 MB RAM-mal. Ezzel a CPU erővel és a RAM-mal sok olyan dolog is lehetséges, ami alapgéppel nem. Durva FLI, stb. képeket, sőt videókat lehet csinálni. Pl. minden karakterhelyen külön programozható a képernyő, sprite, stb. színek. Itt 1 jó példa, főleg az utolsó kép, hogy kikapcsolt képernyővel, csak az 53280 címet változtatva mit lehet elérni:

https://videa.hu/videok/tudomany-technika/supercpu-128-16-mb-jlvsiirXBjnUbktE

Plus4-re nem lehetséges ilyen bővítőkártyát építeni.

Előzmény: MMSZoli2 (8848)
MMSZoli2 Creative Commons License 2018.09.13 0 1 8851

Láttam már én is ilyen kódot. 

GRAPHIC1:GRAPHIC0 sort kell berakni a BASIC program elejére, hogy ez működjön.
 

Ez a lejjebb írtak szerint Plus/4-en felviszi a BASIC kezdetét $4000-re (grafikus képernyő utáni első szabad hely címe), C16-on pedig felülről lekorlátozza ha jól rémlik $1800-ra (1800-tól színmemória),  így marad 2KB a gépben. Plus/4-en a parancs után a BASIC számára a $1000-$1800 memória 2KB-ja ilyenkor elveszett. 

Törölt nick Creative Commons License 2018.09.11 0 1 8850

Ha beléptél már egyszer basicből grafikus módba, az relokálta a basic területet, és akkor rajzolhatsz akár a grafikus kép bekapcsolása a nélkül is. Egyébként meg nem, hanem hibaüzi.

 

Ha nem lenne ez a "védelem", véletlenül is felülnyomhatnád, szétverhetnéd a basic programodat egyetlen grafikus paranccsal.

 

Tehát ez a hibaüzenet van, ha még nem lett a basic relokálva.

Amit egy gépi program (aminek ha van basic része, az egyetlen sys xxxx) nincs ok amiért elvégezzen.

 

Lusta vagyok romlistát olvasni magyarul ezer oldalakon át :(, mit vizsgál, van egy "márbekapcsoltuk" flag valahol a basic munkaterületen, vagy simán minden parancs előtt(!) megnézi újra a basic vég-kezdet stb mutatókat.

 

 

 

Előzmény: IEC-ATA (8849)
IEC-ATA Creative Commons License 2018.09.11 0 0 8849

Találkoztam egy furcsasággal. Grafikai eredetű, a mikéntje hogyanja érdekel. Találtam egy minta programot ami a grafikus és karakteres(osztott) képernyőre kiírja a romban található karakter készletet. A program lefutása után lehet görgetni az osztott képernyőt, tehát a grafikus terület és a karakteres is jól elkülönül. Na most ilyenkor akármilyen grafikus utasítást kiadok, teszem azt egy kör kirajzolását (CIRCLE 1,160,100,80,80), a "?NO GRAPHICS AREA ERROR" hibaüzenet a jutalom. Akkor most a gépi kódban kiadott grafikus képernyő után nem adhatok basic parancsokat, csak ha basic-ben kapcsoltam be a grafikus területet?

MMSZoli2 Creative Commons License 2018.09.10 0 0 8848

Még egy gondolat fogalmazódott meg bennem a "hivatalos" VS "trükkös" üzemmódok témában.

A C128 és a Plus/4 rendelkezik egy olyan üzemmóddal, amit a C64 tulaj trükkösnek nevezhet, de mivel a hivalatos beépített ROM is támogatja, emiatt semmiképp nem lehet csalásnak nevezni. A 264szérián egy csak egy plusz paraméter a Graphics parancsban, hogy osztott grafikus/karakteres képernyőt kapjunk.
 Jobban belegondolva ezt is csak rasztertrükkel és időzítéssel operáló rezidens kóddal lehet elintézni, amihez C64en egy korrektül megírt (bár nem túl bonyolult) kóddal lehet csak intézni. Mivel benne van a hivatalosan kiadott alap ROM csomagban, nem lehet csalásnak nevezni, de ha nem lett volna benne, azonnal ebben a kategóriába került volna a korábbi fórumozó által.

 

Ezt a gondolatmenetet folytatva egy sok memóriával és CPU erőforrással kellően felvértezett gépen az általunk használt FLI módot is be lehetett volna emelni a hivatalosan támogatott üzemmódok közé, csak sok memória kell hozzá, és eléggé lefoglalja a CPUt. A SAM Coupe gépen erre tettek is egy próbát ("Mode 4 üzemmódban a paletta színei újradefiniálhatók rasztersoronként, így mind a 128 szín felhasználható a képen."), sajnos a 6MHz-es Z80 sem bírt el ekkora mennyiségű grafikával megosztott memória mellett.
 Az Amiga500 HAM és az Amiga1200 SuperHAM üzemmódja ugyanilyen

MMSZoli2 Creative Commons License 2018.09.10 0 0 8847

Hello!
 Jó itt is találkozni :-)

 Elviekben a C28VDC-je a saját 16K vagy 64K memória miatt lett volna sokkal profibb ennél, mert nincs ütközés a CPU-val. (meg persze az összes PCs videókártya ilyen volt, kivéve az elmúlt pár év integrált megoldásait, megosztott memóriával, de azt is dedikálja magának a memóriát. Illetve volt még a IBM PCjr a Tandy-val, hasonló felépítéssel, mint a Plus/4, ott is bármely blokkban lehetett a grafikus memória vagy a karakteres képernyő)

 A C128-nál talán ott rontották el, hogy nagyon szűk lett az a port, amin keresztül a VDC-t programozhatták, meg hát a VDC MOS8563 szintén csak 8+8 színnel rendekezett (igaz eredetileg UNIX gépbe tervezték Z8000 mellé 1983-ban)).

  Csakhogy a MCGA (1987!) ugyanekkora 64K-ban csinált egy 320x200 felbontást 256 szabadon választott színnel (262ezerből), és ez a chunky mód könnyen programozható volt (1 bájt/pixel), a 64K szelet miatt gyors is, pl szoftver sprite-hoz
Avatott kezekben baromi jól is tudott kinézni (lásd King's Quest 5, aminek az Amigás portja inkább csak elfogadhatóan néz ki).

 Tehát a VDC a 64K saját RAM ellenére kihagyta ezt a ziccert (illetve elég lett volna 256 jól megválasztott fix szín is ehhez a módhoz, némi limitációval OK lett volna). 
 Jah, poénból beraktam, hogy a HFLI (nem interlace) Plus/4 320x200-ban mire képes a palettájával. (persze a sebessége és a memóriaigénye miatt ez soha nem tudna így kinézni valódi játékban, de ujjgyakorlatnak nem rossz, mit tudna agép kicsit több memóriával, kicsit gyorsabb procival)

Ez a felújított King Quest1 VGA konverziója IstvanV féle konverterrel kb így nézne ki Plus/4en:
[img]https://i.imgur.com/w5IpvXp.jpg[/img]

Ez az eredeti PC EGA verzió normál Plus/4 multicolorba konvertálva, kis szerkesztés után:
[img]https://i.imgur.com/yoeV9NT.jpg[/img]

Ez pedig az eredeti APPLE II, muhahaha! (ez persze csak annyit jelent, hogy arra gépre elkészítették, Commodore 8 bitre meg nem )
[img]https://i.imgur.com/GeQHbf1.jpg[/img]
  

siz Creative Commons License 2018.09.09 0 0 8846

Elég jól összeszedted. Köszi. :)

 

> Sajnos a C64-nél gyakoribb badline miatt (talán a 2K színmemória miatt?) a Plus/4-en nem lehet minden sorban új színpalettát behozni az attributumba, csak minden második sorban lehetséges.

 

Igazából nem gyakoribb a badline, mint C64-en: itt is minden karaktersor előtt van. Csak itt kettő, mert szín- és karakter- (vagy fényerő- és szín-) memóriát is olvasni kell. C64-en a színmemória dedikált 1024x4 bites RAM, azt a VIC a CPU-tól függetlenül tudja elérni, nincs szükség hozzá badline-ra.

 

Illetve ha csak fényerőt akarsz változtatni (vagy karakteres módban színt, karakter nélkül, de akkor ugyanaz a karaktersor ismétlődik), akkor minden sorban lehet badline.

Előzmény: MMSZoli2 (8845)
MMSZoli2 Creative Commons License 2018.09.09 0 0 8845

Hi,

 

Bár kicsit későn, de beszállok a Plus/4 FLI grafika topicba. Bár nem programozok, csak használom.

Természetesen jól kihasználható a C64hez képest több szín, de valóban FLI az, ahol a legjobban kihozható a bővebb paletta, de anélkül is lehet részletesebb/szebb átmeneteket képezni.

Ha a legutóbbi képemre ránéztek (nem lett nagy valami, de nem akartam üres kézzel menni az AROK-ra), akkor az azon látható színátmenet majdnem teljes mértékben kihozható normál HIRES üzemmódban is. Ezek egy részéhez hasonló átmenetet a C64-el is össze lehet hozni (kék, rózsaszín, szürke), de a többit nem.
http://plus4world.powweb.com/software/Boredom

Ami miatt HFLI-ben csináltam meg a képet, hogy a Garfield feje ne legyen a HIRES-re jellemző "kockás" hátterű.
(Ennek ellenére így is lett két részlet, ahol a 2 szín per 2x8 attributum nem volt elég, mert háromra lett volna szükség: a jobb oldali fülénél és a jobb pofinál kellett volna több szín)

 FLI-ben könnyebben megoldhattam volna,  de vízszintes felbontás felére csökkenése nagyon lerontja a kép minőségét, a nagyobb részletesség miatt preferálom a 320x200 és HFLI üzemmódokat. Persze több színhiba lehet benne MC illetve FLI-hez képest.
Sajnos a C64-nél gyakoribb badline miatt (talán a 2K színmemória miatt?) a Plus/4-en nem lehet minden sorban új színpalettát behozni az attributumba, csak minden második sorban lehetséges. 


 Amikor képeket konvertálok, akkor először leveszem 32 vagy 64 színűre a képet (elég sokat is kell válogatni), és ha nem tetszik, akkor inkább visszalépek egyet és PAINT.NET-el dolgozom el az eredeti képen azokat a hibákat amelyek a konverzió után láthatóak, illetve állítok István konverterén, nem pedig utólag javítgatom natív vagy crossplatform editorral. (mivel gyorsabb és kényelmesebb, bár idén ezen lehet hogy változtatni fogok).

 A Plus/4-en elérhető 9 szürke árnyalat 320x200 nagyfelbontásban igen nagy luxus (1 fekete + 8 szürke), bár a fehér lehetne fehérebb. (8 bites gépek közül talán egyedül a MSX2 tudott egyszerre ennyit kitenni a képernyőre - trükkökkel vagy anélkül). MSX: 3 szürke, SAM Coupe , CGA: 4; C64: 5; Apple II: 4; Atari 8bit: 8 de ebből csak 4 egyszerre, hacsak nem trükkel, de ott csak 160x192 a legnagyobb felbontás, és az is interlace)

 Erre a korábban linkelt Faces slideshow-m, vagy a VDC Challenge slideshow első képe a jó példa, bár Larry interlacelt HIRES FLI képei  képei mérföldeket vernek az és sima HFLI képeimre. (speciális X-shiftes trükkel vannak még megerősítve)

Mennyire szabványosak az FLI módok? Igazából nincsenek titkok. Igazából ezek nem is trükkök, hanem "software-driven graphics mode".

Maga a módszer ugyanaz, mint a C64-en, csak ritkábban lehet színt váltani (2 raszterenként lehet, nem mindne sorban, mint a C64en vagy ATARI-n) 
Az FLI módszer és a trükk leírása teljesn publikus:
http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm

A C64 VIC-II regisztereknek megfelelő TED regiszterek pedig SVS Ultimate Map-ben található
http://plus4world.powweb.com/tools/Ultimate_Map


Larry IHFLI crossplatform konvertere teljes mértékben publikus, bárki tud vele képet hegeszteni. Igen profi a végeredmény, 
http://plus4world.powweb.com/tools/Larrys_FLI_Converter

A régebbi, Plus4Emu igen jó emulátora mellé IstvánV pakolt egy csomó plusz tool-t, nekem természetesen az ablakos felülettel, előnézettel megáldott p4fliconv_gui a kedvencem. (Larry tool-ja egy fokkal modernebb, de sajnos a monitorom nem bírja az interlace-es képeket az  emuban megjeleníteni)

Ebben a HFLI mód 320x248 felbontású
Hogy mennyire nem titkos az FLI mód: István mellépakolta az összes forráskódot is alaposan kommenlve, megjelenítővel, miegymás.
Szerintem baromi jó package.

Az MC mód 2 szabad szín per attributumja szemben a C64 3 színével valóban plusz megkötés.
 Valamint soha nem értetem meg, hogy a feketéből miért nem csináltak szintén 8 sötétszürke árnyalatot, 16 szürkeárnyalattal közel fényképminőségű képeket lehetett volna csinálni.
 A valós plusz megkötés helyett/mellett szerintem csinálhattak volna a TED-be egy 12K memóriát foglaló SuperMC üzemmódot, ami dupla színmemórával, és attributumonként egyedi 4 színnel sokkal könnyebbé tehette volna a sprite emulációt szoftverből is, és a gazdagabb paletta is jobba kihasználható lett volna. Ez előrelépés lehetett volna, olyan demo képeket alkothattak volna a termék indításakor, hogy csak na! 

 Az Amiga Boing! demója és pár HAM képe is rengeteg vásárlót szerzett a gépnek, pedig a HAM pontosan ugyanannyira használható normál programok közben, mint az FLI: semennyire.

siz Creative Commons License 2018.09.02 0 0 8844

A Plus/4Emu-ban van egy p4fliconv nevű program, az is tud ilyet. Meg a Pixel Polizei-t használtam mostanában.

Előzmény: IEC-ATA (8843)
IEC-ATA Creative Commons License 2018.09.01 0 0 8843

Felvetés! Olyan lehetőség vagy program érdekelne, ami fotót vagy egyszerű grafikát konvertál Plus/4-es formátumra. Megelégszek a fekete-fehér konvertálással.

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