On 22.05.2024 18:21, J.F wrote:

> Hm, a duży problem dodać?
> Bo jeśli to ma rozwiązać problemy ... to dodać od razu :-)

Sprawdziłem jakie inne karty CF mam pod ręką. Okazuje się, że jakiś tani
EMTEC 512MB w zmęczonej życiem obudowie działa zupełnie poprawnie. A
przynajmniej poprawnie ładuje testowy programik z wartością 0xFF.
Nie wiem czy nie dodam dodatkowego checka do bootloadera - zliczanie
odebranych bajtów i finalne sprawdzanie, czy skopiowane zostało
faktycznie dokładnie 16kB. Nie uchroni mnie to przed przekłamanymi
wartościami (chociaż tego problemu jak na razie nie zaobserwowałem) ale
będę wiedział czy faktycznie żaden bajt nie został pominięty.
A finalnie pewnie dodam bufory na liniach karty. :)

do góry

On Thu, 23 May 2024 10:09:17 +0200, Atlantis wrote:
> On 22.05.2024 18:21, J.F wrote:
>> Hm, a duży problem dodać?
>> Bo jeśli to ma rozwiązać problemy ... to dodać od razu :-)
>
> Sprawdziłem jakie inne karty CF mam pod ręką. Okazuje się, że jakiś tani
> EMTEC 512MB w zmęczonej życiem obudowie działa zupełnie poprawnie. A
> przynajmniej poprawnie ładuje testowy programik z wartością 0xFF.
> Nie wiem czy nie dodam dodatkowego checka do bootloadera - zliczanie
> odebranych bajtów i finalne sprawdzanie, czy skopiowane zostało
> faktycznie dokładnie 16kB.

Skoro nie masz tego problemu juz dziś, to widać karta nie robi
problemu z odczytem nadmiarowych (z jej punktu widzenia) bajtów.

> Nie uchroni mnie to przed przekłamanymi
> wartościami (chociaż tego problemu jak na razie nie zaobserwowałem) ale
> będę wiedział czy faktycznie żaden bajt nie został pominięty.

Jakas suma kontrolna by się niewątpliwie przydała.

> A finalnie pewnie dodam bufory na liniach karty. :)

Ee, warto to? Po co Ci ten CP/M ?
Chcesz Turbo Pascala 1.0 zobaczyc?

J.

do góry

On 23.05.2024 10:54, J.F wrote:

> Skoro nie masz tego problemu juz dziś, to widać karta nie robi
> problemu z odczytem nadmiarowych (z jej punktu widzenia) bajtów.

Nie o to chodzi. Miałem na myśli zliczanie bajtów odebranych po stronie
komputera. Karta otrzymuje żądanie udostępnienia określonej liczby
sektorów. Komputer ustawia wskaźnik początku bufora i pętli odczytuje
flagi zajętości i dostępności danych udostępniane przez kartę. Jeśli
dane są dostępne, pobiera je, zapisuje i inkrementuje wskaźnik bufora
To karta w pewnym momencie pomija bajt i przeskakuje do przodu. Z punktu
widzenia komputera wszystko nadal jest w porządku.
Jeśli będę zliczał zapisywane bajty, to po fakcie będę mógł wiedzieć,
czy faktycznie załadowała się całość. I na tej podstawie będe mógł
podjąć decyzję: wykonać program czy wyprintować informację o błędzie.


> Jakas suma kontrolna by się niewątpliwie przydała.

Tak, chociaż to trochę skomplikuje mechanizm tworzenia obrazu,
nagrywania go na kartę i ładowania do pamięci. Z drugiej strony mógłbym
do tego wykorzystać początek partycji, oryginalnie wykorzystywany na
bootloader. Oryginalnie komputer wczytywał stamtąd krótki programik,
który mówił mu jak załadować resztę systemu z dysku. Mi to do niczego
nie jest potrzebne, bo bootloader zapisany w EPROM-ie za jednym razem
ładuje z pamięci całość danych i nie trzeba kombinować. Niemniej adresy
nadal muszą być odpowiednio wyrównane, wiec ten fragment jest
nieużywany. W przyszłości mógłbym tam zapisywać jakaś sumę kontrolną.


> Ee, warto to? Po co Ci ten CP/M ?
> Chcesz Turbo Pascala 1.0 zobaczyc?

