A plus4world-ön levő bitang nagy doboz csak kamu lehet, ha a joystick portra kell dugni, azon ugyanis nincs analóg bemenet, tehát legjobb esetben is csak egy joystick-ként emulált (vagy joystick módban működő 1351-ről) lehet szó és a doboz ugyanazt csinálja, mint a mezei joystick átalakító kábel.
TCFS valamelyik programjának az elején volt a vezérlés választás, vagy a Terra-X vagy a Blue Angel 69 lehetett, mert akkoriban csak azokkal játszottunk a tesómmal.
Az RS232 a User Port-on egér működhetne, de nincs rá program, vagy működő rezidens kód. Elég sokat kell toszogatni jobbra-balra a biteket. Nulláslapba nem fért el, amit kaptam, illetve farigcsáltam, de nem vagyok valami nagy kóder... Maga az RS232 egér által küldött adatok elég alaposan ki lettek vesézve, csak szerintem valahol elrontom a kalkulációt, valami túlcsordul, vagy rossz helyre fut ki és BRK...
Esetleg kiírhatunk egy pályázatot, a nyertes kap tőlem egy működő RS232 IBM vagy A4Tech dobozos egeret (csak mondom, hogy már csak aranyáron lehet ilyesmit szerezni) és egy karton középkategóriás sört vagy vele egyenértékű akármit. (nem vicc!)
igen, valaki alatt én is őt értettem :D másra nem emlékszem (közben a plus/4 world-ön találtam joystick portos egérillesztőt, bitang nagy dobozban van és nem tudom, hogy soros vagy C64 egeret fogad, mert semmi infó nincs róla)
Én is csak bszggg user portos egéradapterét ismerem a saját programjával. De valahol láttam egy játékot is aminek az elején lehet választani, hogy egér, joy vagy keyboard-ról akarom irányítani! Minden esetre érdekes!
Szerintem nem nagyon van ilyen. C64 egeret nem lehetett illeszteni, mert az összes joystick adapter a föld jelet kötötte a select kimenetre, azaz folyamatosan megszaggatta a földet. A C16-on user port sincs. Proof-of-concept szinten láttam, hogy RS232 egeret illesztett valaki user-portra, de valami saját demóján kívül más nem használta. BSz tett ilyet a saját SID-kártyájának a teszt programjába, mert arra tudsz C64-es 1351, Amiga vagy Atari ST egeret dugni.
Ehhez még tegyük hozzá, hogy a C128-nál az első kiadásakor (16k) semmilyen nagy felbontású VDC grafikus módot sem említettek meg hivatalosan, egyszerű 80 karakteres kijelzést támogató RGB kimenetes termékként volt a C128 reklámozva (a CP/M kompatibilitás miatt).
Egyébként a C128 fejlesztés során (az IC abbab afázisában) sorra döglöttek meg a VDC chip-ek, úgyhogy mindig volt egy tucatnyi tartalékban. Talán emiatt nem is erőltették annyira a dolgot.
Magyarul ha valakik nem fejtik ezt meg, és nem publikálják, akkor talán a 64K-s VDC kiadás sem történik meg a Commodore részéről.
A GATE-In a végső, piacra került gépekben mind kvázi szükségtelen.
Az újabb 8501 procin már kb semmit nem is csinál. Ideoda el van vezetve a fémezésen, és be is van kötve a tokon belül, de mintha egy kamu lenne az egész.
Hogy miért kellett egy céges szintű önátb@szás végig evvel kapcsolatban, azt a titkot szerintem "sírba viszik magukkal" a MOS szakemberei.
Roppant érdekes anekdota lenne, de kb már az sem emlékszik semmire, aki anno a 80as évek elején naponta benne dolgozott.
IT mércével felfoghatatlan sok idő telt azóta el, akik akkor +negyvenes középkorú vezető mérnökök voltak, már agastyánok vagy nem élnek. Plusz rengeteg gányolás, hekkelés, és belső, ennél jelentősebb botrány volt (pl a 6522-k shift regiszter hibája)
A VDC "csodálatos memóriabővítése" azon az egyszerű tényen alapszik ,hogy a VDC egy teljesen másra szánt chip, amit hirtelen bedobtak a C128-ba, mellé némi dedikált ramot.
Különösebb erőfeszítés nélül képes sokkal többet címezni és használni, ez megint egy olyan ,hogy eredetileg nem tervezték bele a gébe, amit a chip tud, de utólag pótolható. (mint a gyors IEC busz, a shift regiszter hiba javítása után, vagy a kétoldalas 1541-II, amihez az író-olvasóerősítőn megvan a második fej helye, csak nincs oda bekötve semmi, stb,stb)
A gate_in jel nélkül is teljesen jól működik a 6510-es processzor helyettesítés. Megcsináltam én is és még a kenelt is átírtam, hogy legyen floppy vezérlés. Amit beraktam lentebb képet a 7501-es proci működéséről ott látszik, hogy amikor az órajel Q0 alacsony, az AEC szinén, és amikor a MUX magasból alacsony jelre vált, akkor az R/_W jelet "HOLD"-ba rakja, mindaddig amíg a ugyanez a 3 jel magasba nem vált. Hogy az R/_W jelnél a "HOLD" állapot mi, az gondolom mindig az adott jelszint. Szerintem! De majd az okosabbak megmondják! :-)
Amúgy dióhéjban a dolog lényege csak annyi, hogy az MMU-nak vannak regiszterei, ahol egyszerűen beállítható, hogy a verem és a nulláslap is külön-külön melyik bankban és azokon belül melyik lapon legyen, és attól kezdve azok tartalma virtuálisan megcserélődik az eredeti lapok tartalmával.
Azon túl, hogy ez itt témaidegen, úgy gondolom a VDC alá kell betenni, és nincs szükség más módosításra. Ennek SaRuMan-VDC a neve. Meg kellene keresned a kitalálóját és vele egyeztetni a továbbfejlesztésről.
Nem volt övön aluli, mert nem a Z80 és a blokk mozgatási képessége volt a téma, hanem a rugalmas memória lapozás. Azt meg mindegy milyen processzoros rendszerben valósítják meg, a lényeg a memória szabad átszervezhetősége.
Egyébként bár nem vagyok teljesen képben a Z80 programozásával, de egyszer mintha olvastam volna valahol olyasmit, hogy a blokkmozgató utasításoknál lehet gyorsabbat írni, és ott is talán a PUSH-sal trükköztek valamit.
Speed kód alatt általában azt értjük, amikor a rendszerint ciklusba szervezett műveleteket "kigörgetjük" (unrolled loop), vagyis a ciklus magot többször (sokszor) egymás után lekódolod úgy, hogy a ciklusszervezésre "elpocsékolt" időt megspórold.
A C=128-ban kijelölheted, hogy a 2×64 KB memóriának valamennyi része közös legyen. De a nullás lap és a verem áthelyezésére nem emlékszem. Ugyanúgy a speed kódra sem. Írnál ezekről néhány mondatot? (!!!)
Ellenben az 1750-es bővítőben a DMA gyorsan tölt, ment, cserél. Ugyancsak érdemes átkapcsolni a beépített Zilogra, ha nagyobb területet akarsz mozgatni (és nincs bővítőd). Ha pedig 128R féle géped van, akkor a VDC-ben is tudsz egynéhány képet váltogatni.
A fadados módszert (hogy az egész 64K-t átkapcsolja cakkumpakk) a CBM-II sorozatban használták, és nem véletlen nem vált be. Építettek köréje egy nyakatekert Kernal-szintű környezetet, ami 2-4 bankkal eléggé jól elboldogul a Basic interpreter céljaira (az egyes változótípusokat szétosztja ez egyes bankokba, így csak a Basic programkódnak fennmarad egy teljes 64K egyben), de azon kívül bármilyen más célra alkalmazni rémálom.
Azonban a C128-ban ehhez képest rengeteget finomítottak, és ott nagyon rugalmasan kihasználható - viszont ahhoz pedig kellett már egy komplett MMU vezérlőchip, ami nagyon bonyolult. Azzal megteheted például, hogy a nulláslapot átirányítod az egyik bankba, a vermet meg egy másikba, majd azután LDA $xx / PHA utasításpárokkal és speed kóddal egész gyorsan lehet adatokat mozgatni a kettő közt (vagy a képernyőt is átteheted másik bankba stb.). Programozás szempontjából csúcs, ám igen komoly hardverháttér dolgozik meg érte mögötte.
Hát, a Hannes bővítő gyakorlatilag egy-az-egyben a C64-es +240k bővítés plus/4 implementációja. Anno inkább az volt a szempont, hogy minél kevesebb TTL áramkörből kihozzák.
Jah, megint tanultam pár dolgot, köszi Mindenkinek!
A teljes 512K -nak külön örülök, majd lehet hogy összehozok egy képnézegetőt a Conan képregényből, ami az egyik első (nem túl sikeres) slideshow próbálkozásom volt :-) (még mindig sokkol, hogy mint az Apple Macintosh, mind az Atari ST ennél kevesebb memóriával került a piacra az indulásnál, de talán az Amiga 1000 is)
(egyébként leszámítva a Lotharek cuccot, nem került olyan sokba a dolog (ami azért egy elég fájó pontot érint, szerintem a megpusztul 8501 miatt halott gépek benne vannak a top3-ban))
A RAM bővítésről:
Ha ez együtt jár egy ROM bővítéssel együtt, ami ezt az egészet lekezeli (X helyre belapozva), az ott elhelyezett dedikált rutinok el tudják végezni a műveleteket a teljes RAM csere esetén/után is. Szerintem ebben az összefüggő nagy blokkos memória felosztásban a plus/4 kifejezetten jó, nincs úgy szétnyirbálva, mint a C64-é.
Ha már kompatibilitás, Hannes/Csory és egyéb bővítések nem csak úgy ad hoc módon lettek összelapátolva, volt koncepció mi hová menjen összeakadás nélkül (a MIDI inteface azért érdekelt volna mit tud...): http://plus4world.powweb.com/kb.php?id=500249
$FD00-$FD0F ACIA-chip (6551/8551) $FD00-$FD03 Effective range for ACIA $FD03-$FD0F Mirrors of $FD00-$FD03 $FD10-$FD1F Userport 6529B-chip (original) $FD10 Effective adress for 6529B (original) $FD10-$FD1F Mirrors of $FD10 (original) $FD10-$FD1F Userport-area (plus/4 with expansion) $FD10 6529B-chip from userport $FD11-$FD12 Centronics-printerport $FD13-$FD14 Low-/high-switching for OS96 $FD15 Register for CSORY-RAM-expansion $FD16 Register for Hannes-RAM-expansion $FD17 Register for EPROM-/sRAM-expansion $FD18-$FD1F Free (best for internal expansion) $FD20-$FD2F Used by different hardware, decoded by PLA (pin 18) $FD30-$FD3F 6529B for keyboard $FD30 Effective adress for this 6529B $FD31-$FD3F Mirrors of $FD30 $FD40-$FD5F SID-card, area for SID-chip $FD40-$FD5D SID-chip $FD5E DAC on digiblaster add-on $FD5F ADC on digiblaster add-on $FD60-$FD7F Area for expansion-userport $FD60-$FD63 ACIA on card 1 $FD64-$FD67 ACIA on card 2 $FD68-$FD6B ACIA on card 3 $FD6C-$FD6F ACIA on card 4 $FD70-$FD73 6529B-emulation on card 1 $FD70 Effective adress for 6529B-emulation $FD71-$FD73 Mirrors of $FD70 $FD74-$FD77 6529B-emulation on card 2 $FD74 Effective adress for 6529B-emulation $FD75-$FD77 Mirrors of $FD74 $FD78-$FD7B 6529B-emulation on card 3 $FD78 Effective adress for 6529B-emulation $FD79-$FD7B Mirrors of $FD78 $FD7C-$FD7F 6529B-emulation on card 4 $FD7C Effective adress for 6529B-emulation $FD7D-$FD7F Mirrors of $FD7C $FD80-$FD8F Joyport on SID-card $FD80 Effective adress for joyport $FD81-$FD8F Mirrors of $FD80 $FD90-$FDCF Free $FDD0-$FDDF Area for ROM-banking $FDE0-$FDE1 MIDI-interface $FDE2-$FDEF Free $FDF0-$FDFD Free $FDFE Register on EPROM-card $FDFF Register on sRAM-card $FE00-$FE7F Free (best usage for a RAM-drive...) $FE80-$FE9F SID-card, mirror from $FD40... for hungarian-compatibility $FE80-$FE9D SID-chip $FE9E DAC on digiblaster add-on $FE9F ADC on digiblaster add-on $FEA0-$FEBF Free (?) $FEC0-$FECF Floppy 1551, device 9 $FED0-$FEEF Free (?) $FEF0-$FEFF Floppy 1551, device 8
Ennyire talán nem rugalmasak. A Hannes 4db 64k-s lapból dönti el, hogy melyiket látod a váltási határ (4k vagy 16k) fölött, a váltási határ alatt mindig az alapértelmezettet. A Csory-nál meg a 64k-s címtartomány 1db 16k-s lapjára mondhatod meg, hogy a 16db 16k-s lapból melyiket látod ott. Tehát egyszerre van 3 alapértelmezett és 1db lapozott szegmensed.
(és egyébként MMS-nek info: a Lotharek féle bővítőn tudod használni mind az 512k-t, tehát ott 8db 64k-s lapból választhatsz, a leírás csak arra vonatkozik, hogy a vezérlése kompatibilis a Hannes 256k-val)
De például az Enterprise 64/128 számítógép is pont így csinálja, hogy bárhová be tudod lapozni a tetszőleges 16 kB-ot a lehetséges 4 MB-ból. De a 128 k-s ZX Spectrum is azt csinálja, hogy két lapra ki lehet választani, hogy milyen memória legyen ott. Legjobb tudomásom szerint.
Tudtommal a Hannes és a Csory memória bővítés. A Hannes-féle lehetővé teszi hogy a négy 16 k-s lapra egymástól függetlenül belapozd valamelyik 64 k megfelelő lapját, de az alsó nem tudom mennyi memóriát fixen belapozva tartja. A Csory-féle pedig biztosítja, hogy a négy 16 k-s lapra a 256 k bármelyik 16 k-s szegmensét belapozd. Amennyire én tudom. Ez rugalmas, de nem nagyon támogatja az eredeti BASIC. Talán az OS92/OS96 ki tudja használni.
Már bocsi! De ki csinálja másképp? Én (és a C=128) csak és kizárólag az akku tartalmát tudom mozgatni. X regiszter a lapkód, Y pedig a számláló – indexeléshez.
