Posted By
BSZ
on 2023-07-24
17:09:26
|  Re: Trackloader For The Masses, Not The Classes
Ú, de rég is volt ez... 
Az SD2IEC + VCPU topikban emlegettem, hogy az egész amiatt lett elkezdve, hogy a Bitfire-hez legyen reális lehetőség SD2IEC támogatást írni. A témában vannak fejlemények, erről hamarosan beszámolok. Elöljáróban annyit, hogy páran már láthatták működés közben! Illetve kedvcsinálónak egy kép:
"Ezt senki se próbálja ki otthon!" 
Ápdét 2023.07.22.:
Itt ígértem egy hosszabb beszámolót, csak közben akadt egyéb feladat is. Készült pár mérés a töltési sebességekkel kapcsolatban, de az adatok előtt célszerű pontosítani, hogy mi is a cél valójában!
A feladat a topik címében emlegetett Bitfire töltő-rendszer SD2IEC-kel történő működőképessé tétele, de fontos kiemelni, hogy a BF alapvetően egy lemezes töltő. Tehát: az SD2IEC-es verziónak nem a leggyorsabb töltés a célja, hanem csak az, hogy hozza az 1541-es meghajtó sebességét. (Ha a töltőt használó program megfelelő sebességgel működik egy 1541-es meghajtóval is, akkor nincs ok arra, hogy ennél gyorsabban kelljen tölteni SD2IEC meghajtóról.)
Tehát a cél: hozni az 1541-es töltési sebességét, ahhoz képest bármi plusz az jó, de optimalizálni rá fölösleges. Azt már az elején megtippeltük, hogy csak a meghajtócsere önmagában gyorsítani fog (nem kell a lemez mechanikát kezelni, ami sok idő), emiatt lett még egy – legalább kipróbálandó – dolog: a ’41-es változat 2 bites adatátvitelt használ, de ennek van egy olyan hátránya, hogy csak egy eszköz lehet a soros buszra kapcsolva. Az SD2IEC-es verzióval érdemes megpróbálni az 1 bites adatátvitelt (hogy ne legyen ez a perifériaszám-limit), mert ha úgy is képes hozni az 1541 + 2 bites átvitel sebességét, akkor érdemes azt használni.
Maga a teszt annyit csinál, hogy a lemezen van 5 db. 32 KBYTE-os fájl, ezeket betölti sorban, és közben „megszámolja”, hogy a feladat hány képernyő-kirajzolás idejéig tart. A C64 / plus/4 képernyő-kirajzolási ideje nem pontosan egyforma, de az eltérés itt elhanyagolható, számolhatunk 50-nel másodpercenként. Azaz a kapott számot ha elosztom 50-nel, akkor megkapom, hogy hány másodperc alatt sikerült a 32 KBYTE adatot betölteni. (Itt a minél kisebb szám a gyorsabb.) Ha a 32-t elosztom az előbb kapott másodperc-számmal, akkor kijön az adatátviteli sebesség KB/Sec-ben. (Itt meg nyilván minél nagyobb a szám, annál gyorsabb.) A továbbiakban maradok a frame-számnál, aki a másik két mértékegységre kíváncsi, a fenti módon átszámolhatja.
No de jöjjenek az adatok! Készítettem még a múltkor két molinót, az első a C64-es verzió sebességeiről szól:
Az első két képrészlet az eredeti 1541-es töltésről szól, a számok a képernyőn hexadecimális értékek, az idők így rendre 303..333 képkiírásra jönnek ki. (A hagyományos lemeznél nem minden sávon található ugyanannyi szektor, illetve még ezer másik tényező befolyásolja a sebességet, ez a szórás emiatt teljesen rendben van.)
A második két képrészleten már az SD2IEC-es töltés látszik, annál is a két bites adatátvitel. És itt fontos megjegyezni, hogy ebben az esetben kizárólag a meghajtó változott, a számítógép oldalán futó kód teljesen megegyezik azzal, amit az 1541-es esetben használ! Itt az idők 164..167 képkiírásra jöttek ki, ez jó közelítéssel a duplája a ’41-es sebességnek. Lehet bizakodni, hogy az 1 bites átvitellel nem fog a felénél jobban visszaesni a sebesség…
A harmadik két képrészleten az 1 bites SD2IEC töltési idők látszanak: 250..252 képkiírásnyi idők lettek az eredmények, ez szépen hozza is a várakozásokat, az 1541-es 2 bites adatátvitelnél azért nem kevéssel gyorsabb, és nem zavarja a soros buszon levő több eszköz a töltést. Azaz: érdemes ezt a verziót használni a későbbiekben.
És akkor jöjjön a plus/4-es méréscsokor, ez egy kicsit komplexebb lesz, és van benne meglepetés:
Az első két képrészleten az 1541-es töltési idők látszanak, mindjárt két példányban. Ehhez is kell ide egy magyarázat: a kedvenc gépünk kétfajta órajellel működik, a képkiírás pozíciójától függően egyszeres vagy dupla órajellel. Az adatátvitelnél viszont a meghajtó sebességéhez kell a gépnek igazodni, ami az 1541 esetén „nem túl gyors”. A számítógépnek viszonylag sokat kell várakozni a meghajtóra, még az adatátvitel közben is! De ezeket a várakozási időket a dupla órajelhez kell beállítani, mivel a gép időnként azzal a sebességgel megy. Emiatt egyszeres órajel esetén „nem optimális” a várakozási idő. A gépet be lehet úgy konfigurálni, hogy csak egyszeres órajellel működjön végig, ilyenkor beállítható olyan várakozási idő (igen, még ekkor is gyorsabb a gép mint a ’41), ami az adatátvitel szempontjából megfelelő. Az idők közül az „#Sx” sorok ebben, az egyszeres órajeles üzemmódban mért időket mutatják: 301..332 képkiírási idők jönnek itt ki. (Ezek jó közelítéssel megegyeznek a C64-en mért értékekkel.) A „#Dx” sorok a dupla órajeles adatátviteli idők: 370..388 képkiírásnyi ideig tart egy-egy töltés. (A dupla órajeles módnak az az értelme, hogy az egyszeres órajelre kapcsolgatás rengeteg dolgot (időzítést, egyebet) felborít. Szinte mindig megéri a lassabb töltési sebesség mint kompromisszum, mint hogy az órajel-váltások által okozott mellékhatásokkal kelljen küzdenie a programozónak.)
A második két képrészleten ugyanez a teszt egy 1551-es meghajtóval fut. Itt a töltési idők 134..166 képkiírásra jönnek ki. Az 1551 CPU-ja dupla sebességen fut az 1541-éhez képest, így itt nincs szükség a gép egyszeres órajelére, ezért egyeznek meg a „#Sx” / „#Dx” értékek.
A harmadik két képrészleten a teszt SD2IEC meghajtóval + két bites átvitellel futott, de itt is érvényes az, ami a C64-nél fent: a gép oldali program megegyezik az 1541-es verzióval, csak a meghajtó változott! Az idők 165..167 képkiírás közöttiek egyszeres, 207..210 képkiírás közöttiek dupla órajeles átvitelnél. Az (erősen hunyorítva) dupla sebesség itt is látszik mindkét értéknél, az egy bites átvitelt mindenképpen érdemes megnézni. És itt jön egy kis meglepetés:
A negyedik két képrészleten az SD2IEC + 1 bites adatátvitel látszik, ahol 146..149 közötti képkiírási időt sikerült a programnak mérnie. Ez az érték nem hogy nem lassú, hanem egyenesen az 1551 8 bites sebességének a nagyságrendje! Ehhez azért muszáj fűzni szintén egy kis magyarázatot: a használt adatátviteli módszert egy 1541-gyel nem lehet megvalósítani ekkora sebességgel, annak a meghajtónak a CPU-ja lassú a feladathoz. Az SD2IEC esetén a meghajtó „odaér” a plus/4 adatátviteli protokolljára, ráadásul még dupla órajeles működés esetén is! (Az „#Sx” / „#Dx” számok között ezért nincs különbség, itt sincs szükség az egyszeres órajelre, mint ahogy az 1551 esetén sincs.)
A számok talán adnak némi támpontot a sebességeket illetően, de mint ahogy sok más teszt, ez sem teljes körű. A Bitfire tud „töltés közben kicsomagolni”, a fenti példák csak a „nyers”, egyszerű töltési sebességet mérik. A kicsomagolásos verzióhoz nem sikerült olyan mérési metódust kitalálni, ami úgy általánosságban mondana valamit, nem csak az adott fájl adott módon történő betöltésére. (A kicsomagolással egybekötött betöltés koncepciója az, hogy ameddig a meghajtó a következő blokkot keresi / olvassa, addig a gép úgyis csak vár a meghajtóra. Ezt a várakozási időt ki lehet használni a kitömörítésre, de ez persze csak akkor tud működni, ha a következő adag adat kicsomagoláshoz szükséges BYTE-ok már be vannak töltődve.)
Maga a módosított Bitfire loader még némi finomításra szorul, de remélem nem sokára kiadható formába kerül. Kérem várjon...
| Re: Trackloader For The Masses, Not The Classes
Man, how long ago this was.
As I mentioned in the topic of SD2IEC + VCPU, all this started to provide real possibility to code SD2IEC support for Bitfire. There are new developments which I soon will tell about. As a hint for you, some people saw it in operation. Also, to pique your interest, here is a picture:
"None should try this at home!"
Update 2023-07-22:
I promised a longer report here, but I had other things to do in the meantime. A few measurements have been made of the loading speeds, but before the data, it is useful to clarify what the 'target'!
The task is to make the Bitfire loader system (mentioned in the title of this topic) work with SD2IECs, but it is important to point out that the BF is basically a disk-loader. So: the SD2IEC version does not aim to be the fastest, but only to reach the speed of the 1541 drive. (If the program using the loader works with a 1541 drive at a reasonable speed, there is no reason to load faster from an SD2IEC drive.)
So the goal is to reach the loading speed of the 1541, anything extra is good, but optimizing for it is unnecessary. We guessed from the beginning that just changing the drive alone would speed things up (no need to deal with the disk mechanics, which takes a lot of time), so we added one more thing - at least to test: the '41 version uses 2-bit data transfer, but this has the disadvantage that only one device can be connected to the serial bus. With the SD2IEC version, it is worth trying 1-bit data transfer (so that this is not the peripheral number limit), because if it can still achieve the speed of 1541 + 2-bit transfer, it is worth using it.
What the test itself does is that it loads 5 files of 32 KBYTE from the disk in sequence, and "counts" how many frames (screen-drawing times) the task takes. The C64 / plus/4 frame times are not exactly the same, but the difference here is negligible, we calculate at 50 per second. That is, if I divide the resulting number by 50, I get the number of seconds it took to load the 32 KBYTE data. (Smaller number is the faster.) If I divide 32 by the number of seconds I just got, I get the data transfer rate in KB/sec. (Obviously, higher number is the faster.) I will use the frame numbers, but if you want to know the other two units, you can convert them as above.
But let's get to the data! I made two more molinos the other day, the first one is about the speed of the C64 version:
The first two pieces are the original 1541 load, the numbers on the screen are hexadecimal, so the times come out to 303..333 frames. (With conventional disk, there are not the same number of sectors on each track, and there are thousands of other factors affecting the speed, so this scatter is perfectly fine.)
In the second two pieces you can see the SD2IEC loading with the two-bit data transfer. And here it is important to note that in this case only the drive has changed, the code running on the computer side is exactly the same as the one used in the 1541 case! Here the times came out to 164..167 frames, which is roughly double the speed in '41. Let's hope that with the 1 bit transmission the speed will not drop more than half...
In the third two pieces you can see the 1-bit SD2IEC load times: 250..252 frames, which is pretty much as expected, a bit faster than the 1541 2-bit data transfer, and not disturbed by the multiple devices on the serial bus. In other words: it is worth using this version in the future.
And then we come to the plus/4 measurement, this one will be a bit more complex, and there are surprises in it:
The first two pieces show the loading times of 1541, in two versions. Here's an explanation: our favourite machine works with two types of clock, single or double clock, depending on the 'printing' position on the screen. When transferring data, however, the machine has to adapt to the speed of the drive, which is "not very fast" for the 1541. The computer has to wait a relatively long time for the drive, even during data transfer! But these waiting times must be set to the double clock speed, as the machine will sometimes run at that speed. For this reason, the waiting time is "sub-optimal" for a single clock running speed. The machine can be configured to run at a single clock all the way through, in which case you can set a latency (yes, even then the machine is faster than the '41) that is full optimal for data transfer. Of the times, the "#Sx" lines here show the times measured in single clock mode: 301..332 frames come out here. (These are roughly the same as the values measured on the C64.) The "#Dx" lines are the double clock data transfer times: 370..388 frames per load. (The point of double clocking is that switching to single clocking messes up a lot of things (timing, etc). It's almost always worth the slower load speed as a trade-off rather than having to deal with the side-effects of clock changes for the programmer.)
The second two pieces show the same test running on a 1551 drive. Here the load times come out to 134..166 frames. The CPU of the 1551 is running at double the speed of the 1541, so there is no need to single clock in computer-side, hence the "#Sx" / "#Dx" values are same.
In the third two pieces the test was run with SD2IEC drive + two-bit transfer, but here too what applies to the C64 above: the machine-side program is the same as in the 1541 version, only the drive has changed! Times are between 165..167 frames for single clock transmission and between 207..210 frames for double clock transmission. The (heavily about) double speed is also visible here for both values, the one bit transmission is definitely worth looking at. And here comes a little surprise:
The fourth two pieces show the SD2IEC + 1 bit data transfer, where the program was able to measure between 146..149 frames. This value is not only not slow, it is the order of magnitude of the 8-bit speed of 1551! A little explanation is also necessary for this: the data transfer method used cannot be achieved with a 1541 at this speed, the CPU of that drive is slow for this task. In the case of SD2IEC, the drive "reaches" the data transfer protocol of plus/4, even in double clock operation! (The numbers "#Sx" / "#Dx" therefore make no difference, and the single clock mode is not needed here, as it is not needed for 1551.)
The numbers may give some indication of speeds, but like many tests, it's not comprehensive. Bitfire can "decompress while loading", but the above examples only measure the simple "raw" loading speed. For the decompress version, it was not possible to come up with a measurement method that would tell you something in general, not just how speed of load that file in a particular way. (The concept of an decompressed load is that as long as the drive is looking for/reading the next block, the machine is waiting for the drive anyway. This waiting time can be used for decompressing, but of course this can only work if the BYTEs needed to decompress the next batch of data are already loaded.)
The modified Bitfire loader itself still needs some refinement, but I hope to have it in a releasable form soon. Please wait...
(Partly machine translation, correct me if something is wrong! )
|
