englishHi everybody!
Ok, as you well know, I've been asked for some time to add support for storage devices, i.e. mass storage. Apart from the fact that I opened an issue about it, in general it involves giving support to four different things:
- give the possibility to support deferred loading of (ugBASIC) programs, with the so-called "chaining";
- allow the dynamic loading of modules within ugBasic programs, with the so-called overlay;
- allow deferred loading of resources (graphics, audio, game data);
- allow to save the game state, for later reload.
Each of these points will need dedicated instructions, or an adaptation of those that are already there (backwards compatible adaptation, of course). However, they all come up against a fundamental decision: does it make sense to use the file metaphor, or is it more reasonable to see the medium as an addressable memory space?
The difference is not insignificant.
On the one hand, maintaining the metaphor of files, directories, and so on, we have a simple way to insert data into media using a PC, a way that programs on the home computer itself can access. On the other hand, access becomes very laborious, less performant and, in the end, a very demanding development.
On the other hand, seeing the medium as a storage space without a form, we can give it any form. We can therefore quickly access what interests us, load it and save it as we want. The disadvantage? No one else will be able to access that data if he doesn't know how.
And you, what do you think?
italianCiao a tutti!
Ok, come ben sapete, da tempo mi viene chiesto di aggiungere il supporto per i dispositivi di archiviazione, cioè le memorie di massa. A parte il fatto che ho aperto un ticket a riguardo, in generale si tratta di dare supporto a quattro funzionalità differenti:
- dare la possibilità di supportare il caricamento differito dei programmi (ugBASIC), con il cosiddetto "chaining";
- permettere il caricamento dinamico dei moduli all'interno dei programmi ugBasic, con il cosiddetto overlay;
- consentire il caricamento differito delle risorse (grafica, audio, dati di gioco);
- consentire di salvare lo stato del gioco, per ricaricarlo successivamente.
Ognuno di questi punti avrà bisogno di istruzioni dedicate, o di un adattamento di quelle già presenti (adattamento retrocompatibile, ovviamente). Tutti però si scontrano con una decisione fondamentale: ha senso usare la metafora del file, o è più ragionevole vedere il mezzo come uno spazio di memoria indirizzabile?
La differenza non è insignificante.
Da un lato, mantenendo la metafora di file, directory e così via, abbiamo un modo semplice per inserire dati nei media utilizzando un PC, un modo a cui possono accedere i programmi sul computer di casa stesso. D’altro canto, l’accesso diventa molto laborioso, meno performante e, in definitiva, uno sviluppo molto impegnativo.
D'altra parte, considerando il mezzo come uno spazio di archiviazione senza forma, possiamo dargli qualsiasi forma. Possiamo quindi accedere velocemente a ciò che ci interessa, caricarlo e salvarlo come vogliamo. Lo svantaggio? Nessun altro potrà accedere a quei dati se non sa come.
E voi, cosa ne pensate?
frenchSalut tout le monde!
Ok, comme vous le savez bien, on me demande depuis un certain temps d'ajouter le support des périphériques de stockage, c'est-à-dire le "mass storage". Outre le fait que j'ai ouvert un ticket à ce sujet, il s'agit en général d'apporter son soutien à quatre différentes choses:
- donnent la possibilité de prendre en charge le chargement différé des programmes (ugBASIC), avec ce que l'on appelle le "chaining" ;
- permet le chargement dynamique de modules dans les programmes ugBasic, avec ce que l'on appelle la [url=https://retroprogramming.iwashere.eu/ovl6502]overlay[/ URL];
- autoriser le chargement différé des ressources (graphiques, audio, données de jeu) ;
- permet de enregistrer l'état du jeu, pour un rechargement ultérieur.
Chacun de ces points nécessitera des instructions dédiées, ou une adaptation de celles qui existent déjà (adaptation rétrocompatible bien entendu). Cependant, ils se heurtent tous à une décision fondamentale : est-il judicieux d’utiliser la métaphore du fichier, ou est-il plus raisonnable de considérer le support comme un espace mémoire adressable ?
La différence n'est pas négligeable.
D’une part, en conservant la métaphore des fichiers, des répertoires, etc., nous disposons d’un moyen simple d’insérer des données dans un support à l’aide d’un PC, un moyen auquel les programmes de l’ordinateur personnel lui-même peuvent accéder. En revanche, l'accès devient très laborieux, moins performant et, au final, un développement très exigeant.
En revanche, en considérant le support comme un espace de stockage sans forme, on peut lui donner n'importe quelle forme. On peut donc accéder rapidement à ce qui nous intéresse, le charger et le sauvegarder comme bon nous semble. Le désavantage? Personne d'autre ne pourra accéder à ces données s'il ne sait pas comment.
Et vous, qu'en pensez-vous ?
