I must admit the Amiga Blitter has been my nemesis on more than a few occasions. These videos contain some really useful information that most people have to learn the hard way. The way you are explaining things and showing your thought process is fantastic. Well done.
@@pixelplopWith all those parameters you need to set correctly to do a blit, it would be easy to mess it up. It also shows that it only took the next processor iteration in the Amiga to mess up lots of games. The 1200 is probably able to access memory on every clock cycle and coupled with the CPU cache, it's way faster than A500 which unfortunately meant lots of software would just stomp over an ongoing blitter operation. It's amazing to see that menace works fine on an A500 with not a single care about whether the blitter was still running, even testing the result of the blit on the line after it started worked fine on the 500.
So far, I'm tremendously enjoying this series. Don't own an Amiga, never owned one either. Never really programmed in assembler either, apart from some assignments back at university. But all of this, it just clicks in my brain. You explain it very well.
Awesome job fixing that. Is it possible the problem is exacerbated because the 68000 in an A500 without fast RAM would slow down until the bltter has finished cycle stealing?
@@SM-rn3xy it must be doing that because the collision detection check is literally on the next line after the blitter was started to do the check and the A500 had no problem with it. I think the biggest problem on A1200 is the double clock speed and the CPU cache which is allowing the processor to get some work done concurrently with the blitter. I think the code in menace is still being loaded into chip ram as there is a directive at the top telling it to be loaded into chip.
Two things: "clr" is a bad idea on 68000 but good on 68020+. If you were so inclined you could just mark all the code as residing in chipram and turn on blitternasty - that would probably have fixed it without any wait inserts. I don't know if that would have made it too slow for a pure 68000 though.
@@NorthWay_no I didn't want to turn on blitter nasty as it's just throwing away any performance you can get from running the blitter concurrently. But even with that on, I think the CPU could still execute depending on conditions. As for the chip ram, I believe this game already marks the code as wanting to be in chip ram, so could change that to get even more speed. I the CPU can get access to chip ram on 68020 whilst the blitter is running as it can go in-between Dma cycles.
@@DavePoo2 The 68000 will - for some unfathomable reason - do a read before it writes 0. That can have both unintended consequences with hw and is slower or no faster than a move #0. The 68020 and later will just do a fast 0 write.
I would suspect it does a read because to write a 0 it is doing an 'exclusive or' with itself to get the zero. Looks like the CLR and EOR instructions take exactly the same amount of time. wiki.neogeodev.org/index.php?title=68k_instructions_timings But looks like you are right, if you want to do a CLR.L, then it's quicker to do a a MOVEQ #0, D0 instead as that will clear the entire long word. But if you want to do a CLR.W or CLR.B then you can't use MOVEQ as it always affects the entire longword.
@@PaulOvery001 I'm happy it's working as it runs perfectly every time. Ideally it would need to be run on faster 68000s to see if I have caught them all. As in some places, maybe even the 68020 wouldn't be able to catch up before the blitter finished.
![ลองสั่งของจากแอพ temu ถูกจริงหรอ?? ( part : 1/2 ) [โกงไหมครับ ep.89 ] | DOM](http://i.ytimg.com/vi/RTcZSQTiDZw/mqdefault.jpg)
I must admit the Amiga Blitter has been my nemesis on more than a few occasions. These videos contain some really useful information that most people have to learn the hard way. The way you are explaining things and showing your thought process is fantastic. Well done.
@@pixelplopWith all those parameters you need to set correctly to do a blit, it would be easy to mess it up. It also shows that it only took the next processor iteration in the Amiga to mess up lots of games. The 1200 is probably able to access memory on every clock cycle and coupled with the CPU cache, it's way faster than A500 which unfortunately meant lots of software would just stomp over an ongoing blitter operation. It's amazing to see that menace works fine on an A500 with not a single care about whether the blitter was still running, even testing the result of the blit on the line after it started worked fine on the 500.
So far, I'm tremendously enjoying this series. Don't own an Amiga, never owned one either. Never really programmed in assembler either, apart from some assignments back at university. But all of this, it just clicks in my brain. You explain it very well.
@@EvenTheDogAgrees thanks. I'm all a bit rusty at it myself. I haven't done 68000 since the 90s. It's coming back slowly.
A very happy October 3rd to you, Senor Poo!
I do hope you are in excellent fettle on this splendidly delightful Thursday eve.
@@thegreathadoken6808 I am indeed in excellent fettle.
How frustrating to discover after all those changes that it was the *assembler* that was the problem!
Awesome job fixing that. Is it possible the problem is exacerbated because the 68000 in an A500 without fast RAM would slow down until the bltter has finished cycle stealing?
@@SM-rn3xy it must be doing that because the collision detection check is literally on the next line after the blitter was started to do the check and the A500 had no problem with it. I think the biggest problem on A1200 is the double clock speed and the CPU cache which is allowing the processor to get some work done concurrently with the blitter. I think the code in menace is still being loaded into chip ram as there is a directive at the top telling it to be loaded into chip.
Two things: "clr" is a bad idea on 68000 but good on 68020+. If you were so inclined you could just mark all the code as residing in chipram and turn on blitternasty - that would probably have fixed it without any wait inserts. I don't know if that would have made it too slow for a pure 68000 though.
@@NorthWay_no I didn't want to turn on blitter nasty as it's just throwing away any performance you can get from running the blitter concurrently. But even with that on, I think the CPU could still execute depending on conditions. As for the chip ram, I believe this game already marks the code as wanting to be in chip ram, so could change that to get even more speed. I the CPU can get access to chip ram on 68020 whilst the blitter is running as it can go in-between Dma cycles.
@@NorthWay_no what's the deal with CLR?
@@DavePoo2 The 68000 will - for some unfathomable reason - do a read before it writes 0. That can have both unintended consequences with hw and is slower or no faster than a move #0. The 68020 and later will just do a fast 0 write.
I would suspect it does a read because to write a 0 it is doing an 'exclusive or' with itself to get the zero. Looks like the CLR and EOR instructions take exactly the same amount of time. wiki.neogeodev.org/index.php?title=68k_instructions_timings
But looks like you are right, if you want to do a CLR.L, then it's quicker to do a a MOVEQ #0, D0 instead as that will clear the entire long word. But if you want to do a CLR.W or CLR.B then you can't use MOVEQ as it always affects the entire longword.
Sanity check - Stub out macro, make artifacts come back.
@@PaulOvery001 I'm happy it's working as it runs perfectly every time. Ideally it would need to be run on faster 68000s to see if I have caught them all. As in some places, maybe even the 68020 wouldn't be able to catch up before the blitter finished.