Crazyace

Well if you've got any sync scroll code lying around ( I thought I'd take a look back for Atariksi's 5 points... and got as far back as then when I thought why am I bothering )

No problem, I wrote it for my info more than anything else, and then posted it so at least there would be something to back up my claim. I'll see if I can get the Battlesquadron first level to assemble ( I couldn't fully recover one of my data discs ), as that uses vertical smooth scrolling ( 16 colours ) with roughly 20 scanlines worth of time. - Not speculation, but actual figures for a game. To me, Sync scrolling is just as valid as the prior 0 hacks on the 8 bits, something that relies on an undocumented reliable mechanism in the hardware to give a boost to the machine capabilities.

I'm not going to argue against your list ( Can't really be bothered, and I probably agree with them anyway..( at least if they're sane ) ) I only became intrigued because you went on about Boulderdash ( and Joust ) as examples of the inferior machine, when they're more like unoptimised implementations. After all, I wouldn't use 'Journey to the Planets' as the best the A8 could do.

Wrong. It proves that you can barely fit a 3-plane scroll into a frame's time which was required for the Boulderdash example. Atari still has superior scrolling as it takes less time and can still do more than 8-colors and scroll them. It's not a 3 plane scroll - please take a look at the code, or at least read my description. It's a 16 colour 320 resolution display scrolled at 160 pixel resolution - based on palletted 4 colour characters. It does fit in a frame though, which is enough to reproduce Boulderdash a lot better than the version that came out. I'm sorry, I thought you might look at the code. But here's some numbers. Per group of 4 chars ( header ) - (28+32+48)*5*12 = 6480 cycle Per 4 char line - 48+76=124*5*184 = 114080 ( Matching boulderdash, as Pete pointed out ) Total 120560 cycles, giving over 12k cycles for other stuff on NTSC ( >39k cycles on PAL ) A lot closer than the 4 colour only code, but I expect some of the better ST programmers ( especially some of the demo guys ) could reproduce the game (on any ST/STe) using less than 10% of the cycles I've used.

Nautilus. 2 independant scrolling regions. Sometimes a dozen or more objects independantly moving in each window. The problem with using brute force CPU power to duplicate one method that another machine does almost for free in hardware is that it leaves little left for duplicating other things. Smaller scroll area - 64+96 makes it easier in some ways. ( I'd probably use a different technique as it's more of a fixed background ) The brute force comment is true, but in many cases even when duplicating a 'free' effect there are quite a few cycles left. ( And the A8 is a poor example, as the display is not free ) Now I'm going to have to play Nautilus again.. ( Uncharted 2 goes back on the shelf )

I'd call it a draw - pokey was pretty cool, and had lot's of tricks but the ST sound chip had an amazing advantage - the volume control was logarithmic rather than linear. That made it possible to produce an effective 8 bit ( or even a little more ) signal from the mixture of the 3 channels. ( The ST sound chip was considered rubbish as things had moved on though - the Amiga was the 'future' of sound )

Not like it makes a different to A8. Add up to 240 scanlines of LMS/HSCRL/VSCRL and it hardly adds any time to the scrolling unlike ST (and C64). Looks like A8 Boulderdash is scrolling in the 24th line vertically (although 23 are visible); however, in ST's case don't you have to split your routines for the 16*16 renderer... Don't care about the C64 ( not in this topic ) Of course you're right about the vscroll on A8. But what the code here proves is that it's possible to reproduce the scrolling found on the A8 with software on the ST, and that the game you were using as a weakness of the ST hardware platform ( Boulderdash ) was just a case of unoptimised coding. Your other example 'Joust' is similar, but I doubt that I have to prove that to you. I can't really think of any game on the A8 that couldn't be reproduced exactly on the ST. The machine is just more powerful, and it's enough that the crippling lack of A8 style hardware scrolling can be overcome by software. ( Like your VGA analogy - once the cpu could send 320x200x256 every frame to the graphics card all of the hardware tricks could be reproduced in software. )

All ST's had colour output ( RGB ) via the stupid non standard connector ( I had to poke resistor legs in on the first ST I played with as I had no connectors ) Probably the reference is to not having RF out

Good point ( I'd been assuming it was 192 lines of background + 8 lines of score )

This is running a 16 colour boulderdash scroller. ( Well it's a bit of a cheat - the 16x16 characters only have 2 bitplanes per pixel, with the other 2 bitplanes constant across the whole character ) - It's enough to manage the 5th colour that the A8 offers. It still runs in a frame - but the timing is getting a lot tighter on NTSC. BOULD16.zip

No problem, I've only been looking at the case for 'boulderdash' scrolling - and looking at how many cycles are available for each machines processor. After all , on the A8 there are cases where you run with the screen turned off completely to maximise cpu cycles - so even a non scrolling screen takes a sizeable number of cycles away from the cpu ( If I had local bus graphics/1GHz cpu it wouldn't be interesting any more, as it wouldn't be a challenge. So let's just stick with comparing the A8 and the ST )

Different comparison topic though ( I don't want to be dragged into that.. )

To be honest I wasn't that fussed about exact cycle counts ( apart from when I scribble possible loops ), but the 0 cycle cost on ST is effectively true due to the interleaved 68000/DMA cycles ( baring the odd 2 cycle offset opcodes, which is why I mentioned rounding to 4 earlier ) compared to the A8 where Antic and 6502 fight for the 1.79MHz memory. I'm interested in what timings I might have missed though. I guess the problem with ST games in general, was that they were pretty much always ST/Amiga games - so the graphics were shared, and the ST version sucked compared to the Amiga version. It wasn't really being compared to the A8 at the time though. ( I had loads of bits of scrolling routines lying around, but basically a decision to run at 25Hz was made, and everything was designed to look good around that ) Doing code today isn't like 'remembering about a nitrous button' - it's more like thinking 'I could drive better, given the experience I have now' ( Given that the required 30 minutes 'shredding of the christmas present wrapping' has occured, I've got some time in front of the PC - so I can waste it playing around with code just because it's fun )

The valid comparison is to compare like for like, not the delta - ie. static screen vs static screen is 0 cycles on ST vs xxx cycles on A8 , and scrolling screen is nnn cycles on ST vs yyy cycles on A8. Also comparing the 'free' cycles is valid, as it shows what the 'rest' of the system is capable of after the scrolling. Never the less hardware scrolling is a huge win for the A8 , and as I said before it should have been part of the ST. However it doesn't automatically make the A8 superior to the ST , as pure software gruntwork can make up for the lack of elegant hardware. I'll go back and play a little with the code to make it 8 colours - as you are write^H^H^H^H^H right about 5 being used on the A8 though. ( and have a merry xmas )

I suppose I could check in the Atari800win debugger - but I always assumed the animations were simply 4 ( or however many ) different character sets - as only 1 write would be needed to change all of the animations.

Are you sure? - I've just been frame stepping boulderdash on the emulator, and the diamond seems to only be 4 colours in the animation. As far as cycle counting though - you need to calculate all of the dma cycles taken for the display to compare against the ST ( as ST video/refresh dma doesn't slow down the 68k )

Thanks for the info.

It's not relevant to me, as my example was not 'scrolling mode 4 on ST' but 'Boulderdash on ST' ... Give me the exact timing calculations then - I'm not in A8 mode at the moment ( I remembered that when scrolling is enabled PF width goes up from 40 to 48 bytes )

Boulderdash uses ANTIC mode 4 and has 5 colors. I can see the five different colors for the playfield. I captured the screen for the playfield, and there were only 4 colours - I know that there are 5 colours supported in that mode though - it just wasn't relevant to reproduce the game at 60fps on the ST. Okay, I'll correct you since you're wrong. ANTIC mode 4 is 24 lines not 192. Also, adding scrolling to a display shouldn't include the time for display dma or refresh. That would be a separate comparison. and I'll correct you back as you are wrong - Antic mode 4 in this case is 192 lines, 24 of which fetch map data as well as char data - hence 192x48 + 24*48. Refresh takes cycles away from the A8, and not from the ST, so that's why I included it. The dlist fetch may be less than 192*3 - I never checked if the entries are fetched redundantly every line, so feel free to add 500 cycles to the a8 count.

The 68010 sped up small instruction loops, but didn't help if the loops were bigger, or unrolled already for speed. Regarding the blitter/STe - they weren't part of the original machine spec. ( A blitter, or scrolling at the ST launch would have been much superb though )

I'd have killed for a barrel-shifter , ( though not as much as h/w scrolling ) I think I'm pretty safe with the cycle counts - the 68k normally runs a 4 cycle memory access, and only 2 cycles are needed for the access, so the dma takes the other cycle. ( The amiga is the same way, so 320x200x16 doesn't slow the cpu down ) I expect that if the 68k get's out of sync ( via a 6 cycle op maybe ) it's delayed by 2 to fix things up

Yes, it's only 2 planes - that works for me as Boulderdash is only 4 colours. The other twelve colours are available for software sprites. It's not GTIA though Atariksi - but it is 320x192x4 colours, which is something the A8 can't scroll at all. ( Correct me if I'm wrong, but for on the A8 there are probably 192*48+24*48 cycles for the scroll, plus 192*3 for dlist, plus 262*4 for refresh. So thats other 11000 cycles taken for the display - leaving around 18000 cycles for the 6502 ... even assuming that the 6502 is more efficient than the 68000, the ST has nearly 15000 cycles extra to play with per frame. ) The sad thing is that the ST should have had h/w scrolling from the start - Even a simple 0-15 pixel scroll ( and the ability to rewrite the screen ptrs in hblank ) would have had a stunning effect on the quality of scrolling games

The main memory bug and running C on the riscs has nothing to do with each other. Running gpu out of main is not always faster than the 68k. It would have to be "wonderfully optimized assembly" in order to be useful in main. They are related if you intend to write an entire game in C - not just a group of small routines. It's interesting that you find cases where the 68k is faster than the GPU running from main? What are they? Are they situations which would run faster if the memory bugs had been fixed?

I always considered it unusable because of the local memory limitation myself, but it was a compiler - and if it had been the only compiler for the machine then Atari could have had the bugs fixed. ( It was gcc - so the compiler is good, just the machine model is bugged )

This is the code, it's just really a scribble though code.zip