Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TONY - Ark of the Covenant Kontynuacja przygód Tony'ego na Atari 8-bit, bez przemocy, z naciskiem na spryt i eksplorację.
ABBUC Software Contest 2025: Zgłoszenia Sprawdź aktualną listę programów zgłoszonych do konkursu ABBUC Software Contest 2025. Termin mija 31 lipca!
Gopher2600 0.50.0 Nowa wersja emulatora Atari 2600 z usprawnieniami i nowymi funkcjami debuggera.
Steem SSE 4.2.0 już dostępny Nowa wersja emulatora Steem SSE z istotnymi usprawnieniami i nowościami
Powrót Head Over Heels! Thalamus zapowiada Return to Blacktooth - kontynuację klasyka na Amigę i Atari ST
atari.area forum » Posty przez drac030
Na real Atari to jednak sporo trudniejsze...
E tam. Kwestia odpowiednich toolsów. Pewnie, że jakbym miał gołe 800XL + XC12, to bym tak robił, ale na atarce spoko się da wygodnie kodować, trzeba tylko chcieć (a nie, jak niektórzy, przykleić się do nieużywalnego QA i z tego powodu prędzej przesiąść się na peceta niż na lepszy asembler).
Za odpowiedź: "pisz se pod Atari" dziekuje od razu swiatecznym "Bóg zapłać" ;P
A co jest żłego w pisaniu na Atari? To np. http://atariki.krap.pl/index.php/The_Fi … _Processor jest bardzo wygodny edytor. A ostatnio istnieje tez The Last Word http://www.atari8.co.uk/lastword/lastword.htm dość podobny, tylko lepszy...
wymagana java5
Heh... to ja poczekam, aż coś będzie działało na atarce :)
No najs, ale jak zobaczyć, jak on wygląda?
Calamus ma wektorowe fonty (CFN), fakt. A Calamus 1.09N chodzi na zwykłym ST, więc to się musi w miarę łatwo renderować. I tych fontów jest cała masa, swego czasu Corel się chował.
PS. Tylko że chyba jest cienko z opisem formatu. Znalazłem tyle, że są na "b-spline'ach". A Signum ma fonty bitmapowe, trzeba poprawić info w Atariki...
Print Shop miał bitmapowe czcionki, jeno duże i proporcjonalne. Był jeszcze SprintXL, co to używał fontów z programu Signum z ST, też bitmapowych zdaje się, tyle że skalowalnych, bo (ale tu się mogę mylić bardzo) przygotowanych od razu w paru rozmiarach.
Wiesz co, "ja się co prawda na tym nie znam, ale mam na ten temat własne zdanie" (tm) Miałem okazję oglądać, jak z renderingiem TTF-ów radzi sobie Falcon030. No więc wychodzi mu to nieźle tylko dlatego, że raz zrenderowane znaki przechowuje w cache'u o wielkości kilkuset KB (OIDP), a póki mu sie ten bufor nie zapełni potrzebnymi znakami, wygląda to raczej blado.
No można. Pod warunkiem, że masz dedykowany, osobiście napisany CP/M BIOS, wtedy reszta CP/M też pójdzie. Przecież na LDW nie chodzi żaden CP/M z Amstrada, tylko "Indus CP/M", z dedykowanym BIOS-em, który ktoś musiał napisać.
Jasne, że się da napisać, z Księżyca nie spadają. Ale nie jest to kwestia wzięcia SIO2PC oraz 64k static RAM-u i związania ich sznurkiem.
No, skoro tak, to rób - tylko się potem nie dziw, że ci nie działa ... :P
PS. oprócz napisania BIOS-u dla CP/M przygotuj się też napisanie specjalnego firmware'u w asmie Z80, który będzie udawał, że działa na stacji LDW, mimo że nie będzie miał np. napędu ani kontrolera WD pod ręką.
Mówisz o Z80, a powinieneś pomyśleć, skąd weźmiesz dedykowany tej "karcie" BIOS CP/M :P I o tym ja mówię.
Sama potrzebna elektronika to własnie stacja LDW albo CA. Do uruchomienia Turbo Pascala sam Z-80 nie wystarczy, trzeba mieć jeszcze skąd załadować (stacja) oraz przydałby się dedykowany CP/M BIOS, bo inaczej z uruchomienia reszty CP/M-u nici.
Tak poza tym, to - jeśli ktoś zainteresowany - drajwerek "S2:" dla VBXE jest ciągle ulepszany, v. 0.90 tutaj http://drac030.krap.pl/vbxe_s.arc Niedługo, mam nadzieję, będzie też 80-kolumnowa konsola (czyli "E:" vel "CON:") dla SDX.
Znacie taki kawał, wychodzi ruski z samolotu z Moskwy i ma na ręku fajny elektroniczny zegarek. Robi to za zegarek, stoper, kalendarz, kalkulator, mały komputerek, radio (Moskwa), telewizor, wszystko radzieckie. A baterie? A baterie wiozę za sobą na wózku...
Ja sobie zadaję, wypuszczony przez mnie drajwerek powinien działać i na stronie $d6 i na stronie $d7.
No przecież jest napisane, że idą. Tylko że to jest 65C02, a nie 6502, więc jeśli już zmieniać procesor, to chyba lepiej na 65C816? Zgodność z 6502 nawet deko większa, a i możliwości jakby szersze.
Dorzuciłem możliwość zmiany koloru tła w trybie tekstowym. URL ten sam.
PS. Polecam szanownej uwadze plik RAIN.TXL - dla porównania można podmienić w linii 30 OPEN na GR.31 i zapuścić na ANTIC-u ;)
Dla chętnych, zabawka pozwalająca na dostęp do nowych trybów graficznych spod BASIC-a:
http://drac030.krap.pl/vbxe_s.arc
W archiwum przykłady w TBXL i opis w pliku tekstowym. Wersja 0.5, mogą być błędy i zmiany niektórych featur, ale już raczej chyba niezbyt duże.
Ja? :P :)
Przepraszam, ale od kiedy to MADS jest programem z cyklu "Software, gry 8-bit"? Przecież to program na peceta. Ergo ten wątek jest oftopem w tym dziale.
Mamy sprite'y. Z tego co widziałem ostatnio na zrzutach z Geos'a, również tam są one zastosowane - http://www.guidebookgallery.org/screenshots/geosc64
To trochę mało elastyczne, poza tym na C-64 masz dodatkowo atrybuty, co trochę pomaga. W ST desktop zadowala się dwoma kolorami, ale to w hiresie (640x400), gdzie za trzeci kolor robi siateczka białych i czarnych punktów i wyglada to bardzo dobrze. W 320x200 w dwóch kolorach (na Falconie da się włączyć taki tryb) dokładnie to samo wygląda jak kupa.
Tutaj widzę raczej inny problem, a mianowicie ograniczenie ilości pamięci na okno (16kB). Ewentualnie byłoby to na styk, chyba, że darujemy sobie buforowanie pamięci ekranu.
Buforowanie nie jest konieczne, z okien modalnych można zrezygnować zupełnie, a zamknięcie menu może wysyłać komunikat "redraw" tak samo, jak zamknięcie okna. To są szczegóły.
Oczywiście, że jest z tym trochę zabawy, ale czy specyfiką old-schoolowych komputerków nie jest właśnie ta konieczność zmagania się z takimi problemami?
Jest, ale po co sobie utrudniać tam gdzie można sobie nie utrudniać.
Oczywiście kompatybilność wsteczna z modelem pamięci OS'u atarowskiego nie ma w tym wariancie miejsca.
To kolejna wg mnie zaleta takiego Warpa: model pamięci (konwencjonalnej) pozostaje taki, jak był.
Jestem przekonany, że można zrobić to lepiej.
Och, naturalnie. Tzn. samej "ideologii" odświeżania raczej nie można się czepiać, jest to zrobione prosto, dobrze i skutecznie, ale to na poziomie AES-u. Problemem jest niewielka szybkość działania VDI, ale ono nie jest optymalne, istnieją alternatywne VDI działające kilkakrotnie szybciej.
Sam model pamięci procesora na CAR może być w dużym stopniu od tego niezależny.
Tak i tam by była pamięć w jednym kawałku, ale znowu tak jakby "na zewnątrz", bez dostępu do rejestrów I/O, OS-u itd., nie da się tam załadowac rezydenta współpracującego z normalny OS-em i ulepszającego jakoś jego działanie, a przy tym nie popadającego w konflikt z istniejącymi programami (bo model pamięci się zmienia). Znowu, na Warpie nie ma tych wszystkich problemów, dlatego sądzę, że tamto jest dużo bardziej atrakcyjne. No ale co tam komu, mnie osobiście taki kart, jeśli powstanie, przeszkadzał nie będzie.
PS. Te screenshoty z GEOS-a nie wyglądają źle, ale jednak wolałbym obejrzeć to na żywym egzemplarzu, tutaj kolory sa cokolwiek rozmyte, co wydatnie polepsza jakość "trzeciego koloru". Na moim Neptunie taka siateczka wygląda jak siateczka punktów, a nie jak kolor pośredni między czarnym a białym. Tak samo było na Falconie (na monitorze VGA).
Rozumiem, że chętniej widziałbyś bardziej ogólne zastosowania, być może jakiś system operacyjny, dodatkową pamięć, coś na kształt Geos'a, ale czy na pewno to nie jest osiągalne w tej formie, w jakiejś dalszej perspektywie czasowej?
Od tego to mamy VBXE (sorry, ale graficzny desktop musi być ładny, a z 320x192 w dwóch kolorach nic ładnego nie powstanie, bo potrzebne sa co najmniej 3 kolory, żeby to jakoś wyglądało).
Ogólnie miałem okazję poprogramować na atarce, która miała 1 megabajt pamięci w jednym kawałku, ale poza tym wszystko działało tak samo (oprócz tego, że szybciej). I od tamtej pory uważam, że bawienie się w bankowanie RAM-u, nawet jeśli by się miało w nim coś automagicznie pojawiać, to mało sensowna mordęga i komplikowanie prostych spraw.
To tak ogólnie, natomiast co do zastosowania takiego koproca do systemu operacyjnego, to powątpiewam w uzyteczność w ogóle. Normalny OS tego nie potrzebuje, bo i co on liczy. Zrobienie na tym pakietu FP jest problematyczne, jeśli bank 16k ma się podpinać tam, gdzie jest przestrzeń adresowa karta (w BASIC-u oznaczałoby to nieustanne migotanie ekranu, bo BASIC w kółko liczy coś na FP). Systemowi graficznemu przydałby się szybki procesor robiący za blitter, ale co z takiego blittera, który może skopiować blok pamięci obrazu w inne miejsce tylko wtedy, kiedy Antic/GTIA nic nie wyświetlają (poza tym potencjalna wydajność raczej blednie w porównaniu z blitterem VBXE).
Tak więc nie bardzo widzę, do czego miałoby mi się to osobiście przydać, a poza tym nasuwa się ogólniejsza obserwacja, że rozwój komputerów poszedł w tym kierunku, w jakim poszedł (mam tu głównie na myśli, że tam, gdzie jest więcej pamięci, jest ona dostępna w jednym kawałku) pewnie dlatego, że jest to rozwiązanie najlepsze i nie ma co wynajdywać prochu, który się na dodatek kiepsko pali...
Wiem, że marudzę, ale ciut za duży i przede wszystkim ciut za drogi.
n-buforowanie
No tak, tylko jakie widzisz zastosowania tego, bo ja, jak już napisałem wyżej, raczej wąskie (grafika wektorowa w gierce, pewnie głównie, oraz efekty w demach niedopuszczonych do konkursu). I co z tego nie może zostać zrobione przez regularne 65C816 z takiego Warpa?
drac030: no i wyszlo na jaw ze wypowiadasz sie na temat, mimo ze wczesniej nawet nie przeczytales opisu dzialania Zenona.
(...) wykonuje sie, po czym wraca do romu sygnalizujac w rejestrze zakonczenie operacji. (...) po upewnieniu sie czytajac z rejestru ze poprzednia operacja dopalatora sie zakonczyla (i "biega" on w romie), atarkowy procek przelacza polowki ramu CARta.
Co oznacza właśnie, że atarkowe 6502 zajmuje się synchronizacją dostępu i o to mi tu chodzi :P A teraz dodaj do tego pamięć ekranu i DL umieszczoną w "oknie" wiedząc, że póki Antic z niej czyta, dodatkowy procesor nie może do niej pisać.
konop: pin nie ma ani warpa ani f7 - on ma prosty adapter 65816 - drac030 to wie i nie wiem po co miast sprostowac twoja lekka pomylke - brnie dalej...
"Brnę", bo padł nonsensowny argument, że Warpy i F7 mają problemy ze stabilnością, i że to Konop na własne oczy widział. To mniej więcej tak, jakby wziąć zepsute 130XE, stwierdzic, że nie działa, po czym uogólnić, że wszystkie 130XE z natury mają to do siebie, że nie działają ...
Człowiek ma esteka i Turbo C, nie wiem, czy C++ mu się do czegoś przyda, a gcc żre tyle pamięci, że chyba bez 32 MB RAM-u nie ma co podchodzić.
atari.area forum » Posty przez drac030
Wygenerowano w 0.127 sekund, wykonano 13 zapytań