Routine for Screen Encoding detection with PureC or Assembly

[moulinaie]

Hello,

I have written a routine that can detect the screen encoding of nearly every Atari (with or without graphic card, even under emulators, etc...).

Formerly, it was just included in some of my programs. I decided to make it available as a Pure C OBJect file to be included in every C program.
It can help when EdDI cookie is not available, it only uses AES/VDI standard calls and only requires that you call appl_init() before.
As the ASM sources are also included, you can easely use it into an assembly program.

 

I have included an example C program.

 

The call is simple:
long code = ScreenEncoding(_GemParBlk.global, flag);

 

Upon return, you have a code that can be one of these:

 

#define B1_mono        0x00010000    /* monochrome one plane ATARI ST HIGH */
#define B2_inter     0x00020000  /* 4 colors interlaced ATARI ST MEDIUM */
#define B2_ninter     0x00020001    /* 4 colors non interlaced */
#define B4_inter    0x00040000  /* 16 colors interlaced ATARI ST Low/TT Med */
#define B4_ninter    0x00040001  /* 16 colors non interlaced */
#define B4_packed    0x00040002    /* 2 pixels/byte */
#define B8_inter    0x00080000  /* 256 col interlaced ATARI TT Low/Falcon */
#define B8_ninter    0x00080001  /* 256 col non interlaced */
#define B8_packed     0x00080002  /* 256 col 1byte = 1 pixel, NOVA */
#define B8_packedM     0x00080003  /* 256 col 1byte = 1 pixel MATRIX */
#define B16_motor     0x00100000  /* rrrrrggg gggbbbbb ATARI Falcon */
#define B16_intel     0x00100001  /* gggbbbbb rrrrrggg */
#define B15_motor     0x00100002    /* xrrrrrgg gggbbbbb */
#define B15_intel     0x00100003    /* gggbbbbb xrrrrrgg NOVA */
#define B24_rgb     0x00180000  /* RGB */
#define B24_bgr        0x00180001    /* BGR */
#define B32_xrgb     0x00200000    /* xRGB */
#define B32_xbgr     0x00200001    /* xBGR */
#define B32_bgrx     0x00200002    /* BGRx */
#define B32_rgbx     0x00200003  /* RGBx */

Enjoy,

 

Guillaume.

tstscr.zip

[ParanoidLittleMan]

Honestly, I don't see real need for this, because everyone who programmed on Atari ST and compatible followers (TT, Falcon) can see trap #14 function for that in literature, and use it in own program - and that means not more than 50 bytes code in ASM .  But surely this is good for beginners, and to show how to use it, thanx to included sources.

 

Now the really bad part:  your English terms are really wrong. It is called screen or video mode, not 'encoding' . Screen data is just bitmap based, and difference is count of bits for 1 pixel.  In ST video modes it can be 1, 2 or 4 .  So, 2 POW 1 = 2 colors - black and white. 2 POW 2 = 4 colors.

2 POW 4 = 16 colors.

Order of bit planes, and why we have  bit planes ? Yeah, it is interleaved in ST color modes, so for instance in low res there are first 16 bits (2 bytes) of first plane, then 16 bits of second, third, fourth. Then data for next 16 pixels.  It is called interleaved, not 'interlaced' ,

Interlaced is way of sending video data to display (TV, monitor) and you actually can not detect it with SW, because it is in design of video circuit. And it is known that Atari ST generates so called progressive video signal and not interlaced. Here to add that even in that case you may get interlaced picture on your TV (because it expects such signal). I even have screenshot of that at AF).

What is missing from your info about detected video mode is mentioning of available color count for palette. Sure, that is not indicated by that trap call, but knowing video mode and Atari model you can know it - ST has 512 color palette for low and medium res. STE 4096 .

 

Then, Falcon has for instance beside ST compatible modes , not palette based video modes, where screen data gives straight (directly) color of pixel. Like B16 - I let you to find how that mode is exactly called (in English).

 

So, you need to change word 'encoding' to mode in this thread title and in English part of your SW. + 'interlaced' to interleaved. Otherwise, this will remain pretty much confusing.

[moulinaie]

