Visualizza post

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

Pagine: [1] 2
1
Non importa molto se hai voglia di usare hardware serio lo usi.

Il driver sorgente era nel cd in bundle e io l'ho modificato per sfruttare la stm via Eclipse CDT  ;)

Effettivamente "diamo la conoscenza a tutti" era uno dei buoni propositi della filosofia di Arduino, tuttavia diciamocelo chiaro:
se vuoi delle cose fatte in un certo modo devi soffrire per ottenerlo, non esistono scorciatoie.

Il wiring e Arduino dopo aver fatto blinkare i led e acceso la console out con il sensore di luminosità  possono essere accantonati facilmente, semplicemente perchè ti ritroveresti nel limbo del "vorrei ma non posso": ed eccoti senza le VERE nozioni che ti servirebbero per fare quello che ti viene in mente dopo esserti gasato a far finta di essere un ingegnere navigato.

Vorrei proprio conoscere la statistica di chi dopo aver giocherellato con qualche esperimento e aver esclamato "SI PUO' FARE" sia andato veramente avanti a fare qualcosa di concreto.

A riprova di ciò per dirne una, tutti i droni fatti con Arduino sono stati scartati dai più scaltri a favore dell'utilizzo della STM32F3, di fatto con progetti su Github ready-made per fare tutto quello che faceva prima il figlio di Banzi e molto altro e molto ma molto meglio.

Ma dai poi per fare qualcosina devi mettergli 200 shield, non se ne esce +, per carità...

2
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.

3
Intervengo solo ora, e me ne dispiaccio, causa momenti liberi pochi e quei pochi dedicati al mio progetto NeoGeo.

Sono assolutamente entusiasta quando leggo interventi come questi specie in territorio tricolore.

Adoro l'Amiga forse quanto il Commodore 64 (inchino), e faccio un grosso in bocca al lupo all autore del thread e nella sua "via crucis" affermo di capirlo benissimo!
Lascio qui la mia testimonianza verso di lui tesa ad incoraggiarlo a non mollare mai, parole che spesso ripeto a me stesso dato che sono parole di cui si ha bisogno in questi casi.

Ho letto anche l'intervento inerente il fronte homebrew paragonato tra le 2 macchine e mi spiace moltissimo sentire che l'Amiga sia così indietro.
Sembra quasi che la scena sia concentrata a cercare di tramutare l'Amiga >= 1200 in una specie di Frankenstein per competere con le macchine moderne, centellinando installazioni e pregando sulla nuova performance che si otterrà con chissà quale SO in fase di rilascio.

E' tutto molto triste è vero, e forse, anzi quasi sicuramente, la scena C64 è stra-avvantaggiata dall'estrema semplicità di realizzo in relazione ad una certa complessità nel gestire invece la sorellona a 16 bit.

Tuttavia finchè ci saranno appassionati, io nutro sempre speranza.
Vorrei tornare a 13 anni quando mi tuffavo con la fantasia inserendo un floppy blu dentro quella tastiera bianca, cercando di risolvere i puzzle di Beast III o di Myth o le avventure Lucas....

PS: OMG cosa non è Hyperion per C64!!!  :o

4
Hobby & Passioni / Re:Aviazione
« il: 23 Maggio 2015, 13:12:32 »
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...  :-\

5
Presentati / Re:Un saluto a tutti voi
« il: 25 Dicembre 2014, 17:28:09 »
 ;)

6
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...

7
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

Successivamente ho rispolverato un progetto di un ragazzo francese che si trova qui:

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...

8
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?

9
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.


10
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  ;)

11
Presentati / Re:Un saluto a tutti da www.assistenzacommodore.it
« il: 08 Dicembre 2014, 14:55:07 »
mi accodo al gaudio  :)

Benvenuto!

12
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!

13
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

14
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 :)

15
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!!!).

Pagine: [1] 2