Assembly & 68k Toolchain: come gestire la memoria del Neo Geo

[cdimauro]

• 

Ho finalmente avuto il tempo di smazzarmi tutto quello che avete scritto, e parte della documentazione. Come giustamente dicevano gli altri, non è tanto un problema di conoscere il 68K, quanto di capire come funziona il NeoGeo, quindi com'è organizzata la memoria e come funziona il chipset.

Sì, legacy: da $200000 a $2FFFFF hai 1MB di memoria a cui puoi mappare 4 diversi bank, da 0 a 3. La locazione per controllare il cambiamento di bank è $2FFFF0, ma il problema è che lo switch del banco di memoria non è immediato e bisogna aspettare un po' di tempo prima che si verifichi.

Per cui, BlackJack, sarà questo il motivo per cui il tuo codice non funziona correttamente. Come Antonio aveva già riportato prima, devi assicurarti che lo switch sia stato completato, prima di poter utilizzare i dati del banco. Questo si fa con la routine che Razola t'aveva indicato (e che Antonio ha quotato prima), ma il punto è che devi organizzare i banchi in maniera opportuna in modo da riconoscere quando hai finalmente il tuo nuovo banco operativo.

Per far questo, nel banco 0 devi assicurarti che ci sia scritto 0 a $2FFFF0, 1 per il banco 1, e così via. In realtà, poiché ogni banco occupa 1MB e puoi vederlo (e devi realizzarlo) come un file di 1MB, devi assicurarti che all'offset $FFFF0 nel file che contiene i dati dello specifico banco ci sia 0, 1, e così a seconda del banco.

Visto che vengono usati 2 tipi di ROM, magari utilizza quello A (fisso) per metterci del codice "di servizio", come ad esempio la routine che esegue lo switch del banco, che sarà comune per tutti i banchi  & livelli di gioco, e si assicura che il nuovo banco sia operativo prima di restituire il controllo al chiamante.

In questo modo puoi suddividere il codice dei vari livelli del tuo gioco in maniera opportuna, tenendo conto che potrai utilizzare soltanto 1MB alla volta per uno o più livelli.

Comunque è strano che si possa usare soltanto 1MB alla volta. Il 68000 può indirizzare 16MB in tutto (64MB con particolari trucchi, ma non è il tuo caso), e comunque ricordo che le ROM del MAME per il NeoGeo avevano anche file di 4MB ciascuno. Al momento non ho tempo per studiarmi il layout della memoria del NeoGeo, ma cerca di controllare bene come e dove vengono mappate le varie ROM, e vedrai riuscirai a tirare fuori un design più pulito del tuo gioco.

Ultima cosa, il compilatore GCC 2.95 genera codice scarsamente ottimizzato, come giustamente ha riportato legacy. Questo significa che se vuoi realizzare dei giochi col raster per degli effetti speciali, potresti non riuscirsi a causa della lentezza del codice generato. In questo caso si va di assembly, e te ne esci tranquillamente, magari soltanto per queste parti specifiche (il C, è innegabile, è troppo comodo).

OK, adesso devo prepararmi per andare a lavoro. Buon fortuna.

[cdimauro]

• 

Un altro paio di cose al volo, prima di correre a lavoro.

Questo, perche' penso che, siccome sono almeno 15 anni che siamo nell'era RISC,

E chi l'ha detto? CISC rulez.

allora bisogna anche adeguarsi, ed e' per questo motivo che, piuttosto che proseguire con quelle carriole che ho elencato prima, ho preferito ri-schedulare le priorità del mio tempo libero per buttarmi nei RISC, prima tappandomi il naso (sopratutto i RISC di tipo MIPS, di cui sono appassionato ma che sono veramente spacca ossa), poi ridisegnando la loro ISA sulle ceneri del 68k.

Il risultato e' tutto lavoro in corso, ovvero una ISA tutta nuova ibridata tra un MIPS di classe 1, ed un 68k ridotto all'osso.

Questa roba trova asilo nelle FPGA (di classe spartan3-500 almeno) e si programma molto bene in assembly, ed e' RISC pura, pero' umana, anche perche' e' una esigenza forte, dato che un C compiler per questa architettura non esiste, e me lo scordo di realizzarlo in poco tempo, ci vorranno anni per metterlo in piedi, e possibilmente senza passare da gcc & suoi amici, anche perche' io non aderisco alle linee guida di casa GNU, nemmeno un po'.

Che roba golosa. Ma ne hai parlato qui? Rilasciato le specifiche dell'ISA? Se non l'hai ancora fatto, perché non apri un thread? Così ne parliamo meglio (tempo permettendo. ).

[TheKaneB]

• 

magari per risparmiare qualche dollaro, avranno usato un 68000 modificato con meno pin sul package?

[cdimauro]

• 

Visto che vengono usati 2 tipi di ROM, magari utilizza quello A (fisso) per metterci del codice "di servizio"

secondo me "dipende"

all'inizio avevo parlato di una BSP, ovvero di codice di servizio, questa può anche stare in A, e ogni altra cosa (immagino cose come oggetti grafica/suono) in B, in questo modo si caricano all'occorrenza lasciando il codice eseguibile TUTTO in A, addirittura si può strutturare B in modo indicizzato, oppure meglio ancora far linkare tutti i suoi oggetti in un header, in questo modo ci si svincola dal dove ritoccare a mano quanto non saprebbe fare diversamente il linker

c'e' da capire come e' strutturato il gioco, quanto codice eseguibile c'e', se può stare tutto in A o se sconfina in B

