Keresés

Részletes keresés

SuperCPU Creative Commons License 2018.10.05 0 0 8963

Én úgy okoskodtam, ha lelapozom az összes romot, nem tud IRQ végrehajtódni.

 

Mondjuk a végül ide betett példám valóban pont rossz, mert a beépített ROM-ban van IRQ...de próbáltam már SEI+JMP$ végtelen ciklussal is, FDxx-írástól függetlenül mindig a BASIC eleje van a képernyőn.

 

A yape annyival jobb(?), legalább a karaktergenerátor "eltűnik" egy fddf írás után, mert mind2 lapon külső ROM van, amiben nincs karakter adat. De a színmemória olyankor is mutatja, hogy magát a képet még mindig ugyanonnan rajzolja, ugyanazok a szines kockák vannak, mint ami a FDxx írás nélkül.

 

 

 

Előzmény: siz (8962)
siz Creative Commons License 2018.10.05 0 0 8962

A BRK kezelője szerintem visszaállítja a KERNAL ROM-t. Van a PLA-nak egy KERNAL nevű kimenete, ami akkor lesz aktív, ha $fc00-$ffff címeket szólítasz meg és ez minden ROM olvasásnál ebben a címtartományban a KERNAL kiválasztását kényszeríti. Az IRQ kezelő meg így indul:

. FCB3 48        PHA                                                       

. FCB4 8A        TXA                                                       

. FCB5 48        PHA                                                       

. FCB6 98        TYA                                                       

. FCB7 48        PHA                                                       

. FCB8 8D D0 FD  STA $FDD0                                                 

. FCBB 4C 00 CE  JMP $CE00                                                 

 

$ce00-nál megnézi, hogy BRK volt-e:

. CE00 BA        TSX                                                       

. CE01 BD 04 01  LDA $0104,X                                               

. CE04 29 10     AND #$10                                                  

. CE06 D0 03     BNE $CE0B                                                 

. CE08 6C 14 03  JMP ($0314)                                               

. CE0B 6C 16 03  JMP ($0316)

 

Most azt hirtelen nem találom, hogy mit csinál a BRK kezelő a ROM bankkal, de az IRQ vége biztosan az, hogy

. FCC9 A6 FB     LDX $FB                                                   

. FCCB 9D D0 FD  STA $FDD0,X

 

Tehát ha nem tiltod le a megszakításokat és JMP * -al fejezed be a programodat, akkor valaki később garantáltan visszaállítja a $0-s ROM bankot (BASIC+KERNAL). Ha $FB-re $05-öt írsz, akkor a megszakítás végén az visszaállítja neked a saját bankodat. Kivéve, ha a BRK rutin valahol $0-t ír a $FB-re.

 

Előzmény: SuperCPU (8960)
ergoGnomik Creative Commons License 2018.10.05 0 0 8961

Ahhoz, hogy tudjuk mit cseszel el, tudnunk kéne azt is, hogy mit vársz mi történjen.

 

Egyébként VICE felejtős. Linuxon és Macen plus4emu, Windowson YAPE vagy plus4emu.

Előzmény: SuperCPU (8960)
SuperCPU Creative Commons License 2018.10.05 0 0 8960

Szerintetek ilyenkor minek kellene a képernyőn lennie? Mit cseszek el?

 

.C:2000  A9 80       LDA #$80
.C:2002  8D 14 FF    STA $FF14
.C:2005  8D D5 FD    STA $FDD5
.C:2008  00          BRK
.C:2009  00          BRK
.C:200a  00          BRK
.C:200b  00          BRK
.C:200c  00          BRK

 

Mintha sem a vice, sem a yape nem működne helyesen, de ezt nem tudom elhinni..., tuti valamit én nézek el :(

 

siz Creative Commons License 2018.10.05 0 0 8959

Oh, tényleg bocs. A !=-t benéztem =-nek :)

Előzmény: epy116 (8958)
epy116 Creative Commons License 2018.10.05 0 0 8958

Én is azt mondtam hogy nem ő az :-)

Előzmény: siz (8957)
siz Creative Commons License 2018.10.05 0 0 8957

