Welcome, Guest. Please login or register.


Author Topic: Magnós frekvenciák (Read 39180 times)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Magnós frekvenciák
« Reply #105 on: 2009.November.15. 14:04:27 »
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.





Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Magnós frekvenciák
« Reply #106 on: 2009.November.15. 14:08:59 »
Miben gondolod hogy nehezebb lenne ?

Mert, mint már említettem, nincs fix, hardver által meghatározott időmérés, hanem figyelembe kell venni, hogy a kód sebessége változhat a feltételes elágazásoknak megfelelően. De természetesen lehet használni ezt a módszert is, illetve a Spectrumon például eleve csak így oldhatták meg a hardver kezdetlegessége miatt, mivel ott nincs semmilyen időzítő :)

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

Lehet, hogy egyszerűen csak túl nagy sebességet próbálsz elérni :)
« Last Edit: 2009.November.15. 14:12:41 by IstvanV »

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Magnós frekvenciák
« Reply #107 on: 2009.November.15. 14:38:18 »
A kulonbozo frekis gepek engem nem erdekelnenek, az meg hogy a felteteles elagazasoknak ugyanaz legyen a sebessege sztm nem igazan fontos, hiszen a merendo jelek, azok fix idovel jonnek, kivulrol, es mi majd varakozni fogunk ra, a kovetkezo bitnel,

tehat:

OLVASS:
olvasunk az inputbitrol
teszteljuk hogy van- e valtozas
ha nincs valtozas visszaugrunk OLVASS -ra,

ha van valtozas akkor itt folytatjuk ( most mas ideje lett az eddig OLVASS -ra ugro felteteles ugrasnak, de nem ertem miert szamitana ez )

itt megnezzuk az uj bit 0 vagy 1 es eltesszuk az uj bitet egy regiszterbe, amiben gyujtjuk ossze a bajtunkat

es visszaugrunk OLVASS -ra olvasni a kovetkezo bitet. ( vagy kifejtjuk ezt a 8- as loopot, de ez most reszletkerdes )



Lenyeg, hogy a ket fajta lefutas ( meg varunk a valtozasra ill. megvan a valtozas es betesszuk a bajtba ) kozul az egyiknek az ideje hosszabb lesz, es annal az idonel kell nagyobbnak lennie ket valtozas kozott eltelt idonek az inputjelben, hogy barhonnan is ugrunk vissza OLVASS- ra, ne veszisunk bitet. Ugyhogy nem szamit hogy kulonbozo a ketfele lefutas ideje. Nem ?


( most a bajt eltarolasat ne nezzuk, csak olvassuk a biteket osszegyujtjuk, aztan eldobjuk, nekem ugye ez sem ment mar )




sebesseg:

Hat a vegen mar 5KHz -es jel valtozasai kozott szamoltam a ciklusokat, ami 10KHz valtozas ami kisebb mint a te 13KHz- ed. Ugyan nagyobb ciklusszamok jottek ki ( kb. ketszer akkorak ) mint a dupla ekkora frekinel ( ami az alom freki lenne ), de ugyanolyan durvan osszevissza ertekek, nem stabil, vagy esetleg 1-2 ciklusszammal kulonbozo ertekek.
« Last Edit: 2009.November.15. 18:09:57 by Z80System »
Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Magnós frekvenciák
« Reply #108 on: 2009.November.15. 18:39:52 »
Kisebb optimalizálással ~9804 bit/s-re nőtt az átlagos sebesség (az "órajel" 250000 / 17, azaz kb. 14706 Hz). Valójában lehetne 10417 is, elvileg elég gyors a kód ahhoz is, csak még nem próbáltam ki:
  [ Guests cannot view attachments ]
  [ Guests cannot view attachments ]
  [ Guests cannot view attachments ]
  [ Guests cannot view attachments ]
  [ Guests cannot view attachments ]
Ez még mindig normál (04H) várakozást használ. A keretcsíkozás kissé más lett, mert úgy módosítottam, hogy egy byte bitjei között írjon a 81H portra, így a legrosszabb esetben (byte határon) az effektus nem használ CPU időt. A sebességet a tapeload.s 110. és a tapesave.s 89. sorában lehet állítani.

