Z racji że przez ładnych parę lat (straconych) w niebycie nadrabiam stracony czas, czytam i chłonę Doczytałem się wynalazków typu Tomek-8 Dwa razy pytałem co z tym projektem, i nikt nie odpowiedział, stąd nowy wątek i zapytanie co z tym projektem?
Nosty, który jest autorem tego rozwiązania odnalazł się na scenie IndieGames, zatrzymał się nad projektowaniem frameworka dla Tomka, pisaniem jakiegoś API, na czym stanął, korzysta z gotowych rozwiązań dla PC, które zachwyciły go łatwością tworzenia i projektowania gier, w wolnym czasie zwiedza świat, jego pasją jest jazda na rolkach
@tebe - cały ja. Dzięki, lepiej bym tego nie ujął ;)
@rosomak - dzięki za zainteresowanie. Projekt faktycznie leży i czeka na wolne moce przerobowe. Tomek-8 istnieje w 3 działających prototypach. API o którym pisze tebe faktycznie jest w 70-80% skończone w podstawowej wersji (wyszedłem z założenia, że nikomu nie będzie chciało się uczyć programować kontrolery PIC, więc chciałem, aby programista po stronie Atari po prostu miał proste zestaw rozkazów, którymi zleca wykonanie obliczeń, generuje i ustawia duszki itd.). Hardware też wymaga lekkiego przeprojektowania (przejście z układów cyfrowych na gala) i poprawek przed wdrożeniem produkcji.
@nosty - życzę Ci czasu do skończenia projektu. W moich oczach to byłoby bardzo duże COŚ dla Atarowego świata, powiedzmy za kartem za 100 zł możnaby pokazać światu produkcje o dwa poziomy wyżej niż do tej pory I to bez lutownicy, właśnie to że nie trzeba lutować i cena byłaby przystępna powinno wpłynąć na skłonność do zakupu, a potem do programowania itd
A tak w ogóle, to jakie dopałki poza stacją mają do dyspozycji commodorowcy, i czy do wlutowania czy bez ?
bitmapa wyswietlana przez antic a generowana przez kardrydz. bez prucia atari :-) takie kreatywne rozwiniecie idei koproca, ciekawy wspomagacz byl tez w karcie z jakas klasyczna gra do atari.
na konsolach jest to norma , chyba każdy może upchnąć do Carta co tam sobie wymyśli ,ale przy takim rozwiązaniu rosną koszta ... fajnie jak byłby to jakiś standard montowany w cartridge w który wkładało by się kartę sd z grą pisaną pod ów rozszerzenie -jeden zakup do wielu gier -co sądzicie ?
@Mono, @xxl, tak Super Charger to był cart, który natchnął mnie do idei zewnętrzengo "koproca" w cartridgu. W SC był jeden chip wykonujący mnożenie (chyba integer). Wykorzystywała go wyłącznie jedna gra, Assalut Force. Co ciekawe, parę lat temu powstała wersja tej gry zoptymalizowana tak, że działa bez carta ;) Nie jestem pewny, ale chyba autorstwa Fandala. @atariki50 - masz rację. Oczywiście, bezapelacyjnie warto :)
Don't rule out using the UNO Cart for the same principles. This uses an STM32F4 rather than a Microchip microprocessor but is effectively a bus-sniffer.
Last year I'd taken the memory dump of the VRAM area of a Gameboy game (Pokemon) and implemented an extension to the existing firmware to convert the tilemap / tile defintions to the Atari screen layout which is then fed to Antic utilising the way DMA works.
coś takiego jak ten UNO Cart można zrobić bez UNO Cart, korzystając z dodatkowej pamięci (PORTB) i modyfikując w locie zestawy znaków, albo bitmapę, jeśli podejść do tego z głową
przykład z paczki madpascal\examples\extmem\vscrol_4.pas
bitmapa znajduje się w pamięci dodatkowej (PORTB), pobierana jest tylko 1 linia takiej bitmapy i wstawiana pod odpowiedni adres na podstawie DISPLAY LIST-y (DL) ANTIC-a, scroll realizowany jest tylko poprzez modyfikację tejże DL
wyobraźcie sobie kartkę zwiniętą w rulon, scroll w dół oznacza że ostatnia linia DL przechodzi na pozycję pierwszą, pozostałe linie w dół o 1 pozycję i tak w pętli, scroll w górę odwrotnie, czyli jest to 'ring buffer' ->link<-
zużywamy tylko 8KB pamięci (kopiujemy tylko 40 bajtów bitmapy + 400 bajtów DL dla 200 adresów linii obrazu, zamiast 8KB), podobnie można zrealizować scrolla poziomego
Tomek-8 / UNO is not for replicating A8 feature but extending. Hence with the GB VRAM emulation we add the tilemapping and upto 40 8x8 sprites for free and make them very easy to control, e.g. through the OAM registers.
As I saw Tomek-8, this provided a way of defining larger 'sprites', again taking the burden of the screen processing away from the A8.
But then these cartridges are not limited there, it could handle a vector or filled polygon 3D engine and manage object / camera movement / animation etc with little direction from the A8. It could target gr.7 or 10 or antic E or 4.
A combination of the gb-disasm and z80compiler projects can help there.
Bank switch the $A000-$BFFF area for code/data but as long as the 6502 writes to the VRAM area in the same way then we should see the same output.
I wouldn't think the current micro on the cartridge is up to providing a complete z80/gb interpreter as it very time critical on turning around the memory requests for the screen, hence I have it busy during the vblank rendering the framebuffer.
If the sources for the Tomek-8 demos were available they are probably easily ported to the ARM.
