When your only registers are a 8 bits X, Y, and A, the hires screen memory was practically encrypted!
It felt so fucking amazing to finally have a computer with a normal 1 pixel : 1 byte memory mapped display.
But before that, I played around with the Sun CG1 graphics board (on a Sun 2: I mmap'ed /dev/cgone0, but maybe it was actually a cgtwo card, not sure), which was kinda but not really memory mapped.
It had 8 bit color mapped pixels, and it had an implicit read position and write position, such that you could address a row and column of pixels at a time, one pair for reading and one for writing ("rop mode memory").
When you accessed a column of the row block of memory, that set which column you could address in the other column block of memory. When you accessed a row of the the column block of memory, that set which row you could address in the other row block of memory!
As it turned out, that just happened to be useful for drawing lines and filling trapazons and performing raster operations, but it made random access quite inefficient, and was a huge pain in the ass for anything else.
(Although nowhere near as painful as Apple ][ graphics, but a lot more expensive!)
I think the early X10 and X11 servers actually supported it (SunView [SunTools at the time] certainly did), but it was really really slow.
I learned later than John Gilmore had written weird union structs the .h file to describe the memory mapped registers, when he was at Sun in its early days:
Here's some Forth and 68K code I wrote to play around with that card (notice how register offsets gr_x_select / gr_y_select, 68k code xsel / ysel, and Forth words lineaddr / coladdr work together -- yes Forth can mmap device registers, and that is RPN 68k assembly code, with opcodes at the end of the line!):
It felt so fucking amazing to finally have a computer with a normal 1 pixel : 1 byte memory mapped display.
But before that, I played around with the Sun CG1 graphics board (on a Sun 2: I mmap'ed /dev/cgone0, but maybe it was actually a cgtwo card, not sure), which was kinda but not really memory mapped.
http://www.sunhelp.org/faq/FrameBufferHistory.html
It had 8 bit color mapped pixels, and it had an implicit read position and write position, such that you could address a row and column of pixels at a time, one pair for reading and one for writing ("rop mode memory").
When you accessed a column of the row block of memory, that set which column you could address in the other column block of memory. When you accessed a row of the the column block of memory, that set which row you could address in the other row block of memory!
As it turned out, that just happened to be useful for drawing lines and filling trapazons and performing raster operations, but it made random access quite inefficient, and was a huge pain in the ass for anything else.
(Although nowhere near as painful as Apple ][ graphics, but a lot more expensive!)
I think the early X10 and X11 servers actually supported it (SunView [SunTools at the time] certainly did), but it was really really slow.
I learned later than John Gilmore had written weird union structs the .h file to describe the memory mapped registers, when he was at Sun in its early days:
https://donhopkins.com/home/archive/forth/cg/cg2reg.h
Here's some Forth and 68K code I wrote to play around with that card (notice how register offsets gr_x_select / gr_y_select, 68k code xsel / ysel, and Forth words lineaddr / coladdr work together -- yes Forth can mmap device registers, and that is RPN 68k assembly code, with opcodes at the end of the line!):
https://donhopkins.com/home/archive/forth/cg/cgone.f
https://donhopkins.com/home/archive/forth/cg/cg.f https://donhopkins.com/home/archive/forth/cg/fline.fhttps://donhopkins.com/home/archive/forth/cg/iline.f