Atari v Commodore

[atariksi]

Well, there's a difference here. VGA was backward compatible with CGA/EGA/MGA/MCGA

I don't see where VGA being compatible to most of the older standards. It's just like on Amiga: If you installed a gfx card, you could still use OCS.

 

There's a VGA scan line counter in old VGA cards so it must be getting updated even on TFT displays. I see you are stating that flicker would still occur although the scanline counter is working since the TFT would actually re-intrepret the data and reorganize it in tiles.

There is a scanline counter in some gfx card drivers, but what does it help you? You may ask and try to compare scanline values, but at the very same moment the scheduler might have placed another process there and all your comparisions of scanlines are bust because both scanline values of the compare are several frames from each other. Also a busy wait loop is the worst thing you can do for VSync, and btw... even most gfx card drivers do it when you call WaitForVerticalBlank.

 

Same thing with Amiga-- Opalvision hardware is not compatible with Picasso hardware and so just like ATI cards are not compatible with STB cards. As I mentioned ATI cards don't even use the same ports within the same family of cards.

 

I see in a multitasking environment scanline compares may not be good but as long as you can limit the worst case time, you should be okay. Or in worst case, write device driver at Ring 0 and use CLI to stop other tasks.

[Fröhn]

I see in a multitasking environment scanline compares may not be good but as long as you can limit the worst case time, you should be okay. Or in worst case, write device driver at Ring 0 and use CLI to stop other tasks.

Been there, tried that... and results sucked.

[atariksi]

I see in a multitasking environment scanline compares may not be good but as long as you can limit the worst case time, you should be okay. Or in worst case, write device driver at Ring 0 and use CLI to stop other tasks.

Been there, tried that... and results sucked.

 

It's better to quantize the "sucks" scenario. If OS switches to other tasks while you repaint the screen for longer than frame time - time to repaint, it does suck. If no OS is involved (using Ring0 mode) and suppose you are repainting 640*400 window where Windows is running in 32-bit color mode, you need to update 1MB of video memory so no tearing occurs. If you try to finish within vertical retrace, you would need a video card capable of > 750MB/second so that won't work but if you stay behind the drawing of the frame and start off at VBI, it can be done.

[atariksi]

>>That's true that Amiga games usually go directly to hardware registers (since they are standard) and thus give you a more efficient product.

>PC games did the same. Just with less efficient hardware.

 

PCs don't have the capability of synching to color clocks like Amiga and Atari but old VGA standard did have polling for horizontal and vertical retrace capability. But now the frequencies of VGA modes are so variegated so you can't optimize on the video frequencies like you can with Amigas and Ataris. And you can't synchronize the PC for Amiga and Atari frequencies as well.

[oky2000]

The trouble DOS coders faced was that there was a million possible combinations of hardware specification inside each "PC" most notably the graphics chips could have nothing in common beyond the most basic functionality. Some VGA/EGA cards weren't even 100% VESA compatible.

 

What was nice about the Amiga and the ST was that you could just write something to particular addresses and you knew everyone's machine would more or less just do what it was doing on your machine in front of you.

 

Serious coders absolutely trashed the Amiga OS to gain absolute maximum performance and free up all 512k or 1mb of memory. Man I miss those days, this kind of continuity of hardware now only exists for console coders.

 

As for the tearing on the movies I mentioned...it is when something really crap (like Adobe Flash) is sucking up cycles and ruins all the timing in XP/Vista. Killing the tasks responsible will get back perfect video playback but until you kill those tasks even outputting to an external 60fps projector causes the tearing even with a CORE2DUO.

 

The problem has always been that the PC is never a standard machine, no two graphics cards are identical in the DOS days and could not really be programmed in machine code the same way as the ST shifter/DMA or Amiga Copper/Blitter. The only checks you needed to do on the ST/Amiga was total RAM size and modify your code at worst for each size other than that your code would work on any model within reason (forget Amiga AGA <===>ECS/OCS as not many people had to do that).

 

