Atari 8bit is superior to the ST

[atariksi]

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

 

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? )

 

It should apply to gauntlet as well. Now that I think about it-- it's better to have big screen scrolling; perhaps ST got lucky that it had to scroll subset of screen so it had less area to update. Are you asking if there's delay in setting HSCRL and when it takes effect?

[Rybags]

You can't change HSCROL midline - you get corruption or missed DMA in many cases.

Although a situation where it goes from a value of 1-3 back to zero might work.

 

It'd be easier to just dynamically change character definitions for status area items.

 

Re ST mouse - I was of the impression an Interrupt was generated for every input change on the joystick port... or can it actually operate in a Delta mode like the Amiga where it reports what X/Y changes have occurred since the last read.

Edited December 16, 2009 by Rybags

[atariksi]

That's a subjective statement. If I had every species of machine ever built (prior to Amiga) and only could keep one, I would keep Atari 800. All of my serious stuff was done on A800 and is impossible to port over to the other machines even theoretically.

 

Let me guess ... it's because the 800 supports even MORE high speed joysticks!?

 

Actually, I was doing more timing stuff than high speed stuff prior to Amiga. And none of the machines at the time could time things as accurately as A8 w/its WSYNC, POKEY timers @1.79Mhz, DLIs, etc.

[atariksi]

You can't change HSCROL midline - you get corruption or missed DMA in many cases.

Although a situation where it goes from a value of 1-3 back to zero might work.

 

It'd be easier to just dynamically change character definitions for status area items.

 

Re ST mouse - I was of the impression an Interrupt was generated for every input change on the joystick port... or can it actually operate in a Delta mode like the Amiga where it reports what X/Y changes have occurred since the last read.

 

It maybe due to what chars are bufferred when you set HSCRL past 3 (even/odd).

 

Well, Amiga has a hardware register to read the mouse counters which are updated in real-time (no serial protocol involved). Just do a Move.w $DFF00A,D0.

[Crazyace]

 

It should apply to gauntlet as well. Now that I think about it-- it's better to have big screen scrolling; perhaps ST got lucky that it had to scroll subset of screen so it had less area to update. Are you asking if there's delay in setting HSCRL and when it takes effect?

 

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?

Edited December 16, 2009 by Crazyace

[roland p]

Well, Amiga has a hardware register to read the mouse counters which are updated in real-time (no serial protocol involved). Just do a Move.w $DFF00A,D0.

That was great, when will they implement that feature in todays pc's? Along with v-synced mouse pointer updates. So I finally get a smooth moving mouse cursor like I had twenty years ago on my amiga...

[TMR]

Collisions don't usually slow games down, the majority of action games use bounding boxes and those can be handled at a reasonable speed on the C64 so i doubt the ST is going to worry too much.

I wasn't talking about software collisions slowing things down-- but not being able to finish within a frame's time makes the collision detection produce a delayed effect. I have seen a lot of that on Colecovision games like Popeye giving terrible playability.

 

Since they're based on the current state of objects in play, software collisions don't suffer as badly from not being run every vertical blank since the object positions only move as fast as the collisions are handled; nobody has ever complained about the collisions in Rescue on Fractalus on the A8 for example and that's not managing to refresh even every other VBL when it's busy. Hardware collisions are more troublesome than software in that context really, reading the register every other frame or lower can lead to false positives, reading it every frame and ignoring every other one leaves small "holes" that are just as bad.

 

Of course, collision detection does have some impact too whether it's hardware or software but I'm only talking about things that have major hits. Scrolling gives a major hit to ST and will cause skipping frames (if double bufferred) otherwise it will cause other bad effects like tearing.

 

Enchanted Land on the ST scrolls nearly a full screen on every VBL, Goldrunner and if memory serves Return to Genesis both move about half the screen on every VBL, there are other examples (two from memory that might be wrong because i tend to play the Amiga versions are Wings of Death and Wizball) and many demos doing it too with some of the latter not relying on buffering.

 

Read what i said; almost none need to read the mouse and quite a few don't even touch the keyboard. Some do more reading yes, but they're in the minority and the bulk of games simply poll a joystick or two once per VBL at most. But even in those situations where games are doing more, the way the ST handles things is still more than efficient enough to get the job done and it's nowhere near the throughput you're talking about.

 

How can it be almost none when the entire system is built on a GUI which centers around the mouse. I would think they have plenty of mouse-based games

 

