Uruchamianie CP/M 2.2 na procesorze MCY7880 z kartą CF w trybie 8-bitowym

Wed May 22, 2024 10:27 am   

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?

Wed May 22, 2024 10:50 am   

On Wed, 22 May 2024 10:27:16 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Masz może video jak to działa?



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

Wed May 22, 2024 11:38 am   

On 22.05.2024 10:50, Marek wrote:


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



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

Wed May 22, 2024 5:57 pm   

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

Wed May 22, 2024 6:21 pm   

On Wed, 22 May 2024 10:27:16 +0200, Atlantis wrote:

Hm, o ile pamiętam, to CP/M miał sektory 128 Bajtów, a karta 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.


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


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

J.

Wed May 22, 2024 6:40 pm   

On Wed, 22 May 2024 17:57:57 +0200, Atlantis 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.


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.

Wed May 22, 2024 6:56 pm   

On 22.05.2024 18:21, J.F wrote:


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.



Tak.



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.



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.

Wed May 22, 2024 7:10 pm   

On 22.05.2024 18:40, J.F wrote:


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



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


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




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



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


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

Wed May 22, 2024 7:14 pm   

On 22.05.2024 18:40, J.F wrote:


Ok. Wartość 0xC0 nie jest pomijana. Czyli ma problem faktycznie z 0xFF.
Trzeba będzie poszukać innej karty, a docelowo zastosować bufory.

Wed May 22, 2024 10:08 pm   

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.

Thu May 23, 2024 10:09 am   

On 22.05.2024 18:21, J.F wrote:


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.

Thu May 23, 2024 10:54 am   

On Thu, 23 May 2024 10:09:17 +0200, Atlantis wrote:

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


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


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

J.

Thu May 23, 2024 11:09 am   

On 23.05.2024 10:54, J.F wrote:


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.



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



Chcę odpalić Zorka na PRL-owskim mikroprocesorze.

Thu May 23, 2024 1:52 pm   

On Thu, 23 May 2024 11:09:19 +0200, Atlantis 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:
-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 ...


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


Są symulatory. A moze nawet jest port.

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

J.

Thu May 23, 2024 3:18 pm   

On 23.05.2024 13:52, J.F wrote:


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.



Jak wynika z kodu który wrzuciłem, proszę o 32 sektory (16kB).


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.



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.



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



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



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.