On 23.05.2024 21:51, J.F wrote:

> Płytkę masz 2 warstwową, czy 4?

Prototyp jest zbudowany na dwóch płytkach uniwersalnych. Masa i
zasilanie jest prowadzone srebrzanką, sygnały za pomocą dużej ilości
kynaru. ;) Najpierw powstała płytka z podstawowymi elementami (CPU,
zegar, kontroler magistrali, RAM, EPROM, UART/RS232, port równoległy,
logika dekodowania adresów) na której przetestowałem działanie systemu.
Potem pojawiła się druga płytka z peryferiami (układ graficzny,
kontroler klawiatury, kontroler przerwań, RTC i złącze do modułu karty
CF). Obydwie płyty są połączone dwiema taśmami ze złaczami pinowymi (dla
sygnałów) oraz przewodami rozprowadzającymi zasilanie.
Moduł karty CF miał oryginalnie wchodzić bezpośrednio w złącze drugiej
płytce. Jednak potem okazało się, że w takiej pozycji nie ma dla niego
miejsca w obudowie, którą przeznaczyłem dla tego projektu, wiec finalnie
on również jest połączony kawałkiem taśmy sygnałowej.

Wersja "finalna" ma już dwie trawione płytki - jednowarstwowe, z
licznymi kynarowymi mostkami po stronie elementów. Masa "wylana". Złacze
karty CF jest umieszczone bezpośrednio na jednej z płytek. Docelowo w
tej wersji ma się jeszcze pojawić trzecia płytka z kontrolerem wideo i
stacji dyskietek.


> Raczej połączylbym masę okolic procesora z masą karty, jeśli jest taka
> możliwość.

To znaczy dodać dodatkowe połączenie, niezależnie od istniejącego (masa
idąca taśmą do jednej z płytek, przez złącze modułu karty) czy czy
raczej przerwać istniejące połączenie i poprowadzić jak mówisz?
Chyba to drugie, żeby nie robić pętli, prawda?

Zresztą... Jeśli okaże się, że z obecnie dobraną karta działa poprawnie,
to może nie będe kombinował. Co najwyżej za jakiś czas dodam te bufory.

do góry

Ok, udało mi się załadować do pamięci (prowizorycznie) działający CP/M.
Na razie jeszcze nie dostarczyłem pełnych wersji procedur
odpowiedzialnych za obsługe dysku, więc system nie widzi zawartości
partycji, jednak mam dostępny prompt. Poza tym będę musiał jeszcze
dopracować obsługę klawiatury, bo mam drobnego buga.
Tak czy inaczej - tym razem bootloader ładuje do pamięci 32 sektory z
karty CF (16kB) i za każdym razem mam powtarzalny efekt. Można więc
chyba założyć, że dobrana karta CF działa prawidłowo. Przy tym stopniu
złożoności oprogramowania przeskoczenie choćby jednego bajtu
powodowałoby kompletny chaos.

do góry

On Tue, 4 Jun 2024 10:58:08 +0200, Atlantis wrote:
> Ok, udało mi się załadować do pamięci (prowizorycznie) działający CP/M.
> Na razie jeszcze nie dostarczyłem pełnych wersji procedur
> odpowiedzialnych za obsługe dysku, więc system nie widzi zawartości
> partycji, jednak mam dostępny prompt. Poza tym będę musiał jeszcze
> dopracować obsługę klawiatury, bo mam drobnego buga.
> Tak czy inaczej - tym razem bootloader ładuje do pamięci 32 sektory z
> karty CF (16kB) i za każdym razem mam powtarzalny efekt. Można więc
> chyba założyć, że dobrana karta CF działa prawidłowo. Przy tym stopniu
> złożoności oprogramowania przeskoczenie choćby jednego bajtu
> powodowałoby kompletny chaos.

Tym niemniej te wczesniejsze cuda są warte diagnozy.

P.S. Zapisz na karcie program, który będzie ładował 32 sektory pod
inny adres i porównywał.

Zabootuj, zmien kartę, wystartuj program :)

J.

do góry

On 4.06.2024 20:15, J.F wrote:

> Tym niemniej te wczesniejsze cuda są warte diagnozy.