The job i had when the ST was current was computer sales bunny (i wanted that on the business cards, but they didn't go for it) and the small company i worked for had a thing about hiring gamers to sell games; as a result i played a metric f**kload of games on just about every platform we were selling over those seven or so years. During that time i noticed that mouse-based games on the ST were pretty rare, titles that actually used the GUI even more so and the majority of games were joystick controlled.

 

but non-games should also be considered. High rates was related to doing other things with joystick ports such as doing a joystick recorder which would produce inferior results on ST.

 

The primary job of the joystick ports are to connect joysticks or in this case mice and as long as they manage that optimially any other task they can achive is merely a bonus; the users utilising those optional extras are well into the minority however and although i don't know the ST well from anything apart from a gaming standpoint i'd be surprised if there weren't far better options for data transfer available for them.

[kool kitty89]

I'm not actually that sure how many other games do use RAM expansion on the 7800.. I can't imagine it's that many, since you repeatedly hear about how Atari was being very penny pinching at the time when it came to the 7800, so I guess you had to be something very very special to get it.. Heck.. Even 16KB of RAM seems crazy for Summer Games and Winter Game..

SRAM prices really must have fallen sharply to make that possible at all (and if they coresponded to contemportary DRAM prices, then they certainly would have dropped sharply from the '84-87 period), still kind of crazy though, particularly with the later Panther planned to only have 32 kB of SRAM. (then again, that's on a 32-bit bus and at least 16 MHz)

 

I'm not sure why half of these need that much RAM in the first place.. Especially Summer/Winter Games with 16K of RAM.. That seems positively bonkers, but then I'm sure there's some logical reason for it..

Maybe they were using the RAM as a framebuffer for a bitmapped display. (that's what Gorf keeps mentioning he'd like to do with some extra RAM)

 

Of course, all those data transfers aren't free.. When MARIA is rendering its Line RAM, the CPU is locked out, so if you create a display that uses every cycle that MARIA can use then the CPU will not get much done

 

It's an awesome system and very very flexible.. Just let down in the 7800 implementation by the rather tiny 4K of RAM..

Still, I do believe that we haven't even begun to see what the 7800 is capable of

I'm sure it would have been more than 4 kB if it hadn't been planned for a 1984 release (by late 1986 it probably could have been 16kB, and even earlier 8 KB could have the advantage of using a single chip rather than 2, using less board space), DRAM would have been cheaper regardless (as the 5200/8-bits used), but I think that came up in another discussion with the speed/latency issues bing too great to be advantageous. (even if MARIA and the CPU were connected to independent busses -which might mitigate any cost advantages anyway) -That's all unrelated to issues of including POKEY though. (except with the single 8 kB SRAM chip, which could have possibly opened up board space for a POKEY)

 

 

I know I've missed out some things, but that's the jist of it If you want to know more the best bet is really to go and read the Maria Docs on it, and then write some code, because that's the only way I could clarify in my head the way the thing worked

I understand some of it on a basic level, but a lot is still over my head, I'm just starting out in computer science on an acedemic level. Fascinating stuff though. (and the one thing I did already understand pretty well was MARIA rendering one scanline at a time -which has some parallels to the operation of TIA or CTIA/GTIA -with the excepion of the latter 2 having ANTIC to drive them)

 

 

Sorry for draging the off-topic tangent. Then again, it might have been more productive than the current direction this thread had taken.

[+poobah]

As I said, "you cannot make up for the time lost in doing things in software" vs. A8 doing it in hardware. So even if you do it double bufferred vs. A8 doing it in a VBI or with double bufferring, you still took a longer time and thus it's inferior on ST. You have less time left in the frame for other things.

You base assertion is wrong.

People working in the real world deal with "software/hardware equivalence" all the time.

If I can recreate any screen with software that your hardware can generate, they are, at best, equal.

I *can* make up for hardware with software.

 

Just for grins and giggles, lets say my software takes longer to render the frame than the A8 hardware. The 68k is going to accomplish the rest of game related tasks significantly faster (AI, math, etc.) to compensate. I need less time in the frame for other things.

 

Tell IKBD to report sticks as keypresses. mouse in relative mode.

Each frame, peek at IKBD's status register. if no change, you are done.

If there's a packet, grab it and decode, done.

The port could be 10 times slower and still be plenty fast enough to do what it is designed for.

 

Even at 781 bytes/second, you still spend more time (cycles) reading joystick and figuring out what it does than A8 doing LDA 54016 which doesn't have any timing constraints of when to read it.

Have you ever actually written *any* ST code to read the keyboard, mouse or joysticks?

Edited December 17, 2009 by poobah

[oky2000]

bloody hell u are off AGAIN.

 

having 1970s hardware graphics chips in it does NOT under ANY circumstances mean that the A8 is better than the ST at games in general. the sprites are MONO and u have FOUR that does not even compare favourably to a 64 let alone an ST.

 

to ignore the fact that the ST's processor is 4x faster clock speed and a WHOLE generation more advanced as a processing unit is just ludicrous.

 

i ask u to post ONCE AGAIN a selection of A8 games which the ST cannot produce or have a equivalent of.

 

Steve

 

I would like to add 3 games that the A8 can never do justice to compared to the stock STFM version.

 

1) Gauntlet 1. Sure the scrolling is a little slow sometimes but look at the size of the graphics and the frames of animation. Also we analysed the ASM for G1 on ST and it can probably be optimised by 50% by using a more efficient scrolling engine/memory map etc. You can check out how the game plays on a 12mhz ST in STeem for an idea.

 