Szerintem nem. Visszaolvastam a hozzászólásait: ahhoz túl értelmesen ír programozási dolgokról és plus/4-es témákról is.

Előzmény: epy116 (8956)
epy116 Creative Commons License 2018.10.05 0 0 8956

Szerintem SuperCPU != SuperCPU128 / TiedLehet / C128 / AmigaFan / RetroFan

Előzmény: MMSZoli2 (8955)
MMSZoli2 Creative Commons License 2018.10.05 0 0 8955

16Ks játékokról beszélünk, ennyi fért bele. Hasonló kóddal, 64K-ban sokkal részletesebb és több grafika belefért volna, de nagyon kevés 64K játék fejlesztődött

 

A Spectrumban nem erősebb a proci. Amit a Spectrum meg tud csinálni, azt a Plus/4os direkt konverziói mind meg tudták csinálni, csak gyorsabban.

A Sabrewulf konverziót konkrétan le kellett lassítani, mert az első verzió játszhatatlanul gyors volt plus/4-en.

 

Mindent, amit tud a ZX Spectrum 48K, azt a Plus/4 is tudja, csak sokkal jobban,

Legyen az CPU sebesség, grafika, hang, memória, csatlakoztathatóság.

A Spectrum 128 csak 1985/86-ban jelent meg, ami több szempontból már jobb mint a Plus/4 (hang, memória, bővíthetőség, CP/M), de a grafika továbbra is gyengusz maradt, pedig csinálhattak volna egy új módot, valami hasonlót, mint amikor a plus/4 kibővítette a 16os színteret a világosság jellel.


A Tir Na Nog-nál a Spectrum scroll egy kissé tényleg akadozik. A C64 dettó, amit láttam a tube-on.

A Plus/4 verzió teljesen folyamatos.

 

HW sprite: kincs ami nincs, tehát a kicsinek is örülünk :-)

A Zylonra tett megjegyzéseddel nem értek egyet.
Ha gondolod, próbálj meg leprogramozni pl SuperCPUra HW segítség nélkül ekkora soft-sprite-ot, attributum kezelést, kitakarásokat, collision detectiont, állítólag penge vagy benne. Meglátod az mennyire lesz folyamatos.

Előzmény: SuperCPU (8954)
SuperCPU Creative Commons License 2018.10.03 0 0 8954

Magicians-ban a tényleges bejárható háttered általában sötét, egyszerű grafikákkal.

Hogy a show nagyobb legyen, a 256szín miatt szépen hunyorognak a csillagok. Ilyet pl ennyire klasszul C64en nem igen lehet.

Scroll viszont nincs, ez képernyőváltós játék.  Sok sprite sincs, egyedül nyomod, vagy jön 1-2 denevér, esetleg esik rád az alma.

 

A Zylon egy tolószékesen lassú játék, C64-en a rosszabb basic sprite demók néznek ki így.

 

Timeslip-ben pl egészen klassz a finomscroll, bár csak a képernyő egy harmadát scrollozza, ami ad raszteridőt minden másra.

 

Rengeteg kisgépen nincsen hardvare sprite, pl scectrumon sem. Viszont erősebb bennük a proci.

 

Erre szép példa a TirNaNog, ami máig ámulat, hogy a francba írták meg ekkora hires sprite-val, eredetileg egy spectrum game, ...

...nem teljesen reccenésmentes a scrollja, és más grafikus hiba is van, de mindenképpen ámulatba ejtő, pláne a maga korában.

 

 

 

Előzmény: MMSZoli2 (8953)
MMSZoli2 Creative Commons License 2018.10.03 0 0 8953

Pontosan emiatt nem játékgép a plus/4, mert hw sprite hiányában a játékok egy részét (nem mindet) nehezebb leprogramozni, mint az árkád vagy c64 gépeken.

(PC VGA-n a roppant egyszerű chunky 320x200x256szín módban baromi egyszerű software spite-ot programozni, mert nincs szín-ütközés meg attributum)

-Driller: 3D majdnem ugyanolyan, grafikusan karakterenként eggyel kevesebb szabad szín


-Elite:  wireframe grafika ugyanolyan, csak a plus/4 gyorsabb


