exxos's Atari, Amiga & retro forum

Posted: **03 Jan 2020 19:47**

NVDI 2.51: http://www.atari-forum.com/viewtopic.php?t=23806

Posted: **03 Jan 2020 19:52**

pixelpusher wrote: 03 Jan 2020 19:45 Then you're probably not using a current MB : -) - for many years neither Intel nor AMD have floppy support on their MB anymore (and I haven found a floppy controller PCIe 1x-card via Google - only USB based solutions).

Mine was one of the last ones to have a floppy on it. https://www.asrock.com/mb/AMD/990FX%20E ... ifications

Posted: **04 Jan 2020 09:50**

exxos wrote: 03 Jan 2020 19:52
pixelpusher wrote: 03 Jan 2020 19:45 Then you're probably not using a current MB : -) - for many years neither Intel nor AMD have floppy support on their MB anymore (and I haven found a floppy controller PCIe 1x-card via Google - only USB based solutions).
Mine was one of the last ones to have a floppy on it. https://www.asrock.com/mb/AMD/990FX%20E ... ifications

Shortened output from Sysmon trace logs of GB6

Blitting only does VDI raster copy like this:

Code: Select all

$512E96 GB608B31 V_109  $51C5EA  vro_cpyfm       H 4 Mode 3 { E= S } MFDB 
                                                  $519558 { addr $000000 w 0 h 
                                                  0 ww 0 stand 0 nplanes 0 } 
                                                  MFDB $51957A 
                                                  { addr $000000 w 0 h 0 ww 0
                                                   stand 0 nplanes 0 } 
                                                  (10 ,38 ) (210,88 )  to 
                                                  (22 ,118) (222,206) ->

VDI scroll does a combination of VDI calls (text, raster, rectangle):

Code: Select all

$512E96 GB608B31 V_8    $51C552  v_gtext         H 4 (10 ,171) 
                                                  "VDI Scroll Text VDI Scroll Tex
t VDI Scroll Text VDI Scroll Text VDI 0" -> 
 $512E96 GB608B31 V_109  $51C5EA  vro_cpyfm       H 4 Mode 3 { E= S } MFDB 
                                                  $519558 { addr $000000 w 0 h 
                                                  0 ww 0 stand 0 nplanes 0 } 
                                                  MFDB $51957A 
                                                  { addr $000000 w 0 h 0 ww 0
                                                   stand 0 nplanes 0 } 
                                                  (1  ,38 ) (607,171)  to 
                                                  (1  ,30 ) (607,171) -> 
 $512E96 GB608B31 V_114  $51C5F8  vr_recfl        H 4 (9  ,163) (10 ,171) ->

VDI text does various VDI text output calls with occasional text color changes and VDI justified does the justified calls with occasional VDI rectangle calls.

As the rectangle calls aren't used in the justified text output (but in the normal text output - and both show the slow-down), we can rule out any influence of the rectangle code (and changing the text color too). So basically it boils down to "Text output" (ordinary as well as justified) is slower on your machine.

Other things to check that come to my mind:
- is this slowdown not present with blitter disabled (haven't looked into your original thread ...)? If it ain't then it would really point to the blitter being odd on the machine. Otherwise it still could be some cpu operations being slower (esp. justified output might use more Integer mul/div operations).
- does a stock 68k cpu running at 8 MHz show the same slow-down?
- same behaviour with NVDI?

Posted: **04 Jan 2020 10:01**

The image at the start of the thread is at 8mhz. NVDI 4 bombs as mentioned earlier so can't do tests with it. I could try TOS 104 to see if it matches benchmarks posted on the forum.

Posted: **04 Jan 2020 10:17**

exxos wrote: 04 Jan 2020 10:01 The image at the start of the thread is at 8mhz. NVDI 4 bombs as mentioned earlier so can't do tests with it. I could try TOS 104 to see if it matches benchmarks posted on the forum.

Are you starting from floppy or HD? ASSYGN.SYS file is adopted properly to the drive used (so that it can accesss the screen drivers)?

Posted: **04 Jan 2020 10:33**

pixelpusher wrote: 04 Jan 2020 10:17 Are you starting from floppy or HD? ASSYGN.SYS file is adopted properly to the drive used (so that it can accesss the screen drivers)?

Floppy.. Yeah I changed the sys file to A:\

I'm just trying TOS104...

Posted: **04 Jan 2020 10:48**

So short version, TOS104 benchmarks the same as the images on here exactly. Vs the STE, GEM window is a few % down as with the first test, but thats the difference between OS versions. So basically TOS104 works fine.

I don't see its a slow down with my TOS206 decoding, I don't delay anything.. and in terms of my booster running 50MHz, ROM access is a lot faster.. but the scores are still slower than a STE... and this machine just doesn't like TOS206 when other peoples machines do..

The only possible thing thing relating tos TOS206, is if I let the GLUE "see" the bus access or not.. So the glue seeing TOS206 access (well a bus cycle) means the GLUE may wait a bit before starting a blitter cycle... In the past I isolated /AS from GLUE to stop it seeing 104 and 206 address decoding, BUT, I found it was causing DMA issues, so now I always let GLUE see the access.

Either way, maybe someone in the UK can loan me a lightning ? So I can see if the same things happens with another TOS206 decoder.

Posted: **10 Dec 2022 21:08**

Sorry for being late. I just found this thread...

exxos wrote: 31 Dec 2019 16:39 We are in short, the blitter in a STFM is actually running slower than in a STE.

Yes, this is normal due to the weaker pull-ups on the DMA control signals. And this is why an H5, or any ST with stronger pull-ups for that matter, will not be slower.

Note that this affects only certain type of blits and only when Blitter is accessed from ROM (or fast RAM). So this doesn't affect demos that access Blitter directly.

Posted: **10 Dec 2022 22:03**

ijor wrote: 10 Dec 2022 21:08
exxos wrote: 31 Dec 2019 16:39 We are in short, the blitter in a STFM is actually running slower than in a STE.
Yes, this is normal due to the weaker pull-ups on the DMA control signals. And this is why an H5, or any ST with stronger pull-ups for that matter, will not be slower.

how to understand that? e.g. does it mean that in the STfm, every the BLiTTER pass will take additional bus cycle?

ijor wrote: 10 Dec 2022 21:08 Note that this affects only certain type of blits and only when Blitter is accessed from ROM (or fast RAM). So this doesn't affect demos that access Blitter directly.

good to know, thanks

Posted: **11 Dec 2022 13:03**

Cyprian wrote: 10 Dec 2022 22:03 how to understand that? e.g. does it mean that in the STfm, every the BLiTTER pass will take additional bus cycle?

I don't even remember starting this thread now. But I'd assume due to the slowdowns that a extra bus cycle could be a reason.

But not every ST. As stated here https://www.exxosforum.co.uk/forum/view ... =20#p31240 works good.

So likely down to tolerances on various aspects of chips / pull ups / PSU voltages. All the usual chaos.

The H4 / H5 should be a more stable platform. As it includes fixes for all the known issues at the time of its release.

exxos's Atari, Amiga & retro forum

Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness

Re: Slow STFM blitter oddness