Com'è stato lo sviluppo di giochi su Apple II? [chiuso]


14

Ho fatto una domanda simile sullo sviluppo di DOS qualche tempo fa e ho avuto un'ottima risposta: qual era la tipica toolchain per lo sviluppo di giochi DOS?

Ora mi chiedo come fosse lo sviluppo del gioco su Apple II alla fine degli anni '70 / primi anni '80. Sono principalmente interessato ai primi: II e II +, ma vorrei anche risposte su IIe ecc.

Quindi, ecco le mie domande:

Quali lingue sono state usate?

Presumo che 6502 assemblatore, ma BASIC era in bundle e probabilmente anche usato molto. Riesci a pensare ai giochi popolari scritti in BASIC? Che ne dici di C?

Come è stato lo sviluppo dell'assemblatore 6502?

Ho notato che puoi inserire i codici op direttamente se avvii il monitor di sistema e puoi persino eseguire l'assemblatore direttamente con il mini assemblatore. Ma non riesco a immaginare che i giochi siano stati scritti in quel modo, c'erano editor / IDE? Come sono stati memorizzati i programmi su dischi / nastri?

Com'è stato lo sviluppo BASIC?

L'interprete BASIC di Apple II non è male, credo che tu possa scrivere programmi completi. Ti permette anche di SALVARE / CARICARE programmi, presumo su disco / nastro. Ma non c'era nessun editor visivo?

C'erano API o Middleware?

O era necessario parlare direttamente con l'hardware tutto il tempo se volevi disegnare qualcosa o riprodurre un suono? C'erano delle biblioteche?

Qualcos'altro che è diverso da oggi?

Sarei felice di sentire altre differenze, ad esempio quali formati di immagine / audio sono stati utilizzati. Dato che non c'era davvero un concetto di file se lo capissi correttamente, mi chiedo come funzionasse. Hai dovuto digitare la grafica e i suoni in assemblatore? Come ha funzionato in BASIC?


L'introduzione al Black Book grafico di Michael Abrash è stata scritta da John Carmack e parla di quanto sia stato facile realizzare la grafica: hai appena fatto un comando di disegno e cambierà automaticamente. Da quello che ricordo di averlo giocato negli anni '80, è possibile effettuare chiamate direttamente tramite BASIC.
Filippo,

Ho già collegato a questo da qualche altra parte ma ... comunque, Jordan Mechner ha rilasciato il codice sorgente per la versione Apple II di Prince of Persia . Potrebbe essere interessante per te!
Laurent Couvidou,

Una delle stranezze più notevoli dell'Apple II era che la grafica non era direttamente mappata in memoria; invece, il sistema usava uno strano tipo di sistema interlacciato in cui la riga che seguiva la riga 0 in memoria non era la riga 1 ma invece era la riga 64; quindi la riga 128 ha seguito quello in memoria, e solo dopo appare la riga 1. Ecco perché vedi gli strani effetti di caricamento "tri-banded" sui giochi Apple II.
Steven Stadnicki,

Risposte:


5

Ho fatto molta programmazione su Apple (non professionalmente, ma è quello che ho imparato su) e Applesoft BASIC e assemblatore su dove fosse per gli appassionati. Altre lingue erano disponibili - Il logo era comune, Pascal era scritto ovunque ma non conosco nessuno che lo usasse, non ero davvero a conoscenza del fatto che C fosse usato su qualsiasi piattaforma Apple fino a Orca C per Apple IIGS, c'era un Forth interprete con grafica in stile tartaruga (o chiamalo in stile logo) fluttuante.

Affronterò alcune delle tue domande, quindi idee di base:

Riesci a pensare ai giochi popolari scritti in BASIC? Che ne dici di C?

Un sacco di shareware è stato scritto in BASIC, non solo Applesoft BASIC ma anche Integer BASIC (che come suggerisce il nome, non aveva numeri in virgola mobile). Mi viene in mente la serie Eamon, ma non riesco davvero a pensare a molti altri. Inoltre, gran parte del software scritto da Beagle Bros. è stato realizzato in BASIC (principalmente utility, non giochi).

Credo che la maggior parte dei software commerciali sia stata scritta in assembler, comunque.

Ma non riesco a immaginare che i giochi siano stati scritti in quel modo, c'erano editor / IDE? Come sono stati memorizzati i programmi su dischi / nastri?

Ho usato l'Assemblatore Merlin, per definirlo un IDE potrebbe allungarlo, ma ha funzionato bene. Come hai detto, puoi passare al monitor di sistema, inserire i codici operativi ed eseguire da lì. Merlino aveva un modo per tornare ad esso dal monitor di sistema (che non ricordo come ora).

Ma non c'era nessun editor visivo?

Esisteva uno strumento di terze parti che rendeva un po 'migliore l'ambiente Applesoft e ti consentiva di usare le frecce per scorrere lo schermo e apportare modifiche come un editor visivo (dovevi ancora premere Invio alla fine di una riga o i cambiamenti non si attaccherebbero). Non ricordo cosa fosse, l'ho usato un po '.

O era necessario parlare direttamente con l'hardware tutto il tempo se volevi disegnare qualcosa o riprodurre un suono? C'erano delle biblioteche?

Su Apple II + / IIe / IIc praticamente parlavi solo con l'hardware. C'erano un paio di programmi nella ROM che potevi usare ma erano molto limitati e di solito avresti PEEK e POKE varie posizioni di memoria per cambiare i registri per fare quello che volevi, ad esempio per cambiare le modalità grafiche, colpire 49152 per attivare l'altoparlante, ecc. .