2) Starglider I...possible but never be the same quality in colours/resolution/speed.

 

3) The Pawn....graphics not possible....parser speed not possible.

 

What is actually amazing is these are all first generation ST titles.

 

There are of course times when soft-scrolling is a big disadvantage though and that I will admit....I don't know how well Salamander (Lifeforce in USA) would turn out compared to the amazing C64 version that leans very heavily on the custom chips...Konamis classic 80s arcade shmup might be impossible to do on a stock STFM actually(...an STE however is a different matter)but then the A8 couldn't do Salamander as well as the C64 either so that's not really a win for either.

 

At best you could have smoother scrolling worse graphics with better sound on the A8...if it is a standard 2D scrolling game true, Rally Speedway is a good example with its fast 8-way scrolling.

[Rybags]

You could say similar for A8 games on the ST - practically any fullscreen smooth h-scrolling game.

 

Just look at h-scrollers on the ST - most run in a smallish window, and even then they often jump 4 pixels at a time.

 

Sure, the 68000 CPU is a generation and a half ahead of the 6502. But the sound subsystem is a jump backwards. And don't bother bringing MIDI into the equation, practically nobody I know who had an ST used it.

 

Graphically, the 1st gen ST was a disappointment. Page aligned screen origin plus kludgy bitplane arrangement does not make for a gaming machine.

 

TBH, what rescued the system was raw CPU grunt. Although it only managed to bring the system to parity or slightly above existing 8-bit machines, but lagged significantly compared with the likes of Amiga and the Genesis/Megadrive and SNES.

[oky2000]

It would take Microsoft 2 days tops to write a routine to read the Amiga's format....the problem is those routines are so low level and PCs are such a dodgy platform it's not easy to reverse engineer that part of windows. Putting in a dodgy disk on an 8 core machine even on Vista can hang it dead LOL

It's not the low level software which cannot read the Amiga format, it's the PC disk controller which only starts to read data after a PC-format sync signal is encountered. If you insert an Amiga disk the controller will not give you a single bit of MFM data. You cannot fix that in software.

Well an ex Microsoft employee working on DOS7 claimed it is possible to do this during discussions about "it's a shame that WinUAE doesn't...." etc so I think I will stick with the knowledge of someone who programmed low level parts of DOS your or anyone else will never have access to information about the workings of.

 

It's not as weird as the variable rotational speed Mac floppies...what a dumb idea (as usual) from crApple.

The outer tracks have far more space per bit than the inner tracks. Apple tried to compensate that by adjusting the bitrate. Btw, also the CBM 1541 is doing that.

 

I know why they did it, it just adds another layer of complexity to achieve LESS data per disk than a constant velocity format used by the Amiga or extended track formatters for the ST too. 1541 is not an example of a decent floppy drive....now if you had said the Commodore SFD1000 drive which stored 1mb per 5.25" disk used that technology then I might be a little more impressed

 

Simple fact is 880-720= a lot of data for 1985....a huge amount of extra files. May not make disc drives sound great but it works and I still have FDs from 20 years ago that my A1000 will still read quite happily so there is no issue with the Amiga floppy format...simplest way of upping disk capacity by 22%

[RevEng]

And don't bother bringing MIDI into the equation, practically nobody I know who had an ST used it.

Your friends didn't use MIDI, so it's not worth counting?

 

Seems like a sound argument to me!

Edited December 17, 2009 by RevEng

[Rybags]

He's right about the PC controller not being able to read Amiga floppies, but there's a kludge that was developed by someone to do it.

 

Use 2 drives, the second drive holds a PC disk which generates the sync. Then the software flips a bit in the controller so the first disk is read. I tried it, a bit slow but it successfully copied a Workbench disk and I was able to boot the image in WinUAE.

 

