Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, Moderator Team
leonard wrote:Frank B wrote:I just had a brainstorming session with Doug. I think we worked out what the issue is. I think the real hardware clears both the busy bit and the bus sharing bit at the end of each blit. The hog mod state doesn't persist from blit to blit. It needs to be set each time. If this is the case it would explain the code running at half speed. It would also be a bug in both Hatari and steem. My wifi at this airport is horrible. I may not be able to upload the next build.
it really make sense! I'll test your new version when you post. Btw I always prefer using move.b #$c0,$8a3c instead of bset #7,$8a3c
Frank B wrote:I assumed it would be set. Previous experience on the Amiga.
In any case the behaviour isn't documented. It is now
npomarede wrote:Frank B wrote:I assumed it would be set. Previous experience on the Amiga.
In any case the behaviour isn't documented. It is now
By the way, if we want to be complete, there're 2 cases where busy bit is cleared :
- at the end of a transfer, as in your case
- "immediately" if line count at $FF8A38 is 0 when blitter is started
In both cases, I now clear hog bit too in Hatari.
But for 2nd case, some checks could be made on real STE :
- if line count is 0, how many cycles are taken after a write to FF8A3C ? Does the blitter tries to take the bus anyway and gives it back just after ? (I guess it's the case)
- in that case, is hog bit cleared too ? If there's only 1 common path in the blitter, then it should be. But maybe the blitter has a special case if line==0 at start ?
Nicolas
Frank B wrote:Yeah.. I need to do some optimisation yetThe original could do 30 a frame. The theoretical max is 35.
I'm also seeing it lie about the frame count sometimes in the emulator.. More bugs to fix. That said, here comes the STFM and Falcon compatible version. Enjoy
exxos wrote:V6 shows $1A bobs, all is well, $1B and 2 VBL and slow down, but also you seem to have a new bug as the whole screen jumps vertically
exxos wrote:Interesting program for sure, defiantly does bobbing better than CPU it seems.
leonard wrote:exxos wrote:Interesting program for sure, defiantly does bobbing better than CPU it seems.
I like the blitter too, but to compare with CPU I think that a "generated code" section must be added. Blitter is obviously faster than CPU for sprite if you can't preshift. But if you have enough memory to preshift (always the case in demos), then you have enough memory to use generated code. And in that case, I'm not sure blitter can beat CPU, even for 32*32 sprites.
There is really few demos with 2 bitplans sprites. generally it's 3 or 4. Maybe Franck could add a 3 bitplans sprites in its benchmark. To compare with CPU, that demo is cool : http://www.pouet.net/prod.php?which=29317
-it uses 32*31 sprites, 3 bitplans ( anyway 11 lines of the sprite are 2 bitplans )
-it uses real time curve (as in the benchmark)
exxos wrote:@FrankB - Your program starts to load then just quits back to desktop on my STFM with blitter
dml wrote:exxos wrote:@FrankB - Your program starts to load then just quits back to desktop on my STFM with blitter
The blitter existence test might be TOS based rather than HW register based? I suppose Frank will know what kind of test he used
Users browsing this forum: No registered users and 2 guests