Niewykluczone, że świętowanie mogło być przedwczesne.
Właśnie testuję pierwszą wersję do odczytu sektorów z karty CF i
tłumaczenia ich na 128 bajtowe sektory CP/M. System plików został
przygotowany wcześniej na Linuksie, za pomocą cpmtools.
Niestety w chwili obecnej działanie jest niestabilne. "DIR" nieraz
zwraca całą zawartość partycji, nieraz tylko jej część, a innym razem
zawiesza komputer na nieskończonym odczycie.
Niestety nie wyskakują przy tym żadne błedy BDOS-a, wiec będę musiał
dodać dodatkowe printy debugowe żeby wiedzieć, co się tak właściwie
dzieje z perspektywy BIOS-a. Możliwe, że to kwestia jakiegoś buga w moim
kodzie, ale mógł też powrócić problem z kartą.

do góry

On Fri, 7 Jun 2024 07:12:54 +0200, Atlantis wrote:
> On 4.06.2024 20:15, J.F wrote:
>> Tym niemniej te wczesniejsze cuda są warte diagnozy.
>
> Niewykluczone, że świętowanie mogło być przedwczesne.
> Właśnie testuję pierwszą wersję do odczytu sektorów z karty CF i
> tłumaczenia ich na 128 bajtowe sektory CP/M. System plików został
> przygotowany wcześniej na Linuksie, za pomocą cpmtools.
> Niestety w chwili obecnej działanie jest niestabilne. "DIR" nieraz
> zwraca całą zawartość partycji, nieraz tylko jej część, a innym razem
> zawiesza komputer na nieskończonym odczycie.
> Niestety nie wyskakują przy tym żadne błedy BDOS-a, wiec będę musiał
> dodać dodatkowe printy debugowe żeby wiedzieć, co się tak właściwie
> dzieje z perspektywy BIOS-a. Możliwe, że to kwestia jakiegoś buga w moim
> kodzie, ale mógł też powrócić problem z kartą.

To może być kwestia Twojego podejscia do programu.
Masz przeczytać 512 bajtów, to odbieraj 512, z zabezpieczeniem
czasowym, a nie wysyłaj komendę odczytu, a potem odbieraj póki są
dane.

Oscyloskp by się przydał, i to szybki, 2 czy więcej kanałowy, żeby
zobaczyc co się tam na pinach karty wyrabia, łącznie z masą i
zasilaniem ...

J.

do góry

On 7.06.2024 11:45, J.F wrote:

> To może być kwestia Twojego podejscia do programu.
> Masz przeczytać 512 bajtów, to odbieraj 512, z zabezpieczeniem
> czasowym, a nie wysyłaj komendę odczytu, a potem odbieraj póki są
> dane.

Prawdę mówiąc nie bardzo rozumiem co mi da takie podejście. Karta
otrzymuje komendę wysłania określonej liczby sektorów i wysyła je
ustawiając flagi. Jeśli w pewnym momencie to się rozjedzie i karta z
jakiegoś powodu wyśle więcej (lub mniej) danych niż ją o to poproszono,
to i tak jest unrecoverable error. A już na pewno CP/M nie jest na tyle
inteligentny, żeby z takiej sytuacji się wywinąć i jedynym rozwiązaniem
będzie reset. Tak więc tak czy inaczej, niezależnie od podejścia mamy
ten sam wynik - niedziałający system.

Wyjście jest jedno - trzeba będzie namierzyć przyczyną i ją usunąć. Przy
czym na chwilę obecną nie jestem nawet pewien czy oryginalny problem z
przeskakiwaniem bajtów faktycznie jest przyczyną obecnych kłopotów ze
stabilnością.

Te nowe problemy pojawiły się dopiero wtedy, gdy zacząłem dodawać do
BIOS-a procedury odpowiedzialne za operacje dyskowe. Gdy początkowo w
ich miejscu były tylko podstawowe stuby (za sprawą których system
myślał, że ma do czynienia z pustym, niesformatowanym dyskiem) wszystko
działało poprawnie i stabilnie, chociaż oczywiście niewiele dało się w
takim systemie zrobić. ;)

