65C02 Simulator on a bare metal Raspberry PI

[okwatts]

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

[Sheep64]

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.

[8BIT]

Sheep64 wrote:

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

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

Quote:

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

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

Quote:

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.

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

[8BIT]

okwatts wrote:

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

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

[cjs]

8BIT wrote:

In core 2, I have a 320x200 display set up with 63 colors ( 2 bits for each Red, Green, & Blue). I have it set up as 4 addresses in the simulator IO space
$8040 = pixel color - 0x00RRGGBB
$8041 = Y coordinate 0 - 199, above that and the pixel will not get plotted
$8042 = X coordinate low byte
$8043 = X coordinate high byte 0-319, above that and the pixel will not get plotted

A write to $8044 will tell core2 to plot the point.

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.

[8BIT]

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

[cjs]

8BIT wrote:

I'd have to check to see if the plot engine could keep up, or if you might miss a point.

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.