Hacker News new | past | comments | ask | show | jobs | submit login
Apple II Double High Resolution Graphics (2017) (lukazi.blogspot.com)
73 points by todsacerdoti on Sept 11, 2021 | hide | past | favorite | 12 comments



What makes this feat possible is that each block's pixel colours are affected by its neighbouring block (on both sides of the block).

That's known as https://en.wikipedia.org/wiki/Composite_artifact_colors and there's some deep explanations here:

https://retrocomputing.stackexchange.com/questions/2595/does...

...and a related article on doing the same (and much more!) on a PC CGA: https://int10h.org/blog/2015/04/cga-in-1024-colors-new-mode-...


Also why a lot of console games (especially Sega Genesis/Mega Drive) look weird on an emulator with perfect rendering

https://forums.libretro.com/t/mdapt-gdapt-dithering-treatmen...


One very interesting trick when using composite artifacts is that the “color” pixels don’t need to line up - any group of pixels will produce different colors in any of the 560 horizontal positions. The more contiguous pixels you light up, the closer to white you get.



I love this is on blogger.com/blogspot.com. I logged in and found a blog I made back in 2009 on personal finance. Brings back memories.


I truly, truly hated hi res graphics on the Apple- well, specifically, trying to do high speed graphics in assembly.


I remember as a kid being baffled by the weird memory layout for the Apple II's high-res graphics mode. Each contiguous row in memory corresponded to non-contiguous rows on the screen, probably to reduce top-to-bottom flickering on an NTSC display. The choice seemed to be between using BASIC, which abstracted away the layout but was extremely slow, or using 6502 assembly, which was fast but required my 11-year-old brain to invent an impossibly complicated algorithm for manipulating the memory.

Then one day I was disassembling the bootloader for a game disk. I think it was Borg; it showed a little dragon creature in the center of the screen that jumped each time the disk controller needed to move to a new track on the diskette. In 256 bytes, this code generated a look-up table for each screen row's starting location in memory, used it to blit incredibly fast, and loaded the game. And of course it left enough room for the dragon image itself. That snippet of code taught me at least a semester's worth of simple CS concepts.

As an aside to an aside, many cracked versions of Apple II games omit the loading screens, whose code was often enmeshed with the copy-protection code that needed to be neutralized. While many crackers replaced them with their own comparably creative loaders, I suspect many of the original elegant and cute screens are lost to history.


yeah, more or less the same experience (except I never got to the point of disassembling bootloaders).

What I do remember is the cracked version of Ultima IV, you could hit Control-C while booting and there was, just laying around, a file that played polyphonic music on the Apple (also a cool assembly trick). And All those BBSes... lost in time.

It's funny you mention the lookup table. If I had just known how to do that, I could have done row addressing. The problem I had was that the width (in pixels) of the screen was larger than the Apple's 8-bit operands, and I got stuck on thinking I needed to do multiple-byte additions (with carries) manually.


Exactly. As they say, all optimization is caching. Seeing the hard part of the formula front-loaded into the LUT generation hammered that lesson home for me.


I feel like I remember something called “Super High Res” graphics back in my Apple 2 days. Is this the same thing as what’s called Double High Res here?


I think SHR was a IIgs thing?


Yes it was: https://en.wikipedia.org/wiki/Apple_IIGS#Graphics

And TIL that Wikipedia has an entire page dedicated to graphics for the pre-GS Apple II's! https://en.wikipedia.org/wiki/Apple_II_graphics




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: