Emulator aspect ratios?

[yews...@gmail.com]

So, with the Octalyzer we're rendering the screen as 4:3... but it seems AppleWin and JACE render the screen a bit wider.

Is there any particular reason for this? Was the Apple II display not 4:3? (I don't currently have one kicking around to check...)

Should we be rendering our display a bit wider?

Cheers,
Melody.

[Steve Nickolas]

I think most emulators don't even try to get the aspect ratio correct,
they just render one or two pixels for each Apple pixel.

-uso.

[Zellyn]

I put all my actual-screen-photos in an album here: https://goo.gl/photos/M3Ax15Hckc9kZiLQ7

I also included a screenshot of OpenEmulator and Virtual ][ each showing the results of:
HGR: HCOLOR=3
HPLOT 0,0 TO 100,0 TO 100,100 TO 0,100 TO 0,0

You can see that Virtual ][ draws a square, and OpenEmulator (while a bit harder to measure because it also simulates some monitor curvature) comes out at about 1.2

I'll try to draw a square in the center of my real II monitors, and take a couple of straight-on pictures to see what it comes out at exactly. :-)

Zellyn

[Tom Greene]

"Understanding the Apple II" covers this a bit, there is a section titled "Aspect Ratio in the Apple Display" in the chapter on video generation.

https://archive.org/stream/understanding_the_apple_ii#page/n223/mode/1up

Tom

[Michael AppleWin Debugger Dev]

Melody,

Here are the measurements from my two composite monitors this morning.

# Code

HGR2
CALL-151
c051
c054
2000:7f
2027:7f
3fd0:7f
3ff7:7f
c050


# Measurements

Apple Color Monitor
===================
Width: 9.5"
Height: 7"
Diagonal: 12"

Franklin Color Monitor
======================
Width: 9" or 22.5 cm
Height: 6.5" or 16.5 cm
Diagonal: 11"
Aspect Ratio (Width/height):

# Calculations

Apple:
DPI Width: 560 dots/9.5 inches = 58.94 dpi
DPI Height: 192 dots/7 inches = 27.42 dpi
Aspect Ratio (Width/Height): 9.5 / 7 = 1.35

Franklin:
DPI Width: 560 dots/9 inches = 62 dpi
DPI Height: 192 dots/6.5 inches = 29.58 dpi
Aspect Ratio (Width/Height): 9 / 6.5 = 1.38

Ergo, the aspect ratio is very close to 4/3 = 1.33.

Hope this helps!

Cheers
Michael

[Michael AppleWin Debugger Dev]

> it seems AppleWin and JACE render the screen a bit wider.

P.S.

Whoops that code should be:

HGR
CALL-151
2000:7F
2027:7F
3FD0:7F
3FF7:7F
C052

For all version of Applewin we render to 560x384 -- 192 vertical lines doubled.

* In windowed mode we add a 1 pixel black padding so you are seeing a 562x386 "screen."
* In full-screen mode we use 640x480 (IIRC) since 640x400 is non-standard.

[Steve Nickolas]

On Fri, 7 Apr 2017, Michael AppleWin Debugger Dev wrote:

> For all version of Applewin we render to 560x384 -- 192 vertical lines
> doubled.

This is pretty typical; all of my emulators have used an exact integer
multiple of 280x192, typically 560x384.

-uso.

[Michael J. Mahon]

Apple graphics aspect ratio is a slippery subject.

Because the Apple II was designed to use a CRT TV set for its display,
there are numerous design and adjustment issues that enter into the aspect
ratio.

TV sets were designed with a certain amount of overscan, so that the edges
of the raster would not be visible. This resulted in the Apple II video
using only 40 microseconds of the 52.6 us allocated to video information
and only 192 lines of the 241 (non-interlaced) lines allocated to video.
This avoidance of the raster edges was chosen to ensure that the entire
Apple video signal was visible to the user.

Further, CRT receivers and monitors have continuously adjustable height and
width controls.

The vertical size is usually easiest to adjust, though there is often
considerable interaction between the nominal vertical size (height) control
and the vertical linearity control and the vertical hold control. The
horizontal size (width) control is usually harder to access, and has
interaction with the horizontal linearity control.

The numerous compromises involved in these adjustments resulted in varying
amounts of overscan and, not infrequently, in non-circular circles on the
display.

When we transitioned to pixel-oriented LCD displays, the mapping of Apple
pixels to display pixels became an issue.

Most emulators simply map Apple pixels to some multiple of display pixels,
resulting in a fixed pixel shape (often two display pixels high for each
horizontal display pixel).

With a TV set monitor, I often approximated circles by scaling their Apple
pixel width to about 10% more than their height. I notice, however, that
AppleWin looks best with no correction factor, corresponding to "square"
virtual Apple pixels.

Ideally, for faithful graphics display, emulators would provide adjustable
scaling to allow matching to the monitor used by the designer of the
graphics, but that nicety, pervasive with CRT monitors, is rarely
available.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[Michael AppleWin Debugger Dev]

Yup, scaling it up to a non-integer multiple looks pretty horrible. The trade-off is that the aspect ratio isn't entirely correct. :-/