Parę lat temu zacząłem budować prosty komputerek na polskim
mikroprocesorze MCY7880. Zaczęło się od migania diodą i przesyłania
znaków przez UART, ale na chwilę obecną mam już właściwie kompletny
system z klawiaturą i monitorem, zdolny do uruchamiania Tiny Basica z
pamięci EPROM. Docelowo jednak moim celem od początku było uruchomienie
na tym CP/M 2.2 i ładowanie programów z dysku (w tej roli podpięta
bezpośrednio do magistrali karta CF, pracująca w trybie 8bit).

Podczas pandemii prace nad projektem nieco spowolniły, ale ostatnio
powróciłem do niego. Na chwilę obecną mam już działający bootloader,
który pozwala na załadowanie programu do pamięci RAM. Działa to mniej
więcej w następujący sposób:

1. Program podejmuje próbę zainicjowania karty CF, pobiera strukturę z
informacjami i wyświetla na ekranie jej nazwę.
2. Program odczytuje pierwszy sektor karty CF i sprawdza, czy określone
bajty mają wartości, których można się spodziewać po MBR w stylu MS-DOS.
3. Program odczytuje i wyświetla na ekranie tablicę partycji (adresy i
rozmiary poszczególnych partycji).
4. Program wyświetla menu, pozwalając użytkownikowi wybrać bootowanie z
karty albo uruchomienie Tiny Basica z EPROM-u.
5. Jeśli użytkownik wybierze bootowanie z CF, program sprawdza czy
pierwsza partycja ma odpowiedni rozmiar. Jeśli tak, pobiera jej adres i
ładuje pierwszych 16kB do RAM-u (zaczynając od adresu 0x0000).
6. Program wykonuje skok bezwarunkowy pod adres 0x0000.
7. Jeśli karta CF nie zostanie poprawnie zainicjowana lub nie powiedzie
się któryś z wspomnianych testów, uruchamiany jest od razu TinyBasic.

Takie podejście pozwala mi dość łatwo wgrywać na kartę testowe programy
- wystarczy wrzucić plik bin za pomocą dd:

dd if=source.bin of=/dev/sdx1 bs=512

Podczas wstępnych testów miałem problem z niektórymi modelami karty CF.
O ile struktura z nazwą odczytywała się zawsze poprawnie, to karta użyta
początkowo (wszystkie egzemplarze tego samego modelu, bodajże SanDisk
32MB) dawała dziwne rezultaty podczas próby odczytu MBR-a/tablicy
partycji. Co kilka prób pojawiały się przekłamania wartości i jakieś
dziwne przesunięcie o kilka bajtów w buforze. Kolejna karta (jakaś
przemysłowa WD 256MB) działa już o wiele lepiej i to właśnie jej używam
obecnie podczas testów.

O ile MBR jak dotąd ładuje się zawsze poprawnie, to jednak ze dwa razy
rzucił mi się w oczy dziwny błąd. Jak wspominałem, program testowy to
krótka pętla printująca z opóźnieniem wartość hex jednego bajtu
(konkretnie 0xFA). Wykonywany kod wykorzystuje gotowe procedury,
zapisane w pamięci EPROM, tak wiec składa się on zaledwie z kilku
wywołań CALL, poprzedzonych ładowaniem wartości do rejestrów. Testując
program od kilku dni już dwa razy zauważyłem sytuację, kiedy wykonywał
się on znacznie szybciej - zupełnie jakby przekłamana została wartość
odpowiadająca za czas trwania pętli opóźniającej. Trochę mnie to dziwi,
bo byłoby to dość specyficzne przekłamanie, które pojawiło się dwa razy.

Trochę mnie to jednak niepokoi, bo jeśli problemy pojawiają się przy
ładowaniu tak krótkiego programu, to tym bardziej mogą pojawić się przy
próbie załadowania całego CP/M (gdy już przygotuję niskopoziomowe
procedury I/O).

