Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Atari800MacX 6.0.1 Użytkownicy maszyn z MacOS X z pewnością będą zadowoleni.
LiteDOS-SE Build 2022 January 26 Nowa kompilacja minimalistycznego w rozmiarze DOS dla ośmiobitowych komputerów Atari.
4th Annual Atari Homebrew Awards konkurs na najlepszą pracę dla komputerów i konsol Atari w kilkunastu kategoriach.
SprEd - edytor do sprzętowych sprajtów Nowy edytor do tworzenia sprzętowych sprajtów Atari w przeglądarce.
Rozmowa z Maciejem Sysakiewiczem (Eden) Zapraszamy do przeczytania rozmowy z Maciejem Sysakiewiczem - członkiem silnej śląskiej giełdowej społeczności Atari.
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
tu jest o odwolywaniu sie do OS a nie hardware.
dałem przykład, myśleć.
Bartosz: - jeśli to przykład na wyciśnięcie z Atari "ostatnich herców i bitów" to chylę czoła :)
No nic, piszcie dalej, będzie śmieszniej :)
Pin... ale proszę nie używaj takich bezsensownych argumentów ... pytasz "ogólnie" a czepiasz się "szczególnie" fragmentu odpowiedzi o którym wiesz, że ma inna wymowę w kontekście twojego pytania. Ja nie napisałem nigdzie, że ten program jest przykładem "wyciskania czegokolwiek" tylko, że "wyciskanie" wymagać może omijania czegoś co ktoś uznaje za standard. Mam nadzieję, że nie musze tego jeszcze dobitniej wyjaśniać. Pozwolisz, że zacytuję "Dałem przykład - myśleć".
Ty piszesz o programistach zawodowych. Czy zakładasz, że ktokolwiek na tym forum jest zawodowym programistą Atari? Już w tym kontekście twoje pytanie/zarzut było pozbawione sensu. Bo czemu niby amator Atari ma się trzymać standardów? Nie zadziała na innym sprzęcie, to nikomu nic sie nie stanie i co najwyżej zrobi kolejną wersję skoro ma takie "widzi-mi-się".
BTW XXL pisze przy pomocy tego jakiś minimalny generator labiryntu ... zwracam uwagę na słowo "minimalny". Zresztą nie ważne co pisze. Ważne, że mu się chce.
Oh. Pin.
Nie chcę cię irytować, ale chyba już tylko Ty myślisz o profesjonalnym programowaniu na atari.
Czy czujesz się jak ten ostatni weteran WWI?
Który stwierdził - nie spodziewałem się że to będę Ja?
@Pin - proponuję zatem, by do regulaminu kompotów dopisać punkty:
1. Projekt zgodny ze schematem MVC
2. Założenia muszą być opsane w UML
3. Spełnone metryki HIS
4. Unit testy - bądźmy litościwi - niech będzie przynajmniej 90% pokrycia.
Parę kolejnych punktów pewnie by się dało dodać.
Myślę, że będzie stado chętnych :).
A tak całkiem serio - koledzy chyba przeoczyli fakt, że sprzęt Atari (XE i ST) to jest już trup. Trochę podgrzewamy tego trupa nowym softem i/lub sprzętem, ale jednak wiele to nie zmienia. Nas (podtrzymywaczy) raczej ubywa niż przybywa więc to podgrzewanie coraz słabiej nam wychodzi.
Ja nie napisałem nigdzie, że ten program jest przykładem "wyciskania czegokolwiek" tylko, że "wyciskanie" wymagać może omijania czegoś co ktoś uznaje za standard.
Omijanie legalnych odwołań OS to faktycznie zysk :)- teraz czeka nas tylko wysyp nowych produkcji z użyciem tej funkcjonalności.
Ty piszesz o programistach zawodowych. Czy zakładasz, że ktokolwiek na tym forum jest zawodowym programistą Atari?
nie sądzę.
Nie chcę cię irytować, ale chyba już tylko Ty myślisz o profesjonalnym programowaniu na atari.
gdzie coś takiego napisałem?
@Bober - nawet nie przeczytałem Twojego posta :)
Ok, dla Waszego szczęścia i ogólnego powodzenia w realizacji waszych wzniosłych celów niniejszym opuszczam ten postatarowski wątek ;)
@Pin - i dobrze. Bo to taki korpo-dev-dełkot :).
Ale na scenie używać tego nie trzeba, więc kod pisze się swobodniej. I na tym zabawa polega.
Inna rzecz, że łamanie standardów demoscena ma w swoich genach.
DISPLY equ $F1E9
jakby sie dobrze zakrecic to ta procka moglaby posluzyc do drukowania tekstu na ekranie graficznym...
albo, szybkie wypelnianie...
albo, softsprite poruszany z dokladnoscia do pixela... ale trzeba przygotowac dane tak, zeby kazdy pixel to osobny bajt wiec 4 kolorowym sprite wielkosci 8x16 zabieralby 128 bajtow ;)
wszystkie XL OS maja procke pod tym adresem
- w kodzie nie ma zadnego bezposredniego zapisu do pamieci ekranu, wszystko leci przez OS
- stos programowy w tym trybie zabiera 2.5 kb
- systemowy fill to jakas porazka, juz stawianie punktow w petli bylo szybsze ale za to funkcja z posta 57 robi robote :-)
i najwazniejsze - wielkosc kodu, no niestety 3 strony pamieci :/ kiepsko.
zostalem poproszony o przekompilowanie wersji labiryntow dla "upgrejdowanych" komputerow atari z systemem operacyjnym potrafiacym emulowac CIO (nie wiem dlaczego nie uzywaja oryginalnego XL OS)...
mam prosbe o udostepnienie procedur XLOS w wersji CIO dla:
Graphics
Plot
Drawto
Locate
dziekuje w imieniu emu"sceny" ;-)
Wszystko to znajdziesz u Zientary w "Procedurach Wejścia/Wyjścia": http://tajemnice.atari8.info/ksiazki/index.html
Można spojrzeć do "Procedur interpretera BASIC-a" w jaki sposób realizowane jest LOCATE - wydaje mi się, że x i y należało wstawić do COLCRS i ROWCRS po czym wykonać GET (PLOT analogicznie, ale z PUT-em). Ale głowy nie dam.
Ostatnio edytowany przez mono (2018-12-27 13:56:19)
materialy na podstawie ktorych moge sobie te procedury napisac znam... nie tego oczekiwalem ale dziekuje.
oczekuje gotowych procedur.
dziekuje :-)
http://www.atarimagazines.com/compute/i … _Atari.php
dzieki :-)
myslalem ze sie wymigam ... a teraz bede musial usiasc ;-)
nic odkrywczego, dokladnie ten sam program:
wykorzystujac procedury graficzne OS bezposrednio: 28 sekund
wykorzysujac CIO: 76 sekund
dwa i pol raza szybciej jest bez CIO
ciezka noc... inna reprezentacja labiryntu.
raycaster korzystajacy z procedur w OS na oko wyglada na 2 razy wolniejszy
Ostatnio edytowany przez xxl (2019-06-22 12:38:09)
czasem przychodzi potrzeba sprawdzenia w jakiej rozdzielczosci pracujem. niestety sterownik nie ma takiej funkcji wiec albo tabelka albo:
os_graphics equ $ef9c
GETCH equ $F180
rowcrs equ $54
colcrs equ $55
dindex equ $57
newrow equ $60
newcol equ $61
lda #7
jsr os_graphics
lda #0
sta colcrs
sta colcrs+1
sta newcol
sta newcol+1
sta rowcrs
@ inc newcol
bne @+
inc newcol+1
@ jsr GETCH
lda rowcrs
beq @-1
ldx dindex
lda $EE8D,x
sta newrow
w newcol i newrow mamy odpowiedznio rozdzielczosc pozioma i pionowa.
To samo prościej:
dindex equ $57
tmccn equ $ee7d
tmrcn equ $ee8d
ldx dindex
lda tmccn,x
ldy tmrcn,x
ldx #0
cmp #<320
sne:inx
; X:A = horizontal resolution
; Y = vertical resolutionOstatnio edytowany przez Fox (2019-08-19 19:23:10)
ok, a informacja o szerokości obrazu w bajtach, czyli ile bajtów przypada na poziomą linię obrazu ? też takim sprytnym sposobem czy tabelką ?
tu jest tabelka:
EE9D: 00 00 00 02 03 02 03 02 03 01 01 01 00 00 03 02
ile razy trzeba wykonac LSR na X i A
wynik w bajtach szerokosc ekranu
To przy okazji informacja o bitach na piksel:
00 = 8 bitów (tryby znakowe)
01 = 4 bity (tryby GTIA)
02 = 2 bity (tryby 4-kolorowe)
03 = 1 bit (mono)
ok, a informacja o szerokości obrazu w bajtach, czyli ile bajtów przypada na poziomą linię obrazu ? też takim sprytnym sposobem czy tabelką ?
Drugi sposób:
dindex equ $57
tlshc equ $ee6d
ldx dindex
ldy tlshc,x
lda #5
shift asl @
dey
bne shifti ten pierwszy sposob:
ldx dindex
lda $ee7d,x
cmp #<320
beq @+
clc
@ ldy $ee9d,x
@ dey
bmi @+
ror @
bne @-
@ A = byte per lineSzybciej:
dindex equ $57
tmccn equ $ee7d
trshc equ $ee9d
ldx dindex
lda tmccn,x
ldy trshc,x
beq done
cmp #<320
seq:clc
loop ror @
dey
bne loop
donedziękuję Panowie, procedura InitGraph w MadPascalu jest teraz krótsza blisko 100 bajtów :)
DISPLY equ $F1E9
nie bylo przykladu.
wyswietla bajt z akumulatora na obecnych wspolrzednych, atrakcyjne tez w trybie tekstowym (kody ekranowe) bo nie zmienia wspolrzednych jak print.
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.093 sekund, wykonano 10 zapytań ]