Próbuję właśnie uruchomić własną konstrukcję - komputerek pod CP/M
(docelowo także MP/M), zbudowany na relatywnie niszowym CPU od Ziloga,
Z80182. W wielkim skrócie jest to Z180 z kilkoma dodatkowymi bajerami.
https://www.zilog.com/docs/z180/z80182.pdf

Na chwilę obecną udało mi się sprawić, że płytka wykonuje kod z flasha.
Jestem w stanie pisać do wewnętrznych rejestrów (na oscyloskopie widać
wpływ np. po ustawieniu wait-state'ów) i zmieniać stan pinów GPIO.

Utknąłem natomiast na próbach skorzystania z RAM-u, przez co nie mogę
nawet skorzystać ze stosu.

Pamięć SRAM (AS6C4008) korzysta z wbudowanego w układ dekodera adresów,
a więc linia /OE jest podłączona do wyjścia /RAMCS. Rejestry
konfigurujące dekoder są ustawione poprawnie, bo jeśli próbuje pisać pod
adres odpowiadający pamięci RAM, na linii RAMCS pojawia się stan niski.
Nie przechodzi natomiast test polegający na zapisaniu wartości (np.
0x55) do komórki w ramie, ponownego odczytu i porównania wartości. Jeśli
próbuję korzystać ze stosu (np. używając instrukcji CALL), program się
wysypuje.

Próbowałem już następujących rzeczy:
1. Ustawiałem różne wartości wait-state'ów dla RAM-u.
2. Tymczasowo podmieniłem kwarc na wolniejszy, obniżając zegar systemowy
z 12,5 MHz do 4 MHz.
3. Sprawdziłem na oscyloskopie stany linii w momencie zapisu do RAM-u.
Na liniach adresowych i danych stabilne stany pojawiają się przed
aktywacją /CS, a ich wartości odpowiadają temu, co chcę zapisać i gdzie.
Sygnał /WR pojawia się po /CS i znika razem z nim.
4. Sprawdziłem na oscyloskopie stany linii w momencie odczytu. Linie /CS
i /RD pojawiają się właściwie jednocześnie. Stany linii adresowych
pasują do tego, co chcę odczytać. Sytuacja z liniami danych jest
dziwniejsza - linie, które powinny być w stanie wysokim wyglądają
normalnie. Natomiast linie niskie wyglądają w momencie aktywacji CS jak
grupa równoległych przebiegów - coś jak linie w stanie wysokiej
impedancji
(https://www.speccy.pl/forum/index.php?action=dlatta
ch;topic=7902.0;attach=28900;image)
5. Myślałem, że mam do czynienia z uszkodzeniem pamięci, więc
spróbowałem innego egzemplarza. Niestety zachowuje się identycznie.
Pamięci są z dobrego źródła (TME). Na wszelki wypadek zamówiłem więcej,
jednak nie sądzę, żeby to coś mi dało.
6. Testowo spróbowałem użyć pinu MRD (sygnał generowany wewnętrznie jako
/MRD = /RD AND /MREQ).

Na chwilę obecną kończą mi się pomysły - niby mógłbym jeszcze spróbować
podmienić CPU na inny egzemplarz, ale nic nie wskazuje na jego
uszkodzenie...

Ktoś ma jakiś pomysł co do możliwej przyczyny? Czego jeszcze mógłbym
spróbować?

do góry

Ok, udało mi się ustalić jedną rzecz.
Wygląda na to, że wystąpienia problemu z zapisem/odczytem do/z RAM-u
jest uzależnione od typu użytego w projekcie flasha. Gdy korzystałem z
ST29F040 nie działało wcale, natomiast w przypadku pamięci Hyundai
HY29F040 część operacji zapis/odczyt się udaje. Powiedziałbym, że jakieś
50%. Oczywiście w takiej sytuacji nadal nie mogę korzystać ze stosu.
Jest to o tyle dziwne, że wcześniej próbowałem już obniżenia zegara
systemowego (z 12,5 MHz do 4 MHz) i dodawania wait-state'ów dla operacji
na flashu i RAM-ie.

Zresztą, nawet przy zegarze 12,4 MHz relatywnie współczesne pamięci
powinny zwalniać magistralę na czas, przed kolejną transmisją. Tymczasem
wygląda na to, że mam do czynienia z jakimś konfliktem na magistrali...

do góry

On Wed, 3 Sep 2025 09:25:01 +0200, Atlantis wrote:
> Ok, udało mi się ustalić jedną rzecz.
> Wygląda na to, że wystąpienia problemu z zapisem/odczytem do/z RAM-u
> jest uzależnione od typu użytego w projekcie flasha. Gdy korzystałem z
> ST29F040 nie działało wcale, natomiast w przypadku pamięci Hyundai
> HY29F040 część operacji zapis/odczyt się udaje. Powiedziałbym, że jakieś
> 50%. Oczywiście w takiej sytuacji nadal nie mogę korzystać ze stosu.
> Jest to o tyle dziwne, że wcześniej próbowałem już obniżenia zegara
> systemowego (z 12,5 MHz do 4 MHz) i dodawania wait-state'ów dla operacji
> na flashu i RAM-ie.
>
> Zresztą, nawet przy zegarze 12,4 MHz relatywnie współczesne pamięci
> powinny zwalniać magistralę na czas, przed kolejną transmisją. Tymczasem
> wygląda na to, że mam do czynienia z jakimś konfliktem na magistrali...

A dekoder adresów masz prawidłowy?
Może flash wysyła dane razem z RAM i wygrywa silniejszy?

J.

do góry

On 3.09.2025 11:48, J.F wrote:

> A dekoder adresów masz prawidłowy?
> Może flash wysyła dane razem z RAM i wygrywa silniejszy?

To normalnie byłoby moim głównym założeniem, ale nie tym razem. Dekoder
adresów pamięci jest jednym z peryferiów Z80182. Układ ma dwa piny:
/ROMCS i /RAMCS. Za pomocą zestawu trzech rejestrów można ustawiać
zakresy adresów: górna granica ROM, dolne granica RAM i górna granica
RAM. Jest też bit konfiguracyjny, który pozwala zupełnie wyłączyć
obsługę ROM-u. Obowiązuje zasada, że ROM (o ile jest aktywny) ma
priorytet nad RAM-em, nie ma więc możliwości, żeby obydwie linie CS były
aktywne jednocześnie.
Domyślnie, po resecie ROM zajmuje całą przestrzeń adresową. Ja
zmodyfikowałem konfigurację w ten sposób, że od 0x0000 do 0x7FFF mamy
ROM, a od 0x8000-0xFFFF RAM. I faktycznie po takim ustawieniu adresów
pojawia się aktywność na linii /RAMCS, gdy próbuję operować na adresie
powyżej 0x8000.

Bardziej zastanawiam się czy przypadkiem którejś pamięci (raczej
flashowi) uwolnienie magistrali nie zajmuje za dużo czasu po deaktywacji
linii CS i koleje urządzenie trafia na ciągle aktywne linie danych. Z
drugiej strony to tylko 12,5 MHz...

do góry

On Wed, 3 Sep 2025 14:03:11 +0200, Atlantis wrote:
> On 3.09.2025 11:48, J.F wrote:
>> A dekoder adresów masz prawidłowy?
>> Może flash wysyła dane razem z RAM i wygrywa silniejszy?
>
> To normalnie byłoby moim głównym założeniem, ale nie tym razem. Dekoder
> adresów pamięci jest jednym z peryferiów Z80182. Układ ma dwa piny:
> /ROMCS i /RAMCS. Za pomocą zestawu trzech rejestrów można ustawiać
> zakresy adresów: górna granica ROM, dolne granica RAM i górna granica
> RAM. Jest też bit konfiguracyjny, który pozwala zupełnie wyłączyć
> obsługę ROM-u. Obowiązuje zasada, że ROM (o ile jest aktywny) ma
> priorytet nad RAM-em, nie ma więc możliwości, żeby obydwie linie CS były
> aktywne jednocześnie.

Takie sprytne.
Ale tak na oko:
/CE pamięci trzeba podłączyć do (/RAMCS or /MERQ), no chyba, że RAMCS
już zawiera ten /MERQ,

/OE pamięci podłączamy do /RD
/WE pamięci podłączamy do /WR

> Bardziej zastanawiam się czy przypadkiem którejś pamięci (raczej
> flashowi) uwolnienie magistrali nie zajmuje za dużo czasu po deaktywacji
> linii CS i koleje urządzenie trafia na ciągle aktywne linie danych. Z
> drugiej strony to tylko 12,5 MHz...

A nawet 4MHz jak pisałeś.


J.

do góry

On 3.09.2025 17:58, J.F wrote:

> /CE pamięci trzeba podłączyć do (/RAMCS or /MERQ), no chyba, że RAMCS
> już zawiera ten /MERQ,

Tak. Sygnały RAMCS i ROMCS są generowane z uwzględnieniem MREQ.
Dostępne są też sygnały MRD i MWR, (RD/WR z MREQ) ale z nich nie
korzystam, bo dostępne są na multipleksowanych pinach, których
potrzebuję do alternatywnych funkcji. Na magistrali systemowej mam
standardowe RD/WR.


> /OE pamięci podłączamy do /RD
> /WE pamięci podłączamy do /WR

Tak, dokładnie w ten sposób mam to podłączone.

Chyba znalazłem przyczynę, a przynajmniej jedną z przyczyn. Okazuje się,
że miałem przerwę na linii ROMCS - najprawdopodobniej niekontaktujący
lut na przelotce. I to niekontaktujący w ten sposób, że akurat dał
prawidłowy odczyt, gdy robiłem tekst ciągłości multimetrem.

Wygląda na to, że linia ROMCS wisząc w powietrzu był interpretowana
przez flash jako stan niski, dzięki czemu program się wykonywał. Jednak
w momencie korzystania z RAM-u dochodziło do konfliktu na magistrali.

Poprawiłem to połączenie i zniknęły "brzydkie" stany z linii danych w
momencie korzystania z pamięci RAM - teraz mam już ładne, jednoznaczne
stany niskie lub wysokie.

Niemniej program korzystający z flasha nadal nie chce działać. Możliwe,
że mam jeszcze inny problem. Mam tylko nadzieję, że nie uszkodziłem
pamięci...

do góry

On 3.09.2025 18:31, Atlantis wrote:

> Niemniej program korzystający z flasha nadal nie chce działać. Możliwe,
> że mam jeszcze inny problem. Mam tylko nadzieję, że nie uszkodziłem
> pamięci...

Ok, problem ze stosem okazał się mieć banalne podłoże - dałem include w
złym miejscu w stosunku do dyrektywy ORG, przez co funkcja do której
robiłem CALL z osobnego pliku znajdowała się pod adresem niemającym sensu.

do góry