Crazyace

As with Boulderdash you state that these games would be inferior on ST - but I contest that, as I can reproduce them 'as is' on the ST ( Boulderdash being the most challenging, but fun to work out ) and then they could easily be redrawn to have superior graphics. The big point with Boulderdash ( when I was looking at 4 colour scrolling ) was that even though the ST lacks hardware scrolling ( and I wish it were there ) it has enough CPU power to reproduce the actual game scrolling found on the A8 game with plenty of cycles to spare. I've found with reproducing Pacman on A8 that effectively drawing 5 16x16 4 colour sprite on an screen is pretty much consuming all of the cpu cycles at 60hz anyway .... ( I really should move away from the ST playing, and go back to that code )

It does require 3 bpp to reproduce the 5 colour mode - so it's a valid observation by Atariksi. And way back then, it was a plus point to compare against the Apple's 6 colour highres mode, and I guess it didn't require any extra h/w as there were already 5 playfield registers for the other text modes.

For Atariski I looked at the Rescue picture on ST. Here is a standard version frat8.jp And then there's a photochrome format version fratphoto.jpg But a better test would be to use a reference image that not 80 pixels across - BSTAR.jpg Normal ST ( spectrum 512 ) - bstar512.jpg Normal ST ( photochrome ) - battlepcs.jpg Atari 8 bit ( GTIA ) - BSTARa8.jpg ( Please feel free to upload a better A8 version, I haven't got any tools to make hip or other A8 advanced image formats )

That would be interesting to see - even the developer ST I used from Atari UK in 85 was able to connect via RGB to my Amstrad monitor. Maybe you're thinking of the composite video on pin 2 of the connector - that may not have been connected on early machines, but RGB was always present.

I just grabbed it from the site I'd assume they obtained the image in the usual way - take a 24 bit master, and reduce it to 128 fixed colours ( representing the A8 pallette ) - Any good paint package should have some option like that. ( I've used PaintShop pro before - I guess GIMP and Photoshop also have the same type of option )

I actually preferred the robot to the spaceship Photochrome is for ST and STe ( the picture I showed you was ST only )

I looked at all of the levels, and I'm pretty certain that there's always more than 50% 'blank' chars - and as I said in most levels the animating chars are a lot less. So 50% is a good number. For DLI I'd just use a timerB IRQ on the ST - I've used it for colour graduations before, and the cost should be pretty similar to the A8 interupt as it's only going to change a single pallette entry. What about custom screens? And regarding DLIs, I wanted to know what overhead you had computed since for ST, you have to subtract that from total cycles in the frame unlike Boulderdash which didn't require that DLI overhead. It doesn't matter if overhead is same as A8 since A8 repainting chars or sprites is a breeze compared to ST. A8 can repaint the screen even with a kernel running full-screen mimicing the Copper color re-use. Do you mean custom screens in Mr Robot? ( I'm guessing you do as you seem to be looking for a reason why the game can't be reproduced on the ST now ) I guess - if I wanted to reproduce the Mr Robot ultimate animated screen ( where each of the 40x20 grid is animating ) I'd switch to a different method , 4 screens. Then I'd only paint a character that changed, and paint it's 4 animation frames - one to each screen. Then to actually animate I'd just change the screenbase - and voila! The number of 'changing' characters is tiny - either objects hit by you ( a few per frame at most ) or bombs changing to explosions ( again a few per frame at most ) And sprites aren't an issue - as the monsters are software sprites on the A8 the time taken to repaint them is likely to be more than it would be on the ST. Regarding DLI overhead I'd probably have something like this: move.l a0,-(sp) move.l dliptr,a0 move.w (a0)+,$ffff825c\w move.w (a0)+,$fffffa20\w move.l a0,dliptr move.l (sp)+,a0 rte It's not the fastest routine, but as it's only hit 20 times per frame it wouldn't be a huge priority I guess on the A8 it's something like this pha tya pha ldy index lda table,y sta COLUPF1 inc index pla tay pla rti

Yep, I've been using those for comparison for a while. (I got that VCS palette immage from the video game color palettes wiki page -all the palette lists use that stock immage) Displays show the entire palette applied at original resolution to the immage and examples of optimized displays the hardware was capable of. (non-dithered in both cases) Here's the one for 8-bit computers, though the A8 isn't listed. http://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_palettes Sometimes I wonder about some articles on Wiki-- if they are biased views of someone or just lack of research. That article should be modified or removed-- shows bias toward certain platforms and other problems. I didn't think the pictures would be more biased or not - I only posted it because they show the pallette well and compare directly - unlike the standard colour grid pictures. They weren't meant to be an indication of actual pictures on the A8 and ST.