7 hours ago, ParanoidLittleMan said:

Honestly, I don't see real need for this, because everyone who programmed on Atari ST and compatible followers (TT, Falcon) can see trap #14 function for that in literature, and use it in own program - and that means not more than 50 bytes code in ASM .  But surely this is good for beginners, and to show how to use it, thanx to included sources.

For instance, if you're in High Color mode (15-16 bits) does your TRAP #14 call tell you what encoding is really used?

There are four possible encodings:

rrrrrggg gggbbbbb in Motorola or Intel order

xrrrrrgg gggbbbbb in Motorola or Intel order.

 

7 hours ago, ParanoidLittleMan said:

 

Now the really bad part:  your English terms are really wrong. It is called screen or video mode, not 'encoding' .

I insist on "encoding".

When your video mode is 800x600x32 bits, the hardware encoding of every pixel can be (four bytes per pixel):

RGBx or BGRx or xRGB or xBGR.

 

These are four encodings for the same video mode.

 

7 hours ago, ParanoidLittleMan said:

 

Screen data is just bitmap based, and difference is count of bits for 1 pixel.  In ST video modes it can be 1, 2 or 4 .  So, 2 POW 1 = 2 colors - black and white. 2 POW 2 = 4 colors.

2 POW 4 = 16 colors.

Order of bit planes, and why we have  bit planes ? Yeah, it is interleaved in ST color modes, so for instance in low res there are first 16 bits (2 bytes) of first plane, then 16 bits of second, third, fourth. Then data for next 16 pixels.  It is called interleaved, not 'interlaced' ,

Ok I can replace Interlaced with interleaved.

 

7 hours ago, ParanoidLittleMan said:

So, you need to change word 'encoding' to mode in this thread title and in English part of your SW. + 'interlaced' to interleaved. Otherwise, this will remain pretty much confusing.

The whole world should speak french!

 

;-))

 

Guillaume.

 

[ParanoidLittleMan]

?

[ParanoidLittleMan]

Well, by my best knowledge 'encoding' means replacing some data with specific code. Maybe best example is ASCII code for some letter.

So, we have for instance capital letter A - and that's some kind of picture. Instead repeating it's bitmap data every time in storage of text, we use code for it. So, it takes only 1 byte instead some 8, what would be some minimum for decent look (and it is 8 bytes in TOS for color modes, 16 for monochrome) .  Encoding is used in video storage and many other things. Even encrypting could be called some kind of encoding.

Screen data is just bitmap data in latest 30 years (we can say that Sinclair Spectrum used some kind of encoding with it's attributes, but even that sounds strange) . What differs - in your examples too is order of bits, sections, count of used bits. That's just different structure - need to know only order and meaning of all components (bits, bytes, words, long ...) .

Example of encoding would be PAL color system used in analogue TV broadcasting in Eu mostly, somewhere at 1970. Color data was presented not 'directly' - in analogue meaning, like B/W data, but it was modulated with special modulation, what can hold 2 signals, and together with B/W signal could on TV side to restore original RGB colors.   Ah sorry, bad example. It was not used in France ?

 

[mikro]

Ppera, you giving lectures on English seems like professional trolling to me.

 

As for the screen format encoding, I would recommend to look it up first: https://en.wikipedia.org/wiki/RGBA_color_model#Representation. It's a widely used term.

 

 

[ParanoidLittleMan]

It may be in Wiki, may be used by some computer people, programmers. Still wrong. And it is not even English word in fact - code.

Code is just presentation of something via (with) code instead of original data/info. RGB and all those bit planes etc. are just different structure.

 

And bad terminology is present even by large computer companies - Microsoft calls hard disk partition initialization 'formatting' - and that's just wrong. misleading. And best example is case of some SSD or Flash card - still says formatting. There are no tracks at all to format. And what is 'fast format' in Windows - just omitting checking of bad sectors. If there would be real formatting it would take still plenty of time, even without bad sector tests.

 

Sorry, it there is trolling it's you and your MikroSoft ?

 

[Cyprian]

well done @moulinaie

[moulinaie]

15 hours ago, Cyprian_K said:

well done @moulinaie

Thanks!