Teraz dzieją się rzeczy dziwne - system czasem wylistuje zawartość
dysku, czasem pokaże tylko część plików, a czasem się zawiesi podczas
tej operacji. Dodałem trochę printów debugowych, ale to wprowadziło
kolejne problemy. Bo teraz na przykład widzę, że podczas wstępnego
sprawdzania dysku ładowane są kolejne sektory, ale z jakiegoś powodu po
ukończeniu tej operacji system zawiesza się zaraz po wyświetleniu
prompta i przestaje reagować na klawiaturę - ale tylko jeśli włączę te
debugi.

Oczywiście możliwe, że jest to winą tego oryginalnego problemu z kartą
(bo np. dodatkowy kod zwiększa prawdopodobieństwo, że gdzieś jednak
przeskoczy ten bajt) ale równie dobrze może to być coś zupełnie
niezwiązanego, np. przepełnienie stosu.

Więc chyba najlepiej byłoby faktycznie zrobić moduł z buforami i
zobaczyć czy ogólnie poprawi to sytuację. Jeśli dotychczas niedziałające
karty nagle zaczną działać będę wiedział, że przyczyna leży gdzie
indziej. Bo faktycznie dość dziwnie wygląda fakt, że tylko na jednej
karcie CP/M w ogóle chce się bootować i nijak nie daje mi to gwarancji,
że jej działanie jest w 100% poprawne.



> Oscyloskp by się przydał, i to szybki, 2 czy więcej kanałowy, żeby
> zobaczyc co się tam na pinach karty wyrabia, łącznie z masą i
> zasilaniem ...

W wolnej chwili spróbuję się podpiąć i zobaczę.

do góry

On 7.06.2024 11:45, J.F wrote:

> To może być kwestia Twojego podejscia do programu.
> Masz przeczytać 512 bajtów, to odbieraj 512, z zabezpieczeniem
> czasowym, a nie wysyłaj komendę odczytu, a potem odbieraj póki są
> dane.

Coś dzisiaj wolno myślę, bo dopiero teraz dotarło do mnie co masz na
myśli. Jeśli polegam tylko na flagach, to nie mam gwarancji, że
faktycznie odbiorę dokładnie 512 bajtów. Co prawda do tej pory miałem do
czynienia tylko z sytuacją, kiedy bajty były tracone, ale przecież nie
mam gwarancji, że nie dojdzie do przekłamania skutkującego wysłaniem
nadmiarowych bajtów. I w takiej sytuacji wskaźnik bufora będzie nadal
inkrementowany, co doprowadzi do nadpisania innych obszarów pamięci.
To może tłumaczyć niestabilność i zawieszenia.
No cóż... Na chwile obecną jedynym sensownym wyjściem będzie zrobienie
buforów na liniach.

do góry

Ok, w końcu znalazłem trochę czasu, żeby się za to zabrać.
Wykonałem nową wersję modułu karty CF, tym razem z buforami (układ
74HCT245) na liniach D0..D7. Sytuacja poprawiła się o tyle, że teraz
jestem w stanie uruchomić CP/M z większej liczby kart, a wcześniej
działała tylko jedna. Nadal nie są to wszystkie, które posiadam w
podręcznym zestawie, ale postęp jest zauważalny.

Główny problem nie został wyeliminowany - system nadal wywala się (na
kilka różnych sposobów) przy próbie wylistowania zawartości dysku.

Aby mieć większą pewność, że system ładuje się poprawnie dodałem prostą
procedurę, która po załadowaniu CP/M liczy CRC16 obszaru pamięci, w
którym przechowywany jest jego kod wykonywalny (CCP+BDOS+BIOS). Na
chwilę obecną widzę, że wartość ta jest powtarzalna przy każdym rozruchu
systemu oraz zmienia się, jeśli wprowadzę jakąś modyfikację do BIOS-a.
Jeszcze nie porównywałem z obrazem źródłowym na dysku PC - muszę
poszukać jakiegoś programu, który pozwoli mi wyliczyć analogiczną sumę
kontrolną z pliku bin generowanego podczas budowania systemu.

Sporo zaczyna wskazywać, że mój problem może jednak mieć programowy
charakter.

do góry

Dodałem do programu printy debugowe, które informują o wejściu w
poszczególne procedury BIOS-a oraz zrzucają zawartość poszczególnych
parametrów odpowiedzialnych za operacje dyskowe, które są w nich ustawianie.

