Niezalogowany (Zaloguj się)

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

TOMEK-8 cartridge by Nosty

Od 1 do 18 z 18

- 1:
  
  CommentAuthortdc
- CommentTime5 Sep 2012 zmieniony
Co prawda Pin już wspominał o tym na forum, jednak stwierdziłem, że warto poruszyć ten temat szerzej (w końcu jestem imiennikiem tego projektu :D)

Oto pierwszy filmik Nosytego, który pokazuje nowe możliwości Atari:
->link<-

Mamy tu:
Tryb hi-res wąski (256x208 pikseli).
Maski obiektow są rysowane osobno, mozna wiec powiedziec ze pod koniec dema, na ekranie lata jednoczesnie:
- 16 "duszkow" o wymiarach 16x9 pikseli,
- 16 "duszkow" 32x32 piksele,
- 16 "duszkow" 64x58 pikseli,
+ teksty.

Czyli podsumowując mamy tutaj nowe urządzenie (obecnie prototypowe) mieszczące się w carcie, który każdy może sobie wsadzić do standardowego Atari i odkryć je na nowo ;)

Jedną z największych zalet tego rozwiązania jest prostota, a co z tego wynika także cena, która obecnie jest szacowana na ~40 zł.

To genialne rozwiązanie nie tylko od strony sprzętowej, programowej, ale też każdej innej.

Obecnie mają być jedynie wydawane gry na cartach z wykorzystaniem tych nowych cudów graficznych, ale po przemyśleniu Nosty planuje też samodzielny cart dla osób chcących samodzielnie wykorzystywać ten potencjał do innych zastosowań, a jest ich właściwie tak dużo jak zastosowań samego Atari;)

Ogólnie Nosty - wielki szacun! Jeśli chodzi o mnie to zainteresowałeś mnie bardzo tym rozwiązaniem;)
- 2:
  
  CommentAuthortdc
- CommentTime5 Sep 2012 zmieniony
Nosty, projektem tym trafiłeś bardzo celnie w moje atarowe serce ;)

Już oczami wyobraźni widzę bibliotekę dla Action! która wykorzystuje te możliwości. Action! jest jednym z najbardziej elastycznych języków dla małego Atari, już teraz mamy dla niego wiele różnorodnych bibliotek, ale taka do robienia gier to miodzio np.
```
Module

include "tomek8.act"
inclide "sin.act"

byte a,dr

Proc gra()
graphicsx(8)
dr=0

do
for a=0 to 254 
do
plotx(dr,a+sin(a+dr,a),1)
od
dr==+1
ramkax()
od

Return
```
To jest tak piękne... hmmmm... proste.
Proste jak programowanie w Atari Basic;)

Dlatego ja bardzo proszę o dwie drogi rozwoju (tak jak obecnie zakładasz).
1. produkcja gier - ok to zrozumiałe
2. cart dla ktosiów którzy chcą coś z tym potencjałem zrobić.

Odnośnie punktu 2 to trzeba koniecznie tutaj zrobić cartridge, który jest przelotowy, bo np. warto aby można było dodać cartridge z Action!;) albo może ktoś jeszcze coś będzie chciał dodawać.

Druga sprawa to oczywiście musi to być mocniejszy cart, (czyli 70MIPS, 56KB RAM, 512KB flash), kwestia nieco większej ceny nie gra tutaj żadnej roli. Moc obliczeniowa pewnie komuś się przyda, ale na razie nie jest tak istotna jak ilość pamięci. Obecne 8 kb to dla Atari za mało, szczególnie gdy możemy wyświetlać dziesiątki dużych spritesów (które mają dodatkowo maski), a każdy z nich powinien mieć jakieś klatki animacji (czego nie ma na filmiku).

Nosty narobiłeś zamieszania ;) Teraz trzeba będzie przygotować nową wersję plików car he he ;):)
- 3: CommentAuthorYolk (xmgatz)
- CommentTime5 Sep 2012
Ale czad. Tak jak nie jestem specjalnie zwolennikiem "sprzętowych" modyfikacji, tak koncepcja cartridge'a, który daje dodatkowe możliwości jest dla mnie jak najbardziej atrakcyjna. Trochę jak commodorkowy Ultimate, chociaż oczywiście operujący w innej przestrzeni (ale tam też zdaje się już jest stereo SID emulowany software'owo).