-Grafikus/karakteres kalandjátékok: ugyanolyan, sőt a plus/4 alapból támogatja a grafikus/karakteres osztott képernyőt.


-Logikai tologatós játékok: Fekete háttér előtt mozgó blokkok: nincs sprite, de meg mehet oldani

-Egyszerű platformerek: egyszínű háttér előtt mozgó blokkok: nincs sprite, de meg mehet oldani


-Akciójátékok bonyolult háttér előtt mozgó karakterekkel: nem lehet vagy csak erős limitációkkal lehet megoldani plus/4en.
 A Turrican például pont ilyen, de számos játékot erős színütközéssel, vagy a karakter blokk körüli fekete kerettel oldották meg.

Voltak szép és gyors szoftver sprite szimulációk roppant jó collision detectionnel, de kevés volt az ilyen jó programozó.
Például a Magician's Curse vagy a Zylon, ezeken nem látszik, hogy nem hardver sprite-al oldották meg.

 

A legutolsó hasonló játékok már a Plus/4en is elég profin néznek ki, az Adventures in Time, Pet rescue mind nagyon okésan oldotta ezt (is) meg.

MMSZoli2 Creative Commons License 2018.10.03 0 0 8952

Finomscroll:

Bár én sem vagyok nagy programozó :-)

Megy a finomscroll a Plus/4-nek, van rá HW regiszter, és szépen meg is lehet oldani. Ezzel még az Atari ST-t is megelőzi :-)
(Igaz az Atari STE és a Mega ST már tudta ezt is, és a 8bites Atarik is)

 

Plus/4-en ebben az esetben az a gond, hogy nincs HW sprite.
Így a regiszter állításakor nemcsak a háttér (mint a C64en), hanem az ellenség és a játékos űrhajója is scrollozódik.

Tehát ilyenkor egy másik képet kell kirakni az űrhajókból

Mivel karakteres grafikának nézem, a teljes finomscrollhoz az űrhajók esetén 4 fázist kell eltárolni (mivel multicolor, ezért 2 pixeles egy pont, tehát 4 scroll fázis van). A függőleges eltolással eltárolt űrhajóról nem is beszéltem.

 

Persze ezeket a tologatásokat meg lehet  is csinálni a Plus/4-el szoftveresen, csak az  is raszteridő.


Elég sok dolog mozog ezen a képernyőn egyszerre,  hogy megérje a raszteridőn vagy a memórián spórolni (emellett az elérhető raszteridőt terhelik a hangeffektek, zenelejátszó, lövések mozgatása, collision control meg hasonló nyalánkságok amihez szintén nem értek). Tehát ebben az esetben a 4 pixeles scrollal sok mindent meg lehet spórolni.

Sheme Creative Commons License 2018.10.02 0 0 8951

Ööööö..., itt valami félreértés lészen!

 

Nem tudok programozni, még az amatőrebbnél is amatőrebb vagyok.

 

Szóval feltűnt ez a scrollozós dolog - emlékeztem a Turrican-ra, az szépen scrollozott: https://www.youtube.com/watch?v=nNAkBxNt0Dc

 

Vagy a Rambo: https://www.youtube.com/watch?v=n4l3ZVSon_4

 

Ne harapd le a fejem! :-)

Előzmény: ergoGnomik (8947)
turntable Creative Commons License 2018.10.02 0 0 8950

Elkelt.

Előzmény: turntable (8948)
siz Creative Commons License 2018.10.01 0 2 8949

A leírása szerint 25Hz a frissítés, azaz két frame-enként rajzol új képet. A többi sima matek: mondjuk ha egy másodperc alatt 100 pixelt akarsz scrollozni, akkor 100Hz frissítéssel ez 1pixel/frame, 50Hz-nél 2pixel/frame, 25Hz-nél meg 4pixel/frame. Nyilván itt nem scrolloz 100pixelt/másodperc, de a matek hasonló.

Előzmény: Sheme (8946)
turntable Creative Commons License 2018.10.01 0 0 8948

Eladók az alábbi IC-k:

-MOS 8501 R1 C16/+4 CPU 2db
-MOS 8360 R2 C16/+4 TED 2db
-MOS 251641 251641-02 PLA C16 / C116 / +4 2db

 