Zacząłem trochę czytać i analizować inne podobne projekty retro i widzę,
że w wielu z ich przed kartą CF stosowane są bufory 74HC245. Ludzie
wspominają też o problemach i konieczności dobierania kompatybilnej
karty w przypadku, gdy tego bufora nie ma. W dodatku ja w tej chwili
pracują na prototypie zbudowanym na płytce uniwersalnej (przy pomocy
dużej ilości kynaru), gdzie karta jest umieszczona na osobnym module,
podpiętym za pomocą taśmy (jednocześnie powstaje nowsza wersja na
trawionym PCB).

Myślicie, że jest szansa na dobranie karty, która będzie poprawnie
pracowała ze starym procesorem NMOS (tym bardziej, że raz dobrana karta
zostanie tam na stałe i nie będzie podmieniana) czy jednak nieuniknione
będzie zmodyfikowanie projektu i dodanie 74HC245?

do góry

On Wed, 22 May 2024 10:27:16 +0200, Atlantis <m...@w...pl>
wrote:
> 1. Program podejmuje próbę zainicjowania karty CF, pobiera
> strukturę z
> informacjami i wyświetla na ekranie jej nazwę.

Masz może video jak to działa?


> Myślicie, że jest szansa na dobranie karty, która będzie poprawnie
> pracowała ze starym procesorem NMOS (tym bardziej, że raz dobrana
> karta
> zostanie tam na stałe i nie będzie podmieniana) czy jednak
> nieuniknione
> będzie zmodyfikowanie projektu i dodanie 74HC245?

Wyczuwam, że gdzieś między wierszami jest sugestia jakoby był jakiś
problem między technologią NMOS a kartą CF, mógłbys zdradzić o co
chodzi? Inne różnice poziomów logicznych?

--
Marek

do góry

On 22.05.2024 10:50, Marek wrote:

> Masz może video jak to działa?

Potem nakręcę i gdzieś wrzucę. Przy czym nie jestem pewien czy uda mi
się zreprodukować sam błąd.


> Wyczuwam, że gdzieś między wierszami jest sugestia jakoby był jakiś
> problem między technologią NMOS a kartą CF, mógłbys zdradzić o co
> chodzi? Inne różnice poziomów logicznych?

Też o tym myślałem, przy czym nie udało mi się na szybko znaleźć w
internecie informacji o tym, czy i w jakim stopniu technologia NMOS
różni się od CMOS (przy zasilaniu 5V). Noty katalogowe kart CF czasami
ostrzegają przed niekompatybilnością ze standardem TTL. Ale czy można
postawić znak równości pomiędzy NMOS i TTL w tym względzie - nie wiem...

No i w każdym razie problem jest dziwnie powtarzalny. Zawsze objawia się
w ten sam sposób - czasem opóźnienie pomiędzy kolejnymi printowanymi
wartościami jest mniejsze. Gdyby chodziło o poziomy napięć, to
należałoby się spodziewać chaosu na magistrali i losowych przekłamań. W
przypadku pojawienia się takich problemów program powinien przeważnie
crashować, i to na różne sposoby. Tymczasem to się nie dzieje.

Zastanawiam się jeszcze czy przypadkiem komórka pamięci do której trafia
ta konkretna wartość nie jest jakaś problematyczna - albo z powodu
wewnętrznego uszkodzenia, albo przez kiepski kontakt z podstawką.

do góry

Zrobiłem kilka dodatkowych testów i wyniki są... Zaskakujące...
Po pierwsze dodałem do kodu hexdump pierwszych 32 bajtów pamięci po
załadowaniu kodu z karty CF. Cały programik ma zaledwie 20 bajtów, więc
jest to wystarczająca liczba.

Zawartość binarnego pliku wygląda następująco: 21 FF 7F F9 C3 07 00 0E
20 CD 27 C5 3E FA CD B3 C5 C3 07 00

Zawartość pamięci, gdy program printuje znaki szybko: 21 FF 7F F9 C3 07
00 0E 20 CD 27 C5 3E FA CD B3 C5 C3 07 00 37 30 30 30 45 32 30 43 44 31
45 43