But, in this age nobody wants floppies anymore. I don't think I've used mine more than twice in the last 2 years.

[Rybags]

And don't bother bringing MIDI into the equation, practically nobody I know who had an ST used it.

Your friends didn't use MIDI, so it's not worth counting?

 

Seems like a sound argument to me!

 

Well if it isn't, then the lack of games that used it would be justification.

[oky2000]

And really, for what it was, the ST didnt do too terribly bad.. It managed to spawn a platform that kept atari in the home computer business for many more years, and actually it out-survived commodore by at least a year or two..

 

Lots of good stuff snipped here, but ST outlasted the Amiga? No way matey! Or do you mean as a functional company per se? Atari vs. Commodore up until the mid 90's? Ignoring the multitude of practical 3rd party products that continue to this day for the Amiga, remember companies like Amiga Technologies, Escom et al, produced Amiga systems for many years after Commodores demise. Still, the history of it all is mind boggling. Amiga really is a 'current' platform and OS for all practical intents and is supported by many companies. There's even a couple of current FPGA projects, one is an A500 clone and with the AGA patents expiring in a year or two, I bet we'll have new A1200's, etc. While the ST may not be dead-dead, pretty darn close. I don't see new cases, sound cards, video cards, usb cards or any TOS OS being developed or replicated anywhere in the world except for maybe high atop a secluded German mountain. lol But I'm sure as soon as I say that, someone will point to some link(s).... lol (I am aware of a new or semi-new IDE or SCSI interface for the ST)

 

Well let's take a look....

 

Commodore built the 128.....bought Amiga....launched essentially just 2 different chipsets between A1000 and A1200/CD32 (first and last models) from 1985 to 1994

 

Atari built the ST then the STE upgrades, bought Epyx's Lynx, Built the TT, Built the Falcon, Built the Jaguar.

 

I suppose I class the Falcon as an ST line machine but shouldn't really, although it is ST compatible so I think of it the same way as A500<-->A1200. I am pretty sure Atari (in Germany at least) were still selling the Falcon in 94 when Commodore went bankrupt.

 

However I totally agree with you that as an ideal and a community of users the Amiga has a greater following (AROS, minimig etc) but that has nothing to do with the original companies, Commodore screwed themselves at almost every stage after the A500/2000 machines either on price or lack of sufficiently advanced improvements (8bit sound in AGA? Losing 50% cpu speed for the sake of a 1mb hard soldered memory module on the CD32 motherboard? what were they thinking!!)

 

Jack Tramiel ran Atari (and Commodore) better with less money at his disposal than that little prik Medhi Ali at Commodore (who with any luck is, for his sins, in an eternal hell)

 

Engineering talent was probably about equal on both sides though....remember the engineers can only make what they are allowed to make when given sufficient freedom....Which from A1000 to A600 chronologically the engineers hands were tied even though they were screaming at the little fukka (Medhi Ali) to improve the bloody chipset, many gave up and left in this period which is why AGA is too little too late...bit like when Stalin killed all the engineers and then complained about the lack of technological improvement in his airforce a decade later

 

PS copyright on Amiga stuff will never expire in our lifetime so Minimig and other FPGA clones are ALL illegal unless Amiga Inc allows you to make such things with kickstart onboard.

[Rybags]

Well, there's lifespan and there's useful lifespan.

 

You could still buy new 2600s here when the Megadrive and SNES were about.

Some countries still made the original VW Beetle into the 1990s.

[RevEng]

And don't bother bringing MIDI into the equation, practically nobody I know who had an ST used it.

Your friends didn't use MIDI, so it's not worth counting?

 

Seems like a sound argument to me!

 

Well if it isn't, then the lack of games that used it would be justification.

All the Sierra Adventures used it. There were quite a few, and they were quite popular back in the day.

Edited December 17, 2009 by RevEng

[Rybags]

So what's that - a dozen or so ?

 

I bet if you made a list of MIDI-enhanced games of the 3,000 or whatever were released on the ST, you'd be lucky to hit 50.

[RevEng]

So what's that - a dozen or so ?

 

I bet if you made a list of MIDI-enhanced games of the 3,000 or whatever were released on the ST, you'd be lucky to hit 50.

Sure. It all depends on how you look at it. I acknowledge that the absolute number of games that used midi was small.

 

But, I'm guessing that the Sierra Adventures were played by a heck of a lot more people than most of those remaining 2978 games.

 

I'd be surprised if almost every ST owner that had games didn't have at least one of them.

