Date création: 22/02/2009
Dernière mise à jour: 04/03/2009
1) Introduction
"L'Apple II, la Rolls Royce des micro-ordinateurs".
C'est ainsi qu'était qualifiée notre bonne
vieille machine increvable au début des années 80.
Et ce à tous points de vue: face à la concurrence
(Amtrad, Atari, Oric, Sinclair, Thomson, etc...) l'Apple II
avait d'excellents
atouts mais aussi un sacré inconvénient: son
prix!!
Avec un
ticket d'entrée fixé
à 12.000 francs pour une configuration de base,
ça calmait monsieur "Tout Le Monde", surtout si
c'était pour le fiston qui voulait faire des parties
de Castle Wolfenstein
ou de Robot War...
Pour illustration, cette image issue du film "Un
fauteuil pour deux"
("Trading Places" dans la
version originale)
réalisé par John
Landis en 1983 avec entre autre
Dan Aykroyd et Eddie Murphy. Sur l'image, on voit un
des deux
frères
Duke contrôlant une
puissante banque de Philadelphie
à leur nom (Duke & Duke)
en train de lire The Wall
Street Journal. On aperçoit sur la page arrière
une publicité pour l'Apple II qui de par sa
présence ici en dit long. Le slogan utilisé: "The
first problem they solve is what to give for Christmas".
Merci à Vincent
Hémeury pour m'avoir fourni cette
image.
Mise à jour des photos le 24/04/2009 avec les nouvelles
envoyées par Vincent.
Un gros chèque pour la configuration de base et... des
chèques non négligeables dès qu'on
voulait le faire évoluer.
Quelques prix pour passer sa machine à 128k ou pour avoir
accès au mode 80 colonnes par ligne (le standard
étant 40 colonnes):
Pour obtenir des
caractères en minuscule sur les modèles les plus
anciens, il fallait casquer. Idem rien que pour avoir
l'équivalent de la touche Shift!!
Bien entendu, de nombreux utilisateurs ne pouvaient pas ou ne voulaient
pas passer de nouveau à la caisse pour
bénéficier de ces dernières
évolutions.
On en vient naturellement à la problématique
rencontrée par les éditeurs de logiciels:
à qui
destiner leurs produits et comment contenter tout le monde?
- Fallait-il cibler les utilisateurs les plus argentés et
ainsi passer
à
côté d'acheteurs potentiels plus "modestes"?
- Ou bien niveler par le bas en offrant un logiciel fonctionnant sur
toutes les configurations mais faisant grincer les dents des
possesseurs de cartes 80 colonnes en n'offrant pas le support de leur
hardware acheté à prix d'or?
Les éditeurs souhaitant ratisser le plus large possible ont
dû fait preuve d'originalité et proposer des
solutions
satisfaisant la clientèle la plus étendue.
Je prendrais comme exemple celui des éditeurs de traitement
de textes.
Alors que les machines à écrire standards
proposaient de
60 à 80 caractères par ligne, comment vendre un
traitement de textes à une personne n'ayant que 40 colonnes
par
ligne sur son Apple II de base?
Des petits malins se sont creuser la tête et ont eu
l'idée de se servir du mode graphique plutôt que
du mode texte pour... afficher du texte de manière plus
compacte.
J'explique: avec le mode HIRES natif de l'Apple II, il est
possible d'atteindre une résolution de 280 pixels de large.
Pour cela, l'Apple utilise 40 octets pour une ligne,
chaque octet étant exploité de la
façon suivante: 7
bits pour l'écriture proprement dite sur l'écran
(=7 pixels) et un bit servant au choix de la couleur selon la
parité de
l'emplacement de l'octet.
Voici le calcul qui a été effectué
pour offrir une solution de substitution: 40 octets * 7 bits = 280 bits
/ 4 bits de large = 70
caractères.
Il était donc possible d'offrir aux utilisateurs les moins
dotés une solution alternative proposant non pas 40 mais 70
caractères par ligne avec une police étroite de 4
pixels
de large. Sachant qu'il faut un espace entre chaque
caractère,
on enlève un pixel et du coup chaque caractère de
la
police doit être codée pour ne faire que 3 pixels
de
large.
Et ce n'était pas tout! En plus du passage
à 70
colonnes par
ligne, cette solution graphique permettait aussi aux utilisateurs
d'anciennes
machines de bénéficier du support des minuscules
alors
que leur ordinateur n'en était pas pourvu. Un simple appui
sur
une touche dédiée (par exemple
un control-"touche quelconque") servait de
switch virtuel majuscule/minuscule en mode graphique.
Il faut tout de même mettre un bémol sur cette
solution apparement géniale: cette
émulation logicielle en mode graphique
requiert plus de
mémoire (il y avait donc moins d'espace disponible pour
stocker
le texte tapé par l'utilisateur) et la lisibilité
n'était pas top non plus (à noter qu'il
faut
être en mode monochrome car sinon les caractères
affichés sont illisibles).
Mais c'était néanmoins un plus
indéniable que les
éditeurs n'hésitaient pas à mettre en
avant dans
leurs publicités.
Il me semble que le 1er à avoir édité
une telle solution a été On-Line
Systems (plus
tard rebaptisé Sierra On-Line).
Est sorti sur le marché en février 1981 le
traitement de textes SuperScript
qui a changé de nom
plusieurs fois de suite pour des raisons de conflits d'appellation.
Le soft écrit par David Kidwell
(et Jeff
Schmoyer) a été
rebaptisé
SuperScribe II en mai 1981
puis est devenu Screenwriter II
en mai 1982.
Sur le site Apple2History, on peut lire au
sujet de Screenwriter II: "No
extra hardware for upper-lower
case, 70 column display, printer
spooling. Edits BASIC, text, and binary files; complete search
and replace. Sierra On-Line." [This solved the
hardware problem of no lowercase display and only 40
columns of text by creating hi-res graphics
characters. Because of the
limits of the hi-res screen, it was only possible to get 70
columns of text in this
mode. This method was later used in other word processors and
even for Applesoft programs through add-on modules.]
En fait ces fonctionnalités étaient
déjà présentes dans la version
antérieure (SuperScribe II).
Ci-dessous trois publicités de ces produits (dont la
2nde
redonne tous ces arguments avec une illustration choc d'un mec en train
de pulvériser le hardware):
Ne pas confondre le SuperScript
d'On-Line Systems avec le SuperScript
(également un traitement de textes) de la
société anglaise Precision
Software (dont j'ai un
original en boite datant de 1984).
Comme il est dit, on retrouvera par la suite chez les concurrents d'On-Line
Systems ce
mode spécial intégré à leur
propre traitement de textes.
On peut citer le programme Word
Handler
(chez Silicon Valley
Systems vendu seul ou avec le package The
Handlers) ainsi
que les produits
édités par Artsci
mais j'y reviendrai dans le chapitre suivant.
Il y a surement d'autres logiciels ayant cette faculté...
Mise à jour du 4/03/2009:
Rajout des pubs pour le traitement de textes Super
Text (en
version Home/Office) de Muse Software
et le terminal TekTerm de Fountain Computer Products:
"70 colonnes dans un traitement de textes, c'est bien. Mais pourquoi ne
pas pouvoir bénéficier de cet affichage
spécial dans n'importe quel autre programme ou lorsque l'on
a la main sous DOS 3.3 pour faire ce que l'on veut avec???"
Telle est la question que s'est un jour posée un autre petit
malin du nom de Gene Hite.
Il a alors eu l'idée de sortir sa propre solution
appelée Soft Seventy.
Il s'agissait d'un programme à part entière qui
commutait ce mode et redonnait ensuite la
main à l'utilisateur (qui pouvait alors par
exemple taper
la
commande CATALOG du DOS 3.3 en mode 70 colonnes ou
écrire/exécuter
son propre programme
BASIC
en utilisant cette fonctionnalité d'écriture).
Soft Seventy était
signé HeartWood
Designs, Inc et a été
publié
en 1981 par **********.
Je n'ai pas voulu me pencher davantage sur ce produit, ayant
été en conflit avec un responsable de cette
organisation qui existe toujours.
Bref, je ne veux surtout pas leur faire trop de publicité...
J'en ai parlé pour des raisons historiques mais je zappe
rapidement.
Pour l'anectode, même si 80 colonnes pouvait
paraître le nec le plus ultra à
l'époque, pour certains ce n'était pas encore
assez.
Les pros pouvaient avoir besoin d'une visualisation horizontale plus
importante par exemple pour avoir une vue élargie sur une
feuille de calculs.
Le constructeur Videx a ainsi
sorti une carte UltraTerm
pour
bénéficier de 160 colonnes de large.
Rien que pour ce mode vidéo (sans ajout de ram), il fallait
débourser 379 dollars US...
2) Artsci Inc
Artsci
Inc
a été un acteur très actif dans la
première moitié des années 80 sur
cette plateforme.
Le nom de cette société (qui existe toujours!!)
provient de la contraction "Where ART and SCIence work for you".
Un de ses fondateurs, "Bill" Smith, a eu la bonne
idée de
raconter son histoire (avec celles
liées de Softape - l'éditeur de
cassettes
dédiées à l'Apple II - et
de la revue Softalk).
Qui ne se souvient pas de leur excellent programme de traitement de
textes appelé Magic Window?
Comme le raconte cet article, Artsci
a aussi
édité d'autres produits comme Magic
Words ou
encore Magic Mailer.
Personnellement, après avoir beaucoup utilisé le
1er volet de Magic Window
(qui donnait l'impression de taper sur une
vraie machine à écrire avec le curseur qui
restait au milieu de l'écran et la feuille virtuelle qui se
décalait vers la gauche à fur et à
mesure de la frappe), j'étais passé sur Magic
Window II.
Un très bon souvenir et d'ailleurs j'ai encore un bon nombre
de mes fichiers datant de mes études avec l'extension .MW
sous DOS3.3.
Quelques pubs du produit ainsi qu'un article dessus:
Même si je ne m'en suis quasiment pas servi car j'avais une
carte 80 colonnes étendue, je me souviens très
bien que le programme proposait au démarrage la fameuse
option "70 colonnes par ligne".
Quelques écrans d'équivalence entre 80 colonnes
(en texte) et 70 colonnes (en mode graphique) - on notera au passage la
différence des "sectors free" entre les 2
dernières
illustrations (en bas d'écran):
A noter que le driver nommé ARTSCI70.OBJ0 qui permet cet
affichage était aussi disponible pour le tableur maison
Magicalc:
Un affichage de la configuration avec driver 70 colonnes (+ option
"video slot" forcée à zero) et le
résultat sur une feuille de calcul:
J'ai également vu une publicité (en
mauvais état) de
juillet 83 sur la revue
Micro numéro 62
pour un autre de leur produit: Magic
Memory qui était une sorte
de carnet d'adresses amélioré avec index A-Z dans
lequel on mettait toutes
ses notes pour les regrouper et les stocker sur un seul disk. Tout
comme pour Magic Window II
et Magicalc, je cite, "Magic
Memory is
designed to operate on an Apple //e and still remain totally
compatible
with APPLE II. The system will operate in 40 columns or 80 columns. You
may also use the 70-column display that requires no additional
hardware."
3) ARTSCI70 et PD8
Pourquoi est-ce que je m'intéresse à ce fameux
mode 70 colonnes par ligne?
Il s'avère que j'ai été
"recruté" par Vladimir
(de Bulgarie) aka Vladitx qui
planche sur un
nouveau firmware de la carte Pseudodisk II
(PD8) d'Alex Freed (dont j'ai
déjà parlé dans les 2
précédants articles de ce site) pour
écrire le sélecteur chargé au boot.
Son nouveau firmware sera supérieur à la
dernière version (déjà de lui) en cela
qu'il autorisera un stockage libre des disques images sur
la carte SD.
Avec la version d'Alex, les
disques images devaient se suivre
à raison de 16 noms par block et les
répertoires/sous-répertoires
étaient interdits (car non gérés).
La nouvelle version pourra afficher le
contenu total de la FAT16 en se "baladant"
dessus et en tenant compte
des répertoires présents ainsi que des
LFN (Long File
Names) de Microsoft pour affecter l'image choisie à
un des 2 drives
virtuels possible gérés par la PD8. Plus besoin
de faire
des renames de noms après un download sur Asimov ou
ailleurs pour avoir le format standard restrictif du DOS: 8
caractères de nom + 3 caractères d'extension.
Comment gérer les LFN?
Je ne veux pas être limité
à un affichage en 40
caractères (pour peu que le nom soit
détaillé, il
peut facilement dépasser cette taille) mais je ne veux pas
lier
l'usage de la PD8 à la présence d'une
carte 80
colonnes
(quand j'achète une carte et que je la teste, je vire toutes
mes autres cartes de la machine pour ne pas les griller si ma
dernière acquisition a un grave problème. Au prix
actuel de la RamWorks III, ça serait quand même
idiot de la flinguer par fainéantise en la laissant dans ma
bécane).
Certes en cas de nom vraiment long (le format VFAT tolère
jusqu'à 255 caractères), le LFN se retrouve
tronqué mais il y a 30 caractères de plus
visibles à l'écran (par rapport au mode 40
colonnes), ce qui est toujours
ça de gagné.
Voici un exemple d'écran avec l'écriture de texte
en 70 colonnes par ligne avec ARTSCI70:
Le driver ARTSCI70 se trouve sur la face 2 de Magic
Window II.
Il est possible de le lancer individuellement en tapant un CALL
ARTSCI70.OBJ0 depuis un DOS 3.3 mais ça reste un driver et
à part
l'affichage on ne peut rien faire contrairement à Soft
Seventy.
Mais il ne m'en faut pas plus car c'est juste cet affichage qui
m'intéresse :-)
A titre indicatif le driver "ARTSCI 70 COLUMN SOFTWARE" a comme adresse
de stockage mémoire: ARTSCI70.OBJ0 "A$8300,L$1300".
Je me suis donc amusé à le
désassembler avec Sourceror
et à refaire un
source clean avec Merlin-8.
Ca m'a rappelé l'époque où je
programmais le mode DHGR 16 couleurs car le principe est assez
similaire.
Je vais en dire quelques mots dans le chapitre suivant pour
faciliter la
compréhension du source livré.
4) Détails techniques
ETUDE DES CAS
Nous avons vu que chaque caractère fait 4 bits de large et
que sur les octets correspondant
à l'écran HGR seuls 7
bits représentent les pixels.
Ce n'est pas un compte juste et quand on écrit une phrase,
50% du temps pour afficher un caractère on est à
cheval sur 2 octets différents.
Ce qui oblige à faire des manipulations de bits à
grands coups de EOR et de AND pour ne pas écraser les
éventuels caractères adjacents
déjà présents à
côté de l'endroit où on veut afficher
notre nouveau caractère.
Il faut de plus prendre en compte le mode inverse qui affiche
un caractère en vidéo-inversée quand
cela est demandé.
La situation se résume à une étude de
cas comme le montre cet exemple.
On veut écrire les 4 pixels ABCD plusieurs fois de
suite sur les premières colonnes de
l'écran.
Sur l'écran, les pixels (bits) vont de 0
à 6 (7 bits en tout par octet).
On s'aperçoit qu'il y a des cycles de 7 cas
différents (cas 0 à cas 6): on retombe sur le cas
0 tous les 4 octets (numérotés de 0 à
3 sur la représentation ci-dessous):
Screen
======
byte # 0000000111111122222223333333 4444444555555566666667777777
pixel
0123456012345601234560123456 0123456012345601234560123456
.<-----><-----><-----><----->.<-----><-----><-----><----->.
Case 0.ABCD
.ABCD
.
Case 1. ABCD
. ABCD
.
Case
2.
ABCD
.
ABCD
.
Case
3.
ABCD .
ABCD .
Case
4.
ABCD .
ABCD .
Case
5.
ABCD .
ABCD .
Case
6.
ABCD.
ABCD.
.<-----><-----><-----><----->.<-----><-----><-----><----->.
Un cycle se déroulant sur 4 octets, comme il y a 40 octets
par ligne, on compte ainsi 10 cycles sur l'horizontale.
Voici pour chacun des cas d'un cycle la représentation des
bits des
octets en mémoire.
A noter que l'ordre des bits est inversé par rapport
à la séquence des numéros
de pixels (la représentation écran est
l'inverse du codage mémoire).
Ce n'est donc pas ABCD que l'on écrit mais DCBA.
Pour chaque cas, on peut être amené à
écrire
sur un ou deux octets (que j'ai appelé MASK A et MASK B ici
pour
faire le lien avec le source).
Le bit 7 (pour la couleur) n'est pas utilisé.
J'ai écrit entre parenthèses les bits
significatifs que l'on doit réellement écrire
(avec la font). Quand la valeur est $00 (pour le MASK B), cela
signifie que DCBA tient dans un seul octet. On retrouve bien
évidemment ces valeurs dans les tables d'ARTSCI70 portant
les noms MASK_BYTE_A et MASK_BYTE_B.
Memory
======
MASK Byte A MASK Byte B
Case 0 Byte
0
Byte 1
======
76543210
76543210
DCBA
($0F)
($00)
Case 1 Byte
0
Byte 1
======
76543210
76543210
CBA
($70)
D ($01)
Case 2 Byte
1
Byte 2
======
76543210
76543210
DCBA
($1E)
($00)
Case 3 Byte
1
Byte 2
======
76543210
76543210
BA
($60)
DC ($03)
Case 4 Byte
2
Byte 3
======
76543210
76543210
DCBA
($3C)
($00)
Case 5 Byte
2
Byte 3
======
76543210
76543210
A
($40) DCB
($07)
Case 6 Byte
3
------
======
76543210
76543210
DCBA
($78)
($00)
CODAGE DE LA POLICE DE CARACTERES
La police d'Artsci compte 128
caractères.
Nous avons vu qu'il fallait 4 octets pour prendre en compte les 7 cas,
ceci pour une seule ligne du caractère.
Normalement, un caractère est
représenté par 8 lignes. Mais ici comme
la police est étroite, pour ne pas avoir des
lettres trop étirées, seules 6 lignes sont
réellement employées (et même pour la
plupart, il n'y a que 5 lignes). Bref, 6 lignes en tout: la ligne du
haut et la ligne du bas ne sont pas écrites, ce qui fait des
économies de place car ces lignes ne sont pas
codées du tout dans la police. C'est la routine d'affichage
qui s'en occupe.
On récapitule: 4 octets * 6 lignes = 24 blocks de 128
caractères.
Chacun de ces blocks porte un nom dans le source.
Les noms sont de la forme: FONT_BYTxLy avec x=octet[0..3] et y=ligne
utilisée[1..6]
Examinons un cas au hasard. Par exemple la lettre "B".
Il s'agit du code ASCII 66.
On va prendre les datas à l'index 66 de tous les
blocs et regarder
à quoi ils correspondent.
Line Byte 0 1
2 3 00000000111111112222222233333333
==== === === === ===
76543210765432107654321076543210
1 $33 $66 $4C $19
..XX..XX.XX..XX..X..XX.....XX..X
2 $55 $2A $55 $2A
.X.X.X.X..X.X.X..X.X.X.X..X.X.X.
3 $33 $66 $4C $19
..XX..XX.XX..XX..X..XX.....XX..X
4 $55 $2A $55 $2A
.X.X.X.X..X.X.X..X.X.X.X..X.X.X.
5 $33 $66 $4C $19
..XX..XX.XX..XX..X..XX.....XX..X
6 $00 $00 $00 $00
................................
La même chose mais sans afficher
les bits 7 inutilisés:
Line
0000000111111122222223333333
==== 6543210654321065432106543210
1 .XX..XXXX..XX.X..XX....XX..X
2 X.X.X.X.X.X.X.X.X.X.X.X.X.X.
3 .XX..XXXX..XX.X..XX....XX..X
4 X.X.X.X.X.X.X.X.X.X.X.X.X.X.
5 .XX..XXXX..XX.X..XX....XX..X
6 ............................
En inversant les bits pour avoir l'équivalent
écran:
Line
0000000111111122222223333333
==== 0123456012345601234560123456
1 XX..XX..XX..XX..XX..XX..XX..
2 X.X.X.X.X.X.X.X.X.X.X.X.X.X.
3 XX..XX..XX..XX..XX..XX..XX..
4 X.X.X.X.X.X.X.X.X.X.X.X.X.X.
5 XX..XX..XX..XX..XX..XX..XX..
6 ............................
On a bien un ensemble de caractères "B" correspondant
à tous les cas de figure.
Quand on écrit un "B" à l'écran, le
cas correspondant à la colonne où on veut
l'afficher va lire la font et éliminera par AND les bits des
cas adjacents.
GESTION DU BUFFER DE SAISIE
Un autre point à clarifier: l'utilisation du buffer clavier
KEY_BUFF.
Cette zone sert à mémoriser la frappe
à fur et à mesure (une sorte d'écho).
C'est indispensable car imaginez par exemple que vous
commencez à écrire une dizaine de mots et vous
vous apercevez qu'il y a une faute dans le 1er. Vous devez faire
reculer le curseur pour revenir corriger l'anomalie. Or à
chaque fois que le curseur recule il repasse sur un
caractère précédemment saisi et
l'affiche en inverse après
avoir réaffiché son ancienne
position en mode
normal (pour bien suivre l'emplacement courant du
curseur). Or pour que ça marche, il fallait bien que soit
stockée cette saisie pour permettre de réafficher
chacun de ces caractères. C'est le rôle de ce
tampon.
5) Download
|
DOS 3.3
|
Download ARTSCI70 Disk
|
|
Merlin 8 v2.48 DOS
|
View: ARTSCI70 assembled
source code
|
File: ARTSCI70_Source.dsk
Disk: DOS 3.3 Volume 254 (140KB)
Name
Type Auxtyp
Modified
Format Length
------------------------------------------------------------------------------
ARTSCI70
BIN $8300 [No
Date]
DOS
4864
T.ARTSCI70
TXT $0000 [No
Date]
DOS 26076
ARTSCI70.OBJ0
BIN $8300 [No
Date]
DOS
4864
------------------------------------------------------------------------------
Le programme ARTSCI70 est le résultat de la compilation du
source et ARTSCI70.OBJ0 le driver originel. Ces 2 objets sont
identiques (je les ai comparés).
