NSA - Non Solo Amiga
SOFTWARE => Linguaggi di programmazione e scripting => Topic aperto da: Black.Jack - 18 Ottobre 2014, 11:16:43
-
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!
-
Beh dimostri una preparazione notevole, ti ho mandato un MP.
Tra parentesi se siete di Milano se ne può parlare davanti un'ottimo caffè ;)
-
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
-
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
-
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!
-
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.
-
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 ;)
-
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 ;)
-
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:
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...
-
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:
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).
-
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...):
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... ;)
???
-
@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. :D Bisogna solo stare attenti a non mettere troppemila app 'che ti esplode la ROM size.
-
@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.
-
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? :o
-
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:
//settiamo la banca..
char * const MY_BANKNUM = (char * const )(0x2ffff0);
extern char CBANK;
dopodichè ho associato alla pressione di un bottone del Joystick:
if(p1&JOY_C) {
CBANK = '1';
*MY_BANKNUM = CBANK;
prepareStep();
STAGE1();
break;
}
e di un'altro:
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!!!).
-
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.
-
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. 8)
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. :'( ).
-
magari per risparmiare qualche dollaro, avranno usato un 68000 modificato con meno pin sul package?
-
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.
-
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 :)
-
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à. :P
-
Ma è roba che AVR può permettersi tranquillamente di foraggiare. Il panorama 68K, invece, è in mano a pochi hobbisti, per cui si muove molto lentamente.
-
Tipico del mondo GNU. ;D
-
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... ;D
-
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... ;D
Siamo in due: makefile et similia sono cose che non riesco a digerire. Dopo pochi secondi di visione... fuggo.
-
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!
-
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.
-
Certo. Come pensi che funzionasse fino a una ventina d'anni fa? ;D
-
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.
-
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.
-
Senz'altro, ma sta sempre a te scegliere come modellare il prototipo. Se non usi costrutti di livello molto elevato, ti verrà più facile la traduzione. ;)
Anche perché, ripeto, con un 68K a 12,5Mhz non puoi farci granché a livello di i.a..
-
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 ;)
-
Non ho ancora in canna abbastanza info per potermi decidere su quello che hai chiesto.
Per ora escludo di operare tutto in ASM, assolutamente ingestibile e complesso per me.
Il mio "trend" attuale è quello di riuscire a dare del "tu" al bios o almeno cercare di sgraffignare qualche comando in +, ma gestire le banche con una toolchain c.
-
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?
-
Z80Fan. ;D
C'ho lavorato a fine anni '80, per cui è passato un po' di tempo, ma qualcosa me la ricordo ancora.
-
Presente. :D
Però non so come è incastrato lo Z80 nell'architettura del Neo Geo; parlando solo della CPU la conosco bene, sia a livello di ISA che di implementazione hardware.
-
Se non ricordo male serve per gestire l'audio.
-
Se non ricordo male serve per gestire l'audio.
Si, lo Z80 si preoccupa interamente solo dell'audio.
Però la conoscenza termina qui. ;D
-
idem. :P
-
Beh che ci crediate o no, sono riuscito già a far fare un paio di peti al mio progetto.
Fondamentalmente cmq nulla di chè, ho chiamato in assembly inline il jingle preesistente che si può sentire durante lo standard boot della macchina, ossia il comando numero 02 come spiegato qui:
https://wiki.neogeodev.org/index.php?title=68k/Z80_communication (https://wiki.neogeodev.org/index.php?title=68k/Z80_communication)
Successivamente ho rispolverato un progetto di un ragazzo francese che si trova qui:
http://www.pascalorama.com/article.php?news=32&cat=23 (http://www.pascalorama.com/article.php?news=32&cat=23)
All'interno tuttavia a parte la classica rom di puzzle de pon rieditata per far girare il progetto in Mame c'è poco nulla.
Ho preso direttamente il file .bin che contiene i file audio ritoccati (non è spiegato come!) e ho messo il comando sempre via Assembly inline, e funziona nel mio progetto!
Tutto ciò è incoraggiante, solitamente impiego molto di più per qualche risultato tangibile...tuttavia c'è poco nulla in giro su come sfruttare lo Z80 per l'audio.
Somiglia al modo in cui il Sega MegaDrive usa lo stesso Chip - sempre per scopi inerenti al sonoro - ma è difficile immaginare come sia stato gestito il file wav...
-
@z80fan
una cosa interessante e' forse il chip audio Yamaha YM2610, di cui ho qui un esemplare che non ho mai usato
che ne dici ?
Non conosco il suo funzionamento, quindi non ti so dare pareri...
-
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...