video upgrade?

[ClausB]

I don't think Antic/GTIA even do the 262.5 lines/frame.

 

Isn't it 262 or 312 (PAL)?

I agree. AFAIK, NTSC has 227.5 color clocks by 262.5 lines per field (half a frame). ANTIC/GTIA does 228 color clocks by 262 lines. No interlacing provided.

 

Has anyone ever hacked an Atari to do NTSC or PAL interlacing? Is it even possible? Isn't the sync generation hard-coded into the ICs?

 

Could we feed ANTIC digital output(s) into a FRAM and feed video from the FRAM? Swap back and forth each frame? Heck, you could do 480p that way! You could do 1080p that way... sort of...

That's another interesting idea, Bob, resampling the AN0-2 signals. By modifying the sync commands and playing it all back to GTIA, could you generate a true interlaced or progressive scan signal?

Edited July 11, 2008 by ClausB

[carmel_andrews]

Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)

[MEtalGuy66]

Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)

 

Heres an idea... Why not read the thread before you post, and understand the relevency/redundancy of your questions/comments before you make them!

[ijor]

I agree. AFAIK, NTSC has 227.5 color clocks by 262.5 lines per field (half a frame). ANTIC/GTIA does 228 color clocks by 262 lines. No interlacing provided.

 

None of the older "classic" consoles and home computer did interlacing. It wouldn't make any sense then. Interlacing is more expensive to implement, more complicated software wise, and produces more flickering for static screens.

 

The main purpose of interlacing is to double the vertical resolution without increasing the bandwidth. But doubling the vertical resolution on home computers and consoles at that time wasn't practical.

[Rybags]

I had an idea some time ago for interlacing. It would have involved using a circuit controlled via output from the joystick port with software control.

 

The strategy was to be able to override sync pulses, cancelling them selectively and creating them selectively.

 

So, each second frame create the first sync pulse halfway through the last scanline. Still, it wouldn't have been a standard signal but might work with some TVs just as our default signal isn't exactly standard either.

[+bob1200xl]

Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)

 

 

Because it's way beyond our capabilities. That would be great if we could do it - but we can't. Someone(s) out there has the knowledge and hardware to do it. If she were just an Atari Nut like we are...

 

(might as well dream big!)

 

Bob

[machf]

"She" who? You actually know such a person, or are you just guessing?

[+bob1200xl]

I don't think Antic/GTIA even do the 262.5 lines/frame.

 

Isn't it 262 or 312 (PAL)?

I agree. AFAIK, NTSC has 227.5 color clocks by 262.5 lines per field (half a frame). ANTIC/GTIA does 228 color clocks by 262 lines. No interlacing provided.

 

Has anyone ever hacked an Atari to do NTSC or PAL interlacing? Is it even possible? Isn't the sync generation hard-coded into the ICs?

 

Could we feed ANTIC digital output(s) into a FRAM and feed video from the FRAM? Swap back and forth each frame? Heck, you could do 480p that way! You could do 1080p that way... sort of...

That's another interesting idea, Bob, resampling the AN0-2 signals. By modifying the sync commands and playing it all back to GTIA, could you generate a true interlaced or progressive scan signal?

 

I am guessing that the tag for interlaced video is the timing of the horizontal sync vs. the vertical sync. In the odd field the vertical and horizontal are asserted in phase. The even field has them skewed by half a horizontal clock interval. The Atari has them co-incident. If we just clip off the hsync at vsync for every other field, would the component input 'see' something it could use? One thing that seems to happen (if you can sync up) is the TV line-doubles the display where it finds an interlaced picture. At least, that's what I see on mine. Looks super!

 

I am pretty sure that you could store both sync fields in one FRAM and just point to their starting address at the beginning of each frame. The 'data' FRAMs would not need to be odd/even format, actually.

 

It seems like to me that the TV is going to stripe the data according to hsync and just blow off those pesky little short lines. It has to do something like that, looking at what NTSC feeds it.

 

Bob

[+bob1200xl]

"She" who? You actually know such a person, or are you just guessing?

 

No, just dreaming...

 

 

Bob

[ijor]

Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)

 

Because it's way beyond our capabilities. That would be great if we could do it - but we can't. Someone(s) out there has the knowledge and hardware to do it. If she were just an Atari Nut like we are...

 

I beg to differ. I think that the know how in this forum is far and beyond than what's needed for a full reverse engineering, recreation and enhancement of the full A8 chipset and hardware. It hasn't been done yet for several reasons. Mainly because it's a lot of work, and this is just a hobby for most of us. I can bet it will eventually be done.

[DamageX]

"She" who? You actually know such a person, or are you just guessing?

 

No, just dreaming...

oh? I thought maybe you were talking about Jeri Ellsworth.

[ClausB]

Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)

 

Because it's way beyond our capabilities. That would be great if we could do it - but we can't. Someone(s) out there has the knowledge and hardware to do it. If she were just an Atari Nut like we are...

 

I beg to differ. I think that the know how in this forum is far and beyond than what's needed for a full reverse engineering, recreation and enhancement of the full A8 chipset and hardware. It hasn't been done yet for several reasons. Mainly because it's a lot of work, and this is just a hobby for most of us. I can bet it will eventually be done.

Yes, it's been done for the Amiga:

http://www.amiga.org/modules/newbb/viewtop...988&forum=8

and for the Apple II (just Google "Apple FPGA" and pick one).

 

I have programmed FPGAs in LabView but I think that would be too inefficient for a project like this. Anybody got a copy of "Verilog for Dummies" to lend me?

[peteym5]

