Articles on Apple II High-Res mode + tips/tricks/hacks

[anthon...@gmail.com]

Would someone be so kind as to forward me a link to a site with some great explanations of the Apple II High Res mode, all of its quirks, and tips/tricks/hacks on how to properly display what you want on it. Also of interest to me is how Ultima V accomplished the water animation; was it via some clever palette switching or just swapping out frames of sprites?

Thanks

[James Davis]

On Thursday, June 8, 2017 at 4:30:32 PM UTC-7, anthon...@gmail.com wrote:
> Would someone be so kind as to forward me a link to a site with some great explanations of the Apple II High Res mode, all of its quirks, and tips/tricks/hacks on how to properly display what you want on it. Also of interest to me is how Ultima V accomplished the water animation; was it via some clever palette switching or just swapping out frames of sprites?
>
> Thanks

Go to:

ftp://public.asimov.net/pub/apple_II/

Download their index. Sort it, re-save it, then search it for all things Apple II.

Here are some "Hi-Res" example links from their index:

ftp://public.asimov.net/pub/apple_II/documentation/hardware/video
ftp://public.asimov.net/pub/apple_II/documentation/programming/6502assembly/Hires reference - The Apple II Forever Anthology_v0.3.pdf
ftp://public.asimov.net/pub/apple_II/documentation/programming/misc/HiRes Color Graphics on the Apple II Computer (by Wozniak).pdf

ftp://public.asimov.net/pub/apple_II/images/productivity/graphics/misc/hires-demo.dsk
ftp://public.asimov.net/pub/apple_II/images/productivity/graphics/misc/HIRES_SECRETS_A.dsk
ftp://public.asimov.net/pub/apple_II/images/productivity/graphics/misc/HIRES_SECRETS_B.dsk

[Antoine Vignau]

There is no palette switching on the 8-bit Apple IIs. U5 uses tiles (small sprites) to display things on the HGR screen. There is a tiny routine that changes the different sprites of the water to animate it.

Antoine

[anthon...@gmail.com]

Wow, thanks James!

[anthon...@gmail.com]

On Friday, June 9, 2017 at 6:18:11 AM UTC-4, Antoine Vignau wrote:
> There is no palette switching on the 8-bit Apple IIs. U5 uses tiles (small sprites) to display things on the HGR screen. There is a tiny routine that changes the different sprites of the water to animate it.
>
> Antoine

Thanks Antoine. Given that there's no timing chip on the II, I'm guessing he just stuffed it in the main game loop.

[Michael Pohoreski]

I would highly recommend starting with my Apple 2 HGR Font Tutorial. It lays out the HGR memory and shows how to do basic 7x8 tile blitting in 6502 assembly.
https://github.com/Michaelangel007/apple2_hgr_font_tutorial

Also, I would recommend my HGR Byte Inspector to play around and fully grok the HGR bits.
https://github.com/Michaelangel007/apple2_hgrbyte

The Apple 2 is just a simple non-linear framebuffer -- there is no color palette. Games just redraw the bitmap tiles for animation. Games may or may not use page flipping -- depending on how advanced they are.

In AppleWin with your favorite game running:

* press F7 to enter the debugger.
* Then type HGR1 to view the graphics page 1. Press a key to return to the debugger.
* Type HGR2 to view the graphics page 2. Press a key to return to the debugger.
* Press F7 to exit the debugger.

Hope this helps. Let us know if you have any more questions!

[Antoine Vignau]

If not in the main loop, at least it is called by it. That refresh tiles routine is located at $300 on (IIRC) Ultima II ;-)

Antoine

[anthon...@gmail.com]

Wow... this is one piece of work Michael! Quick question for you since you're in the font business... I recall high-res games such as Where in the World is Carmen Sandiego having text that looked so mangled an almost unreadable at times due to the color artifacting. Is this something that you handle in your routines or is this impossible to overcome due to the II's color mode limitations?

[Jean-Michel Paris]

Le vendredi 9 juin 2017 01:30:32 UTC+2, anthon...@gmail.com a écrit :
> Would someone be so kind as to forward me a link to a site with some great explanations of the Apple II High Res mode, all of its quirks, and tips/tricks/hacks on how to properly display what you want on it. Also of interest to me is how Ultima V accomplished the water animation; was it via some clever palette switching or just swapping out frames of sprites?
>
> Thanks

For Ultima V, the animation was done by cycling successive water sprites (8 different if I remember). Each new sprite has one vertical pixel offset from the previous one. Everything was pre-drawn of course.

Upon each screen refresh, the next water sprite is used, so is apparent the animation.

[Michael Pohoreski]

Thanks.

Color fringing is sad fact of life due to "Never The Same Color" (NTSC) of crappy / cheap CRTs back in the day. A "clean" emulator could not show "color bleeding" but that isn't "authentic".

I.e.
https://cloud.githubusercontent.com/assets/7876796/5509507/bdfda9d8-876d-11e4-842a-c5a29fcdedad.JPG

Notice the white chroma ghosting when white turns into black.

Also notice that single pixel lines are either magenta/green or blue/orange on the Apple 2. If you want a solid white pixel you MUST use two pixels -- which has the chroma artifacts. :-/

I.e. Third pixel in the top left is a "single" white pixel -- which is two bits.

https://cloud.githubusercontent.com/assets/7876796/5530575/58664c54-89d6-11e4-95f0-6886b770b7e2.JPG

There are also some esoteric off color such as dim orange on certain odd/even byte boundaries but that's a topic for another day.

Hope this helps shed some light on the funky HGR colors.

I'm returning home from business today -- but I'll take a look at one the Carmen games next week and see how bad they are.

Michael

[James Davis]

You're welcome.

You can also check the Apple II Documentation Project:

http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/

[James Davis]

Also, as Beagle Buddy #227, I have to recommend all things Beagle Bros. They had some pretty neat Hi-Res info in their "Peek, Pokes, & Calls," "Tips & Tricks," Docs and on their Hi-Res Program Disks.

[anthon...@gmail.com]

Good tip, I'll check that out! I was a HUGE Beagle Bros fan back in the day but I don't recall there being a Beagle Buddy thing going on... what is that?

[James Davis]

Beagle Bros gave one member of each Apple II computer club all their TimeOut stuff to keep all clubs/members updated, members that already had some of their TO stuff only. So, as their representative for my club, I got all their TO stuff for free.

[anthon...@gmail.com]

Wow...had I known!

[Michael J. Mahon]

Michael Pohoreski <michael....@gmail.com> wrote:
> Thanks.
>
> Color fringing is sad fact of life due to "Never The Same Color" (NTSC)
> of crappy / cheap CRTs back in the day. A "clean" emulator could not
> show "color bleeding" but that isn't "authentic".

That seems a bit harsh, considering that the *only* way that the Apple II
video produces *any* color is by exploiting NTSC behaviors. ;-)

It has a "depth 1" frame buffer, yet, by exploiting NTSC characteristics,
it is capable of quite artistic color graphics.

> I.e.
> https://cloud.githubusercontent.com/assets/7876796/5509507/bdfda9d8-876d-11e4-842a-c5a29fcdedad.JPG
>
> Notice the white chroma ghosting when white turns into black.
>
> Also notice that single pixel lines are either magenta/green or
> blue/orange on the Apple 2. If you want a solid white pixel you MUST use
> two pixels -- which has the chroma artifacts. :-/

But, addressing the OP's question, using fonts that avoid single-pixel
verticals avoids the "unreadable font" problem to a large degree, by
minimizing artifact color saturation.

> I.e. Third pixel in the top left is a "single" white pixel -- which is two bits.
>
> https://cloud.githubusercontent.com/assets/7876796/5530575/58664c54-89d6-11e4-95f0-6886b770b7e2.JPG
>
> There are also some esoteric off color such as dim orange on certain
> odd/even byte boundaries but that's a topic for another day.
>
> Hope this helps shed some light on the funky HGR colors.
>
> I'm returning home from business today -- but I'll take a look at one the
> Carmen games next week and see how bad they are.
>
> Michael
>

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

[anthon...@gmail.com]

