Crazyace

A Spectrum 512 image uses 48 colours per line - so it's better or equal to the 32+ colours in Gr.9+PM due to the 320 pixels vs 80 pixels.

That's what you did. However, there are some factual postings in this thread-- here's another see if you can disprove them: (1) Atari 8-bit has sprites and ST does not nor cannot it make up for them with its faster CPU. (2) Atari 8-bit has more shades and the ST cannot make up for it even with more colors. (3) Atari 8-bit has faster joystick I/O than ST. (4) Atari 8-bit can update a scrolling display faster although at lower resolutions thanks to ANTIC's various modes and features. (5) Atari 8-bit has easier overscanning capability Haven't tested all aspects of Atari ST hardware to draw any conclusions or give some more points but the above should be obvious. Here is original post with my 5 claims. ST cannot make up for the A8 sprites in software. Comparing 4 colour 10 pixel h/w sprites against 16 colour software sprites the A8 has 448 'lines' per frame , and the ST could draw around 869 'lines' - so the ST could match the 8 bit PM display hardware using around 50% CPU. Clearing the sprites would be 10% ( but the A8 would probally take more than 10% clearing/setting the Players and missiles ) and then it's just 40% ST CPU left to match game code on the A8. ( And obviously one of the ST demo guys could reduce the time dramatically, but I'm not going to bother writing a 2 plane routine - just looking in awe at the 312 sprite demo ) Your points 3,4,5 are definitely true though.

I was comparing software v software - There are no h/w sprites on the ST so there's not much point comparing them. ( In my book the lack of h/w scrolling was vastly more damaging than the lack of h/w sprites )

You've obviously stumbled on Curt's secret plans for the new Maria chip - 78000 to rule them all!!

That's really cool - 312 16x16 sprites at 50 Hz works out at around 32 cycles per line! Definitely elite optimisation as that also needs to cover the unpaint/clear time. The code above is more a general purpose fragment to compare the two machines - It's actually quite funny that the 68k would be faster than the 6502 in cycle count as well though, as normally the 6502 is considered king of the cycle counts... ( In my ST games my sprite routines were never this optimised , I always ran out of memory - so I never had preshifted sprites... and the shifts vary the time taken. I tended to spend a lot more time trying to optimise the background scrolling as that took way more cycles )

Did Mr Robot or Hero come out on the ST? I agree that Boulderdash sucks on the ST, the scrolling is really jerky. Joust on the other hand looks way better on the ST - why do you think it's technically inferior to the 8 bit version?

Scrolling is a huge win on the A8 - It can take a huge amount of time to copy a screen on the ST to emulate scrolling ( Unrolled movem.l (a5)+,d0-d7/a0-a4 ; movem.l d0-d7/a0-a4,xxx(a6) takes 616*12*2 cycles + 8000*8*2 , so nearly 18ms for a full screen ) Drawing a 16 pixel wide preshifted softsprite is a bit more even.. On 8 bit 20 pixels needed ( 4 per byte ) lda (scr),y ; and mask,x ; ora data,x ; sta (scr),y ; iny 5 + 4 + 4 + 6 + 2 = 21 Repeat 5 times, except for last iny , so 21*5 -2 = 103 cycles On ST 32 pixels needed move.l (a0)+,d0 ; move.l d0,d2 ; move.l (amask++),d1 ; move.l d1,d3 12 + 4 + 12 + 4 = 32 and.l (a1)+,d0 ; and.l (a1)+,d1 ; and.l (a1)+,d2 ; and.l (a1)+,d3 14 + 14 + 14 + 14 = 56 or.l (a0)+,d0 ; or.l (a0)+,d1 ; or.l (a0)+,d2 ; or.l (a0)+,d3 14 + 14 + 14 + 14 = 56 movem.l d0-d3,-(a1) 8+4*8 = 40 Total of 32+56+56+40 = 184 cycles... ( based on 68k timings now rather than testing - but close enough for this example ) It seems like the 8 bit is nearly twice as fast based on the cycle count , but the ST is drawing 16 colour rather than 4 colour sprites ( It would be 21*9-2 or 187 cycles for a GTIA 16 pixel sprite - so actually slower! ) , and the ST is clocked over 4x faster