-PAL kernal Revision 5 C16/+4 318004-05 1db
-318030-01 C16/plus4 Kernal PAL Magyar Rev1 1db
-318006-01 C16/+4 basic rom 1db

 

-MOS 6502 VIC-20/1541 CPU 1db
-1541 lower ROM 325302-01 1db
-1541 upper ROM 901229-5 1db
-MOS 6522 Via I/O VIC-20/1541 2db

 

-BLUE CHIP BCD/5.25 DISK DRIVE(1541 klón) MEL9501-40 8520 motorvezérlő 40PIN 1db









Ár: megegyezés szerint

ergoGnomik Creative Commons License 2018.10.01 -1 0 8947

Mert mondjuk megy a finomscroll a Plusinak? Egy kicsit feltennéd a gondolkodó sapkát? Ha nincs hardver sprite és multicolor felbontásban csinálod a grafikát milyen lesz a látvány ha a képpontnál kisebb eltolást alkalmazol? Csak nem jobbra-balra (előre-hátra) fog fűrészelni a mozgó objektum? Jól nézne az ki?

 

De persze ismerhetsz olyan grafikai és programozási technikákat, amivel ezt sikerrel el lehet kendőzni a látvány és a teljesítmény romlása nélkül. Szerintem minden 16-os és pluszi tulaj és rajongó nagyon örülne, ha megosztanád velünk ezt a titkot.

Előzmény: Sheme (8946)
Sheme Creative Commons License 2018.10.01 0 0 8946

Mondjuk a finomscroll még mindig nem megy a Plusinak, de miért nem? Nagyon darabos, igaz, nem karakteres balra scroll van, talán 4 pixeles, de passz, az biztos, h nem pixelnyi a lépésköz, hanem nagyobb.

Előzmény: Sheme (8945)
Sheme Creative Commons License 2018.10.01 0 0 8945

Armalyte / IO klónnak tűnik. Mindenesetre gyönyörű munka, gratulálok!

 

Végre kihasználják a Plus/4-et, mert eddig nagyon sok, gyatra grafikával és animációval megáldott játékot írtak rá.

Előzmény: epy116 (8943)
epy116 Creative Commons License 2018.10.01 0 1 8944

Pi1541 display upgrade. Egy Amiga Gotek projectből visszamaradt kiskijelzőt rákötöttem a Pi1541-re, tök jól működik. Ami elég furcsa benne, hogy nem találtam olyan demót C64-re ami ne menne vele, szóval úgy tűnik, hogy 100%-os a 1541-es drive emuláció, de mégsem, mert Plus/4-en a 'Pets Rescue' az 1. pálya betöltése közben kifagy.

epy116 Creative Commons License 2018.09.28 0 0 8943
O.R. Creative Commons License 2018.09.25 0 0 8942

Megj. hogy topiktéma maradjon: a Plus/4-en is lehet játszadozni vele, pl. ha kikapcsolod a képet, és/vagy átkapcsolod fix slow clock-ra stb., szintén jelzi neked pontosan a CPU átlagsebességének a változásait (ld. 0.89 vs 1.70 MHz és társai). Sajnos pont a legérdekesebbik mérésre azonban NEM alkalmas: a PAL/NTSC átkapcsolós TED-bit "turbó" trükk esetében nem értelmezhető (azért nem, mert pont a képfrissítést használja fel fix pontnak a méréshez, ami ekkor ugye megváltozik valahogy, és nem tud tovább támaszkodni rá). Még VIC-20-on is működik a módszer egyébként.

 

Ha tényleg készítene egyszer valaki egy turbókártyát Plus/4-re (mint amit itt emlegetett valaki), azt is lehetne majd mérni vele valószínűleg... (Feltéve, hogy a TED chip működése közben nem változik meg.)

Előzmény: Törölt nick (8937)
MMSZoli2 Creative Commons License 2018.09.24 0 0 8941

Még annyi, hogy ha az IEEE-488 interface-be ölöd az idődet (vagy atz IEC22IEE-re), arra akár a Commodore IEEE HDD is ráköthető.

