video upgrade?

[+bob1200xl]

No reason you should drop it... if it were simple, someone would have done it already!

 

I can't get that 'timing' diagram to format on my screen. I can see what it should probably look like but it chops up all the lines so there is no sync on the columns. How do you 'open' that file?

 

Anyway, ANTIC is deterministic, for sure, so I agree that you can probably offset data fetches and feed video without a big buffer. Masking out refresh is easy. Write to xmem with the CPU, read xmem with ANTIC, latch the data, gate to LUMA... what else?

 

Are you going to build this? This could be pretty cool. Different display modes would require different s/w routines but the h/w should work pretty much the same. You could peek the DL and do this line by line, I expect.

 

Bob

 

 

ANTIC does not access the screen data from memory as it outputs a line - it gets it from its own internal 40 byte buffer. It fill its buffer from memory when it needs to update but the timings for access do not relate directly to display timings. You need to multiplex an address counter (read - screen timings) with the system address (write - screen updates) and update the RAM with software routines - ANTIC is not useful here.

Yes, quite right. After I posted, I looked at an ANTIC timing diagram from another thread here. It verifies what you said -- there are 8 or more color clocks of delay between DMA and display. That would require a big shift register to correct -- not worth it.

You could put ANTIC into wide playfield mode and correct for the delay in software by mapping the enhanced luma pixels a few bytes earlier than the ANTIC data. A downside would be 20% more display RAM for wide mode.

 

Here's the timing diagram I had found. You see the DMA fetch timing is regular enough to generate steady video directly -- just mask out the refresh cycles.

 

Sorry, I couldn't just drop this.

[+bob1200xl]

You could put ANTIC into wide playfield mode and correct for the delay in software by mapping the enhanced luma pixels a few bytes earlier than the ANTIC data. A downside would be 20% more display RAM for wide mode.

 

Here's the timing diagram I had found. You see the DMA fetch timing is regular enough to generate steady video directly -- just mask out the refresh cycles.

 

Sorry, I couldn't just drop this.

 

You could just gate ANTIC data on fetches to LUMA and see if it is stable, you know. HALT and NOTREF ===> DATAn to LUMA. You don't need memory to do a feasibility test.

 

