Atari v Commodore

[supercat]

I wonder what speed was possible for the 6502 in 1982. The BBC ran memory at 4MHz and the 6502 at 2MHz ( with no wait states ) - An 800XL with 3.84MHz memory and a 3.84MHz 6502 would have ruled ( especially if it have additional graphics modes )

 

What CPU was the BBC machine using? The Z80, IIRC allows almost two full T-states between outputting address and sampling data; the 6502 allows slightly less than one cycle.

 

Still, if the Atari could have run its memory system at 3.579MHz while keeping the CPU at 1.79MHz, that could have made more bus cycles available for the display hardware, allowing higher-resolution modes like 160x200x16 or 320x200x4 with no CPU slowdown, or 160x200x256 or 320x200x16 with significant CPU slowdown. Alternatively, it could have allowed a 7800-style oodles-of-sprites system.

 

BTW, I wonder if there were any systems which shared RAM between the CPU and display, and didn't have an integer number of CPU cycles for each display column. If one is trying to use RAM at its maximum speed all the time (as opposed to interleaving, which leaves cycles idle outside the vertical display interval), I would think that it might make sense to use a non-integer number of cycles so that the CPU would never have to be stalled for very long. For example, if each display column took four chroma clocks and on the badlines required two bytes, and if the memory clock rate was 9/16 the chroma rate (2.24MHz), then even on the badlines the CPU could use cycle every 16 chroma cycles (223Khz). A standard 6502 can't have its clock rate fall below 100KHz, and it takes a few cycles to suspend operation while its clock is running, but if the display controller could run the CPU in slow motion without violating the minimum speed, the extra DMA startup cycles could be eliminated.

[atariksi]

They hadn't caught *ALL* the way up with the latest 2.8Ghz Dell system I bought a couple of years ago.

 

In terms of graphic and sound horsepower they pretty much had. No doubt you can find little corner casey things that Amigas do better than today's PCs and if you want to argue that Amiga is more elegant from an engineering POV then no argument from me. But the fact remains that today's PCs can accomplish anything a classic Amiga* can even if it has to use sheer brute force to emulate the Amiga itself.

 

*The funny little closed PCs that may more may not come out sometime "soon" are modern machines that emulate the old stuff if they bothers to run it at all. Braaaaaaaaaiiinnnns!

 

If you look at it in terms of objective in the 1980s/1990s, the PCs weren't trying to catch up to the Atari/Amigas. Atari/Amigas had gaming elements in their hardware like sprites, digital joysticks, multichannel voices, timing of these elements together, etc. and PCs were more of business type. Even the lower resolutions were advantages of Atari 8-bit since it allowed for fast update of full-screen. VESA/PCI/AGP allowed them to catch up for faster screen updates, but they still did not catch up to the other gaming elements in these machines. They just have to hope the overall effect looks the same although internally it can be proven it's not the same.

[Rybags]

The BBC uses a 6502 at 2 MHz... RAM access is interleaved in similar fashion to the C-64.

 

I think running the Atari's RAM at 3.6 MHz speeds in 1979 would have probably been prohibitive for cost reasons. For starters, you need access times halved, so it would have needed 125 ns RAM rather than 250 ns parts.

[emkay]

The big win on the a8 is the use of the lower res graphics modes, with their lower bus use. That's what allows Rescue to run as well as it does.

 

Yes. It's a straight thing... with two advantages: The CPU can run a bit faster due to less DMA readings of ANTIC(40 of every 2nd line). And Antic saves the CPU from doing something like LDA $,x , STA $$$$,x ... 40 times every 2nd scanline.

That's why I'm pretty sure that Rescue can run clearly faster on the A8, if the game was optimized to the CPU...

[Crazyace]

I agree that 1979 would have been impractical - instead I'm thinking of 1982 ( 1200XL time ) - The BBC launched in late 81 at £300. A 800XL+ with faster cpu/memory and 80 col support would have been competition not just for the C64, but also the Apple IIe

