Esetleg lehetnének EP-s frekvenciák is, bár ez a Spectrum felhasználók számára valószínűleg nem lenne ismerős (bevezetőjel: 2400 Hz, 0 bit: 2000 Hz, 1 bit: 3000 Hz; ezek kerekített értékek).

Ezzel valamennyit gyorsulna is a betöltés, a specball.tap EP formátumban mentve (tapeedit) csak 3:50.4.

persze ehhez sztereó magnó is kell...

1 csatorna egyszerűbb és olcsóbb. Sztereó jelet 8 bites processzorral valószínűleg nehezebb is lenne feldolgozni.

Turbósított és tömörített betöltésre tett próbálkozás Spectrumon (emulátoron működik, de az időzítéseken lehet, hogy még állítani kellene):

 zxloadm3.s (5.62 kB - downloaded 311 times.)
 test.tzx (3.72 kB - downloaded 249 times.)
 tapeenc.cpp (3.88 kB - downloaded 249 times.)    (epcompress forráskód kell a fordításához)

Ez durván turbósított , hány baudos a töltési sebesség? Viszont az a furcsa, hogy hangzás alapján 2x olyan gyors, mint a speccy töltési sebessége, és mégis majdnem annyi idő alatt tölti be a 4k-s blokkot, mint a normál EP töltés, úgy emlékszem jó hosszú bevezetőjellel volt 16mp, itt 13 mp alatt töltődik be rövid bevezetőjellel.

A sebesség kb. azonos az EP-vel, 0 bit = 2000 Hz, 1 bit = 3000 Hz, átlagosan (50-50% 0 és 1 bit) 2400 baud, azaz 300 byte/s. Az EP-hez képest gyorsulást eredményez, hogy nincsen sok kis blokk hosszú bevezetőjelekkel, és tömörített az adat. A Spectrum ROM-ban a 0 bit 2046.8 Hz, az 1 bit pedig 1023.4 Hz. Lehet, hogy a "turbós" betöltőben érdemes lenne 2000/4000 Hz-et használni, vagy más értékeket 2:1 aránnyal, így ugyan nagyobb a frekvencia, de nagyobb az eltérés is a bitek időtartama között, ami javíthatja a megbízhatóságot.

Ránézésre egyszerűbbnek tűnik a töltö rutin kódja, mint a speccys ROM loader

Ez a jelenlegi blokk formátum:

500 x D2h byte (nem a legjobb megoldás bevezetőjel céljára )
8Bh byte
blokk azonosító (2 byte, az alsó 8 bit az első), a betöltő ezt keresi (DE-ben megadott érték a rutin hívásakor)
blokk méret (N, 2 byte)
CRC kezdőérték (2 byte, az algoritmus hasonló az EXOS-ban használthoz, az adatblokk betöltése után CRC = FFFFh-nak kell lennie)
adatblokk (N byte)
5 x D2h byte
1.5 másodperc szünet

Az adatblokk az epcompress -raw -m3 kimenetéhez hasonló formátumú, de az első két byte (tömörített méret) nélkül.

Mar nem fert bele a gepidobe az eredeti loaderes villogtatas?
Egyebkent a toltesi ido magaert beszel

Elvileg beleférhetett volna, csak a keretcsíkozás egyszerűbb volt.

Megértem

Én nem daraboltam 4K-s blokkokra, a legnagyobb blokk (a főprogram tömörítve) egyébként is csak 12843 byte. Ennyivel is egyszerűbb lehetett a betöltő. Azzal a megoldással is próbálkoztam, hogy a specball.scr és specball.128 egy blokkban legyen, ami néhány másodperccel rövidítette volna a betöltést, viszont külön tárolva hamarabb jelenik meg a betöltőkép, ezért maradt az a verzió. A tömörítést epcompress -m2 formátumra cseréltem, így néhány száz byte-ot még meg lehetett takarítani, és előnye még, hogy a tömörített adatot a szabad memória végére lehet tölteni és onnan kicsomagolni. Érdekesség, hogy a byte sorrend fordított, ami még egyszerűsített egy keveset a betöltőn (FD87h-tól lefelé tárolja a beolvasott adatot, és a decompressData hívásakor az IX regiszterben már a kezdőcím van).

--------------------

Szerk.: lehetséges bug ? Nekem ilyen még nem fordult elő, talán csak Spectrumon jelentkezik (pl. R regiszteres véletlenszám generálás és eltérő időzítés miatt), de eddig ott sem láttam ilyen hibát.