| Posted By
BSZ
on 2021-11-07
19:32:33
|  SD2IEC drives + VCPU extension
Eleget húztam az SD2IEC meghajtókhoz készült firmware módosítás kiadását, de szerettem volna legalább vállalható formába hozni a forráskódokat.  Ismétlésképpen: a 2021-es Function partin kiadott BA - The Stream abból a szempontból semmiképpen sem Wild kategória, hogy a szükséges extra hardver kimerül egy egyszerű SD2IEC meghajtóban, ami sok felhasználónak van. Viszont ezt a meghajtócsaládot egy olyan szoftver működteti, ami - eddig - nem tette lehetővé az eszköz programozását. A VCPU bővítés ezt a hiányt orvosolja.
Amit itt az elején el kell mondani: az SD2IEC drive nem egy fajta hardvert takar, van belőle több különböző változat. Ami közös bennük, hogy egy mikrovezérlő az alapjuk. (Ez egy olyan integrált áramkör, amiben a CPU magon kívül benne van a RAM, a működtető programot tartalmazó ROM, illetve egy rakás periféria; azaz egy IC-ben egy komplett "számítógép".) Ami program "fut" bennük, az (általában) az sd2iec névre hallgató firmware valamilyen verziója. Ez a firmware open-source, a GPLv2 licenc alapján szabadon módosítható / használható. Ezt a firmware-t sikerült kibővíteni, ami két tulajdonsággal is jár: egyrészt a megszokott működés megmarad, másrészt ugyanazokkal a hardverekkel működik, mint az eredeti (ezt mindjárt pontosítom).
Csináltam egy egyszerű oldalt, ami itt található:
Flexible SD drive firmware
Egyelőre ez egy "vázlat", lesz még mit alakítani rajta. Legfőképp a név az, amivel nem vagyok kibékülve.  Az eredeti sd2iec firmware egyik tulajdonsága, hogy nem túl rugalmas, azokat a töltő (/ mentő) rutinokat támogatja csak, amik "bele vannak égetve" a fw-be. A saját verzió neve emiatt lett "rugalmas": Flexible SD drive firmware, rövidebben FlexSD fw. Viszont ez túlzottan nem tetszik, úgyhogy itt az első feladat:
Ha van valami frappáns névötleted, azt kérlek kommenteld ide! Aki kitalál valami fantasztikusat, az nyer egy greetings-t!
A firmware-rel kapcsolatban ki kell térni néhány "rossz hírre". A bővítés nem fordítható hozzá az összes fajta hardverhez, amit az eredeti sd2iec fw támogat:
Első körben kiesett a két ARM mikrovezérlőre épülő változat. (Ezeket ARM2IEC néven lehet megtalálni, nem tudom, mekkora ezen hardverek felhasználó bázisa. Mindegyik egy relatív drága ARM-os fejlesztői lapra épül, "natív", megvehető változatot nem is találtam belőlük.) Ezeknek a támogatása a későbbiekben megoldhatónak tűnik, ha "ARM2IEC felhasználók hordái követelik" a megoldást, majd nekiállok. Mindenesetre ha használsz ilyen hardvert, kérlek jelezd itt!
Ezen felül egyelőre nincs kész a petSD nevű hardverhez sem a támogatás. Ez egy olyan eszköz, ami a CBM PET számítógépekhez kapcsolható IEEE-488 buszon keresztül. (A VCPU bővítés egy része a CBM soros busz kezelését végzi, itt meg az IEEE-488 buszra kellene megcsinálni valami hasonlót.) Ennek a támogatása sincs kizárva, egyelőre nincs hozzá hardverem, amivel tesztelhetném. Meg szintén nem ismerem, mekkora a PET-es scene, egyáltalán van-e igény ilyesmire.
Ami még kimarad, az az XS1541 hardver támogatása. Erről annyit kell tudni, hogy ez valójában nem is meghajtó lenne, hanem egy olyan kábel, amivel egy CBM soros / IEEE-488 buszos meghajtót vagy számítógépet lehet pécéhez kapcsolni. Ehhez - némi trükközéssel - hozzákapcsolható egy SD-kártya, majd a megfelelően fordított sd2iec fw-rel SD2IEC meghajtónak lehet használni. De - hála a nem szokványos órajelének - az amúgy sd2iec fw-rel támogatott töltő (/ mentő) rutinok sem használhatóak, csak egy nagyon alap meghajtóként működik.
A többi hardver viszont támogatott, de itt is van egy "rossz hír". A fennmaradó eszközök egyik része 64, a másik 128 KBYTE programmemóriával rendelkezik. A 64 KBYTE-os verziókban csak úgy van elég szabad hely a VCPU számára (úgy is épp' hogy...), hogy a firmware-ből ki kellett venni a külső RTC támogatását. (RTC: Real-Time Clock: az aktuális dátumot / időt tartalmazó óra.) Az SD kártyán a FAT fájlrendszer valamilyen verziója lehet, az meg a fájlokhoz tárol ilyen-olyan időpontokat (pl. létrehozási időt). Viszont: ezt nem gondolom kritikusnak, az olcsóbb SD2IEC hardverekben van 64K-s mikrovezérlő, amiken nem jellemző, hogy lenne külön óra IC. Mindenesetre ehhez is ideírom: ha ilyen hardvered van használatban, kérlek jelezd!
A "rossz hírek" ezzel remélhetőleg véget értek, innentől már csak a fun van.
Az oldalról letölthető egy csomag az előre lefordított firmware-ekkel. A felhasználó elvileg egyszerűen fel tudja a saját meghajtójára rakni, annyi a teendő, hogy a meghajtójához tartozó fw-fájlt a használt SD kártya gyökérkönyvtárába kell másolni, majd úgy kell bekapcsolni (resetelni) az SD2IEC meghajtót. A meghajtó ilyenkor végignézi a kártya gyökerét, és ha talál rajta frissítést, azt felrakja a ROM-jába. (Az itt használt mikrovezérlők ROM-ja valójában FLASH-memória, a megfelelő programmal törölhető / programozható.) Ha a felhasználó esetleg nincs tisztában azzal, hogy milyen hardvere is van, az sem baj: ha a csomagban levő összes firmware fájlt felmásolja a kártya gyökerébe, a meghajtó kikeresi közülük a megfelelő darabot. A csere alatt a meghajtó egyik LED-je vadul villog, majd ha kész, az új verzió fog elindulni. A kártyán otthagyhatóak a fw fájlok, újra nem fogja felírni ugyanazt, de érdemes inkább letörölni a folyamat végén, mert minden RESET alkalmával végignézi őket, ami fölöslegesen lassítja a meghajtó indulását.
A firmware cseréhez is jár megjegyzés: az előző folyamat akkor működik, ha az SD2IEC hardverben levő mikrovezérlő tartalmazza a fw-cseréhez tartozó programot. (Ez a FlexSD fw-től független cucc, annak a felrakása ezt nem is cseréli le.) Ha a csere nem működik, kérdezd meg az SD2IEC-et eladó dealert, hogy miért. Ezen felül a cserével elvileg nem lehet elrontani a meghajtót, ha a felrakott fw nem működne, az eredeti verziót a fenti metódussal bármikor vissza lehet rakni.
Az oldalról letölthető a firmware forráskódja, a lefordításhoz 10.2-es gcc van jelenleg használatban. Nincs kizárva, hogy másik verzióval is fordítható, de tesztelve nincs.
Ezen felül az oldalon található egy dokumentáció a VCPU programozásáról, ez jelenleg magyar nyelven érhető el. Az angol fordítás folyamatban van, remélem hamarosan elkészül.
A stuffhoz tartozik egy rakás teszt / mintaprogram, ez szintén letölthető az oldalról. Ezek a tesztek / minták jelenleg négy platformra vannak elkészítve, VIC20-ra, C64-re, C16 / C116 / plus/4-re (C264 széria), illetve C128-ra. Van egy csak forrást tartalmazó csomag, illetve egy olyan, amibe az összes platformra lefordított verzió is benne van.
Alap felhasználóknak a FlexSD firmware binárisokat érdemes letölteni, (abból a megfelelő verziót felrakni a meghajtóra,) ezen felül a lefordított tesztprogramos pakkot. Ebből a "target-20" / "target-64" / "target-264" / "target-128" könyvtárak közül, amelyik számítógép éppen szimpatikus, azt az SD kártyára (könyvtárastól) célszerű felmásolni. Majd abba belépve egy (D)LOAD"A-*"(,8) stílusú paranccsal végig lehet tölteni a tesztprogramokat.
Jelenleg én két fajta SD2IEC hardvert tudok tesztelni (LarsP-mini, SW2), ezen felül tesztelődik még egy (LarsP) Siz és Larry által. A tesztelésekért nekik ezúton is köszönet! A többi verzióról jelenleg nincs semmi tapasztalat, ha ezeken felül egyéb fajta hardvered van (gondolok itt pl. a uIEC / uIEC3 párosra), akkor kérlek segíts egy teszteléssel! Mivel a tesztkódok nem plus/4 specifikusak, ezért ez a "feladat" nem csak plus/4-gyel használva érdekes, ez ilyen "össz-retró-CBM-népi" teszt lenne!
Fontos figyelmeztetés: Béta verzió! Csak saját felelősségre! Az SD kártyán ne legyen pótolhatatlan adat! :)
Lenne még mit írni, de a részletek majd a folytatásban.
| SD2IEC drives + VCPU extension
I've been dragging my feet on releasing the firmware modification for SD2IEC drives, but I wanted to at least get the source code into a workable form. To repeat: BA - The Stream which was released at the 2021 Function party is by no means a Wild Category - in that the extra hardware which is required is simply an SD2IEC drive, which many users already have. However, this family of drives is powered by software that - until now - did not allow the device to be programmed. The VCPU extension addresses this shortcoming.
What needs to be said at the outset here is that the SD2IEC drive is not a single type of hardware, there are several different versions. What they all have in common is that they are based on a micro-controller (an integrated circuit that contains, in addition to the CPU core, RAM, ROM containing the operating program, and a bunch of peripherals; i.e. a complete "computer" in one IC.) The program "runs" in them is (usually) some version of a firmware called sd2iec. This firmware is open-source, free to modify/use under the GPLv2 license. This firmware has been extended, which has two features: on the one hand, the usual functionality is preserved, and on the other hand, it works with the same hardware as the original (I'll clarify this in a moment).
I've made a simple page, which you can find here:
Flexible SD drive firmware
For now it's a "sketch", there will be more to do. It's mainly the name that I'm not happy with. One of the features of the original sd2iec firmware is that it is not very flexible, it only supports the load (/save) routines that are "burned into" the fw. That's why the name of my own version was changed to "flexible": Flexible SD drive firmware, or FlexSD fw for short. However, I don't like this that much, so here's the first task:
If you have a catchy name idea, please comment here! Whoever comes up with something fantastic will win a "greetings"!
Some "bad news" about the firmware should be mentioned. The extension cannot be compiled for all types of hardware supported by the original sd2iec fw:
First, the two versions based on ARM micro-controllers have been dropped. (These can be found as ARM2IEC, I don't know how large the user base of these hardware is. They are all built on a relatively expensive ARM development board, I couldn't find a "native" version of them available for purchase.) Support for these seems to be a workable solution for later, if "hordes of ARM2IEC users demand" a solution, I'll get on it. Anyway, if you use such hardware, please report it here!
Also, support for the petSD hardware is not yet ready. This is a device that connects to CBM PET computers via the IEEE-488 bus. (Part of the VCPU extension handles the CBM serial bus, and here we need to do something similar for the IEEE-488 bus.) Support for this is also not out of the question, I don't have the hardware to test it with yet. I also don't know how big the PET scene is, or if there is a need for such a thing at all.
What's still missing is support for the XS1541 hardware. All you need to know about this is that it wouldn't actually be a driver, but a cable to connect a CBM serial / IEEE-488 bus drive or computer to a PC. With a little trickery, you can attach an SD card to it, and then use it as an SD2IEC drive with the sd2iec fw properly compiled. But - thanks to its unconventional clock speed - the otherwise sd2iec fw-supported load (/save) routines are not usable either, it just works as a very basic drive.
All other hardware is supported, but here too is some "bad news". Some of the remaining devices have 64 KBYTE program memory, others have 128 KBYTE. The 64 KBYTE versions only have enough free space for the VCPU (barely...) because the firmware had to remove support for external RTC (RTC: Real-Time Clock). The SD card may have some version of the FAT file system, and it stores some timestamps (e.g. file creation time) for each files However: I don't think this is critical, cheaper SD2IEC hardware has 64K micro-controllers, which don't typically have a separate clock IC. Anyway, I'll add this: if you have such hardware in use, please let me know!
Hopefully this is the end of the "bad news", from now on it's all fun.
A package with pre-compiled firmware can be downloaded from the site. A user can in principle simply put it on their own drive, all they have to do is copy the fw file belonging to his drive to the root directory of the SD card used and then turn on (reset) the SD2IEC drive. The drive then looks at the root of the card and, if it finds an update on it, uploads it to its ROM. (The ROM of the micro-controllers used here is actually FLASH memory, which can be erased / programmed with the appropriate program.) If the user may not be aware of what hardware they have, it is okay to copy all the firmware files in the package to the root of the card, the drive will find the correct piece among them. During the replacement, one of the drive LEDs will flash wildly, and when done, the new version will start. You can leave the fw files on the card, you will not overwrite the same again, but you may want to delete them at the end of the process, because they will be checked after every RESET, which will unnecessarily slow down the drive.
There is also a note for firmware replacement: the previous process works if the micro-controller in the SD2IEC hardware includes the program for fw replacement. (This is FlexSD fw-independent stuff, putting it on won’t even replace it.) If the replacement doesn’t work, ask the dealer who sold the SD2IEC why. In addition, the replacement in principle can not damage the drive, if the loaded fw would not work, the original version can be restored at any time using the above method.
The source code of the firmware can be downloaded from the site, currently it's compiled with gcc 10.2. It might work with other compilers, but it has not been tested.
In addition, the site contains documentation on VCPU programming, which is currently available in Hungarian. The English translation is in progress, I hope it will be ready soon.
The stuff comes with a bunch of test / sample programs, this can also be downloaded from the site. These tests / samples are currently available for four platforms, VIC20, C64, C16 / C116 / plus / 4 (C264 series) and C128. There is a source-only package or one that includes versions translated for all platforms.
Average users should download the FlexSD firmware binaries, (put the appropriate version on the drive,) in addition to the compiled test program package. From the "target-20" / "target-64" / "target-264" / "target-128" directories, whichever computer is in use, it is advisable to copy it to the SD card (including the entire folder). Then, by entering it, you can load the test programs with (D)LOAD"A-*" (,8) style commands.
Currently, I can test two types of SD2IEC hardware (LarsP-mini, SW2), and in addition another one (LarsP) is being tested by Siz and Larry. Thanks to them again for testing! There is currently no experience with the other versions, if you have other types of hardware in addition to these (I am thinking here for example of the uIEC / uIEC3 pair), please help by testing it! Since the test codes are not plus/4 specific, this "task" is not only interesting when used with a plus/4, it would be a kind of "total-retro-CBM-folk" test!
Important warning: Beta version! Use at your own risk! Do not have irreplaceable data on the SD card! :)
There would be more to write, more details will follow.
|
|
Posted By
marcos64
on 2021-11-08
08:01:34
| Re: SD2IEC drives + VCPU extension
I've tried it with a uIEC3 and a C64.
It seems to flash the firmware OK.
With normal Kernal:
LOAD"$",8 ... it hangs.
LOAD "*",8 ... it hangs.
With JiffyDOS:
F1 to load the directory ... it hangs.
SHIFT+RUN/STOP to load the first file ... it hangs.
@ to read the error channel ... it responds OK with the VCPU name.
I've flashed back the SD2IEC firmware and everything seems to work OK again.
|
|
Posted By
BSZ
on 2021-11-10
18:29:58
| Re: SD2IEC drives + VCPU extension
@marcos64: Thank you for testing! Not exactly what I expected... :|
Is the (working) firmware you are using from the original site? Does this version work?
sd2iec-1.0.0atentdead0-29-gb8572fe-uIEC3-m1281.bin
(I copied this from the precompiled binaries.) If this version above work, please check this:
sd2iec-1.0.0atendead0-recompile.bin
This version is the original sd2iec for uIEC3, but I compiled it myself this binary. (The two files do not match exactly. I use a different version of the compiler.) If this works, we will investigate further. If it doesn't work, we investigate.
Thanks!
|
|
Posted By
marcos64
on 2021-11-09
04:43:20
| Re: SD2IEC drives + VCPU extension
I was using sd2iec-1.0.0atentdead0-16-g357fe83-uIEC3-m1281.bin
I tried your flexsd-1.1.0vcpubeta4-m1281-uIEC3.bin
And now it has sd2iec-1.0.0atentdead0-29-gb8572fe-uIEC3-m1281.bin
I hope I can test sd2iec-1.0.0atendead0-recompile.bin this morning.
UPDATE: Just tested sd2iec-1.0.0atendead0-recompile.bin and it works. At least LOAD"$",8 LOAD"*",8 and using a file browser to load a PRG has worked OK. If I read the error channel I get PETSCII characters and have to do a COMMODORE+SHIFT to read the text.
Don't know what to do exactly now. I've copied AUTOSWAP.LST tstdat2m.seq vcputstdsk1.d64 and vcputstdsk2.d64 to a folder but I don't see a PRG.
|
|
Posted By
BSZ
on 2021-11-10
18:30:49
| Re: SD2IEC drives + VCPU extension
@marcos64: Thank you for your efforts! The "-recompile.bin" is working = my compiler toolchain is OK. (I built it myself, anything is possible. ) The upper/lower case of version string is a known issue, not important for this situation.
But I found a possible bug, so I built a new firmware for you:
flexsd-1.1.0vcpubeta4-m1281-uIEC3-211109.bin
Please check it!
Don't know what to do exactly now. I've copied AUTOSWAP.LST tstdat2m.seq vcputstdsk1.d64 and vcputstdsk2.d64 to a folder but I don't see a PRG.
This is only interesting if the firmware works. In the "precompiled test codes" archive you will find the "target-64" folder. Copy this folder (all contents) to the SD-card. Insert the card to the SD2IEC drive, and go to the previously copied directory. This directory contain the test-programs. (This directory implies the ".d64" files, but _not select_ this!)
|
|
Posted By
marcos64
on 2021-11-10
04:30:40
| Re: SD2IEC drives + VCPU extension
I've updated with flexsd-1.1.0vcpubeta4-m1281-uIEC3-211109
I copied the target-64 folder and LOAD and RUN the file z-vcpuctst-64
All test PASS.
I've done it 3 times with standart kernal and another 3 times with jiffydos. All test PASS.
By de way, I have a C16+64KB but with an EEPROM-PLA and a CPU4C16 replacement CPU with which I've had some little load issues. So not sure if it can help you.
|
|
Posted By
BSZ
on 2021-11-10
18:19:24
| Re: SD2IEC drives + VCPU extension
@marcos64: Thank you! This bug only affected the uIEC3 version. (The problem is that I could not find a schematic diagram for this device. My help: source code, µC datasheet. )
The "z-vcputst" is check the VCPU commands only. If you have some time, please also check the "m-loadtst1b" and "n-loadtst2b" tests, these will load the "tstdat2m" file. They run for a long time! Meanwhile, they also measure the time. I would like to know the displayed values for comparing. Plus: this tests check the communication on serial bus.
The C16 test is interesting if the original firmware is good but there is a bug with the current firmware. (I hope this will not happen, I have not touched this part. )
@All: I have replaced the firmware files and source on the site with the corrected version. (beta4 -> beta5). Any feedback is welcome!
|
|
Posted By
marcos64
on 2021-11-11
08:02:56
| Re: SD2IEC drives + VCPU extension
I've updated with flexsd-1.1.0vcpubeta5-m1281-uIEC3.bin
z-vcpuctst-64: All PASS.
m-loadtst1b-64:
n-loadtst2b-64
|
|
Posted By
BSZ
on 2021-11-13
11:19:20
| Re: SD2IEC drives + VCPU extension
@marcos64: Thank you! The numbers are slightly different from what we have seen so far. But I'm not surprised! This is a bit more complicated than a traditional floppy. I started to make a spreadsheet in which I collect the values. The file loading is in two parts: 1: reading from the card, 2: data transmission to the machine. The times shown in the pictures are the sum of the two.
Create a separate test was made to measure the time taken to read from the card: "q-benchmark". I thought: "overall time" - "reading time" = "transmission time", but the "transmission time" is constant, thanks to the unified hardware. So far I have been able to compare two tests, but the calculation doesn't work out. If you feel like it, check out this test! What may be of interest is the type/size of the SD card and what file system is on it. (The firmware handles the FAT12 / 16 / 32 filesystems, i think. )
|
|
Posted By
marcos64
on 2021-11-14
06:15:38
| Re: SD2IEC drives + VCPU extension
The SD card is a Lexar SDHC 8GB Class 2. With FAT32.
The q-benchmark-64
|
|
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 :)
|
|
Posted By
Ati
on 2021-11-14
12:20:11
| Re: SD2IEC drives + VCPU extension
Hát én ebből kukkot nem értek.
| Re: SD2IEC drives + VCPU extension
Well I didn't understand a single peep out of that.
|
|
Posted By
Mad
on 2021-11-14
14:37:54
| Re: SD2IEC drives + VCPU extension
WOW! Very nice read! Did you also try out KickC? I think it's done by Camelot, and these guys usually know what they do (on a 6502). I hope this extension later goes into the standard SD2IEC kernel distributions.. Crazy that you try to do such stuff.. Big respect for that!
edit: ah sorry it's no 6502 c compiler! :D Maybe there is some better one out there, though.. llvm (clang) with the right backend usually gives good results currently I think..
edit2: there is an AVR backend for llvm.. https://llvm.org/doxygen/md_lib_Target_AVR_README.html.. But actually I have no clue on what I am writing or if this is the processor you target with this awesome stuff... :)
|
|
Posted By
BSZ
on 2021-11-14
15:24:25
| Re: SD2IEC drives + VCPU extension
@Ati: Ennyire rosszul magyarázok..? Vagy túl hardveres a megközelítés? (Esetleg mindkettő?)
@Mad: Yes, I need a C compiler for AVR. GCC works, but can write much more optimal code by hand. But it is good to know that another compiler is making in progress.
|
|
Posted By
marcos64
on 2021-11-16
04:12:17
| Re: SD2IEC drives + VCPU extension
I don't know if it can help, but I did the tests with my C16+64KB with EPROM-PLA and CPU4C16 replacements.
Everything worked except the first time I tried n-loadtst2b-264 it answers NO VCPU SUPPORT and the second time it hung. After turning it off and on again it worked.
|
|
Posted By
BSZ
on 2021-11-17
17:06:42
| Re: SD2IEC drives + VCPU extension
@marcos64: Thank you for these tests too! Did you use the same SD card as before? (I'll put it in the table. )
The VCPU support test is very simple: the computer send to drive the "get information" command ("ZI"), and receive the answer. If the answer's first byte is $33 (ASCII code of "3", the "30, SYNTAX ERROR,00,00" message's first BYTE), no VCPU support. If VCPU support present, the first BYTE from answer is $41 (at this moment). But...
$41 = %01000001
$33 = %00110011
Maybe the first didn't become the second. Based on what I have seen, I would not consider this a computer's receiving error. If the drive receives the "ZI" command incorrectly, that could be the error above, "30, SYNTAX..." message. An interesting experience!
|
|
Posted By
marcos64
on 2021-11-18
03:45:03
| Re: SD2IEC drives + VCPU extension
@BSZ: Yes, same SD card.
My C16 has sometimes strange problems loading with games like Alpharay or Lands of Zador. So it is most likely a problem of my C16.
|
|
Posted By
BSZ
on 2021-11-20
17:40:43
| Re: SD2IEC drives + VCPU extension
@marcos64: Your measurements have been added to the table! I don't think the strange error is caused by PLA. If the PLA is not good, it wouldn't just be a problem with drive communication. But it could also be a simple soldering or contact error. To test this, the "j-sr2b-usr" program may be appropriate. This test sends 256 BYTE to the drive, then receive back this data. This is repeated until there is no error. If this test run, meanwhile, you move the machine / cables, gently press the CPU with your finger, etc... If it is running at idle, but stops with a fault when moved, this may be the nature of the fault. If there is no correlation, it would be good to try it with an original CPU.
@All: A felmerült sebességtesztes blokkszámolási hiba nekem nem jött eddig elő, de amit sejtek, azon a részen módosítottam a tesztprogramon. A végeredményeket majd jól figyeljük a jövőben is! Ezen felül készítettem egy új csomagot, ez lett a vcpubeta6. Viszont elkövettem egy olyan "disznóságot", amit béta verzióval már nem illik: bekerült a kódba plusz egy utasítás, aminek a funkciója annyira hiányzott, hogy eddig fel se merült, hogy kéne. (De fogjuk úgy fel, hogy az eddigi verziókban nem működött.  ) Az oldalon lecseréltem a letölthető fájlokat: SD2IEC lefordított firmware-ek, forráskód, tesztprogramok, dokumentáció. (Lehet, hogy a böngészőben kell egy "Reload Page", valahogy ezek a cache-ek mindig bekevernek.)
Szerk: Közben "megálmodtam" egy másik lehetséges hibát a sebességtesztben, a javítás egy kicsit bonyolultabb lett, mint korábban, de kész. Kicseréltem a két tesztprogram-archívumot az oldalon. (1.0.1 -> 1.0.2)
| Re: SD2IEC drives + VCPU extension
@marcos64: Your measurements have been added to the table! I don't think the strange error is caused by PLA. If the PLA is not good, it wouldn't just be a problem with drive communication. But it could also be a simple soldering or contact error. To test this, the "j-sr2b-usr" program may be appropriate. This test sends 256 BYTE to the drive, then receive back this data. This is repeated until there is no error. If this test run, meanwhile, you move the machine / cables, gently press the CPU with your finger, etc... If it is running at idle, but stops with a fault when moved, this may be the nature of the fault. If there is no correlation, it would be good to try it with an original CPU.
@All: I have not yet encountered this speed-test block-counting error, but I modified the part of the test program that I suspect is the culprit. We will keep a close eye on the results in the future! In addition, I created a new package, which became vcpubeta6. However, I made a "mistake" which is not appropriate with a beta version: I added an extra statement to the code, the function of which was missing so much that I didn't even think it was needed until now. (But let's assume it didn't work in the previous versions. ) On the page I've replaced the downloadable files: SD2IEC compiled firmware, source code, test programs, documentation. (Your browser might need a "Reload Page", somehow cache always messes things up.)
Edit: In the meantime I "dreamed up" another possible bug in the speed test, and the fix became a bit more complicated than before, but it's done. I have replaced the two test program archives on the site. (1.0.1 -> 1.0.2)
|
|
Posted By
marcos64
on 2021-11-22
03:43:00
| Re: SD2IEC drives + VCPU extension
Upgraded to flexsd-1.1.0vcpubeta6-m1281-uIEC3.bin
Results:
|
|
Posted By
BSZ
on 2021-11-23
16:12:48
| Re: SD2IEC drives + VCPU extension
@marcos64: Thanks! Is this the previous SD card again? The numbers are interesting. The run time is about 19 IRQ longer. Over 2 MB of reading, that's not much of a difference. But the speed will not be the same for everyone, it depends on many things. (Not as constant as on a floppy.) At least the benchmark block number is good!
|
|
Posted By
marcos64
on 2021-11-24
04:18:19
| Re: SD2IEC drives + VCPU extension
Yes. Always the same SD card. Don't have other at the moment
|
|
Posted By
BSZ
on 2022-10-05
01:11:09
| Re: SD2IEC drives + VCPU extension
@marcos64: That's just right! At least it is comparable. There should be no speed difference between the previous and the last firmware version, it is likely that the location of the file on the partition has something to do with this.
@All: Ha a firmware-rel kapcsolatban nem derül ki hiba, lassan "kész"-nek lehet majd nyilvánítani, viszont itt van egy "gond": a kiindulási alapnak használt sd2iec firmware-ből évek óta nem készült "kész" kiadás, csak ilyen "aktuális napi fordítás". Így meg nehezen tudom ráfogni, hogy "kész". Ezen még gondolkozok. Apropó: a "név"-pályázat továbbra is nyitva van ám!
Állapotfrissítés: 2022.08.14.
A téma nincs elfelejtve, már csak azért sem, mert az Árok 2022-n nevezett WavePlay-SD is ezt használja. Mivel az elmúlt időben nem érkezett hibáról információ, így a Beta6-ból csináltam egy RC1 változatot. Ez amúgy elvileg megegyezik a Beta6-tal, a terveim szerint ez lesz a "végleges" 1.1.0 verzió. (Akinél a Beta6 fw van felrakva a meghajtóra, az azért jó lenne ha frissítené az RC1-re, de a teszteket nem szükséges újra futtatni, csak használni kellene "normális" módon.) A valódi "végleges" verzión még gondolkozok. A dilemma tárgya:
Az SD2IEC meghajtóban levő firmware-cserélő program két fajta "működtető" firmware-t ismer, az egyik a fejlesztői (development), a másik a "végleges", kiadási (release) verzió. Ha a FLASH-ben fejlesztői verzió van, azt bármilyen fejlesztői vagy kiadási verzióra szó nélkül lecseréli. Viszont kiadási verziót kizárólag magasabb verziószámú kiadási verzióra (vagy bármilyen fejlesztői verzióra) hajlandó csak cserélni. Emiatt egy minimális kavarást tud az okozni, ha kiadási verzió kerül telepítésre.
Tehát egyelőre marad a "Release Candidate 1" mint "végleges", a valódi végleges verziót meg még megálmodom. És lassan nyitok egy 1.2.0-s fejlesztői ágat, vannak ötletek, hogy mit lehet belefejleszteni.
Az oldalon frissültek a fájlok, de ide is linkelem őket:
Lefordított V1.1.0rc1 binárisok alap felhasználásra
V1.1.0rc1 forráskód azok számára, akik maguk fordítanák
A tesztek nem változtak, azokból emiatt nem csináltam frissebb csomagot.
Frissítés: 2022.10.03.
Az oldalon frissítettem a doksit, illetve a legfontosabb: siz fordításának köszönhetően felkerült a dokumentáció angol verziója! Ezúton is köszönet érte! A "biztonság kedvéért" ide is linkelem őket:
Angol nyelvű dokumentáció V0.999
Magyar nyelvű dokumentáció V0.999
Ha valaki hibát vél bármelyikben felfedezni, kérem jelezze! Aztán lassan ebből is lehet egy V1.0...
| Re: SD2IEC drives + VCPU extension
@marcos64: That's just right! At least it is comparable. There should be no speed difference between the previous and the last firmware version, it is likely that the location of the file on the partition has something to do with this.
@All: If no errors emerge regarding the firmware slowly it might be pronounced "ready". However there is a "problem" here: the SD2IEC firmware it is based on has no "releases" only "nightly builds" since years. That way it is hard to claim it being "ready." I am still deliberating that. By the way, the "naming competition" is still running.
Status update on 14. 08. 2022
It is not forgotten, especially so since WavePlay-SD competing in Árok 2022 is built on it too. As there were no error reports recently, I developed RC1 from Beta6. This latter theoretically is completely the same as Beta6 and I plan it to be the "final" version 1.1.0. Those of you who have Beta6 firmware installed on their drives are encouraged to refresh them to RC1. The tests don't have to be rerun, you should use the drives in normal day to day operation. I'm still thinking about the "real final" version.
My dilemma is: the firmware swapping programme of the SD2IEC knows two types of operating firmware; one is the development version, the other is the release. If the FLASH is programmed with a development version then the programme replaces that with any development or release version without any obstruction. Release versions, however, can only be replaced with ones having higher version number or any development version. Therefore, installing release versions may cause some mild turmoil.
That's why the "final release" will stay "Release Candidate 1" for now, until I come up with a solution. And I'll open a development branch sooner or later with version number 1.2.0; I still have ideas what else to implement into it.
The files have been updated on my page so I put the links below:
Compiled V1.1.0rc1 binaries for common usage
V1.1.0rc1 sources for those who'd like to compile it themselves
Tests haven't changed so I didn't create a newer package out of them.
Update on 03. 10. 2022.
I updated the documentation on my page and more importantly, thanks to siz' work there is an English version of it there. Again, thank you very much. I put their links here, just to be sure:
English Manual V0.999
Hungarian Manual V0.999
Whoever thinks he/she found error(s) in any of them, please notify me. Then, after much deliberation, this may turn into V1.0.
|
|
Posted By
Larry
on 2023-03-28
00:46:59
| Re: SD2IEC drives + VCPU extension
I really like this project! Is there anything new?
|
|
Posted By
siz
on 2023-03-28
04:13:52
| Re: SD2IEC drives + VCPU extension
Actually there is. But I'm busy (=a lazy bastard) to refresh the English translation of the manual and the GitHub sources. :/
|
|
Posted By
BSZ
on 2023-06-16
15:24:11
| Re: SD2IEC drives + VCPU extension
Ó, köszönöm hogy kiástátok a topikot, akartam is egy állapotjelentést írni!
Az elmúlt napokban frissítettem is az oldalon a fájlokat, itt a FlexSD firmware 1.1.0RC2 verziója! Mivel - egyelőre - hatalmas felhasználói, pláne programozói bázissal nem rendelkezik, ezért nem bírtam megállni, hogy további optimalizációk ne kerüljenek bele. Így pár apróság gyorsult, illetve kioptimalizálódott belőle egy utasítás. Ezt a jelenlegi rengeteg (2 db.) publikus program nem használja, így azokkal nincs teendő. Az oldalról letölthető tesztkódokat érintette csak ez a változás, amiből emiatt készült egy frissített változat.
A dokumentáció is frissült, a magyar, illetve az angol változat is. Ez utóbbi egy alapos átnézést kíván még, némi "gépi segítséget" kénytelen voltam hozzá igénybe venni, így aztán simán lehet benne furcsaság.
A tesztprogramok meg a dokumentációk "verziószámát" egységesítettem, talán könnyebben összerendelhetőek lesznek a jövőben. Így az 1.1.x firmware verzióval "egyidős" az 1.1.x tesztcsomag pakk, meg az 1.1.x dokumentáció. Aztán majd elválik, hogy ez a számozási séma mennyire válik be.
Akinek van hozzá hardvere / ideje, az kérem frissítse az előző verziót, és teszteljen! Nyilván nem csak a linkelt tesztpakk az érdekes, hanem a régebbi BA - The Stream illetve az újabb WavePlay-SD is.
Frissítés 2023.04.04.: Az angol dokumentációban Siz talált (a gépi fordításomban ) egy hibát, amit gyorsan át is szerkesztettem. A fenti (ebben a posztban szereplő) linket módosítottam, illetve az oldalon levő linket is aktualizáltam.
Frissítés 2023.06.10.: Készült egy újabb verzió, itt a FlexSD firmware 1.1.0RC3! Ebben tényleg csak hibajavításos módosítások kaptak helyet, egyebek nem. Cserébe a tesztkódokban van újdonság is. Egyrészt az RC3-ban megoldott dolgokhoz bekerült a Z-VCPUCTST-be a hozzá tartozó ellenőrzés, másrészt készült R-LSTRESSTST néven egy új teszt. Az egyik saját SD2IEC meghajtómmal tapasztaltam egy furcsaságot, mint kiderült, hardver hiba. Ennek a detektálására készült ez a teszt, ami a meghajtó oldaláról kapcsolgatja a soros port vonalait, a gép meg közben figyeli, hogy előfordul-e nem várt állapot. Ha minden rendben van, akkor nem lehet a futás közben semmilyen figyelmeztetés. Amennyiben "LINE ERROR:" kezdetű sorok jelennek meg, az utal erre a hibára. Simán lehet, hogy ez az esemény csak nálam fordult elő, ha esetleg más is jelzi hogy érintett, akkor leírom részletesen a tapasztalatokat.
Az oldalra - szokás szerint - felkerültek az új fájlok, a szokásos "minden" (forráskódok, lefordított csomagok), frissítésre + tesztelésre fel!
Frissítés 2023.06.16.: A doksikba bekerült még egy-két pontosítás, így a .hu és .en programozási dokumentációk is frissültek az oldalon.
| Re: SD2IEC drives + VCPU extension
Thank you for digging up this topic. I was about writing a status report.
I updated the files on their page in the last few days. The new version FlexSD firmware 1.1.0RC2 is here! As, for now, it doesn't have a massive user base, let alone the programmers, I couldn't help myself adding further optimizations. Therefore a couple of minor things became faster and one instruction got optimized out. The current plethora of all two public programmes aren't using that so there's no need to do anything to them. The change do affect only the test codes which you can download from the page so an updated version was made of it.
Documentation was updated, too. Both the Hungarian and the English version. This latter needs a thorough read through as I had to use some 'machine help' so strange things may have found their way into it.
I unified the version numbers of the documentation and test programmes; maybe they will be easier to match from now on. That means firmware 1.1.x is the same 'age' as 1.1.x test software package and 1.1.x documentation. We'll see how good that numbering scheme will work.
I'd like to ask those of you who have the appropriate hardware and time to update and test the new version, please. Obviously, I'm interested not only the results reported by the linked test package but your experiences with the older BA - The Stream and newer WavePlay-SD too.
Update on 2023.04.04: Siz already found an error in the machine translated parts of the English documentation which I promptly corrected. I modified the link above in this post and also updated the link on the page.
Update on 2023.06.10: Another new version was made, FlexSD firmware 1.1.0RC3 is here. Bugfixes only, nothing else. However, the test programmes have introduced some new features. On one hand, the problems RC3 solved have their test cases included in Z-VCPUCTST; on the other hand, a new test called R-LSTRESSTST was made. I experienced something strange with one of my SD2IEC devices which turned out to be a hardware error. This test was made to detect that error by toggling the serial lines on the drive side while the computer listens looking for unexpected line state configurations. No warnings shall be displayed if there is everything all right. If there appear any printouts starting with "LINE ERROR:" those imply the error I mentioned. I cannot exclude the possibility of this happening only for me, but if others are influenced too I'll enter into details on my experiences.
"Everything", as in sources and compiled packages, is uploaded, as per usual, to the page so everybody update and test now!
Update on 2023.06.16: A few more clarifications have been added to the docs, so the .hu and .en programming documentation has been updated on the site.
|
|
|
|
Posted By
Murphy
on 2023-09-24
04:00:24
| Re: SD2IEC drives + VCPU extension
@gerliczer wow, this FW looks promising!
The question is of course whether it supports plus/4 bitfire. It would be great to test it.
|
|
Posted By
BSZ
on 2023-09-23
17:00:02
| Re: SD2IEC drives + VCPU extension
@gerliczer: Thanks for your discovery! I watch this kind of thing too, I found a version that has support for two extra games. But I've never seen this before, it's quite interesting! It's not offtopic at all, the license allows you to take over functions from each other.
Now I had a quick look, because I was curious about some of the details. The question is, how to fit into the program memory? For me, this is a major problem. This included support for plus four loaders. But I downloaded the compiled binaries and I think I have the solution: binary is only available for 128K program memory drives. The 128K version has a lot of free space, I might as well include this modification in my version.
This FW really does look promising! However...
This is a perfect "veterinary horse" (is there such an english term?), or a perfect example of why I didn't want to code the BF support in this way. It says in the documentation: "Added support for Bitfire, BoozeLoader, Sparkle and Spindle." Okay. These loaders are not "finished" things, they are constantly evolving. Since there is no need for compatibility, they may work completely differently from version to version.
My question: the firmware support these loaders, but which version?! My question is of course answered by the documentation:
Bitfire: 0.1 .. 1.2 (10 versions),
BoozeLoader: 1.0 (1 version)
Sparkle: 1.0 .. 2.x (maybe 11 versions)
Spindle: 1.0 .. 3.1 (7 versions)
It may not be necessary to build support for the different versions in a completely separate way, but differences must be managed. And... If a new version of any of the loaders is made, need to adapt the firmware. However, support for older versions cannot be removed, because programs made with the old version will not run afterwards. Because of this, they just "accumulate" in the firmware, and you end up running out of space. (Although that may come later.)
It must have been an amazing job to do this, congratulations! But this promises to be a "never ending" adventure.
@Murphy: As I know the firmware, it will probably not recognize the plus/4 version. But of course it is worth a try.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
