Crazyace

No, blitter is still better than doing it all in software. You have this misunderstanding that CPU speed alone can make up for lack of all other hardware. Let me give you an example-- 16-bit ISA VGA cards barely can muster 2MBytes/second using the fastest instructions REP MOVSD. Now even if you double the processer speed, you still won't get any faster. The I/O limit has been reached. So if you wanted to scroll a 640*480 screen in software, you have to update 150K for each frame or 150K*60 = 9MBytes/second so it's IMPOSSIBLE to do smooth scrolling on an ISA VGA in software regardless of how fast your CPU is. What's that got to do with the ST though?

Using sync scroll code gave a real boost to scrolling ( especially vertical scrolling - horizontal still had the 16 pixel limitations ) - It's a pity that it wasn't more widely available in games earlier. Also it's not killing CRT monitors, it's just an unforeseen use of the hardware in the same way as the GPRIOR=0 hack on the 8 bit. The STe should have been the original ST though - although I agree with oky2000 that a faster 68000 would have made up for a blitter more that anything else... ( Imagine if it had been at 10MHz 68000 at launch , the increased clock would have supported 512 pixels/16 colours using full overscan )

Making the CD an add-on was the biggest mistake, everything else about it was a 'win' , CD gave much more memory than carts for a far far lower price, and the logistics were way better. A free SDK wouldn't have helped much - developers tend to want working tools in the first place , it's not their job to rewrite things from scratch. ( The Sega CD was a lot more popular than the Jaguar - the 32x seemed to be the big mistake )

First of all though a data cache would be an added extra, the instruction cache is REALLY what matters here and that alone would allow the 020 to run off the bus quite efficiently. You also miss(again) the obvious point and fail to mention the fact that we are not talking about a 13 mhz but a 26.59 mhz clock rate. Fail. Then you completely and constantly ignore the double bit width. Even The 68k with a 64 bit prefect would have made a more efficient effort. The obvious is that now the Blitter and the OPL have the Bus almost 85% of the time with two riscs and the host running instead of as is with two risc(one at half the bit width) and a 68k that ate up 85% of the bus could not run in parallel AT ALL. The two risc did not have caches at all. They had local RAM. So your point is moot and it's also very mis-informed. Properly coded your opinion of the risc's are wishful PS1 fanboy at best. The Jag Riscs with properly interleave code can do 0.75 to 1.00 MIPS per mhz. So real life and fact go much further than a tainted opinon. Also 020 at 26.59 x 0.2 = 5.32? funny since the 68k is doing about 1 MIPS at 8 mhz. So where you got these obviously false/flawed numbers from further shows your desperation to be right whenyou are wrong. Therefore the 13.29 hmz 68k was doing about 1.5 mips. So with that said, an 020 with a cache and twice the clock and twice the bit width should be doing a lot better than what you wish it to be...probably near 6 to 7 mips wich for game AI and logic is more than enough....many times more than useful and proven chips like the 68k/6502 and Z80 which were fine for their game logic. I took the MIPs figures from wikipedia , and extrapolated the gpu figures , 0.5Mips/Mhz is kind of what I'd expect, with the stalls and redundant move instructions that are often needed. I definitely picked a lower figure though, you're right that a tight hand tuned loop could be better - but that's not likely to occur with C compiled code. How much would a 27MHz 68020 have cost in 1983? Even a 13MHz 68ec020 would be a lot more than the 68000? The reason why I dont favour a 68020 is that fixing gpu/dsp would give 32 bit risc code running from main memory for no cost ( as in a perfect world the bug would not have occurred in the first place )

