ma c'è ancora qualcuno che lo usa Arduino?

C'è molto di meglio a molto meno, l'anno scorso mi ero messo a sviluppare in C\C++ driver di comunicazione custom per la mia STM32-F3 Discovery, leggete le specifiche e il divario sarà presto spiegato.

Concordo con legacy sul disappunto.

Sentendolo all'inizio sembrava una persona intelligente che proponeva qualcosa di intelligente, poi però arrivando al sodo si è sempre dimostrato solo uno showman, facendosi del tutto rivalutare, dato che non l'ho mai visto nè sentito spiegare SERIAMENTE come utilizzare SERIAMENTE la periferica.

Bah. Arduino grazie a lui è + una "moda" che una vera idea.

Esiste il deltaplano e il volo tramite paramotore (o il connubio dei 2), sicuramente molto + economici e con un discreto numero di appassionati.

Io avrei una certa cosa per la testa, ma non so se la scimmia qui è già andata via... 

Ok, ho scoperto di essere stato MOLTO fortunato.

Ho risolto per l'audio sebbene non sia di ottima fattura...accidenti...

Cmq sono in grado di gestire gli effetti sonori.

Ci studio un po' meglio e vi aggiorno...

Lo lascio perdere per un po' si, ed ecco che fioccano novità!

Finalmente ho capito come gestire i Coin e un pochino il Fix Layer...ora diciamo che la gestione tipica della giocata da bar comincia a potersi dire decente.


Per ora vorrei cercare di gestire lo Z80...ma qui son dolori, poi penso tornerò al BS.

In merito allo Z80...qualcuno ha un po' di esperienza?

ragazzi io vi seguo e approfitto del tempo libero per studicchiare e leggere voi, documentazione scovata in rete o qualsiasi cosa possa essere utile: non pensiate abbia mollato in alcun modo 

x legacy: come agirei? programmaticamente parlando io butterei nelle bank ad indirizzi che mi devo segnare da qualche parte, le tiles da prendere x costituire gli sprites. In fondo se il grosso sono proprio le mattonelle grafiche...fare switch e andarle a prendere per popolare a runtime la grafica mi sembra un buon modo di fare.
Come?...ci sto lavorando...è dura come ben sai.

intanto è saltata fuori una nuova lib free ASSEMBLY-only : https://github.com/freem/freemlib-neogeo/tree/master/doc

Adesso mi fiondo a leggere se magari posso rubacchiare qualcosa. D'altronde un piccolo assembly inline nel mio C per qualche effetto (tipo l'inserimento di un gettone) non sarebbe male!

Mamma mia mi volto un attimo e guarda che popò di risposte!

Ovviamente e come sempre ringrazio tutti per le brillanti osservazioni fatte.
Oddio sono certo che mi dimenticherò di qualcosa...
ma fortunosamente esiste l'edit e i messaggi sono gratuiti 


Purtroppo ammetto di non aver presentato il problema iniziale con la verità che avrebbe necessitato, questo perchè
io per primo non sospettavo minimamente di come stessero in realtà le cose.

Sorry guys

Cmq vorrei fare un po' di chiarezza se posso:

- Avevo cmq previsto il timing del bankswitch, che dovrebbe allinearsi grossomodo con il V_BLANK: avrei
ovviamente appianato al volo, l'importante era il risultato!
Il mio tentativo è stato fallimentare non tanto per il fatto che non avevo "atteso" lo switch, ma semplicemente
perchè NON SI PUO' con un modulo base A di PROM e una Banca sola.
Si "switcha" solo la banca, per cui è la seconda PROM che andrebbe presa in considerazione.

- E' vero, esistono rom Mame Neo Geo che testimoniano dimensioni di file PROM maggiori ma questo perchè
nella lunga storia Neo Geo (vi ricordo che la console è la più longeva al mondo, nata alla fine degli anni 80
e morta definitivamente nel 2005 o giù di lì...scusate se è poco!) hanno cercato ad un certo punto di ottimizzare
l'hardware delle cartucce, così è stato creato l'SMA, ossia una sorta di "porta" per delle memorie SD, così lo
stoccaggio dei dati per il 68k non avrebbe + dovuto sottostare ai soliti paletti, cmq solo alcuni titoli
vantano del sistema SMA, tipo Metal Slug 3 alcune release e pochi altri titoli.
Se fossi un figo in elettronica o potessi coprire legacy d'oro e di circuiti fighi\introvabili lo noleggerei per un
anno per crearmi una toolchain che simuli detto chip Scherzo cmq, il divertimento per me è anche apprendere,
per cui sono stato un po' gambizzato dalle ultime news ma sono soddisfatto di aver scoperto cose nuove.

- ...tornando a noi...è vero quindi che esistono diversi tipi di cartucce. Dipende dai produttori, dipende da quando magari avrebbero
potuto costare in quel dato periodo storico alcuni componenti rispetto ad altri...e così via.
Vi invito a riflettere sul fatto che il Neo Geo è un sistema prima di tutto Arcade e secondariamente una console.
Neo Geo è forse la forma più evoluta di STANDARDIZZAZIONE per sistemi da sala giochi.
Avete mai visto le pcb dei giochi <> "Neo Geo"? Ecco ci siamo capiti.
Pensate che esistono case di sviluppo che TUTTORA vendono giochi Neo Geo (fatevi un giro sul tubo se vi va, Fast Striker,
Gunlord - spudorato clone di Turrican, Knight's Chance....) e si sono create il loro layout per le cartucce
e le plastiche delle shell per ovviare a ripercussioni giuridiche da parte di SNK.
Questi signori dimostrano che alla fine per raggiungere un'obiettivo ci sono infinite vie...io devo trovare
semplicemente la mia (i said cotica...i know...)

- Attenzione. Se aprite un file zippato che rappresenta un gioco per Neo Geo da infilare nella rom folder del Mame
per gustarvela, non è che tutti i files sono uguali:

            pippo-c1.c1 and pippo-c2.c2 (C ROM pair, sprite graphics, qui si ha fino a 128 megabit...)
            pippo-m1.m1 (Z80 code)
            pippo-p1.p1 (68k code...qui è dove stiamo lavorando noi attualmente...)
            pippo-s1.s1 (S ROM: fix graphics)
            pippo-v1.v1 (V ROM: Sonoro...altro cinema....ci penserò later...)


EDIT:

Sapevo mi sarebbe sfuggito qualcosa, ed eccomi qua:

- Un'osservazione piuttosto acuta di Mauro è stata: beh il codice non può pesare poi così tanto, sta PROM come farà mai a riempirsi?
Te lo dico io. Il grosso del peso è il mapper delle tiles grafiche che faccio io.
Sapete perfettamente che ogni sprite che riempie i frame occupano memoria. Benissimo.
Detti sprite sono suddivisi in tiles da 8x8 pixel. Quindi ovviamente ogni sprite, è in realtà una concatena di tiles che vanno quindi gestite
insieme, specie per esempio per i personaggi animati.

Provate ad immaginare tutte le coordinate che regolamentano detti sprite e le loro tiles, ed avete in mano il bandolo della matassa.
Il maps.o appena uno si mette ad esagerare con la grafica (come faccio io) sale come una mina.

Non ditemi di ridurre la grandezza dei miei sprite o di sacrificare le animazioni perchè non lo faccio, piuttosto smetto di lavorare a questo progetto, è una questione di principio!!!

            

ri - Buona camicia a tutti