Verilog and VHDL appear to be high level programming language like C or Basic. I am sure its not impossible to learn how FPGAs work. Are there tools in Windows to help figure out these things? 6502 and Pokey have been done already. Doing the Atari Video, would be interesting. Wonder if we can port a emulators' video section source code over to Verilog for a start.

[machf]

Looks pretty straightforward to me... analog ASIC design using TENTOS on DOS or TANIS on a Sun SPARC in the mid-90s was harder. Plain digital design using predefined blocks is so much easier.

[ClausB]

Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)

Thanks, Carmel, for the fun diversion. Don't let nasty posts put you off!

 

Back to the FRAM idea: I'm considering building a simple proof-of-concept circuit based on an old OSS cart which already has a 4-bit register mapped to $D5xx. I'll keep the bit that switches between RAM and ROM but I'll reassign the other bits as:

1) switch between 14 MHz clock (for reading) and $D5xx strobe clock (for writing)

2) FRAM -CS

3) video mode

 

It will have one 256Kb FRAM and two modes: 640 monochrome and 320 4-lum. The 14.3 MHz clock will be a simple RC oscillator with TTL gates, synchronized to the 1.79 MHz bus clock. Should be easy to build. I'll draw it up sometime and post it. I'll likely wait until winter to build it, since Michigan summers are too short to spend in the lab!

[+bob1200xl]

Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)

Thanks, Carmel, for the fun diversion. Don't let nasty posts put you off!

 

Back to the FRAM idea: I'm considering building a simple proof-of-concept circuit based on an old OSS cart which already has a 4-bit register mapped to $D5xx. I'll keep the bit that switches between RAM and ROM but I'll reassign the other bits as:

1) switch between 14 MHz clock (for reading) and $D5xx strobe clock (for writing)

2) FRAM -CS

3) video mode

 

It will have one 256Kb FRAM and two modes: 640 monochrome and 320 4-lum. The 14.3 MHz clock will be a simple RC oscillator with TTL gates, synchronized to the 1.79 MHz bus clock. Should be easy to build. I'll draw it up sometime and post it. I'll likely wait until winter to build it, since Michigan summers are too short to spend in the lab!

 

Will you share the Verilog source with us?

 

No, seriously, sounds great!

 

Do you have the FRAMs yet? Where is a good source? Which ones will you use? I'd like to try some things under the covers - it's always summer out here in California...

 

Bob

[Mathy]

Hello Claus

1) switch between 14 MHz clock (for reading) and $D5xx strobe clock (for writing)

Why not switch using the R/W signal?

 

It will have one 256Kb FRAM and two modes: 640 monochrome and 320 4-lum. The 14.3 MHz clock will be a simple RC oscillator with TTL gates, synchronized to the 1.79 MHz bus clock. Should be easy to build. I'll draw it up sometime and post it. I'll likely wait until winter to build it, since Michigan summers are too short to spend in the lab!

Yes, please post the schematics here. There's always somebody who wants to build even an experimental version. And maybe others can have a look at the schematic and propose enhancements.

 

Greetings

 

Mathy

[machf]

Back to the FRAM idea: I'm considering building a simple proof-of-concept circuit based on an old OSS cart which already has a 4-bit register mapped to $D5xx.

Does that mean it's going to use the cartridge slot, then?

[peteym5]

I don't think its possible it will work on a cartridge or through an expansion, this has to be wired directly onto the Ataris' motherboard to work. I see mentioning $D5xx may confuse some people since that is used by cartridges. May consider $D1xx, $D6xx, or $D7xx, plus have all that room beyond the first few bytes of GTIA, Antic, Pokey, and PIA pages.

[drac030]

already has a 4-bit register mapped to $D5xx.

 

Please make sure it doesn't conflict with carts like SpartaDOS X or R-Time8.

[ClausB]

Do you have the FRAMs yet? Where is a good source? Which ones will you use?

No. The only source I've found for the FM25256B is onlinecomponents.com at $4.70 each. I would have to order 8 to make minimum order, or get some other stuff.

 

Why not switch using the R/W signal?

Because in read mode, the FRAM will continually shift out bits for 192 scan lines independently of the system bus, so R/-W would be changing during that time.

 

I don't think its possible it will work on a cartridge or through an expansion, this has to be wired directly onto the Ataris' motherboard to work.

The only signal I need that is not on the cart slot is composite luma, which I can get from the monitor connector.

[carmel_andrews]

All this extra ram your'e sticking in....is that purely for graphics oriented tasks or is that split betw. CPU and Antic Access....also, will you be able to code more complex DLI routines (as Antic will have it's own memory)....Additionally as Antic will have memory as well, will any extension to the typical graphics resolutions be possinle i.e beyond 300x192

[Rybags]

Antic has nothing to do with this upgrade - it's in a cartridge and modifies the video signal.

 

That's the potential beauty - plug and play, with no modding of the machine.

[ClausB]

All this extra ram your'e sticking in....is that purely for graphics oriented tasks or is that split betw. CPU and Antic Access....also, will you be able to code more complex DLI routines (as Antic will have it's own memory)....Additionally as Antic will have memory as well, will any extension to the typical graphics resolutions be possinle i.e beyond 300x192

In the simple circuit I plan, the FRAM will be write-only with respect to the CPU. It will run in read mode only during video generation, independent of ANTIC. Others may wish to implement more sophisticated circuitry which might also provide CPU read access to the FRAM. Then one could even take advantage of the non-volatile feature of the FRAM.

 

I plan to overlay the FRAM video onto the ANTIC/GTIA video, providing many possible combination graphics modes, up to 640 pixels horizontal.

Edited July 16, 2008 by ClausB

[MEtalGuy66]