UI.: érdekességként a tapeload.s-ben a 112. sornál az E0H-t is át lehet írni C0H-ra, hogy legyen hang :) Egészen más (jóval magasabb) hangja van, mint a normál EXOS magnókezelőnek.
« Last Edit: 2009.November.15. 18:50:54 by IstvanV »

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Magnós frekvenciák
« Reply #109 on: 2009.November.15. 18:54:22 »
hmmm... alakul... ez igy az eredeti magno sebesseg 5X -ose, marcsak megduplazodik, es mar el is ertuk az "alomfrekit", amit elvileg lehetsegesnek tartottam ... :)

Z80 System

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14721
  • Country: hu
    • http://enterprise.iko.hu/
Re: Magnós frekvenciák
« Reply #110 on: 2009.November.16. 10:16:10 »
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)

Sõt mi lenne ha mondjuk a TPT magnókezelõjébe szerkesztenénk bele? A blokk kezelõ részt kéne kibõvíteni. Kimentésnél egyszerû, a turbó változó egy új, eddig nem használt értékénél lehetne az új mód, Betöltésnél meg a fejlécsípolást felismerõ részt kéne úgy alakítani, hogy eldöntse új vagy régi. Ha ez nem megoldható, akkor lehetne hagyományos fejléc, de pl a fájlnévben egyébként érvénytelen karakterrel jelezni, hogy extra turbó mód jön. (Keretcsíkozás helyett meg szivárványszín töltés jelzõ :-) ) Így egyben rátevõdne a TPT tömörítõ rutinja is.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Magnós frekvenciák
« Reply #111 on: 2009.November.16. 11:12:51 »
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 :(

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.

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

A puffer használata azért is van, hogy a programok tetszőleges méretű EXOS 6, illetve EXOS 5 hívással is tudjanak olvasni. Ha nem lenne 4K-s puffer, akkor az adat küldésénél pontosan azokat a blokk méreteket kellene használni, amit a másik gépen a felhasználói program vár (vagy kétirányúvá tenni a kommunikációt - de ez jelenleg csak igazi gépek között lenne lehetséges, mert az emulátorban nincs hangkártya bemenet - és először visszaküldeni a blokk méretét). Pufferrel viszont lassabb lesz az adatátvitel; a 9800 bit/s sebességnél egy 4K-s blokk másolása csak kb. 3 és fél másodperc, ami összemérhető a PAUSE hosszával. :(

Offline geco

  • EP addict
  • *
  • Posts: 7082
  • Country: hu
    • Támogató Támogató
Re: Magnós frekvenciák
« Reply #112 on: 2009.November.17. 09:10:16 »
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

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14721
  • Country: hu
    • http://enterprise.iko.hu/
Re: Magnós frekvenciák
« Reply #113 on: 2009.November.17. 09:16:27 »
Olyan viszont nagyon sok van, ami 100H-a állítja a vermet, ez nem okoz gondot?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Magnós frekvenciák
« Reply #114 on: 2009.November.17. 10:08:24 »
Olyan viszont nagyon sok van, ami 100H-a állítja a vermet, ez nem okoz gondot?

Nem, mert az EXOS bővítők futás közben az EXOS saját vermét (2.1-nél FFH:B217H-tól lefelé) használják, tehát a program esetleges 0. lapon található verem területe is csak elmentendő és visszaállítandó adat. Valójában azonban a másolás közben átmenetileg külön kis méretű vermet kellene létrehozni valahol a 0-100H területen, mert ilyenkor a felhasználói program lapozása lenne beállítva, azaz egyáltalán nem biztos, hogy a 2. lapon a rendszerszegmens lenne; ezen kívül video RAM helyett a gyorsabb 0. lap használható veremnek.
Azonban ez a 0. lapra másolós módszer csak akkor kell, ha nem lesz 4K-s puffer. Ha pedig 0. lap helyett igazi gépen EPROM-ban fut a kód, akkor nem jelentene problémát a 0CH várakozási mód beállítása sem. Egy másodperces PAUSE 9800 bit/s-ről kb. 7500 bit/s-re csökkentené a sebességet, de nem tudom, mennyi az a szünet, ami még általában megbízható (talán állítható legyen ?).

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Magnós frekvenciák
« Reply #115 on: 2010.March.25. 15:44:59 »
Ezt érdemes fejleszteni ? Talán megoldható lenne a következő:
  - rendszerbővítő EP-re, amely a FILE: eszközhöz hasonlóan használható (csak természetesen lassabb); az I/O műveletek közben a kód és a verem a 0-FFH területen lenne, elkerülendő a lapozást és puffer használatot, tehát ide nem lehetne tölteni, de a bővítő elmentené (pl. az EXOS verembe) és visszaállítaná az itt található adatokat
  - kétirányú EP<->PC összekötés (EP magnóbemenet-PC hangkimenet, és EP magnókimenet-PC hangbemenet), így tölteni és menteni is lehet, illetve az EP-s bővítő el tudja küldeni, hogy éppen milyen EXOS csatornahívást kellene végrehajtani
  - PC-s segédprogram, amely figyeli és elvégzi az EP-ről érkező EXOS csatornaművelet kéréseket az aktuális könyvtárban található file-okon; esetleg töltésnél használhatna "dtf -lz" tömörítést is, tovább növelve a sebességet

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: Magnós frekvenciák
« Reply #116 on: 2010.March.25. 19:12:43 »
Hat mikor 1X majd ujra fejlesztek EP- re en biztos imadnam, mert bar emun csinalom, attol meg probalgatni EP- n is kell. Es per pillanat az csak lemezre mentessel lehetseges.

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.

Es Zozosoft pld. nem latja ertelmet olyan tolto/mento funkciok komoly modon torteno exosba integralasanak, amik utana majd ( ha nemi sebessegnovokedessel a magohoz kepest ) bizonytalanul mukodnek. Szal vagy el van mentve valami, vagy nincs. Vagy biztos vok benne hogy az toltodott be ami a hattertaron van, vagy nem. Nincs kozeput. Ha meg stabilra akarjuk, akkor CRC- zni kell, de bizonyos esetekben ugy akar masolgatni is, pufferbol ( mikor olyan helyekre akarnak tolteni, ami direkt modon nem megvalosithato ).

Szal tobbszoros sebessegenek kene lennie a dolognak ahhoz, hogy gyakorlati haszna lehessen. Nagyon nagyon kecsegteto hogy mindossze 1 kabel raforditassal ( es persze szoftver mindket oldalon, de meg ep oldalon is lehetne akar sima floppyrol/winyorol toltodo rendszerbovito a dolog, EPROM se feltetlen kene ) lehetne adatot tolni egy vas EP- be, de sajna nem lenne eleg gyors.

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.

Persze ez akkor van igy ha fejleszteshez szeretne hasznalni az ember.

Koztudott hogy csak minimalis szami EP- re jut egy-egy EXDOS, a floppy- val rendelkezok szama elenyeszo az EP- k szamahoz kepest.
Ezert is tartottam fontosnak, anno a HDD probalgatasanal, hogy leszogezzuk, a HDD- s megoldas mukodokepes lehetne EXDOS es floppy nelkul is. Bar en nem hinnem, hogy Zozot megrohantak volna a HDD megrendelesek, szal lehet hogy egesz keves embernek kell csak az EP- be toltes gyorsan es kulturalt modon. Szal ennek a bekezdesnek az lett volna a lenyege, hogy ramutasson, hogy mivel nem fejlesztesi celra kellemes lehet ez a megoldas, megis lehet hogy van letjogosultsaga. De ha olyan sokan szeretnenek EP- be tolteni, hogy erdemes legyen ilyet kifejleszteni, akkor hogyhogy nem keszulnek az EP winyok zsinorba... Szal eljutottam a tezisem ellentezisehez: nem lehet tunni.

Azert azt megis olyan jo lenne tudni, hogy ha van valakinek egy vas EP- je, akkor az ( megha lassabban is ) egy tescoban vasarolt 300 forintos atjatszo kabellel barmit kepes betolteni/kimenteni PC- rol/re. Ez olyan jovobe mutato dolog lenne, nem ? Tehat ha vki szerez egy alapgepet, es nincs neki hozza egyeb mas ketyereje, kartyaja, bovitoje, akkor is egy minimalis kabelezessel monitorra (scart) es adathordozora (pc) tudja kotni a vasat. Sztm ez nagyban meghosszabbithatna az EP hasznalatot, mert mukodokepes alaplap, gep azert lehet, de exdos, meg winyo meg ilyenek addig van mig Zozo butykoli oket, aztan kampo.

A persze meg mindig ott a billentyu kerdes, a harmadik nehez dio. Hiaba a monitor (scart) es hattertar (pc, ha lenne), akkor se er semmit a vas egy mukodo bill folia nelkul, mert billentyut taknyolni hozza mar nem 1 juzer feladat. Lassu is, nehez is. Aki meg mar taknyol maganak bill- t, mert annyira ugyes es/vagy annyira erdekli, az mar szerezhet maganak winyot is azzal az erovel. Persze tovabbra is csak amig Zozo csinalja oket ...

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, akkor majd joesellyel az emu utan fog majd valaki egy remake EP- t csinalni vasbol, es ha nem lesz jo az emu, akkor nem lesz ugyanaz a vas EP sem. :)

Amigakat pld. mar regota toljak remake- ben, mindenfele fejlesztessel, extraval.

Tenyleg egy  remake vas EP, ami tok ugyanaz, csak a most elerheto legnagyobb frekis alkatreszekbol, es van benne plussz kihasznalhato sprite hw ? :)

Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Magnós frekvenciák
« Reply #117 on: 2010.March.25. 19:43:32 »
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.