[Thorsten Günther]

It's hard to say exactly what is "today's PCs" since hardware varies with various systems. If you go by standard hardware (present in >95% of PCs), they can't fully emulate the Amiga nor Atari nor some other machines brute force or otherwise.

 

My old Thinkpad T23 runs Atari 800 WinPLus 4.0 (and STEem), my desktop PC runs UAE, both without slowdowns. Could you be precise and tell me wich part of the hardware of these computers modern PCs can't emulate by sheer brute force?

 

 

Thorsten

[Rybags]

I agree that 1979 would have been impractical - instead I'm thinking of 1982 ( 1200XL time ) - The BBC launched in late 81 at £300. A 800XL+ with faster cpu/memory and 80 col support would have been competition not just for the C64, but also the Apple IIe

 

Well, lots of Apple II accelerators and even Apple's laptop version had means of switching to 1 MHz for compatability purposes.

 

The Plus/4 allows switching to half-clock mode manually if required via a TED register.

 

No reason really that Atari couldn't have ran quicker RAM, if only to give Antic and the CPU exclusive access on alternate cycles (other than dev/refab costs).

Just have an extra register than aligns them on the same cycle for a compatability mode.

[Heaven/TQA]

The big win on the a8 is the use of the lower res graphics modes, with their lower bus use. That's what allows Rescue to run as well as it does.

 

Yes. It's a straight thing... with two advantages: The CPU can run a bit faster due to less DMA readings of ANTIC(40 of every 2nd line). And Antic saves the CPU from doing something like LDA $,x , STA $$$$,x ... 40 times every 2nd scanline.

That's why I'm pretty sure that Rescue can run clearly faster on the A8, if the game was optimized to the CPU...

 

but it is interesting as when going through the RoFl code in the monitor... you do not find much "unrolled" loops or code... which suprised me because that is one of the first things to do.... same in Eidolon.

 

so actually the gfx rendering engine could not be the bottle neck more the 3d engine...

[Crazyace]

Quicker ram and quicker cpu would have been much better though

[Crazyace]

but it is interesting as when going through the RoFl code in the monitor... you do not find much "unrolled" loops or code... which suprised me because that is one of the first things to do.... same in Eidolon.

 

so actually the gfx rendering engine could not be the bottle neck more the 3d engine...

 

In one of the Lucas interviews they said that the original code was unrolled, but size was more of a constraint

[Rybags]

It's hard to say exactly what is "today's PCs" since hardware varies with various systems. If you go by standard hardware (present in >95% of PCs), they can't fully emulate the Amiga nor Atari nor some other machines brute force or otherwise.

 

My old Thinkpad T23 runs Atari 800 WinPLus 4.0 (and STEem), my desktop PC runs UAE, both without slowdowns. Could you be precise and tell me wich part of the hardware of these computers modern PCs can't emulate by sheer brute force?

 

 

Thorsten

 

I think the brute force part means stuff like I/O happening on an exact timeline basis, e.g. serial/parallel ports etc. It's fairly rare for emulation to even come close, but in most cases you have emulated devices like disk drives anyway which can benefit by running extremely fast.

 

Graphics, CPU and sound don't need to be time-synched. So long as you can perform the emulation of all 3 and generate a frame's worth of processing in less time than the real machine, then the emulation can run to speed.

 

Graphics just need to be kept in a buffer then displayed. Sound is typically buffered and converted to 48, 41.1 or 22 KHz.

 

One potential slowdown is that graphics/CPU especially have to be processed on a per-cycle basis, so that what's supposed to be on a given part of the display at a given time is actually shown, e.g. you might change a pixel several times in a frame but what's shown has to be what it is at the relevant time.

Another slowdown can be collision detection for sprites/graphics.

[Heaven/TQA]

