Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
MadPascal 1.7.3 już dostępny Nowa wersja kompilatora MadPascal przynosi poprawki i optymalizacje
Echa Lost Party 2025 Wyniki, zapis wideo oraz stuff.
Lost Party 2025 startuje już jutro W Licheniu Starym rusza zlot fanów 8-bitowych komputerów
atari.area forum » Posty przez tebe
to mozesz potestowac u Laoo, ma pamiec liniowa
SQT wersja angielska dociera do wiekszej liczby osob, kapujesz ?
a jaka jest Twoja nowa koncepcja, jesli to nie tajemnica ?
ekrany z pierwszego LEVEL'a do Rick Dangerous 1 mam zrzucone z C64 dzieki uprzejmosci pewnej osoby tworzacej mapy do gier, komplecik
dziwne, czyzby brak kompatybilnosci sprzetowej ;)
w zalaczniku zrodla z makrami *.MAC, oraz nowym MADS'em 1.6.2 ktory poradzi sobie z nowa dyrektywa .GET
struktura danych @SHAPE jest inna dla 6502 i 65816, organizacja pamieci danych kursora tez jest inne dla obu CPU, 65816 ma rozpisane te dane za pomoca 2 bajtow a umozliwia to wlasnie dyrektywa .GET z poziomu asma
p.s.
a skad LAOO masz liniowy RAM ?
Chcecie zrobic konkurencje Abbuc'owi ;)? Jak dotad tylko ABBUC potrafi motywowac. Tylko co z tego skoro wiekszosc produkcji jest marnej jakosci, wyjatkiem jest Dynablaster :)
Jakis grafik stworzy animacje ludzika i chce aby z tego powstala cala gra.
Brakuje grupy osob, ktore opracowalyby scenariusz gry (jesli to konwersja to scenariusz juz jest), grafike, muze. Bo na nowego Richarda Munnsa czy innego "czlowieka orkiestre" nie mamy co liczyc.
Chcialbym wiedziec przed napisaniem czegokolwiek, o co chodzi w grze, jak porusza sie glowny bochater, kim sa jego przeciwnicy, za co sa punkty, jak moze zginac, jak moga zginac przeciwnicy, jak zorganizowany jest ekran, czy to scrol pionowy, poziomy czy pojedyncze ekrany-komnaty, ile ma byc tych komnat, poziomow gry. Jak juz wszystkiego tego sie dowiem mozna zaczynac pisac bez obawy ze nagle kod programu bedzie musial zostac zmieniony o 180 st.
chodzi o to biale tlo, ktore pokazuje zuzycie CPU
rysuje wolno bo program startuje nie od poczatku ramki tylko znacznie pozniej (tam gdzie zaczyna sie biale tlo), gdyby startowac od poczatku ramki nie byloby widac ze tworzy kursor
ogolnie oba CPU wyrabiaja sie z plynna animacja w 1 ramce, jednak na CPU65816 jest to realizowane szybciej, o 1/3 szybciej, gdyby tak odpalic 14MHz powinno byc jeszcze szybciej
jest tutaj http://www.romnation.net/srv
na pewno dziala spod Qmega'a, w DOS'y sie nie bawilem
ekran podzielony jest na 3 czesci, dzieki ktorym widac ze 65816 jest szybszy od 6502 z tym samym zegarem o 1/3
taki maly przyklad realizacji tego samego zadania na 8 i 16 bitach
przyklady realizuja nakladanie na ekran programowego "ducha" (kursor mychy),
czy operacje na 16-bitach sa szybsze od 8-bitowych? sprawdzcie :)
topowe tytuly http://www.romnation.net/srv/toprated.html
pozatym:
http://www.arcade-museum.com/index.php
przyjrzyj sie tym tytulom super cobra, gyruss, moon patrol na Atari i na Mame
p.s.
skorzystam z okazji i zapytam Was o gre, ktora pamietam z automatow, tyle ze zawsze byla okupowana i nigdy w nia nie zagralem, a bardzo mi sie podobalo
w grze startowalo sie malym samolocikiem, po drodze zabieralo bombe ktora trzeba bylo zrzucic na statek, po drodze oczywiscie ostrzal obrony itp (gra 2D, scroll poziomy), kojarzycie taka gre ?
to moze juz lepiej przesiadziecie sie na atari 8-bit i nie bedziecie sie tak nudzic :)
p.s.
srednio 8bitowiec, tu na forum jest lepszy o 50% od 16-32bitowca :)
nie lubicie czarnego chumoru ?
dzieki Stryker za JagPad'a sprawuje sie znakomicie, a kasy nie oddam ;)
A7800 jest kompatybilne z A2600, bo ma w sobie A2600 wiec mozna na niej uruchamiac carty z A2600
z kolei carty dla A7800 sa w wiekszosci dla systemu NTSC, moze dzialac ekran tytulowy ale reszta gry juz nie
kolory wystepujace w obrazku sa sortowane od najczesciej do najmniej wystepujacych i po kolei, przypisywane sa im kolory, czyli najczesciej wystepujacy bedzie tlem
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 ;)
atari.area forum » Posty przez tebe
Wygenerowano w 0.086 sekund, wykonano 17 zapytań