The PSP manages to emulate an Amiga 500 with 366mhz because of the same reason (fixed hardware platform so you can optimise your code until there is zero wasted cycles) but the PC needs about twice that power and STILL will give you screen tears on a 30FPS game displayed on a 60hz screen mode because PCs are just crap, and this is a legacy of the open standard. Good thing every 6 months a faster CPU is released by Intel then

[atariksi]

Processor speed increases in the past few years did not make that much of an impact as bus speed changes since the I/O bottleneck still remains so Amiga/Atari emulation failing is due to I/O speed bottlenecks and timing issues than the dual core or quad cores. IN AL,DX takes 66 cycles for some I/O device on Pentium 100Mhz and it takes a thousand cycles on 1Ghz+ processors so no gain.

[frenchman]

Fröhn's a funny guy, defending, only for in the next post his stack of cards come tumbling down again, I admire his spirit.

[Fröhn]

Fröhn's a funny guy, defending, only for in the next post his stack of cards come tumbling down again, I admire his spirit.

Huh? I said that you can easily do OS-based 100% smooth animation ond Amiga and you can't do that on Win/Linux.

[atariksi]

The trouble DOS coders faced was that there was a million possible combinations of hardware specification inside each "PC" most notably the graphics chips could have nothing in common beyond the most basic functionality. Some VGA/EGA cards weren't even 100% VESA compatible.

 

What was nice about the Amiga and the ST was that you could just write something to particular addresses and you knew everyone's machine would more or less just do what it was doing on your machine in front of you.

 

...

 

Sound cards are more of a nonstandard than video cards. That's why you see many DOS games either expecting sound blaster compatibility or giving you a list of sound cards to choose from. But even Sound Blaster directly accessed lacks the multifrequency DACs running simultaneously like you can do on Amiga and Atari. They even have monitor drivers nowadays! Although, TFT standard display driver seems to work find for my analog monitor.

 

Video cards up to now maintain the VGA standard modes although speeds vary. I mean Windows installs itself assuming VGA compatible display and later on you install the card-specific driver. If the super-VGAs were standard, you wouldn't need a Windows graphics driver. If sound cards were using standard ports, you wouldn't need a sound driver. If printers were standard, you wouldn't need a printer driver. If mice were standard, you won't need so many mouse drivers. Take this to the limit and you find that if hardware standards were there, you won't need plug-and-play, OS would fit within a 512KB ROM chip, and DOS would be more efficient to use than Windows!

[malducci]

Sound cards are more of a nonstandard than video cards. That's why you see many DOS games either expecting sound blaster compatibility or giving you a list of sound cards to choose from. But even Sound Blaster directly accessed lacks the multifrequency DACs running simultaneously like you can do on Amiga and Atari.

 

Well, they had more than just a stereo DAC. There was opl2 (sound blaster) and opl3 (sound blaster 16) FM chips on the sound cards. Some recent music examples of just OPL2 here.

[atariksi]

Sound cards are more of a nonstandard than video cards. That's why you see many DOS games either expecting sound blaster compatibility or giving you a list of sound cards to choose from. But even Sound Blaster directly accessed lacks the multifrequency DACs running simultaneously like you can do on Amiga and Atari.

 

Well, they had more than just a stereo DAC. There was opl2 (sound blaster) and opl3 (sound blaster 16) FM chips on the sound cards. Some recent music examples of just OPL2 here.

 

For digital audio playback, Amiga has 4 tracks and 4 8-bit DACs with their own frequency and volume settings. Atari has 4 4-bit DACs each can be played at their own frequency using IRQ or cycle exact coding. Sound Blasters have 1 DAC with stereo you have 2 DACs but they have to run at the same sampling rate. Adlib stuff is just for music notes not for generic digital audio playback.

[Fröhn]

Atari has 4 4-bit DACs each can be played at their own frequency using IRQ or cycle exact coding.

That will not work. Feeding those 4 DACs alone is already quite a job for a 6502, but it won't be able to do it at different frequencies per channel.

[oky2000]

Atari has 4 4-bit DACs each can be played at their own frequency using IRQ or cycle exact coding.

That will not work. Feeding those 4 DACs alone is already quite a job for a 6502, but it won't be able to do it at different frequencies per channel.

 