Il codice in un gioco occupa decisamente poco. Specialmente su quel tipo di macchine e quel tipo di gioco. 128KB di codice per la ROM/A sono una quantità notevole, e dovrebbe poterci stare tutto.

Comunque è strano che si possa usare soltanto 1MB alla volta. Il 68000 può indirizzare 16MB in tutto

sul local bus lato CPU hai 24 bit lineari di address space, tipicamente da A23 ad A1, questi a loro volta condizionati dal sizing, tipicamente a 16bit ma indirizzabile anche al byte (sfruttando i segnali UDS, LDS, A1, ed AS per i cicli bus necessari), e volendo puoi anche usare FC + address, questo ti apre ben 8 subspaces, di cui uno per lo user, uno per il superuser, uno per eventuali cooprocessori (ha mai avuto senso?), e altri che non ho mai capito

Sì, avevo scritto che si potevano indirizzare fino a 64MB, usando proprio i Function Codes: user + supervisor = 1 extra bit, code fetch + data access = 1 extra bit.

ci sono vari trucchi

il punto e' che quella console e' di retaggio, ovvero mi sa tanto che hanno iniziato con un modello di memoria per le cartucce, la cosa andava bene, loro non hanno guardato al futuro, e ad un certo punto si sono trovati con … programmatori che volevano + ROM, a quel punto … la "pezza" hw e' stato usare il bank switching sfruttando i latch

lo dico a naso, mi sembra il classico caso in cui si cerca una pezza hw, difatti a me quella console non piace come design perche' rende le cose contorte

Credo che il bank switching fosse già previsto fin dall'inizio per il NeoGeo, perché è stato pensato per gestire giochi mostruosamente grandi. Ricordo, però, che il limite fosse di 330Mbit (41MB) inizialmente, mentre per gli ultimi giochi è stato portato a 1Gbit (128MB).


Comunque non ti vuoi proprio sbottonare sulla tua architetture, eh? Cattivone!!!

magari per risparmiare qualche dollaro, avranno usato un 68000 modificato con meno pin sul package?

Proprio per il NeoGeo, non credo, visto quanto costava e gli obiettivi che SNK s'era prefissa fin dall'inizio. Già alla commercializzazione le cartucce dei giochi costavano quasi quanto la console, e a volte la superavano.

[Black.Jack]

• 

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

[cdimauro]

• 

Nel mio gioco di macchine per Amiga, USA Racing (mai uscito), il mapper per le tile occupava 128KB e mappava uno schermo virtuale da 8192x65536.  E' stato poi ridotto a 64KB, ma soltanto perché per disegnare tutta quella grafica ci si metteva una vita. Le tile erano da 32x32 (a 32 colori), e ce n'erano 640.

Mi pare difficile pensare che serva così tanto spazio per fare qualcosa del genere su NeoGeo. Hai qualche altro dato sul tuo gioco, per quanto riguarda quest'aspetto?

@legacy: lascia perdere quelle cose, e dedicati alla CPU, che è molto più interessante. E apri presto il thread, che sbavo già.

[cdimauro]

• 

Ma è roba che AVR può permettersi tranquillamente di foraggiare. Il panorama 68K, invece, è in mano a pochi hobbisti, per cui si muove molto lentamente.

[cdimauro]

• 

Tipico del mondo GNU.

[Black.Jack]

• 

Io di tiles ne ho circa 60k...


Il motore di gestione delle tiles non l'ho fatto io ma non credo sia ulteriormente ottimizzabile, e se anche non lo fosse , non lo sarebbe a sufficienza da permettermi di ignorare tattiche come il bankswitching.

Adesso sto seriamente pensando a cosa fare con il mio linker.

Se potessi solo dire di non capirci un cavolo stapperei lo champagne...

[cdimauro]

• 

Io di tiles ne ho circa 60k...


Il motore di gestione delle tiles non l'ho fatto io ma non credo sia ulteriormente ottimizzabile, e se anche non lo fosse , non lo sarebbe a sufficienza da permettermi di ignorare tattiche come il bankswitching.

Il bankswitching col NeoGeo è praticamente scontato se vuoi farci qualcosa di non banale, quindi con un bel po' di grafica e sonoro.

Adesso sto seriamente pensando a cosa fare con il mio linker.

Se potessi solo dire di non capirci un cavolo stapperei lo champagne...

Siamo in due: makefile et similia sono cose che non riesco a digerire. Dopo pochi secondi di visione... fuggo.

[Black.Jack]

• 

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!

[cdimauro]

• 

In giochi del genere non c'è logica complessa, per cui si può benissimo procedere usando soltanto assembly 68K. Tra l'altro l'hardware del Neo Geo è molto più semplice da programmare rispetto a quello Amiga.

[cdimauro]

• 

Certo. Come pensi che funzionasse fino a una ventina d'anni fa?

[cdimauro]

• 

Puoi sempre scriverla e testarla velocemente per PC. Ad esempio con Python. E quando è funzionante, ti limiti a convertire il tutto in codice 68K.

Ma in ogni caso il processore del Neo Geo è a 12,5Mhz: non è che può calcolare i.a. per passare il test di Turing. E c'è pure tutta la grafica e il sonoro da gestire.

[cdimauro]

• 

Python lo usi per modellare, per fare esperimenti. Quando hai tutto funzionante poi lo traduci. All'epoca, invece, si sperimentava sempre in assembly, per cui i tempi di sviluppo erano biblici.