Komputery z Z80 > AMSTRAD

Modyfikacja ROM-u w CPC

(1/4) > >>

ZbyniuR:
   Przydałby mi się spec od Asemblera Z80 by rozpracować kawałek kodu w ROMie Amstrada.
Chciałbym zmodyfikować OS6128.rom  a konkretnie zmienić znaczenie klawiszy funkcyjnych. I tu nieco wprowadzenia dla tych co nie są Amstradowcami. W CPC można modyfikować mapę klawiatury za pomocą POKE, 80 klawiszy i 3 ich znaczenia w sumie ta mapka ma 240 bajtów i w identycznej postaci jest ROMie jakby ktoś chciał to zmienić trwalej pod Emulatorem. Bułka z masłem i nie z tym mam problem.
   Jednak kody od 128 do 156 przypisane pod jakiś klawisz nie powodują po wciśnięciu pojawienia się tych znaków na ekranie, tylko zamiast nich wyświetla się tzw funkcja, czyli po prostu ciąg znaków przypisanych do tego kodu. Domyślnie po resecie 13 z tych 32 kodów jest zdefiniowana jako 10 cyfr od 0 do 9, (czyli w tym przypadku ciąg znaków ma po 1 bajcie długości). następne 2 to kropka i kod 13 [cr] czyli Enter, oraz jedyny dłuższy ciąg ułatwiający uruchamianie plików czyli  RUN" +[cr]. Pozostałe ciągi są puste.
   W pamięci RAM te ciągi są zapisane dość przejrzyście co widać na obrazku pierwszym od adresu &B590, czyli 1 bajt określa długość ciągu po czym następuje ten ciąg znaków, a potem kolejny bajt z długością następnego ciągu. Jeśli ciąg jest pusty to mamy tylko 1 bajt &00 i od razu kolejny kod.  Łatwo to zmienić komendą Basica albo POKE-ami, ale niestety w ROM-ie jest to zapisane w jakiś czarodziejski sposób...
   Jedyne miejsce w ROM gdzie jest wspomniany ten adres &B590 pod którym te ciągi są w RAM, jest na obrazku pod &5B9F, (wczytałem ten 16K ROM do ramu pod &4000), kilkanaście linijek niżej widać 3 ostatnie z tych 13 zdefiniowanych ciągów, w identycznej postaci jak są w RAM czyli bajt długości i ciąg, poznajemy to po słówku RUN który to ciąg kończy się pod &5C45.
   A pomiędzy jest ok 200 bajtów kodu w których przypuszczam że definiuje kody od 128 do 137 jako cyfry (0-9) po czym bierze ostatnie 3 definicje podane jak wspomniałem i przerzuca to do RAMu w chwili resetu. Możliwe że robi to za pomocą procedur z drugiego ROMu z Basiciem albo że nazywa te kody zamiast (128-137) to (0-9) bo Basic uznaje oba sposoby.
   Idealnie by było gdyby tej pętli z cyframi nie było, a wszystkie ciągi były robione tak jak te 3 ostatnie i przechowywane w ROM w identycznej formie jak w RAM, albo przerzucał to do RAM LDIR-em a nie jakimiś odwołaniami do procedur.
   Gdyby ten obszar był z 10 razy mniejszy to bym się przemęczył z tabelką z rozkazami i sam próbował to rozgryźć ale póki co liczę że znajdzie się ktoś chętny do pomocy i bystry. :)

McArti0:
org #1b98
call #1e75
call #1bf8
ld de,#b590 <------ &b590
ld hl,#0098
call #1c0a

org #1c0a
di
ld a,l   ;<----- A=l=&98
sub #31      A=&98-&31=&67 CY=0
ld a,h      A=H=0
sbc #00      A=0-0-CY=0  CY=0
ret c      return jezeli CY=1 czyli nie
add hl,de    &0098+&b590=&b628
ld (#b62d),hl   poke &b62d,&28 : poke &b62e,&b6
ex de,hl   de=&b628 , hl=&b590
ld (#b62b),hl   poke &b62b,&90 : poke &b62c,&b5

.L_1C1A        ;#####<-powiedzmy ze odtad mozna zmieniac kod na swoj
ld bc,#0a30
;******************************************
      hl=&b590: C=&30=48
.L_1c1d      For b=&A to 1 step -1
ld (hl),#01      poke hl,1
inc hl      hl=hl+1
ld (hl),c   poke hl,C
inc hl      hl=hl+1
inc c      C=C+1
djnz L_1c1d   next
;*************************kod ma 11 bajtow, tworzy 20b tablice
ex de,hl
ld hl,L_1c3c   ;   <dane
ld c,#0a
ldir        ; kopia 10 bajtow z DANE do

ex de,hl
ld b,#13

xor a   A=0

.L_1c31      ; KASOWANIE reszty obszaru RAM 19 bajtow
ld (hl),a
inc hl
djnz L_1c31

          ; zapamietanie w systemie konca bloku ustawien klawiszy
ld (#b62f),hl  poke &b62f,l : poke &b630,h <- hl=&b5c2
ld (#b629),a   poke &b629,0
ret      ;<powrot

.L_1c3c      ;<dane
db #01
db  #2e
db #01
db  #0d   
db #05
db  #52,#55,#4e,#22 ;RUN"
db  #0d        ; enter

^L_1C45    ostatni adres tego bloku programu
           od 1C1A-1C45 (44 bajty) mozna zmienic na swoja proc.
           z obostrzeniami wypelnienia zmiennych systemowych

McArti0:

Za mapą firmwaru:
CPC6128    CPC464   bajty
&B590       &B446     &98 DEF KEY's definition area (for Keys &80 to &9F in sequence):
                                      each definition has either a single byte of &00 if it is unused/unaltered,
                                      or: byte 1: length of definition bytes 2 to x: definition,
                                      either a single key or a string of keys

&B628       &B4DE       1 Byte after end of DEF KEY area
&B629       &B4DF       1                                           <-0
&B62A       &B4E0       1                 
&B62B(C)    &B4E1       2 address of DEF KEY area                   <-&b590
&B62D(E)    &B4E3       2 address of byte after end of DEF KEY area <-&b628
&B62F       &B4E5       1                                           <-&b5(c2) <-adres bajtu po użytym obszarze Key Def Tab
&B630       &B4E6       1                                           <-&(b5)c2 

ROM wypełnia te bajty troche inaczej niż to opisane, używa komórek nie opisanych.

McArti0:
W Romie AMSDOSa od adresu DC00 do DFFF jest "chyba niepotrzebna dziura" o wartościach &FF, bite 1024 bajty. Mam nadzieje, że nie służy to do kasowania sektorów czy czegoś podobnego.  :D

ZbyniuR:
Widzę że się napracowałeś tylko że ja mam ostatnio ważniejsze problemy na głowie i nie mam czasu by nad tym pomyśleć.

Nawigacja

[0] Indeks wiadomości

[#] Następna strona

Idź do wersji pełnej