Trzymam kciuki i już wstępnie zapisuję się jako chętny na zakup gdyby ruszyła produkcja. :-)
- 4:
  
  CommentAuthortdc
- CommentTime5 Sep 2012
No ja właśnie też nie jestem zwolennikiem rozszerzeń w tym względzie że każdy kto sięgnie po dowolne Atari nie będzie mógł z tego skorzystać. Tomek-8 nie ma takich ograniczeń - dla mnie to idealne rozwiązanie.

A no i jeszcze jedno mi przyszło do głowy, warto zrobić jakiś test obecności takiego carta bo w Action! bardzo łatwo będzie zrobić bibliotekę która będzie się dostosowywać do tego czy taki sprzęt jest czy go nie ma, a program będzie działał mimo to.
- 5:
  
  CommentAuthorxeen
- CommentTime5 Sep 2012 zmieniony
ogólnie wypas - niestety jedyna "wada" to brak wsparcia w "emu". Nie każdy ma sprzęt. Cudzysłów - celowy, po prostu ogranicza to odbiorców, a może właśnie zachęca odbiorców do kupna A8 - tego nie wiem. Odbiorców może nie ogranicza aż tak cena, która jak rozumiem nie będzie wygórowana, ale ilość wyprodukowanych egzemplarzy. Bez karta nie pograsz, panie - dla tytułów komercyjnych to akurat zaleta.
- 6:
  
  CommentAuthortdc
- CommentTime5 Sep 2012
xeen, sama gra też będzie na carcie wydana jako całość;)

Co do emulacji to nic nie stoi na przeszkodzie aby emulatory emulowały i to, w końcu Altirra już dziś emuluje kilka nowych rozwiązań sprzętowych. Problem z emulacją jest jedynie taki że na Pentium 200 MHz czy Falconie to nie będzie to chodziło płynnie:P
- 7:
  
  CommentAuthorxeen
- CommentTime5 Sep 2012
nie wiem czy dobrze rozumiem ideę, teoretycznie każda edycja karta może mieć inne, dedykowane pod daną grę możliwości. nie wyobrażam sobie emulacji czegoś takiego - ale może źle to rozumiem. Taj ka pisałem - może emulacja to nie jest dobry argument - ale będzie trochę bolał.
- 8:
  
  CommentAuthortdc
- CommentTime5 Sep 2012 zmieniony
Do emulatora dodajemy emulację wykorzystanych w TOMKU-8 rodziny procesorów, a następnie wraz z kodem gry dodajemy kod dla tej dopałki (którą przygotował autor) i będzie glanc działało. Ale to jak pisałem trzeba będzie dzielić pliki car/bin/rom na dwa bloki danych.

Większym problemem są niezgodności nowych/różnych wersji co już dziś doskwiera właścicielom VBXE. Dlatego jestem za tym aby to było jakoś dobrze dopracowane i pilnowane. Jest to ważne już na tym etapie rozwoju, bo potem (po uwolnieniu) problemy się już będą tylko piętrzyć.

---
Jeszcze przyszło mi do głowy że coś takiego przydałoby się użytkownikom Atari ST (choć oni i tak mają dużą wydajność, w końcu automatowe gry się pojawiały na ST), jednak problem w tym, że Atari ST ma kompletnie zwalony cartridge. W Falconie jest to już lepiej zrobione bo tam można wiele rzeczy pobierać (na różne sposoby) z zewnątrz, w ST jest kicha.
- 9: CommentAuthornodez
- CommentTime5 Sep 2012
nie no nie mam pytan masakra jest ten cart
- 10: CommentAuthorwieczor
- CommentTime5 Sep 2012
@tdc: właścicielom VBXE nic nie doskwiera - poza brakiem softu :) - jakiś czas temu jeszcze na poziomie prac poruszałem ten problem na AArea - rdzenie są względnie ustandaryzowane, więc programista może się określonych rzeczy spodziewać

@xeen: jak ty chcesz mieć wsparcie w emulatorze, skoro pierwsze ogólne info o carcie pokazało się 2 dni temu ? :D Spokojnie, poczekamy na wersję standalone, jeśli dobrze zrozumiałem zasadę działania to emulacja czegoś takiego nie będzie trudna. Prostsza niż np VBXE a to już jest
- 11:
  
  CommentAuthorxeen
