KarlosTKG now on GitHub

[Karlos]

Originally Posted by tomcat666

Yes, it is not perfect (yet) - this is one thing the developers will try to improve in the future for pistorm32. But 4.7Mb/s should give more than 31 fps (theoretically) when doing Long writes. The frame buffer for the reads is in the Fast mem though, right (thats the only thing that would make it half the speed really)?

Hmm. I'm not sure. That would be true if it was all on the same bus, but naïvely, I'd assume that the fast memory bandwidth locally on the RPi is so fast as to essentially not be a factor in the throughput here.

[tomcat666]

Originally Posted by Karlos

Hmm. I'm not sure. That would be true if it was all on the same bus, but naïvely, I'd assume that the fast memory bandwidth locally on the RPi is so fast as to essentially not be a factor in the throughput here.

Exactly, if all reads are done on fast memory it shouldnt really matter. No idea why it would be half the speed then

[Karlos]

Originally Posted by tomcat666

Exactly, if all reads are done on fast memory it shouldnt really matter. No idea why it would be half the speed then

This could be a vsync type issue. So far we use double buffering. If you just miss your slot you will have to wait to the next sync. If that's a consistent miss it normally halves your frame rate though. You are clearly seeing more than half.

Even 4.7Mb/s is more than enough for 50fps at the given resolution, including the additional overhead of audio output (8kHz, 3 channels, 1 channel reserved for the music module).

[Karlos]

Originally Posted by tomcat666

Exactly, if all reads are done on fast memory it shouldnt really matter. No idea why it would be half the speed then

For the avoidance of doubt, how were you capturing the video?

[tomcat666]

Originally Posted by Karlos

For the avoidance of doubt, how were you capturing the video?

A1200 RGB out -> RGB SCART to HDMI -> MS2130 HDMI to USB -> OBS Studio

https://www.aliexpress.com/item/1005...62b31802QupPo1

https://www.aliexpress.com/item/1005...62b31802QupPo1

[Karlos]

Originally Posted by tomcat666

A1200 RGB out -> RGB SCART to HDMI -> MS2130 HDMI to USB -> OBS Studio

https://www.aliexpress.com/item/1005...62b31802QupPo1

https://www.aliexpress.com/item/1005...62b31802QupPo1

So it's all capture of the output. I wondered for a moment if some internal screen recording was going on that might explain the reduction in performance. AFAIK, the 2/3 screen size only writes the small window and bottom border digits so if something was constantly reading the whole frame maybe it would've explained it

[Karlos]

Originally Posted by tomcat666

Exactly, if all reads are done on fast memory it shouldnt really matter. No idea why it would be half the speed then

There must be some existing tools that can benchmark long fast to chip copy times to rule this out. If not, and you are able, a simple C program that allocates a block of chip ram and then just times how long it takes to copy from an equal sized block of fast ram might shed some light.

[abu_the_monkey]

I am still fuzzy from an operation earlier but this thread has some infos for bus/ram copy speeds with various cards (some show chip) using bustest, would this tool be what you are looking for?

https://eab.abime.net/showthread.php?t=109013

from the bustest readme:-

The 68040 and 68060 usually uses a _copyback_ cache. This means,
that _writing_ causes the cache to _read_ the data first (and
later _write_ it) thus halving write performance when writing
large blocks.

Small blocks like local variables usually fit into the cache and
are just read once which is the reason for the good performance
of the copyback cache. But.. block writes are the worst case. The
68040 has a special MOVE16 instruction to circumvent that problem,
but it is not used in the AmigaOS (nor in this test program).

The 68040 and 68060 have rather large caches and especially the
68060 uses an effective pseudo-random cache replacement strategy
which bias results if the tested memory area isn't much larger
than the cache. This is the reason why previous versions of bustest
yielded too high transfer rates for cached memory. The 16k area
still generated more than 50% cache hits in case of the 68060.

[Karlos]

I don't think copyback is used for chip ram destination because it's normally marked as non cacheable.

[grond]

The writes happen to chipmem which isn't cached anyway, hence, the copyback cache can't be a factor there. The c2p most probably reads the screenbuffer to convert in a linear fashion which usually is okay because the data caches read entire cache lines (16 bytes aligned to 16-byte-boundaries like what MOVE16 would move) anyway.

Perhaps even with the superfast processor there still is some time consumed for rendering the screens which results in less than 100% chipmem bandwidth usaeg? Perhaps the JIT-buffer is too small for the amount of code that gets executed between two frames?

[tomcat666]

Originally Posted by Karlos

There must be some existing tools that can benchmark long fast to chip copy times to rule this out. If not, and you are able, a simple C program that allocates a block of chip ram and then just times how long it takes to copy from an equal sized block of fast ram might shed some light.

Results of the SysSpeed test program: last 5 are what you need.. fast2chip

The "You" is the pistorm32lite with rPi4, "Emu68" is the ordinary pistorm with rPi3A+

[Karlos]

Originally Posted by tomcat666

Results of the SysSpeed test program: last 5 are what you need.. fast2chip

The "You" is the pistorm32lite with rPi4, "Emu68" is the ordinary pistorm with rPi3A+

You will note Fast2ChipLX is basically the same result as WriteChipX, which is what we expected assuming that the local fast memory lives up to its name. The entire bottleneck here is chip write.

The figures you get make me wonder if the destination bitplanes are somehow misaligned in memory, so that every long write is going out as a pair of 16 bit writes over the bus.

[abu_the_monkey]

I know I have been in hospital today and feel fuzzy from the anaesthetic and pain meds, but, where are the results?

[tomcat666]

Originally Posted by abu_the_monkey

I know I have been in hospital today and feel fuzzy from the anaesthetic and pain meds, but, where are the results?

What do you mean? Here is the pic with the results:

[abu_the_monkey]

My bad, had to restart my pc it was not displaying the images in posts for some reason.

[Karlos]

Originally Posted by abu_the_monkey

I know I have been in hospital today and feel fuzzy from the anaesthetic and pain meds, but, where are the results?

But that's enough about you, how are your patients?

[abu_the_monkey]

I think as fast as the pistorm32lite is, its very similar to what ZyBeR had with Amiberry on Rpi, its just on the limit of being capable of running it full screen full detail but just not quite there (yet).

[Karlos]

Originally Posted by abu_the_monkey

I think as fast as the pistorm32lite is, its very similar to what ZyBeR had with Amiberry on Rpi, its just on the limit of being capable of running it full screen full detail but just not quite there (yet).

Yeah, but I'm sure it's a chip write / bus problem here.

[Karlos]

While these results may improve as the product matures, to me it really underscores the need for an RTG version. I have plenty of experience with RTG from C but haven't really gone at it from the assembly language side. That said, I'm somewhat of the opinion that maybe it's time to start adding C modules to the code anyway. As long as it's just for resource management and bitmap locking I can't see it hurting performance.

[grond]

It's not very difficult to use RTG from assembly code. Basically there is some special setup code (like opening CyberGraphX or P96, possibly depending on some user-defined ToolType or startup argument) and later on some code for screen update that may depend on a variable you set at the beginning and indicates whether you need c2p or not.

There should be lots of code examples around. Unfortunately I never wrote working code myself as I never had an RTG system back in the day. I believe I have some code somewhere that checked for a preferred c2p method set by a ToolType and optionally used WritePixelsArray() if the ToolType was set accordingly. But when I tested it on somebody's 060/Cybervision system back in the 90s (only chance I got to test it), it didn't work. I didn't know back then that it wasn't enough to use OS functions but that one had to open one of the RTG libraries and use some stuff from them.