Newsgroup: it.comp.retrocomputing
Titolo: Re: giochi autoboot su xt 8088

 
contenevano il System Dos+un file autoexec.bat+il prg !!!!  Il me li 
facevo cosi' !!!! Ai tempi quei giochini erano di dimensioni risottissime 
e su un floppy ci stavano con il System.

 e su un floppy ci stavano con il System.
Nyet :)
Il file system era diverso, tali dischetti non erano nemmeno leggibili 
con un semplice "dir".
-- 
8tto (38,273/4,MI)
Nuke the Vatican
C'è differenza tra peccato e reato

 Che sistema operativo contenevano?
La maggior parte nessuno.
Il programma era compilato direttamente in linguaggio macchina, e
lanciato "al posto" del sistema operativo.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 lanciato "al posto" del sistema operativo.
Proprio così, in quel periodo c'era l'esigenza di bypassare il sistema
operativo per una serie di motivi:
1) Gli hd erano rarissimi e quasi sempre il s.o. veniva caricato da
floppy: evitarlo significava risparmiare spazio su disco ed avere più
ram libera, che quasi sempre non superava i classici 640k.
2) Un disco non standard era difficilmente copiabile dalla "massa"...
3) Un gioco prodotto in questo modo era anche più facile da
utilizzare, col sistema "inserisci e vai"...
Al creatore del thread consiglio di cercare su google "pc booter" per
trovare maggiori informazioni, e il sito "retrograde station" (non ho
il link sottomano), che si occupava appunto di catalogare questo tipo
di giochi per pc.
--
AndreaP
http://avereventanni.blogspot.com

 operativo per una serie di motivi:
Eh, lo so, sono un retroprogrammatore, in fondo. ;-)


 retrograde station
http://retrograde.trustno1.org/index.html

>> hours of Amiga hacking a day  :-) <<< 

 ciofecone 8088/86/286/386
La grafica e i colori della CGA erano a dir poco imbarazzanti, capaci di 
sfigurare perfino di fronte a un umile C64.
p.bes

 risoluzione un pochino piu' alta se non sbaglio)
Lascia fare...la combinazione verde-fuscia della cga...manco li cani 
tedeschi... ;))
Forse e' stata una (infelice) scelta mirata al puro contrasto nella 
visualizzazione di programmi testuali.. (?)
ciao
-- 

e la Hercules monocromatica allora dove la mettiamo?
Nel cesso :-PPP

 ce ne vuole eh....
Beh, in fondo non erano poi giochi enormi. ;-)
E in fondo, se devi solo usare video e tastiera, serve ben poco di più
di un compilatore che producesse eseguibili per il dos.
In fondo, i .com si potevano far partire praticamente senza dos, se non
usavano qualche chiamata diretta alle system call tipiche di dos.
In quel caso, si usavano direttamente le funzioni a basso livello
fornite dal BIOS, meno pratiche, meno portabili, ma sempre presenti.
PS: Indovina un po' che differenza ci può essere dal 
command.com
 ad
un gioco compilato nello stesso modo, quando vengolo letti dal disco
in fase di avvio.


 risoluzione un pochino piu' alta se non sbaglio)
e che te ne fai di 720x240? monocromatici? un qualsiasi amiga 1000 e poi 500 
era capace di sbatterti 640x256 e 16 colori, stessa epoca e costo di mooolto 
minore.


 abstraction layer?
Esatto.
Da quel che ricordo, io.sys si occupava, guarda caso, dell'I/O, mentre
msdos.sys aveva le funzioni "di interrupt", in pratica, le system call
che volendo potevi rimappare e sostituire per fare qualche giochino in
più rispetto allo standard fornito.


 risparmiare memoria)
Bravo. Così se il programmatore se ne scordava, il PC diventava 
inagibile fino a nuovo avvio...
p.bes


Qualcosa del genere accadeva. Se ricordi, infatti, in alcune circostanze
all'uscita di un programma veniva richiesto nuovamente un floppy del DOS con
il messaggio: "Inserire un disco con 
COMMAND.COM
 e premere un tasto quando
