30 January 2023, 13:27 | #181 | |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
Quote:
|
|
30 January 2023, 13:28 | #182 |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,665
|
Exactly, if all reads are done on fast memory it shouldnt really matter. No idea why it would be half the speed then
|
30 January 2023, 13:32 | #183 | |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
Quote:
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). |
|
30 January 2023, 13:33 | #184 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
|
30 January 2023, 13:54 | #185 |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,665
|
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 |
30 January 2023, 15:23 | #186 | |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
Quote:
|
|
30 January 2023, 15:51 | #187 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
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.
|
30 January 2023, 16:57 | #188 |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,023
|
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. Last edited by abu_the_monkey; 30 January 2023 at 17:36. |
30 January 2023, 17:50 | #189 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
I don't think copyback is used for chip ram destination because it's normally marked as non cacheable.
|
30 January 2023, 17:54 | #190 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,926
|
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? |
30 January 2023, 20:06 | #191 | |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,665
|
Quote:
The "You" is the pistorm32lite with rPi4, "Emu68" is the ordinary pistorm with rPi3A+ Last edited by tomcat666; 30 January 2023 at 20:28. |
|
30 January 2023, 20:51 | #192 | |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
Quote:
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. |
|
30 January 2023, 21:09 | #193 |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,023
|
I know I have been in hospital today and feel fuzzy from the anaesthetic and pain meds, but, where are the results?
Last edited by abu_the_monkey; 30 January 2023 at 21:17. |
30 January 2023, 21:35 | #194 |
Retro Freak
Join Date: Nov 2001
Location: Slovenia
Age: 51
Posts: 1,665
|
|
30 January 2023, 22:09 | #195 |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,023
|
My bad, had to restart my pc it was not displaying the images in posts for some reason.
|
30 January 2023, 22:57 | #196 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
|
30 January 2023, 23:50 | #197 |
Registered User
Join Date: Oct 2020
Location: Bicester
Posts: 2,023
|
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).
|
31 January 2023, 00:27 | #198 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
Yeah, but I'm sure it's a chip write / bus problem here.
|
31 January 2023, 15:59 | #199 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,483
|
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.
|
31 January 2023, 16:34 | #200 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,926
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
JOTD sources on github | jotd | project.WHDLoad | 30 | 17 December 2022 12:25 |
A600 github 4m mem | sasquatchuk | Hardware mods | 0 | 18 June 2022 20:46 |
My old Amiga games available on GitHub | palaste | Coders. General | 14 | 22 June 2020 02:41 |
KTRL CD32 on GitHub | MickGyver | News | 1 | 04 December 2018 19:56 |
How about a GitHub for startup-sequences? | wXR | Amiga scene | 9 | 16 February 2013 12:38 |
|
|