[+wood_jl]

So what's that - a dozen or so ?

 

I bet if you made a list of MIDI-enhanced games of the 3,000 or whatever were released on the ST, you'd be lucky to hit 50.

Sure. It all depends on how you look at it. I acknowledge that the absolute number of games that used midi was small.

 

But, I'm guessing that the Sierra Adventures were played by a heck of a lot more people than most of those remaining 2978 games.

 

I'd be surprised if almost every ST owner that had games didn't have at least one of them.

 

But the number of people who had: (1) An ST, (2) A Sierra Adventure, and (3) a Casio CZ-101 (or whatever) was a small number. I believe that's the point he's trying to make.

 

[On the other hand, I think "Karate Kid Part 2" supported the MIDI because I remember it playing in the store.]

[RevEng]

The intersection of all 3 may be a small number, but not as insignificant as many may think.

 

A *lot* of musicians had an ST back in the day. Probably as many musicians as game-only owners. It was featured many times in all of the midi and studio magazines. Every studio with any midi gear had one.

 

A lot of us also liked to game with our machines as well. The games with midi sound output were a gear-geeks wet dream.

 

[Edit - apparently even non-musician types enjoyed the MT-32 output.

 

Also, you could get output from other non-Roland modules, you'd just need to edit your banks to get the similar instrument assignments.]

Edited December 17, 2009 by RevEng

[oky2000]

Enchanted Land on the ST scrolls nearly a full screen on every VBL, Goldrunner and if memory serves Return to Genesis both move about half the screen on every VBL, there are other examples (two from memory that might be wrong because i tend to play the Amiga versions are Wings of Death and Wizball) and many demos doing it too with some of the latter not relying on buffering.

 

Enchanted Land is interesting, if you watch it very closely it isn't really scrolling everything for every pixel you move the wizard up/down/left/right like in a true 8 way scrolling game, this gives a push-scroll effect which allows some time for buffering or catch up I guess. On the youtube video the character drops below the bottom border before the screen scrolling downwards catches up with him....this clearly is a design decision not a gameplay decision for sure.

 

That's not to say it isn't very impressive all the same, but definitely not a true 50hz full screen 8 way scrolling engine suitable for something like an 8 way shootemup like Time Pilot...the latency (eg moving left then right again) allows for the scrolling to keep up and cancel out some pixel scrolling in the meantime. And to put it into perspective that is probably written by one of the most talented coders within one of the most talented demo groups for the stock ST too, but shows what is possible with talent

[oky2000]

Well, there's lifespan and there's useful lifespan.

 

You could still buy new 2600s here when the Megadrive and SNES were about.

Some countries still made the original VW Beetle into the 1990s.

 

But in the dying days of both the Amiga and the ST gamesplaying were certainly not their home base, a SNES or Megadrive were significantly cheaper than a Falcon or A1200 and the games were consistently better. ST/Falcon was pretty much music studio standard equipment, Amiga was a animators/videographers dream machine and the Mac had the DTP market sewn up.

 

The Falcon was absolutely a perfect improvement for music production with it's 16bit audio processing capabilities thanks to the DSP. On the other hand all that happened between the Atari 800 model and the Atari 130XE was a 300% increase in memory...zero graphics chip improvements or sound hardware changes, no change in CPU speed either...so if any machine died from lack of development (to fight off the SID and VIC-II advantages) it was the A8.

 

For a long time after the ST/Falcon was launched musicians still flocked to use Cubase and Steinberg software on Atari hardware....who really hankered after an A8 apart from retro enthusiasts during the ST/Amiga/Snes/Genesis years? Exactly.

[oky2000]

So what's that - a dozen or so ?

 

I bet if you made a list of MIDI-enhanced games of the 3,000 or whatever were released on the ST, you'd be lucky to hit 50.

Sure. It all depends on how you look at it. I acknowledge that the absolute number of games that used midi was small.

 

But, I'm guessing that the Sierra Adventures were played by a heck of a lot more people than most of those remaining 2978 games.

 

I'd be surprised if almost every ST owner that had games didn't have at least one of them.

 

But the number of people who had: (1) An ST, (2) A Sierra Adventure, and (3) a Casio CZ-101 (or whatever) was a small number. I believe that's the point he's trying to make.

 

[On the other hand, I think "Karate Kid Part 2" supported the MIDI because I remember it playing in the store.]

 

Well maybe they should have spent their time on more fruitful activities like perhaps using the extra capabilities of the STE hardware instead of palming off crappy Midi files from their PC projects for 0.00001% of the userbase