AtariKsi is right though - there are things on the 8 bit Atari that are superior to the ST - even though I don't feel the need to prioritise joystick reading as much. Having 16 shades of each colour is nice for certain effects - and the mixing of colours via GPRIOR is an excellent bonus. But the reds on the 8 bit suck, and there are no unsaturated colours. I could imagine a straight forward evolution of Antic/GTIA to a 16 bit machine being way more capable than the ST , 4x memory bandwidth would allow 160 pixel by 256 colour modes as well as 320x16colour and 640x4 colour - and Antic would have both character and bitmap modes. But the Amiga showed the real way forward , emphasizing the blitter objects and bitmap graphics over character mode graphics and hardware sprites.

Yes it would have and it would have had better software as ports would be much more realistic on an 020, with better blitter and no penalties on stalls. You just do not have a clue and I am not going to go through the clear and simple reasons as to why it would be able to for the umpteenth time. clear and simple and wrong reasons

Curt's efforts are worth it just for the information he makes public - His site is really cool and I look forward to the info he and Marty unveil on all of the Atari Corp projects. If he makes a 7800 flashback I'm sure it will sell enough units to return his investments Sometimes I look back on some of the cool hardware I've worked on in my current job - and I wish that they'd show up via digital archaeology in the future. I doubt if they will though...

The Playstation would still have wiped out a 'better' jaguar - as even the Jaguar 2 blitter wouldn't have competed ( at the speeds Atari were talking about in 1995 ) The only way for the jag to have survived would have been with more ( and better ) software at launch. Then they could have faced the launch of PS1 and Saturn backed with an install base in millions, instead of a palty 100k. ( I favoured CD as a hardware change at launch, but really the software is all that matters.. )

For me the saddest thing is that the scrolling wasn't put into the ST - it wouldn't have been that difficult to add the ability to fine scroll to the shifter ( and the full address range rather than 256 byte alignment for the screen ) In my opinion the ST is a superior computer ( for it's time ) , but the Atari 8 bit is a superior games machine ( again for it's time ). The joystick comparison that Atariksi makes is a red herring though, as the joystick/mice don't need a fast sample rate. Using the joystick ports for general I/O is required on the 8bit, but the printer port, or hard disk port are better suited on the ST.