- CommentTime5 Sep 2012
oj Wieczór, to był skrót myślowy. Jeżeli dobrze rozumiem ideę to wsparcie dla emu może okazać się nierealne, powtarzam, jeżeli dobrze rozumiem. Nie oczekiwałem wsparcia teraz. Ogólnie jest ono ważne (chociaż w przypadku VBXE na razie i ono nie pomogło)
- 12:
  
  CommentAuthortdc
- CommentTime5 Sep 2012 zmieniony
@wieczór kluczowe jest tutaj słowo "względnie" to tak jak w tej znanej reklamie piwa było słowo "prawie" :P
Mnie to nie dotyczy, ale mało brakowało a też bym kupił pierwszą wersję zaraz jak się pojawiło VBXE.

Co do procedur graficznych TOMEK-8 to chodzi mi po głowie problem generowania dużej ilości cząsteczek (czym się akurat zajmuję) i mamy tu dwa rozwiązania:

1. mamy tablicę w RAMie TOMKA np. 500 współrzędnych x i y (kolor nie ma znaczenia w 8 tr.gr., kasowanie punktów też może być automatyczne). Za pomocą 6502 wypełniamy jedynie tę tablicę, zakładając że np. współrzędna y <240 to punkt który ma być narysowany, inne nie (nie istnieje w danej chwili cząsteczka).

To świetne i bardzo ułatwiające programowanie, jak pisał XXL nie wymaga żadnego kodu do rysowania w pamięci Atari.

Ma to jednak wadę wydajnościową, tzn. z jednej strony umożliwia osiągnięcie efektów rewelacyjnych jak na 8bitowy komputer, z drugiej strony pozostawiamy całą kwestię wyznaczania współrzędnych biednemu 6502, biorąc pod uwagę że ten nawet nie ma operacji mnożenia i dzielenia, sinusów itp. to sprawa się komplikuje.

Nawet jeśli operację mnożenia będziemy zlecać TOMKowi to wszystko to razem będzie obciążało 6502 i ogólnie doprowadzi do sporych obciążeń. W skrajnym przypadku może się okazać, że nie uda się wypełnić wszystkich 500 współrzędnych w jednej ramce.

Dlatego warto opracować bardziej zaawansowaną (ale otwartą) procedurę rysującą duże ilości cząsteczek.

2. Tu też pozostaje tablica z współrzędnymi x i y aby można je było (jak trzeba) pobrać do pamięci Atari, jednak traci to już takie znaczenie.

Budujemy sobie przykładowo stos prostych operacji (np. trygonometrycznych itp.) wraz z określeniem na jakich grupach cząsteczek mają one być wykonane i wtedy wypełniamy tylko taki stos na ramkę, a całą sprawą obliczeń i rysowania zajmuje się wywołanie jednej operacji TOMKA.

Rozwiązanie to eliminuje do minimum obciążanie procesora centralnego Atari w operacjach na cząsteczkach czyli możemy osiągnąć maksymalną szybkość rysowania takowych (z opcją np. rysowania prostych między punktami, czy też trójkątów).
W mojej ocenie da to taką ilość cząsteczek, że będzie można ekran zasypać takimi cząsteczkami, czego jeszcze użytkownicy 8bitowców nie widzieli - to będzie robiło piorunujące wrażenie !

Warto się też tutaj zastanowić czy współrzędne tych cząsteczek od początku nie powinny być 3D czy może do wyboru 2D i 3D (szybkością się tu niewiele zaoszczędzi, ale będzie o jeden parametr mniej do przekazywania w komunikacji z Atari).

Rozwiązanie 1 ma wady, ale też jest bardzo łatwe do zakodowania po stronie TOMKA, a też wiele ułatwia koderom na Atari. Natomiast rozwiązanie 2 jest bardziej złożone i pewnie nosty się tym nie zajmie, ale ma duży potencjał i jakiś dobry koder może się tym z przyjemnością zająć. Mam nadzieję że w przyszłości coś takiego nastąpi.

Jakby się tym zajął jakiś dobry koder, to dałoby się to bardzo uprościć i byłoby to fajne. No i oczywiście dałoby się osiągnąć jakąś fajną wydajność - na co liczę;)

---
No i na koniec:
Steve Jobs i Michaił Kałasznikow wyznawali zasadę że proste jest piękne, że proste jest najlepsze (i najtrudniejsze). Nosty tutaj sięgnął szczytów, odwdzięczę się mu tutaj: nosty to człowiek renesansu !;)