Zawartość pamięci, gdy program printuje znaki wolno: 21 7F F9 C3 07 00
0E 20 CD 27 C5 3E FA CD B3 C5 C3 07 00 37 30 30 30 45 32 30 43 44 31 45
43 35

Już na pierwszy rzut oka widać, gdzie leży sedno problemu - pomijany
jest drugi bajt o wartości 0xFF. Wbrew mojemu oryginalnemu założeniu, to
szybkie printowanie jest poprawnym wynikiem. Wolniejsze działanie
(chociaż występuje znacznie) częściej stanowi efekt działania błędu.

Wbrew moim podejrzeniom, błąd nie miesza w pętli opóźniającej, ale
sabotuje początkowe ustawienie wartości stosu:

0000 ORG 0000H
0000 21 ff 7f START: LXI H,STACK
0003 f9 SPHL
0004 c3 07 00 JMP LOOP

Wygląda więc na to, że w wyniku błedu do pary rejestrów HL trafia
wartość 0x7ff9, ale rozkaz SPHL nie jest wykonywany (bo kod interpretuje
jego wartość jako parametr instrukcji LXI). Wskaźnik stosu pozostaje
więc taki, jakim ustawił go bootloader. Dlaczego powoduje to wolniejsze
działanie programu? Nie mam pojęcia. Dlaczego ładowanie danych z karty
odbywa się z tak zadziwiająco powtarzalnym błędem? Też nie wiem...

Poeksperymentuję jeszcze z kilkoma kartami. Jeśli jednak nie uda mi się
znaleźć takiej, która będzie działała w 100% poprawnie, to trudno będzie
myśleć o eksperymentach z CP/M. Pomyślałbym, że to faktycznie wina
poziomów napięć i braku bufora. Tylko ta powtarzalność... Problem z
niedopasowaniem poziomów napięć mógłby powodować losowe przekłamania
bitów, ale nie konsystentne pomijanie całego bajtu...

do góry

On Wed, 22 May 2024 10:27:16 +0200, Atlantis wrote:
> Parę lat temu zacząłem budować prosty komputerek na polskim
> mikroprocesorze MCY7880. Zaczęło się od migania diodą i przesyłania
> znaków przez UART, ale na chwilę obecną mam już właściwie kompletny
> system z klawiaturą i monitorem, zdolny do uruchamiania Tiny Basica z
> pamięci EPROM. Docelowo jednak moim celem od początku było uruchomienie
> na tym CP/M 2.2 i ładowanie programów z dysku (w tej roli podpięta
> bezpośrednio do magistrali karta CF, pracująca w trybie 8bit).

Hm, o ile pamiętam, to CP/M miał sektory 128 Bajtów, a karta 512.

> Podczas pandemii prace nad projektem nieco spowolniły, ale ostatnio
> powróciłem do niego. Na chwilę obecną mam już działający bootloader,
> który pozwala na załadowanie programu do pamięci RAM. Działa to mniej
> więcej w następujący sposób:
>
> 1. Program podejmuje próbę zainicjowania karty CF, pobiera strukturę z
> informacjami i wyświetla na ekranie jej nazwę.
> 2. Program odczytuje pierwszy sektor karty CF i sprawdza, czy określone
> bajty mają wartości, których można się spodziewać po MBR w stylu MS-DOS.
> 3. Program odczytuje i wyświetla na ekranie tablicę partycji (adresy i
> rozmiary poszczególnych partycji).
> 4. Program wyświetla menu, pozwalając użytkownikowi wybrać bootowanie z
> karty albo uruchomienie Tiny Basica z EPROM-u.
> 5. Jeśli użytkownik wybierze bootowanie z CF, program sprawdza czy
> pierwsza partycja ma odpowiedni rozmiar. Jeśli tak, pobiera jej adres i
> ładuje pierwszych 16kB do RAM-u (zaczynając od adresu 0x0000).
> 6. Program wykonuje skok bezwarunkowy pod adres 0x0000.
> 7. Jeśli karta CF nie zostanie poprawnie zainicjowana lub nie powiedzie
> się któryś z wspomnianych testów, uruchamiany jest od razu TinyBasic.
>
> Takie podejście pozwala mi dość łatwo wgrywać na kartę testowe programy
> - wystarczy wrzucić plik bin za pomocą dd:
>
> dd if=source.bin of=/dev/sdx1 bs=512

