Hi Daryl
Glad to see work progressing, looking forward to further updates especially for PI 3 as I have a few of them (not all in use).
Larry

Firstly, I quite like the allocation of seperate cores to multi-media. This provides the most immediate performance boost.

Secondly, I am curious to know how much of this work can be deployed on MCL65+.

Thirdly, I strongly recommend augmenting the six bit RRGGBB palette with two least significant intensity bits shared across all channels. (See 16*16 Pixel Tile Video Display And Video Codec for subjective test results across four 8 bit palettes.) At the very least, common intensity bits provide 16 shades of gray rather than four.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Yes it does, and with 4 cores, there's room for more.


I am not familiar with the Teensy4.1 and do not use Arduino, so I cannot really answer this.


This could be done, but I found the 64 color choices seemed ample. I will try some experiments with this suggestion when I get time.

Thanks for your input!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I have the Pi3 SD versions loaded on my website. Feel free to give them a try and let me know if you have any problems. The "manual" says Pi2 but its the same for either version.

https://sbc.rictor.org/pisim.html

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I like that interface.

Just one comment: you might be able to get a fair efficiency boost, especially for doing things like clearing the screen, by changing it so that a write to $8042, the X coordinate low byte, triggers a plot. Then a lot of the plotting time for some common operations would simply be incrementing and writing the X co-ordinate.

_________________
Curt J. Sampson - github.com/0cjs

I'd have to check to see if the plot engine could keep up, or if you might miss a point. I have a poll for engine ready status to prevent missing plots. Unfortunately, I dont have spare time to test right now. I'll keep this on my to-do list.

Thanks for the suggestion!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Yeah, that occured to me, but I couldn't think of a good solution for it so I thought that maybe ignoring the problem would work. :-)

Perhaps generate wait states on write when not ready? Though that of course just slows the CPU.

MSX machines have this issue with their VDPs (TMS9118 and friends). There might be something in all the work that's been done on that that could help, but it probably is a bit of a rabbit hole.

_________________
Curt J. Sampson - github.com/0cjs