Plus/4 OFF
 Sőt láttam egy nagyon exkluzív CP/M terminált PET-re, ami az IEEE interface-en és egy programon keresztül "rabszolga sorba" (terminálüzemmódba) száműzte a PET gépet, és egy teljes CP/Met futtatott egy kvázi külső gépen, a PET csak a billentyűzet és megjelenítő szerepet töltötte be. Mivel másodpercenként kb 1.4KB-ot tud áttölteni az IEEE trükkök nélkül, ez pont elegendő volt a (fekete fehér) karakteres képernyőtartalom frissítésére. 
http://mikenaberezny.com/hardware/pet-cbm/sse-softbox-z80-computer/
http://mikenaberezny.com/wp-content/uploads/2011/05/softbox-schematic.png
Very complex :-D

 Ez  kissé butaságnak tűnhet, csakhogy akkoriban a CP/M olyan fejlettségűnek tűnt, mint később az MS-DOS, tehát ez az eszköz kvázi PC emulációt csinált a PET-en (Pascal, C compilerek, Wordstar profi szövegszerkesztő, stb lettek vele elérhetőek, futtathatóak, egy CP/M masina árának töredékkéért). Ráadásul erre még HDD-t is lehetett kötni, amiről a CP/M boot-olhatott.

 Aki még ismerte a PC XT szintű vonalat, az nagyjából képben van, milyen (még nem garfikus felületű) jellegű programokról beszélek. (A C64-re volt egy hasonló CP/M cartridge, csak az az esetek 80%-ban nem működött, A C128 már igen).

Plus/4 ON

A CP/M csak 80 karakteren működött, tehát a folyamatosan futó terminál program mellett még egy soft 80 column üzemmód vitelezése is szükséges lenne, hogy CP/M-et lehessen futtatni Plus/4-en. Hogy ez mire lenne jó? Profi karakteres szövegszerkesztő a 3+1 helyett :-)

 

MMSZoli2 Creative Commons License 2018.09.24 0 0 8940

1551 VS SFD1001

 

(komment: épp el akartam magyarázni, hogy wzerintem az 1551 és a IEEE interface-ek alapvetően máshogy működnek, és ránéztem a CMD IEEE Interface-ére (CIE a neve)  és pont ugyanazt a "haszontalan" MOS 6525 IC-t alkalmazza, mint az 1551, vagy a Commodore sajár C64 IEEE inteface-e  ooooopss).
Egyébként ugyanez az IC volt használva a CDTV-ben, meg az A570 Amiga CD lejátszóban. Szánalmas, hogy milyen elavult alkatrészek voltak az 1551-ben :-D 


Úgyhogy ha az 1551 C64-re kötését tervezed, akkor érdemes erre ránézned, valami hasonlót végzett a CMD a lenki áramkörrel, csak IEEE-488 eszközökkel (hasonló 8 bites adatátvitel és sebesség, persze más a protokol)
https://imgur.com/a/bIDjqEb

Egyébként a CMD IEEE eszköze az, ami az egyik legegyszerűbb és legelegánsabb (szerintem), összevetve pl. a Commodore saját C64 IEEE488 vagy VIC1122 Cartridge-al (VIC-20-hoz).

 

Emellett vannak a IEC-re IEEE eszközöket csatoló cartridge-ek, ezek gyakorlatilag online fordítják a jeleket.
A legbonyolultabb az Interpod nevű eszköz, ami az IEC-re mappel RS232 és IEEE488 interface-eket. elég bonyolult. 

Ebből a legolcsóbb és legelegánsabb megoldás az NLQ.DE(Jochen Adler) által kifejlesztett ATMEL alapú kapcsolás, amit Codekiller fejlesztett tovább az engedélyével, jóval kisebb helyen megvalósítva ugyanazt a funkciót, egy centronics csatlakozó házban elfér.
http://www.nlq.de

 

 

 

 

Előzmény: Sheme (8938)
O.R. Creative Commons License 2018.09.24 0 0 8939