Na linuxie to robisz?
Hm, nie jestem pewien, czy tak można, w pierwszym sektorze partycji
powinny być określone dane w DOS/Windows. Jeli ich nie ma ... ciekawe,
co zwariuje.

> Podczas wstępnych testów miałem problem z niektórymi modelami karty CF.
> O ile struktura z nazwą odczytywała się zawsze poprawnie, to karta użyta
> początkowo (wszystkie egzemplarze tego samego modelu, bodajże SanDisk
> 32MB) dawała dziwne rezultaty podczas próby odczytu MBR-a/tablicy
> partycji. Co kilka prób pojawiały się przekłamania wartości i jakieś
> dziwne przesunięcie o kilka bajtów w buforze. Kolejna karta (jakaś
> przemysłowa WD 256MB) działa już o wiele lepiej i to właśnie jej używam
> obecnie podczas testów.

Do sprawdzenia - nie powinno być takich cudów.
A jesli są, to gdzieś jest błąd :-)

> O ile MBR jak dotąd ładuje się zawsze poprawnie, to jednak ze dwa razy
> rzucił mi się w oczy dziwny błąd. Jak wspominałem, program testowy to
> krótka pętla printująca z opóźnieniem wartość hex jednego bajtu
> (konkretnie 0xFA). Wykonywany kod wykorzystuje gotowe procedury,
> zapisane w pamięci EPROM, tak wiec składa się on zaledwie z kilku
> wywołań CALL, poprzedzonych ładowaniem wartości do rejestrów. Testując
> program od kilku dni już dwa razy zauważyłem sytuację, kiedy wykonywał
> się on znacznie szybciej - zupełnie jakby przekłamana została wartość
> odpowiadająca za czas trwania pętli opóźniającej. Trochę mnie to dziwi,
> bo byłoby to dość specyficzne przekłamanie, które pojawiło się dwa razy.
>
> Trochę mnie to jednak niepokoi, bo jeśli problemy pojawiają się przy
> ładowaniu tak krótkiego programu, to tym bardziej mogą pojawić się przy
> próbie załadowania całego CP/M (gdy już przygotuję niskopoziomowe
> procedury I/O).
>
> Zacząłem trochę czytać i analizować inne podobne projekty retro i widzę,
> że w wielu z ich przed kartą CF stosowane są bufory 74HC245. Ludzie
> wspominają też o problemach i konieczności dobierania kompatybilnej
> karty w przypadku, gdy tego bufora nie ma. W dodatku ja w tej chwili
> pracują na prototypie zbudowanym na płytce uniwersalnej (przy pomocy
> dużej ilości kynaru), gdzie karta jest umieszczona na osobnym module,
> podpiętym za pomocą taśmy (jednocześnie powstaje nowsza wersja na
> trawionym PCB).
>
> Myślicie, że jest szansa na dobranie karty, która będzie poprawnie
> pracowała ze starym procesorem NMOS (tym bardziej, że raz dobrana karta
> zostanie tam na stałe i nie będzie podmieniana) czy jednak nieuniknione
> będzie zmodyfikowanie projektu i dodanie 74HC245?

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

J.

do góry

