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

[Black.Jack]

• 

Ciao a tutti,

PREMESSA:
Non sono riuscito ad accostare alcun thread particolare alla mia discussione per cui chiedo ai moderatori di spostare pure il mio intervento nella sezione che decideranno essere quella più consona.

VENIAMO A NOI:
Ho un grosso problema, attualmente sto sviluppando un gioco per il mitico mostro dell'SNK tramite una toolchain free basata su 68k.

Tutto funziona tramite un uso moderato del linguaggio C, e attualmente sto sfruttando il Mame per testare il mio videogame.

Ma ho un grosso problema, legato al BankSwitching della memoria, il quale necessita molto probabilmente una buona dose di Assembly.
Prima di scendere in dettagli vorrei sapere se tra di voi esiste qualcuno che abbia voglia di aiutarmi ad uscirne ma sopratutto abbia buone\ottime capacità in Assembly.

Grossomodo essendo il mitico Motorola 68000 presente in ogni dove nel retrogaming (MegaDrive, Amiga, Neo Geo...), se ci fosse tra voi chi già sviluppa in Assembly per Amiga sarebbe un ottimo candidato.

Ovviamente prenderei la palla al balzo per formare me stesso e un domani, cercare di sviluppare qualcosa per Amiga, altra piattaforma che adoro.

Sicuramente aprirò un posto per il mio Amy 1200 con ppc che purtroppo soffre di problemi di ventilazione...

Incrocio le dita.

Grazie anticipatamente!

[Black.Jack]

• 

Beh dimostri una preparazione notevole, ti ho mandato un MP.

Tra parentesi se siete di Milano se ne può parlare davanti un'ottimo caffè 

[Black.Jack]

• 

ok, sarò un po' + specifico, sinceramente la mia non credo sia una richiesta di collaborazione su un progetto, ma prettamente come detto all'inizio una richiesta di aiuto per uscire da una situazione che richiede delle conoscenze che non posseggo e non riesco ad ottenere con le mie sole forze e il web.

Tutto questo spero possa portare quindi alla risoluzione di un singolo problema, che mi permetta poi di proseguire e basta.

Quanto tempo possa portare via questa soluzione non lo so, dato che non ne conosco esattamente l'entità, però quello che posso dare è la mia massima serietà, sono convinto che il tempo speso per qualcosa è tempo non torna indietro e dev'essere valorizzato con l'impegno all'apprendimento ed all'autoformazione.

La toolchain M68k che sto usando è questa:

gcc -v
Using builtin specs.
gcc version 2.95.2 19991024 (release)


Il mio problema come detto riguarda il bankswitching, ossia la possibilità di sfruttare memorie ROM in latching per le ipotetiche cartucce, e bisogna gestirlo anche con Assembly.

Non obbligo nessuno ad aiutarmi, vedo che hai già parecchie cose in corso, non ti preoccupare di dirmi di no se ritieni che la cosa possa toglierti eccessive energie per quello che ti interessa di più.


grazie

Marco

[Black.Jack]

• 

io temo sia proprio qualcosa di simile all'ultimo caso che citi.

Ho contattato la persona che si occupa dei Bios Neo Geo, il mitico Razoola, il quale però purtroppo non programma in C.
Tuttavia mi ha spiegato che quello che sta succedendo è questo:

attualmente la mia toolchain, per com'è impostata, gestisce l'ipotetica memoria P ROM da 1 mega.

Nei casi gli sviluppatori SNK abbisognassero di + memoria, non dovevano fare altro che aggiungere altri chip da 1 mega (fino a 4 mi pare), ma come potevano spiegarlo al povero Neo Geo?

Beh, ci pensava il bankswitching! E come?
Beh cito direttamente il mitico Raz:

Changing banks however on the hardware side is very easy if you are using the standard neogeo cart hardware. The P ROM bank is from 0x200000 – 0x2FFFFF, bank 0 is default.
 
