384x240 on a stock Atari 800

[fibrewire]

I was looking at graphic modes of the Atari 8-bit and noticed some interesting aspects of ANTIC. http://en.wikipedia.org/wiki/Atari_8-bit_family#Map_Modes

 

Is it possible to create a 1BPP screen thats 384x240 and if so, how does this compare to the other 320x200 mode?

[Rybags]

It's actually a bit less horizontally. IIRC it's 352 pixels visible horizontally and you also get 4 (?) pixels of "bus noise" to the right of that.

It's not scrunched into the normal 320 area, it's overscan, most old TVs will cut off 10-30 pixels - usually slightly more lost from left than right side.

The 384 pixels (or 48 characters) reference is due to the fact of Antic doing sufficient DMA for that amount of screen display.

 

I measured the video output on an oscilloscope once - if I remember rightly you also get 1 pixel of PMG data that is displayed to the left of the visible 352 pixels. Unsure how many PMG pixels can be shown to the right (remembering PMG pixels are double the hires pixel size)

 

Vertical - 240 scanlines is the normal and "known limit" that Antic can show character or bitmap data. The scanline 240 bug exists in that if the last scanline is hires or if graphics DMA is turned off at a certain time and left off while a hires mode is in force then the display can become distorted.

There is a workaround for the bug, involving either turning DMA off at a strategic time or setting Wide DMA mode at the end of the Antic visible display.

 

Vertical (PMGs) - the scanline 240 bug can be used in a productive sense in that PMG data can be display onscreen outside the normal 240 boundary. Practically never used, and the PMG graphics registers have to be set on the fly by the program as Antic PMG DMA doesn't occur in these areas.

Edited November 9, 2013 by Rybags

[flashjazzcat]

And I have no intention of using this in the GUI before anyone asks (again). Apart from anything else, I can only afford 8KB for the frame buffer.

[Rybags]

Wide mode can be expensive in terms of Ram and CPU cycles lost, and limited usefullness since many TVs won't show the entire display.

 

Using HSCROL mode and shifting everything to the right frees up some DMA cycles, some RAM saving can be had by using LMS on each line - you can use a little less than the 48 byte increment per line due to not all the data being displayed.

 

Extra vertical size in most cases is much more useful - I see no reason for any productivity app not to use something like 208-224 scanlines instead of the default 192.

[fibrewire]

I was thinking more along the lines of terminal emulation without an 80 column card.

Edited November 9, 2013 by fibrewire

[Rybags]

352 pixels = 44 chars at 8 pixels horiz.

50 chars at 7 pixels horiz.

58 at 6, 70 at 5, 88 at 4

 

Realistically, 5 pixels is an ideal minimum, IMO 4 pixels just doesn't cut it for anything resembling easily readable text.

Problem is, rendering odd sized characters like that to a bitmap screen isn't so fast or easy. 4 pixel chars are simple enough since they always occupy the high or low nybble of the byte. Other char sizes mean either shift operations or keeping preshifted font data which eats up memory.

[Matej]

Raster had some demo entries - pictures of such mod...

Was great. But only for static images.

[MrFish]

I see no reason for any productivity app not to use something like 208-224 scanlines instead of the default 192.

 

I've found that 210 is about the best vertical max for NTSC on the monitors that I own (C= 1702 and JVC BM-H1300SU).

Edited November 9, 2013 by MrFish

[flashjazzcat]

Problem is, rendering odd sized characters like that to a bitmap screen isn't so fast or easy. 4 pixel chars are simple enough since they always occupy the high or low nybble of the byte. Other char sizes mean either shift operations or keeping preshifted font data which eats up memory.

 

Or by using lookup tables (7 pages), which are a bit less memory-hungry than pre-shifted fonts (especially since 5-bit fonts need shifting into eight different positions). But 384 pixels horizontal resolution still only gives you 76 columns of 5-bit chars, with an awkward 4 pixels left over. I suppose that's the other reason (as well as speed of rendering) that the less readable 4-bit solutions have prevailed.

 

If RAM's absolutely no object and you don't value your eyesight, there's always the very interesting interleaved 80 column mode Phaeron uses in his Acid test.

[kenjennings]

Wide mode can be expensive in terms of Ram and CPU cycles lost, and limited usefullness since many TVs won't show the entire display.

 

That is actually intentional. Remember this was before LCDs and emulators. Wide playfield allows the graphics to extend past the displayable area of most conventional TVs or CRT. Where most other platforms force borders on the screen (or are diffcult to remove) an Atari fine scrolling playfield with no left and right borders is a nice effect on a regular TV.

[+AtariNerd]

I'm curious, though. Is it possible through some trick of display memory or other means, to condense some of the higher color modes to a smaller area of the display screen? Say, a GTIA mode to the center half of the screen or a 160 mode to half? This way, you'd get the pixel density effect of a higher resolution mode, with the color density of a lower resolution mode. You'd be limited, of course, in how much of the screen is covered, but for something like a logo or title that only would take up a small portion, this might be a interesting compromise.

[Rybags]

Pixel crunching of that nature, not possible. Pixel size is fixed in stone, tied to a ratio of the system clock which itself is also a fixed value.

[potatohead]

No.

 

The clocking of everything is locked to the NTSC / PAL display signals. (sorry)

[Fres]

No.