If you switch the frequency to 71Hz for a long time it might cause damage. However none of the border removal routines switch actually cause the hsync frequency to change. They just catch the internal state machine at the point where it asserts or deasserts the display enable. To actually change hsync you'd have to catch the state machine at the point it asserts hsync ( or leave it switched all the time ) Also if you look at Griff's routine, it only plays around with the borders for 7 lines in the top border - so the rest of the screen is completely untouched. The warning is the same kind of thing I see on any article ( ie - plugging other devices into joystick ports could damage the A8 , but it doesn't in most cases ) I think on the ST forum there's actually a much more detailed analysis of the ST timings ( by Ijor I think ) where he explains why there are differences between the various models.

It'snot a real a8 picture - but a picture using all 128 colours from the pallette

I think the Bally Astrocade was the only other machine with a big pallette ( 256 colours ) around that time.

Wikipedia has a really interesting pallette comparision here Atari ST: Atari VCS/8 bit (edit) Actually, that's not really fair, as the ST image is quantised to 16 colours. This one is representative of the 9 bit pallette:

... I found this as an example for the standard ST ( not STe ) - in my eyes it looks pretty good That looks pretty good. Same Nrsima (half man/half lion) image I used in my A8 demo posted earlier in the thread. This looks like more than 16 colors though... Yes, it's a photochrome image - ( Around 400-500 colours on the ST ) , I posted it as I thought it would be a valid comparision. The zip file has the ST disk image with the picture and viewer.

I looked at all of the levels, and I'm pretty certain that there's always more than 50% 'blank' chars - and as I said in most levels the animating chars are a lot less. So 50% is a good number. For DLI I'd just use a timerB IRQ on the ST - I've used it for colour graduations before, and the cost should be pretty similar to the A8 interupt as it's only going to change a single pallette entry.

Also, for MrRobot - painting the screen could run quite quickly, even with a 8x8 charset. Something like this per character: move.w (a4)+,a3 [8] beq.s skip [8] or [12 if skip taken] add.l a5,a3 [8] movem.w (a3),d0-d7 [12+4*8] movep.w d0,0(a6) movep.w d1,160(a6) ... movep.w d7,1120(a6) [16*8] skip: It's a total of 196 cycles/char on a grid of 40x20 ( as used by MrRobot ) thats 156800 cycles, which is too slow for 60Hz. However most of the Mr Robot screens have massive amounts of blank space - so in practice less than 50% of the characters will need to be painted. The cost of skipping 50% is just 20*40*(8+12)/2 = 8000 cycles, and the painting then costs 78400 - so the total is way less than a frame. And really, only the characters that actually animate will nead to be repainted, and in practise less than 20% of the characters would qualify in any one level, which is a further saving.

... I found this as an example for the standard ST ( not STe ) - in my eyes it looks pretty good PICS.zip

Switching DRAM to SRAM would be extremely unlikely though I was just curious as to what the routine would be ( all I could think of that might be slower than 68k in main ram might be some kind of polling loop )

also, is it slower because of the main code workaround - or would it still be slower if the gpu didn't have the main code bug.

Just curious as to what it is , as you said a C compiler would only make it worse?

Interesting. What code snippet was it? ( 'unroll loops' in gcc generally increases the number of instructions within a loop )

There is one case where the tight loop senario indeed chokes the GPU. But we are talking very few instructions in between the loop points. Once unrolled it actually ran as fast as it did in local. your saying in that situation the 68k could of done it faster? It sounds like a very extreme example though - and the kind of thing that could be optimised even in C code for gpu. ( ie - if there's a tight loop, unroll it a few times in C code )

I wonder if there are any good galleries - I've looked at some images on various AA topics , but if you've got any better examples? ( Maybe it's worth posting the best looking images on each platform , and then deciding ) Yes, I was quite surprised - but it makes sense, as you could easily have 4 monsters on the same line in the designer. ( See picture ) But it's only 4 real colours for everything except Mr Robot - so I could easily repaint the entire screen, 4 enemies , and Mr Robot in a NTSC frame. ( and if I used 4 screens, I wouldn't actually take any real time for any of the actual repeating animations )

Do you actually have any evidence for this for Sync scrolling? - as none of the sync scrolling techniques I've seen change monitor frequencies or garble memory ( no memory seems to be changed at all - the shifter doesn't write after all ) Yes. I combined both of those unreliable hacks into one sentence. One uses frequency toggling the other causes memory issues. I have read about both and thus avoided both. Ok - please show me the evidence then - I'd be very interested in seeing it. ( Maybe you are getting confused about what switching the shifter from 50 to 60 and back again actually does to the real monitor frequency ) Please also keep on the topic of ST and A8 - any comparisions with CGA, C64 or even Amiga are irrelevant.

Do you actually have any evidence for this for Sync scrolling? - as none of the sync scrolling techniques I've seen change monitor frequencies or garble memory ( no memory seems to be changed at all - the shifter doesn't write after all )

I've noticed more flickering on the A8 pictures myself - maybe it's a combination of bigger pixels, and not flickering between the 2 closest shades? ( I still remember being super impressed by the first 256 colour PAL pictures on the A8 - at the time that was amazing ) I just had a look at Mr Robot again - I'd assumed that the monsters were paired players, as I've only seen 2 intersect on a scan line - but at closer inspection they are 9 pixel wide software sprites, and Mr Robot is the only player graphic. So no multiplexing there. I'd probably just repaint the screen each time ( for anything non blank ) on the ST as I'm pretty sure I could handle a whole screen of animating bombs easily in a frame. But if not I'd just have 4 screens, each one representing one of the animation frames and cycle the whole screens in the same way that MrRobot cycles character animations.