video upgrade?

[cathrynm]

What about...

 

1. On the SIO bus. No-solder install.

2. XEP-80 like driver.

3. Pass through for Atari video output.

4. Overlay 80 over 40.

5. SVGA output.

[Mathy]

Hello Edward

 

It seems like all SD-cards over 2MB are SDHC. Will the SD-80 support those SD-cards too?

 

BTW it's black and white only I guess? Or 16 greyscales?

 

Greetings

 

Mathy

[bfollett]

Full SD Card support Fat 16 File system, with ATR and native support up to 2GB of Storage for Images and even

cartridge and/or OS images loaded from the SD Card.

 

You might even get 4GB compatibility. Transcend still makes a 4GB non-SDHC SD card. You have to use a larger than standard cluster size to format it in Fat16 and still get all 4GB, but it can be done. I wonder what the the compatibility of these SD cards would be with this cartridge. I know most digital cameras from a few years back (including my Canon S2) can only format and officially use non-SDHC SD cards up to a 2GB, but the 4GB Transcend Cards have been tested and work, if formated from a dos box in Windows.

 

Bob

[edward1469]

Bob,

I can't Imagine why anyone would need more than 2GB of Storage, I know I know I sound like Bill Gates "I can't imagine anyone needing more than 640K" ROFL

but truth is The Sky is the limit as it's all software based on the 32 Bit CPU vs a Hardwired option

Thanks

Ed

 

Full SD Card support Fat 16 File system, with ATR and native support up to 2GB of Storage for Images and even

cartridge and/or OS images loaded from the SD Card.

 

You might even get 4GB compatibility. Transcend still makes a 4GB non-SDHC SD card. You have to use a larger than standard cluster size to format it in Fat16 and still get all 4GB, but it can be done. I wonder what the the compatibility of these SD cards would be with this cartridge. I know most digital cameras from a few years back (including my Canon S2) can only format and officially use non-SDHC SD cards up to a 2GB, but the 4GB Transcend Cards have been tested and work, if formated from a dos box in Windows.

 

Bob

[peteym5]

Bob,

I can't Imagine why anyone would need more than 2GB of Storage, I know I know I sound like Bill Gates "I can't imagine anyone needing more than 640K" ROFL

but truth is The Sky is the limit as it's all software based on the 32 Bit CPU vs a Hardwired option

Thanks

Ed

 

Have to keep in mind we are talking about storing all the games and software ever written for the Atari 8-bit computer. I can fit them all on a 650meg CD ROM along with emulators and other related software so I don't see much of a need to go really crazy with gigabyte storage.

[Artlover]

Have to keep in mind we are talking about storing all the games and software ever written for the Atari 8-bit computer. I can fit them all on a 650meg CD ROM along with emulators and other related software so I don't see much of a need to go really crazy with gigabyte storage.

EVERY disk image, EVERY cart dump, EVERY cassette dump, EVERY program file?

 

The Homestar game disk collection alone is like 65 megs of extracted images.

 

What about atari specific data files. User created pokey music files, bitmap screens, etc?

 

What about generic cross platform data files useable on the atari through utilities. It's got Mod trackers, Gif/Jpg viewers, etc. Don't you need/want a place to put the files you want to play/view.

 

Even on the C64, the complete Gamebase V5 collection is 4.5 gigs. Yes, GIG's, as in it barely fits on a DVD. Even that is not 100%. Didn't think the C64 had that much more then the Atari.

 

There is no such thing as "too much storage". Ok, maybe 1TB might be a bit excessive for an 8bit. But a few gigs, absolutely not.

[atariksi]

Have to keep in mind we are talking about storing all the games and software ever written for the Atari 8-bit computer. I can fit them all on a 650meg CD ROM along with emulators and other related software so I don't see much of a need to go really crazy with gigabyte storage.

EVERY disk image, EVERY cart dump, EVERY cassette dump, EVERY program file?

 

The Homestar game disk collection alone is like 65 megs of extracted images.

 

What about atari specific data files. User created pokey music files, bitmap screens, etc?

 

What about generic cross platform data files useable on the atari through utilities. It's got Mod trackers, Gif/Jpg viewers, etc. Don't you need/want a place to put the files you want to play/view.

...

 

Yeah, it would be hard to make an absolute statement regarding total MBs of Atari software. I bet there is some software exists that no one has ever heard or seen. Once you get into cross-platform data files, I have one application that's 2GB compressed into one CD (650MB) and comes with MPDOS Pro: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewI...em=320309023177 and nobody knew about it until I started putting it on ebay.

 

