Goto page Previous 1, 2, 3 Next
J.F
Guest
Thu May 23, 2024 5:47 pm
On Thu, 23 May 2024 15:18:07 +0200, Atlantis wrote:
Quote:
On 23.05.2024 13:52, J.F wrote:
No tak, ale jak karta przeskakuje 1 bajt, to tak jakby komputer chciał
odczytac 1 bajt więcej.
I widać nie ma z tym kłopotów, więc albo:
Wydaje mi się, że karta po prostu uznaje ten jeden bajt za wysłany.
No. To na koniec komputer chce od niej o 1 bajt za dużo.
Quote:
Tak
wynikałoby z tego posta, który wczoraj znalazłem i przytaczałem. Kwestia
zakłóceń na magistrali przy szybko zmieniających się stanach linii.
Względnie nowoczesna, szybka karta jest na to znacznie bardziej
wyczulona niż stary procesor. Do tej hipotezy zdaje się też pasować
fakt, że najwyraźniej niektóre karty są wolne od tego problemu.
A komputerowi wszystko jedno, bo to nie on steruje procesem. Nie ma tam
żadnej pętli, w której oczekiwałby określonej liczby bajtów. On po
prostu prosi kartę o wysłanie odpowiedniej liczy sektorów zaczynając od
określonego punktu startowego, a potem przyjmuje dane tak długo, jak
ustawiane są odpowiednie flagi.
spodziewałem się, ze w bootloaderze masz czytanie określonej liczby
bajtów, ale widzę, że nie.
Czytanie na flagi znów rodzi kwestię zależnosci czasowych, ale karta
raczej szybka, a 8080 bardzo wolny.
A zgubić tak drugi bajt byłoby raczej trudno.
Quote:
-wysłałes do karty żądanie odczytu większej ilosci sektorów, i
oczekuje nadmiar na odczyt,
Jak wynika z kodu który wrzuciłem, proszę o 32 sektory (16kB).
-jakis timeout mas w bootloaderze, i nawet nie zauważa, ze 1 bajtu
zabrakło,
-gdzie indziej leży problem, w procesorze/bootloaderze ... przerwania
np ?
Timeoutu nie ma, bo tak naprawdę nie jest potrzebny. Jeśli komputer
zawiesi się na tym etapie, to tak naprawdę jedynym wyjściem będzie reset
Może i tak, ale w tym CFWAIT jakos czekasz, może byc za mało lub za
dużo. Ale patrzę w program - jak przerwie, to całość, drugiego bajtu
tak nie zgubisz.
Quote:
całego systemu. Przerwania w tym konkretnym momencie są wyłączone na
poziomie procesora (instrukcja DI).
nie pamietam ... chyba były jeszcze niemaskowane,
czy to dopiero w Z80 ?
Quote:
Karta nie może tak po prostu wysłać o jeden lub kilka bajtów za mało w
losowych miejscach, bo prosimy ją o wysłanie danych liczonych w
sektorach (po 512 bajtów). Dlatego najbardziej prawdopodobna wydaje się
hipoteza mówiaca, że bajt "przeskakuje" ponieważ karta uznaje, że bajt
został już wysłany (kiedy tak naprawdę nie miało to jeszcze miejsca) i
przechodzi do wysyłania kolejnego.
Ciekawie byłoby zobaczyc ile bajtów bootloader przeczytał.
Quote:
-karta jakas taka, że sama wewnętrznie przeskakuje ten 1 bajt, i potem
uzupełnia ... IMO, mało prawdopodobne ...
Właśnie to jest najbardziej prawdopodobne wyjaśnienie, pasujące do tego,
co wrzuciłem wczoraj. Ktoś miał bardzo podobny objaw i mają za niego
odpowiadać zakłócenia na magistrali, na które wrażliwe są szybkie karty.
Lekarstwem jest użycie buforów albo gorszej karty.
Karta niczego nie musi uzupełniać, bo z jej punktu widzenia została
nadana właściwa liczba danych.
Zakładałem, ze BL odczytuje założoną ilość bajtów.
I wtedy karta musiałaby uzupełnić ilość.
Quote:
Tymczasem komputer nigdy nie otrzymuje
(co najmniej) jednego bajtu, a więc nie inkrementuje wskaźnika i kolejny
nadawany przez kartę trafia na jego miejsce w pamięci.
Albo ostatnie bajty obrazu. Przygotujesz obraz, przepuscisz przez
program generujący sumę kontrolne, zapisze w pliku,
a potem plik zapiszesz na kartę.
Przy czym tak naprawdę niewiele mnie to ratuje. Tak - będę w stanie
wykryć niepoprawne załadowanie systemu, jednak jeśli transmisje między
kartą CF i pamięcią/procesorem nie będą poprawne, to system wykrzaczy
się zaraz później, na ładowaniu programów i operacjach na plikach. Bo
tam raczej nie będzie żadnych sum kontrolnych...
Ogólnie racja, ale takie zabezpieczenie jest sensowne, żebyś był
pewny, że uruchamiasz dobry program.
Inaczej ... wszytko tam może być, przypadkowe dane, które się stają
przypadkowym programem, czy lekko przekłamany program, który cos
uszkodzi, albo np skasuje kartę ...
Quote:
Są symulatory. A moze nawet jest port.
Oczywiście, że są. Tylko co do za przyjemność?
Nie widzę przyjemnosci w starej grze tekstowej.
No ale wiadomo - de gustibus ...
Quote:
Wiesz, ja kolekcjonuję stary sprzęt. Jeśli mogę, to w oryginale, jeśli
nie to w formie współczesnego klona. I właśnie ta "epoka" to jest trochę
taka dziura w kolekcji, bo w Polsce nie mieliśmy amatorskich komputerów
tej generacji. MCY7880 pracował głównie w sprzęcie produkowanym na
potrzeby instytucji państwowych. Nie mieliśmy naszego ALTAIR-a 8800 albo
IMSAI 8080. Amatorska Cobra pojawiła się nieco później i była już na Z80.
IMO - no i dobrze, jesli Z80 lepszy. A pojawił się raptem 2 lata po
8080.
był jeszcze 8085 - taki trochę lepszy 8080.
Quote:
A że parę lat temu wpadło mi w ręce kilka sztuk MCY7880 z peryferiami (i
dodatkowo w szufladach miałem sporo scalaków od CEMI) pomyślałem, że
zrobię z tego działający system z użyciem polskich części.
No coż, de gustibus ...
Takie komputerki były za PRL, ale raczej przemysłowe ... i chyba nikt
nie patrzył na polskość, tylko na stawiane wymogi - jak były potrzebne
zagraniczne kości, to się kupowało.
Quote:
Przecież CP/M nie miał grafiki, to tekstowa gra ?
Tak. Tekstowa przygodówka. Żeby było ciekawiej wersja prototypowa
posiada nieco anachroniczny układ wideo TMS9918. Teoretycznie może on
generować grafikę (ma sprzętowa obsługe sprite'ów) jednak w moim
projekcie pracuje tylko w trybie tekstowym. Wersja finalna dostanie już
raczej jakiś bardziej typowy dla epoki, czysto graficzny kontroler
wideo. Zaletą TMS-a była łatwa implementacja wynikająca z tego, że
posiada on własną pamięć wideo na osobnej magistrali, dlatego trafił do
wersji prototypowej.
Gdzieś kiedyś czytałem, że ponoć niektóre systemy na CP/M można było
wyposażyć w kartę graficzna na TMS99xx i po zastosowaniu jakiejś
Wsadzic mogłeś duzo, ale standard nie przewidywał, to i z programami
gorzej.
Akurat w CP/M szybko zaczęło brakować pamięci, to pewnie był nacisk,
aby pamięc video jakoś bankować.
Quote:
programowej warstwy kompatybilności dało się odpalać gry z jakiejś
platformy opartej na Z80 i TMS99xx (MSX? Sega?),
Podejrzewam MSX, ale lista komputerków z tym systemem jest dłuzsza.
Quote:
jednak u mnie to
odpada, bo nie mam procesora Z80. Cała frajda tego projektu wiąże się z
faktem, że został w nim użyty rodzimy klon 8080 + cała masa części
polskiej produkcji.
Niech Ci będzie :-)
J.
J.F
Guest
Thu May 23, 2024 6:15 pm
On Wed, 22 May 2024 19:14:48 +0200, Atlantis wrote:
Quote:
On 22.05.2024 18:40, J.F wrote:
A wpisz tam inną wartość, np C0, w koncu możesz ustwic stos na
7FC0, zobaczysz czy to wartosc FF jest wredna.
Ok. Wartość 0xC0 nie jest pomijana. Czyli ma problem faktycznie z 0xFF.
Trzeba będzie poszukać innej karty, a docelowo zastosować bufory.
To ja bym jeszcze sprawdził, czy FF w innych miejscach też bywają
pomijane.
Ale to troche dziwne. Bo niby takie FF mogłoby zakłócic inne linie,
ale czekasz w programie ten CFWAIT, czytasz CFREG7, odczytujesz CFREG0
.... i co by tu się musiało stać, żeby karta bajt zgubiła?
Jakies zakłocenie na linii CS/IORD czy co tam jest używane?
Nie wiem, czy karta by zdążyła, bo procesor wystawia IORD i wkrótce
zatrzaskuje dane.
Raczej bym się spodziewał, ze zgubi wtedy trzeci bajt.
Chyba, ze problem sie zdarza przy odczycie pierwszego bajtu, procek
odczytuje poprawnie, ale karta widzi jakis kolejny odczyt, który idzie
w próżnie. Ale w pierwszym bajcie 21h.
Akurat stan wysoki to ma raczej mniejsze prądy w TTL, ale raczej nie
na wejsciach NMOS.
Jeśli to coś związane z prądami na liniach danych, to moze połącz
solidniej masy karty, zasilanie, i dodaj kondensatorów przy gnieździe
...
Oscyloskop też byłby ciekawy, ale tu raczej jakis cyfrowy potrzebny,
aby złapać odczyt tego jednego bajtu ...
J.
Atlantis
Guest
Thu May 23, 2024 8:33 pm
On 23.05.2024 18:15, J.F wrote:
Quote:
Jakies zakłocenie na linii CS/IORD czy co tam jest używane?
Nie wiem, czy karta by zdążyła, bo procesor wystawia IORD i wkrótce
zatrzaskuje dane.
Chyba na wyjaśnienie wskazuje znaleziony w Internecie opis podobnej
sytuacji, który przytaczałem wczoraj:
"When the eight data lines of a fast CF disk simultaneously drive
capacitive loads such as a backplane with many boards, especially from
all 0's to all 1's, a large instaneous current is flowing out of the CF
disk, which cause its ground to sink lower than the system reference
ground. The ground negative spike is too brief to affect Z80 and older
TTL technology, but the CF_read line see a brief positive spike when
CF's ground is spiking down. The CF_read controls a FIFO, so a spike can
cause the FIFO to advance to next data byte thus discarding current byte
of data thus corrupt the data packet."
Quote:
Jeśli to coś związane z prądami na liniach danych, to moze połącz
solidniej masy karty, zasilanie, i dodaj kondensatorów przy gnieździe
Kondensatory przy zasilaniu karty są już obecne (100nF + tantal
kilkadziesiąt uF). Zastanawia mnie jeszcze tylko zasilanie. VDD i VSS
idą liniami taśmy, która łączy moduł karty CF z płyta główną. Może to za
mało? Może powinienem pociągnąć masę i 5V osobnymi przewodami, gdzieś z
okolicy bliższej zasilaczowi?
J.F
Guest
Thu May 23, 2024 9:51 pm
On Thu, 23 May 2024 20:33:13 +0200, Atlantis wrote:
Quote:
On 23.05.2024 18:15, J.F wrote:
Jakies zakłocenie na linii CS/IORD czy co tam jest używane?
Nie wiem, czy karta by zdążyła, bo procesor wystawia IORD i wkrótce
zatrzaskuje dane.
Chyba na wyjaśnienie wskazuje znaleziony w Internecie opis podobnej
sytuacji, który przytaczałem wczoraj:
"When the eight data lines of a fast CF disk simultaneously drive
capacitive loads such as a backplane with many boards, especially from
all 0's to all 1's, a large instaneous current is flowing out of the CF
disk, which cause its ground to sink lower than the system reference
ground.
Nie jestem przekonany. prąd płynie od + zasilacza, przez +V karty,
przez linie sygnałowe, do masy gdzies na płycie komputera, i do -
zasilacza. Masa karty nie gra tu roli.
A gdzie podłączona masa karty? nie wiadomo.
Płytkę masz 2 warstwową, czy 4?
Hm ... a jednak nie tak prosto. Bo ten prąd nie płynie z zasilacza,
tylko z kondensatora na karcie. I wraca do - kondensatora.
Ale w którą stronę bedzie impuls napięcia ?
Quote:
The ground negative spike is too brief to affect Z80 and older
TTL technology,
Hm, musialbym odszukac wykresy.
https://deramp.com/downloads/intel/8080%20Data%20Sheet.pdf
aaaa, to jeszcze bardziej skomplikowane, bo sygnały sterujące generuje
dodatkowa kosc.
Strona 9 - odczyt portu jest cyklu M3. DBIN, który jak rozumiem jest
zamieniany na IORD, jest aktywany w podcyklu T2, a dane są
zatrzaskiwanie na początku T3 - mało czasu, kruca bomba..
Quote:
but the CF_read line see a brief positive spike when
CF's ground is spiking down. The CF_read controls a FIFO, so a spike can
cause the FIFO to advance to next data byte thus discarding current byte
of data thus corrupt the data packet."
A karty CF to nie wiem jakie szybkie, potrafia tak szybko przeskoczyc,
czy nie bardzo?
Quote:
Jeśli to coś związane z prądami na liniach danych, to moze połącz
solidniej masy karty, zasilanie, i dodaj kondensatorów przy gnieździe
Kondensatory przy zasilaniu karty są już obecne (100nF + tantal
kilkadziesiąt uF). Zastanawia mnie jeszcze tylko zasilanie. VDD i VSS
idą liniami taśmy, która łączy moduł karty CF z płyta główną. Może to za
mało? Może powinienem pociągnąć masę i 5V osobnymi przewodami, gdzieś z
okolicy bliższej zasilaczowi?
Raczej połączylbym masę okolic procesora z masą karty, jeśli jest taka
możliwość.
J.
Atlantis
Guest
Fri May 24, 2024 7:02 pm
On 23.05.2024 17:47, J.F wrote:
Quote:
nie pamietam ... chyba były jeszcze niemaskowane,
czy to dopiero w Z80 ?
Prawdę mówiąc już nie pamiętam, ale wydaje mi się, że nie. W każdym
razie u mnie system przerwań opiera się na kontrolerze 8259 i używam go
do asynchronicznego odczytywania niektórych peryferiów. Po wykonaniu
instrukcji DI te przerwania przestają przychodzić.
Quote:
IMO - no i dobrze, jesli Z80 lepszy. A pojawił się raptem 2 lata po
8080.
był jeszcze 8085 - taki trochę lepszy 8080.
Tak, wiem. Jednych i drugich mam trochę w podręcznym zapasie i nawet
chodziło mi po głowie, żeby za jakiś czas zrobić też system oparty na
Z80 i 8085. Byłoby o tyle łatwiej, że moje konstrukcje są modułowe, więc
wystarczyłoby przygotować kompatybilną płytę procesorowa i połączyć ją z
istniejącymi peryferiami.
W ten sposób wcześniej udało mi się dość łatwo zrobić komputerek na
MC6802, opierając się na istniejącej konstrukcji z MOS6502 (a jako
niedokończony projekt zacząłem też robi płytkę pod MC68008).
Tyle tylko, że istniejących projektów pod Z80 albo 8085 jest całe
mnóstwo, bo są to systemy relatywnie łatwe w implementacji. Intel 8080
odstrasza takimi szczegółami jak trzy napięcia zasilania, dwufazowy
zegar albo konieczność użycia osobnego kontrolera magistrali.
Quote:
No coż, de gustibus ...
Takie komputerki były za PRL, ale raczej przemysłowe ... i chyba nikt
nie patrzył na polskość, tylko na stawiane wymogi - jak były potrzebne
zagraniczne kości, to się kupowało.
Był przemysłowy komputer MSA80 i pewnie trochę mniej skomplikowanych
sterowników mikroprocesorowych do automatyki.
Jednak były też komputery ogólnego przeznaczenia, jak Elwro 500, Elwro
600, MK45 albo PSPD-90. Tyle tylko, że to wszystko było produkowane z
myślą o instytucjach państwowych, w relatywnie małych seriach.
Społeczeństwo się komputeryzowało oddolnie, sprowadzając sprzęt w ramach
turystyki importowej. ;)
Quote:
Wsadzic mogłeś duzo, ale standard nie przewidywał, to i z programami
gorzej.
Akurat w CP/M szybko zaczęło brakować pamięci, to pewnie był nacisk,
aby pamięc video jakoś bankować.
Jasne - sam standard CP/M przewiduje tylko drukowanie znaków na ekranie,
jakby to był dalekopis. System nie zakłada nawet, że podpięty ekran jest
inteligentnym terminalem, w którym można sterować kursorem. Nie ma więc
gwarancji, że wszędzie zadziałają gry i programy wykorzystujące
manipulowanie semigrafiką. A wszystkie operacje graficzne muszą już
odwoływać się bezpośrednio do sprzętu, bo system nie przewiduje w ogóle
takich standardowych wywołań.
Atlantis
Guest
Fri May 24, 2024 7:15 pm
On 23.05.2024 21:51, J.F wrote:
Quote:
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.
Quote:
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.
Atlantis
Guest
Tue Jun 04, 2024 10:58 am
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.
J.F
Guest
Tue Jun 04, 2024 8:15 pm
On Tue, 4 Jun 2024 10:58:08 +0200, Atlantis wrote:
Quote:
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.
Atlantis
Guest
Fri Jun 07, 2024 7:12 am
On 4.06.2024 20:15, J.F wrote:
Quote:
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ą.
J.F
Guest
Fri Jun 07, 2024 11:45 am
On Fri, 7 Jun 2024 07:12:54 +0200, Atlantis wrote:
Quote:
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.
Atlantis
Guest
Fri Jun 07, 2024 4:18 pm
On 7.06.2024 11:45, J.F wrote:
Quote:
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.
Quote:
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ę.
Atlantis
Guest
Fri Jun 07, 2024 7:00 pm
On 7.06.2024 11:45, J.F wrote:
Quote:
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.
Atlantis
Guest
Tue Jun 25, 2024 9:26 am
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.
Atlantis
Guest
Wed Jul 03, 2024 8:10 am
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ć?
MKi
Guest
Thu Jul 04, 2024 7:45 am
W dniu 2024-07-03 o 08:10, Atlantis pisze:
Quote:
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
Goto page Previous 1, 2, 3 Next