x16-docs

> Also, to be slightly pedantic, the X-16 doesn't have IO ports. It's using a 65C02 processor, where all I/O is memory mapped. The video ram is not on the 65C02's bus apparently and is accessed through a set of registers which must slow down things quite a bit, you get plenty of video memory this way though I guess. Must be what they mean by "IO Ports" https://github.com/commanderx16/x16-docs/blob/master/VERA%20...

Last night a new version of the vera documentation was uploaded (https://github.com/commanderx16/x16-docs/blob/master/vera-mo...). It looks like the changes will allow for more memory, up to 1mb. Of which the last 64kb seem to be reserved for the registers, so max 960kb. Constantly copying data to the VERA (chasing the beam/screen), seems unpractical. The 6502@8MHz can never move that much data.

> It has a tile mode. That's going to be how larger images are handled. Perhaps. But in the video, he said mode 7, and the VERA module documentation https://github.com/commanderx16/x16-docs/raw/master/vera-mod... lists that as a bitmapped mode, 8 bits per pixel. However, I do have some experience creating complex images on an 8-bit machine using tile mode (using interrupts to progressively load new character sets while the image is being rendered by the video chip). There is a place for each. (I believe it might have been used in Super Mario type image they demonstrated?) > Now, as to why it's done the way it's done? Simplicity. Yup. Hopefully I've made that design decision clear for those who might have missed it, and I'd certainly like to encourage them to see if they can improve upon this one particular architectural decision.