AtariZoll wrote:So, you expect that blitter chip can work stable at 16 MHz ? I guess that some may, like it is case with FDC (WD1772) chip, but likely most will be not able.In case of 16 MHz mod, blitter works faster from simple reason: there is less time for wait that CPU finishes his "turn" So, blitter can work 67% time instead 50%. In HOG mode there would be no speed boost.

actually, I think that assumption isn't correct. In nonHog mode the blitter doesn't counts its internal cycles before it does next blitting pass, but it counts the memory bus accesses used by the CPU. The blitter takes control over the bus when the CPU do 64th memory bus access.Therefore, whether blitter works on 16MHz or 8MHz it needs to wait 256 cycles (8Mhz CPU ) because of 64 * 4 cycles ST RAM access.

AtariZoll wrote:So, you expect that blitter chip can work stable at 16 MHz ? I guess that some may, like it is case with FDC (WD1772) chip, but likely most will be not able.In case of 16 MHz mod, blitter works faster from simple reason: there is less time for wait that CPU finishes his "turn" So, blitter can work 67% time instead 50%. In HOG mode there would be no speed boost.

actually, I think that assumption isn't correct. In nonHog mode the blitter doesn't counts its internal cycles before it does next blitting pass, but it counts the memory bus accesses used by the CPU. The blitter takes control over the bus when the CPU do 64th memory bus access.Therefore, whether blitter works on 16MHz or 8MHz it needs to wait 256 cycles (8Mhz CPU ) because of 64 * 4 cycles ST RAM access.

I have found we need to add more code to the GALs to allow blitter operation. The problem being the blitter has access to the CPU and TOS which may or may not be running at 16mhz. Then the blitter has access to RAM which needs 8mhz. Problem being there is a mash up of speeds which need sorting out.

This shouldn't be to hard since all we need to do is make sure the CPU is running at 8mhz when the blitter has control of the bus. While that probably doesn't make sense, the CPU clock is linked to the blitter clock, while that may not make sense either, the blitter cannot run on 8mhz because the CPU and TOS run at 16mhz, so its a mismatch in speeds which ever way you look at it.

Once we get the CPU and blitter operating at 8mhz, We will program in that the blitter can run at 16mhz when talking to the CPU or TOS only. If the blitter requests control of the bus, then we will have to assume its talking to RAM and switch it to 8mhz.

It might be easier to run separate clocks for the blitter and CPU, but unfortunately we do not have any more free pins on the frequency control GAL. In anycase, the blitter can talk to the CPU and TOS at higher speeds. Though I don't know if the blitter does anything like shifting data around its internal registers ? As when the blitter hasn't got control of the bus, it could be clocked at 16mhz or 8mhz. Of course there is no point clocking it at 16mhz if its not actually doing anything internally...

CPU&blitter at 16MHZ looks like a great improvement. It is a pity the ST Ram bottleneck. Why did they solved this on the Mega STe? adding the cache?

And would it be necessary a specific test program to see it it is reliable and stable? or are those expected 16MHZ operations few and it won't get hot/freezed in any case?

I think speed boost was the cache on the mega, i never had one of those machines anyway..

16mhz uses 16mhz CPU and 16mhz capable TOS so nothing is overclocked there. Blitter will be, but i doubt it will be running 16mhz constantly, so while it may get a little warmer, it shouldn't be a problem.

Like the WD1772, OK totally different chip, but that overclocked to 16mhz. Though I found a lot of upgrades ran it at 16mhz as the basic frequency, so it was running 16mhz when no floppy access. So it just got hot doing nothing. My kit only ran 16mhz when HD floppy was accessed, so everyone variation of 1772 would work at 16mhz, but the "norm" is you need a 02-02 or AJAX , but its not true. Of course blitter needs to be tested at high speeds for reliability, if it does not work, we will leave it at stock speed. Or offer 2 variations of GAL code for people to try faster blitter..

AtariZoll wrote:So, you expect that blitter chip can work stable at 16 MHz ? I guess that some may, like it is case with FDC (WD1772) chip, but likely most will be not able.In case of 16 MHz mod, blitter works faster from simple reason: there is less time for wait that CPU finishes his "turn" So, blitter can work 67% time instead 50%. In HOG mode there would be no speed boost.

actually, I think that assumption isn't correct. In nonHog mode the blitter doesn't counts its internal cycles before it does next blitting pass, but it counts the memory bus accesses used by the CPU. The blitter takes control over the bus when the CPU do 64th memory bus access.Therefore, whether blitter works on 16MHz or 8MHz it needs to wait 256 cycles (8Mhz CPU ) because of 64 * 4 cycles ST RAM access.