...i oprawiłem to w ramki;)
- 13: CommentAuthornosty
- CommentTime6 Sep 2012
Dziekuje za mile slowa :)

Z emulacja faktycznie beda problemy jesli nie powstanie jeden frimeware, a pewnie nie powstanie. Bo np problem TDC'a z czasteczkami pokazuje ze nawet gdybym przemyslal wszystkie standardowe potrzeby to natychmiast znajdzie sie koder z pomyslem, ktory wykracza poz standard :) I trzeba dla niego zmienic frimeware.

Te 500 "czasteczek" to po prostu punkty? No to rozwiazanie nr 1 dzialaloby juz teraz. Mam zaimplementowany rozkaz PLOT X,Y, ktory dziala natychmiastowo. Po prostu musialbyc co ramke rysowac te 500 punktow w nowych miejscach.

Rozwiazanie nr 2 wymagaloby osobnej implementacji. XXL wymyslil cos podobnego, i nazwal to nie "stosem rozkazow" ale DL_PIC :)
Generalnie chodzi o jakas powtarzalnosc i automatyke rozkazow po stronie PIC'a.
Ja zas wymyslilem ze mozna bardzo latwo zrobic "animacje sprzetowa". Czyli zlecasz ktore klatki animacji i co ile ramek ma je podmieniac TOMEK w danym "duszku" i juz wiecej sie nie martwisz.

To wszystko sa juz jednak rozwiazania wyzszego rzedu. Najpierw musze zakodowac podstawy :)

Ale bardzo sie ciesze z zainteresowania na wszystkich forach. Widze ze jest zapotrzebowanie i mam mnostwo motywacji do dalszej pracy!
- 14: CommentAuthorwieczor
- CommentTime6 Sep 2012
Wbrew pozorom emulacja bez jednego uniwersalnego firmware'u jest jak najbardziej mozliwa jesli mowimy o urzadzeniu programowalnym. Po prostu trzeba napisac emulator urzadzenia - czyli PICa z pamiecia w okreslonym miejscu a nie symulowac wylacznie efekt dzialania :)
- 15: CommentAuthorwieczor
- CommentTime6 Sep 2012
A co do zdania w ramce to zgoda, aczkolwiek nie ujmujac Nosty'emu czy Jobsowi uwazam ze szczytow siegnal Kalasznikow, gdyz z wymienionej trojki jego wynalazki sa najbardziej uniwersalne i rozwiazuja najszerszy zakres problemow :)
- 16: CommentAuthorwieczor
- CommentTime6 Sep 2012
A swoją ścieżką, Nosty nie przestajesz mnie zadziwiać :) Tworzysz fajne gry, teraz ten wynalazek (w końcu stało się jasne o co Ci chodziło w tym wątku: ->link<- :) ). Nie pracujesz zawodowo, nie masz rodziny/znajomych, czy po prostu nie śpisz ? :)
- 17:
  
  CommentAuthortdc
- CommentTime6 Sep 2012 zmieniony
nosty:
Dziekuje za mile slowa :)

A proszę bardzo!;)

Co innego latami pisać, tracąc nasz czas i miejsce na serwerze (jak np. ci którym brakuje odwagi aby się podpisać pod swoimi komentarzami), a co innego gdy np. Ty nas co chwilę czymś zaskakujesz;)

nosty:
Z emulacja faktycznie beda problemy jesli nie powstanie jeden frimeware, a pewnie nie powstanie.

Ja co prawda nie chciałbym aby było tych firmwareów dużo, wolałbym jeden elastyczny i z wieloma funkcjami. Jednak nawet jeśli ktoś np. XXL zaszaleje to zapisując ten kod wraz z plikem car/bin/rom wszystko będzie działało.

nosty:
Bo np problem TDC'a z czasteczkami (...), ktory wykracza poz standard :)

Ten problem absolutnie nie wykracza poza standard, cząsteczki są dziś standardowo od wielu lat realizowane sprzętowo przez karty graficzne (na pecetach było spore zacofanie pod tym względem, bo rozwijało się wszystko z wyjątkiem cząsteczek, ale w końcu jakoś po roku 2000 wprowadzono i dziś jest normą).