Yeah well he thinks an 020 would not help the Jag at all, so consider the source. Having an Idea of the specs means nothing. Jag with an 020 and the proper tools, Sony would not have had it as easy. But of course the ineptness of the Tramiel Atari never ceased to fail anyone. I just point you to an article that reflects the gospel truth Regarding your comment Gorf, I half agree with you - when I first thought about this a better cpu seemed like a good idea ( although I prefered something like the IBM 486SL25 - as it had cache and fpu, and was pretty cheap... ) But then I thought about the gpu/dsp main memory execution and how trivial the bug stopping them working was - and I leant towards a good GPU C compiler/toolchain and debugger as being much important. Having a CD at launch is just my feeling ( in hindsight ) that Atari couldn't succeed with a split machine - the Sega CD add-on had a massive install base of machines when it was launched, but the Jaguar CD was too little too late. Atari needed developers to work on games without being paid/published by Atari, and they didn't have the market penetration to get that. ( A 68020 is rated at 0.2MIPS/MHz , a 68000 0.125MIPS/MHz - the Jag GPU / DSP are (in my opinion) more like 0.5MIPS/MHz - so they are better for running code, and also have the advantage of being able to run completely off the bus in internal memory, unlike the 68020 which lacks a data cache ) So for me, in 1993 I'd have: Fixed GPU compiler ( and debugger ) Fixed main memory instruction bug - so GPU and DSP can run freely from main memory. No 68k at all ( GPU tweak to start code from rom ) - so DSP connection is 32 bits rather than 16 bit. Single speed CD as standard ( build Butch functionality into Jerry, even if it means removing the waveform rom to save memory )

Seemed pretty fine for games when I used them. But I guess you would want the 5V supply for projects - ( Was there a standard for current draw.. I never saw one ) If so just use an external supply Apple and Tandy didn't use the same joysticks, so they weren't really standard - and even IBM had different joysticks - they were probably more of a standard