A program lehetőség szerint csak az aktuális állapotot méri fel (ez benne van a leírásában), de lehetőleg minél átfogóbban, részint pont azért, hogy össze lehessen hasonlítani az eredményeket. Pl. ha kikapcsolod előtte a képernyőt, vagy sprite-okat helyezel el a képen stb., akkor nyilván minden egyes ilyen esetben egy kicsit más-más lesz a vége. Éppen ettől érdekes, mert látni vele, egy-egy adott változtatás mivel jár. Nekem nincsen SCPU-m (mint ahogyan nincs MEGA65-öm sem), csak feljegyzem a mások által visszajelzett adatokat. Nem tudom, ők hogy állították be a hardvert előtte. Ha neked van, és lenne kedved megvizsgálni többféle beállítás mellett, akkor nagy örömmel látnám, mit hoz ki. (Amúgy mivel open-source, a forráskódban megnézheted pontosan, hogy mit csinál.)

Előzmény: Törölt nick (8937)
Sheme Creative Commons License 2018.09.24 -1 0 8938

Tehát van rá - elvi - lehetőség, h a C-64 kezelje a 1551-et.

 

Úgy gondolom - 99%, h eltévesztettem a házszámot! -, az SFD1001 megoldásából kéne kiindulni, ugye? Mert közvetlenül NEM lehet kezelni a 1001-et, kell egy kezelő program, amit ez az IEEE488 kártya tartalmaz. (Nem tudom, mi a kártya neve, ex-has elneveztem.)

 

Valamilyen elven belapozgatja a 1001-ről jövő adatokat valamelyik lábon keresztül - felteszem, EXROM-nak mondja a 1001-et és az IO1 - $DE00(?) -, vagy IO2-es - $DF00(?) - lábon keresztül belapozza a valamelyikük területére a byte-okat?

 

Az 5-ös lábon keresztül lehet eldönteni, írás / olvasás legyen. Gondolom...

 

Az EXROM-on keresztül az alapgép bekapcsolásakor betölti a 1001-et kezelő rutinokat, de lehet, tévedek.

 

Mintha Gaia Mester írta volna valamikor, h mely memóriaterületre - talán a $FEC0 / F0-ra? - lapozódik be a 1551-es. Ezt - elvileg - be lehet adni a C-64 oldalról is neki, h ide van belapozva, eze(ke)n a címe(ke)n keresztül látszódik.

 

Ha ez így igaz - kizárt, csak elmélkedem! -, akkor már "csak" meg kell tudni szólítani a drive-ot, valahogy. Talán a YAPE-ban lévő kezelőrutinok átírása segít? Sokat kellene módosítani? Mondjuk ezt az emulátor írója tudná megmondani...

 

Röviden összefoglalva:

- hasonlóan a 1001-et vezérlő crtg-hoz, valami ilyesmi programmal kéne elhitetni a 1551-gyel, h Plus/4-en van?

 

- mennyit kell(ene) módosítani a YAPE-s emulátorban lévő 1551-et kezelő rutinon, h C-64-en fusson? Talán a C-64-nek megfelelő memória-címekre módosítva működhet?

 

- vagy van kifejezetten 1551 specifikus cím, címek, ami miatt cím-konverzió kell? Pl mondjuk $8000 "fölé" töltendő program esetében ugye a ROM alá kell tölteni, ami Plus/4-nél nincs, ott kb 57 kByte-nyi közvetlenül elérhető RAM van.

 

- hw-esen "közvetlen" össze lehet kötni a C-64-gyel? A feszültségek (+/-) ugyan azok?

 

Most tekintsünk el attól, h nem lehet kapni Plus/4-es expansion portot, azzal később is ráérünk foglalkozni - egyet fel tudok ajánlani!

Előzmény: Törölt nick (8934)
Törölt nick Creative Commons License 2018.09.24 0 0 8937

Pluszi OFF:

Az SCPU kint a gyors statikus ramban "tükrözi" a gép ramját (ha ezt egy-egy lapra bekapcsolod), plusz van egy egyértékes regiszter, egy "mikro-fifo" ami majd megvalósítja az írásokat, ha a lassú busz "ráér". Tehát olvasásra a gyorsan beírt másolatból azonnal kapunk értéket, írásra meg sem kell megvárni ameddig a lassú buszon teljesül.

 