On Wed, 22 May 2024 17:57:57 +0200, Atlantis wrote:
> Zrobiłem kilka dodatkowych testów i wyniki są... Zaskakujące...
> Po pierwsze dodałem do kodu hexdump pierwszych 32 bajtów pamięci po
> załadowaniu kodu z karty CF. Cały programik ma zaledwie 20 bajtów, więc
> jest to wystarczająca liczba.
>
> Zawartość binarnego pliku wygląda następująco: 21 FF 7F F9 C3 07 00 0E
> 20 CD 27 C5 3E FA CD B3 C5 C3 07 00
>
> Zawartość pamięci, gdy program printuje znaki szybko: 21 FF 7F F9 C3 07
> 00 0E 20 CD 27 C5 3E FA CD B3 C5 C3 07 00 37 30 30 30 45 32 30 43 44 31
> 45 43
>
> Zawartość pamięci, gdy program printuje znaki wolno: 21 7F F9 C3 07 00
> 0E 20 CD 27 C5 3E FA CD B3 C5 C3 07 00 37 30 30 30 45 32 30 43 44 31 45
> 43 35
>
> Już na pierwszy rzut oka widać, gdzie leży sedno problemu - pomijany
> jest drugi bajt o wartości 0xFF. Wbrew mojemu oryginalnemu założeniu, to
> szybkie printowanie jest poprawnym wynikiem. Wolniejsze działanie
> (chociaż występuje znacznie) częściej stanowi efekt działania błędu.
>
> Wbrew moim podejrzeniom, błąd nie miesza w pętli opóźniającej, ale
> sabotuje początkowe ustawienie wartości stosu:
>
> 0000 ORG 0000H
> 0000 21 ff 7f START: LXI H,STACK
> 0003 f9 SPHL
> 0004 c3 07 00 JMP LOOP
>
> Wygląda więc na to, że w wyniku błedu do pary rejestrów HL trafia
> wartość 0x7ff9, ale rozkaz SPHL nie jest wykonywany (bo kod interpretuje
> jego wartość jako parametr instrukcji LXI). Wskaźnik stosu pozostaje
> więc taki, jakim ustawił go bootloader. Dlaczego powoduje to wolniejsze
> działanie programu? Nie mam pojęcia.

Masz też przestawiony program o cały bajt. Wiec choćby ten LOOP, jest
teraz pod adresem 0006, a skok jest nadal do 0007, czyli pomijasz
pierwszy bajt pętli. Co tam jest istotnego, to sam musisz zobaczyc.

> Dlaczego ładowanie danych z karty
> odbywa się z tak zadziwiająco powtarzalnym błędem? Też nie wiem...
>
> Poeksperymentuję jeszcze z kilkoma kartami. Jeśli jednak nie uda mi się
> znaleźć takiej, która będzie działała w 100% poprawnie, to trudno będzie
> myśleć o eksperymentach z CP/M. Pomyślałbym, że to faktycznie wina
> poziomów napięć i braku bufora. Tylko ta powtarzalność... Problem z
> niedopasowaniem poziomów napięć mógłby powodować losowe przekłamania
> bitów, ale nie konsystentne pomijanie całego bajtu...

A jak czytasz? Spodziewam się, ze po ustawieniu numeru sektora i
komendy odczytu go, wystarczy już odczytać kolejne bajty.
Takie zniknięcie bajtu może być spowodowane:
-karta zobaczyła fałszywą informacje o odczycie bajtu, i przeskoczyła
na następny. A to może być spowodowane właśnie poziomami napięcia,
zakłóceniami elektrycznymi, itp. Ale czemu tylko pod drugim bajtem?
A może wcale nie tylko pod drugim, i więcej bywa zgubione?

A wpisz tam inną wartość, np C0, w koncu możesz ustwic stos na
7FC0, zobaczysz czy to wartosc FF jest wredna.

-przeskoczenie licznika/indeksu w bootloaderze? Ale jaki mógłby być
powód, i czemu tylko na drugim bajcie.

Zrobiłbym też długi dump.
I moze dodał do programu kilka tablic po 256B o kolejnych wartosciach
- zobaczysz na dumpie czy się poprawnie wczytują.

J.

do góry

On 22.05.2024 18:21, J.F wrote:

> Hm, o ile pamiętam, to CP/M miał sektory 128 Bajtów, a karta 512.