I was talking about case when CPU is clocked to 16 MHz. As may see from "there is less time for wait that CPU finishes his "turn" " .

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

exxos wrote:I think speed boost was the cache on the mega, i never had one of those machines anyway..16mhz uses 16mhz CPU and 16mhz capable TOS so nothing is overclocked there. Blitter will be, but i doubt it will be running 16mhz constantly, so while it may get a little warmer, it shouldn't be a problem. ...

16 KB cache is pretty much for Atari ST SW, so may give pretty big speed up. But not when huge RAM areas need to move, because RAM access time is still same as by 8 MHz ST(E) . It is well visible in scroll tests, when is faster only some 12%.

Actually, all TOS versions can work on faster clock. TOS 2.06 is not designed specially for 16 MHz. It just works fine at. But same is with TOS 1.04, etc.TOS 2.06 has support for 68010 CPU, Fast RAM, IDE hard disks. + Desktop is much improved.

Considering blitter at 16 MHz: I would not expect some bigger speed-up from simple reason: it must go back to 8 MHz when accessing RAM. And because way how it works - almost all time accessing RAM, and % of internal cycles is very low, speed up will be very small.Example: IDE hard disk access with blitter is faster some 15-20% than via CPU. With CPU we have: move.l (a0),(a1)+ - where 4 T goes for opcode fetch, then 4+4+4+4 for read, write . So, 1/5 of time is wasted on opcode fetch.By blitter all cycles do RAM access, so will transfer 4 bytes in 16 cycles instead 20 . 16 MHz blitter may be faster with Fast RAM, but that seems not much useful, as it can not hold screen.

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll wrote:So, you expect that blitter chip can work stable at 16 MHz ? I guess that some may, like it is case with FDC (WD1772) chip, but likely most will be not able.In case of 16 MHz mod, blitter works faster from simple reason: there is less time for wait that CPU finishes his "turn" So, blitter can work 67% time instead 50%. In HOG mode there would be no speed boost.

actually, I think that assumption isn't correct. In nonHog mode the blitter doesn't counts its internal cycles before it does next blitting pass, but it counts the memory bus accesses used by the CPU. The blitter takes control over the bus when the CPU do 64th memory bus access.Therefore, whether blitter works on 16MHz or 8MHz it needs to wait 256 cycles (8Mhz CPU ) because of 64 * 4 cycles ST RAM access.

I was talking about case when CPU is clocked to 16 MHz. As may see from "there is less time for wait that CPU finishes his "turn" " .

The mistake is believing that the blitter always gets 50% of the time in shared mode. The 50% figure is an upper bound only reached when the processor is touching main memory every 500 ns.*

Of course a faster processor running out of standard memory is more likely to trigger a restart of the blitter while cache and non-mmu controlled memory will tend to idle the blitter for longer periods of time.

*Excepting the case where the CPU is made to manually restart the blitter, of course.

Last edited by mc6809e on Wed Nov 12, 2014 10:30 pm, edited 1 time in total.

AtariZoll wrote:Considering blitter at 16 MHz: I would not expect some bigger speed-up from simple reason: it must go back to 8 MHz when accessing RAM. And because way how it works - almost all time accessing RAM, and % of internal cycles is very low, speed up will be very small.Example: IDE hard disk access with blitter is faster some 15-20% than via CPU. With CPU we have: move.l (a0),(a1)+ - where 4 T goes for opcode fetch, then 4+4+4+4 for read, write . So, 1/5 of time is wasted on opcode fetch.By blitter all cycles do RAM access, so will transfer 4 bytes in 16 cycles instead 20 . 16 MHz blitter may be faster with Fast RAM, but that seems not much useful, as it can not hold screen.

I am still working on the blitter, but I found it needs its own clock, so I am talking to rodolphe about adding another GAL to control blitter clock. Problem is, when blitter have control of the bus, the CPU is going to 8mhz with the blitter, so the CPU is getting slowed down when it should be running at 16mhz. At current tests, machine actually run slower with blitter enabled, because it is slowing CPU. But blitter does show 1% speed gain so it is doing something good, this is nothing really, but results are tainted by CPU running slower.

The current results are this, but the blitter does seem capable of 16mhz operation. of course it has to slow to 8mhz for RAM access, but so does CPU. We may get 10% speed boost on blitter when work is completed..

ffdbegce.jpg

You do not have the required permissions to view the files attached to this post.

? Tried but it still seems corrupted, especially the interrupt services are getting out of sync very often. ! Please note that in BLiT mode, the BLiTTER will always arbitrate for the bus after 64 cycles of idle time, no matter what the CPU is doing. It will interfere with the interrupt service routines. If the timing of the interrupt service routines is critical, the BLiTTER should only be used with great care and in HOG mode where appropriate.