Ha jól emlékszem, a nagyobb PLD-s V2 CPU-ban ez már igazi fifo, tehát megszabhatod hány értéket akarsz "várakoztatni", a gyors végrehajtás mindaddig nem vár arra (vagy te várhatsz tervezetten!) amíg tele nem lesz a fifo..

 

Kivéve az IO terület, mert ott a tényleges beolvasott értékre vagyunk (feltehetően) kíváncsiak, nem egy statikus másolatra, és írásra sem mindig tanácsos saját időzításünk helyett egy random "na most lehet" első szabad pillanatban rádobni az értéket.

Ezektől bonyolult az SCPU, hogy mindez regiszterekkel konfigurálhatóan meg van valósítva benne.

 

Ha fogunk egy gyors "emulátort",(nevezzünk most így mindent, ami nem az eredeti VAS), ami pl. vga képet rajzol, és az eredeti gép időzítéséhez semmi köze, teljesen  mindegy, hogy szoftvres emulátor vagy módosított gyorshardveres másolat, ezek a problémák nem merülnek így fel, nyilván gyorsabb rendszert lehet csinálni, határ a csillagos ég.

 

Pont ez volt a nagy ötlet az SCPU-ban, nem az egész gépet replikálja (ez akkoriban lehetetlen lett volna) még az IO-t is meghagyja a helyén, nem kell beledugni a floppy-t, nem kell külső billentyű, nem kell semmi, sőt a belső 64k lassú ramot is használhatod egyfajta lassú"tárolónak", mégis van egy külső gyorsabb procid, neki való gyors külső rammal)

 

Tehát ha nem tudsz és akarsz SCPU-t programozni, csak elindítassz egy ilyen progit, más értékeket kapsz,...

....  -akár magával a progival- is más lenne, ha előzetesen konfigurálnád, hogy mindezek a műveletek fussanak kint és csak kint a gyors ramban, rögtön nem várnánk a lassú buszra és ha nem is 20 de 14-17 mhz körüli értéket adna (ha jó a program, és helyesen számol, ekkora sebességnél is)

 

Pluszi ON

 

 

 

 

Előzmény: O.R. (8935)
MMSZoli2 Creative Commons License 2018.09.24 0 0 8936

Király cucc! :-D

Előzmény: O.R. (8935)
O.R. Creative Commons License 2018.09.24 0 0 8935

Igazából azért az a SuperCPU sem olyan nagy adu ász, mint amilyennek látszik elsőre, mert van pár hátulütője, legalábbis 8-bit turbó tekintetében. (A 16-bites használata lenne inkább érdekesebb, de arra meg nincs szoftver.) A külső és a belső memóriák összehangolása egész sokat visszafékezhet, ha úgy jön ki a lépés. Ha pusztán a CPU pörög magában, úgy igen, az 20 MHz, de minél több a memóriaművelet a kódban, végül átlagosan annál lassúbb lesz.

 

Tavaly írtam ezt a kis MemTest64 nevű proggit (mely Plus/4-en is fut amúgy! szóval ez itt ontopik ;) ), ami nemcsak a memóriabővítőket teszteli, de többek közt megméri a CPU sebességét is, vagyis olyan formában, hogy tapasztalati úton mennyinek érzékelhető a szoftver számára. Lásd alább:

 

http://lemon64.com/forum/viewtopic.php?t=65168

 

http://csdb.dk/release/?id=158763

 

http://mega65.net/memtest64

 

Ezzel tesztelve az SCPU-t például, csak kb. 8-9 MHz körüli sebességek jönnek ki (még egyszer a kulcsszó: sok-sok memóriaművelet az első 64K-ban).

 

Ugyanez a Turbo Chameleon esetében több, mint 14 MHz. A MEGA65-ön kb. 36 MHz jött ki (de ez még csak tavaly volt, majd meglátjuk, a végső verzióban mennyit nyom).

 

Kíváncsi leszek majd az U64-re, ha egyszer eljut odáig, mert Gideon szerint akár 31 MHz körüli turbóteljesítmény lenne saccolható rá.

Törölt nick Creative Commons License 2018.09.23 0 1 8934

Már írtam...

...itt nem ez az igazán "nehéz"!

 