Rysowanie masy punktów jest jak najbardziej typowym wykorzystaniem akceleracji grafiki, w końcu to zawsze sprawiało wiele problemów, przykładowo pierwsze demka na Falcona popisywały się dużą ilością punktów animowanych w ramce, właśnie dlatego bo chciano się pochwalić DSP, czyli czymś nieosiągalnym wtedy na innych komputerach.

nosty:
I trzeba dla niego zmienic frimeware.

Dlatego uważam, że API powinno przewidywać wszystkie podstawowe operacje graficzne już na początku, włącznie z hurtowym rysowaniem masy punktów.

nosty:
Te 500 "czasteczek" to po prostu punkty?

To rozwiązanie ma być jak najbardziej uniwersalne, dla mnie to będą cząsteczki bo jak pisałem się tym zajmuję, dla kogoś innego będą to po prostu punkty np. coś w rodzaju gwiazd, które zwykle się robiło na sprzętowych duszkach - ale teraz będą mogły być animowane we wszystkich kierunkach jak w demkach na ST.

nosty:
No to rozwiazanie nr 1 dzialaloby juz teraz. Mam zaimplementowany rozkaz PLOT X,Y, ktory dziala natychmiastowo.

No ja wiem jednak rozwiązanie numer 1 jest tylko trochę bardziej zaawansowane, a będzie działało szybciej niż zwykły PLOT X,Y.

Przykładowo cząsteczka która nie będzie w danych ramkach zmieniała pozycji, to nie będzie wymagała komunikacji z TOMKIEM, co już będzie istotnym zaoszczędzeniem czasu CPU.
To tylko taki przykład, naprawdę warto zamiast pojedynczej operacji PLOT dodać operację "hurtową".

nosty:
Rozwiazanie nr 2 wymagaloby osobnej implementacji. XXL wymyslil cos podobnego, i nazwal to nie "stosem rozkazow" ale DL_PIC :)

Hmmm... jestem zainteresowany. XXL możesz napisać co chcesz zrobić?

nosty:
Czyli zlecasz ktore klatki animacji i co ile ramek ma je podmieniac TOMEK w danym "duszku" i juz wiecej sie nie martwisz.

No tak to już będzie działać jak jakiś hardware do konsoli (z tych znanych nam np. 16bitowych).

nosty:
To wszystko sa juz jednak rozwiazania wyzszego rzedu. Najpierw musze zakodowac podstawy :)

Oczywiście, czekamy z niecierpliwością.

Ja nic nie poradzę, bo nie znam tego asm kompletnie.

Ale ogólnie znam się na różnych asmach, więc może teoretycznie coś mogę poradzić, domyślać się mogę że ten procek implementuje wiele najbardziej wydajnych rozwiązań stosowanych w obecnych procesorach, a to jest wiedza cenna ale i powszechnie mało znana od strony praktycznej.

nosty:
Ale bardzo sie ciesze z zainteresowania na wszystkich forach. Widze ze jest zapotrzebowanie i mam mnostwo motywacji do dalszej pracy!

Polecam się;)
W każdym razie mam nadzieję że zainteresuje się tym jakiś koder na poważnie i wyręczy Ciebie z pisania wszystkich niezbędnych procedur.

wieczor:
Wbrew pozorom emulacja bez jednego uniwersalnego firmware'u jest jak najbardziej mozliwa jesli mowimy o urzadzeniu programowalnym. Po prostu trzeba napisac emulator urzadzenia - czyli PICa z pamiecia w okreslonym miejscu a nie symulowac wylacznie efekt dzialania :)

Pisałem o tym w poście #8.

wieczor:
A co do zdania w ramce to zgoda, aczkolwiek nie ujmujac Nosty'emu czy Jobsowi uwazam ze szczytow siegnal Kalasznikow, gdyz z wymienionej trojki jego wynalazki sa najbardziej uniwersalne i rozwiazuja najszerszy zakres problemow :)

He he;)

No ale jak miałbym się czepiać;) To rozwiązanie nostyego doskonale się nadaje do zakodowania sygnału (np. radiowego), odkodowania np. strumienia video czy innego (np. mp3 lub ogg teraz jest realne na Atari!), a do tego nie przyda się ani karabin Kałaszkikowa, ani jego genialna pułapka na krety ;):):)
- 18:
  
  CommentAuthortdc
- CommentTime6 Sep 2012
Stawiam że jak wielu z nas nosty po prostu nie śpi :P

Od 1 do 18 z 18