Sony didn't begin designing the Playstation we know until 1993. I agree that target specs were probably being shown to a few developers in 1993, but actual hardware didn't exist that year. I've read a story about one early developer prototyping on SGIs without real hardware, desperately hoping they would receive a devkit and complete a port, just to make it as a launch title! They ended up making it with something like 8 weeks from first hardware to gold master. Playstation history is a little confusing because the PS existed in various forms for years. Sony even released 200 Playstation consoles to developers way back in late 1991, but that hardware was completely different and not compatible with the 1994 Playstation. I've always wondered how well developers in 1993 could grasp the differences between the consoles. In hindsight, it's easy to see where the wrong turns were in the Jaguar and Saturn, but in 1993 looking at spec sheets and dev manuals, it might not be very obvious. In engineering, a lot of roads aren't clear until you take them. And nobody had much experience making 3D games in 1993. - KS I'm sorry - you're incorrect - The PSX H/W was being designed a lot earlier that people think.. Phil Harrison showed it to European devs in Dec 1993 with the dinosaur demo ( http://www.edge-online.com/magazine/the-making-of-playstation?page=0%2C2 ) Even though the devkits wouldn't be in developers hands - they had a good idea of the specs.

And because there's absolutely no sane reason to do that on the ST. Although ST is inferior even on joystick reads by themselves, you shouldn't think people are insane to use joystick ports for uses other than reading a joystick/mouse. Just consider the parallel port on PC 8088 machines. All those projects done on it were expected to perform equal or better on the next PC not degrade performance. And they were originally meant for LPT (line printers). But parallel ports went from SPP->BPP->EPP->ECP and each time they improved in speed. So someone takes his A8 machine with all it's add-ons like ComputerEyes, Video titlers, Covox, parrot, etc. and can't use them on a NEW so-called superior machine because they decided to degrade the joystick ports, reduce the shades, remove hardware scrolling, remove overscan hardware, and do away with sprites. I had the 4 player adaptor for Gauntlet (I or II can't remember ) that used the parallel port to give two more db9 sockets- I guess that would allow you to plug in your Atari 800 joystick peripherals.... You'd need new software though. That would have been good if they standardized the parallel port on ST for gaming interface. But then games like Zany Golf, Marble Madness, etc. that employ mice probably won't work with parallel ports. The normal joystick ports are fine for games - I only mentioned it as you seemed hung up on not being able to use esoteric A8 hardware on the ST. Most actual ST hardware of that kind plugged into the cartridge port though.

And because there's absolutely no sane reason to do that on the ST. Although ST is inferior even on joystick reads by themselves, you shouldn't think people are insane to use joystick ports for uses other than reading a joystick/mouse. Just consider the parallel port on PC 8088 machines. All those projects done on it were expected to perform equal or better on the next PC not degrade performance. And they were originally meant for LPT (line printers). But parallel ports went from SPP->BPP->EPP->ECP and each time they improved in speed. So someone takes his A8 machine with all it's add-ons like ComputerEyes, Video titlers, Covox, parrot, etc. and can't use them on a NEW so-called superior machine because they decided to degrade the joystick ports, reduce the shades, remove hardware scrolling, remove overscan hardware, and do away with sprites. I had the 4 player adaptor for Gauntlet (I or II can't remember ) that used the parallel port to give two more db9 sockets- I guess that would allow you to plug in your Atari 800 joystick peripherals.... You'd need new software though.

I was interested in how well it worked for you - it seems like a cool idea, but there would be problems with character mode lines? Did you test it just with graphics?

Unless you use sprites for the static portion and let the lines scroll beneath it with DL scrolling. And if the game involves a kernel, you could set HSCRL in the middle of the scanline. That seems very difficult - you end up using all of the players to replicate a static panel, or you waste large amounts of cpu resources on changes the scroll value.. ( I expect you've tested this mechanism - how much time does it take away? ) I said, "if the game involves a kernel", meaning you are already using a kernel so just have to fit in a LDA/STA for the HSCRL. And I wasn't speaking specifically for your Gauntlet II (which I am not familiar with), but in general for scrolling splits horizontally. No, you don't necessarily use up all your players. But you can't use the LMS in some cases but you can do 16 color clocks of scroll at least (still better than C64 and ST). Ok, I assumed you were replying to my point about Gauntlet II. The point about setting HSCRL every line sounded interesting, which is why I asked how expensive it was. ( Also, if you change HSCRL mid line what gets displayed? )

Unless you use sprites for the static portion and let the lines scroll beneath it with DL scrolling. And if the game involves a kernel, you could set HSCRL in the middle of the scanline. That seems very difficult - you end up using all of the players to replicate a static panel, or you waste large amounts of cpu resources on changes the scroll value.. ( I expect you've tested this mechanism - how much time does it take away? )

Yes, Gauntlet II shows 4 way scrolling that would be difficult to replicate on the A8 , as the static panel is on the right

Most probably that program was Signum! - it was a breakthrough ST application and gained massive popularity esp. among scientists and students due to its advanced formula printing and layout capabilities (much like modern word processors). The approach to "dump GEM" and the choice of pixel based fonts was shortsighted, though, as more and more ST compatible computers were either equipped with graphics cards or "small" graphics expansions like the "Autoswitch-Overscan" or "Pixel Wonder" - not to mention the TT030. This led to the downfall of Signum! in the early 1990s and to the rise of Papyrus (which still exists today in OSX and Windows versions) - a true "modern" word processor which easily works with vector fonts (provided a vector font capable GDOS like that contained in NVDI >=3.0 is installed) and was fully GEM compliant. Thorsten That's it - it was really good for equations.. and it looked nice on my MX80 , I switched to a DTP package later on though, as I could print the Postscript files on Apple laser printers. ( I remember how cheap the Atari Laser printer seemed when it came out - and how I can now buy a full colour laser for way less than my original MX80 dot matrix )

I guess the "STe" is a typo, since one of the most useful improvements of the STe was hardware scrolling registers. As I am not a programmer, I can only say that horizontally scrolling games on the plain ST always come with compromises, it's either 2-pixel scrolling (or worse) like in "Venus the Flytrap", or reduced playfield size like in "Toki", "Warp", "Seven Gates of Jambala" or "Return to Genesis". But - contrary to the belief of atariksi, ST games do not necessarily scroll jerkily - indeed the game he chooses to substantiate his rather ridiculous claim of A8 superiority ("Boulder Dash") is an obvious example of bad ST programming. I could as well point to "Racing Destruction Set" to "prove" the jerky scrolling on the A8 or to "Up'n'Down" to "prove" the terrible sprite flickering on that hardware. Thorsten Sorry, STe was a typo I remember being disappointed with Boulderdash on the ST, and working on a 60Hz( Well 50Hz as my TV was PAL ) scroller to reproduce the 8 bit original. I've probably still got it on one of my old ST source disks somewhere.

Why do you keep going on about flickery? - Nearly all ST games used double buffering , so there wouldn't be flickering at all. ( I'll have to go look at Joust again - but if it's single buffered then it's definitely in the minority ) (SW was my first complete ST game, it was pretty rubbish though ) Well, I don't buy the theory that 30Hz updates and 60Hz updates should be equated. Whether they flicker or not, they are in the same catagory of slower updates. Then we can also say that 32-shade pictures using interlaced can be compared to 8-shade at 60Hz??? It's not just Joust. Joust that I played on ST had shearing not flicker. By the way, when we analyzed the scroll timing, we only looked at read/write cycle times (which would only be good for something like a blitter but on a 68K, you also have to take into account the instruction fetch times and bit-manipulations since not everything is WORD aligned so even PAL would have problems updating within a frame time.) You're absolutely correct 30Hz and 60Hz can't be equated ... ( although modern games seem to have made 30Hz the new 'gold' standard ) I found with scrolling games on the ST that 30Hz was a consequence of matching the Amiga level visuals. ( ie: 1 frame of sprite painting + 1 frame of background scroll compared with just 1 frame of sprite painting on the Amiga ) Games like Goldrunner showed that 60Hz updates were possible with visuals way better than A8 games though. My analysis of the background paint included instruction fetches , although no bit manipulations ( for another horizontal scrolling game I used 8 copies of the background, each shifted by 2 pixels, and only added chars as they scrolled in. It ran at 30Hz on ST, 60Hz on STe and Amiga ) There were many A8 games that didn't run at 60Hz - Bandits was a great game, but it chugged at points, and RoF wasn't a poster child for 60Hz either.

Ah - looked at Joust, That does flicker pretty badly on the ST - I wonder why it's not double buffered at all?

Why do you keep going on about flickery? - Nearly all ST games used double buffering , so there wouldn't be flickering at all. ( I'll have to go look at Joust again - but if it's single buffered then it's definitely in the minority ) (SW was my first complete ST game, it was pretty rubbish though )

The quality of the original Atari RGB monitor was pretty amazing - I really wanted one, and had to settle for wiring my ST into an Amstrad CPC monitor ( resistor legs poked into the ST directly due to the difficulty in obtaining the stupid plug for the monitor connector ) I remember using a really cool word processor on the ST that dumped GEM, and just gave WYSIWYG on a full 640x400 screen - can't remember the name though, but it was really smooth and fast.

One thing to take into consideration - In 1993 the Playstation hardware was being shown to developers/publishers , so even though the public didn't know the specs of the machine, the industry did.

Nope! Its palette is 256 colours and it has 16 shades of grey. EDIT: You can find the NTSC palette (taken from the ProSystem emulator) here :- http://www.atariage.com/forums/topic/143720-7800-ntsc-colour-bitmap/ Of course you're correct ... show's how long it's been since I last looked at the 7800 docs.. My apologies ( You should now start a 7800 vs ST thread )

When you multiplex h/w sprites there's an added cost on the 8 bit for the interrupt routines, and the code to change the player positions. That helps to offset the extra cost of the ST software sprites. Plus there's a software cost for the sprite multiplexor needed when more than 2 4 colour sprites are expected on a single line which isn't a problem with straightforward software sprites. The problem with the ST isn't sprites - it's the background scrolling ( and maybe the lack of character modes ) But your choosing an example of 16*16 sprites which A8 doesn't employ in most of sprite-based games. Interrupt overhead to reposition isn't that much. May need some recalculations here. Char-mode software sprites was another issue. Maybe the best comparision is to look at Goldrunner, which was a cool near launch title from Steve Bak .... 50fps vertical scroller with sprites. That compares pretty well with any A8 game. ( Another example: I cant actually remember making any money from the ST version of screaming wings ... It wasn't that good a game, but it did look way better than the A8 version )

ah, but the 7800 only supports 128 colours, so fails on the 16 shade test

When you multiplex h/w sprites there's an added cost on the 8 bit for the interrupt routines, and the code to change the player positions. That helps to offset the extra cost of the ST software sprites. Plus there's a software cost for the sprite multiplexor needed when more than 2 4 colour sprites are expected on a single line which isn't a problem with straightforward software sprites. The problem with the ST isn't sprites - it's the background scrolling ( and maybe the lack of character modes )

Easy to way to look at is 320*200 takes 4000 words per plane to draw and 4 planes so 16000 words * 60 is 960,000 memory moves and since each read/write takes 4 cycles, you would eat up all your frame time just copying the video buffer in a scrolling situation. That's why the 18ms figure in the original calculation - it's > 16.67ms(NTSC) but less than 20ms(PAL). Scrolling really does suck on the STe. For vertical scrolling I did play around with the border removal tricks in the first 8 lines to get 50Hz scrolling with sprites. I never looked at horizontal scrolling - but I guess that some of the demos did. The ST really should have had h/w scrolling