Ciąg dalszy prac nad jednym z projektów "retro". Tym razem nie chodzi o
debugowanie błędu, a raczej jedną informację na temat działania karty CF.

Karta jest podłączona do magistrali systemowej. Występuje komunikacja
pomiędzy nią i CPU. Wygląda też na to, że udało mi się zainicjować kartę
do pracy w trybie 8bit. Teraz próbuję napisać zestaw funkcji, które
pozwolą mi podpiąć ją do jakiegoś systemu plików (odczyt i zapis sektora
po numerze LBA, odczyt liczby dostępnych sektorów).

Kod w obecnej postaci znajduje się tu:
https://github.com/marekw1986/RetroEG/blob/testing/c
ode/cf.c

Problem dotyczy odczytu liczby sektorów. Wzorowałem się na tym
przykładzie, napisanym w asemblerze 6800:
http://www.waveguide.se/?article=26&file=cftest.asm

Jeśli dobrze rozumiem, karcie trzeba wydać komendę 0xEC, a potem
odbierać dane bajt po bajcie, tak długo, jak ustawiana będzie flaga DRQ
w REG7. Zwrócone dane zawierają m.in. nazwę karty, jej numer seryjny, a
także jej rozmiar (wyrażany w liczbie sektorów).

I z tym ostatnim mam problem. W jaki konkretny sposób te dane są
przedstawiane? To ciąg bajtów składający się na 32bitową liczbę? Jeśli
tak, to jak wygląda kwestia ich kolejności? A może to łańcuch znaków
ASCII? W takim wypadku w jakim formacie?

Ktoś pamięta szczegóły, albo przynajmniej może mi wskazać jakieś źródło,
w które mógłbym się wczytać?

do góry

W dniu 03.10.2020 o 11:11, Atlantis pisze:

>
> Jeśli dobrze rozumiem, karcie trzeba wydać komendę 0xEC, a potem
> odbierać dane bajt po bajcie, tak długo, jak ustawiana będzie flaga DRQ
> w REG7. Zwrócone dane zawierają m.in. nazwę karty, jej numer seryjny, a
> także jej rozmiar (wyrażany w liczbie sektorów).
>
> I z tym ostatnim mam problem. W jaki konkretny sposób te dane są
> przedstawiane? To ciąg bajtów składający się na 32bitową liczbę? Jeśli
> tak, to jak wygląda kwestia ich kolejności? A może to łańcuch znaków
> ASCII? W takim wypadku w jakim formacie?
>
> Ktoś pamięta szczegóły, albo przynajmniej może mi wskazać jakieś źródło,
> w które mógłbym się wczytać?
>

http://www.farnell.com/datasheets/39782.pdf

MJ

do góry

On 03.10.2020 11:20, Michal Jankowski wrote:

> http://www.farnell.com/datasheets/39782.pdf

Ok, też już n to trafiłem. Okazuje się, że mój kod jest w porządku.
Niejednoznaczne wyniki były wynikiem zastosowania złego typu zmiennej w
procedurze, która raportowała odczytaną liczbę sektorów.

To teraz kolejne pytanie: czy istnieje jakaś prost biblioteka do obsługi
systemu plików, którą mógłbym skompilować za pomocą CC65?
Eksperymentowałem z FatFS. Po wprowadzeniu kilku drobnych zmian udało mi
się go skompilować, jednak nawet przy rozsądnej konfiguracji zajmuje
dużo miejsca w pamięci programu (w tech chili po dołączeniu tej
biblioteki mam zajęty prawie cały 32kB EPROM).
Rozpatruję PetitFS, ale on tutaj znowu będą bolały ograniczenia odnośnie
pisania do (a właściwie dopisywana do) pliku.

Na dobrą sprawę nie musi to być nawet FAT, byleby tylko nośnik dało się
zamontować pod Linuksem. Nie potrzebuję obsługi katalogów, wystarczy
zapis do głównego katalogu karty CF.

do góry

W dniu sobota, 3 października 2020 07:28:22 UTC-5 użytkownik Atlantis napisał:
> On 03.10.2020 11:20, Michal Jankowski wrote:
>
> > http://www.farnell.com/datasheets/39782.pdf
>
> Ok, też już n to trafiłem. Okazuje się, że mój kod jest w porządku.
> Niejednoznaczne wyniki były wynikiem zastosowania złego typu zmiennej w
> procedurze, która raportowała odczytaną liczbę sektorów.
>
> To teraz kolejne pytanie: czy istnieje jakaś prost biblioteka do obsługi
> systemu plików, którą mógłbym skompilować za pomocą CC65?
> Eksperymentowałem z FatFS. Po wprowadzeniu kilku drobnych zmian udało mi
> się go skompilować, jednak nawet przy rozsądnej konfiguracji zajmuje
> dużo miejsca w pamięci programu (w tech chili po dołączeniu tej
> biblioteki mam zajęty prawie cały 32kB EPROM).
> Rozpatruję PetitFS, ale on tutaj znowu będą bolały ograniczenia odnośnie
> pisania do (a właściwie dopisywana do) pliku.
>
> Na dobrą sprawę nie musi to być nawet FAT, byleby tylko nośnik dało się
> zamontować pod Linuksem. Nie potrzebuję obsługi katalogów, wystarczy
> zapis do głównego katalogu karty CF.

Poszperaj za "microcontroller file system"

Nie wiem czy jest taki ktory ci podejdzie ale kiedys najprostsze to bylo po prostu
zbudowanie sobie na sztywno 10-100 plikow w glownym katalogu i pisanie do nich po
calym sektorze.

Tak dlugo jak nie bedziesz tych plikow przenosic to mozna jets otwierac na komputerze
i czytac a sporo programow jes bedzie potrafic zapisac (chodzi o to aby nie
zmienialy pozycji na dysku).

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

A jak nie schesz samego FS-a to w sumie starczy ci troche skryptu bash-a.
Na dysk sobie piszesz jak ci tam pasuje i tylko utrzymujesz sobie gdzies tablice
gdzie ci sie pliki zaczynaja i koncza a potem sprawne uzycie dd ci to z karty zczyta
albo na karte wrzuci.

Do zmontowania chyba w jeden wieczor.

do góry

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

do góry