Heya,
I have been playing for a while with 6502 assembly and namely on Apple ][. Presently I got curious about how vertical position would be calculated in hires. Yes, some uses tables and got one of my own for both hires and text/lores. However hires table is created in basic, and I am more curious about calculating it without using table. Namely calculating with assembly and that horrible 8 bit register. Google didn't give out pure math (read none at all).
Unless somewhere in memory is table used by basic's hires graphics function, in which case that table will be handy. Didn't find anything resembling such table however, but would be memory saver if such thing exist.
If you are curious what I am doing right now, it is actually trying put up two functions. Hires versions of hlin and vlin. Byte accurate versions, not pixel. I am working with something? Well, won't give out details until all required snippets are gathered... nope...
You might want to look at the GBASCALC routine in the Monitor ROM ($F847).
Actually are you sure that one is right address, coz all results seem be pointing to text memory address. Plus only PLOT seem be calling it, not HPLOT. Kinda useless, as basic already has VLINE and HLINE for LORES, but I am working with HIRES and looking to create similar call functions with assembly. HPLOT is both far too slow and don't need pixel accurate function. Just byte accuracy for right results...
As I recall, you could transpose a few bits in the Y coordinate, mulitply by 40, and then you should have it.Except that I think there might be some skip bytes at the end of every so many lines, which complicates things. Can anyone shed some light on this?
Back in 1989-90 I was experimenting with the 160x192x16 mode provided by the A2E AppleColor RGB card (not standard DHR). I didn't know where the ROM calc routines for HIRES lived back then and I wrote some assembly to compute a screen memory value from an X,Y coordinate pair. For the Y values, it's still 0-191, so the algorithm doesn't change. There are (of course) lots of intersting patterns in the memory layout of Hires... Here's the basic gist of how I did it (which probably isn't the *best* way, mathwise, but it worked):
The low byte of the destination screen memory address starts as $00.
First, take the Y coord and divide it by 8. This gives a value of 0-23. If that value is odd, add $80 to the low byte of the destination screen memory address.
If Y/8 is >7, add another $28 to the low byte of the destination address.
If Y/8 is >15, add another $28 to the low byte of the destination address.
The high byte of the destination address starts as $20.
Take Y/8 Modulo 8 (0-7). Divide by two (0-3). Add this to the high byte of the dest address.
Take Y Modulo 8. (0-7). Multiply by 4. Add this to the high byte of the destination address.
You now have the memory address for the start of the row.
The picture of the hi-res memory layout at https://www.xtof.info/hires-graphics-apple-ii.html (which I believe was similar to what was shown in one of the books that came with the RGB card) helps visualize what's going on with the math.
I can provide my source code if you wish, but working through it to reverse engineer the algorithm I see that there are several things that could be improved that I did the hard way (I was 13/14 years old at the time!)... and to be quite honest, a table-based lookup is going to be much, much faster and simpler than trying to do all the math.
REM HOW TO CALCULATE THE HIRES ADDRESSREM GIVEN THE COORDINATE OF A PIXELhttps://mmphosis.netlify.app/hires/