I think we are getting beyond ourselves here. Amiga means 3 chips only as far as programmers in the 80/90s were concerned

 

Agnus (Blitter etc)

Daphne (Copper? + other stuff)

Paul (4x 8bit DACs plus I/O)

 

But you get the idea. When a game was written for the A1000 it worked on the A500, A1500,A2000 because a 16bit Amiga all had the same basic capabilities (early A1000s without 64 colour lores and lores 'lace modes being the exception) and it worked in the same way ie writing ?? to register ?? produced the same results. Memory was the only issue needing code to be modified for register addresses sometimes that's it. In the 80s a PC could have 1 of 100 graphics cards all different technology and capabilities and 10 different sound cards. It was a complete mess and that's why PC games up until the early/mid 90s were a complete pile of shit compared to Amiga games.

 

Sound was usually midi/wavetable tunes which sounded like example tunes on cheap $100 synthesizers.

VGA was hardly supported because the number of PCs with 256 colour VGA was so small it wasn't worth doing graphics for them (like the old days when Amiga games had ST graphics because it wasn't worth paying an artist to do extra graphics for a few Amiga games they might sell and it looked good enough on RF connection to TV )

 

And this was if you were lucky to get games to work! Half the time there wasn't enough stupid DOS memory (640k business) even though you had a 1mb or 4mb PC! And then the mouse drivers didn't work, the CD-ROM drive and 2 sound cards didn't work because of IRQ channel conflicts. What a mess! Thank fuck we had ST/Amiga machines to just load the game and play it just like a games console haha!

[frenchman]

Crack me up these comparisons all the time and the C64 vs Atari XL. The C64 fans saying that things can be done on the C64 they cannot be done on Atari XL. Those people are just unknowledgable.

 

As David Crane (famous Atari VCS programmer) stated: "We invented, we done things on VCS where even the Atari guys says this would not be possible. But I did it."

 

So anything is possible, given time.

[atariksi]

Atari has 4 4-bit DACs each can be played at their own frequency using IRQ or cycle exact coding.

That will not work. Feeding those 4 DACs alone is already quite a job for a 6502, but it won't be able to do it at different frequencies per channel.

 

I was referring to humans. Given 29868 cycles/frame on Atari minus the refresh cycles giving 27510 cycles divide by 6 cycles/LDA+STA for a DAC write, you get >68Khz output per DAC more than enough for humans since it's beyond their audio frequencies. Okay, so you had some mechanical ears put inside your brain in your last surgery and can distinguish higher than 68Khz:

CPT:

62145

ICDs:

V45.89

E871.0 (foreign object left in body during surgery-- ON PURPOSE)

 

So you can state that it would be hard for Atari to keep up with your sense of hearing. But I was talking about average humans.

 

Now if you can do 68Khz, it can obviously do for example 8Khz on one sample, 9Khz on another, 11Khz on a third, and 13Khz on the fourth easily. Come on, take your thinking beyond the limits of what the C64 allows for and you will see. Not every machine has one main volume DAC register that has to run at one frequency. Don't be like Dr. Frog.

[emkay]

Atari has 4 4-bit DACs each can be played at their own frequency using IRQ or cycle exact coding.

That will not work. Feeding those 4 DACs alone is already quite a job for a 6502, but it won't be able to do it at different frequencies per channel.

 

YES, WE CAN

 

You might think about the max. of possible samplereate. Just look at "Softsynth". It uses different sample speeds for the different channels. The CPU speed bonus is that there is no need to mix the resulting channels to one voice, as needed on the C64. Actually, you can play 5 voices on the A8 without software mixing.

[Fröhn]

I think we are getting beyond ourselves here. Amiga means 3 chips only as far as programmers in the 80/90s were concerned

 

Agnus (Blitter etc)

Daphne (Copper? + other stuff)

Paul (4x 8bit DACs plus I/O)

