Komputer 8-bitowy

[jethrotull]

Zaczynam powoli wracać między żywych, i postanowiłem wrócić do mojego projektu. Jako że ostatnio miałem więcej czasu żeby programować a mniej siły żeby lutować, zabrałem się za aspekt software'owy, a mianowicie sportowałem na mój komputer CP/M-a. Na załączonym zdjęciu widać jak pracuje. Nie robi póki co za wiele, jedynie narzeka że nie ma dysku, ale działa. Dysk zorganizuję na karcie CF, tylko muszę ją zakupić. 8MB wystarczy po wszystkie czasy na wszystkie moje obecne i przyszłe maszyny z CP/M-em.

20241021_211657.jpg

[jethrotull]

Mam pewien kłopot z kartami Compact Flash.
Spośród trzech moich kart jedna działa zgodnie z założeniami, a dwie pozostałe (różnych producentów i różnych rozmiarów) zapisują jedynie trzy na cztery bajty, a co czwarty bajt nie jest zapisywany. Odczyt działa prawidłowo. Nie sądzę aby była to kwestia prędkości, próbowałem opóźnić każdą operację zapisu o 10ms, bez skutku.

mój kod:

Kod: Zaznacz cały

cf_writeSector:
	PUSH AF
	PUSH BC
	CALL cf_waitCmd			; wait till the cf card is ready for command
	LD A, CF_WRITE			; prepare the write command
	OUT	(CF_CMD), A			; send the write command
	LD B, 0					; write 512 bytes, 2 bytes per loop iteration
.loop:
	CALL cf_waitDat
	LD A, (HL)
	OUT (CF_DAT), A			; write a byte of data	
	INC HL
	CALL cf_waitDat
	LD A, (HL)
	OUT (CF_DAT), A			; write a byte of data	
	INC HL
	DJNZ .loop
	POP BC
	POP AF
	RET

cf_waitCmd:
	PUSH AF
.loop:
	IN A, (CF_STATUS)	; read the cf status word
	BIT 7, A
	JR NZ, .loop		; busy bit (D7) should be 0
	BIT	6, A
	JR Z, .loop			; drvrdy (D6) should be 1 
	POP AF
	RET

cf_waitDat:
	PUSH AF
.loop:
	IN A, (CF_STATUS)	; read the cf status word
	BIT 7, A
	JR NZ, .loop		; busy bit (D7) should be 0
	BIT 3, A
	JR Z, .loop			; drq bit (D3) should be 1
	POP AF
	RET

Czy ktoś się może spotkał z takim problemem?

[Tomasz Gumny]

DJNZ .loop kiedy się kończy? INC HL nie ustawia znaczników.

[jethrotull]

Rejestr B jest licznikiem pętli.

[jethrotull]

Jako że wiem o kartach CF, że są hałaśliwe, dodałem duży kondensator elektrolityczny żeby filtrował zasilanie przy gnieździe taśmy dysku na płycie głównej, i kolejny kondensator ceramiczny 1uF bezpośrednio przy karcie (na płytce adaptera). Jeśli to nie przyniesie efektów, dodam jeszcze dławik między tymi dwoma kondensatorami.

Ostatecznie, CP/M potrzebuje jedynie 128 bajtów na sektor, spośród 512 oferowanych przez kartę CF, więc w najgorszym wypadku będę programowo "omijał" niedziałające bajty, chociaż takie rozwiązanie trudno nazwać eleganckim.

Może też kupię więcej kart tego typu/producenta, który u mnie działa.

[jethrotull]

Żeby nie było że tylko zaczynam nowe projekty i nie kończę starych, oto mój komputer na 8085 w zaimprowizowanej obudowie:

20250309_155439.jpg

20250309_155441.jpg

20250309_155456.jpg

A pamiętacie karty CF, które zapisywały (lub odczytywały, trudno stwierdzić) tylko trzy bajty na każde cztery, a czwarty bajt ignorowały?
Otóż okazało się że moje pozostałe karty, które uważałem za w pełni sprawne/kompatybilne, nie zapisują (lub nie odczytują) ostatnich dwóch bajtów każdego sektora.

Próbowałem różnych sztuczek z opóźnianiem sygnału IORD opisanych tu: https://www.vtsys.pl/interface-compact-flash/
ale bez powodzenia. W końcu, w akcie desperacji, zmniejszyłem rozmiar logicznego sektora do 256 bajtów, a drugą połowę sektora ignoruję. W sumie to dałoby się tak zapisywać sektory, żeby mieć 256 bajtów na sektor i jednocześnie obsługować karty z oboma rodzajami problemu, wystarczyłoby używać dwóch pierwszych bajtów z każdych czterech.

[jethrotull]

Oto kolorowa, bitmapowa karta graficzna, prezentująca niektóre spośród swoich (docelowo) szesnastu kolorów.
Teraz trzeba napisać sterownik.
Niebawem załączę schemat wraz z opisem.

