Mostmar csak azt kene megmondja valaki, hogyan kell az EP serialt PC- vel osszekotni, mer ez a magno, ez egy vezercsiga.
Tehat valahonnan tisztaban vagy a reszletekkel. De honnan ?Igaz, nem nekem lett címezve a kérdés, de mivel foglalkoztam én is a témával (lásd TAPir (http://enterpriseforever.com/emulatorok/tapir-t140.0.html)), így leírom a saját "verziómat" ;-)
Leader | Sync | Zero | One | |
Normal sebesség | 9 | 15 | 11 | 7 |
EPTE max speed | 7 | 11 | 8 | 5 |
Turbo, ezt az emulátorom még beolvasta | 2 | 3 | 3 | 8 |
Nekem az rémlik, hogy a BAM-féle másolóprogramokkal lehetett turbósan menteni, 3200 baud esetén még turbó betöltõ nélkül sikerült betölteni a programotÉn ha jól emlékszem 2700-at használtam. A TPT leírásban 2950 szerepel, mint amit elbír a gyári betöltõ rutin.
ha jól emlékszem, akkor 4000 baud volt a max, amit már csak a turbó vitt4800
István gondolom más utat követett vagy esetleg rögtön tudta, hogy az FSK (http://en.wikipedia.org/wiki/Frequency-shift_keying)-ról van szó. Erre én azután jöttem rá miután már túl voltam a fenti kísérletezésen ;-)
Ha jól értem, akkor nemcsak a frekvencia növelésével lehet gyorsítani, hanem az ismétlõdések csökkentésével is?
Én ha jól emlékszem 2700-at használtam. A TPT leírásban 2950 szerepel, mint amit elbír a gyári betöltõ rutin.
Nekem PC-rõl másolva még a 3100 is mûködöttGondolom az is bejátszhat, hogy a töltõ rutint teljesítõképességének határánál már sokkal fontosabb a tökéletes jelalak, így PC-rõl küldve tovább lehet elmenni, mint valódi kazettáról.
es azert rossz mert valszeg a z80 cpu nem lenne eleg semmire ( ill. max ketszerezesre vagy ilyesmire, az meg nem eleg).
Na szo ez a baud ertek a PC holdalon hangkartyanal maximum 44KHz lehetne
Tehat elvileg egy pc hangkartyaval meg 44 KHz- es negyszogjelet le lehet generaltatni.
Kerdes hogy az EP oldalon a detektalo kod, az mibol all, mert errol meg nem hallottunk semmit
A masik kerdes ami beugrik, hogy a szalagon eleve valtakozo jel van, tehat nincs neki egy szintje, amihez kepest a bit beallhatna
Igy gondoltam lejatszom neki az egy masodperces 1 khz negyszoget es akkor 1000- et kell kapjak a szamlaloban vagy 2000- et, nem tom mi szamit egy ciklusnak.
Eloszor lefuttattam jel nelkul, tesztkent, es mar ez meglepo volt, mert ugy ter viszsa a kod jel nelkul, hogy par (5 vagy 20, vagy 76, vagy ilyesmi szamot, valtozot) valtozast detektal, mire lejar a hosszu ido, hogy ha addig nincs valtozas, akkor kilepjen.
Amikor az egy kilohercet szamoltattam megvele, akkor 1700 koruli szamot adott. Hat ez eleg sz**...
Mondjuk szemmel nezve a jelet nem tul szep, eleg trapezos .... nem tud valaki adni nekem egy 1 masodperc 1khz tomoritetlen sample- t. tehat tomoritetlen wav, nem mp3.Nem tudom, ilyenre gondoltál-e... mondjuk szinuszhullám lehet, nem négyszögjel.
Mondjuk szemmel nezve a jelet nem tul szep, eleg trapezos .... nem tud valaki adni nekem egy 1 masodperc 1khz tomoritetlen sample- t. tehat tomoritetlen wav, nem mp3.
Eleg gyenge a hangkatyim kimenete, nem mozditja at maxi hangeron sem a standard toltestkijelzot a pirosba egyszer sem, de azert a standard toltes teljesen zolden is mukodik.TAPE LEVEL-t is felnyomtad az emulált gépen mentéshez?
eszem all meg ...
az 1khz.com -on 1707 -et szamolt.
namost az elotte kapott wav az egy 3 mp- es szinuszjel. azon 5103 -mat szamolt.
namost mennyi 1700 * 3 ? :)
= 5100 ! :)
Most kipróbáltam egy olyat, hogy az emus EP-t turbózom, így kb 5.168 Mhz a határ amit az alap 4 Mhz-es gép betölt. (emu beállítások: 5168000 CPU frq, 646000 Sound frq)
Vagy kene trukk asmonbol remote allitasra, vagy az asm kodbol kene valami trukk az eleresre
Ez megfelel a TPT-nél tapasztalt 3100 bit/s körüli határnak.Viszont úgy tûnik, hogy a LOAD részbe annyira nem piszkált bele a Haluska Laci, TPT-s emuról TPT-s gépre esetén már nem megy el ugyanilyen arányú túlhajtás, vissza kell venni 2500-ra a tempót, ami azt jelenti, hogy kb 3230 amit a TPT LOAD rutinja felismer 4 Mhz-es gépen.
Zozo te azert preferalnad a hivatalos modszer turbozasat, hogy 1Xû megoldas legyen, es kompatibilis az ismert dolgokkal ?
Ha új dolgot fejlesztünk, akkor újra fel kell találni ahhoz sok mindent: szinkronizálás, CRC ellenõrzés, stb, hogy megbízható legyen.
Es az igy megnovelt ideju ciklusmag mar csak toredeket tudta leszamolni a valtozasoknak.Szóval ha nekiállsz a bitekbõl bájtokat faragni, letárolni, ehhez memórialapozást kezelni, stb, akkor máris jócskán visszaesik a tempo!
Visszairtam a ciklusmagot a sima "inc hl" - re akkor megint 40 ezretszamolt.
Aztan probalkoztam plust "nop" -ok beiktatasaval az "inc hl" utan.
Igy kiderult hogy akar ket "nop" beiktatasaval az egynyegyedet mar elvesziti a CPU a valtozasoknak.
Ez tenylegesen megtortenik ennyi alatt ( ugye az orajel pontosan 4 millio Hz ? ), vagy pedig valami ramtol fuggo keslekedes lesz ezen az utasitason ?Alapértelmezésben minden utasítás olvasáskor van 1 órajel várakozás.
Es ha lesz keslekedes, akkor milyen idok alatt varhato a lefutasa ? Mi a legrosszabb eset ?
Tehat azt mondod hogy amit a leirasban talalok orajelet, ahhoz mindig adjak hozza 1 -et ?Igen.
Es az, hogy az ld (hl),e az maga is irja a memoriat, az nem noveli tovabb ?Alapértelmezésben nem. De be lehet olyat is állítani :-)
ld (hl),e
utasaitasra azt irjak, hogy 1.75 orajel alatt fut le.
Es az, hogy az ld (hl),e az maga is irja a memoriat, az nem noveli tovabb ?
Aham, es videoram sima ram kozott sincs alapesetben kulonbseg ? Mert en anno sztm mertem olyat hogy egyik ramunk lassbb volt ( minden allitas nelkul, en nem tudtam hogy lehet ilyet allitani ) mint a masik ...
Ez 4 MHz-es gépen 1 és 5.5 ciklus közötti várakozást jelent (a várakozás fél Z80 ciklus egységekben történik).És ez ha jól sejtem a Z80 órajelének felfüggesztésével történik. A TVC esetén konkrétan írják is, hogy így van.
A BFh porton beállítható várakozási módnak azonban a video RAM-ra nincs hatása.Ez pedig szabályosan a Z80 WAIT lábát használja. Ha erre a vezetékre rakunk egy kapcsolót, akkor kézzel ki lehet iktatni a várakozást, attól függetlenül, hogy a programok éppen mit állítgatnak. (Ennek 6 Mhz gép + 1.44 floppy esetén van értelme, 6 Mhz-es Z80 csak úgy tudja követni a 16 Mhz-es WD-t, ha nincs várakozás, legalábbis az EXDOS jelenlegi programkódjával.)
A videó RAM az jóval lassabb, és a program szempontjából vehetjük nagyjából véletlenszerûnek, hogy mikor jön be a várakozás...
Talán István tud egy átlagos idõt mondani rá.
Szal ha eleg stabil lenne, akkor ha 100- bol egyszer nem toltene be egy jatekot jol, es nem szolna hogy CRC error, hanem csak szetfagyna, akkor az, ki banja, nem ?Az egybõl szétfagyás az csak azt jelenti, hogy olyan helyre esett a hiba, hogy egybõl elõjön. De lehet, hogy máskor olyan helyre esik, hogy a második pályán fagy le. Vagy a harmadikon. Vagy akkor ha a zöld szörnyet a bal felsõ sarokban lövöd le. stb
Most lemertem egy sima betoltest. 32050 bajt hosszu fajlt 140 masodpercig toltott, az 1831 bit/s .
Azzal a betoltessel amit ott taglaltam olyan 10 ezer bit/s -set azert el lehetne erni. Az olyan 5.5 szoros sebessegnovekedes lenne.
A 8000 a a gyari 2000- hez kepest 4X- es. Nem lenne olyan rossz, ahhoz kepest ha csak 2 szamot kene atirni hozza valahol, de nem nagyon hiszek enebben ( semmi bizonyitek csak erzes ), mert ahhoz az 5.5- szoros sebesseghez en eldobnekminden funkciot, akkor az EP betolto szuper kepessegei megtartasa melletti 4X- es gyorsitas ... nem hinnem h bejonne.
Van valami rom visszafejtesszeru a magno betoltorol ?
Van valami rom visszafejtesszeru a magno betoltorol ?Nem sok, az 1-es szegmens visszafejtése kézíratban még nem lett részletesen visszafejtve :-(
Eloszor is az emu mintha lassabb lenne a vas EP- nel. Ezt a mert ciklusszamok a beolvaso programban is igy mutatjak, meg szemmel, mikor asmonban a szovegben shift+le gombbal kozlekedek, akkor az EP sokkal gyorsabban felulirja a kepet (mozog le egy oldalt), mint a szimulator. Ez miert lehet ?
BFh -portot en nem allitom, felteszem hogy a programok tobbsege se.
Az EXOS 2.3x (vagy a ZozoTools ?) kikapcsolja a várakozást, ha van RAM bõvítés.Akkor az bug lesz :oops: a RAM teszt idejére ki van kapcsolva, hogy gyorsabb legyen (meg jobban is legyenek strapálva a memóriák), de elvileg utána vissza kéne írnia az alapértéket.
Akkor az bug lesz :oops: a RAM teszt idejére ki van kapcsolva, hogy gyorsabb legyen (meg jobban is legyenek strapálva a memóriák), de elvileg utána vissza kéne írnia az alapértéket.
Hogyhogy az eredeti EP kapasbol nem ezt hasznalta ?Az alaplapok mindenféle vegyesfelvágott típusú, sebességû RAM IC-kkel készültek (gondolom amit éppen kapni lehetett olcsón), ezért van egy várakozás, hogy mindegyik gépen stabilan mûködjön.
Nem lehet hogy az NMI megszakitasok okozzak ezt a random merest ?Nem mert nincs az EP-ben NMI, csak akkor ha rákötsz egy Spectrum Emulátort.
Tehat te is azt gondolnad, hogy ha van egy ciklus, amiben csak port olvasas, regiszter muvelet, es felteteles ugras lesz, annak az ideje mikroszekundumban josolhato, es kovetkezetes kell legyen ?Igen. Viszont ha jól tudom a feltételes ugrásoknak nem ugyanannyi ideig tart a két variációja.
Ezt az EPTE maxot nekem nem sikerült 4 Mhz-es gépen beolvasni, csak 6Mhz-esen.
Leader Sync Zero One Normal sebesség 9 15 11 7 EPTE max speed 7 11 8 5
uff... hat csak a loadot neztem ( igazabol az az ami mozgatna ), es nem mondanam hogy ertem ...
tokmasnak nez ki mint az enyem, es nem ertem mi ez a sok bonyesz dolog ...
aze meg nezegetem, de akar el is mondhatnad az elvet hogyan mukodik, meg h melyik kodresz mit csinal,
hatha ugy megertem ...
na de itt vmi dave resetelesek vannak
, meg moindenfele rst hivasok... azok vlaami megszakitasok nem ? hat minek kellenek azok ?Azok csak rövidebb és gyorsabb CALL utasítások fix címre :) :oops:
volt valami ha jol emlekszem szaz vagy tobbszaz kiloherces hangmegszak, lehet azzal kell idot merni ?
Egy megleheto"sen kezdetleges próbálkozás gyors PC->EP másolásra:De ez elvileg 2 valódi EP között is menne, igaz?
De ez elvileg 2 valódi EP között is menne, igaz?
Magnóhang ki lett kapcsolva, vagy már átment ultrahangba? :-)
Ugh... es miert valasztottad azt ?
Es ezzel a hangmegszakos modszernel mi limitalja a sebesseget az altalad megnevezett 8770 bit/s -ses sebessegre ?
Mivel forditasz egyebkent, mik ezeke a forrasok, amiket attacsolsz ?
A Dave-s módszernek viszont az a elönye, hogy nem függ a memóriavárakozások állítgatásától. És ha lehetne berakni hasonló órajel detectálást, mint a hanglejátszóba, akkor mindenféle turbós géppel is müködne.
A mondatod masik reszet viszont total nem ertem, ha egyszer megszak, akkor az mar proci orajel fuggetlen, nem ? Tehat nem kell mar bele egyeb orajel detektalas, ha egyszer nem prociorajellel, hanem megszakkal merunk, akkor az nem lesz orajelfuggo. Nem ?
A csak Z80-as időzítés a DAVE programozásra fordított idő elkerülése miatt lehetne valamivel gyorsabb, de nehezebb jól megoldani.
Miben gondolod hogy nehezebb lenne ?
En arra a kerdesre keresem a valaszt, hogy vajon en rontottam- e el a beolvasoban valamit, vagy van valami ismert, elvi dolog, ami miatt az nem mukodhet.
Viszont ha rendes EXOS bõvítõt csinálunk belõle, akkor jön a probléma, hogy a memórialapozást is kezelni kell, ami jelentõsen belassítaná a dolgot :(
vagy lehet azt a trükköt csinálni mint az EXOS magnókezelõ, hogy mondjuk egy 4K-s csatornapuffert foglalni és oda töltögetve blokkonként az adatokat, majd utána lehet átmásolgatni. (valószínûleg ugyanezen okból van a magnókezelõnél is a darabolás, hogy a sebességkényes átvitelnél ne kelljen lapozgatással foglalkozni)
Erre megoldás lehet az, ha a bővítő átmenetileg a 0. lap elejére másolja az I/O rutint, elmentve és visszaállítva azt, ami eredetileg ott van. Természetesen problémát jelentene, ha a felhasználói program pont arra a területre próbálna tölteni, de remélhetőleg ez ritka eset. Ezzel a módszerrel a betöltő rutinban nem lenne lapozás, használhatna RST utasításokat, és a verem is a 0. lapra kerülhetne a lassú video RAM (FFH szegmens) helyett.Ez jónak tűnik, elég kevés program van, ami 0000h-0100h közé töltöget, még egy bibi lehetséges, ha van olyan program, ami kilapozza a 0-ás lapot, és helyére másikat lapoz be, de szerintem a programok 1-4%-ánál fordulhat elő ilyen probléma
Olyan viszont nagyon sok van, ami 100H-a állítja a vermet, ez nem okoz gondot?
A dolog hibaja azm hogy a sebesseg novekedese nem eleg nagy ahhoz hogy kibirja a szukseges CRC kezelesek es ilyesmiket, szal ahhoz hogy ez 1 hasznos dolog legyen, ahhoz sajna lassu lesz.
Ha egy atlag file eseteben a toltesi ido meghaladja azt az idot, amivel en floppy- ra mentek a pc- bol, es atteszem a floppy- t az EP meghajtoba, es betoltom rola, akkor ez kvazi ertelmetlen funkcio. Es itt sztm altalaban meghaladna a toltesi ido a kezi floppy -s modszeret.
Szal talan legjobb megis hagyni a faxba, es az emut csinalni tokeletesre ( ha van meg neki hibaja 1altalan ), mert ha 1X majd mar nem lesz mukodokepes EP, vagy majd mar csak 3 db mukodokepes lesz, abbol 2 Zozosoftnal 1 meg a nemzeti muzeumban
Bar en nem hinnem, hogy Zozot megrohantak volna a HDD megrendelesek,15 kártya már elfogyott, és még várólista is van :-) Ha lenne némi tõke, akkor lehetne legyártani egy kupac kártyát és felrakni ebay-re, vaterára.
de exdos, meg winyo meg ilyenek addig van mig Zozo butykoli oket, aztan kampo.Ha rajtam múlik, akkor ez a pillanat remélhetõleg csak 50-60 év múlva következik be.
Tenyleg egy remake vas EP, ami tok ugyanaz, csak a most elerheto legnagyobb frekis alkatreszekbol, es van benne plussz kihasznalhato sprite hw ? :)Ilyesmirõl szoktam álmodozni én is :-) Z380-al...
- rendszerbo"víto" EP-re, amely a FILE: eszközhöz hasonlóan használható (csak természetesen lassabb); az I/O mu"veletek közben a kód és a verem a 0-FFH területen lenne, elkerülendo" a lapozást és puffer használatot, tehát ide nem lehetne tölteni, de a bo"víto" elmentené (pl. az EXOS verembe) és visszaállítaná az itt található adatokat
A "szerver" PortAudio probléma miatt egyelőre csak Linux alatt használható :oops:
Miért volt az annak idején nálam, hogy a Magicball játékot csak lassabb baud rate-tel lehetett betölteni? (lassabb volt és mélyebb a felvétel) Emlékszem, hogy amikor átmásoltam a játékot, és normál sebességgel vette fel a kazira, akkor azt már nem tudtam visszatölteni.