The same is true for software "sprites" (both would be blitter objects to be more accurate, software manipulation vs hardware though), but you can run into screen tearing/shearing if you push things too hard, right? (exceed the bandwidth w/out double buffering) Yup - the ST has the same advantage ( although it's slower ). You would always double buffer the screens though, as it's simpler than the alternatives. ( The PC-Engine was pretty fast for a 6502 machine - I wonder if it could manage as many software sprites as the ST )

You mentioned the genesis though, which was limited to a 9-bit RGB palette like the ST and PC Engine, and only had 4 16-color subpalettes. (another difference with SNES and genesis was chunky pixel organization opposed to planar on PCE/Amiga/ST) The PC engine also had a huge advantage in hardware sprites over the Amiga (similar to Genesis I beleive). Sound is debatable, but if nothing else the PCE had good sample playback capabilities, very clean. (sometimes even better than SNES like with Street Fighter, and almost always better than Genesis -which relied on Z80 or 68k for controling sample playback in software with the bare 8-bit DAC on channel 6 of the YM2612 -so more like the ST except it had a plain DAC to write to rather than using tricks with the YM2149 and the Genesis had the Z80 coporcessor) Of course the Genesis had 2 BG scroll layers to the PCE's 1. (and amiga tended to use blitter objects instead of its limited hardware sprites) HAM isn't useful in games other than splash screens, OTOH the Amiga does have 32 colors compared to the 15/16 color tiles of PCE/Genesis (and usually SNES as well, with 8-bit color mode rarely used, mode 7 probably most prominently), but that's 32 colors for everything (only 16 of which can be used by hardware sprites) so its a trade off compared to multiple 16-color subpalettes. (many colors tended to be redundant with subpalettes though and were 15 colors rather than 16 due to 1 reserved for colorless) In halfbrite mode I'd say the Amiga definitely has the color advantage in general over the Genesis and probably PC engine as well in some cases. (and SNES has the 8-bit color modes) Yes, the blitter outweighs the sprite advantage somewhat - and I was thinking of EHB ( as it was pretty much standard on all Amigas except the very first ) giving 64 colours from 4096. Copper can increase the number of colours per line as well. HAM actually works quite well with H/W sprites - as the base 16 palettes control HAM, and the 2nd 16 palettes control sprites. The biggest advantage of the amiga was that there was no limit on sprites when the blitter was used. The frame rate would drop, but there'd be no flickering. The biggest disadvantage was the single button joystick

Curt, Do you have the schematics for Antic, or just the layout?

What about the PC Engine (TG-16)? That would have been the first to rival it, prior to the Mega Drive's release. (and indeed, even had some technical advantages over the MD and SNES) The PC Engine was ahead in some areas ( notably number of pallettes for sprites/charmaps ) and behind in others, like multiple playfields, HAM, and the 4096 colour range )

My view on this, Looking back there is no comparision: The Amiga is infinitely better ( original model ) even compared to the STe. The hardware was lightyears ahead in all aspects apart from the monochrome 70Hz mode - which saved the ST in serious applications. For games the Amiga hardware ruled , and nothing really matched it till the Genesis/SNES arrived. However at the time price was king, and the ST gave most of the Amiga experience at a far lower price, and there were some great games that worked better ( For example Dungeon Master needing 1MB on the Amiga compared to 512K on the ST ) The ST was ( for me in the UK ) a spiritual successor to the Spectrum

Has anyone looked at the c64 code for ROF , I wonder if it was broken during the conversion - I'd only really expect half speed for the C64 compared to the Atari ( lower cpu speed + extra overhead for filling in 2x lines ) and it does seem a lot slower.

I look forward to the release - the 8 bit and 2600 emulator/debuggers have really spoiled me. ( I even spent quite a bit of time using the SPE simulator for cell because of the extra info shown )

A Jag emulator with debugger would be amazing - it really makes it easier to code, so I hope that all of your emu projects aren't in limbo

I think that's only rotating by 90 degrees, which could be implemented pretty quickly

I wonder if the CoJag had two banks of DRAM rather than 1 ( I've seen sites that state extra ram , but no details ) - If so then blitting may have been more efficient with source in the first bank, and screen in the second due to less pagebreaks.

It should be pretty simple - As there are no games for the JagII the emulator suddenly becomes the reference. There are probably still more issues with emulating the original Jaguar system.

Again wrong here. The Atari version is one year older. The coder has learned in that time to make some things better on the C64. It's similar to Rescue on Fractalus. One example is the compass. The coder used "better" colours for the directions. Not to tell about the "simple" Gr. 0 lines. Well, as we might see, to have more colours sometimes means, the "artist" has to take care about the correct ones. Having only "some" colours restricts the coder to use what that hardware has to offer. Sometimes it seems to be better to restrict other's thoughts Wayout is simply faster due to the double scanline mode, and has nothing to do with some "superior" coding. The superior coding is done on the C64 for sure. I don't think that Wayout uses a double scan line mode - it's just mirroring the 48line 64 pixel wide upper half of the display area. I guess the C64 version uses a grid of 6 chars by 16 chars for the upper half - arranged in vertical strips as that would optimised the line drawing ( I'd actually make it an imaginary 8x16 grid to ensure power of two offsets ) The reflection is then extra work to copy the top half into another 6x16 char block for the reflection ( 768 byte copy ). Most of the difference in speed should just be because the A8 has the faster CPU - ( the extra copy time doesn't help either ) - The Apple II version also seems a little bit slower as well.

Only if you are working on 2600 code