Su Apple IIGS, la ROM veniva fornita con una suite di librerie simile a quella fornita da Macintosh, per realizzare fantasiose GUI e quant'altro. Le ROM sono state aggiornate nel tempo e, se si caricava un disco di sistema che utilizzava librerie più recenti, avrebbero letto dal disco anziché dalla ROM, facendo sì che il tempo di avvio diventasse VERAMENTE LENTO. C'erano ROM 01, 02 e 03 e 02 -> 03 era un aggiornamento gratuito, e c'era una versione prima di 01 che avrebbero fatto anche un aggiornamento gratuito a 01.

Sarei felice di sentire altre differenze, ad esempio quali formati di immagine / audio sono stati utilizzati. Dato che non c'era davvero un concetto di file se lo capissi correttamente, mi chiedo come funzionasse. Hai dovuto digitare la grafica e i suoni in assemblatore? Come ha funzionato in BASIC?

C'erano file, non sono sicuro di cosa tu voglia dire, e ProDOS non supportava meno le directory (il DOS precedente non aveva, ma aveva ancora il concetto di un file che riconosceresti). Ho usato bitmap e .pcx. Non ricordo alcun file audio sulla serie II + / IIe / IIc, ma era perché era difficile rendere più rumorosi i rumori rispetto ai blip e ai bloop dei videogiochi. C'erano alcuni hack là fuori che producevano suoni fantasiosi (in particolare, avevo un disco che suonava Gun N 'Roses), ma quasi sempre veniva fatto grammaticalmente.

Rispetto agli ambienti moderni, era decisamente primitivo. Ma ricorda, non c'era supporto per eseguire più programmi contemporaneamente, quindi il tuo compilatore doveva anche essere il tuo editor - non potevi davvero discutere i vantaggi di vi vs. emacs, quindi qualunque cosa il tuo compilatore ti offrisse, hai imparato a usare. Penso che sia stato molto più semplice rispetto all'utilizzo di librerie ammucchiate su librerie, e ci sono molti trucchi se stai lavorando per l'hardware e sai di cosa si tratta. Ad esempio, un'implementazione comune di "pause per un momento" era "for (int i = 0; i <1000; i ++)" (è diverso in BASIC), che non viene mai usato ora, perché l'hardware è così veloce che tu ' avrebbe bisogno di un numero enorme, e anche se non lo fosse, sarebbe eseguito su diversi tipi di macchine, quindi sarebbe una pausa diversa per persone diverse (II +, IIe,

Questo è tutto dalla memoria, non ho guardato alcun riferimento durante la scrittura di questo, quindi mi scuso se la mia memoria è difettosa e ti ho detto cose sbagliate. Spero che questo ti dia un po 'di gusto e risponda ad alcune delle tue domande.


4

Quali lingue sono state usate?

6502 per la maggior parte, raramente C (Aztek), molti BASIC, alcuni Pascal (Apple Pascal).

Come è stato lo sviluppo dell'assemblatore 6502?

C'erano alcuni assemblatori e strumenti piuttosto accurati per 6502: Orca / M, Merlin, inoltre nei giorni successivi era possibile sviluppare su PC e un collegamento seriale ad Apple per il debug remoto. Non dimentichiamo le utility Beagle Bros. Modifica + compila + esegui, il mondo non cambia mai ;-)

Com'è stato lo sviluppo BASIC?

Nessun editor visivo, solo una console che ti permettesse di interagire con il buffer BASIC all'inizio. Tuttavia, Beagle Bros. aveva un paio di utilità magiche che hanno fatto sparire gran parte del dolore. E più tardi c'erano delle conchiglie che si sarebbero comportate almeno come un editor basato su linee per i tuoi scritti. C'era uno strumento (Expediter 2) che poteva ridurre il BASIC in un binario di assemblaggio che correva molto più velocemente (un viaggio di sola andata).

C'erano API o Middleware?

C'erano alcuni, ma per lo più di portata molto ristretta, niente come quello che oggi chiameresti un SDK. Siamo onesti, in 48K non puoi permetterti un'API per scopi generali. Nei giorni successivi sono emersi due o tre SDK con scopi specifici emersi per i giochi di avventura, i giochi basati su tessere,

Qualcos'altro che è diverso da oggi?

Tutto e niente. Le pratiche rimangono le stesse, gli strumenti sono migliorati.


-1

Interprete di base nativo: quando scrivi un programma dovresti numerare ogni riga, inserire il tuo codice e premere invio. Un programma di base è simile a: 10: HOME 20: STAMPA "HELLO WORLD"

In questo esempio HOME cancella lo schermo, se necessario devi inserire una linea intermedia, fe .:

15: STAMPA "SALUTI"

All'uscita dovrebbe cancellare lo schermo, mostrare SALUTI SALUTO MONDO

ELENCO comandi mostra il tuo codice (senza pausa!) Nessun capslock in alcune modalità (solo maiuscole), nessun carattere speciale. Nessun gioco professionale è stato scritto in BASIC, a causa delle prestazioni, potresti effettivamente vedere il tuo programma tracciare le linee.

Solo effetti sonori, è stato difficile riprodurre musica, abbiamo solo un altoparlante con ONE bit (non scherzo) 49152 che cambia stato, sì, dovresti controllare anche la frequenza ed era una forma d'onda quadra.

per andare all'assemblaggio CHIAMARE -151

dovresti codificare a mano sul monitor senza IDE inserire l'indirizzo e il tuo codice (HEXA)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.