On 04.10.2020 05:47, s...@g...com wrote:

> Taki FS jest najprostszy i najmniej pamieciozerny.
> Do wielu zastosowan sie nadaje.

W ramach testu odpaliłem na tym sprzęcie FatFS-. Jak już chyba
wspominałem, potrzebne były drobne poprawki żeby go skompilować, bo nie
CC65 nie radził sobie z niektórymi wyrażeniami użytymi w kodzie. Po
skompilowaniu z wyłączoną większością opcjo rozmiar mojego projektu
urósł dość znacznie, jednak wciąż mam jeszcze około 7kB wolnej
przestrzeni pamięci EPROM, co powinno wystarczyć na zaimplementowanie
funkcji, które chciałbym tam jeszcze dodać.

Pamięcią RAM się specjalnie nie przejmuję, bo 8kB w tego typu urządzeniu
jest dostatecznie dużą ilością, żeby nie trzeba było się przejmować
brakiem miejsca na bufory.

Pierwszy test wypadł w miarę pozytywne. Udało mi się zamontować system
plików na karcie CF - instrukcja f_mount(&cffs, "", 1) zwraca 0 (jeśli
usunę kartę zwraca 3)_.
Instrukcja f_open(&file, "name.txt", (FA_OPEN_ALWAYS | FA_WRITE))
również zwraca taką samą wartość.

Wskazuje to na to, że występuje prawidłowa komunikacja pomiędzy kartą a
systemem plików. Problem pojawia się dopiero, gdy próbuję wykonać zapis
do pliku, za pomocą następującego ciągu instrukcji:

feed_hungry_watchdog();
res = f_write(&file, "Test\r\n", 6, NULL);
feed_hungry_watchdog();
mos6551_puts("File write: ");
utoa(res, buf, 10);
mos6551_puts(buf);
mos6551_puts("\r\n");
feed_hungry_watchdog();
f_close(&file);
prepare_disp();

Urządzenie się resetuje, UART nie wysyła żadnej informacji o wartości
zwróconej przez f_write. Co ciekawe jednak, na wyświetlaczu pojawia się
efekt działania prepare_disp().

Watchdog jest ustawiony w ten sposób, żeby zresetować urządzenie dopiero
po 1,2s braku aktywności. Jak widać resetuję go tuż przed i zaraz po
wywołaniu f_write(). Chyba zapis paru znaków nie zabierze tyle czasu,
nawet systemowi z 1 MHz 6502... Poza tym to nie wyjaśniłoby wykonania
prepare_disp()...

Ktoś ma jakiś pomysł?

Pełny, aktualny kod tutaj:

https://github.com/marekw1986/RetroEG/tree/testing/c
ode