Question : Given the last two pictures in your tutorial, how is it that your fonts snapshots (second and third to last screenshot) don't have fringe artifacts (I thought a single vertical white line was impossible to do without having artifacts, and all the fonts with single vertical lines seem fine) and the last screenshot (monitor text mode?) is full of artifacts?

[Michael Pohoreski]

Most of the screenshots are:

- in monochrome mode, and
- before AppleWin 1.25 which has proper NTSC emulation (Sheldon's work was integrated into the video rendering).

Pre AppleWin 1.25 is "sharper" due to NOT emulating the NTSC color fringe artifacts AT ALL. This is why pictures of a real monitor is necessary to compare what an actual CRT monitor is doing -- which AppleWin 1.25+ does. The trade off is that text becomes blurry. You can have proper color fringe accuracy with bluriness or inaccurate color fringes with sharpness. Pick one.

The only good way to get sharp text on a CRT is disable all chroma.

[anthon...@gmail.com]

Jees... makes me wonder why we don't come up with a video card that kills two birds with one stone : 1) finally rid ourselves of the NTSC artifacts and 2) SVGA mode. I'm guessing "Second Sight" did just that.

[Michael J. Mahon]

A simple mod to provide a switch to disable color in graphics modes would
be pretty easy.

[James Davis]

My monitor has such a switch to toggle between color and monochrome (black & white).

[Michael J. Mahon]

Yes, the AppleColor Composite makes this easy.

The lock to monochrome can be done either in the monitor or the computer.

In some ways, it's unfortunate that the color burst wasn't controlled by a
softswitch (but you could always hijack an annunciator). ;-)

[John Brooks]

On Monday, June 12, 2017 at 10:34:48 PM UTC-7, mjm...@aol.com wrote:

BTW: The Apple IIGS has a soft switch to force monochrome output for double hires: bit 5 of $C029.

-JB
@JBrooksBSI

[Michael Pohoreski]

On Thursday, June 8, 2017 at 4:30:32 PM UTC-7, anthon...@gmail.com wrote:

> I recall high-res games such as Where in the World is Carmen Sandiego having text that looked so mangled an almost unreadable at times due to the color artifacting.

I'm finally back home after being up for 21 hours (makes for a REALLY long day.) Having rested slightly I was able to take some pictures and screenshots of WITWICS (Where In The World Is Carmen Sandiego).

Which text in the game are you referring to ?

ACME Detective Window
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Camen_Sandiego_1436.JPG

Logo
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1440.JPG

Name entry
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/Where_In_The_World_Carmen_Sandiego_1444.JPG


I'm going to assume you were referring to the text description on the right.
Lets have some "Fun With Fonts" and analyze the main WITWICS font.

When I first read your description I was getting ready for a pukefest. Thankfully the artists/programmers did a very good job with the font -- all things considered!

An actual photo:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_original.JPG

Here is the screenshot running on AppleWin 1.26 we'll use in our comparison:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_color_singapore.png

