zestawu znakow w linii zmienic nie mozna, obowiazuje tylko jedna zmiana na linie
w pierwszej linii wiersza trybu znakowego mozna dokonac max 4-5 zmian, wiekszosc czasu zabiera antic ktory dekoduje wiersz ze znakami
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł Jer Odszedł nasz kolega, encyklopedia wiedzy na temat elektroniki.
20. odcinek kursu programowania u Larka Larek wraca z okrągłą, dwudziestą częścią swojego popularnego kursu pisania gier na Atari.
ELITE Atari 8-bit! Dostępne demo portu gry ELITE (wersja dyskowa z BBC Micro) na komputery Atari XL/XE.
BBC BASIC dla Atari XL/XE BBC BASIC w wersji 3.10 dostępny na Atari XL/XE! Port stworzył Ivo van Poorten.
Altirra 4.40-test23 Kolejna testowa wersja Altirry przynosi poprawki w emulacji VBXE i usprawnienia w zarządzaniu firmware.
atari.area forum » Posty przez tebe
zestawu znakow w linii zmienic nie mozna, obowiazuje tylko jedna zmiana na linie
w pierwszej linii wiersza trybu znakowego mozna dokonac max 4-5 zmian, wiekszosc czasu zabiera antic ktory dekoduje wiersz ze znakami
osobiscie jestem za jednym taskiem (procesem), gdzie cala moc CPU przydzielana jest wlasnie temu jednemu procesowi
wyobrazcie sobie obsluge myszki w multi-taskingu, przy kilku procesach, opoznienia wplyna na plynnosc ruchow myszki ktora jest zalezna wlasnie od czestotliwosci odczytywanie jej koordynat
najlepiej gdyby bylo sprzetowe wsparcie mychy, inaczej najlepszym manipulatorem staje sie JOY odswiezany na VBL'u
WSYNC jest po to aby zatrzymac CPU az do zakonczenia tworzenia linii przez ANTIC, dzieki temu nie widac "poszarpanych" zmian kolorow, jesli chcesz zrezygnowac z WSYNC to musisza synchronizowac sie z rastrem, tak jak ma to miejsce w G2F dla GED+ i GED--, wtedy bedziesz mial kontrole nad miejscem w ktorym wystapi zmiana
wlacz G2F, tryb GED-- lub GED+ przejdz ALT+R (Edit Rasters) i ogladaj miejsca w ktorych mozna dokonac zmian :)
oczywiscie na C64 istnieje juz taki psudo-multitaskowy system (do 30 procesow) zwie sie Lunix
ciekawe jak oni sie do tego zabierali ze zdolali cos zrobic :)
z ta emulacja Konop ma racje, moze zbyt doslownie go zrozumieliscie, piszac aplikacje nalezaloby zrezygnowac ze wszystkich rozkazow odwolujacych sie do stosu i strony zerowej, przerwania wylaczone koniecznie
czysto teoretycznie wygladaloby to tak: wywolujemy task, jako parametry podajemy mu nowy adres stosu i strony zerowej, odpowiednie procedury modyfikuja procedury emulujace stos i strone zerowa, task rusza
wlasciwie ze strony zerowej moglibysmy zrezygnowac i emulowac tylko stos, MADS udostepnia stos programowy (malej poprawki dotyczyloby tylko wywolanie procedury w MADS), np.
; wywolanie procedury w MADS po nazwie procedury
nazwa_procki
; MADS wymusza:
;
; JSR NAZWA_PROCKI
;
; a wiec juz korzystamy ze stosu sprzetowego $0100-$01FF
; teraz wystarczy poprawic MADS tak aby wykonywal tutaj makro,
; ktorego parametrem bedzie nazwa procedury (a wiec jej adres),
; np. na takie:
;
; .macro @EXECUTE
; ldx @stack_pointer
; lda >:1
; sta stack,x
; lda <:1
; sta stack-1,x
;
; txa
; sec
; sbc #2
; sta @stack_pointer
;
; jmp :1 ; a najlepiej BRA :1 dla 65816 i bedzie relokowalne
;
; .endm
;
.proc nazwa_procki
.endpmakro @CALL odkladajace parametry procedur na stos programowy moze zostac, natomiast makro @EXITPROC musi zostac poprawione, na np.:
.macro @EXITPROC
ldx @stack_pointer
lda stack,x
sta _jump+1
lda stack+1,x
sta _jump+2
txa
clc
adc #2
sta @stack_pointer
_jump jmp $FFFF
.endmtak wiec narzedzie jest, do tego konfigurowalne, oprocz nowego sposobu tworzenia aplikacji, musi istniec system udostepniajacy podstawowe komponenty, posredniczacy w komunikacji miedzy sprzetem a aplikacja
niewatpliwie najmilszy jest 65816, zaczalem pisac takie srodowisko wlasnie dla niego, latwiejszy relokowalny kod (skok bezwarunkowy BRA), stos programowy o rozmiarze wiekszym niz 256B, ktory latwo adresowac dzieki rejestrom 16-bitowym
wieksza i szybsza liczba zmian na linie (4):
lda #
ldx #
ldy #
sta $d40a
sta $d016
stx $d017
sty $d018
lda #
sta $d019jest to wykorzystane w procedurach G2F, jesli jest potrzebna wieksza liczba zmian no to juz rastrem da sie zrobic (z lewej strony ekranu ok. 7 zmian)
skrocenie wywolania przerwania DLI (zapamietanie rejestrow):
sta regA
stx regX
sty regY
vdli jmp $ffffregA, regX, regY na stronie zerowej (w G2F wogole nie ma zapamietywania wartosci rejestrow przed przerwaniem DLI)
przelaczanie bankow moze spowalniac co najwyzej emulator
ogolnie chodziloby mi o stworzenie srodowiska graficznego (lepszego od GEOS'a), w ktorym takie przelaczanie aplikacji moznaby wykorzystac
jesli ktos bedzie chcial wykorzystac obsluge podstawowych komponentow w takim srodowisku to napisze aplikacje dzialajace w gfx, jesli chce najszybsza napisze aplikacje konsolowa, dzialajaca w znakowym srodowisku, z tym ze tu bedzie sam obslugiwal ekran albo za pomoca OS'a
a jedynym multitaskingiem bylyby programy podczepione pod koncowke przerwania VBL, zegar czasu rzeczywistego, player msx, bufor klawiatury itp. ogolnie krotkie programy nie przekraczajace 20.000 cykli
i tak jak napisal DRAC030 stos, strona zerowa, pamiec obrazu, program antica alokowany w pamieci dodatkowej, w momencie żądania wywolania programu przepisywane sa te dane do podstawowej, a kod aplikacji uruchamiany w dodatkowej pamieci
co by to dalo?
kilka, kilkadziesiat aplikacji w pamieci, mozliwosc przelaczania sie pomiedzy nimi, zupelnie inny komfort pracy, cala moc CPU wykorzystywana przez aktywna aplikacje
nasuwa sie skojarzenie z TTP (Tight Tools Package), ktore na GEOS jest wzorowany (graficznie), statyczne okno glowne, z ktorego wybieramy programy
inne skojarzenie podsunal Jurgi
miałem kiedyś programik, który robił mniej więcej to, co Qmeg 4.04
potrafił zamieniać dwa prg miejscami (łącznie z dosem), snapshot się zwał
nie był tak dobry jak Qmeg, ale niezły, można było na zmianę dwóch systemów używać, tylko przy wspólnym używaniu ramdysku były problemy, na 100% używał dodatkowego 64kb
do czego multitasking?
do obslugi protokolu TCP/IP, ftp'a, www, irc'a, gg czyli wszystkiego tego czego nie mamy (Contiki powstalo ale pewnie RJ'ek zabraklo w Atari )
p.s.
byloby milo gdyby w DRAC'OS mozna jakas funkcja systemowa wybrac nowe miejsce dla strony zerowej, stosu, czyli taki zalazek dla przelaczania taskow, do wykorzystania w przyszlosci
z tego co czytalem alokacje pamieci ma zaimplementowana, wiec moznaby wykorzystac ten OS jako podstawe integracji z takim srodowiskiem graficznym
multitasking prosty jak drut :), w n/w przykladzie na VBL'u przelaczane sa dwie "aplikacje", dzialanie kazdej polega na wpisywaniu do rejestru $d01a wartosci w petli nieskonczonej, pierwsza wpisuje wartosc $88, druga $26
...
start
lda #$88
sta $d01a
jmp start
...efekt koncowy to mruganie ekranu
wbrew pozorom nie jest to zbyt wolne jak na mozliwosci 6502, przepisanie stosu (256bajtow), zwrocenie wartosci rejestrow A,X,Y, wartosci wskaznika stosu S zajmuje z 5200 cykli, w skali 20.000 ktore oferuje VBL nie jest zle, jednak 65816 wykonalby to samo w kilkudziesieciu cyklach
w momencie wywolania przerwania VBL, na stos odkladane sa 3 wartosci, stan CPU, oraz adres ostatniego wykonywanego rozkazu
n/w program na poczatku preparuje odpowiednio stosy, ustawiajac w nich odpowiednio adresy startowe kazdej z "aplikacji", zapamietujac poczatkowa wartosc wskaznika stosu, reszte zalatwia juz "przyroda"
kazda z "aplikacji" zaczyna sie od poczatku strony pamieci, 256b na stos, nastepnie rozkaz skoku pod wlasciwy adres startowy aplikacji (JMP INIT) i wlasciwy kod programu (START)
jesli tych aplikacji mialoby byc kilkadziesiat, wowczas opoznienie tez wynosiloby kilkadziesiat ramek, dlatego najlepszym zastosowaniem takiego multitaskingu bylaby mozliwosc przelanczania aplikacji, np. mamy zaladowanych kilka programow w pamieci (odpowiednio napisanych, kod relokowalny) odpowiednia kombinacja klawiszy przechodzimy to task managera, wybieramy inna aplikacje i dzialamy w niej, potem mozemy wrocic do poprzedniej i kontynuowac
oczywiscie czesc aplikacji wymagalaby dzialania w tle, ftp'e, zegar czasu (co 50 ramek wywolywac), msx player (wywolywac co 1 ramke), moznaby takie aplikacje podpiac pod koncowke przerwania VBL, ogolnie bylyby rozne typy aplikacji jak i rozne ich piorytety dzialania, z kolei
operacje IO bylyby krytyczne czasowo
sposob tworzenia aplikacji tez wymagalby zmian, na pewno zostalby wyodrebniony podzial na segmenty, segment stosu, danych, kodu i antica, oczywiscie kod relokowalny. Aplikacja bylaby przechowywana w pamieci dodatkowej, w momencie żądania jej wykonania przepisywana bylaby do pamieci podstawowej (program ANTIC'a nie wykona sie w dodatkowej) i tu byloby kontynuowane jej dzialanie (po podmianie stosu)
kod dla 65816 bylby szybszy jednak narzucalby ograniczenia co do ilosci zaladowanych aplikacji, nie przeznaczymy przeciez calych 64kb na stosy dla kazdej z aplikacji, przechowywanie aplikacji w pamieci dodatkowej jest bardziej uniwersalne i nie narzuca ograniczen dla organizacji pamieci podstawowej
ktos chetny na projekt takiego systemu ? i pisanie aplikacji do niego ?
org $2000
tasks equ 2
main
/*
Initialize TASK
copy current stack to TASK1.STACK and TASK2.STACK
*/
cld
tsx
ldy #0
cp
lda $0100,y
sta task1,y
sta task2,y
iny
bne cp
// init stacks
lda >task1.init
sta task1,x
lda <task1.init
sta task1-1,x
lda #$a4
sta task1-2,x
lda >task2.init
sta task2,x
lda <task2.init
sta task2-1,x
lda #$a4
sta task2-2,x
// init stack pointers
:3 dex
stx task_point
stx task_point+1
/*
Initialize NMI vector
*/
lda $14
_wai cmp $14
beq _wai
sei
lda #0
sta $d40e
sta $d400
mva #$fe $d301
mwa #nmi $fffa
mva #$40 $d40e
// LET'S GO
jmp task1.init
/*
NMI routine
*/
.proc nmi
bit $d40f
bpl vbl
dli rti
vbl
sta rA+1
stx rX+1
sty rY+1
sta $d40f
// OLD TASK
tsk ldy #0
lda task_stack,y
sta _dst+2
ldx #0
_src lda $0100,x
_dst sta $ff00,x
inx
bne _src
tsx
txa
sta task_point,y
lda rA+1
sta task_regA,y
lda rX+1
sta task_regX,y
lda rY+1
sta task_regY,y
// NEW TASK
iny
cpy #tasks
bne skip
ldy #0
skip
sty tsk+1
lda task_stack,y
sta src+2
ldx #0
src lda $ff00,x
sta $0100,x
inx
bne src
ldx task_point,y
txs
lda task_regA,y
sta rA+1
lda task_regX,y
sta rX+1
lda task_regY,y
sta rY+1
rA lda #
rX ldx #
rY ldy #
rti
.endp
/*
TASK NO.1
*/
align
.proc task1
stack
.ds 256
init
jmp start
start
lda #$88
sta $d01a
jmp start
.endp
/*
TASK NO.2
*/
align
.proc task2
stack
.ds 256
init jmp start
start
lda #$26
sta $d01a
jmp start
.endp
task_stack dta h( task1 , task2 )
task_point .ds tasks
task_regA .ds tasks
task_regX .ds tasks
task_regY .ds tasks
;---
run main
opt l-
icl 'align.asm'
icl 'xasm.asm'po disasemblacji bedzie juz z gorki ;)
http://www.atariage.com/forums/index.ph … 49359&
przyklad jest w formacie MADS, wykorzystuje struktury danych, tablice
wykorzystane sa dwa sprity Player0 i Player1 dwu-kolorowe, program po modyfikacji struktury SDLI i procedury MPLEX mozna rozbudowac do 2 spritow 4 kolorowych, jesli skorzystamy z rastra to kazdy nowy sprite bedzie mogl miec inny kolor
jesli bedziemy rozmnazac 4 sprity, mozemy uzyskac od 16-21 spritow dwu-kolorowych i powstanie z tego scroll jak w Joyride
mozna taki multiplexer wykorzystac np. do gry, sprawdzanie kolizji bedzie odbywalo sie poprzez test pozycji X,Y kazdego z 8-21 obiektow, oczywiscie pozycja X,Y wyznacza lewy gorny naroznik obiektu, my musimy sprawdzic kolizje w obrebie prostokata, kwadratu
p.s.
program dla PC zostanie rozbudowany o automatyczne generowanie plikow wynikowych dla Atari
ok zapamietam znak < uzyskujemy przez < a > przez >
i nie wiem skad ta wrzawa, martwa materia aarea nabroila a Wy juz do gardel skaczecie :)
w zalaczniku oryginal, bez dodatkowych znaczkow dziwaczkow, dodawanych przez aarea, mozecie nawet do Worda to wczytac i edytowac
proponuje pobrac material genetyczny od Swietego, Pasia i innych wybrancow a nastepnie przekazac go zonom innych atarowcow aby ... no wiadomo sklonowac, najlepszy material genetyczny powinien byc chroniony i powielany w najczystszej formie
co wy na to ? ktos chce zostac matka zastepcza ?
musialem zapisac to w ten spsob inaczej aarea zjadalaby te znaki interpretujac je jako kod html, tak wiec przyklady sa tak zapisane abyscie je zobaczyli inaczej mielibyscie pourywane fragmenty wierszy co juz sie zdarzylo w innych artykulach
a przyklady byly skopiowane ze strony traktujacej o C++ i PC :) ale sprawdzalem je kompilowaly sie, w koncu to jezyk nie znajacy ograniczen platformowych ;)
no to juz jest grzech pierworodny, jak on mogl dokonac takiego bezecenstwa ;)
skoro to takie proste, male, zintegrowane i pewnie dostepniejsze, czemu nikt tego nie montuje masowo, czyzby wyniknely jakies problemy ?
dziwne bo ten poradnik pisalem korzystajac z XP i u mnie dzialalo
zaraz Macgyver sie odezwie i zapyta, skoro juz podlaczacie SID'a to czemu nie SoundBlastera skoro jest lepszy ;)
tak to jest jak sie artykulow na aarea nie czyta
kurde a ja myslalem ze naprawde chcecie go podrasowac, np. przez sprzetowa glosnosc, sprzetowe ustawianie czestotliwosci odtwarzania sampla :)
ale tak pozatym posiadam takowy
pewnie powstana i trackery na maluicha, jesli tylko SID bedzie dostepniejszy, wiec ktos to zoptymalizuje i ustandaryzuje
a jak wyglada dostepnosc SID'a ? czy trzeba pruc C64, bo jak tak to ja z mila checia bede je niszczyl :)
z tego co slyszalem sa dwie wersje SID'a starsza glosniejsza i nowsza cichsza, czym sie roznia dokladniej, moze nowe mozliwosci dzwiekowe :)?
tia co dwie glowy to nie jedna
Patchboy bedzie robil a Seban bedzie tylko mowil co ma robic :)
[ Dodano: Wto Kwi 26, 2005 5:21 pm ]
p.s.
a jak wyglada sprawa obciazenie CPU Atari podczas odtwarzanie SID'ow ?
tak jak np. z MPT ? bo jak tak to luzik :)
wow, nowy elektronik nam sie narodzil, radujcie sie bo oto nadchodzi :)
albo teoretyk ;) , teraz tylko przekuc to w czyn
buuuu znowu Quast ;)
jesli ktos zrobi to taniej to pewnie tylko w Chinach ;)
dopiero crossassemblery maja pseudo rozkaz INS ktory pozwoli Ci dolaczyc dowolny plik do kodu
trub Wam pewnie pomoze, a asemblery wspierajace Sparte to na Atari 8bit Fast Assembler, na PC Mad Assembler, Zooey i assembler Epi'ego
atari.area forum » Posty przez tebe
Wygenerowano w 0.100 sekund, wykonano 25 zapytań