I guess if you limit it to just executeable code, it may fit into a GB since many EXEs are optimized to use <= 16KB. The statement needs to be qualified by restricting to say marketed software in Atari magazines; Or one can qualify it with words like "Software AS I KNOW IT" similar to what Carl Sagan stated, "There's no life on other planets AS WE KNOW IT."

[Rybags]

4 gig might seem like peanuts if an accelerator board goes mainstream and we then have the ability to do stuff like rudimentary full-screen video + audio.

[edward1469]

Well again being both a Hardware and a Software solution that is upgradeable with new firmware keeps the options open

something us Atari People love to do so I dont really see a problem with going above 4GB or SDHC or anything like that

in the future 8-Bit programmers are a dying breed <not literal> we've always learned to cram code into small spaces and

find unique solutions to problems. I started on an TRaSh-80 in the 70's Then met the Woman of my dreams Coleen Hahahaha!

 

Thanks

Ed

 

4 gig might seem like peanuts if an accelerator board goes mainstream and we then have the ability to do stuff like rudimentary full-screen video + audio.

[Shawn Jefferson]

There is no such thing as "too much storage". Ok, maybe 1TB might be a bit excessive for an 8bit. But a few gigs, absolutely not.

 

The Holmes archive is 3 CDs full of stuff, and that's not everything.. It's probably in the low GB range for sure...

[edward1469]

There is no such thing as "too much storage". Ok, maybe 1TB might be a bit excessive for an 8bit. But a few gigs, absolutely not.

 

The Holmes archive is 3 CDs full of stuff, and that's not everything.. It's probably in the low GB range for sure...

but then your also forgetting that you can have more than one SD Card filled ROFL

Thanks

Ed

[Shawn Jefferson]

I was just speaking to the amount of software available for the Atari 8-bit, not about your mystery upgrade.

[peteym5]

I should be more specific in stating that 2gb will probably be more than enough to store more than all the games ever written for the Atari 8-bit. If I include demos, utility software, basic program listings, programming languages, etc, my collection just exceeds 1gb. Most of us would not store everything anyway, like demos, or where there are different versions of the same game.

 

Getting back on track with video upgrading, many of us are still waiting on news on Videoboard XE. However this new mystery cart, there is not alot of specs listed about its capabilities. Is it 80 col. monochrome or color, and how big is its palette.

[edward1469]

I should be more specific in stating that 2gb will probably be more than enough to store more than all the games ever written for the Atari 8-bit. If I include demos, utility software, basic program listings, programming languages, etc, my collection just exceeds 1gb. Most of us would not store everything anyway, like demos, or where there are different versions of the same game.

 

Getting back on track with video upgrading, many of us are still waiting on news on Videoboard XE. However this new mystery cart, there is not alot of specs listed about its capabilities. Is it 80 col. monochrome or color, and how big is its palette.

 

The Video is VGA 2 bits per pixel so not the best but true 80 columns depends on how much space I have left as to what modes i'll have right now it emulates the XEP80 to the register level with plenty of registers for expansion once i've got all the SD functions working 100% in the next couple of weeks i'll focus on the Video and USB

Thanks

Ed

[Rybags]

Cool. 2 bpp @640 across should translate to 16 colours in 320x and 256 colours in 160x

 

Will that be the case?

[ClausB]

Summer's over...

But here in Michigan we have another season between Summer and Winter. It's called FLL. That's FIRST Lego League competition season. Go Programmers!

OK, FLL season ended tonight. And winter is definitely here, so I need to get busy with the experiments. Trouble is, I put away the Atari when we got kittens last month. Yeah, I know, excuses, excuses.

[ClausB]

Well, another Winter came and went and my Projects list is no shorter. I have been rethinking the design, however.

 

From your previous comments it's obvious that the FRAM design would be too slow to interest the hot programmers around here. So I suggest we step back to the idea of SRAM addressed by ANTIC in parallel with main RAM. It should still be a plug-in cart though, a solderless accessory. How about this:

 

