Close

Apple II BMP Display Success!​

A project log for Keplermatik

Vintage U.S. and Soviet Hardware come together in a Mission Control-style console that actually tracks satellites.

sup4rl33thax0rsup4rl33thax0r 09/10/2018 at 06:401 Comment

So, an admission.  It’s been a bit since my last update.  Turns out that I don't work on this project full-time :)

Anyone that works on hobby projects knows that time is usually the constraining factor when it comes to getting stuff done.  Work, fixing things, cleaning the shop, and so on generally gets in the way of meaningful progress on SUPAR AWESOME PROJECTS.  That's a big part of why I gave myself a decade to get this project done.  Oh, I didn't mention that?  Yeah, this is a decade-long project.  I think I'm on track.

Believe it or not though, I have made some great progress since the previous update.  Among other things, I have the full Simplified Perturbations Models running on the INMOS transputer hardware.  Last we checked in, I had some stuff running including decoding the TLEs (Two Line Elements) but I had yet to show off actual orbital predictions.  But after some epic hacking sessions, that stuff is for real working.  I'm going to write those accomplishments up but for now what I want to talk about is this map stuff.  

Two posts ago, I detailed some plans to get a satellite map running on Apple II hardware.  The first part of this was succeeding in the display of DHGR (Double Hires GRaphics) bitmaps.  As in BMP, the stuff that you can output directly from a modern version of Adobe Photoshop here in Twenty Eighteen.  That would provide the background map atop which I could display the satellite position.  This was harder than I thought it'd be.

The first barrier to getting DHGR running on the Apple II was the lack of awesome documentation.  I mean, it was out there but for a guy like me used to including some standard libraries and pushing stuff to a display it wasn't exactly intuitive.  I will right now say that it took me a LOT of revisions to get it right.  I looked at a lot of on-screen garbage trying to puzzle out what was going on.

So close.  

So, if you'll excuse a little diversion I want to talk about Apple II graphics.

First, the fact that we can display a 560x192 monochrome bitmap on the Apple II is kind of amazing.

Woz, that is to say, Steve Wozniak, was a brilliant hardware designer.  He was working at Hewlett Packard when he started coming up with the schematics for what would become the Apple I, and he was all about efficiency in design.  Woz was absolutely great at making the very most of the fewest ICs possible.  It's fair to say that it would be hard to strip much out of the Apple II and get meaningful NTSC video out of a design.  The entire video system is based around the NTSC (and later, PAL) waveforms.  Woz basically looked at the required video signal and said, "How can I design a system with minimal cost and display meaningful graphics from a video buffer".  To be sure, his business partner Steve Jobs was probably totally on-board with this cost-optimization in the pursuit of producing an affordable computer with maximum sustainability for Apple.

That said, the side effect of reducing hardware complexity was to increase the software complexity.  There was no sprite hardware, and the video modes played epic tricks with the timing of the video signal to produce colors.  As a result of this spartan hardware design, the higher resolution video modes became fairly complex when it came to memory maps.  In modern frame buffers, there is a nice linear correspondence between the byte stored in memory and its position on the screen.  On the Apple II, one finds themself hopping all over the memory map to load an image that will be properly displayed on the screen.  Line 2 starts at a position farther than it should from Line 1, as does each subsequent line, except the screen hops back 1/3 of the way down (and 2/3 of the way down) to basically interlace these lines in memory.

Oh, and did I mention that alternate bytes are stored in different memory banks?

This makes constructing a DHGR frame buffer a bit of a challenge in 6502 assembly.

What kind of memory map is this?  Oh right, one that makes hardware simpler and cheaper.

On top of that, pixels are stored 7 bits at a time (the 8th bit serves as a funny delay bit in color mode, essentially ignored in mono DHGR graphics), while normal image files are stored 8 bits at a time.

This resulted in what I like to call "the pixel pokey" where I use the carry bit to bang bits back and forth between the BMP and graphics memory.

Fast forward a bit, and I have a for-real BMP loader running on the Apple II.  This is not the first.  Sometime after I started, someone beat me to it.  That person was Mario Patino, aka cybernesto.  You can see his VBMP code here.  Unfortunately, I didn't discover his code until after I had my code working, but I did benefit by looking at his sources.  My first functional code ran in about 4.5 seconds to display an image, while his ran in about 3 seconds.  Some of this is probably attributable to the efforts of Arnaud Cocquière, a demo coder whose work cybernesto expanded on.  Nevertheless after examining the code I found a couple optimizations and now mine runs just as fast, even though we do some things very differently.  As a side note, I was incredibly satisfied to see that a badass French demo coder was using the same "pixel pokey" strategy as I came up with on my very own, especially considering this was my first foray into a real 6502 assembly project.

Beautiful 560x192 monochrome DHGR.  TAY never looked so good.  That’s a 6502 assembly joke.  Nevermind.

At the end of the day, I can fill the screen with just about any 560x192 monochrome bitmap I want.  This is pretty cool.  Next up, I get to figure out how to show the satellite location with a sprite, and plot a curve showing the next orbit.  This will be pretty interesting, as it will require either double-buffering or some crazy caching of the background to make it work.

As a side note, I believe I have a pretty awesome dev environment for Apple II stuff.  I definitely owe thanks to John Newcombe who showed the way to using VSCode with Merlin32 and Gerard Putter's most excellent Virtual ][ emulator.  If you check the keplermatik-map GitHub, you will essentially have a skeleton project that allows you to build and run Apple II 6502 assembly with a simple "Command-B".  This is vastly faster than my previous method using Virtual ][ and AppleScript with native Merlin-8 for development and I get the bonus of a modern IDE with nice 6502 syntax highlighting courtesy of the BEEB VSC plugin.  

Discussions

Asad Raja wrote 05/13/2023 at 15:02 point

Wow wonderful work dear. I also find that one little difficult, but at the end I'm able to understand somehow. It is a suggestion for others to take some interest in such kind of projects, and try to understand by itself or take an admission in such an institute www.aiouedupak.com/ where they can able to learn such things.  

  Are you sure? yes | no