Autor Wątek: Emulacja a instrukcje systemowe  (Przeczytany 5621 razy)

Frodo

  • *
  • Wiadomości: 18
Emulacja a instrukcje systemowe
« dnia: 2015.12.28, 19:41:53 »
Mam już zrobioną emulację 179 z 200 instrukcji. Brakujące 21 to systemowe. Na przykład in/out - jakie adresy są w użyciu? tylko jednobajtowe? $FE? czy inne? halt czeka aż do następnej ramki? Jaki sens instrukcji in f,(c) ?
Załączam bieżącą wersję, już niewiele zostało, aby przeczytać ROM
Tu mam plik z tymi, które zostały:
org $8000
  halt
  im 0
  im 1
  im 2
  in a,($fe)
  in b,(c)
  db $ed, $70 ; in f,(c)
  ind
  indr
  ini
  inir
  out ($55),a
  db $ed, $41 ; out (c),b
  db $ed, $71 ; out (c),0
  outd
  otdr
  outi
  otir
  reti
  retn
  rst $18
ret

Jaki sposób testowania, gdy po wczytaniu ROMu pójdzie w krzaki? myślę że zrobię assert false gdy PC opuści ROM, lub zechce coś do niego wpisać.
Jeszcze pytania: jaki stan rejestrów (w tym PC i SP) po restarcie? same zera? Co to za rejestry I oraz R?
« Ostatnia zmiana: 2015.12.28, 20:17:20 wysłana przez Frodo »

matofesi

  • *****
  • Wiadomości: 2049
  • Miejsce pobytu:
    Toruń/Poland
Odp: Emulacja a instrukcje systemowe
« Odpowiedź #1 dnia: 2015.12.29, 08:24:40 »
Na przykład in/out - jakie adresy są w użyciu? tylko jednobajtowe? $FE? czy inne?

A to niby dlaczego? Jako adres portu może być użyty dowolny adres szesnastobitowy. W wypadku Spectrum ULA przechwytuje wszystkie odwołania do adresów parzystych, ale na dowolnych nieparzystych można z zewnątrz podłączać różne urządzenia.

Cytuj
halt czeka aż do następnej ramki?

Ja wiem, że manual jest długi i nudny, ale może jednak warto do niego zajrzeć...

HALT czeka na przerwanie - niemaskowalne lub (o ile są włączone) na maskowalne. W wypadku Spectrum niemaskowalne może przyjść z zewnątrz po zwarciu /NMI do masy a maskowalne jest generowane przez ULA co ramkę.

Cytuj
Jaki sens instrukcji in f,(c) ?

Żaden. Dlatego w manualu jest komentarz "Undefined op code". Instrukcja o ile pamiętam działa, ale tylko i wyłącznie dlatego, że wewnętrzna struktura procesora jest wprost "symetryczna" i wykonuje nawet takie bezsensowne konstrukcje.

Cytuj
Jaki sposób testowania, gdy po wczytaniu ROMu pójdzie w krzaki?

Co to znaczy "pójdzie w krzaki"? Że kod będzie próbował wyskoczyć poza ROM? A co w tym niezwykłego? Na starcie pewne drobne rzeczy są przenoszone do RAMu i może się zdarzyć tak, że w specyficznej sytuacji (oczywiście poza wywołaniem funkcji USR z BASICa) kod wyskoczy poza ROM.

Cytuj
myślę że zrobię assert false gdy PC opuści ROM,

To na początek może zadziałać...

Cytuj
lub zechce coś do niego wpisać.

...a to niekoniecznie, bo o ile pamiętam są ze dwa albo trzy miejsca w ROMie w których zakłada się, że ROM jest read-only i pisze nie sprawdzając jaki jest adres. A to powoduje, że np. przeniesienie kodu ROMu do RAMu wymaga poprawek a twój assert wyleci na poprawnym kodzie.

Cytuj
Jeszcze pytania: jaki stan rejestrów (w tym PC i SP) po restarcie? same zera?

I znowu... manual... Uruchomienie procesora wywołuje wewnętrznie procedurę restartu tak samo jak podanie stanu niskiego na /RESET. A restart zeruje oba znaczniki przerwań, PC, I i R i ustawia tryb obsługi przerwań na IM 0.

Cytuj
Co to za rejestry I oraz R?

Really????

I to "Interrupt Page Address" - rejestr, który jest górną połową adresu wektora obsługi przerwań w trybie IM 2.
R to "Memory Refresh Register" - siedem dolnych bitów to zwiększany automatycznie po każdym M1 licznik, który w cyklu odświeżania pamięci jest wystawiany jako dolna połówka na szynę adresową (na górną połówkę wystawiane jest I).

Wiem, że to pewnie nudne, ale to wszystko masz opisane w manualu.