but it is interesting as when going through the RoFl code in the monitor... you do not find much "unrolled" loops or code... which suprised me because that is one of the first things to do.... same in Eidolon.

 

so actually the gfx rendering engine could not be the bottle neck more the 3d engine...

 

In one of the Lucas interviews they said that the original code was unrolled, but size was more of a constraint

 

one of my tons of unfinished projects is reverse engineering RoFl as there are not much information about the engine except for the basic fractal algorithm.

[atariksi]

I wonder what speed was possible for the 6502 in 1982. The BBC ran memory at 4MHz and the 6502 at 2MHz ( with no wait states ) - An 800XL with 3.84MHz memory and a 3.84MHz 6502 would have ruled ( especially if it have additional graphics modes )

I seem to remember an option of the OSI computers for an "ION Implanted 6502" or something like that. I *think* the option was up to 4MHz on some of their machines but it was pretty pricey. The OSI Challengers were out in 1978. It's been a long time so I could be wrong.

 

A 2MHz C64 would have ruled... but then the 1MHz did anyway. At least sales wise.

 

Sales wise as increasing CPU speed (1Mhz) is not the only short-coming of the C64 when comparing to other 8-bitters.

[atariksi]

I wonder what speed was possible for the 6502 in 1982. The BBC ran memory at 4MHz and the 6502 at 2MHz ( with no wait states ) - An 800XL with 3.84MHz memory and a 3.84MHz 6502 would have ruled ( especially if it have additional graphics modes )

 

What CPU was the BBC machine using? The Z80, IIRC allows almost two full T-states between outputting address and sampling data; the 6502 allows slightly less than one cycle.

 

Still, if the Atari could have run its memory system at 3.579MHz while keeping the CPU at 1.79MHz, that could have made more bus cycles available for the display hardware, allowing higher-resolution modes like 160x200x16 or 320x200x4 with no CPU slowdown, or 160x200x256 or 320x200x16 with significant CPU slowdown. Alternatively, it could have allowed a 7800-style oodles-of-sprites system.

 

BTW, I wonder if there were any systems which shared RAM between the CPU and display, and didn't have an integer number of CPU cycles for each display column. If one is trying to use RAM at its maximum speed all the time (as opposed to interleaving, which leaves cycles idle outside the vertical display interval), I would think that it might make sense to use a non-integer number of cycles so that the CPU would never have to be stalled for very long. For example, if each display column took four chroma clocks and on the badlines required two bytes, and if the memory clock rate was 9/16 the chroma rate (2.24MHz), then even on the badlines the CPU could use cycle every 16 chroma cycles (223Khz). A standard 6502 can't have its clock rate fall below 100KHz, and it takes a few cycles to suspend operation while its clock is running, but if the display controller could run the CPU in slow motion without violating the minimum speed, the extra DMA startup cycles could be eliminated.

 

I prefer that things all be predictable and easily calculatable rather than just increase CPU speed at the cost of cycle-exactness and organization. So a 7.16Mhz Amiga is better than a 8Mhz one if you are timing things with the video beam, scan lines, etc. and need the CPU/IRQs involved. The 68000 in the A500/A1000 is 8Mhz chip running at 7.16Mhz. Similarly, a 1.79Mhz Atari is better than a 1.89Mhz. You may gain some cycles with the extra speed but at the cost of exactness and predictability (non-integer = misalignment of pixels and CPU cycles).

[atariksi]

It's hard to say exactly what is "today's PCs" since hardware varies with various systems. If you go by standard hardware (present in >95% of PCs), they can't fully emulate the Amiga nor Atari nor some other machines brute force or otherwise.

 

My old Thinkpad T23 runs Atari 800 WinPLus 4.0 (and STEem), my desktop PC runs UAE, both without slowdowns. Could you be precise and tell me wich part of the hardware of these computers modern PCs can't emulate by sheer brute force?

 

 

Thorsten

 