(now, I won't be able to drop it!)

 

Bob

[Rybags]

Turn word wrap off in Notepad, then just scroll across (or use a widescreen monitor).

 

What about this method? Although it leaves out GTIA so you'd lose PMGs and some functionality:

 

Snoop the data bus and the Halt output from Antic (so you know when it's the one reading data). Probably have to get the HSync from GTIA also for timing purposes, such that certain data can be ignored, ie - PMG and DList data.

Then you can generate a display. Problem is, you don't have PMGs or know what the colour registers contain.

Might be a feasible way to do 80 columns. Could also do 640h and 320/4 colour modes with trickery mentioned earlier to get Antic to fetch 80 bytes every line.

[+bob1200xl]

Turn word wrap off in Notepad, then just scroll across (or use a widescreen monitor).

 

What about this method? Although it leaves out GTIA so you'd lose PMGs and some functionality:

 

Snoop the data bus and the Halt output from Antic (so you know when it's the one reading data). Probably have to get the HSync from GTIA also for timing purposes, such that certain data can be ignored, ie - PMG and DList data.

Then you can generate a display. Problem is, you don't have PMGs or know what the colour registers contain.

Might be a feasible way to do 80 columns. Could also do 640h and 320/4 colour modes with trickery mentioned earlier to get Antic to fetch 80 bytes every line.

 

I thought I tired that... I'll try it again.

 

You need to realize that PMG and DL and such are different addresses from the screen data. You just leave nulls in memory for them. Right?

 

'You' don't have PMGs or color regs? Who doesn't? Your software does, doesn't it? Shouldn't be a problem.

 

Bob

[ClausB]

I can't get that 'timing' diagram to format on my screen. I can see what it should probably look like but it chops up all the lines so there is no sync on the columns. How do you 'open' that file?

 

Are you going to build this?

 

You could just gate ANTIC data on fetches to LUMA and see if it is stable, you know. HALT and NOTREF ===> DATAn to LUMA. You don't need memory to do a feasibility test.

I had the same problem with Internet Explorer. Just save the file and then open it with Note/WordPad.

 

I've enjoyed this "thought experiment" but building it is more than I can take on now. It's way quicker to draw a box around the word "Control" than to really make it work. Your feasibility test is a nice idea, though. Hmmm...

Edited May 14, 2008 by ClausB

[ClausB]

If you look at this picture here:

 

http://www.atariage.com/forums/index.php?s...t&p=1514042

 

in 'picture3' you can see there's a small delay of ±10 colourclocks between the last vertical black bar and the right screen border.

Nice, simple way to examine ANTIC timing! It works because GTIA LUMx outputs are open-collector and externally pulled up, right?

[ClausB]

No reason you should drop it... if it were simple, someone would have done it already!

I've been kicking these ideas around in the back of my head for some time but yesterday it hit me. Don't bother with ANTIC at all but rather just clock the enhanced luma bits out of SRAM every cycle. There are 228 cycles (color clocks) every scan line and 262 lines per frame, about 60K cycles per frame. About half of those cycles are during H- and V-blank, but so what? Just keep zeroes in those parts of RAM. We would need binary counters to supply the SRAM read addresses, and they could be reset each frame by a DLI to synchronize them with the ANTIC/GTIA display. The enhanced luma data from the 32K-byte SRAM, 4 bits per color clock, could be summed into the GTIA video, so it would overlay. There could be 3 modes: 640 horizontal monochrome pixels; 320 4-gray-level pixels; or 160 16-gray-level pixels. That last mode, overlaid on the 16-color GTIA mode, would give a true 256-color display. The first mode would allow a clear 80-column display.

 

That's still a big circuit. It would be great to have a RAM with the address counters built in. VRAM was sort of like that but AFAIK it's not available anymore. Serial RAM is like that but it's too small. In searching the Web, I found this $5 serial NVRAM:

http://www.ramtron.com/products/nonvolatil...duct.aspx?id=13

We don't need the NV aspect, but it runs as fast as we need if we clock the data out at 14.32 MHz. The CPU could write the data 1 bit at a time and then start a continuous high-speed read for display.

 

I think the cartridge connector has all the signals we need except for composite luminance, which could be wired over from the monitor connector. The hardware should be simple enough for me to build - the complexity is in the software, just where I like it.

 

Any thoughts?

[Rybags]

Sounds good.

 

So, a cartridge that you just pass the luma through kinda in the style of old 3DFX graphics cards.

Probably work best if it had the smarts to be able to leave the signal alone in the offscreen area (ie all but the 176 colour clocks the Atari normally can display, so that the sync signals aren't tainted.

 

We'd probably want programmable V-Height? Would be helpful so that the Atari would know when it's safe to be able to write to the RAM without access conflicts.

[DamageX]

There could be 3 modes: 640 horizontal monochrome pixels; 320 4-gray-level pixels; or 160 16-gray-level pixels. That last mode, overlaid on the 16-color GTIA mode, would give a true 256-color display. The first mode would allow a clear 80-column display.

a color 80-column display no less! It would be sort of like adding on a CGA card (but grayscale only) combined with Atari's video output. I wonder if there is already a chip somewhere that functions like a CGA with genlock.

 

What about adding the 32KB of RAM and then accessing it at the same as ANTIC and using part of the address? ANTIC could be setup for a 80x192 gr.11 screen let's say. Then when ANTIC halts the CPU to access a byte for the display, the add-on board or cartridge will see the HALT signal (check that it's also not refresh) and latch bits 0-13 of the Atari's address to use as bits 1-14 on its own bus. Then half a CPU cycle later, fetch the next byte from its RAM by toggling bit 0.

 

Since fetches happen at the same on both buses there will be no contention between the CPU and the new video circuit. Plus you can layout the display however you want, with LMS, mixed modes, etc. as long the data in the video RAM follows the same pattern as the data in main RAM (except twice as large).

[DamageX]

With this scheme I think even character based modes could work. If, while snooping the Atari's bus, the add-on board ignored the bytes that came from the map, and mimiced only the charset fetches...

 

ANTIC is setup for 40 column multi-color text (mode 4) with a 1KB charset.

 

add-on board gets set to 160 pixels with 16 luminance levels. User program writes a 2KB charset to the add-on RAM, with each character being 2 bytes wide, 4bpp

 

whenever ANTIC fetches a byte (4 pixels * 2bpp) from the charset in main memory, the add-on board fetches the corresponding 2 bytes (4 pixels * 4bpp) from the charset in its RAM. The result is a 160x200 screen with 5 colors * 16 luminances. And the CPU still only has to deal with one set of screen data.

[Rybags]

Problem is you also have to get it to ignore PMG, DList and Refresh fetches.

 

Although if the board was fed the Sync output or the AN0-AN2 lines then it could reasonably easily ignore those cycles.

 

I'd propose calling it the LEM.

 

NASA LEM = Lunar Entry Module, Atari LEM = Luma Enhancement Module.

[ClausB]

Probably work best if it had the smarts to be able to leave the signal alone in the offscreen area...

 

We'd probably want programmable V-Height? Would be helpful so that the Atari would know when it's safe to be able to write to the RAM without access conflicts.

The "smarts" would be in the software, which would know what RAM addresses overlay the valid display, and would put zeroes into the RAM elsewhere. A DLI at the top of the display would enable the video readout, and another DLI at the bottom would disable reading and enable writing to prevent access conflicts. Since this could be in a cartridge, it could include firmware subroutines to do all the messy work.

 

What about adding the 32KB of RAM and then accessing it at the same as ANTIC and using part of the address?

You have some fine ideas there, and we have discussed similar schemes earlier in this thread. They all require wiring into the motherboard or CPU board. If we leave ANTIC alone, then the whole thing could fit into a cartridge and a video cable, and many more users would try it.

[Rybags]

Like I said, refresh accesses put a spanner in the works, but incorporating some clever logic would probably sort that problem out.

 

If there was a kind of RAM shadowing where it mimiced Antic's accesses to a degree, DList and PMG accesses probably wouldn't be too much drama since they are (in a sensible situation) always different to that of the screen, and you could just store null values there.

 

To accomplish that, wouldn't it be best to have a kind of "transparent" mode where say pixel values of "0000" just tell the device to pass the luma through unmodified.

[ClausB]

Like I said, refresh accesses put a spanner in the works, but incorporating some clever logic would probably sort that problem out.

The clever logic is in the DLIs. For 192 scan lines, only read access for the video generation is allowed. During the other 70 blank scan lines (more for PAL), write access from the CPU is allowed.

 

If there was a kind of RAM shadowing where it mimiced Antic's accesses to a degree, DList and PMG accesses probably wouldn't be too much drama since they are (in a sensible situation) always different to that of the screen, and you could just store null values there.

 

To accomplish that, wouldn't it be best to have a kind of "transparent" mode where say pixel values of "0000" just tell the device to pass the luma through unmodified.

Yes, any zero pixel would be transparent. Non-zero pixels would add their luma values to the video.

 

This FRAM device would not be mapped into the 6502 address space. It has an SPI interface with its own address register. For hardware simplicity, the CPU would write one bit into it at a time by writing to the cart control register at $D5xx. That is fairly slow, about 0.25 Mbps, requiring about 1/2 second to draw the entire screen (if the video generation is temporarily disabled - almost 2 seconds if it is left on).

 

However, fast effects are possible. To scroll the display, the CPU simply resets the FRAM read address to a new value each frame. An 80-column display could scroll up instantly and then draw a new line of text in about 1/12 second. A general graphics app could update small regions of the display more quickly because the FRAM write address is also resettable.

[Rybags]

Wouldn't it be easier to just write to it by having either:

- a "window" that gets mapped to, say $D580-D5FF

- or have 2 bytes controlling the address, then a third which you write the data to.

 

If it was a 32K device, then that leaves bit 15 to control whether you're doing a read or write.

 

Another possible spanner re snooping Antic accesses - the cartidge port doesn't receive the full data bus - remember only 16K addressing is possible.

[ClausB]

Wouldn't it be easier to just write to it by having either:

- a "window" that gets mapped to, say $D580-D5FF

- or have 2 bytes controlling the address, then a third which you write the data to.

 

Another possible spanner re snooping Antic accesses - the cartidge port doesn't receive the full data bus - remember only 16K addressing is possible.

Yes, it would be easier for the software to do that. But the hardware, IMO, would be too large. Lots of 74LS ICs or a complex FPGA. Check the Ramtron link above and look at the tiny SPI. It works just like you said, only serially. Send it 2 bytes of address and 1 or more bytes of write data, 1 bit at a time. During video readout, it would stream out bits at 14 MHz, all in parallel with, but not connected to, ANTIC. There is no snooping. The only trick is to synchronize the 14.32 MHz clock with ANTIC's 3.58 MHz clock. I'm thinking of using a 4x clock multiplier chip to generate the former from the latter, guaranteeing synchrony.

 

I'm sorry if I didn't explain this idea very well. I hope you can piece it together from these posts. When I get more time, I'll post a diagram.

Edited July 5, 2008 by ClausB

[Mathy]

Hello Claus

 

If you want to use the cartridge port, you'll have to multiply 1.78MHz by 8 as that's the only clock signal you'll find on the cartridge port.

 

BTW why send 1 bit at a time. If you use three bytes, two for the address and one for the data that is to be transferred, you should be able to send 8 bits at a time.

 

Greetings

 

Mathy (who'ld prefer to keep the complexity of the software to a minimum, as that saves time that can be used for other things)

[+bob1200xl]

No reason you should drop it... if it were simple, someone would have done it already!

I've been kicking these ideas around in the back of my head for some time but yesterday it hit me. Don't bother with ANTIC at all but rather just clock the enhanced luma bits out of SRAM every cycle. There are 228 cycles (color clocks) every scan line and 262 lines per frame, about 60K cycles per frame. About half of those cycles are during H- and V-blank, but so what? Just keep zeroes in those parts of RAM. We would need binary counters to supply the SRAM read addresses, and they could be reset each frame by a DLI to synchronize them with the ANTIC/GTIA display. The enhanced luma data from the 32K-byte SRAM, 4 bits per color clock, could be summed into the GTIA video, so it would overlay. There could be 3 modes: 640 horizontal monochrome pixels; 320 4-gray-level pixels; or 160 16-gray-level pixels. That last mode, overlaid on the 16-color GTIA mode, would give a true 256-color display. The first mode would allow a clear 80-column display.

 

That's still a big circuit. It would be great to have a RAM with the address counters built in. VRAM was sort of like that but AFAIK it's not available anymore. Serial RAM is like that but it's too small. In searching the Web, I found this $5 serial NVRAM:

http://www.ramtron.com/products/nonvolatil...duct.aspx?id=13

We don't need the NV aspect, but it runs as fast as we need if we clock the data out at 14.32 MHz. The CPU could write the data 1 bit at a time and then start a continuous high-speed read for display.

 

I think the cartridge connector has all the signals we need except for composite luminance, which could be wired over from the monitor connector. The hardware should be simple enough for me to build - the complexity is in the software, just where I like it.

 

Any thoughts?

 

Oh, boy... Yes, it would work fine without ANTIC, although it would offload a lot of work onto the software. (a good thing in your book, right?) You can just sense the beginning of a frame from the composite sync - no need for a DLI. You can capture 14mhz from the phase02 signal using a PLL. I don't think an address clock in a CPLD would be that big of a deal (about 18 divide by 2 registers?). If you set up properly, you can read SRAM during NOT phase02 for the video circuits and write (or read) SRAM during phase02 for the CPU on every clock cycle. I wouldn't even bother decoding anything - as you said, 'let the software figure it out!'. Just run the SRAM in sync with ANTIC for the whole frame. With a 512K SRAM you don't even have to use a shift register for different data depths - clock out 8 bits on every cycle and throw away any you don't need. (this is going to be lots of overhead if you're trying to do an 80 column display! you may want to make an exception if you're doing 80 columns)

 

The cartridge port can do all this but the PBI might be a better choice - maybe allow either?

 

Bob

[DamageX]

They all require wiring into the motherboard or CPU board.

I'm thinking just halt, and maybe refresh in this case. These are available on the ECI port at least.

refresh accesses put a spanner in the works, but incorporating some clever logic would probably sort that problem out.

If there was a kind of RAM shadowing where it mimiced Antic's accesses to a degree, DList and PMG accesses probably wouldn't be too much drama

For ignoring the unneeded accesses I have a couple ideas. One is, maybe there is a simple rule that could be applied like acting on all accesses on "even" cycles, while ignoring those on "odd cycles." Another thing is, it could be activated according to the luma value that was coming out of GTIA. So with the border color set accordingly, the device would be ignoring all accesses outside the playfield area.

- a "window" that gets mapped to, say $D580-D5FF

ideally, an 8KB or 16KB window at $8000 or $A000 like normal cartridges, with $D5xx being used to enable/disable the cart and select the bank...

Another possible spanner re snooping Antic accesses - the cartidge port doesn't receive the full data bus - remember only 16K addressing is possible.

I think that's not a big problem, since ANTIC isn't going to be working with more than 16KB at any given time unless you have a "virtual" screen that is much larger than the actual display. (in which case the device would need even more than 32KB also)

Yes, it would be easier for the software to do that. But the hardware, IMO, would be too large. Lots of 74LS ICs or a complex FPGA.

How many 74xx chips can fit in an Atari cart? How cool would it be to get some Atari cart PCBs made to hold a CPLD or modest FPGA chip? They could then be used for various projects/upgrades/experiments. Something like the 8-bit baby http://www.protovision-online.de/catalog/p...?products_id=97

If you set up properly, you can read SRAM during NOT phase02 for the video circuits and write (or read) SRAM during phase02 for the CPU on every clock cycle.

Yes that's an excellent idea, there is still enough bandwidth for the previously mentioned 640 pixels mono, etc. since you can then read during every CPU cycle, unlike ANTIC which uses only every other cycle for bitmapped modes.

[Rybags]

Another spanner (my toolkit is disappearing here):

 

Antic's mix of character, refresh and mapdata fetches can skew when H-Scrolling is used.

 

The Antic Timings doc is a handy reference. Also note that DList fetches can change dependant on whether PMG DMA is enabled.

 

Antic_Timings.txt

Edited July 6, 2008 by Rybags

[DamageX]

Maybe a simpler approach would be to have the device ignore all ANTIC memory accesses on even 8KB pages (as well as all refresh cycles) then put your PMG, DL, char map there and your bitmaps/charsets on odd 8KB pages. Or some such thing...

 

I googled for "on screen display" chips and came up with the MAX4455. Candidate for an Atari cartridge? It can do high-res 4-bpp grayscale with transparency. Supports up to 8 separate outputs and 2MB of RAM. A little overkill perhaps.

[Rybags]

I just fancy the idea of having the thing "run wild", triggered by software (DLI), and having it have exclusive access to it's own RAM during such time.

 

Have parameters such as frame duration and bit depth/h-resolution if possible.

 

In such case that custom ICs only have the shift-register for R/W, couldn't a 74LS* shift register be used to be able to at least write a byte at a time to it?

[ClausB]

If you want to use the cartridge port, you'll have to multiply 1.78MHz by 8 as that's the only clock signal you'll find on the cartridge port.

Yes, of course, you are right. thanks for the correction.

BTW why send 1 bit at a time. If you use three bytes, two for the address and one for the data that is to be transferred, you should be able to send 8 bits at a time.

The Ramtron FRAM device has a serial interface, which is ideal for shifting out video bits, but no so much for writing data to it. For writing, I envision wiring D7 to the SI pin and using the decoded $D5xx strobe signal to clock the single bit in. So, each 6502 sequence ASL A, STA $D5xx, can write one bit and takes 6 cycles. Including overhead, I estimate about 0.25 Mbps write speed (see above for more timing estimates). If this serial write speed is unacceptably slow, then we should add a parallel-to-serial shift register plus clocking logic to the design. IMO, once we add such hardware, we lose the advantage of the serial RAM, and we might as well go back to the standard SRAM with external address counters.

[Rybags]

Like I said before, couldn't writing to it be accomplished by an off-the-shelf shift register IC?

 

Then, even if it took 8 or 9 cycles for a write byte, it's still a hell-lot quicker than bit bashing, and not too much slower than a scenario of the 6502 writing to extended RAM banks.

[carmel_andrews]

Claus/Rybags....Wouldn't it be just as easy to hack an old PC video chip (say matrox or ATi etc) and try interfacing it with Antic (or as they have done with the VBXE) as a replacement for antic or gtia