video upgrade?

[candle]

ClausB: yes, i've did some thinkering just before bed time and came to the same conclusions, but still - how you're going to synchronise 14mhz clock in your circuit to 3.58 clock in atari?

 

Rybags: how are you going to implement horizontal scroll? you need to send read command and at least 2 bytes of starting address (microchip 23k640 spi ram) every line

from my understanding of the spi protocol implementation you need at least 48 (hardware aided) cpu clocks per byte, and have 115(112?) clocks per scanline, for fram you need to send 4 bytes total to start reading

 

ClausB: consider using XC9536 for SPI communication, there is thread on 6502.org forum for you to get familiar with

[Rybags]

I brought up scrolling just as a timing consideration - DMA timings become different, and you have the half-cycle delay for odd Colour-Clocks.

 

I guess you could implement some sort of delay register to compensate... then again if this thing's accessed serially it's not like we're going to be doing full-screen scrollers with it.

[candle]

full text line horizontal scrolling is somewhat complicated :/ vertical scrolling is trivial

 

i don't want to discourage anyone from futher development of this extension (as long as it doesn't collide with vbxe) but at the end you may recieive a product which will be quite complex, expensive, and yet offering verry little

 

what would really improve this is double port ram

 

please reconsider if time and cost involved are really worth the output

 

it simply cannot compare to vbxe 1.0, or vbxe 2.0 (having vga output in any atari resolution), and putting one into atari involves only taking antic out of the socket, and putting it into vbxe and whole board back to the place where antic was

[ClausB]

Well, OK then.

 

Back to my question for the rest of you:

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?

[candle]

ok, how are you going to synchronize the output from antic with your device when limited to what you find on cart connector?

how do you even know antic is accessing the data?

[ClausB]

ok, how are you going to synchronize the output from antic with your device when limited to what you find on cart connector?

how do you even know antic is accessing the data?

I answered that yesterday in post #296. For the third time: PLEASE READ THE PREVIOUS POSTS.

 

Proszę przeczytać poprzednie posty.

Edited March 15, 2009 by ClausB

[candle]

ClausB: i'm verry sory, but this is not good enought

i admit to not reading whole thread, but post 296 is like julius verner novel for me...

[ClausB]

I suppose I was not very clear. I too can not understand Jules Verne in the original French.

 

My idea is that the hardware would respond to any read (from CPU or ANTIC) with several bytes in quick succession in one cycle, as long as that mode is enabled. The hardware would include a control bit to disable that mode. A DLI could enable that mode just above the first scan line and disable it after the last. The programmer would be careful not to read display RAM while that mode is enabled, otherwise there would be "sparkles" on the screen. But he could read during vertical blank. He could write to display RAM anytime - only reads are affected.

 

I hope that explains it better, and I do welcome your questions.

[candle]

is memory going to be clocked constantly?

if that is so, you need to accomodate ram for blank portion off scanline, and h-sync time, otherwise picture will be skewed - alot!