You write the bank number (word size) you require to 0x2FFFF0, for normal hardware 4 banks are possible (0 to 3). Once you swap the bank you need to read the address to confirm the bank has changed (something like https://wiki.neogeodev.org/index.php?title=Cartridge_self-checking). This means 0x2FFFF0 in each data bank must contain its bank number.

Preferirei parlarne a voce, se qualcuno fosse interessato può darmi il suo contatto e orario in cui posso disturbarlo per fare 2 chiacchiere sull'argomento.

grazie

[Black.Jack]

• 

x legacy: sul tuo ultimo intervento non ti saprei dire, so per che esistono diverse cartucce dove la SNK aveva totalmente abbandonato la PROM e aveva lasciato posto ad uno slot con SD CARD, mi pare per esempio Metal Slug 3 abbia un sistema simile...

Se hai persone di riferimento che possono darmi una mano ti dispiacerebbe girarmi il loro contatto?
Te ne sarei infinitamente grato!

[cdimauro]

• 

Ho lavorato per anni con l'assembly 68K, ma francamente ho pochissimo tempo.

Prova a riportare i tuoi problemi qui, in dettaglio, e se avrò la possibilità cercherò di aiutarmi, ma non posso prometterti nulla di sicuro.

[Black.Jack]

• 

Ho lavorato per anni con l'assembly 68K

  Mio eroe....

Prova a riportare i tuoi problemi qui, in dettaglio, e se avrò la possibilità cercherò di aiutarmi, ma non posso prometterti nulla di sicuro.

Guarda il problema è quello spiegato sopra, bisogna capire come creare il bankswitching via software. Posso passare i file che uso io, però ho bisogno di essere seguito un minimo, proprio perchè non sapendo dove mettere le mani posso spiegare spannometricamente dove sono i files e come ho proceduto, però siete tutti troppo presi mi sa.

L'ideale sarebbe che io inviassi un paio di file, quelli che ritengo importanti: per esempio il linker Map e l'ASM per la costituzione della cartuccia Neo Geo...poi ne potremmo discutere anche verbalmente, max disponibilità....

Ovviamente non pretendo assolutamente soluzioni immediate, ho tutta la pazienza, però temo, ripeto, che siate attualmente già stra-stra impegnati, vedete voi io sono qui 

[Black.Jack]

• 

Ok allego i file richiesti.

I crt0 sono 2, uno ovviamente include l'altro...

neocart2.x è il file map del linker e poi ho aggiunto il Makefile.

in pratica dovrei riuscire a fare sdoppiare il dev_p1.rom...

Avevo provato a modificare dei valori del neocart2.x per ottenere un file dev_p1.rom + grande senza intoppi e ci sono riuscito, solo che poi ovviamente ignorando ogni tipo di dinamica bankswitch mi son beccato errore dal Mame.

In teoria se avete letto quel che dice Raz bisognerebbe gestire per ogni prom in un dato settore, il numero della bank.
Poi non so se è sufficiente quello...e non so nemmeno dove metterlo e come...

Insomma sono in alto mare.

Per quanto riguarda la creazione di una BSP, non mi permetto di dire nulla perchè sono assolutamente digiuno, però non ne ho mai sentito parlare per Neo Geo...

NB: questa versione non compila correttamente ma è molto simile a quella usata da me per ottenere le demo visibili sul tubo. Però qui ci sono le note commentate delle cavolate che ho cercato di fare...

Per ogni appunto o domanda sono qui...

grazie 

[Black.Jack]

• 

Si, quella parte inerente la memoria ho cercato di modificarla per ottenere una compilazione corretta dell'oversize della PROM senza andare a sovrascrivere le altre regioni, mi son reso conto presto che non era la strada giusta....

Effettivamente ho cercato di seguire il codice di quello che viene dopo ma è da fuori di testa, anche io l'ho presa per partito preso e basta...probabilmente un domani con + dimestichezza sta roba riuscirò a commentarla o bonificarla parecchio, chissà.

Le domande che fai sono troppo specifiche, preferirei prendessi il mio stesso ambiente di sviluppo a questo punto per vedere chiaramente come stanno le cose.

Io ho iniziato scaricando l'ambiente dal sito di questo ragazzo canadese molto simpatico (io sto realizzando la versione "X" del suo gioco...):

http://sebastianmihai.com/main.php?t=22

...scarica il "complete dev kit", a disposizione per il settaggio, se ci son riuscito io cmq... .

A questo DevKit ho aggiunto una libreria scritta da un francese per gestire comodamente la grafica, se ci fosse bisogno posso procurare il link...adesso non ce l'ho sottomano, cmq si chiama "DatLib" ed è facilmente visibile dal Makefile.

Aggiungo la wiki ufficiale del Neo Geo:

https://wiki.neogeodev.org/index.php?title=Main_Page

Non perchè non voglia rispondere, ribadisco, ma perchè io stesso non ho le risposte e tutti mi dirottano sempre a questa wiki, che purtroppo non riesco a digerire.

Questa è la zona che ho aggiunto al driver mame:

Codice: [Seleziona]

ROM_START( neothunx )
ROM_REGION( 0x100000, "maincpu", 0 )
ROM_LOAD( "dev_p1.rom", 0x000000, 0x100000, CRC(f67f9aee) SHA1(17677c7f08fe0265453a329e507cce0fcf2ab234) )
 
NEO_SFIX_128K( "202-s1.s1", CRC(cd19264f) SHA1(531be2305cd56d332fb7a53ab924214ade34a9e8) ) /* TC531000 */

NEO_BIOS_AUDIO_128K( "202-m1.m1", CRC(9c0291ea) SHA1(3fa67c62acba79be6b3a98cc1601e45569fa11ae) ) /* TC531001 */

ROM_REGION( 0x080000, "ymsnd", 0 )
ROM_LOAD( "202-v1.v1", 0x000000, 0x080000, CRC(debeb8fb) SHA1(49a3d3578c087f1a0050168571ef8d1b08c5dc05) ) /* TC534200 */

NO_DELTAT_REGION
ROM_REGION( 0x4000000, "sprites", 0 )
ROM_LOAD( "char.bin", 0x000000, 0x4000000, CRC(2878f3aa) SHA1(043acd05b243d25b49df004aad72f5abcdcc5391) )
ROM_END
Allego i comandi in formato .txt che ho pazientemente copiato da shell per gli eseguibili che servono a manipolare i file...

Grazie tante, finalmente sento di aver ripreso a sperare in questo progetto, che aveva preso una battuta d'arresto preoccupante...

[TheKaneB]

• 

Non mi è mai capitato di programmare roba con bank-switching. Sul Nintendo DS potevi usare l'overlay del codice, ma non è la stessa cosa, lì si tratta di caricare e scaricare pezzi di codice via software. Che io sappia, quando si lavora con i giochi a basso livello si preferisce sempre switchare manualmente la memoria, specie se hai constraint di tempo molto stretti (es: DMA, H-Blank e V-Blank interrupt, ecc...) e vuoi avere un comportamento deterministico e facilmente prevedibile.

Quello che farei *io* è il seguente:

Se ho un memory layout a 2 segmenti, di RAM fissa e ROM bank-switched: copio il codice e i dati "comuni" nel primo segmento, metto i dati dei livelli negli altri banchi e faccio switching al caricamento del prossimo livello (es: 4 livelli per ogni banco x 4 banchi = 16 livelli di gioco).

Non conosco il memory layout del NeoGeo, nè l'assembly M68K per cui sono un po' tagliato fuori.
Comunque a giudicare da quello che hai scritto prima:

You write the bank number (word size) you require to 0x2FFFF0, for normal hardware 4 banks are possible (0 to 3). Once you swap the bank you need to read the address to confirm the bank has changed (something like https://wiki.neogeodev.org/index.php?title=Cartridge_self-checking). This means 0x2FFFF0 in each data bank must contain its bank number.

cioè, se il controller che fa lo switch dei banchi è memory mapped, si può agire direttamente da C senza passare dall'ASM, in questo modo:

Codice: [Seleziona]

int *BANK_NUMBER = (int *)(0x2ffff0);
bool switch(int bank) {
  *BANK_NUMBER = bank;
  // Double check: returns "true" when switching; false on error
  return (*BANK_NUMBER == bank)
}

// ....

// Qui mi serve fare switching:
if (switch(3)) {
  // Sono nel banco 3, carico i dati che mi servono
} else {
  // Si è verificato un errore, non riesco a cambiare banco
}

Unico dubbio che mi viene è quel "word size". Non mi è chiaro cosa intenda per "word". Se si trattasse di intero a 16 bit, allora devi sostituire quel "int *" con un "short *". Invece per il tipo "bool" mi sa che GCC 2.95 non lo supporta (è standard ANSI C 99 o successivo). In tal caso modifica la funzione per farti restituire un intero ( 1 = true , 0 = false).

[Black.Jack]

• 

cari tutti....avete imbandito una tavola vuota.

Adesso mi avete dato nuovi spunti, strategie e di questo vi ringrazio.

Controllare lo switch da C....beh effettivamente il V_Blank interrupt è sempre presente nei miei pensieri durante ogni loop per i frame d'animazione, per cui sempre se non ho capito male, dovrei rimaneggiare il codice per:

- gestire la lettura "a blocchi": io devo ricordarmi bene dove sono allocate variabile e codice per poter dinamicamente chiedere alla cpu di saltare al banco corretto. Gestire eventuali rallentamenti causerebbe "l'aggiustamento" del codice spannometricamente, un po' come già faccio per il V_Blank e il numero di menate che metto a video...

- creare nella toolchain una doppia compilazione per l'OBJ dove appunto do un tot di roba alla ipotetica P-Rom1 e alla P-Rom2...etc,etc..(qui son sicuro che farò casini inenarrabili...)


il tutto ovviamente lasciando il linker com'è, perchè fa riferimento all'hardware della macchina, quindi non avrebbe senso cambiarlo.

In tutto ciò però...non mi è ancora chiaro, come faccio a mettere i valori nel giusto settore delle diverse banks (...o prom che dir si voglia...).

Precisamente (ennesimo stralcio di mail che mi sono arrivate da anime pie che mi han dato un po' di retta...):

Codice: [Seleziona]

If you want to change P rom bank all you need is;
 
move.b #$00, $2FFFF0
 
the above will set to bank 0
 
move.b #$01, $2FFFF0
 
the above will set to bank 1
 
Its very simple. Once you change the bank you simply read some expected data at an address inside the bank and keep reading it until you receive the expected value. Once its there you know that bank has successfully changed

Se scrivo castronerie ditemelo...

 

[Z80Fan]

• 

@z80 fan
tu forse hai visto meglio il gameboy: questa faccenta ti e' capitata ? a me no, nella mia cartuccia avevo si l'MBC5 ma indirizzavo 32Kbyte, senza quindi dover cambiare banco.

No, mai capitato, ho fatto solo programmi piccoli.
Comunque anche io sono della stessa vostra idea di mettere le parti principali del gioco nella ROM comune, e mettere tutte le cose "opzionali" (inclusi i dati non immediati tipo i dati di gioco e la grafica che viene caricata a bisogno) nei bank; la cosa critica è mantenere le ISR nella ROM comune, per ovvi motivi.

secondo si può anche fare una cosa molto bovina, ovvero, dato che ogni bank e' un mondo isolato, in address collision (ovvero tutti i bank assumono di vedere lo stesso address space), allora li si può trattare come se fossero dei processi.

Questa è un'idea figherrima. Bisogna solo stare attenti a non mettere troppemila app 'che ti esplode la ROM size.

[TheKaneB]

• 

@legacy: sì, in questo modo hai anche codice diverso per ogni "livello", mentre come la pensavo io il codice era uno solo e cambiavano i dati. Ovviamente dipende tutto da come si realizza il gioco
Inoltre ci sono solo 4 banchi, se ho capito bene, quindi avrai 4 livelli soltanto, a meno che non infili manualmente un certo numero di livelli dentro ogni fileN.c, tenendo traccia degli stessi tramite la state machine che sarà già presente nel gioco.

[Black.Jack]

• 

No aspettate un'attimo, non esageriamo, un banco a stage?

Non so quanti giochi avrebbero prodotto lavorando in questo modo...
Le risorse vanno sharate tra i banchi ma non con questo criterio...

Io adesso sto cercando di implementare la logica del bankswitch dinamico via assegnazione pointer, però il mio problema ora è che se decido di compilare nel makefile separatamente 2 gruppi di file, ho dei problemi a livello di c.

Sinceramente non l'ho mai fatto e chiedo aiuto a voi...

Es, l'obj1 contiene n file ".o" che a loro volta sono semplici .h e .c
a questo punto nel makefile designo l'obj2 che seguirà la stessa sorte di obj1 ma al suo interno avrà solo pippo.c

Ovviamente in fase di compiling, ho errori a tutte le referenze di pippo.c che non  ci sono...

Come si ovvia al problema? Ammesso si possa....

Sto sbagliando tutto? 

[Black.Jack]

• 

Rieccomi sui vostri teleschermi...

Dopo una lauta merenda, ho fatto diverse prove.

Anzitutto sono contento perchè ho trovato il modo di risparmiare spazio e la mia PROM da "quasi un mega" è diventata 300 e rotti KB...il che non guasta.

Ciò mi ha permesso di tentare l'ultima idea bovina di legacy...poichè nel caso di risorse come mappe assembly sharate tra banchi, la cosa sarebbe stata irrealizzabile!!

Successivamente sono riuscito ad ottenere una nuova configurazione Mame che accetti il fatto che io gli stia dando 2 PROM, sebbene identiche (a lui non frega...), dopo un po' di tentativi è andato!
La conferma è che se levo la P2 il mame si siede.


Allorchè ho modificato il codice perchè avesse 2 istanze identiche se non per un particolare a video per poter distinguere "l'instradamento" del bankswitch...

ho aggiunto le istruzioni in un file header:

Codice: [Seleziona]

//settiamo la banca..
char * const MY_BANKNUM = (char * const )(0x2ffff0);
extern char CBANK;
dopodichè ho associato alla pressione di un bottone del Joystick:

                     

Codice: [Seleziona]

                    if(p1&JOY_C) {
  CBANK = '1';
*MY_BANKNUM =  CBANK;
prepareStep();
STAGE1();
break;
}
               e di un'altro:

            

Codice: [Seleziona]

if(p1&JOY_D) {
CBANK = '0';
*MY_BANKNUM =  CBANK;
prepareStep(); 
STAGE1();
break;
}
Così facendo avrei dovuto vedere uno stage con un dettaglio diverso dall'altro a seconda della scelta intrapresa....purtroppo però la variabile *MY_BANKNUM che mi stampo a schermo è sempre di valore 0000
Cambia solo il mio bravo CBANK che è 0048 oppure 0049...


Dai mezzo passo avanti l'ho fatto con la config almeno....


EDIT: attualmente sto vagliando bene il mio operato, sono convinto che in queste pagine ci sia già la soluzione, totale o parziale che sia, ma c'è...vi aggiorno appena ho novità (e non vedo l'ora di averne!!!).