Chcę odpalić Zorka na PRL-owskim mikroprocesorze. ;)

do góry

On Thu, 23 May 2024 11:09:19 +0200, Atlantis wrote:
> On 23.05.2024 10:54, J.F wrote:
>> Skoro nie masz tego problemu juz dziś, to widać karta nie robi
>> problemu z odczytem nadmiarowych (z jej punktu widzenia) bajtów.
>
> Nie o to chodzi. Miałem na myśli zliczanie bajtów odebranych po stronie
> komputera. Karta otrzymuje żądanie udostępnienia określonej liczby
> sektorów. Komputer ustawia wskaźnik początku bufora i pętli odczytuje
> flagi zajętości i dostępności danych udostępniane przez kartę. Jeśli
> dane są dostępne, pobiera je, zapisuje i inkrementuje wskaźnik bufora
> To karta w pewnym momencie pomija bajt i przeskakuje do przodu. Z punktu
> widzenia komputera wszystko nadal jest w porządku.

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:
-wysłałes do karty żądanie odczytu większej ilosci sektorów, i
oczekuje nadmiar na odczyt,
-karta automatycznie udostępnia kolejne sektory,
-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 ?

-karta jakas taka, że sama wewnętrznie przeskakuje ten 1 bajt, i potem
uzupełnia ... IMO, mało prawdopodobne ...

>> Jakas suma kontrolna by się niewątpliwie przydała.
>
> Tak, chociaż to trochę skomplikuje mechanizm tworzenia obrazu,
> nagrywania go na kartę i ładowania do pamięci. Z drugiej strony mógłbym
> do tego wykorzystać początek partycji, oryginalnie wykorzystywany na
> bootloader. Oryginalnie komputer wczytywał stamtąd krótki programik,

Albo ostatnie bajty obrazu. Przygotujesz obraz, przepuscisz przez
program generujący sumę kontrolne, zapisze w pliku,
a potem plik zapiszesz na kartę.

> który mówił mu jak załadować resztę systemu z dysku. Mi to do niczego
> nie jest potrzebne, bo bootloader zapisany w EPROM-ie za jednym razem
> ładuje z pamięci całość danych i nie trzeba kombinować. Niemniej adresy
> nadal muszą być odpowiednio wyrównane, wiec ten fragment jest
> nieużywany. W przyszłości mógłbym tam zapisywać jakaś sumę kontrolną.
>
>> Ee, warto to? Po co Ci ten CP/M ?
>> Chcesz Turbo Pascala 1.0 zobaczyc?
>
> Chcę odpalić Zorka na PRL-owskim mikroprocesorze. ;)

Są symulatory. A moze nawet jest port.

Przecież CP/M nie miał grafiki, to tekstowa gra ?

J.

do góry

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. 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.


> -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
całego systemu. Przerwania w tym konkretnym momencie są wyłączone na
poziomie procesora (instrukcja DI).
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.


> -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. 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...


> Są symulatory. A moze nawet jest port.

Oczywiście, że są. Tylko co do za przyjemność? ;)
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.
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. ;)


> 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ś
programowej warstwy kompatybilności dało się odpalać gry z jakiejś
platformy opartej na Z80 i TMS99xx (MSX? Sega?), 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. ;)

Innym anachronizmem w projekcie jest pecetowy kontroler klawiatury,
jednak dzięki temu nie musiałem się bawić z budowaniem własnej -
komputer działa z klasyczną klawiaturą AT/PS2.

do góry

On Thu, 23 May 2024 15:18:07 +0200, Atlantis wrote:
> 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.

> 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.

>> -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.

> 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 ?

> 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ł.

>> -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ść.

> 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ę ...

>> 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 ...

> 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.

> 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.

>> 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ć.

> 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.

> 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.

do góry

On Wed, 22 May 2024 19:14:48 +0200, Atlantis wrote:
> 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.

do góry

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. 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."


> 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?

do góry

On Thu, 23 May 2024 20:33:13 +0200, Atlantis wrote:
> 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 ?

> 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%20She
et.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..


> 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?

>> 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.

do góry

On 23.05.2024 17:47, J.F wrote:

> 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ć.


> 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.


> 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. ;)


> 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ń.

do góry