Have a fast 32KB SRAM mapped into the 8K cart space with 4 banks. Bank 0 would be the default bank where ANTIC display data would go. Other banks would hold the enhanced luma data and the CPU would read and write them, 8 bits at a time, using normal bank selection techniques. During each ANTIC DMA cycle, the fast SRAM could spit out up to 4 bytes per cycle (kind of like Bob's accelerator), one from each bank. Shift registers would capture all bytes except the last one, which stays on the bus for ANTIC to read. Then the shift registers would serialize the luma data to make hi-res video to be summed with the GTIA luma.

 

Several variations come to mind. Up to 6 bits per color clock are available. Horizontal resolutions up to 960 pixels are possible, or maybe 480 pixels with 4 luma levels. Or we could map a bigger SRAM over the full 16K cart space, giving enough display RAM for Rybags' interlaced mode plus hi-res.

 

What do you all think?

[+bob1200xl]

It would be very nice, but how are you going to sense ANTIC DMA from the cart? Can you limit cart access to only ANTIC? (yes, maybe...)

 

I think FRAM is still worth developing - let someone else make it faster, if need be. Shouldn't be difficult for all these hot programmers!

 

Bob

 

 

 

Well, another Winter came and went and my Projects list is no shorter. I have been rethinking the design, however.

 

From your previous comments it's obvious that the FRAM design would be too slow to interest the hot programmers around here. So I suggest we step back to the idea of SRAM addressed by ANTIC in parallel with main RAM. It should still be a plug-in cart though, a solderless accessory. How about this:

 

Have a fast 32KB SRAM mapped into the 8K cart space with 4 banks. Bank 0 would be the default bank where ANTIC display data would go. Other banks would hold the enhanced luma data and the CPU would read and write them, 8 bits at a time, using normal bank selection techniques. During each ANTIC DMA cycle, the fast SRAM could spit out up to 4 bytes per cycle (kind of like Bob's accelerator), one from each bank. Shift registers would capture all bytes except the last one, which stays on the bus for ANTIC to read. Then the shift registers would serialize the luma data to make hi-res video to be summed with the GTIA luma.

 

Several variations come to mind. Up to 6 bits per color clock are available. Horizontal resolutions up to 960 pixels are possible, or maybe 480 pixels with 4 luma levels. Or we could map a bigger SRAM over the full 16K cart space, giving enough display RAM for Rybags' interlaced mode plus hi-res.

 

What do you all think?

[Rybags]

I guess you'd need to rely on the programmer to not access the cart's RAM when it's doing the display. Of course, you might be able to cater for writes and ignore those cases.

 

I suppose also with character modes, you'd have to keep the map data in main RAM and have the character set reside in the cart.

 

It should all work. So, I guess you just have the thing read extended attributes serially, regardless of what Antic has just read - of course that's the only way character modes could still work.

[candle]

need some clarification: when talking about FRAM, do You mean ferroelectric nonvolatie ram? this is only fram i know of, but it would be pointless

[ClausB]

It would be very nice, but how are you going to sense ANTIC DMA from the cart?

 

I guess you'd need to rely on the programmer to not access the cart's RAM when it's doing the display.

 

That's exactly what I was thinking. In display mode, any read cycle, whether from the CPU or from ANTIC, would trigger the burst. The programmer could set up DLIs to enable and disable display mode and flag when it's safe to read the RAM.

[ClausB]

need some clarification: when talking about FRAM, do You mean ferroelectric nonvolatie ram? this is only fram i know of, but it would be pointless

Yes. See earlier posts. One design was based on serial RAM, and the FRAM was the only serial RAM I could find then. We did not need the nonvolatility feature of FRAM, just the SPI feature.

[candle]

okay, novadays we have spi ram from microchip, but it still follows standard spi flash memory protocol, meaning, that before every write command one must issue wren command, then write command, send starting adress and start sending the data

you're going to implement all of this in software?

 

when reading data, you must issue read command, and sent 3 bytes of starting adress, then supply continuous clock pulses for data to be clocked out

when you put CS line up, data transfer is terminated, and sequence must be repeated - this you must implement in hardware

[ClausB]

okay, novadays we have spi ram from microchip, but it still follows standard spi flash memory protocol, meaning, that before every write command one must issue wren command, then write command, send starting adress and start sending the data

you're going to implement all of this in software?

Yes, software would write one bit at a time. That's why it would be slow.

when reading data, you must issue read command, and sent 3 bytes of starting adress, then supply continuous clock pulses for data to be clocked out

when you put CS line up, data transfer is terminated, and sequence must be repeated - this you must implement in hardware

Software would write command and address, one bit at a time, and then enable a 14 MHz clock to shift out video data. Not much hardware needed for that. See diagram in previous posts.

[Rybags]

Just thinking about this again... is it really necessary to put the normal screen data on the cart?

 

Sure, for syncing purposes it's needed to trigger timing. But, if we're doing HScrolling, things can get thrown out of sync (odd colour clock settings).

 

Why not just rely on having the Display List there instead?

 

Then the only issue of contention becomes 3-byte instructions. In that case, you just "ignore" for a while after the first one is detected.

Edited March 14, 2009 by Rybags