Posted By
BSZ
on 2021-11-14
15:12:34
|  Re: SD2IEC drives + VCPU extension
@marcos64: Thanks! The calculation here also shows an interesting result.  I have a guess, but we'll have to think about it. The type of SD card is "for information", not sure if the hardware is always the same. But one "bug" was revealed: for the 256 measurement, the block number should be 8192.  In this test, this is calculated by the computer, but the testcode can be wrong in some cases. I will fix this later.
Ha már ezek szerencsére kiderültek…
A firmware kibővítésének az eredeti célja az lett volna, hogy a BitFire-t meg lehessen csinálni SD2IEC meghajtóval való működésre is. (Az most mellékes körülmény, hogy ebből jelenleg egy sor sincs még megírva, de remélem ez változni fog. ) Ehhez valamilyen szinten szükséges, hogy a meghajtó programozható legyen. A gyári CBM meghajtóknál ez a lehetőség adott, de vajon az SD2IEC-nél ez miért nincs így? És ha nincs így, akkor mégis hogyan lehetséges, hogy van néhány gyorstöltő, ami meg mégis működik?
Az utóbbi kérdésre a válasz az, hogy az eredeti sd2iec firmware az adott töltőrutinokhoz beépített támogatást tartalmaz; valamilyen logika alapján detektálja, hogy a számítógép milyen töltőrutint akar futtatni, majd az ahhoz a töltőhöz tartozó SD2IEC oldali implementációt futtatja a meghajtóban. De ez az implementáció a firmware-be van „égetve”, ezt csak annak a cseréjével lehet módosítani / bővíteni. Annak viszont sok értelmét nem látom, hogy a jelenlegi gyorstöltők mellé még egy verzió bekerüljön statikusan, módosíthatatlanul.
Hogy az SD2IEC meghajtó miért nem tartalmaz olyan interfészt, mint amilyen az eredeti CBM meghajtók programozását lehetővé teszi? A választ egy kicsit távolabbról kell kezdeni. Az eredeti CBM meghajtókban, meg a számítógépekben levő CPU von Neumann architektúrás. Mint fent írtam, az SD2IEC meghajtók egy mikrovezérlőre épülnek, aminek az egyik – esetünkben nagyon is jelentős – tulajdonsága, hogy a bennük levő CPU-mag Harvard-architektúrára (*, később pontosítom) épül. Esetünkben a leglényegesebb különbség a két architektúra között az, hogy a Harvard-ban külön buszon kapcsolódik a CPU maghoz a program, illetve az adatmemória, amik nem is biztos, hogy ugyanolyan szélességűek! (Itt a kérdésre, hogy „mi van a $0123 memóriacímen” az a válasz, hogy „melyik címtérben”? A programmemóriában itt egy csak olvasható, 16 bites utasításkód lesz általában, az adatmemóriában meg egy írható/olvasható, 8 bites adat.) Ez azért érdekes, mert emiatt a CPU mag az adatmemóriában levő adatokat nem képes futtatni, mint programot! Tehát: ezzel a mikrovezérlő-családdal a felépítéséből fakadóan nem lehet azt megoldani, hogy a RAM-jába kódot töltök, és azt ott elindítom.
(*: A fent leírtak arra a mikrovezérlő-családra vonatkoznak, amikkel az SD2IEC meghajtókat készítik. A FlexSD firmware-rel jelenleg nem támogatott ARM2IEC meghajtókban levő CPU mag a programozó szempontjából von Neumann architektúrás (az egyszerűség kedvéért maradjunk ennél a meghatározásnál), ott lehet a RAM-ból programot futtatni, de ezekből minimális mennyiség van használatban, nem lenne célszerű csak azokat támogatni.)
Ha mégis meg kell oldani, hogy a RAM-ban levő adatok valamilyen módon programként fussanak, akkor csak az marad, hogy olyan programot kell írni, ami a RAM-ba levő adatokat adatként olvassa majd „interpretálja”. Interpreter esetén viszont a programfuttatás nem lesz túl gyors. Viszont: hagyományos lemezkezelés esetén mihez is kell a „nagy CPU sebesség”? Kell egyrészt a lemezről jövő adatok olvasásához és dekódolásához, másrészt a számítógép felé történő adatátvitelhez. Minden más feladat ezek időigényéhez képest „elenyésző”. Esetünkben „lemez-olvasás” mint olyan nincs, ezt a firmware megfelelő funkciói elvégzik. Ha az adatátvitelhez készülne valamilyen fix protokoll, akkor csak az „elenyésző” mennyiségű feladat maradna az interpreterre, amihez elég a „nem túl gyors” végrehajtás is. (Aztán közben ez is jól megváltozott, de erről hamarosan.)
Interpretált végrehajtáshoz adja magát valami egyszerű szkriptnyelv, kerestem is ilyent, de annyira „light” változatot, ami ennyire korlátozott erőforrások mellett is használható, na olyant nem találtam. De ha lenne is, itt csak olyant tudnék elképzelni, ahol a szkriptet valami byte-kód-szerűségbe előre lefordítja, a mikrovezérlő már csak azt az előfordított adathalmazt futtatná. Viszont ha már fordítás... Az interpreter futtathatna „gépi kódot” is, azaz emulálhatok vele processzort is! A programozó a megszokott módján megírja a programját, lefordítja egy assemblerrel, majd azt tölti be a meghajtóba, pont mint eddig.
Pár körrel később az lett a terv, hogy készítek C-ben egy részleges 6502 emulátort, ez fogja futtatni a betöltött programot. A meghajtó firmware funkcióinak az eléréséhez készül valami interfész, a géppel való kommunikációhoz pár algoritmus, aztán kész is vagyok. Nyilván ez se így alakult... A C-s implementálás odáig jutott, hogy a 6502 mag jó része elkészült, pár utasítás hiányzott még, amikor a fordító jelezte, hogy elfogyott a programmemória. Mivel a célok között szerepelt az, hogy az „olcsó” SD2IEC meghajtók kis programmemóriás verziói is – legalább alap szinten – támogatva legyenek, innentől lehetett gondolkozni, hogy mi legyen. Első körben nekiálltam a „fogni a fejem” a látottakon: a C-s program assembly-re fordított változata annyira borzalmasan helypazarló és nem optimális, hogy az egyenesen fájdalmas. (Minden tiszteletem a fordítót készítőké, de ezen nagyon látszik, hogy eredetileg nem egy ilyen, 8 bites mikrovezérlőhöz tervezték ezt.) Itt most azt kellett eldönteni, hogy mi legyen. Ha nekiállok „elmagyarázni” a fordítónak részletesen, hogy mit is akarok, annak a végeredménye egy platformfüggő, de még mindig nem optimális kód lesz. De sokkal kisebb munkának tűnik, ha a 6502 magot teljes egészében C helyett assembly-ben csinálom meg. Az ARM2IEC hardverekkel való kompatibilitás így is – úgy is bukott, ha fontos lesz, az majd kaphat a későbbiekben egy C-s implementációt.
Tehát a végeredmény egy assembly-ben megvalósított, kissé megvágott, illetve némileg kibővített 6502 emuláció lett, de itt is fontos egy dolgok kiemelni: a 6502 emulációtól az eszköz nem lesz 1541 kompatibilis semmilyen szinten! Ez nem is volt cél.
A részletekről majd még csacsogok, de ez megint hosszú lett. Viszont ezt már írnom illett volna: ha valaki most akar SD2IEC meghajtót venni, mindenképpen olyan verziót válasszon, amiben 128K-s a programmemória! :)
| (no topic)
@marcos64: Thanks! The calculation here also shows an interesting result. I have a guess, but we'll have to think about it. The type of SD card is "for information", not sure if the hardware is always the same. But one "bug" was revealed: for the 256 measurement, the block number should be 8192. In this test, this is calculated by the computer, but the testcode can be wrong in some cases. I will fix this later.
Since all these got found out for our fortune...
The original goal of extending the firmware was enabling BitFire to operate with SD2IEC drives. (It is only an unimportant circumstance than not a single line of code is written for that purpose, but I hope it will change soon. ) That need the drive to be programmable to a certain extent. Original CBM drives provided this feature, so why SD2IEC devices don't have it? And if it doesn't have it, how come that some fast-loaders work yet?
The answer to this latter question is that original SD2IEC firmware has built-in support for those loader routines; using some detection logic, it identifies what loader routine the computer wants to run and switches to the corresponding firmware implementation in the SD2IEC drive. But that implementation is "burned" into the firmware so it can be modified or replaced only by replacing the firmware. But I don't find it reasonable to add yet another fast-loader to it in a static, unmodifiable way.
Why SD2IEC drives don't have such an interface that made it possible to program the original CBM devices? Let's take a few steps back before answering that question. Original CBM drives and usually the computers have CPU built on the so called von Neumann architecture. As I wrote it above, SD2IEC drives are built on a microcontroller and one of their characteristics, which is very important in our case, is that their CPU cores are built on Harvard architecture (* more details a bit later). The most important difference, for us, between the two architectures that according to the Harvard principles programme and data memories connect to the CPU core through separate buses which are not even necessarily the same width. (The answer to the question "what data is at memory location $0123" is "in which address space"? Programme memory usually contains a read only 16 bit instruction code, while data memory has an 8 bit, readable and writeable data.) This is important because it results in the CPU core being unable to run data in data memory as a programme. Therefore: it is not possible to upload code into the RAM of this microcontroller family and run it as a program because of their architecture.
(* The things written above are true in the case of the microcontroller family SD2IEC drives are based on. ARM2IEC drives, which are not supported by FlexSD firmware yet, have CPU cores that are von Neumann architecture from the viewpoint of the programmer, to simplify things. Those can run programmes from RAM but as there are not a lot of them in use it wouldn't be prudent supporting only those.)
If we have to make data in RAM somehow ran as a program, we don't have any other choice then writing a programme that reads data in RAM as data and interprets them. However, programmes will not be running to fast if they are interpreted. But: what do we need "high CPU speed" when handling traditional disks? Any other tasks are "insignificant" compared to the time consumed by these two. It is needed for reading and decoding data from the disk and for transferring data to the computer. In our case there is no such thing as "disk reading", that is handled by the appropriate functions of the firmware. If we made some fixed protocol for data transfer then only that "insignificant" amount of work would be left for the interpreter for which the "not too fast" execution would be enough. (That too have change in the mean time but more on that a bit later.)
Scripting languages lend themselves for interpreted execution but I couldn't find any that would've been "light" enough to be usable with such limited resources. But even if there were some I could only envision such solutions where scripts are pre-compiled into some sort of a byte code and the microcontroller had to run only that pre-compiled data. But if we are at compiling... The interpreter may even run "machine code" or simply put I could even emulate a processor with it. Programmers write their programs as usual, compile them with assemblers and upload that to the drive exactly the same way they did always do it.
A few rounds later my plan turned into writing a partial 6502 emulator in C which will run the uploaded programme. I make some interface to access the firmware functions of the drive, a couple of algorithms for communicating with the computer and I'm done with it. Obviously, that didn't pan out exactly that way... Implementation in C reached the point where the 6502 core was mostly done, a couple of instructions were remaining to do when the compiler informed me about programme memory ran out. As one of the goals was to have at least basic support even for the "cheap" SD2IEC drives with small programme memory, it was time to go back to the drawing board. My first "thing to do" was having a headache: the assembly translation of the C programme is so terribly memory wasting and unoptimized that it simply hurts. (Maximum respect for the compiler programmes but it is very obvious that this was originally not designed for such 8 bit microcontrollers.) I had to decide what to do now. If I start to "explain in details" to the compiler what my goal is it will be a platform dependent yet still not optimized code. But it seems to be much less work if I rewrite the whole 6502 core in assembly instead of C. I have lost ARM2IEC compatibility either way; if it will become important later, it could have a C implementation.
So, the result became a somewhat cut down, somewhat extended 6502 emulation written in assembly. But it is important to emphasize one thing: 6502 emulation will not make the device 1541 compatible at any level. That was not the goal.
I'll chatter some more about the details sooner or later but this turned out long again. However, I should have written this already: if you want to buy an SD2IEC drive now, make sure you buy a version with 128K of program memory :)
|