You forgot the two CIAs and the 68k etc. (And it's Agnus/Denise/Paula)

 

But you get the idea. When a game was written for the A1000 it worked on the A500, A1500,A2000 because a 16bit Amiga all had the same basic capabilities (early A1000s without 64 colour lores and lores 'lace modes being the exception) and it worked in the same way ie writing ?? to register ?? produced the same results. Memory was the only issue needing code to be modified for register addresses sometimes that's it. In the 80s a PC could have 1 of 100 graphics cards all different technology and capabilities and 10 different sound cards. It was a complete mess and that's why PC games up until the early/mid 90s were a complete pile of shit compared to Amiga games.

The PC games were crap because the gfx/sound hardware was crap. This changed in the 90s though when the CPUs/RAM bandwidth became so fast that PCs could compensate the lack of gfx features with pure processing power. However that doesn't have anything to do with my critics on todays gfx APIs which make it impossible to have 100% smooth animation.

 

Sound was usually midi/wavetable tunes which sounded like example tunes on cheap $100 synthesizers.

In the 80s it was mostly PC-speaker sound. Later on it was MIDI tunes and software mixed samples.

 

VGA was hardly supported because the number of PCs with 256 colour VGA was so small it wasn't worth doing graphics for them (like the old days when Amiga games had ST graphics because it wasn't worth paying an artist to do extra graphics for a few Amiga games they might sell and it looked good enough on RF connection to TV )

256 from a palette of 262144 colors. That was good enough for a loooong time.

[Fröhn]

That will not work. Feeding those 4 DACs alone is already quite a job for a 6502, but it won't be able to do it at different frequencies per channel.

You might think about the max. of possible samplereate. Just look at "Softsynth". It uses different sample speeds for the different channels. The CPU speed bonus is that there is no need to mix the resulting channels to one voice, as needed on the C64. Actually, you can play 5 voices on the A8 without software mixing.

Different sample speeds doesn't mean that the DAC registers are feeded at different speeds. All the MOD-players I have looked at (A8, C64) read the sample with different sample "gradients" and feed the DACs with a fixed sample rate no matter how fast the sample itself is played.

[atariksi]

>>VGA was hardly supported because the number of PCs with 256 colour VGA was so small it wasn't worth doing graphics for them (like the old days when Amiga games had ST graphics because it wasn't worth paying an artist to do extra graphics for a few Amiga games they might sell and it looked good enough on RF connection to TV )

>256 from a palette of 262144 colors. That was good enough for a loooong time.

 

Well, it's true that for some time, people still made games for CGA/EGA rather than VGA to support more machines. Once VGA became common, people starting hacking it like making Mode X (320*480*256, 360*480*256, etc.) by reprogramming the registers. I think they did similar stuff with Amiga in making a 160*200 chunky mode for stuff that required lower resolution. And more hacking on Atari with it's 100s of graphics mode (including ANTIC mode K). That's why it's important to have standardized I/O ports, you can take the hardware to its limits that way. I mean what's the use of optimizing an API call when you don't even know what resides behind it and what's behind it depends on the machine.

 

For example,

 

for (t=0; t<256; t++)

{

BitBlt(hDC, 0, t, 640, 480, hDCSrc, 0, t+1, SRCINVERT);

if (t==128) t=129;

}

 

optimized to:

 

t=0;

MyLoop:

BitBlt(hDC, 0, t, 640, 480, hDCSrc, 0, t+1, SRCINVERT);

asm { Add Byte Ptr t,1

Jns MyLoop

Inc Byte Ptr t }

MyLoop2:

BitBlt(hDC, 0, t, 640, 480, hDCSrc, 0, t+1, SRCINVERT);

asm { Inc Byte Ptr t

Jnz MyLoop2 }

[Rybags]

What is this "Antic Mode K" of which you speak?

[Fröhn]

Well, it's true that for some time, people still made games for CGA/EGA rather than VGA to support more machines.

That's customer size optimization. Most games are made for profit and not for showing off the latest tech.

 

I think they did similar stuff with Amiga in making a 160*200 chunky mode for stuff that required lower resolution.

Amiga 160x200 modes are just 320x200 with each pixel written twice to the bitplanes. There is no trick involved.

[atariksi]

What is this "Antic Mode K" of which you speak?

 