Na tym etapie to jeszcze nie ma znaczenia. Teraz po prostu próbuję
osiągnąć ten punkt, w którym binarny obraz systemu zapisany na
określonej sekwencji sektorów karty (rozpoczynającej się w miejscu,
gdzie w tabeli partycji wypada początek pierwszej partycji) trafia w
odpowiednie miejsce RAM-u i zostaje wykonany.
Geometrią dysku będę musiał się martwić dopiero wtedy, gdy zacznę
uruchamiać niskopoziomowe procedury odpowiadające z dostęp do dysku. Tak
naprawdę nie jestem tu pierwszy - istnieją projekty ludzi, którzy
nauczyli CP/M korzystać z kart CF albo SD. Nie wspominając już o tym, że
współczesne nośniki mają kolejno numerowane sektory LBA, podczas gdy
dyski/dyskietki z epiki miały bardziej skomplikowaną geometrię. Trzeba
będzie to przetłumaczyć. Bootloadera to wszystko jednak nie obchodzi -
on po prostu kopiuje do RAM-u sekwencję 16kB, zaczynając od początku
pierwszej partycji.


> Na linuxie to robisz?

Tak.


> Hm, nie jestem pewien, czy tak można, w pierwszym sektorze partycji
> powinny być określone dane w DOS/Windows. Jeli ich nie ma ... ciekawe,
> co zwariuje.

To miałoby znaczenie, gdybym używał DOS-owych/windowsowych partycji.
Tutaj jednak jedynym co mnie interesuje jest MBR i pierwsza partycja,
która na chwilę obecną może być równie dobrze niesformatowana.
Oczywiście dd nadpisze jej pierwszy sektor plikiem binarnym i nie będzie
ona miała sensu dla współczesnych systemów, jednak mój komputerek po
prostu odczyta sobie z tego miejsca obraz systemu i skopiuje go do pamięci.
Na dalszym etapie nauczę CP/M traktować inną partycję (albo nawet tę
samą, ale zaczynając od odpowiednio późniejszych sektorów) jak dysk
systemowy.


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

W prototypie nie, bo tam karta CF znajduje się na osobnym module,
połączonym z płyta główną za pomocą taśmy. Wystarczy, że zaprojektuję
jeszcze jeden modulik wpinany między nie. Gorzej z wersją "finalną", z
trawioną płytką. Tam się pospieszyłem i już umieściłem gniazdko karty CF
na jednej z kilku płytek tworzących urządzenie. Teraz pewnie musiałbym
zaprojektować jeszcze jeden moduł, z gniazdkiem i buforami, podpinany
bezpośrednio do magistrali.

do góry

On 22.05.2024 18:40, J.F wrote:

> Masz też przestawiony program o cały bajt. Wiec choćby ten LOOP, jest
> teraz pod adresem 0006, a skok jest nadal do 0007, czyli pomijasz
> pierwszy bajt pętli. Co tam jest istotnego, to sam musisz zobaczyc.

Masz rację. Jakoś mi to umknęło. ;)


> A jak czytasz? Spodziewam się, ze po ustawieniu numeru sektora i
> komendy odczytu go, wystarczy już odczytać kolejne bajty.

Dokładnie tak. Całośc odbywa się względnie bezobsługowo. Po prostu
zgłaszamy karcie ile sektorów chcemy odczytać i zaczynając od którego, a
potem w pętli czytamy sprawdzając flagi ustawiane przez kartę.

LOAD_PARTITION1:
; Pod LOAD_BASE znajduje się już odczytany MBR
LXI D, LOAD_BASE+446+8
LDAX D
OUT CFREG3 ;LBA 0
INX D
LDAX D
OUT CFREG4 ;LBA 1
INX D
LDAX D
OUT CFREG5 ;LBA 2
INX D
LDAX D
ANI 0FH ;FILTER OUT LBA BITS
ORI 0E0H ;MODE LBA, MASTER DEV
OUT CFREG6 ;LBA 3
MVI A, 32 ;READ 32 SECTORS (16kB)
OUT CFREG2
CALL CFWAIT
MVI A, 20H ;READ SECTOR COMMAND
OUT CFREG7
LXI D, LOAD_BASE
CALL CFREAD
CALL CFCHERR
RET

