forum speccy.pl
Komputery z Z80 => AMSTRAD => Wątek zaczęty przez: ZbyniuR w 2016.02.21, 19:05:38
-
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. :)
-
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
-
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.
-
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
-
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ć.
-
Spoko to nasza zabawa w wolnym czasie. Kuriozalne jest już to, że odpowiedz dostałeś po ponad 5 latach ;D
A oto gotowiec ... :D :P 8) :o
OS6128mod.ROM
AMSDOSmod3.ROM
do wypełnienia jest tabelka userKeys w AMSDOSmod3.ROM od adresu &1C00 (w pamięci CPC &DC00)
pod adresem &1C86 (&DC86) trzeba wpisać długość tabelki w bajtach.
skorzystałem z funkcji bios
&B90F ustawianie romu (w C podajemy nr AMSDOSA 7, a w B dostajemy ustawienie poprzedniego stanu ), i
&B90C powrót do poprzedniego stanu (w A podajemy poprzedni stan)
-
ŁAŁ - Szacun i dzięki. :)
Muszę poszukać gdzie miałem ten Basic który mi modyfikował te klawisze co chciałem.
Chodziło mi o ułatwienia przy edycji Basica i przy uruchamianiu programów.
Np klawisz TAB przy edycji Basica do niczego sie nie przydaje, a jeśli ktoś grzebie w listingu to często przerywa program listuje go i uruchamia na nowo, dlatego wygodnie jest mieć pod Tab słówko run z enterem (ale bez cudzysa jak jest na enter), Tab+shift to mode 2:list a Tab+Shift to cat
A do uruchamiania plików ze stacji np run"disc albo |cpm co byłoby odpowiednikiem run" który sie sprawdza ale tylko w magnecie. Albo jeszcze fajniej po wpisaniu cat przydałyby sie klawisze z funkcjami do przeskakiwania kursorem do następnej kolumny na widocznej liście plików, oraz klawisz z funkcją która jeśli umieścimy kursor na początku nazwy pliku i go wciśniemy to skopiuje nam nazwę tego pliku i go uruchomi.
Musiałbym znaleźć czas i natchnienie i to potestować.
A z tej kilobajtowej dziury zostało 133 bajty, rozumiem że opis modyfikacji ma zostać. Normalnie CPC pozwala by wszystkie zmodyfikowane funkcje razem nie zajmowały więcej niż 255 znaków, łącznie z tymi bajtami które wskazują długość poszczególnych funkcji. A czy te FF-y formatują, nie sądzę bo puste sektory są wypełniane znaczkiem liścia czyli 229 (&E5). :)
Ech gdyby tak jeszcze dało sie dorobić obrazek powitalny, trzymany w dodatkowym 16K bloczku ROM. W emulcu taki obrazek byłby łatwy do dodania, ale w realnym CPC byłoby to dostępne tylko dla posiadaczy ROM-boxa. I mogłyby powstawać fanowskie obrazki startowe jak do FutureOS-a. :)
-
Na wszystkie UserKeys mamy razem 133 bajty tak wygląda w RAM ta tablica. Pozostałe 19 bajtów są zerowe. razem 152 bajty i koniec, ściana. Basic nie pozwala zapełnić nawet tych 19 bajtów.
key 0,space$(105)
Improper argument
key 0,space$(104)
Ready
chodzi mi po głowie wyprowadzenie tej tablicy poza b590. sprawdze czy to działa.
W Amsdosie zostało około 1024-133-1=890 bajtów. 890/8=111 znaków mod2 = 55 mod1 =grafika 5x10 znaków, może troche mniej bo kod kopiujący trzeba tu wcisnąć
-
Ok mój błąd chyba tylko raz doszedłem do granic tej tablicy jak robiłem klawisze jak w Spectrum by całe Basicowe słówka wyświetlał jednym kliknięciem i starczyło mi na po słówku dla każdego z 26 liter. Robiłem też kiedyś arabską klawiaturę aby znaki pisały sie od prawej do lewej, to do każdej z 22 liter funkcja dodawała dwie strzałki, ale to było nawet mniej.
Teraz widzę że wszystkie funkcje razem (bez bajtów długości) mogą mieć max 120 bajtów.
Ale spoko to też jest sporo miejsca do popisu. :)
A gdyby chcieć to zwiększać to wpierw trzeba by modyfikować procedury które obsługują te funkcje a potem szukać dla nich miejsca w RAM. Owszem są takie miejsca, (z tych poniżej pamięci obrazu), ale niektóre programy robią z nich użytek, bo to obszary które sie nie kasują przy resecie. Raczej nie ma potrzeby.
-
Sprawdziłem.
&b62b,L_adr
&b62c,H_adr
adres tablicy do tych komórek. i mamy 255 znaków na każdy UserKey.
zaniedbujemy komórki adresu bajtu po tabeli. ( b62d(e), b62f(30) )
co prawda Basic może taką tablice używać, ale ograniczenie na 104 znaki nadal istnieje dla komendy key.
ps. jeżeli w b62d(e) wpiszemy adres bajtu po tabeli [maks.możliwy zakres] a w b62f(30) adres bajtu po dotychczasowym użyciu. ...
TO DZIAŁA KEY 0,space$(255) !!!!!!!!!!!!!!!!!!!!!! niema ograniczenia na długość stringu!
-
Jeśli po resecie wpiszesz
for a=0 to 31:key a,"":next
To możesz potem wpisać jedną funkcję o długości 120 bajtów.
Bo standardowo ma ustawione 11ie 1-bajtowych funkcji i jedną 5bajtową, to zostaje 104.
Pewnie jest taki poke który pozwala ustawić więcej funkcji niż 32.
Jest też gdzieś tabelka jak ma reagować na znaki kontrolne, (bodajże po 3 bajty z adresem do procedury w ROM), ale nie pamiętam czy tylko na te co już istnieją czy jest dla wszystkich kodów od 0 do 255.
EDIT:
Jest taka tabelka (w 6128 od &B763), ale tylko do kodów od 0 do 31, czyli tych jak się mają wyświetlać w PRINT, 1 bajt to ile bajtów parametrów potrzebuje, i 2 bajty adres.
A mnie by tu bardziej interesowało jak reaguje na kody kontrolne przypisane do klawiszy takie jak 127-159, 224-225 i 240-255. Bo wśród nich są funkcyjne 128-159). Ale to już nie wiem jak.
-
:o
Grafika ma 800 bajtów. 10x5 znaków Mode1.
zaczyna się w AMSDOSIE od &DCE0. Od DC90 zaczyna się procedura kopiująca.
na dyskietce kod wspomagający wykonanie takiego zdjęcia w pamięci.
wżarliśmy się do LowROM w &66D. wyżarty kod powtarzamy w ramie od &A000 wraz z odtworzeniem stanu ustawień ROMu.
kod procedur zdjęciujących, można używać dla większych obrazków, procedura dość uniwersalna wyszła.
org #9200
;z pamieci na ekran
ld de,&4000 ;src
;call &9203,src
ld hl,#c000 ;trg
ld c,0
ld b,8
nextL2:
push bc
ld b,5 ;Y bajtow
push hl
nextL:30
push bc
ld bc,20 ;X bajtow
push hl
ex de,hl
ldir
ex de,hl
pop hl
ld c,80
add hl,bc
pop bc
djnz nextL
pop hl
ld bc,2048
add hl,bc
pop bc
djnz nextL2
ret
;z ekranu do pamieci
org #9230
ld de,#4000;trg
;call &9233,trg
ld hl,#c000;src;
ld c,0
ld b,8
nextS2:
push bc
ld b,5 ;Y bajtow
push hl
nextS:
push bc
ld bc,20 ;X bajtow
push hl
ldir
pop hl
ld c,80
add hl,bc
pop bc
djnz nextS
pop hl
ld bc,2048
add hl,bc
pop bc
djnz nextS2
ret
-
są skróty jak na obrazku DEMO.
AMSDOSmod5.ROM i OS6128mod5.rom
Zmodyfikowana tablica przyporządkowania ASCII do klawiszy w OS6128LowROM. od &1EEF, którą potem Amstrad skopiuje do &B496
ДДДДДДЕДДДДДДДЕДДДДДДЕДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД
&B496 і &B34C і &50 і Normal Key Table:
і і і Cur U Cur R Cur D f9 f6 f3 Enter f.
і і і Cur L Copy f7 f8 f5 f1 f2 f0
і і і Clr [ Ret ] f4 \
і і і ^ - @ p ; : / .
і і і 0 9 o i l k m j
і і і 8 7 u y h j n Space
і і і 6 5 r t g f b v
і і і 4 3 e w s d c x
і і і 1 2 Esc q Tab a Caps z
і і і [VT] [LF] [BS] [TAB] Fire2 Fire1 Del
ДДДДДДЕДДДДДДДЕДДДДДДЕДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД
&B4E6 і &B39C і &50 і Shifted Key Table:
і і і Cur U Cur R Cur D f9 f6 f3 Enter f.
і і і Cur L Copy f7 f8 f5 f1 f2 f0
і і і Clr { Ret } f4 `
і і і њ = | P + * ? >
і і і _ ) O I L K M <
і і і ( ' U Y H J N Space
і і і & % R T G F B V
і і і $ # E W S D C X
і і і ! " Esc Q -> A Caps Z
і і і [VT] [LF] [BS] [TAB] Fire2 Fire1 Del
ДДДДДДЕДДДДДДДЕДДДДДДЕДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД
&B536 і &B3EC і &50 і Control Key Table:
і і і Cur U Cur R Cur D f9 f6 f3 Enter f.
і і і Cur L Copy f7 f8 f5 f1 f2 f0
і і і Clr (ESC) Ret (GS) f4 (FS)
і і і (RS) (NUL) (DLE)
і і і (US) (SI) (HT) (FF) (VT) (CR)
і і і (NAK) (EM) (BS) (LF) (SO)
і і і (DC2) (DC4) (BEL) (ACK) (STX) (SYN)
і і і (ENQ) (ETB) (DC3) (EOT) (ETX) (CAN)
і і і ~ Esc (DC1) Ins (SOH) S-lck (SUB)
і і і Del
ДДДДДДЕДДДДДДДЕДДДДДДЕДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД
Procedura obrazka rozszerzona o dekompresor RLE (zamiast 800 bajtów obrazek ma 290)
org #66D
;podmianka w OS6128 LowROM od &066D
ld c,#07
call #b90f ;Wlaczenie ROMu AMSDOS
push bc
jp #dc90 skok do ROMu.
org #dc90
;############### RLE dekompresor #################
;format
;[1-127*][DN]...[128+(1-127*)][DN1][DN2]....[DNx]...[0]
ld hl,#dd00 ;adres skopresowanego obrazka w mod. ROM.
ld de,#4000 ; miejsce rozpakowania w RAM
NextD:
ld a,(hl)
cp 0
jr z,na_ekran
ld c,a
inc hl
bit 7,c
jp z,rle
res 7,c
ld b,0
ldir
jr nextD
rle:
ld b,c
ld a,(hl)
p1:
ld (de),A
inc de
djnz p1
inc hl
jr nextD
na_ekran:
;-------------------
ld hl,49152+1440+59 ;trg 18*80=1440
ld de,&4000 ;src
ld bc,#0500 ;Y -wysokosc w wierszach znakowych
nextL2:
push bc
ld b,8
push hl
nextL:
push bc
ld bc,20 ;X=10*2 -szerokosc w bajtach
push hl
ex de,hl
ldir
ex de,hl
pop hl
ld b,8 ;2048
add hl,bc
pop bc
djnz nextL
pop hl
ld c,80
add hl,bc
pop bc
djnz nextL2
ld c,18
ld hl,koniec
ld de,#a000
ldir ;kopiowanie procedury 'koniec' do pamięci RAM pod &A000
jp #a000 ;skok do procedury koniec w RAM
koniec: ;po skopiowaniu procedura znajduje sie w RAMie od &A000
pop bc ;ustawienie powrotne romu wracamy.
ld a,b
call #b90c
ei ;procedura wywalona z LowROM teraz funkcjonalnie odtwarzana.
pop HL
call #001E ;standardowe napisy CPC
pop bc
pop hl
jp #0077
-
No i zupełnie inne podejście wszystko w dodatkowym ROMIE. BEZ MODYFIKACJI wbudowanych ROMów.
pierwszy bajt ROMu w &c000 równy 1 aktywuje go jako background. Potem następuje skok do do &c006 i tu można zacząć dowolną własną procedurę.
tablica Userkeys wraz z ustawieniami systemu od &B590-B630 należy skopiować do &DC00-DCA0
tablica ASCII map Keys od &B496-B585 należy skopiować do &FF10-FFFF
obrazek skompresowany RLE od adresu &DD20
-
Wiem gdzie w ROMie jest mapa klawiatury, od dawna używam zmodyfikowanej mapy i fonta w emulatorze.
Co do funkcji na klawiszach myślałem np o czymś takim:
KEY 140,STRING$(8,CHR$(224))+CHR$(250)+"run"+CHR$(34)+CHR$(13)
Teraz tylko po cat najeżdżasz kursorem na 1szy znak nazwy pliku i wciskasz ctrl+enter a plik sie uruchamia.
To jest dla stacji tym czym run" jest dla taśmy. Choć może lepiej byłoby przypisać to na shift+enter (można by to jednym palcem włączać), a ten oryginalny taśmowy run" zostawić. Do kompletu na ctrl ze strzałkami <- i -> dodać kody które przeskakują kursorem o całą kolumnę na wyświetlanym katalogu, co by łatwiej trafić w pierwszy znak nazwy pliku w sąsiednich kolumnach. :)
Nie czaję na czym polega ta kompresja obrazka. Jaki duży może być ten obrazek w osobnym ROMie, jaką metodą go skompresować i jak wyświetlić?
-
KEY 140,STRING$(8,CHR$(224))+CHR$(250)+"run"+CHR$(34)+CHR$(13)
Teraz tylko po cat najeżdżasz kursorem na 1szy znak nazwy pliku i wciskasz ctrl+enter a plik sie uruchamia.
mam to zrobione tyle, że tylko dla pierwszej kolumny bo dałem 250 również na początku żeby nie trzeba było ustawiać pierwszego znaku. ... i chyba to nie działa.
Do kompletu na ctrl ze strzałkami <- i -> dodać kody które przeskakują kursorem o całą kolumnę na wyświetlanym katalogu, co by łatwiej trafić w pierwszy znak nazwy pliku w sąsiednich kolumnach. :)
mam skrupuły ;) zastępować ctrl+ArrowLeft może większe mniejsze to powinno być? ctrl+Arrow wraca do początku linii tak włączałem BASy. Copy potem CTRL ArrowLeft ENTER
Nie czaję na czym polega ta kompresja obrazka. Jaki duży może być ten obrazek w osobnym ROMie, jaką metodą go skompresować i jak wyświetlić?
jest to metoda RLE
[1-127*][DN]...[128+(1-127*)][DN1][DN2]....[DNx]...[0]
bajty identyczne są pogrupowane w dwubajtowe pary NxBajt czyli krotność takiego samego bajtu, w porywach 127 bajtów tła zapisze się jako 127, 0
drugi rodzaj grup to bajty które nie daja sie skompresować pierwszy bajt podaje ile jest takich bajtów 1-127 i ma ustawiony bit 7 potem następuje sekwencja tych bajtów. Bajt sterujący o wartości 0 kończy obrazek.
Kompresja jest wydajna o ile mamy znaczną część ciągów bajtów identycznych. puste 16Kb ekranu to 259 bajtów :)
przygotowuje jakiś util do tego. niemam jeszcze dorobione żeby ta procedura w ROMie sama czytała rozdzielczość tego obrazka. narazie tam jest na sztywno miejsce na ekranie i wielkość 10x5 znaków mode 1. Jeżeli zostajemy w romie dodatkowym i nie kisimy sie w tym jednym kilo AMSDOSa to obrazków pełnoekranowych zmieścimy tam kilka. Nawet animacje można zrobić.
Załączam pierwsze wersje tego Utilu. jest w basicu z procedurą maszynową.
Kolejne procedury S2O, O2K, K2O, O2S gdzie S to screen, O to Obrazek rozkompresowany, K obrazek skompresowany.
Obrazek rozkompresowany jest zapisany linia po linii, inaczej niż w pierwszych wersjach w tym wątku.
;z pamieci na ekran
org #9200
;call&9200,&AdresOnScreen,@tablica_nieskompresowana
ld h,(IX+3)
ld l,(IX+2)
;ld de, ;src
;ld hl, ;trg
ld c,0
ld b,5 ;Y bajtow
nextL2:
push bc
ld b,8
push hl
nextL:
push bc
ld bc,20 ;X bajtow
push hl
ex de,hl
ldir
ex de,hl
pop hl
ld bc,2048
add hl,bc
pop bc
djnz nextL
pop hl
ld c,80
add hl,bc
pop bc
djnz nextL2
ret
;z ekranu do pamieci
org #9230
;call&9230,@tablica_nieskompresowana,&AdresOnScreen
ld h,(IX+3)
ld l,(IX+2)
ex de,hl
;ld de,#4000;trg
;ld hl,#c000;src;
ld bc,#0500 ;Y bajtow
nextS2:
push bc
ld b,8
push hl
nextS:
push bc
ld bc,20 ;X bajtow
push hl
ldir
pop hl
ld bc,2048
add hl,bc
pop bc
djnz nextS
pop hl
ld c,80
add hl,bc
pop bc
djnz nextS2
ret
;############### RLE dekompresor #################
org #9260
;call&9260,@tablica_nieskompresowana, @tablica_kompresji
ld h,(IX+3)
ld l,(IX+2)
;ld hl,kompres ;
;ld de,dekompres ;
ex de,hl
NextD:
ld a,(hl)
add 0
ret z
ld c,a
inc hl
bit 7,c
jp z,rle
res 7,c
ld b,0
ldir
jr nextD
rle:
ld b,c
ld a,(hl)
p1:
ld (de),A
inc de
djnz p1
inc hl
jr nextD
;################### RLE kompresor ###############
org #9290
;call&9290,@tablica_kompresji, @source, wielkosc_obrazka,@wielkosc_po_kompresji
di
ld iY,0
add iY,SP
ld SP,IX
pop bc
pop IX
pop HL
pop de
ld sp,iy
ei
push bc ;adres w 4 parametrze
push de ;adres w 1 parametrze tabl_kompr
;ld hl, ;obrazek linia po linii
;ld de, ;obrazek skompresowany
ld bc,#ffff ; -1
push bc
;ld ix, ;wielkosc obrazka-1
dec ix
start:
EX (SP), HL ;|
ex de,hl ;|
inc ix ;|
add ix,de ;|-- takie jazdy z dekrementacja licznika
ex de,hl ;| w rejestrze, ktory nie obsluguje flag
EX (SP), HL ;| nie mozna od niego odejmowac,
jr c,not_end ;| nie mozna dodawac rejestru HL
xor a
ld (DE),A
inc de
pop bc ; -1
ex hl,de ;
pop de ;adr tablicy_kompr
cp a
sbc hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
ret
not_end:
ld B,0
LD A,(HL)
tesame:
inc b
bit 7,b
jr nz,end127
;+++++++++++++++++++++++++
EX (SP), HL
ex de,hl
add IX,de
ex de,hl
EX (SP), HL
jr nc,end_tsame
inc hl
ld c,(hl)
cp c
jr z,tesame
jr end_tsame
end127:
dec b
end_tsame:
;push bc ; b -licznik , c -ostatnia dana
dec b
jr z,licz_rozne
inc b
push AF
ld a,b
ld (de),A
inc de
pop af
ld (de),A
inc de
jr start
;***********************************************
licz_rozne:
ld b,1
push de
pop iY
inc de
ld (de),A
p2:
bit 7,b
jr nz,end_rozne
inc b
ld A,c
inc de
ld (de),A
;+++++++++++++++++++++++++++++++
EX (SP), HL
ex de,hl
add IX,de
ex de,hl
EX (SP), HL
jr nc,set_rozne
inc hl
ld c,(HL)
cp c
jr nz,p2
jr set_rozne
end_rozne:
dec b
;jr z,start
set_rozne:
set 7,b
ld (iY+0),b
ld a,c
inc de
jr start
ret
-
Kod 250 w edytorze Basica nie cofa do lewego marginesu, tylko do początku linii którą wpisujesz. Możesz przesunąć kursor daleko od marginesu i jak tam wpiszesz pierwszy znaczek (lub skopiujesz go drugim kursorem) to tam będzie początek linii do którego cofnie jak użyjesz tego kodu. Dzięki temu ten trik kopiujący nazwę pliku i run działa także w innych kolumnach. :)
Co do tych kodów przesuwających kursor o kolumnę STRING$(20,243) to miałem przed laty takie ustawienie w programiku startowym, i choć też sie lekko niepokoiłem że trafię na program w którym to przeszkadza, ale nie przypominam sobie. Wciąż zostają kody na ctrl + góra lub dół co przeskakuje na początek i koniec edytowanej linii Basica (nawet jak jest dłuższa niż szerokość ekranu). A w Basicu taka super tabulacja ze skokiem o 20 znaków jest nawet bardziej użyteczna. W porządnych edytorach tekstu i tak przywracał domyślne.
Hmm no właśnie bo jak tak będzie w ROMie a przy tym jakiś edytor tekstu zmieni funkcje to może być niefajnie. Trzeba by to przetestować. Ale dobrze kombinujesz z tymi <> bo tam z ctrl nic nie ma. Choć w emulatorach jeśli klawisz z \ masz przy lewym shift a nie prawym to emulator go wogóle nie widzi, więc wstawiłem kody z niego (`\) pod te <>. Więc jeśli sie okaże że jakiś popularny edytor tekstu z takimi ustawieniami głupieje to lepiej będzie je wstawić na <>.
Co do kompresji czytałem o tego typu metodzie. W Bajtku 11/91 s10 są procedury w kodzie do wyświetlania skompresowanych obrazków z ArtStudio, i kompresowania ich jako CSI (to te co się wyświetlają po CALL &6000), w tym i kod do dekompresji ich który jest zawarty w samym obrazku.
Jakieś procedurki w kodzie do kompresji i dekompr są też w IKS 2/89 s15 ale nie obsługują palety.
Miałem kupę obrazków w CSI, zwykle zajmowały tyle samo KB co te z ArtStudia (tyle że nie potrzebowały osobnego pliku z paletą) a czasem CSI zajmowały o 1K mniej. I mało który obrazek był na tyle prosty by w kompresji tracić więcej niż 30% objętości. Czasem wystarczyło usunąć parę zbędnych pikseli na pustawych obszarach to dochodziło do 50%. Mniej zajmowały tylko obrazki z masą pustego miejsca na ekranie lub z masą samych poziomych linii. Dlatego wątpię by w 16K zmieściły sie więcej niż 2 ładne obrazki. Z resztą jak sie zmieści 1 to już by było super. :)
Mam te listingi wklepane. A te do pokazywania ArtStudia są w moim programiku startowym na DSK które parę razy wstawiałem na forum.
Jestem pod wrażeniem jaki jesteś oblatany w Amstradowych sprawach. :)
-
Nie tylko McArti0 pracuje nad obrazkiem startowym. :)
Tylko nie wiem czemu go w MODE 0 zrobił bo kolorowy nie jest.