That's just for my convenience I kept tacking on to where ANTIC finishes off:

 

2 GR.0 TEXT 40 40 - 24 8 1 960

3 NONE TEXT 40 40 - 19 10 1 760

4 GR.12(XL) TEXT 40 40 20 24 8 5 960

5 GR.13(XL) TEXT 40 40 10 12 16 5 480

6 GR.1 TEXT 20 20 20 24 8 5 480

7 GR.2 TEXT 20 20 10 12 16 5 240

8 GR.3 GRAPH 10 40 20 24 8 4 240

9 GR.4 GRAPH 10 80 40 48 4 2 480

A GR.5 GRAPH 20 80 40 48 4 4 960

B GR.6 GRAPH 20 160 80 96 2 2 1920

C GR.14(XL) GRAPH 20 160 160 192 1 2 3840

D GR.7 GRAPH 40 160 80 96 2 4 3840

E GR.15(XL) GRAPH 40 160 160 192 1 4 7680

F GR.8 GRAPH 40 320 160 192 1 1 7680

G GR.9 GRAPH 40 80 160 192 1 16 7680

H GR.10 GRAPH 40 80 160 192 1 9 7680

I GR.11 GRAPH 40 80 160 192 1 16 7680

J NONE GRAPH 45+ 160 160 192 1 16+ 8960+

K NONE GRAPH 45+ 160 160 192 1 16+ 8960+

 

+ more depending on image/DLI algorithm.

[atariksi]

I think they did similar stuff with Amiga in making a 160*200 chunky mode for stuff that required lower resolution.

Amiga 160x200 modes are just 320x200 with each pixel written twice to the bitplanes. There is no trick involved.

 

Sorry, but if it was just software emulation, I wouldn't be stating it. The Amiga hardware is involved in making some weird modes possible-- it involves hardware scrolling odd planes by a pixel and having both planes 0,1 point to same memory location and planes 2,3 point to same location.

[Fröhn]

I think they did similar stuff with Amiga in making a 160*200 chunky mode for stuff that required lower resolution.

Amiga 160x200 modes are just 320x200 with each pixel written twice to the bitplanes. There is no trick involved.

 

Sorry, but if it was just software emulation, I wouldn't be stating it. The Amiga hardware is involved in making some weird modes possible-- it involves hardware scrolling odd planes by a pixel and having both planes 0,1 point to same memory location and planes 2,3 point to same location.

The "odd planes scrolling" was no trick. The Amiga simply offered two scroll registers - one for odd planes, one for even planes. And 160x200 was still done via 320x200 and double pixel writes. Ofcourse for 16 colors it would work. All 160x200 stuff I have seen was 256 colors, and as for 16 colors every sane coder would prefer the lesser bitplane load due to extremeley slow chipram.

Edited March 21, 2009 by Fröhn

[malducci]

Sound cards are more of a nonstandard than video cards. That's why you see many DOS games either expecting sound blaster compatibility or giving you a list of sound cards to choose from. But even Sound Blaster directly accessed lacks the multifrequency DACs running simultaneously like you can do on Amiga and Atari.

 

Well, they had more than just a stereo DAC. There was opl2 (sound blaster) and opl3 (sound blaster 16) FM chips on the sound cards. Some recent music examples of just OPL2 here.

 

For digital audio playback, Amiga has 4 tracks and 4 8-bit DACs with their own frequency and volume settings. Atari has 4 4-bit DACs each can be played at their own frequency using IRQ or cycle exact coding. Sound Blasters have 1 DAC with stereo you have 2 DACs but they have to run at the same sampling rate. Adlib stuff is just for music notes not for generic digital audio playback.

 

 

I think you missed my point. What's is the overall goal of those multiple DACs on the Amiga and Atari? Music.

 

You didn't need multiple DACs because you had 9 FM channels in OPL2 or 18 FM channels with OPL3, not to mention the use of software mixing for the direct DAC if needed.

 

Plus, if you wanted - you could could freeze the FM channel's carrier and use the volume for sample playback on each FM channel.

Edited March 21, 2009 by malducci