pronto". Proprio perché la copia in memoria risultava corrotta o rimossa.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/



 risparmiare memoria) 
Infatti č proprio cosě: il 
COMMAND.COM
 di MS-DOS č composto di due parti, una
residente e una transitoria. Alcuni programmi praticolarmente grossi, durante
l'esecuzione sovrascrivono la parte transitoria. Quando terminano, la
(piccola) parte residente si preoccupa di ricaricare dal disco il resto
dell'interprete. 
COMMAND.COM
 stesso, prima di avviare un programma, imposta
sullo stack un indirizzo di ritorno che punta alla routine residente che
verifica se č necessario ricaricare il resto (ed eventualmente chiedere di
reinserire il floppy giusto). Non sarebbe prudente farlo fare direttamente al
programma chiamato: se terminasse in errore si rimarrebbe senza prompt.
Vedere 
http://books.google.it/books?id=CJDTFXwqcOsC&pg=PA94
 a pagina 97. :-)
Ciao,
G.

 abstraction layer? 
Il boot sector di un disco con MS-DOS carica in memoria e passa il controllo
al codice presente nei primi tre settori del file IO.SYS il quale dev'essere
contiguo e solitamente all'inizio della zona dati del volume. Il codice
contenuto in questi primi tre settori si preoccupa di trovare e caricare in
memoria il resto di IO.SYS che dev'essere mappato nella prima voce della root
directory (non necessariamente contiguo). IO.SYS contiene i driver primitivi
per tastiera, video e disco. Una volta caricato e inizializzato, il suo
compito č cercare e caricare MSDOS.SYS che contiene il kernel vero e proprio
di MS-DOS il quale provvede ad inizializzare varie strutture in memoria, fra
cui la tabella degli interrupt, compreso il famoso interrupt 21H, e a leggere
e interpretare il file CONFIG.SYS. Come ultima cosa, MSDOS.SYS carica la shell
indicata in CONFIG.SYS o quella di default, cioč 
COMMAND.COM
, e le passa il
controllo alla sua routine di inizializzazione. Questa routine cerca il famoso
file AUTOEXEC.BAT, lo esegue e termina al loop di visualizzazione del prompt.
IO.SYS e MSDOS.SYS (che il DOS IBM chiama 
IBMBIO.COM
 e 
IBMDOS.COM
) sono
separati perché inizialmente si ipotizzņ l'esistenza di hardware particolare,
incompatbile e fuori standard, per cui sarebbe stato necessario sostituire la
parte di I/O primitivo, necessaria per fare il boot, con una personalizzata.
Vedere 
http://books.google.it/books?id=CJDTFXwqcOsC&pg=PA94
 a pagina 95. :-)
Ciao,
G.

 
eseguivo:
1) c:format a:
2) c:sys a:
3) copy keybit.* a:
cosi' ottenevo un disco con un sistema bootable... poi, con il Dos 5.x ( se 
ricordo bene) venne il comando  format a: /u /s che trasferiva direttamente 
il system ( 2 files hidden ) e ''rasava al suolo'' i dati sul floppy
successivamente copiavo il gioco s.ul floppy e creavo un autoexec.bat ad hoc 
!


Sì ma qui si parlava di giochi protetti, che si caricavano da soli senza
passare per il DOS: di questi giochi (come si può vedere dal sito che
qualcuno qui ha indicato) ne sono poi esistiti anche le versioni eseguibili
sotto DOS, in genere in formato .COM proprio perché non rilocabili e
caricabili direttamente all'avvio senza procedure di sistema in grado di
gestire la rilocazione (nata del resto dal DOS 2.0 in poi).
La procedura da te descritta andava bene per i giochi che comunque andavano
eseguiti sotto DOS e che avevano sul floppy almeno 100k liberi per i file di
sistema e il 
COMMAND.COM
.