IMG_20251024_170918_hdr.jpg

IMG_20251024_170928_hdr.jpg

[jethrotull]

Podobnie jak w przypadku poprzedniej karty graficznej, sercem układu jest generator sygnałów synchronizacji zrealizowany na pamięci ROM 27C512 (U12). Wejścia adresowe tej pamięci są sterowane licznikami '4040 taktowanymi zegarem 25,125MHz.

Te same liczniki adresują pamięć obrazu: pamięć pikseli i pamięć koloru. Pamięć ta to szybkie układy SRAM 61256-15 o pojemności 32KB każdy. Każdy bajt pamięci koloru zawiera czterobitowy kolor pierwszego plau i również czterobitowy kolor tła. Pamięć pikseli wybiera, dla każdego piksela jeden z dwóch powyższych kolorów. To oznacza, że każde kolejne 8 pikseli może mieć tylko jeden z dwóch kolorów, dowolnie wybranych z maksymalnie szesnastu. Wybór jest fizycznie dokonywany przez multiplekser '157 sterowany z rejestru przesuwnego '165, do którego ładowane są kolejne bajty z pamięci pikseli.

Karta generuje sygnał VGA o nominalnej rozdzielczości 640x480, jednak piksele logiczne mają rozmiar 2x2 pikseli logicznych, stąd efektywna rozdzielczość wynosi 320x240. Każda linia obrazu to 40 bajtów, dodatkowo kolejne 24 bajty są "marnowane" - albo adresowane w trakcie wygaszania albo w ogóle nie adresowane. Pełne pokrycie ekranu wymaga więc 16KB pamięci pikseli i drugie tyle dla koloru.

Aby oszczędzać przestrzeń adresową procesora, pamięć obrazu jest umieszczona w tym samym obszarze adresowym co ROM. Operacje odczytu odwołują się do ROMu, a operacje zapisu do pamięci obrazu.

W trakcie generowania obrazu, pamięć jest adresowana przez liczniki za pośrednictwem rezystorów 1k. Podczas operacji zapisu, aktywują się bufory adresu U5 i U6. Następnie otwierany jest odpowiedni bufor: pikseli lub koloru, odpowiednio U7 lub U8. Skutkiem ubocznym takiego sposobu zapisu jest śnieżenie ekranu widoczne podczas aktualizacji obrazu. Liczniki są nadal podłączone bezpośrednio do generatora sygnałów synchronizacji, stąd operacja zapisu nie wpływa na stabilność obrazu.

Sam sygnał zapisu podawany na wejścia WR pamięci 61256 jest generowany za pomocą detektora zboczy narastających na elementach C1, R1 i U1F. Detektor ten generuje sygnał zapisu w momencie zbocza narastającego zegara procesora, które występuje dokładnie w środku sygnału WR. Dzięki temu zapewniony jest odpowiedni czas stabilizacji adresu (Tas) przed zapisem i podtrzymania danych (Tdh) po zapisie. Oba te czasy mają co prawda wartość 0, wg. karty katalowej układu 61256, jednak w praktyce opóźnienia na buforach powodują konieczność użycia niezerowych czasów.

Oczywiście dzielenie przestrzeni adresowej z pamięcią ROM komputera oznacza, że pamięć obrazu staje się pamięcią tylko do zapisu. Przewijanie obrazu byłoby więc kłopotliwe. Rozwiązaniem jest przewijanie sprzętowe. Pamięć obrazu ma pojemność dwukrotnie większą niż potrzebna do wygenerowania obrazu. Efektywny adres linii jest generowany z wartości liczników '4040 zsumowanej z wartością zapisaną w układzie '574 (U9). 9-bitowy sumator jest zaimplementowany za pomocą dwóch układów '83 i jednej bramki XOR. Zapisywanie do rejetru '574 coraz to większych wartości powoduje przewijanie obrazu. W każdym momencie każda z dwóch pamięci obrazu prezentuje 16KB okno do prszestrzeni adresowej, a adres pierwszej linii obrazu w tym oknie jest przechowywany w rejestrze '574. Adres linii jest dziewięciobitowy, a rejestr tylko ośmiobitowy, stąd przewijanie odbywa się co dwie linie obrazu.

Układ nie zawiera generatora czcionek. Dane czcionek zapisane są natomiast w ROMie komputera i programowo zapisywane do danych pikseli. Oznacza to że zapis każdego znaku 8x8 pikseli wymaga zapisania przez procesor ośmiu bajtów do pamięci pikseli. Z drugiej strony, nic nie stoi na przeszkodzie aby definiować własne kroje czcionek, a nawet zmieniać rozdzielczość czcionki. Możliwe jest np. użycie czcionki 4x8 i uzykanie rozdzielczości 80x30 znaków.

colourVGASchematic.png

[tszczesn]

Bardzo pomysłowa konstrukcja - pozwala na sporo możliwości przy jednocześnie prostym układzie. I ma większe możliwości od Spectrum