Jump to content
IGNORED

a "long lost" Atari console?


DamageX

Recommended Posts

Don't know if you have seen this already, if not I put it up so you can take a look http://www.hyakushiki.net/junk/a9100.txt

 

It's some kind of tech manual for a system which would have been relevant in the mid to late 80's I guess. Someone emailed it to me yesterday for a laugh, as it's really a hoax (and not some old secret Atari file)  ;)

1004044[/snapback]

 

Yeah, pretty obvious since Sally isn't rated for 2.68MHz.

 

-Bry

Link to comment
Share on other sites

Yeah, pretty obvious since Sally isn't rated for 2.68MHz.

1004414[/snapback]

 

On the 6502, out of curiosity, which clock phase has the longer internal prop delays? How fast could one go using optimal clock waveforms?

 

I'd tend to think the next logical step up from (colorburst/2) would be (colorburst*2/3). This would require come queueing logic to deal with the character rate not being in sync with the clock rate, but I wouldn't think that would be too hard.

 

Actually, if we're designing fantasy hardware, how does this sound: All processor, video and DRAM accesses are coordinated by a new chip (Ramone) which recognizes single accesses by the processor and quad accesses by the video controller. Ramone is clocked by a crystal running at colorburst*2, and generates phi1 and phi2 clocks for the main processor.

 

Processor memory reads are performed in 3 cycles: (1) output the row address and assert /RAS; (2) output the column address and assert /CAS; (3) read the data and release /RAS and /CAS. Writes are also performed in 3 cycles: (1) output the row address and assert /RAS; (2) output the column address and data, and assert /CAS and R/W; (3) release /RAS, /CAS, and R/W.

 

Video memory reads are performed in 6 cycles: (1) output the row address and assert /RAS; (2) output the first column address and assert /CAS; (3) read the first byte of data and output the second column address; (4) read the second byte of data and output the third column address; (5) read the third byte of data and output the fourth column address; (6) read the fourth byte of data and release /RAS and /CAS.

 

Ramone would be configurable to either generate a two-cycle or three-cycle DRAM refresh after every 452 clocks (producing a scan line that's 455 or 456 clocks long). The shorter scan line would correspond with broadcast video standards and would generally produce better-looking results. The longer scan line could be used for compatibility with software designs that use chroma artifacting.

 

How's that sound for a fantasy design? Actually, I'd think the quad access cycles would have been a useful feature not only in Atari-8-bit-style computers, but also in higher-end machines like the Amiga. But it's only in more recent times that such things have come into vogue.

Link to comment
Share on other sites

That's interesting, but you have to balance the cost of extra bus management hardware with the cost of simply buying faster chips and upping the clock. I'm pretty sure there was a 4MHz version of the 65C02 available in the early 80's, or you could just upgrade the RAM speed and start using the cycle interleaving trick at higher speeds.

 

-Bry

Link to comment
Share on other sites

AGA Amigas had some improved method of fetching screen data from chip RAM using static-column DRAM.

1004576[/snapback]

 

Were those the 32-bit-chipset ones? My recollection is that the 16-bit-chipset ones that Commodore produced for way too many years maxed out the bus in hires 4-bitplane mode (dot rate of 14.31818MHz, so 3.579545 megawords/sec). That doesn't sound like a data rate one would get from exploiting static-column accesses.

Link to comment
Share on other sites

Of course SRAM is cheap enough now that you can just drop in 128K of SRAM, and it's a lot faster, too, so it should be possible to multiplex it while the 6502 isn't looking.

 

Is -15 on an SRAM 150ns or 15ns? Just taking a quick look at my stack of SRAMs, I see a lot of -10 and -12, with some -7 and -5 in there.

Link to comment
Share on other sites

Is -15 on an SRAM 150ns or 15ns?  Just taking a quick look at my stack of SRAMs, I see a lot of -10 and -12, with some -7 and -5 in there.

1004717[/snapback]

 

On a 62256, a -15 would be 150ns. On some other part numbers, it would be 15ns. When the 62256 part number was created, nobody thought SRAMs would get faster than 20ns. When some of the other part numbers were created, there weren't any versions slower than 70ns.

Link to comment
Share on other sites

Were those the 32-bit-chipset ones?  My recollection is that the 16-bit-chipset ones that Commodore produced for way too many years maxed out the bus in hires 4-bitplane mode (dot rate of 14.31818MHz, so 3.579545 megawords/sec).  That doesn't sound like a data rate one would get from exploiting static-column accesses.

1004635[/snapback]

Yes, you're right. AGA was the newer chipset (circa 1991?). If the screen data is aligned right it can do hires and 8 bitplanes and still leave some bandwidth for the CPU. I don't know all the details, I only have an A2000 anyways...

 

BTW, since this is the 7800 forum, would anyone like to explain about Maria's DMA?

Link to comment
Share on other sites

Yes, you're right. AGA was the newer chipset (circa 1991?). If the screen data is aligned right it can do hires and 8 bitplanes and still leave some bandwidth for the CPU. I don't know all the details, I only have an A2000 anyways...

1004889[/snapback]

 

IMHO, Commodore really dropped the ball on the Amiga chipset. When the Amiga came out, the Amiga's graphics were the best that could be had at reasonable price (the PC was 320x200 in four ugly colors or 640x200 black and white, and the Macintosh was about 512x384 black and white). By the time the AGA chipset appeared, VGA was well-established (640x480x16 colors) and the Macintosh routinely had 640x480x256.

Link to comment
Share on other sites

BTW, since this is the 7800 forum, would anyone like to explain about Maria's DMA?

1004889[/snapback]

During the active screen the 7800's GPU (MARIA) HALTs the 6502 CPU and reads the Display List List and Display List from RAM and the character & graphics data from ROM (or RAM). Once MARIA has finished creating the current raster data, it releases the CPU. MARIA can also exert NMI when it completes a DLL with the Display List Interrupt bit set.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...