In that point Paradox are wrong. If I remember correctly in STE split isn't 64/64 CPU bus cycles but 65/64 and 66/64 in case of MSTE and actually depends on CPU bus usage. I'll later provide test case.

I did some more testing with the blitter. It seems when running at 8mhz, it actually runs faster overall by about 4% or so, as opposed to 16mhz.

Below are the results.

bltres.jpg

Blitter is allowed to run 16mhz only during TOS access, and when blitter does not have control of the bus. This way if blitter does internal operations, it is allowed to run at 16mhz.

When blitter otherwise has control of the bus, IE acess to RAM, it runs at 8mhz. Overall the results do not make sense. You would expect as blitter has some speed injection to run at 16mhz, that it would run faster. but it does not.

You do not have the required permissions to view the files attached to this post.

exxos wrote:Blitter is allowed to run 16mhz only during TOS access, and when blitter does not have control of the bus. This way if blitter does internal operations, it is allowed to run at 16mhz.

Maybe the problem is that internal operations are occurring between two standard 68K bus cycles, so while the internal operation itself takes half the time, the blitter still has to wait for the next available bus cycle to continue which nullifies the speedup.

exxos wrote:I did some more testing with the blitter. It seems when running at 8mhz, it actually runs faster overall by about 4% or so, as opposed to 16mhz.

Below are the results.Blitter is allowed to run 16mhz only during TOS access, and when blitter does not have control of the bus. This way if blitter does internal operations, it is allowed to run at 16mhz.

When blitter otherwise has control of the bus, IE acess to RAM, it runs at 8mhz. Overall the results do not make sense. You would expect as blitter has some speed injection to run at 16mhz, that it would run faster. but it does not.

On a MSTE, Blitter speeds up a little the machin in 16MHZ over 8MHZ as you can see on my earlier post (no cache activated...with cache the results are little strange because blitter seems to slow down the machine).

The results are confusing overall really. As Gembench has the option to compare a machine with and without blitter. Thing is, when running the blitter, and ticking the blitter box, it takes away the blitter speeds gains, so the results which are left, should be the CPU & TOS running at 16mhz. But the results are around 50% less than I would have expected them to be.

For example, GEM Dialog Box: 151%, is without blitter. But with the blitter ON, and ticking the blitter box, the result is 135%. This does not make any sense to me. If the blitter gave 80% speed boost, then ticking the box will take away that 80% and you should be left with a stock machine again, but then the CPU and TOS boost should bring it back up to 151% again I can only think that the blitter while speeds up graphics, its taking away about 25% speed away from the cpu. While the CPU is normally accessing the bus, the blitter has taken over. So you loose the CPU speed gains in favour for blitter stuff.

I did fix the 4% loss problem just also It seems the CPU is still doing stuff like accessing TOS, while the blitter has control of the bus. This is pretty cool actually. I let the CPU access TOS at 16mhz while blitter has control of bus, and the 4% loss vanished. But overall, no speed gain for blitter at 16mhz

Left is the results with the blitter ON, and right is without the blitter. Only a few % drop in speed now, so things are pretty close. I dare say that is probably normal as the blitter will steal some bus time.. but I am still checking...So the total speed boost for the STFM with blitter is......

blitnew.jpg

You do not have the required permissions to view the files attached to this post.

exxos wrote:I did some more testing with the blitter. It seems when running at 8mhz, it actually runs faster overall by about 4% or so, as opposed to 16mhz.

Below are the results.Blitter is allowed to run 16mhz only during TOS access, and when blitter does not have control of the bus. This way if blitter does internal operations, it is allowed to run at 16mhz.

When blitter otherwise has control of the bus, IE acess to RAM, it runs at 8mhz. Overall the results do not make sense. You would expect as blitter has some speed injection to run at 16mhz, that it would run faster. but it does not.

On a MSTE the CPU gain at 16mhz (without cache) on this GEMBENCH test is 25% (125% against a ST 8mhz no blitter). In your test the result is 133%. In Display, only 9% (109%) without blitter and 135% (235%) with it.

With cache and blitter, the results are 264% on display and 197% on cpu.

qq1975b wrote:On a MSTE the CPU gain at 16mhz (without cache) on this GEMBENCH test is 25% (125% against a ST 8mhz no blitter). In your test the result is 133%. In Display, only 9% (109%) without blitter and 135% (235%) with it.

With cache and blitter, the results are 264% on display and 197% on cpu.

263% for display, so the current graphics power matches the MSTE then... Your CPU results will be faster because you have cache. 25% CPU gain without cache is lower than my figures now, as CPU is 133%, so assume yours is 125% with 16mhz no cache ?