[abc80] ABC firmware & disk images

[H. Peter Anvin]

exon at lysator.liu.se wrote:
> Hej igen!
> 
> Det visade sig efter lite experimenterande, att det är samma firmware för
> 800M och C. Bildminnet i 800C saknar dock udda adresser, vilket används
> för att avgöra om skärmbredden blir 40 eller 80 tecken. Listigt!
> 

Eh?  Såvitt jag vet hade ABC800C samma bildminnesstruktur som ABC80. 
800C hade ingen 6845 utan använde ett par chips from Philips som normalt 
användes till Text-TV.  Däremot 802:an och 806:an betedde sig som du 
beskriver.

ABC800C hade ingen (officiell) 80-teckensoption.

> Nu är den stora frågan hur videoenheten egentligen hanterar alla
> styrkommandon typ RED NWBG FLSH DBLE GGRN etc, samt hur text, blockgrafik
> och högupplösningsgrafik egentligen samverkar... tips, någon?

Jag kan beskriva det för 800C; 806:an hade ett helt annorlunda system.

I vilket fall som helst...

Först, det är värt att påpeka att WHT == CHR¤(135), och GWHT == 
CHR¤(151), d.v.s samma koder som rekommenderades för användning I ABC80. 
  De tappar översta bitten när de läggs i bildminnet, men den bitten 
undviker att 135-128 = 7 blir pip, etc.

Det fanns många fler som fungerade, men dessa var framåtkompatibla.

Här är attributmotorn i min ABC80-FPGA, som har så vitt jag vet en 
ABC800C-kompatibel grafikenhet:

                          if ( thischar[6:5] == 2'b00 )
                            begin
                               // Control character
                               casex ( thischar[4:0] )
                                 5'bx0xxx:
                                   begin
                                      curfg <= thischar[2:0];
                                      isgraph <= thischar[4];
                                   end
                                 5'b0110x:
                                   isdble <= thischar[0];
                                 5'b11000:
                                   ishide <= 1'b1;
                                 5'b1111x:
                                   isgrel <= thischar[0];
                                 5'b0100x:
                                   isflsh <= ~thischar[0];
                                 5'b11001:
                                   isgsep <= 1'b0;
                                 5'b11010:
                                   isgsep <= 1'b1;
                                 5'b11100: // BLBG
                                   begin
                                      curbg <= 3'b000;
                                      curfg <= curbg;
                                   end
                                 5'b11101: // NWBG
                                   begin
                                      curbg <= curfg;
                                      curfg <= 3'b000;
                                   end
                               endcase // casex( thischar[4:0] )
                            end // if ( thischar[6:5] == 2'b00 )

Två saker att påpeka:

1. min motor tillåter tecken 0 som BLK och 16 som GBLK, de fanns inte i 
800C (däremot fanns de i 806.)  Den riktiga 800C ignorerade koder 0 och 16.

2. Efter DBLE tog ett tecken dubbelt så stor plats; i 800C visades 
*alltid* den övre raden oavsett vad som fanns i bildminnet för den undre 
raden.  Om alla rader hade DBLE text visades följaktligen varannan rad!

Vad gäller högupplösningsgrafik (återigen, vad gäller 800C):

Det fanns 128 paletter för som man kan välja mellan (4 av 8 färger); 
normalt ansågs höggrafiken som "bakom" texten, men om man satte bit 7 i 
palettkommandot var höggrafiken "framför" texten.

Jag är lite osäker på precis hur blandingen fungerade; jag är rätt säker 
att var gäller textskärmen ansågs svart vara "genomskinlig"; det är 
troligt det gällde grafiken med.

Upplösningen var 240x240 i rader om 64 bytes (256 pixlar) med början på 
adress 0; HR-minnet var ett speciellt minne som "blev synligt" om man 
exekverade kod på adresserna 0x7800..0x7fff.  På adress 0x7ffd fanns 
subrutinen "LDIR ; RET".

Observera att då textmatrisen var 6x10 gånger 40x25 var alltså 
grafikupplösningen på 240x240 samma som textupplösningen.

	----

800M hade samma höggrafiksystem som 800C, utom att alla färger som inte 
var svarta blev den monokroma färgen.  800M:s textsystem var 
6845-baserat och hade inget stöd för låggrafik.  Bildminnet var linjärt 
i minnet från adress 7800h framåt.

802:an var samma som 800M, men med stöd för låggrafik och för att välja 
mellan 40 och 80 tecken.  I 40-teckensmod hoppar den över varannan 
adress.  Dessutom användes bit 7 i 802:an för invers video (liknande 
80:ans blink.)

802:an hade 64K minne; 32K av detta var tillgängligt som ramdisk (MEM:) 
men hade ingen grafisk funktion.  Däremot betydde det att det gick att 
köra CP/M på 802:an utan extra hårdvara.

806:an hade ett system liknande 802:an, men med ett extra attributminne 
för varje tecken; detta attributminne var I/O-mappat.  806:ans textdel 
var den enda i ABC-serien som kunde sätta färger och andra attribut utan 
att ta upp utrymme i form av blanktecken.  Dessutom var det den enda som 
stödde att blanda 40- och 80-teckenstext på samma skärm; det kallades 
"EL" (elongated) och kunde kombineras med DBLE (vad jag inte är säker på 
är om DBLE implicerade EL).  Detta lagrades i attributminnet, och till 
skillnad från 800C krävde 806:an att alla rutor som togs över av ett 
"stort" tecken hade samma information -- annars blev en del av tecknet 
överskrivet.

806:an hade också ett mer avancerat höggrafiksystem som antingen kunde 
göra 512x240 med 4 färger eller 256x240 med "16" färger; dessa kunde 
vara frivilliga kombinationer av de 8 färger som fanns både "bakom" och 
"framför" texten; representerad i BASIC med en sträng av vanliga 
färgkoder och grafiska färgkoder, respektive.  806:an kunde förses med 
upp till 128K grafikminne, vilket stödde 4 sidor och/eller fungerade som 
  ramdisk (RAM:).

> TeleDisk-formatet tycks vara ytters "proprietärt" och finns inte beskrivet
> någonstans, vad jag kan se. Däremot finns det folk på nätet som med
> varierande framgång försökt reverse-engineera det.

:(