so if the answer is no, you have two choices - one is to make this mode stop itself after clocking out n-bytes of data (by hardware counter - additional one i'm affride), or do it in software, which is even more problematic

as for enabling that hipothetical mode in dli - do quick test

get blank screen with graphics mode 15 (antic mode - 320pixels, 1 color and background, it was some time ago when i programmed anything on atari) and enable dli at every scan line

dli routine would ony increment color value of the background and return - nothing more

see if you have color change on the beggining of the line

for pal system you will have it on 1/5 of screen width

 

then you may try to pause the cpu wrting to one of antic registers (wait for hblank) and do the dli test once more - this time every other scanline

see if this is more acceptable

[DamageX]

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?

So, compared to what we discussed before, putting ANTIC's display data right on the cart eliminates the need to snoop the HALT line to know when ANTIC is accessing memory. I like it.

 

480 or 960 pixels would be a bit inconvenient if you want to do software 80-column text though. Characters wouldn't be an even byte wide. Maybe we could just settle for 60 columns if we want it to be fast, as that is vastly more readable on a standard TV anyway.

[candle]

it is very naive to think that antic is accesing screen data when halt is active - it might be doing memory refresh, or feeding gtia with p/m g data

halt is active 9 times per scanline during first half of scanline

for text modes situation is even more problematic

 

the only way to know where antic is is to extract synchronisation from monitor output and feed it into this hipothetical circuit, or have it completly async with antic and capable of doing all the display on its own

 

bottom line is - this ain't gonna be simple circuit if you want it on cart

Edited March 15, 2009 by candle

[ClausB]

480 or 960 pixels would be a bit inconvenient if you want to do software 80-column text though.

True. Another variation on the design would give 640 pixels across, using 3 bytes per cycle.

[ClausB]

it is very naive to think that antic is accesing screen data when halt is active - it might be doing memory refresh, or feeding gtia with p/m g data

The HALT signal is not available on the cart, so it has nothing to do with this design. It is up to the programmer to put only display data in the cart address space. Everything else - display list, PM data - should go elsewhere. He could put some CPU data there as well, but he should not read it while display is enabled, only during vertical blank.

[Rybags]

That's where the address range idea becomes clever.

 

But, I would assume that Antic at times would confuse things by outputting Refresh Rows that correspond to $Axxx addresses.

[candle]

ClausB: did you preform test i've mentioned earlier? my point is you can't relay on memory access alone - it's not good enought, beside - i'm aware of what is and what is not available (long, unpronoucable word) on cart slot

[ClausB]

I would assume that Antic at times would confuse things by outputting Refresh Rows that correspond to $Axxx addresses.

Ouch, good point! I seem to recall that somebody experimented with refresh addresses and found the upper bits were zero. Wishful thinking?

 

Maybe it was this:

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

What happened to the link to the pictures in that post?

[Rybags]

Don't know... AFAIK, Antic generates Row addresses. And supposedly later Antics cater for 9 rows instead of 8.

[ClausB]

did you preform test i've mentioned earlier?

The DLI test? No.

 

We don't need a DLI on every scan line. We only need one before the first scan line and another after the last scan line to enable and disable the mode.

[ClausB]

And supposedly later Antics cater for 9 rows instead of 8.

Actually, 256 rows instead of 128 (low 8 bits instead of 7). But, as you pointed out, it's the upper bits that could be a problem here.

[Rybags]

Might be an idea to check the Antic Timings.txt doc again...

Dependant on mode, width and HScroll, timings can change dramatically, especially the interleaving of Refresh cycles.

 

An alternative to all this bus snooping might be to just have a Trigger start and stop register.

 

Probably not worth exploring the DList idea I expressed earlier - it's kinda useless for text modes.

 

Yeah, I was out with that Rows description... I meant to say 9 bits instead of 8, but even that would have been wrong.

[ClausB]

Might be an idea to check the Antic Timings.txt doc again...

Dependant on mode, width and HScroll, timings can change dramatically, especially the interleaving of Refresh cycles.

Yes, that is a complication, but nothing a clever programmer can't handle.

An alternative to all this bus snooping might be to just have a Trigger start and stop register.

My main idea here is not to have any additional address generating hardware for the SRAM. Just depend on ANTIC to supply addresses.

[+bob1200xl]

All the chip selects are degated during refresh. Nobody will 'see' an address.

 

Bob

 

 

That's where the address range idea becomes clever.

 

But, I would assume that Antic at times would confuse things by outputting Refresh Rows that correspond to $Axxx addresses.

[Rybags]

Just wondering... when Antic supplies Refresh addresses, are they always with low-byte = 00 ?

 

If that's the case, it might be able to be exploited in some way (ie to ignore them).

[+warerat]

Just wondering... when Antic supplies Refresh addresses, are they always with low-byte = 00 ?

 

If that's the case, it might be able to be exploited in some way (ie to ignore them).

 

I'm pretty sure the during times I was observing the unused address lines were set high (A15-A8) during the refresh. I'd have to hook the logic analyzer back up to confirm.

[ClausB]

All the chip selects are degated during refresh. Nobody will 'see' an address.

Yes, you're right, that's done in the PAL in the XLs. However, in the 800, they are degated on the RAM boards and the cart selects are not degated at all.