I mentioned some things in post #2727 above and the short-comings of the buffering approach by emulators was discussed on page 93, post #2301 onwards. When you state "without slowdowns", you are not being exact. You neither want slowdowns nor speed-ups when timing matters. You can't judge an emulator by running a few applications just as you can't claim "earth is flat" because you looked out the window and saw that this is the case. The observation is limited. You need a deductive approach.

 

So if a joystick read on Atari 800 takes 4 CPU cycles (LDA 54016, 2 microseconds) and a PC joystick (through standard gameport at I/O port 201h) takes one millisecond to read the joystick, you can deduce that PCs cannot emulate Atari joysticks. Similarly, if a timer on Atari is at 1.79Mhz and PC timer you use on an emulator is 1.19Mhz or less, you can deduce there will be timing problems (big or small depends on application). If your audio card does not support more than 2 channels and Atari/Amiga does 4 channels at different frequencies, you can conclude that there will audio distortions (won't play like on original machine). If you move an entire screen of sprites in a few microseconds by STA 53248..53255 and your video card does not support sprites, you can conclude that your PC does not emulate Atari sprites. Now there's people who throw around this "FUDGE/KLUGE" factor that what time is lost in one part will be made up elsewhere but you should take that to be just a sales pitch.

[atariksi]

It's hard to say exactly what is "today's PCs" since hardware varies with various systems. If you go by standard hardware (present in >95% of PCs), they can't fully emulate the Amiga nor Atari nor some other machines brute force or otherwise.

 

My old Thinkpad T23 runs Atari 800 WinPLus 4.0 (and STEem), my desktop PC runs UAE, both without slowdowns. Could you be precise and tell me wich part of the hardware of these computers modern PCs can't emulate by sheer brute force?

 

 

Thorsten

I mentioned some things in post #2727 above and the short-comings of the buffering approach by emulators was discussed on page 93, post #2301 onwards. When you state "without slowdowns", you are not being exact. You neither want slowdowns nor speed-ups when timing matters. You can't judge an emulator by running a few applications just as you can't claim "earth is flat" because you looked out the window and saw that this is the case. The observation is limited. You need a deductive approach.....

[Atari_Owl]

I wonder what speed was possible for the 6502 in 1982. The BBC ran memory at 4MHz and the 6502 at 2MHz ( with no wait states ) - An 800XL with 3.84MHz memory and a 3.84MHz 6502 would have ruled ( especially if it have additional graphics modes )

 

What CPU was the BBC machine using? The Z80, IIRC allows almost two full T-states between outputting address and sampling data; the 6502 allows slightly less than one cycle.

 

 

The answer is in the post you quoted.

[+Stephen]

I know one area the 64 was definitely better - BBSes. This is what a caller to my BBS experienced:

 

http://spiceware.org/downloads/commodore/Net-64.wmv

 

Besides standard BBS features and PETSCII graphics and colors, callers to my BBS that used my MusicTerm software experienced:

 

3 voice music - even at 300 baud

speedy menus - text was locally cached

animated characters - check the arrows, ? and +

animated sprites - the 64-Net in the top-right corner

play games online with your joystick

fonts could be changed on the fly (useful for some of the joystick games)

 

One of my best friends in high school ran an Atari based BBS, so at one point I added full support for ATASCII in MusicTerm. I could even watch the ATASCII Movies on my 64, but they were lacking compared to the C/G Movies on Commodore BBSes as the C/G Movies were in color.

 

I have a blog entry about it if you're interested in more detail.

Sorry for the late reply (been busy the past 10 days). I still regularly call BBSes on my Atari, and while I have a nice 80 column ANSI terminal, it's monochrome. That's a really nice BBS there!

 

Stephen Anderson

[supercat]

You may gain some cycles with the extra speed but at the cost of exactness and predictability (non-integer = misalignment of pixels and CPU cycles).

 

Non-integer doesn't imply that there wouldn't be a small integer ratio. Imagine a machine with a 512x400 resolution (interlaced) with four colors. Dot clock is chroma*10/3, so the data rate would be chroma*5/6 (one byte ever 4 pixels). If the memory rate were chroma precisely, there would be 525 clocks every two scan lines, and on each scan line pair during the visible frame, a particular 256 of those clocks would get used by display memory fetches. No less predictable than things are now; the difference would be that the stolen clocks would not all be consecutive. From a hardware standpoint, it would be necessary to add one or two levels of synchronization registers, but that's just an extra 8 or 16 latches. No biggie.

[atariksi]

You may gain some cycles with the extra speed but at the cost of exactness and predictability (non-integer = misalignment of pixels and CPU cycles).

 

Non-integer doesn't imply that there wouldn't be a small integer ratio. Imagine a machine with a 512x400 resolution (interlaced) with four colors. Dot clock is chroma*10/3, so the data rate would be chroma*5/6 (one byte ever 4 pixels). If the memory rate were chroma precisely, there would be 525 clocks every two scan lines, and on each scan line pair during the visible frame, a particular 256 of those clocks would get used by display memory fetches. No less predictable than things are now; the difference would be that the stolen clocks would not all be consecutive. From a hardware standpoint, it would be necessary to add one or two levels of synchronization registers, but that's just an extra 8 or 16 latches. No biggie.

 

What is the 525 clocks for two scanlines for? Non-integer would mean that you also have a mode or timer IRQ or CPU which uses the chroma clock or integer multiple of it. That divide by 3 would cause problems adding up to whole number values. Requiring synchronization registers is not as good as having it synched all the time.

[Crazyace]

If you ran the 6502 and memory at 2/3 the colour clock ( 2.38MHz ) - which matches the slower 64k drams , you would get 152 cycles per line.

In a possible Antic+ you could support a 80 colum character mode in the worst case as below:

 

32 cycles ( 1/3 charmap ) + 96 cycles ( characters ) + 3 cycles ( Dlist ) + 4 cycles ( refresh ) + 16 cycles ( 8 16bit players ) = 151 cycles.

You would have 3 'bad lines' per character line - ( 6 if you had a colour ram a la Plus4 )

 

...actually /3 isn't that likely for logic - so /4 might be better

 

24 + 96 + 3 + 4 + 16 = 143 cycles ( 9 free for cpu )

 

( Alternating fetch charram / colour ram - so all 'badlines' )

 

This would give a mode15 style highres ( 720 ) mode with almost no cpu time - ( although the non scrolling version would be better ) , but a faster cpu during the non display time.

[Rybags]

If they'd gone that way, then maybe they'd also go the Chip/FastRAM approach too like on the Amiga.

[Crazyace]

Maybe - but ram was still expensive , and the 64k drams matched the 6502 address range at the time ( no banking till later )

ColBurst *2/3 or even ColBurst*3/4 ( slightly faster with 171 cycles per line ) should have been possible in 1982.

 

Actually looking at the datasheets for the 64k drams - they supported the fastpage mode accesses.. so if the lms was constrained to even only , the charmap fetches could have been bursts - that would have freed up more time for the 6502 ( The bally arcade hardware had already used 'burst' accesses to support 320x4colour graphics )

 

Split fast/video memory may have been good for the cpu , but It would complicate the bus design a lot more - After all , a 640 pixel 2 colour only mode without sprites should leave as many cpu cycles as the original 8 bit 40 colour mode.

[atariksi]

If they'd gone that way, then maybe they'd also go the Chip/FastRAM approach too like on the Amiga.

 

Yeah, that approach makes more sense as on faster than 7.16Mhz processors, they slow down the RAM speed for Chip RAM access and keep most of the timings in integer multiples of the low-res dot rate. Their CIA frequency does not properly sync with the video as they divided the clock (7.16Mhz) by 10.

[Heaven/TQA]

unfortunatly we can not ask Jay Miner....