Z szybkiej analizy tych logów wynika, że przy starcie systemu:
1. Cyklicznie są wołane procedury SETDMA, SELDSK, SETTRK, SECTRN, SETSEC
i READ.
2. Parametr TRACK ma na początku wartość 0x0000, a potem jest
sukcesywnie podbijany o jeden w zakresie od 0x0020 do 0x003F.
3. Parametr SECTOR przyjmuje wartości od 0 do 3, przechodząc jeden cykl
na jedno podbicie parametru TRACK.
4. Parametr DMA przyjmuje albo adres bufora DISK_BUFFER (0x0080) albo
DIRBUF.
5. Odbywają się sukcesywne odczyty z karty CF, a wartość LBA jest
liczona poprawnie (adres początku partycji + parametr TRACK).

Printy debugowe mogą być włączane i wyłączane dyrektywą budowania
warunkowego. I tutaj jest jedna rzecz, która mnie zastanawia - kod
zachowuje się inaczej po dodaniu tych printów.

Jeśli je włączę, system wchodzi w procedurę BOOT, zaczyna czytać kartę i
zrzuca powyżej wymienione logi. Potem wyświetla prompt i zawiesza się -
klawiatura przestaje reagować.

Jeśli logi WYŁĄCZĘ system się uruchamia, czyta kartę (nie mam oczywiście
logów, ale widzę świecenie diody aktywności) po czym wyświetla prompt i
pozwala mi wypisywać polecenia. Zwykle wtedy dzieje się jedna z dwóch
rzeczy:
- System zawiesza się po wykonaniu komendy DIR.
- System zwraca niepełna zawartość dysku po wpisaniu komendy DIR, ale
pozwala na wpisywanie kolejnych komend.

Ktoś ma pomysł co może być nie tak i jak to dalej debugować?

do góry

W dniu 2024-07-03 o 08:10, Atlantis pisze:
> Dodałem do programu printy debugowe, które informują o wejściu w
> poszczególne procedury BIOS-a oraz zrzucają zawartość poszczególnych
> parametrów odpowiedzialnych za operacje dyskowe, które są w nich
> ustawianie.
>
> Z szybkiej analizy tych logów wynika, że przy starcie systemu:
> 1. Cyklicznie są wołane procedury SETDMA, SELDSK, SETTRK, SECTRN, SETSEC
> i READ.
> 2. Parametr TRACK ma na początku wartość 0x0000, a potem jest
> sukcesywnie podbijany o jeden w zakresie od 0x0020 do 0x003F.
> 3. Parametr SECTOR przyjmuje wartości od 0 do 3, przechodząc jeden cykl
> na jedno podbicie parametru TRACK.
> 4. Parametr DMA przyjmuje albo adres bufora DISK_BUFFER (0x0080) albo
> DIRBUF.
> 5. Odbywają się sukcesywne odczyty z karty CF, a wartość LBA jest
> liczona poprawnie (adres początku partycji + parametr TRACK).
>
> Printy debugowe mogą być włączane i wyłączane dyrektywą budowania
> warunkowego. I tutaj jest jedna rzecz, która mnie zastanawia - kod
> zachowuje się inaczej po dodaniu tych printów.
>
> Jeśli je włączę, system wchodzi w procedurę BOOT, zaczyna czytać kartę i
> zrzuca powyżej wymienione logi. Potem wyświetla prompt i zawiesza się -
> klawiatura przestaje reagować.
>
> Jeśli logi WYŁĄCZĘ system się uruchamia, czyta kartę (nie mam oczywiście
> logów, ale widzę świecenie diody aktywności) po czym wyświetla prompt i
> pozwala mi wypisywać polecenia. Zwykle wtedy dzieje się jedna z dwóch
> rzeczy:
> - System zawiesza się po wykonaniu komendy DIR.
> - System zwraca niepełna zawartość dysku po wpisaniu komendy DIR, ale
> pozwala na wpisywanie kolejnych komend.
>
> Ktoś ma pomysł co może być nie tak i jak to dalej debugować?

Co nie tak to nie wiem, ale bym zaczął usuwać printy debugowe
po jednym aż dojdziesz do stanu bez nich - wtedy będziesz miał winnego
zawieszenia po prompcie.

Pozdrowienia,
MKi

do góry