Hanem hogy valaki megírja az 1551 normális kezelését C64-re.

Darab drótokkal egyébként itt (sem) lehet, kell némi áramkör is.

 

De ha drótokkal sikerül, oké, és?  A csupadrót kártyára úgyis kellene eprom is,...

...legalábbis gondolom nem először 1541-ről akarod betölteni az 1551 loadert,  majd utána tudsz csak 1551-et használni.

 

... kivéve amíg valamivel felül nem töltöd, vagy az első reset, runstoprestore vissza nem "löki" a vektorokat..ugyebár.

 

Az áramkört, meg kell tervezni, részben le kell szimulálni(tanácsos), majd összedrótozott prototipusokat építeni, kisérletezni, mérni, mint anno pl. a boticelli hardverkulcsnál csináltuk itt, olvasd csak vissza.

 

Kell szoftveres guru, "code supporter" is, abban a projectben volt egy topic beli kollega, aki szoftveres patchet irt a feladatra, annyira visszafejtette, itt ilyen mélységbe kellene a C+4 kernalba belemenni, majd adoptálni C64-re.

 

És sokkal jobb team együttműködés lenne szükséges,...csak épp kinek van ennyi deje.....néha te sem irsz hetekig...(sőt)

 

Ott belefért, hogy 2-3 naponta ír valamelyikünk választ vagy kérdést, vagy akármit,  itt ha valami félremegy, meg sem mukkan a drive, és mivel az egész gépet mindenestül nem lehet áramkörszimulátorban megvalósítani, senkinek halvány fingja nem lesz, mi a bánat történik, mi nem jó.

 

Ez nem a kis-isis kössük össze az egyforma akármiket feladat, akármennyire is szeretnéd ezt hinni, ha az analóg tv bemenetét bekötöd hdmi-re sosem lesz semmiféle kép.

 

Igen, ettől még a dolog lehetséges, elvben.

Hasonló a két gép, a két busz, nem látszik előzetesen olyasmi, ami teljesen lehetetlenné tenné, még akár egész kevés alkatrésszel is, de nem arról van szó, hogy kössünk össze 10huzalt meg írjunk le pártucat utasítást és kész, hurrá.

 

Egyetlen egy miatt írtam le ezt, azthiszem újra, mert egyszer már röviden vázoltuk itt a lehetőségeket.

 

Nagyon-nagyon régen, valaha, nekem is volt ilyesmi perverzióm, még a hőskorban, a 80as években álmodoztunk, micsoda szupergép lenne, ami egyben lenne C64 és Plusz4 IS.

Akkor a haverok fele azt mondta ez teljesen lehetetlen, másik része, hogyha lehet is, totál hülyeség, csak mi tartottunk ki a baromságunk mellett, hogy de akkor mi lennél, plusz vagy C64es, hát, kisöcsi, mindkettő, de egyben(!) és elővenném a SzuperGépet.

 

Azóta sok víz lefolyt a dunán, és nem is voltunk teljesen egyedül akkoriban a hülyeséggel, Csory nevű hardware guru, tőlünk teljesen függetlenül álmodozott (tudtunk nélkül, tőlünk függetlenül) kb jó 5 ével később komplett VIC beépítéséről a plusiba, meg készült SID hang, meg stb.

Mostanra ez viszont valami olyan, mint veterán mercit és veterán fiatot keverni, agymenés, és feltehetően keveseknek tetszik.

 

Mondjuk a pluszi "képességeit" sokban "bővítené", ha korlátosan, egyes régen létező C64 bővítések elkezdenének "kicsit plusz4 bővítések" lenni, talán...bár ez sokakat nem igen érdekelne megintcsak, akik annak szeretik a gépet ami, és nem akarnak kicsit sem "valami mást" csinálni belőle.

 

Tehát az irány kérdéses, viszont errefelé lenne valamiféle lépés lenne az 1551---C64, azonban teljesen jelképes lépés.

100% kompatibilis lemezmeghajtó most is van, tehát nem visz ez sehova, így valószinűleg sosem lesz belőle semmi.

 

 

 

 

 

 

 

 

 

Előzmény: Sheme (8932)

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