Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.
Post - Black.Jack
16
« il: 19 Ottobre 2014, 15:05:45 »
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? 
17
« il: 18 Ottobre 2014, 23:44:29 »
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...  
18
« il: 18 Ottobre 2014, 22:24:48 »
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_PageNon 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_ENDAllego 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...
19
« il: 18 Ottobre 2014, 21:31:00 »
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
20
« il: 18 Ottobre 2014, 20:19:10 »
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
21
« il: 18 Ottobre 2014, 15:27:12 »
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!
22
« il: 18 Ottobre 2014, 15:24:39 »
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
23
« il: 18 Ottobre 2014, 14:46:26 »
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
24
« il: 18 Ottobre 2014, 13:52:28 »
Beh dimostri una preparazione notevole, ti ho mandato un MP. Tra parentesi se siete di Milano se ne può parlare davanti un'ottimo caffè
25
« il: 18 Ottobre 2014, 11:18:53 »
grazie ragazzi per la calorosa accoglienza mmm "ASM Lover"...cool! 
26
« il: 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!
27
« il: 18 Ottobre 2014, 10:46:39 »
Salve ragazzi, mi chiamo Marco, 36 anni, da Milano e come facilmente avrete intuito sono un fan della retrotecnologia oltre che modesto appassionato di programmazione sebbene in realtà il mio percorso di studi è stato artistico Perchè mi sono registrato? Perchè principalmente ho, devo, voglio risolvere un piccolo grande problema con Assembly... Tuttavia guardando il sito in generale l'ho trovato gradevole e molto interessante dato che tocca tanti argomenti che mi appassionano molto come la robotica. Per cui mi fiondo ad aprire un thread nella sezione software, spero vivamente che questa skillatissima community riesca a farmi uscire dall'empasse. grazie anticipatamente a tutti, Marco\Black Jack
|
Visualizza post