Sheldon did a good job emulating the chroma bleed without making our eyes bleed. (My 2nd CRT monitor doesn't have the chrome bleed AS bad but it is still there.)

I'd rate the WITWICS font as a solid 94% -- for the most part it is a good, clean font -- and is quite readable on the Apple 2, minor chroma bleeding notwithstanding that most people didn't really understand digital font typography in the 80's.

Pros:

* Font has a consistent weighting -- 2 pixels wide
* Font design is mostly consistent
* The tittle of the i is at the correct height.
* The leading is consistent
* Kerning is (mostly) consistent with 2 bit gap.


Cons:

* 2 and 5 are fugly -- numerals tend to convey the "signature style" of the font but in this readability is more important IMHO.
* s, and e was designed by an amateur. Note: Notch completely fucked up his lowercase 's' in Minecraft as well. These two glyphs are the litmus test to tell if a person is inexperienced or not.
* Top of the 'm' needs work
* The tail on the comma is mis-aligned to the left edge
* The tail on the g is too short.

Let's clean those glyphs up: 2, 5, e, s, m, and ',' -- I was too lazy to clean up the 'g':
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_color_singapore.png

Here's the zoom in of the original: s, e
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_original.png

The problem is that the it looks like the 's' is leaning 'backwords' instead of respecting the tail on the top right of the 's', and bottom left of the 's'.

And zoom in of the fixed: s, e
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/zoom_fixed.png

When looking at fonts it is very important to see how they look

* in monochrome
* at the actual resolution.

This makes very easy to see how crappy the 'e' and 's' look.

Original monochrome:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/original_mono_singapore.png

Fixed monochrome:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/fixed_mono_singapore.png


What a difference even a single pixel makes! Here is a visual difference of the changes:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/compare/difference_mono_singapore.png


And for reference to show that AppleWin 1.25+ is accurately simulating the chroma bleeding here is the fixed version on real hardware:
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/blob/master/pics/witwics/pictures/picture_fixed.JPG


Guess I'll add two new projects to the TODO list ;-)

* [ ] Ripping the WITWICS font and incorporate into my HGR Font Tutorial
* [ ] Providing a patched WITISCS DSK image with the fixed glyphs

> Is this something that you handle in your routines or is this impossible to overcome due to the II's color mode limitations?

I don't handle any color artifacts because it is basically an unsolvable problem.

The only way to resolve the color artifacts are to show the pixels in monochrome. No, that wasn't meant as a snarky response. My CRT monitors have a push-button to toggle chroma on / off. That fixes the text, but then kills the color of the graphics. :-/ You can have either:

* Sharp, Monochrome OR
* Blurry, Color.

Pick your poison is the standard fare on the Apple. :-(

Color artifacts are basically impossible to fix with the current Apple hardware without modification -- you would basically need to re-implement a clean composite signal and a better CRT.

The fundamental problem is that sending an *analog* signal over a *single composite* wire to a CRT is "blurry as fuck." You basically need:

* 3 channels, RGB or YUV to prevent pixel bleed
* A digital display to minimize cross-talk or "noise"

Keep in mind that the CRT set the "gold standard" for color gamut that only _recently_ was surpassed by OLED. i.e. There was a ~$20K "reference" CRT for color matching in the early 2000's because nothing else came close for color quality of CRT.

Also considering this is 1941's technology with color literally hacked in 1953 we can forgive National Television System Committee / Never The Same Color somewhat. I'm more upset of the retarded 29.97 framerate instead of using a solid 60+ Hz such as 72 Hz. That way film @ 24 Hz would be a perfect 3x multiple but I digress.

Anyways, back to playing with Signed-Distance-Fields and font rendering on modern PC's. :-)
* https://www.shadertoy.com/view/llK3Wm#

Michael

[Brian Patrie]

On 2017-06-13 07:56, John Brooks wrote:
> BTW: The Apple IIGS has a soft switch to force monochrome output for
> double hires: bit 5 of $C029.

Which is what the Type setting in the Display control panel controls.
(It also affects single-hi-res, of course.)

(Remember to check that you're running on a IIgs before playing with
this register. (e.g. the IIc+ uses locations in this area for other
things.) (See
http://umich.edu/~archive/apple2/technotes/tn/misc/TN.MISC.007))

[anthon...@gmail.com]

What??!! How are you getting such crisp clean text? When I run it on my IIc using a VGA converter to my LCD screen it looks terrible. I'll have to get a screenshot and post it.

[James Davis]

On Tuesday, June 13, 2017 at 4:25:47 PM UTC-7, anthon...@gmail.com wrote:
> What??!! How are you getting such crisp clean text? When I run it on my IIc using a VGA converter to my LCD screen it looks terrible. I'll have to get a screenshot and post it.

LCD screens in the PC world require different dithering than CRT screens. Maybe that is the cause of your problem, that there is no dithering in the Apple II world.

[Michael J. Mahon]

You just said it: VGA converter.

That's what's mangling your text.

Decoding NTSC composite video is non-trivial, and most VGA converters take
shortcuts that mess it up.

BTW, 30Hz was originally chosen as the frame rate, to cause line frequency
interference to be static in the display, rather than moving annoyingly.

The frame rate was modified very slightly for composite color, but by that
time, the prevalence of 60/120Hz interference had decreased, and having a
"hum bar" move down the screen slowly was considered acceptable.

Of course, the frame rate could not change appreciably, since the composite
color signal had to display compatibly on monochrome sets.

A frame rate as high as 72Hz would have been unthinkable, since, if a
nominal resolution of just 300x240 was to be maintained, a video broadcast
bandwidth of 13MHz to 14MHz would be required--a modulation bandwidth that
would have used much more spectrum than allocated and presented significant
design challenges.

Television was always (and remains) an engineering tradeoff. Judging past
tradeoffs, with their constraints, by present standards is nonsense.

[anthon...@gmail.com]

> You just said it: VGA converter.
>
> That's what's mangling your text.
>
> Decoding NTSC composite video is non-trivial, and most VGA converters take
> shortcuts that mess it up.
>
> BTW, 30Hz was originally chosen as the frame rate, to cause line frequency
> interference to be static in the display, rather than moving annoyingly.
>
> The frame rate was modified very slightly for composite color, but by that
> time, the prevalence of 60/120Hz interference had decreased, and having a
> "hum bar" move down the screen slowly was considered acceptable.
>
> Of course, the frame rate could not change appreciably, since the composite
> color signal had to display compatibly on monochrome sets.
>
> A frame rate as high as 72Hz would have been unthinkable, since, if a
> nominal resolution of just 300x240 was to be maintained, a video broadcast
> bandwidth of 13MHz to 14MHz would be required--a modulation bandwidth that
> would have used much more spectrum than allocated and presented significant
> design challenges.
>
> Television was always (and remains) an engineering tradeoff. Judging past
> tradeoffs, with their constraints, by present standards is nonsense.
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

I purchased the Apple IIc VGA converter by a2heaven.com (http://a2heaven.com/webshop/index.php?rt=product/product&product_id=135). This attaches to the digital video output so it should be clean, no?

[Michael J. Mahon]

Ah, that's one of the very few NTSC-to-VGA converters that actually works
well with Apple II's.

It sounds like there is some other problem with your setup. Check all
connectors for good connections and, if possible, try another VGA display.

It's always possible that there is a problem with your converter, because
you should be getting much better results.

[anthon...@gmail.com]

Okay, finally found some time to hook it up!

https://drive.google.com/open?id=0B-ZQ2AnS2r_6TldNMHZVbWJWNVU

https://drive.google.com/open?id=0B-ZQ2AnS2r_6aklUQ3VNXzc2RzA

As you can see, it's pretty darn fubar. I have a Dell U3011 monitor that was top of the line a few years ago and works great for me without issue so I doubt it's that.

Any ideas?

[Mark Lemmert]

Hi Michael,

I had been using AppleWIN 1.25.04 for a long time and recently started using AppleWIN 1.26.2.2. I noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that is due to further NTSC adjustments?

Thanks.

Mark

[Nick Westgate]

On Friday, 16 June 2017 09:54:57 UTC+12, anthon...@gmail.com wrote:
> As you can see, it's pretty darn fubar.

What mode is the Apple //c VGA in?
1. Colour – VGA Rendering *Default mode
2. Colour – NTSC Emulation – VGA Rendering

It looks like VGA, so presumably 1. Have you tried mode 2?

Presumably you already have the manual:
http://a2heaven.com/webshop/resources/pdf_document/18/7f/0.pdf

Cheers,
Nick.

[Nick Westgate]

On Friday, 16 June 2017 10:15:24 UTC+12, Mark Lemmert wrote:
> I noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that is due to further NTSC adjustments?

Yes, the 1.26 versions have NTSC emulation. The old VGA-style emulation has been removed. There's a feature request for it.

Cheers,
Nick.

[Nick Westgate]

On Friday, 9 June 2017 11:30:32 UTC+12, anthon...@gmail.com wrote:
> Would someone be so kind as to forward me a link to a site with some great explanations of the Apple II High Res mode, all of its quirks, and tips/tricks/hacks on how to properly display what you want on it.

When I was a kid I learned from David Lubar's excellent "The graph paper" series in Creative Computing. The list is here:
http://www.atarimagazines.com/creative/index/index.php?author=David+Lubar

I compiled all the articles into a PDF some time ago, correcting a page order error in the magazine scans:
https://drive.google.com/file/d/0B3JBd-TShLlLTFVuZFZBc1ZFM00/view

There's also the Assembly Lines books which covers the basics of hires:
https://archive.org/details/AssemblyLinesCompleteWagner

And the book Apple II Graphics and Arcade Game Design is floating around, though I don't have it on my Google Drive at the moment.

Cheers,
Nick.

[anthon...@gmail.com]

I've tried all modes, modes 1 and 2 are almost indistinguishable. Anyone else out there using the vga adapter can confirm/deny Carmen San Diego looks like my screenshot?

[Michael Pohoreski]

I haven't noticed that.

Do you have screenshots so we can compare please?

Thanks

[Michael Pohoreski]

Yes I tried my Apple //c VGA Adapter this morning and can confirm the color modes with WITICS looks like crap on it -- not *quite* as bad as what you are seeing but still pretty terrible. I'll try to post pictures this weekend.

I also cycled through all 16 modes -- the only ones that look decent are the monochrome modes (white, green, and yellow) -- but that kind of defeats the purpose of using it. :-/ i.e. Modes 4-8, and 12-16. Modes 3 and 11 look OK.

Here's the modes from the manual (Thanks Nick for the Link):

1. Colour – VGA Rendering *Default mode
2. Colour – NTSC Emulation – VGA Rendering

3. Monochrome – Shaded Green Screen
4. Monochrome - White Screen
5. Monochrome - White Screen Bold, mostly visible in 80 column mode
6. Monochrome - White Screen x2
7. Monochrome - Green Screen
8. Monochrome – Amber Screen

9. Colour – With Scan Lines
10. Colour – NTSC Emulation – With Scan Lines
11. Monochrome – Shaded Green Screen – With Scan Lines
12. Monochrome – White Screen – With Scan Lines
13. Monochrome – White Screen Bold – With Scan Lines
14. Monochrome – White Screen x2– With Scan Lines
15. Monochrome – Green Screen – With Scan Lines
16. Monochrome – Amber Screen – With Scan Lines

Hopefully there will be a version 2 someday that fixes the horrible color artifacts.

[James Davis]

On Friday, June 16, 2017 at 5:31:52 AM UTC-7, anthon...@gmail.com wrote:
> I've tried all modes, modes 1 and 2 are almost indistinguishable. Anyone else out there using the vga adapter can confirm/deny Carmen San Diego looks like my screenshot?

Have you tried a different (OEM's) VGA cable? Maybe you have a faulty cable.

[anthon...@gmail.com]

Michael independently confirmed having the same issue but I do plan on giving another cable a try very soon.

[Michael Pohoreski]

I'll be eventually merging this into my HGR Font Tutorial, but here is some preliminary information on how WITWICS (Where In The World Is Carmen Sandiego) is doing its font rendering.

There are two fonts in the WITWICS:

FontA @ $F800, DataA @ $F8B6
FontB @ $A500, DataB @ A5B66

Font A is 6x9 pixels (without the leading.) The glyph structure is

```c
struct FontGlyph
{
int8_t width;
int8_t height;
int8_t bits[height];
};
```

Yes, it wastes an entire extra byte for the height instead of nibble packing the width and height. ** Sigh.** This wastes a total of $7C-$21 = $5B (91) bytes. That's room for another 10+ glyphs!

There is an array of 16-bit offsets to each glyph.

```c
struct FontHeader
{
uint16_t offset[ GLYPHS ];
};
```



| Char|Hex | Base |Offset| Addr |
|:---:|:---|:----:|:----:|:----:|
| `!` | 21 | F800 | 00B6 | F8B6 |
| `"` | 22 | F802 | 00BF | F8BF |
| `#` | 23 | F804 | 00C8 | F8C8 |
| `$` | 24 | F806 | 00D1 | F8D1 |
| `%` | 25 | F808 | 00DA | F8DA |
| `&` | 26 | F80A | 00E3 | F8E3 |
| `\``| 27 | F80C | 00EC | F8EC |
| `(` | 28 | F80E | 00F5 | F8F5 |
| `)` | 29 | F810 | 00FE | F8FE |
| `*` | 2A | F812 | 0107 | F907 |
| `+` | 2B | F814 | 0110 | F910 |
| `,` | 2C | F816 | 0119 | F919 |
| `-` | 2D | F818 | 0124 | F924 |
| `.` | 2E | F81A | 012D | F92D |
| `/` | 2F | F81C | 0136 | F936 |
| `0` | 30 | F81E | 013F | F93F |
| `1` | 31 | F820 | 0148 | F948 |
| `2` | 32 | F822 | 0151 | F951 |
| `3` | 33 | F824 | 015A | F95A |
| `4` | 34 | F826 | 0163 | F963 |
| `5` | 35 | F828 | 016C | F96C |
| `6` | 36 | F82A | 0175 | F975 |
| `7` | 37 | F82C | 017E | F97E |
| `8` | 38 | F82E | 0187 | F987 |
| `9` | 39 | F830 | 0190 | F990 |
| `:` | 3A | F832 | 0199 | F999 |
| `;` | 3B | F834 | 01A2 | F9A2 |
| `<` | 3C | F836 | 01AD | F9AD |
| `=` | 3D | F838 | 01B6 | F9B6 |
| `>` | 3E | F83A | 01BF | F9BF |
| `?` | 3F | F83C | 01C8 | F9C8 |
| `@` | 40 | F83E | 01D1 | F9D1 |
| `A` | 41 | F840 | 01DA | F9DA |
| `B` | 42 | F842 | 01E3 | F9E3 |
| `C` | 43 | F844 | 01EC | F9EC |
| `D` | 44 | F846 | 01F5 | F9F5 |
| `E` | 45 | F848 | 01FE | F9FE |
| `F` | 46 | F84A | 0207 | FA07 |
| `G` | 47 | F84C | 0210 | FA10 |
| `H` | 48 | F84E | 0219 | FA19 |
| `I` | 49 | F850 | 0222 | FA22 |
| `J` | 4A | F852 | 022B | FA2B |
| `K` | 4B | F854 | 0234 | FA34 |
| `L` | 4C | F856 | 023D | FA3D |
| `M` | 4D | F858 | 0246 | FA46 |
| `N` | 4E | F85A | 024F | FA4F |
| `O` | 4F | F85C | 0258 | FA58 |
| `P` | 50 | F85E | 0261 | FA61 |
| `Q` | 51 | F860 | 026A | FA6A |
| `R` | 52 | F862 | 0273 | FA73 |
| `S` | 53 | F864 | 027C | FA7C |
| `T` | 54 | F866 | 0285 | FA85 |
| `U` | 55 | F868 | 028E | FA8E |
| `V` | 56 | F86A | 0297 | FA97 |
| `W` | 57 | F86C | 02A0 | FAA0 |
| `X` | 58 | F86E | 02A9 | FAA9 |
| `Y` | 59 | F870 | 02B2 | FAB2 |
| `Z` | 5A | F872 | 02BB | FABB |
| `[` | 5B | F874 | 02C4 | FAC4 |
| `\\`| 5C | F876 | 02CD | FACD |
| `]` | 5D | F878 | 02D6 | FAD6 |
| `^` | 5E | F87A | 02DF | FADF |
| `_` | 5F | F87C | 02E3 | FAE3 |
| `@` | 60 | F87E | 02ED | FAED |
| `a` | 61 | F880 | 02F8 | FAF8 |
| `b` | 62 | F882 | 0301 | FB01 |
| `c` | 63 | F884 | 030A | FB0A |
| `d` | 64 | F886 | 0313 | FB13 |
| `e` | 65 | F888 | 031C | FB1C |
| `f` | 66 | F88A | 0325 | FB25 |
| `g` | 67 | F88C | 032E | FB2E |
| `h` | 68 | F88E | 0339 | FB39 |
| `i` | 69 | F890 | 0342 | FB42 |
| `j` | 6A | F892 | 034B | FB4B |
| `k` | 6B | F894 | 0356 | FB56 |
| `l` | 6C | F896 | 035F | FB5F |
| `m` | 6D | F898 | 0368 | FB68 |
| `n` | 6E | F89A | 0371 | FB71 |
| `o` | 6F | F89C | 037A | FB7A |
| `p` | 70 | F89E | 0383 | FB83 |
| `q` | 71 | F8A0 | 038E | FB8E |
| `r` | 72 | F8A2 | 0399 | FB99 |
| `s` | 73 | F8A4 | 03A2 | FBA2 |
| `t` | 74 | F8A6 | 03AB | FBAB |
| `u` | 75 | F8A8 | 03B4 | FBB4 |
| `v` | 76 | F8AA | 03BD | FBBD |
| `w` | 77 | F8AC | 03C6 | FBC6 |
| `x` | 78 | F8AE | 03CF | FBCF |
| `y` | 79 | F8B0 | 03D8 | FBD8 |
| `z` | 7A | F8B2 | 03E3 | FBE3 |
| `{` | 7B | F8B4 | 02A0 | FAA0 |


You can copy/paste this script into AppleWin's debugger for some of the funcs and data:

```
db zGlyphW 33 // @A244
db zGlyphH 34 // @A250
db zGlyphPtr E4
sym GetFontAPtr = A21A
sym GetFontBPtr = A22E
da fontAbase F800:F8B5
da fontBbase A500:A565
db aHGRhiY D361:D420
db aHGRloY D421:D4E0
```

More info. coming later such as the "texture atlas", glyph rendering, etc.

[anthon...@gmail.com]

On Saturday, June 17, 2017 at 1:32:47 PM UTC-4, Michael Pohoreski wrote:
> I'll be eventually merging this into my HGR Font Tutorial, but here is some preliminary information on how WITWICS (Where In The World Is Carmen Sandiego) is doing its font rendering.
>
> There are two fonts in the WITWICS:
>
> FontA @ $F800, DataA @ $F8B6
> FontB @ $A500, DataB @ A5B66
>

Damn Michael, you're hardcore!

[Michael Pohoreski]

Well ...

... I did design the world's smallest readable font with 2x2 lowercase ...
https://github.com/Michaelangel007/nanofont3x4

... and designed my own 5x7 TrueType Font specifically for coding inspired by the Apple 2 ...
https://fontstruct.com/fontstructions/show/670968/program5x7b

... so "guilty as charged." :-)

What else can I say except that the Apple's funky / esoteric half-pixel shift was responsible for my love of small bitmap fonts on the Apple 2, HP48, etc.

I love seeing what bitmap fonts are used in games.

[Michael Pohoreski]

I was bored this morning so let's chop, dissect, and re-assembly the WITWICS font.

First, we can save the font via AppleWin's debugger:

bsave "witwics_6x9.bin",f800:f8eb

Inspecting the font we notice

; Head Size: 182 bytes
; Data Size: 823 bytes
; ====================
; File Size: 1005 bytes

Let's get rid off that idiotic 16-bit offset header along with the explicit glyph height stored in each glyph and make it implicit -- since we KNOW this font is 9 scanlines -- that is 9 bytes / glyph. We will also move all the font metric data (width) into a separate table (array).


Original Font Size: 3ec
Optimized Font Size: 38e

That's a saving of a whopping $5E (94) bytes!

Here is the assembly source ...

- - - 8< opt6x9.s - - -

; ===========
; 6x9 Bitmaps
; ===========
glyphs6x9
DB $03,$03,$03,$03,$00,$03,$03,$00,$00 ; '!
DB $1B,$1B,$1B,$00,$00,$00,$00,$00,$00 ; '"
DB $36,$7F,$7F,$36,$7F,$7F,$36,$00,$00 ; '#
DB $3E,$6B,$0B,$3E,$68,$6B,$3E,$00,$00 ; '$
DB $63,$73,$38,$1C,$0E,$67,$63,$00,$00 ; '%
DB $07,$07,$05,$00,$35,$57,$35,$00,$00 ; '&
DB $03,$03,$03,$00,$00,$00,$00,$00,$00 ; ''
DB $0C,$06,$03,$03,$03,$06,$0C,$00,$00 ; '(
DB $03,$06,$0C,$0C,$0C,$06,$03,$00,$00 ; ')
DB $49,$2A,$1C,$7F,$1C,$2A,$49,$00,$00 ; '*
DB $00,$0C,$0C,$3F,$3F,$0C,$0C,$00,$00 ; '+
DB $00,$00,$00,$00,$00,$06,$06,$02,$01 ; ',
DB $00,$00,$00,$3F,$3F,$00,$00,$00,$00 ; '-
DB $00,$00,$00,$00,$00,$03,$03,$00,$00 ; '.
DB $60,$70,$38,$1C,$0E,$07,$03,$00,$00 ; '/
DB $1C,$3E,$63,$63,$63,$3E,$1C,$00,$00 ; '0
DB $0C,$0E,$0F,$0C,$0C,$0C,$3F,$00,$00 ; '1
DB $3E,$63,$60,$3E,$03,$03,$7F,$00,$00 ; '2
DB $3E,$63,$60,$38,$60,$63,$3E,$00,$00 ; '3
DB $38,$3C,$36,$33,$7F,$30,$30,$00,$00 ; '4
DB $7F,$03,$3E,$60,$60,$63,$3E,$00,$00 ; '5
DB $3E,$63,$03,$3F,$63,$63,$3E,$00,$00 ; '6
DB $3E,$63,$60,$30,$18,$0C,$0C,$00,$00 ; '7
DB $3E,$63,$63,$3E,$63,$63,$3E,$00,$00 ; '8
DB $3E,$63,$63,$7E,$60,$63,$3E,$00,$00 ; '9
DB $00,$00,$03,$03,$00,$03,$03,$00,$00 ; ':
DB $00,$00,$06,$06,$00,$06,$06,$02,$01 ; ';
DB $18,$0C,$06,$03,$06,$0C,$18,$00,$00 ; '<
DB $00,$3F,$3F,$00,$3F,$3F,$00,$00,$00 ; '=
DB $03,$06,$0C,$18,$0C,$06,$03,$00,$00 ; '>
DB $1E,$33,$18,$0C,$0C,$00,$0C,$00,$00 ; '?
DB $07,$05,$07,$3D,$10,$10,$10,$00,$00 ; '@
DB $0C,$1E,$33,$33,$3F,$33,$33,$00,$00 ; 'A
DB $1F,$33,$33,$1F,$33,$33,$1F,$00,$00 ; 'B
DB $1E,$33,$03,$03,$03,$33,$1E,$00,$00 ; 'C
DB $1F,$33,$33,$33,$33,$33,$1F,$00,$00 ; 'D
DB $3F,$03,$03,$1F,$03,$03,$3F,$00,$00 ; 'E
DB $3F,$03,$03,$1F,$03,$03,$03,$00,$00 ; 'F
DB $1E,$33,$03,$3B,$33,$33,$1E,$00,$00 ; 'G
DB $33,$33,$33,$3F,$33,$33,$33,$00,$00 ; 'H
DB $0F,$06,$06,$06,$06,$06,$0F,$00,$00 ; 'I
DB $30,$30,$30,$30,$30,$33,$1E,$00,$00 ; 'J
DB $33,$1B,$0F,$07,$0F,$1B,$33,$00,$00 ; 'K
DB $03,$03,$03,$03,$03,$03,$3F,$00,$00 ; 'L
DB $21,$33,$3F,$3F,$33,$33,$33,$00,$00 ; 'M
DB $33,$37,$37,$3F,$3B,$3B,$33,$00,$00 ; 'N
DB $1E,$33,$33,$33,$33,$33,$1E,$00,$00 ; 'O
DB $1F,$33,$33,$1F,$03,$03,$03,$00,$00 ; 'P
DB $1E,$33,$33,$33,$3B,$3B,$3E,$00,$00 ; 'Q
DB $1F,$33,$33,$1F,$0F,$1B,$33,$00,$00 ; 'R
DB $1E,$33,$03,$1E,$30,$33,$1E,$00,$00 ; 'S
DB $3F,$0C,$0C,$0C,$0C,$0C,$0C,$00,$00 ; 'T
DB $33,$33,$33,$33,$33,$33,$1E,$00,$00 ; 'U
DB $33,$33,$33,$33,$33,$1E,$0C,$00,$00 ; 'V
DB $33,$33,$33,$3F,$3F,$33,$21,$00,$00 ; 'W
DB $33,$33,$3F,$1E,$3F,$33,$33,$00,$00 ; 'X
DB $33,$33,$33,$1E,$0C,$0C,$0C,$00,$00 ; 'Y
DB $3F,$30,$18,$0C,$06,$03,$3F,$00,$00 ; 'Z
DB $0F,$03,$03,$03,$03,$03,$0F,$00,$00 ; '[
DB $03,$07,$0E,$1C,$38,$70,$60,$00,$00 ; '\
DB $0F,$0C,$0C,$0C,$0C,$0C,$0F,$00,$00 ; ']
DB $1E,$33,$00,$00,$00,$00,$00,$00,$00 ; '^
DB $00,$00,$00,$00,$00,$00,$00,$7F,$00 ; '_
DB $00,$00,$00,$00,$00,$06,$06,$02,$01 ; '`
DB $00,$00,$1E,$30,$3E,$33,$3E,$00,$00 ; 'a
DB $03,$03,$1F,$33,$33,$33,$1F,$00,$00 ; 'b
DB $00,$00,$1E,$33,$03,$33,$1E,$00,$00 ; 'c
DB $30,$30,$3E,$33,$33,$33,$3E,$00,$00 ; 'd
DB $00,$00,$1E,$33,$3F,$03,$1E,$00,$00 ; 'e
DB $1C,$06,$06,$0F,$06,$06,$06,$00,$00 ; 'f
DB $00,$00,$1E,$33,$33,$33,$3E,$30,$1E ; 'g
DB $03,$03,$1F,$33,$33,$33,$33,$00,$00 ; 'h
DB $03,$00,$03,$03,$03,$03,$03,$00,$00 ; 'i
DB $00,$18,$00,$18,$18,$18,$18,$1B,$0E ; 'j
DB $03,$03,$1B,$0F,$07,$0F,$1B,$00,$00 ; 'k
DB $03,$03,$03,$03,$03,$03,$03,$00,$00 ; 'l
DB $00,$00,$13,$3F,$3F,$33,$33,$00,$00 ; 'm
DB $00,$00,$1F,$33,$33,$33,$33,$00,$00 ; 'n
DB $00,$00,$1E,$33,$33,$33,$1E,$00,$00 ; 'o
DB $00,$00,$1F,$33,$33,$33,$1F,$03,$03 ; 'p
DB $00,$00,$3E,$33,$33,$33,$3E,$30,$30 ; 'q
DB $00,$00,$0F,$1B,$03,$03,$03,$00,$00 ; 'r
DB $00,$00,$1E,$03,$1E,$30,$1E,$00,$00 ; 's
DB $06,$06,$0F,$06,$06,$36,$1C,$00,$00 ; 't
DB $00,$00,$33,$33,$33,$33,$1E,$00,$00 ; 'u
DB $00,$00,$33,$33,$33,$1E,$0C,$00,$00 ; 'v
DB $00,$00,$33,$33,$3F,$3F,$12,$00,$00 ; 'w
DB $00,$00,$33,$33,$1E,$33,$33,$00,$00 ; 'x
DB $00,$00,$33,$33,$33,$33,$3E,$30,$1E ; 'y
DB $00,$00,$3F,$18,$0C,$06,$3F,$00,$00 ; 'z
DB $33,$33,$33,$3F,$3F,$33,$21,$00,$00 ; '{

; ===========
; 6x9 Metrics
; ===========
widths6x9
DB $02 ; '!
DB $05 ; '"
DB $07 ; '#
DB $07 ; '$
DB $07 ; '%
DB $07 ; '&
DB $02 ; ''
DB $04 ; '(
DB $04 ; ')
DB $07 ; '*
DB $06 ; '+
DB $03 ; ',
DB $06 ; '-
DB $02 ; '.
DB $07 ; '/
DB $07 ; '0
DB $07 ; '1
DB $07 ; '2
DB $07 ; '3
DB $07 ; '4
DB $07 ; '5
DB $07 ; '6
DB $07 ; '7
DB $07 ; '8
DB $07 ; '9
DB $02 ; ':
DB $03 ; ';
DB $05 ; '<
DB $06 ; '=
DB $05 ; '>
DB $06 ; '?
DB $06 ; '@
DB $06 ; 'A
DB $06 ; 'B
DB $06 ; 'C
DB $06 ; 'D
DB $06 ; 'E
DB $06 ; 'F
DB $06 ; 'G
DB $06 ; 'H
DB $04 ; 'I
DB $06 ; 'J
DB $06 ; 'K
DB $06 ; 'L
DB $06 ; 'M
DB $06 ; 'N
DB $06 ; 'O
DB $06 ; 'P
DB $06 ; 'Q
DB $06 ; 'R
DB $06 ; 'S
DB $06 ; 'T
DB $06 ; 'U
DB $06 ; 'V
DB $06 ; 'W
DB $06 ; 'X
DB $06 ; 'Y
DB $06 ; 'Z
DB $04 ; '[
DB $07 ; '\
DB $04 ; ']
DB $06 ; '^
DB $07 ; '_
DB $03 ; '`
DB $06 ; 'a
DB $06 ; 'b
DB $06 ; 'c
DB $06 ; 'd
DB $06 ; 'e
DB $05 ; 'f
DB $06 ; 'g
DB $06 ; 'h
DB $02 ; 'i
DB $05 ; 'j
DB $05 ; 'k
DB $02 ; 'l
DB $06 ; 'm
DB $06 ; 'n
DB $06 ; 'o
DB $06 ; 'p
DB $06 ; 'q
DB $05 ; 'r
DB $06 ; 's
DB $06 ; 't
DB $06 ; 'u
DB $06 ; 'v
DB $06 ; 'w
DB $06 ; 'x
DB $06 ; 'y
DB $06 ; 'z
DB $06 ; '{

Next post I'll show some code to render these glyphs.

[Michael Pohoreski]

With our "ripped" font organized to be more programmer friendly here is a demo to render a string.
NOTE: I have *not* optimized this -- I just threw this together as a "proof of concept" of how to draw a proportional font.


- - - 8< draw_witwics.s - - -


HgrLo EQU $E5 ; Low byte Pointer to screen destination
HgrHi EQU $E6 ; High byte Pointer to screen destination

zSaveY EQU $F4

Tmp0 EQU $F5 ; Glyph bits straddle first byte
Tmp1 EQU $F6 ; Glyph bits straddle second byte

zChar EQU $F7 ; Which Glyph to draw
zFontPtr EQU $F8 ; 16-bit address of glyph
zRow EQU $FA ; current row to draw
cursorXbits EQU $FB ; bit column offset in byte 0 .. $06 ... x mod 7
cursorXbyte EQU $FC ; byte column offset in row 0 .. $27
cursorY EQU $FD
zString EQU $FE ; 16-bit Pointer to ASCIIZ string

FONT_HEIGHT EQU 9

HGR EQU $F3E2 ; Applesoft
PRNTAX EQU $F941 ; debug only
PRBYTE EQU $FDDA ; debug only


ORG $900

; ========================================================================
Main
JSR HGR
JSR MoveHome
JSR DemoString
RTS


; ========================================================================
DemoChar
LDA #'M'
JSR DrawChar
RTS


; ========================================================================
DemoString
LDX #>Text
LDY #<Text
JSR DrawString
RTS

Text
ASC "Hello World Carmen Sandiego!"
DB 0


; ========================================================================
MoveHome
LDA #0 ; bit offset within byte
LDX #0 ; col
LDY #0 ; row
STA cursorXbits
STX cursorXbyte
STY cursorY
RTS


; ========================================================================
DrawString
STX zString+1
STY zString+0
LDY #0

_DrawString
LDA (zString),Y
AND #$7F
BEQ _StringDone
JSR DrawChar
INY
BNE _DrawString

_StringDone
RTS

; Regs
; A - trashed
; Y - saved
; X - trashed
; ========================================================================
DrawChar
STY zSaveY ; Convenience to caller

CMP #$20
BNE NonSpace

LDA #2 ; space = 2 pixel wide, will ALSO add gap
JMP MoveSpace

NonSpace
SEC
SBC #$21 ; glyphs including before 0x20 SPACE not stored
STA zChar
STA zFontPtr

; SrcAddress
; pFontAddress = glyphs6x9[ 9*c ]
; x*9 = x*8 + 1
LDY #0
STY zFontPtr+1

LDX #3 ; High C Low 2^3 = 8
CalcOffset ; 76543210 C 76543210 bits
ASL zFontPtr ; <------- ? 0abcdefg address
ROL zFontPtr+1 ; <------0 0 abcdefg0
DEX ; <-----0a a bcdefg00
BNE CalcOffset ; <----0ab b cdefg000

CLC
LDA zChar ;+00000000 0abcdefg
ADC zFontPtr ;=000000hi jklmnefg
STA LoadGlyph+1 ; *** SELF MODIFIES: low byte address
BCC NoPage
INC zFontPtr+1
NoPage
LDA #>glyphs6x9
CLC
ADC zFontPtr+1
STA LoadGlyph+2 ; *** SELF MODIFIES: high byte address


LDX #0 ; row

StartRow
STX zRow

; DstAddress
LDY cursorY
LDA aHGRloY,Y
STA HgrLo
LDA aHGRhiY,Y
ORA #$20 ; HGR Page 1
STA HgrHi
INC cursorY

; Glyph bits for Byte0 and Byte1
LDA #0
STA Tmp1

LoadGlyph
LDA glyphs6x9 ; *** SELF MODIFIED *** @ $980

LDX cursorXbits ; if we are drawing byte aligned
BEQ NoSpanBytes ; then only draw 1 byte

SplitGlyph ; 76543221 76543210
CLC
ASL ; 00000000 xabcdefg
BMI SetPixel ; _________^

CLC
DB $44 ; SKIP NEXT INSTRUCTIONS: bit $zp -- ignore N V Z

SetPixel
SEC ;

AND #$7F ; 01111111
ROL Tmp1 ; xxxxxxx1
DEX
BNE SplitGlyph
STA Tmp0

NoSpanBytes
LDY cursorXbyte ; col
ORA (HgrLo),Y
STA (HgrLo),Y

LDA Tmp1
BEQ NextRow
INY
ORA (HgrLo),Y
STA (HgrLo),Y
DEY

NextRow
INC LoadGlyph+1
BNE GlyphPage
INC LoadGlyph+2
GlyphPage

LDX zRow
INX
CPX #FONT_HEIGHT
BNE StartRow


; Drawing all done
; Move Cursor back to initial row
LDA cursorY
SEC
SBC #FONT_HEIGHT
STA cursorY

; Update Cursor x position
LDX zChar ; x += widths[ c ]
LDA widths6x9,X
MoveSpace
CLC
ADC #1 ; 1 px gap between glyphs
ADC cursorXbits

CMP #7 ; bits 0..6 in same byte
BCC SameColumn ; move to next byte column?
SBC #7
INC cursorXbyte
SameColumn
STA cursorXbits

LDY zSaveY ; Convenience to caller
RTS

; ========================================================================
Newline
LDA cursorY
CLC
ADC #FONT_HEIGHT
STA cursorY
RTS

; ----- align to page -----
DS \,$00

PUT opt6x9.s

; 192*2 = 384 bytes
PUT hgrtable.s

- - - 8< - - -


This generates this binary that we can paste into AppleWin, Virtual ][ etc.

The font glyphs starts at $A00,
The font widths starts at $D33

The HGR Y Low byte Table starts at $D8E,
The HGR Y High byte Table starts at $E4E.

CALL-151
0900:20 E2 F3 20 35 09 20 10
0908:09 60 A9 4D 20 55 09 60
0910:A2 09 A0 18 20 42 09 60
0918:C8 E5 EC EC EF A0 D7 EF
0920:F2 EC E4 A0 C3 E1 F2 ED
0928:E5 EE A0 D3 E1 EE E4 E9
0930:E5 E7 EF A1 00 A9 00 A2
0938:00 A0 00 85 FB 86 FC 84
0940:FD 60 86 FF 84 FE A0 00
0948:B1 FE 29 7F F0 06 20 55
0950:09 C8 D0 F4 60 84 F4 C9
0958:20 D0 05 A9 02 4C E2 09
0960:38 E9 21 85 F7 85 F8 A0
0968:00 84 F9 A2 03 06 F8 26
0970:F9 CA D0 F9 18 A5 F7 65
0978:F8 8D A1 09 90 02 E6 F9
0980:A9 0A 18 65 F9 8D A2 09
0988:A2 00 86 FA A4 FD B9 8E
0990:0D 85 E5 B9 4E 0E 09 20
0998:85 E6 E6 FD A9 00 85 F6
09A0:AD 00 0A A6 FB F0 10 18
09A8:0A 30 02 18 44 38 29 7F
09B0:26 F6 CA D0 F2 85 F5 A4
09B8:FC 11 E5 91 E5 A5 F6 F0
09C0:06 C8 11 E5 91 E5 88 EE
09C8:A1 09 D0 03 EE A2 09 A6
09D0:FA E8 E0 09 D0 B4 A5 FD
09D8:38 E9 09 85 FD A6 F7 BD
09E0:33 0D 18 69 01 65 FB C9
09E8:07 90 04 E9 07 E6 FC 85
09F0:FB A4 F4 60 A5 FD 18 69
09F8:09 85 FD 60 00 00 00 00
0A00:03 03 03 03 00 03 03 00
0A08:00 1B 1B 1B 00 00 00 00
0A10:00 00 36 7F 7F 36 7F 7F
0A18:36 00 00 3E 6B 0B 3E 68
0A20:6B 3E 00 00 63 73 38 1C
0A28:0E 67 63 00 00 07 07 05
0A30:00 35 57 35 00 00 03 03
0A38:03 00 00 00 00 00 00 0C
0A40:06 03 03 03 06 0C 00 00
0A48:03 06 0C 0C 0C 06 03 00
0A50:00 49 2A 1C 7F 1C 2A 49
0A58:00 00 00 0C 0C 3F 3F 0C
0A60:0C 00 00 00 00 00 00 00
0A68:06 06 02 01 00 00 00 3F
0A70:3F 00 00 00 00 00 00 00
0A78:00 00 03 03 00 00 60 70
0A80:38 1C 0E 07 03 00 00 1C
0A88:3E 63 63 63 3E 1C 00 00
0A90:0C 0E 0F 0C 0C 0C 3F 00
0A98:00 3E 63 60 3E 03 03 7F
0AA0:00 00 3E 63 60 38 60 63
0AA8:3E 00 00 38 3C 36 33 7F
0AB0:30 30 00 00 7F 03 3E 60
0AB8:60 63 3E 00 00 3E 63 03
0AC0:3F 63 63 3E 00 00 3E 63
0AC8:60 30 18 0C 0C 00 00 3E
0AD0:63 63 3E 63 63 3E 00 00
0AD8:3E 63 63 7E 60 63 3E 00
0AE0:00 00 00 03 03 00 03 03
0AE8:00 00 00 00 06 06 00 06
0AF0:06 02 01 18 0C 06 03 06
0AF8:0C 18 00 00 00 3F 3F 00
0B00:3F 3F 00 00 00 03 06 0C
0B08:18 0C 06 03 00 00 1E 33
0B10:18 0C 0C 00 0C 00 00 07
0B18:05 07 3D 10 10 10 00 00
0B20:0C 1E 33 33 3F 33 33 00
0B28:00 1F 33 33 1F 33 33 1F
0B30:00 00 1E 33 03 03 03 33
0B38:1E 00 00 1F 33 33 33 33
0B40:33 1F 00 00 3F 03 03 1F
0B48:03 03 3F 00 00 3F 03 03
0B50:1F 03 03 03 00 00 1E 33
0B58:03 3B 33 33 1E 00 00 33
0B60:33 33 3F 33 33 33 00 00
0B68:0F 06 06 06 06 06 0F 00
0B70:00 30 30 30 30 30 33 1E
0B78:00 00 33 1B 0F 07 0F 1B
0B80:33 00 00 03 03 03 03 03
0B88:03 3F 00 00 21 33 3F 3F
0B90:33 33 33 00 00 33 37 37
0B98:3F 3B 3B 33 00 00 1E 33
0BA0:33 33 33 33 1E 00 00 1F
0BA8:33 33 1F 03 03 03 00 00
0BB0:1E 33 33 33 3B 3B 3E 00
0BB8:00 1F 33 33 1F 0F 1B 33
0BC0:00 00 1E 33 03 1E 30 33
0BC8:1E 00 00 3F 0C 0C 0C 0C
0BD0:0C 0C 00 00 33 33 33 33
0BD8:33 33 1E 00 00 33 33 33
0BE0:33 33 1E 0C 00 00 33 33
0BE8:33 3F 3F 33 21 00 00 33
0BF0:33 3F 1E 3F 33 33 00 00
0BF8:33 33 33 1E 0C 0C 0C 00
0C00:00 3F 30 18 0C 06 03 3F
0C08:00 00 0F 03 03 03 03 03
0C10:0F 00 00 03 07 0E 1C 38
0C18:70 60 00 00 0F 0C 0C 0C
0C20:0C 0C 0F 00 00 1E 33 00
0C28:00 00 00 00 00 00 00 00
0C30:00 00 00 00 00 7F 00 00
0C38:00 00 00 00 06 06 02 01
0C40:00 00 1E 30 3E 33 3E 00
0C48:00 03 03 1F 33 33 33 1F
0C50:00 00 00 00 1E 33 03 33
0C58:1E 00 00 30 30 3E 33 33
0C60:33 3E 00 00 00 00 1E 33
0C68:3F 03 1E 00 00 1C 06 06
0C70:0F 06 06 06 00 00 00 00
0C78:1E 33 33 33 3E 30 1E 03
0C80:03 1F 33 33 33 33 00 00
0C88:03 00 03 03 03 03 03 00
0C90:00 00 18 00 18 18 18 18
0C98:1B 0E 03 03 1B 0F 07 0F
0CA0:1B 00 00 03 03 03 03 03
0CA8:03 03 00 00 00 00 13 3F
0CB0:3F 33 33 00 00 00 00 1F
0CB8:33 33 33 33 00 00 00 00
0CC0:1E 33 33 33 1E 00 00 00
0CC8:00 1F 33 33 33 1F 03 03
0CD0:00 00 3E 33 33 33 3E 30
0CD8:30 00 00 0F 1B 03 03 03
0CE0:00 00 00 00 1E 03 1E 30
0CE8:1E 00 00 06 06 0F 06 06
0CF0:36 1C 00 00 00 00 33 33
0CF8:33 33 1E 00 00 00 00 33
0D00:33 33 1E 0C 00 00 00 00
0D08:33 33 3F 3F 12 00 00 00
0D10:00 33 33 1E 33 33 00 00
0D18:00 00 33 33 33 33 3E 30
0D20:1E 00 00 3F 18 0C 06 3F
0D28:00 00 33 33 33 3F 3F 33
0D30:21 00 00 02 05 07 07 07
0D38:07 02 04 04 07 06 03 06
0D40:02 07 07 07 07 07 07 07
0D48:07 07 07 07 02 03 05 06
0D50:05 06 06 06 06 06 06 06
0D58:06 06 06 04 06 06 06 06
0D60:06 06 06 06 06 06 06 06
0D68:06 06 06 06 06 04 07 04
0D70:06 07 03 06 06 06 06 06
0D78:05 06 06 02 05 05 02 06
0D80:06 06 06 06 05 06 06 06
0D88:06 06 06 06 06 06 00 00
0D90:00 00 00 00 00 00 80 80
0D98:80 80 80 80 80 80 00 00
0DA0:00 00 00 00 00 00 80 80
0DA8:80 80 80 80 80 80 00 00
0DB0:00 00 00 00 00 00 80 80
0DB8:80 80 80 80 80 80 00 00
0DC0:00 00 00 00 00 00 80 80
0DC8:80 80 80 80 80 80 28 28
0DD0:28 28 28 28 28 28 A8 A8
0DD8:A8 A8 A8 A8 A8 A8 28 28
0DE0:28 28 28 28 28 28 A8 A8
0DE8:A8 A8 A8 A8 A8 A8 28 28
0DF0:28 28 28 28 28 28 A8 A8
0DF8:A8 A8 A8 A8 A8 A8 28 28
0E00:28 28 28 28 28 28 A8 A8
0E08:A8 A8 A8 A8 A8 A8 50 50
0E10:50 50 50 50 50 50 D0 D0
0E18:D0 D0 D0 D0 D0 D0 50 50
0E20:50 50 50 50 50 50 D0 D0
0E28:D0 D0 D0 D0 D0 D0 50 50
0E30:50 50 50 50 50 50 D0 D0
0E38:D0 D0 D0 D0 D0 D0 50 50
0E40:50 50 50 50 50 50 D0 D0
0E48:D0 D0 D0 D0 D0 D0 00 04
0E50:08 0C 10 14 18 1C 00 04
0E58:08 0C 10 14 18 1C 01 05
0E60:09 0D 11 15 19 1D 01 05
0E68:09 0D 11 15 19 1D 02 06
0E70:0A 0E 12 16 1A 1E 02 06
0E78:0A 0E 12 16 1A 1E 03 07
0E80:0B 0F 13 17 1B 1F 03 07
0E88:0B 0F 13 17 1B 1F 00 04
0E90:08 0C 10 14 18 1C 00 04
0E98:08 0C 10 14 18 1C 01 05
0EA0:09 0D 11 15 19 1D 01 05
0EA8:09 0D 11 15 19 1D 02 06
0EB0:0A 0E 12 16 1A 1E 02 06
0EB8:0A 0E 12 16 1A 1E 03 07
0EC0:0B 0F 13 17 1B 1F 03 07
0EC8:0B 0F 13 17 1B 1F 00 04
0ED0:08 0C 10 14 18 1C 00 04
0ED8:08 0C 10 14 18 1C 01 05
0EE0:09 0D 11 15 19 1D 01 05
0EE8:09 0D 11 15 19 1D 02 06
0EF0:0A 0E 12 16 1A 1E 02 06
0EF8:0A 0E 12 16 1A 1E 03 07
0F00:0B 0F 13 17 1B 1F 03 07
0F08:0B 0F 13 17 1B 1F

And now for the moment of truth ...

900G

Ta-da!

We can bsave this binary as:

BSAVE DRAWSTRING,A$900,L$60E

If anyone has any questions, feel free to ask!

[anthon...@gmail.com]

On Sunday, June 18, 2017 at 5:18:20 PM UTC-4, Michael Pohoreski wrote:
> And now for the moment of truth ...
>
> 900G
>
> Ta-da!
>
> We can bsave this binary as:
>
> BSAVE DRAWSTRING,A$900,L$60E
>
> If anyone has any questions, feel free to ask!

Jesus xmas... so are you patching Carmen Sandiego? :D

[Michael Pohoreski]

I will sometime next week.

There are 2 patches we can do:

- patch the font data and fix the bad glyphs -- this is rather trivial and I will be doing this one. I'll provide a track/sector/offset style of byte patches.

- patch the code to use less memory, faster, etc. I need to inspect more of the code usage to see what and where to patch. Note that there is no real "need" to do this kind of surgery. That said we'll see since doing it for the challenge is rewarding -- I just have a ton of other projects I'm working on.

I.e.
I did this for Ultima 1 a few years back
https://groups.google.com/forum/m/#!topic/comp.sys.apple2/2NHj_6azS_g

[anthon...@gmail.com]

Here's an update from the maker of the Apple //c VGA Adapter :

=======================================================
AppleIIcVGA display video like as original output of the Apple II and not correct color fringing issue ( like as some software Apple II emulators ) , this i native output of the NTSC coding converted to VGA .

Also visual representation of the VGA output is vary between type of monitors , for example if you using old VGA CRT monitor you can see same as if you using Apple RGB monitor .

But due to LCD monitor not smooth the signal you see all dots and fringe colors .

New version on emulators emulate full signal and if you set the NTSC you can see same fringing colors like A2cVGA .


In this version i can not make correction and not able to make signal like software emulation .

In future i have plans to release new HDMI/DVI version and try to make more modes and correct color fringing .



Of course if you not satisfied of a2cvga you can return it and i can refund your money .
=======================================================

I hope it's possible to fix this in the future version!

Anthony

[Mark Lemmert]

HI Michael,

Was your screenshot request in reference to my post below about AppleWIN versions? Sorry for the late reply.

[Michael Pohoreski]

> Was your screenshot request in reference to my post below about AppleWIN versions? Sorry for the late reply.

Yes.

>I had been using AppleWIN 1.25.04 for a long time and recently started using AppleWIN 1.26.2.2. I
> noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that >is due to further NTSC adjustments?

I'll take a look at 1.25.0.4 and and 1.26.2.2 screenshots next week.

Was there a specific application / game you noticed these differences?

TIA.

[Mark Lemmert]

On Thursday, June 22, 2017 at 11:17:55 AM UTC-5, Michael Pohoreski wrote:
> >I had been using AppleWIN 1.25.04 for a long time and recently started using AppleWIN 1.26.2.2. I
> > noticed that 1.25.04 hi-res screens looks a lot "sharper" than 1.26.2.2 hi-res screens. Do you know if that >is due to further NTSC adjustments?
>
> I'll take a look at 1.25.0.4 and and 1.26.2.2 screenshots next week.

Thanks, I look forward to your thoughts after you have a chance to take a look.

> Was there a specific application / game you noticed these differences?
>
> TIA.

I originally noticed it during Nox Archaist development and I just tried Ultima 5 and see simular results.

Here are screen shots of both:

AppleWIN 1.25.04: Ultima 5
https://www.dropbox.com/s/ylu29orvezkgfef/U5.AppleWIN1.25.04.png?dl=0

AppleWIN 1.26.22: Ultima 5
https://www.dropbox.com/s/bmxqulk6x740pzr/U5.AppleWIN1.26.22.png?dl=0


AppleWIN 1.25.04: Nox Archaist
https://www.dropbox.com/s/6o4jn11nujkthsv/NA.AppleWIN1.25.04.png?dl=0

AppleWIN 1.26.22: Nox Archaist
https://www.dropbox.com/s/mc9vyf0vam39q3j/NA.AppleWIN1.26.22.png?dl=0


Using 1.26.22 the horizontal gaps between the pixels look larger to me than in 1.25.04.

In any event, I'm not complaining. AppleWIN is awesome. I'm just curious.


Thanks.

Mark

[James Davis]

Hi Mark,

Looking at your screen shots, I actually like the latter AppleWin ones better. The latter screen shots appear to have less color bleeding than the former ones.

James Davis

[Mark Lemmert]

Hi James,

Fair point. I was thinking the color bleed was a positive as it results in fairly solid horizontal color lines, but I agree in some circumstances it's not desirable. In particular with text characters where the space is tight.


Mark

[Michael Pohoreski]

> I originally noticed it during Nox Archaist development and I just tried Ultima 5 and see simular results.

> Do you know if that >is due to further NTSC adjustments?

At first I thought we changed the rendering mode in ver 1.24 -> ver 1.25 so when you mentioned 1.26 I thought there was a regression.

Thanks for the screenshots! OK, I can provide a definite answer. Yes, what you are seeing from ver 1.25 -> ver 1.26 is the new NTSC renderer.

* 1.25 while _artificially_ sharper had horrible color accuracy,
* 1.25 has 99% accurate NTSC emulation, albeit with a blurrier image.

On real hardware, the color composite screen really is that "blurry." If you put a composite monitor into monochrome mode you'll see we emulate 100% the dot placement -- the color "bleeds" over inbetween the pixels which is what is making the image blurry. There is a big long discussion about this in 254

https://github.com/AppleWin/AppleWin/issues/254


Some people have asked for the old color mode back, because as you mentioned, in certain circumstances -- like reading text on the graphics screen -- the old inaccurate display mode was far easier to read. We've only made some preliminary investigations so far but you can leave your voice here:

Can we have the option Color (TV Emulation) back?
https://github.com/AppleWin/AppleWin/issues/357

Hope this helps.

[Michael Pohoreski]

Thanks for the update Anthony!

Hopefully a new version is produced that has much better color accuracy.

[Mark Lemmert]

Michael,

Thanks for taking a look and for the GitHub link. I made a post to that thread.



Mark