tj. czym jest cart jak nie rozszerzeniem?

Ja tam bym wolał mieć to wewnątrz, jakoś nie lubię wahlowania cartami w XXI wieku, tym bardziej, że np. takie SIDE stanowi kluczowy element wyposażenia ;) Ale rozumiem ideę wydawania gier z dopałką (jak kiedyś DOOM dla SNESa) i za to należą się wielkie brawa dla Nostiego, nasze ATARI ma swoją złotą erę :)

O wersji "ogolnej" z mocniejszym i wyposazonym w wieksza ilosc pamieci procekiem na razie nie mysle. To musi poczekac min. kwartal az wersja obecna zostanie wyprodukowana i sprawdzi sie w boju.

Mimo ze moim celem jest idea wydawania na tym carcie pojedynczych gier, to chce to tak zaprojektowac, ze jesli kupisz jedną grę na cartridgu to kolejne gry bedziesz mogl odpalic z dyskietki wykorzystujac "infrastrukture" posiadanego carta jako dopalke.
Te koncepcje są wlasnie dyskutowane, za moment będą testowane. Zobaczymy co wyjdzie...

Dokladnie tak: firmware zajmuje pare-parenascie KB, wiec spokojnie gra moze go sobie ladowac, tak jak bedzie ladowac do carta dane graficzne.
Nie wiem czy to sie dokladnie tak uda zrobic, ale pewnie tak.

Już widzę wysyp nowych firmware...
Mi bardziej chodziło o współpracę z SIDE (głównie) z tym wbudowaniem.
Ale w sumie, jak gra per cart to nie ma o czym mówić.
Po namyśle.

nie wiem czy to jest realne, ale przyszło mi na myśl- kart, ktory migiem dokonywalby asemblacji kodu pisanego na atari.wreszcie moznaby wygodnie kodowac na atarce.

chodzilo mi o asemblacje na żądanie, QA miele kod bardzo dlugo

Dziwaczny pomysl w dzisiejszych czasach :) Ale takimi samymi wydają mi sie edytor tekstow na male Atari (chocby najlepszy) czy nawet uzywanie slawetnej Sparty. Bo mimo zamilowania do Atari ciezko mi przychodzi uwierzenie ze ktos na tym sprzecie rzeczywiscie _pracuje_ ;)

Co do rozjezdzania firmware: wklad dla PIC'a zajmuje pare KB. Gra i tak bedzie ladowac grafike do flasha PIC'a. Sprobujcie wiec pomyslec o firmware jako o binarnym dodatku do gry takim samym jak grafika. Gra odpalona z dyskietki sprawdza czy identyfikator wsadu w carcie sie zgadza sie z jej i jesli nie, laduje wlasny plik binarny.
A jesli wsadzicie tego samego carta do Atari bez dyskietki to gra zapisana w EPROM'ie zrobi taka sama akcje i nawet nie zauwazycie ze cos zostalo przeladowane bo potrwa to 1-2 sekundy.
Da sie to zrobic, przynajmniej teraz nie widze przeciwwskazan.

W najblizszym czasie musze sie zaangazowac czasowo w przygotowania do PGA w Poznaniu, na ktorym robimy stoisko retro-gier z wieloma atrakcjami. Ale prace nad Tomkiem trwają.
Dwa dni temu otrzymalem od Sebana schemat w ktorym uzupelnił mój pierwotny prototyp o konieczne poprawki, min dodal EPROM/FLASH na gre Atari (choc moze go nie byc).
Wymyslilem, ze sterowanie bankami tego epromu nie bedzie wymagalo zadnych komorek ze strony $D5. Atari bedzie to robic wydając rozkaz PIC'owi, ktory steruje kilkoma nogami adresowymi pamieci.

Heh, ja bym sie cieszyl z takiego wysypu :P Bo to by znaczylo ze pomysl chwycil i ludzie wzieli sie za nauke asm PIC'a.
Jesli pojawią sie rozne wersje rdzenia to zrobi sie repozytorium na stronie z dokladnymi opisami rozkazow i juz. Programista Atari bedzie mial wiekszy wybor.

Myslalem tez nad pewnym konceptem na przyszlosc: emulator 6502 na PIC'u :) Chodzilo mi o to zeby osoby nie znające asm PIC'a mogly z marszu tworzyc wlasne procedury obslugi rozkazow dla PIC'a (tak jakby w cartridgu siedzial szybki wirtualny 6502). Specjalny kompilator tlumaczylby kod asm 6502 na asm PIC'a i taka procke podpinaloby sie pod obsluge konkretnego rozkazu.

Ale nie wiem czy to ma sens... Z jednej strony pozwoliloby developowac firmware osobom bez specjalnego drogiego (150zl) devkita czy programatora Microchipa (i koniecznego MPLAB IDE).  Ale z drugiej strony - byloby to malo wydajne.
Atari moze przesunac bitowo bajt o 1 bit, a PIC w ma rozkaz do przesuwania 16-bitowego slowa o dowolną ilosc bitow w jednym takcie. Atari ma 3 8-bitowe rejestry A,X,Y, a PIC 16 rejestrow roboczych 16-bitowych przy adresowaniu indexowym obejmujace całą pamięć RAM. Jak sie przeczyta liste takich rozkazow PIC'a to wystarcza zeby nabrac checi do ich uzywania :)
Oczywiscie, moznaby rozszerzyc ten asm Atari o nowe pseudorozkazy wykorzystujące mozliwosci PIC'a, czy nawet "pseudorejestry" (X0, X1, X2 ... X15), ale przeciez wtedy szybko doszlibysmy do... asemblera PIC'a :)
Na razie przestalem o tym myslec.

To zależy od podejścia - wiesz, napisanie czegoś od zera wymaga sporo czasu i nauki - zanim w ogóle taki rdzeń ruszy. O wiele prościej jest przerabiać i rozszerzać. Zwłaszcza jak ktoś chciałby tylko dopisać jakąś funkcję albo zastąpić ją inną - najczęstszy przypadek.

A co my mówimy o rdzeniach, jak produkcji na istniejący nie ma :)

Ostatnio edytowany przez wieczor (2012-09-26 10:04:29)

> nie dojdzie do sytuacji jak xxl vs VBXE

nie ma sytuacji xxl vs VBXE

moze chodzi o przeladowywanie wlasnego rdzenia w vbxe? chcialbym tylko zaznaczyc ze sytuacja jest zupelnie inna. w tomku8 mozesz sobie przeladowac zrdzen dla wlasnej gry i przy kolejnym boot atari bedzie dzialac normalnie. chcesz napisac mnozenie na tomku zaden problem piszesz mnozenie, ale jesli chcesz napisac mnozenie na VBXE to musisz napisac mnozenie oraz emulacje gtia :)

Ale sparta bardzo mi się przydaje do stricte zadań rozrywkowych. Wygoda odpalania playera i słuchanie muzyczek pod systeme a także kopiowania ich po kablu na spartową partycję jest nie do podważenia.