Az itt itt található rutin már tartalmaz ellenőrzést. Bár az algoritmus egyszerűbb és gyorsabb, mint az EXOS-ban használt bitenkénti CRC, de azért nagy valószínűséggel ez is megtalálja a hibákat:
    XOR   L, A
    RLC   HL
    ADD   H, 3

Természetesen ez nem a Z80 kód, de a működését leírja. HL-ben van az ellenőrző összeg (kezdőértéke FFFFh), A-ban pedig az éppen olvasott byte.
Ezt az adatátvitel közben számolja, tehát az még egyszerűbb (8 bites) algoritmussal vagy az ellenőrzést külön menetben végezve gyorsabb is lehetne.

Es Zozosoft pld. nem latja ertelmet olyan tolto/mento funkciok komoly modon torteno exosba integralasanak, amik utana majd ( ha nemi sebessegnovokedessel a magohoz kepest ) bizonytalanul mukodnek. Szal vagy el van mentve valami, vagy nincs. Vagy biztos vok benne hogy az toltodott be ami a hattertaron van, vagy nem. Nincs kozeput. Ha meg stabilra akarjuk, akkor CRC- zni kell, de bizonyos esetekben ugy akar masolgatni is, pufferbol ( mikor olyan helyekre akarnak tolteni, ami direkt modon nem megvalosithato ).

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

Feltéve, hogy van floppy.

Quote
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

Ez valóban érdekes ötlet, másik, nagyon pontos (de egyben nagyon lassú) emulátort készíteni, mindent ciklusonként emulálva.

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14721
  • Country: hu
    • http://enterprise.iko.hu/
Re: Magnós frekvenciák
« Reply #118 on: 2010.March.27. 21:16:44 »
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.
Quote
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.

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

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: Magnós frekvenciák
« Reply #119 on: 2010.March.30. 21:22:25 »
 - 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 bo"víto" nagy része már kész van, már csak azt kell megírni, hogy az EXOS eszközkezelo"ként lássa is, és kijavítani a (valószínu"leg számos) hibákat :oops: A fenti tapeload.s és tapesave.s file-okban található rutinokat használja, de töltéskor lehet tömörített (dtf -cr -lz) is az adatformátum, amivel tovább növelheto" a sebesség (mert kevesebb ideig tart kicsomagolni, mint amennyit a rövidebb másolandó adat megtakarít).