CFREAD:
CALL CFWAIT
IN CFREG7
ANI 08H ;FILTER OUT DRQ
JZ CFREADE
IN CFREG0 ;READ DATA BYTE
STAX D
INX D
JMP CFREAD
CFREADE:
RET

CFCHERR:
IN CFREG7
ANI 01H ;MASK OUT ERROR BIT
JZ CFNERR
LXI D, CFERRM
CALL PRTSTG
IN CFREG1
MOV L, A
MVI H, 0H
MVI C, 4H
CALL PRTNUM
CFNERR:
RET

> Takie zniknięcie bajtu może być spowodowane:
> -karta zobaczyła fałszywą informacje o odczycie bajtu, i przeskoczyła
> na następny. A to może być spowodowane właśnie poziomami napięcia,
> zakłóceniami elektrycznymi, itp. Ale czemu tylko pod drugim bajtem?
> A może wcale nie tylko pod drugim, i więcej bywa zgubione?

Też o tym pomyślałem. Tym bardziej, że szukając na szybko trafiłem w
Internecie na taką wypowiedź:

"From CPU speed of 7Mhz to 20MHz, the CF disk is generally fast enough
that no wait state is needed. Slowing down or speeding up the CPU clock
does not change the CF interface characteristic. The 'fast' or 'slow' CF
disk refers to the rising and falling edges of the CF output signals.
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. In short, the data corruption is
self inflicted that only 'fast' CF can generate the fast ground spike
that the 'fast' CF_read can react to. For the 'slow' CF, the ground
spike is of insufficient magnitude or duration to cause its 'slow'
CF_read to skip a byte of data."



> A wpisz tam inną wartość, np C0, w koncu możesz ustwic stos na
> 7FC0, zobaczysz czy to wartosc FF jest wredna.

Też o tym pomyślałem, zrobię taki test.


> -przeskoczenie licznika/indeksu w bootloaderze? Ale jaki mógłby być
> powód, i czemu tylko na drugim bajcie.

Mało prawdopodobne. Instrukcja INX wykonuje się po każdym zapisanym
bajcie. Musiałby ten jeden raz nie przeskoczyć, powodując nadpisanie
tego 0xFF.

> Zrobiłbym też długi dump.
> I moze dodał do programu kilka tablic po 256B o kolejnych wartosciach
> - zobaczysz na dumpie czy się poprawnie wczytują.

Będę musiał zmodyfikować kod hexdumpa, żeby wywalał to na RS232, bo na
razie korzystam z ekranu. ;)

do góry

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.

do góry

I jeszcze jedna kwestia, o której zapomniałem wspomnieć. To nie jest
pierwszy raz, kiedy używam karty CF w projekcie z ośmiobitowym
mikroprocesorem retro. Parę lat temu zbudowałem pewne urządzenie, które
zapisywało dane w pliku na karcie. Wtedy działał tam już pełnoprawny
system plików - po wprowadzeniu paru niezbędnych zmian udało mi się
skompilować FatFS za pomocą CC65.
Główne różnice w stosunku do obecnej sytuacji były trzy (jeśli nie
liczyć faktu, że kod był napisany w C, a nie asemblerze):
1. Użyłem CPU 6502 zamiast 8080.
2. Procesor był w technologii CMOS, a nie NMOS.
3. Karta była znacznie większa (aby było miejsce na zapisywane dane).

Gdyby pojawiały się podobne problemy z gubionymi bajtami, FatFS
momentalnie by się wykrzaczył. Tymczasem urządzenie poprawnie działało
całymi miesiącami.
Stawiam więc na to, że albo technologia procesora ma znaczenie, albo te
małe przemysłowe karty (których używam obecnie) są szybsze od
przeciętnych, większych, fotograficznych.

do góry