Wide mode right hand 2bytes of garbage

[andym00]

What exactly is this graphics data being generated ? And is there anyway to kill it ?

 

I thought maybe it was just displaying what was left on the data bus, but it's constant down the screen so that would appear to rule that out..

The only other thing that seems to make sense would be that it's the DisplayList data being displayed ?

 

Have I gone mad this morning ?

[Rybags]

There's some about it in the Antic decap thread.

 

Can be avoided by not using certain HScrol values or just using Standard width but you often don't want to do that.

 

IIRC the half-character worth of "noise" is bus data. You can also get stuff on the left if using HScrol and a large scroll value.

 

For the most part nobody ever sees it but with some widescreen TVs and most capture cards you'll see some or all of what a normal TV doesn't show.

[andym00]

There's some about it in the Antic decap thread.

 

Can be avoided by not using certain HScrol values or just using Standard width but you often don't want to do that.

 

IIRC the half-character worth of "noise" is bus data. You can also get stuff on the left if using HScrol and a large scroll value.

 

For the most part nobody ever sees it but with some widescreen TVs and most capture cards you'll see some or all of what a normal TV doesn't show.

 

That rings a bell now you mention the decapping thread! Cheers.. Trying to search for this issue on here was keyword hell..

 

It's precisely for the widescreen TVs that I'd like to fix this somehow, if at all possible because it seems a waste to not have nice wide playfields Even though I seemingly throw cycles away like they're confetti with scrolling thrown in as well

[Rybags]

It's been a while but I think HScrolling will help here.

 

Added bonus is you can actually sometimes save some DMA cycles, plus HScrolling in wide uses the same amount of RAM per line.

 

Try enabling it, then shift everything over by 8 colour-clocks (HSCROL=8 ).

 

Of course if you shift everything by a set amount, your calculations of screen positions will change a bit.

 

The Hardware Manual that Phaeron did for Altirra should have diagrams showing how much DMA is done for each HSCROL value in wide mode. Pretty sure that large values actually cut it down.

Edited February 25, 2011 by Rybags

[andym00]

I've already got caught out by the changing DMA that HSCROL brings with it, and observing my DLIs slipping left as HSCROL increases, and decided to limit it to only using 2 bits of scroll since that saves me having to patch up the DLIs with preceding delays based upon the HSCROLL values to get a fixed position for register changes..

 

Time for some value by value analysis of what's going on then and what appears where on each value.. Though I guess it's be 11xx range then

 

I'm not too fussed about it 'really'.. It's already got the problem that the last character on the line doesn't cleanly scroll off anyway, just disappears after a few shifts, but the noise just irritates me enormously..

 

Though I'm still curious of the source.. In my current tests it's constant all the way down the screen and doesn't change on a scanline basis, even though the CPU is active and only the first scanline pattern is different..

 

It doesn't seem to be related to any of the screen fetches, data on the cpu bus.. Another read of that decapping thread I think

 

 

Screen position calculations aren't an issue for this, it's all flexible enough to not care..

[Rybags]

It could well be that it's data that's been fetched earlier.

 

I'm sure I did some tests and playing around to try and alter it and was able to, but never chased up which cycle was providing the info.

 

Another way to check it out is hang the CPU, that way it should in theory just sit there accessing the one address... ie execute practically any opcode of $x2 or $xC.

[andym00]

It could well be that it's data that's been fetched earlier.

 

I'm sure I did some tests and playing around to try and alter it and was able to, but never chased up which cycle was providing the info.

 

Another way to check it out is hang the CPU, that way it should in theory just sit there accessing the one address... ie execute practically any opcode of $x2 or $xC.

 

I'll give that a go this evening when I've more time to sit and look at the results with some concentration instead of the brief looks i'm giving it now in between builds

 

Would be nice if there was some magical solution to it, but I fear it's not to be, and with it my dreams of a lovely looking widescreen experience..

Or horror of horrors, 40 column mode

 

 

 

[Rybags]

There's always the option to mask bits out using Missiles although it's not real useful in hires modes.

[MaPa]

I thought there should not be any garbage on right side of the screen. Only problem is "poping" of the last character when smooth scrolling. I would bet, you do that "garbage" with your code

[andym00]

I thought there should not be any garbage on right side of the screen. Only problem is "poping" of the last character when smooth scrolling. I would bet, you do that "garbage" with your code

 

I bet I don't

[phaeron]

It is definitely from ANTIC and not from the program. This vidcap is from The Last Starfighter; I guarantee you that last character on the right is not in the ROM character set.

[MaPa]

Ah, my bad, my TV doesn't show the rightmost character where the garbage occurs Maybe via antenna cable but not composite.

[phaeron]

Alright, I did some more testing on real hardware, and I've been able to hack Altirra to show the same effect.

 

I can confirm that the garbage on the right hand side is indeed bus data being pulled in by ANTIC. To be specific, there is a playfield DMA stop that prevents the playfield from going beyond cycle 104, but the fetch hardware keeps going. Normally, the only effect you see from this is that it keeps incrementing the memory scan counter, so the addressing doesn't get mucked up. However, it turns out that the playfield hardware is actually still doing the fetches, but instead of driving a read cycle on the bus, it passively fetches whatever else is on it, usually activity from the 6502. There is a narrow window of cycles in some display modes with a wide playfield where this garbage data can become visible. You should not be able to see it with a narrow or normal width playfield, even if it is being scrolled, but you can see it with a wide playfield, and I think it can get far enough left to collide with it, too.

 

What intrigues me about this is the possibility of using a false playfield DMA fetch to read the activity of a refresh cycle. I wonder if it's possible to distinguish an ANTIC-D from an ANTIC-E in software this way.

Edited March 4, 2011 by phaeron

[Rybags]

Interesting concept... but we're getting Data Bus activity so how would we know D from E unless we populate RAM with known values?

 

And then, doesn't any DRAM expansion beyond 64K need Antic E, or extra circuitry to either generate the extra Rows or alter the Refresh into one the DRAM sees as being an "Auto" one?

[phaeron]

Populating RAM with patterns would have been my idea, but it occurred to me that the DRAM probably doesn't drive the data bus during refresh cycles. Nuts. I was kind of hoping that there was something you could do with this besides annoy people writing emulators. I guess I can use this to annoy hardware people working on FPGAs too.

 

Anyway, it turns out to be possible for the corruption to extend far enough left to be detected by P/M collisions -- in modes 6 and 7, you can get four color clocks in the collidable region at HSCROL=2, at GTIA positions $DA-$DD. Acid800 test module is attached. If you're trying to conceal you want to throw a missile on top of that area. If you're trying to avoid, you want to choose an HSCROL position that delays the first virtual or blocked DMA fetch. The effect seems much rarer with bitmap modes since there is an extra cycle of delay between the graphics fetch and display compared to character modes.

antic_virtdma.zip

[MaPa]

Btw. it's only 1 byte not 2, isn't it?

[phaeron]

Usually it's 1, but you can get 2 bytes if you pull DMA tricks. I got 1.5 bytes to show up with a vertically stretched mode C line, by starting it with high HSCROL and then moving it all the way left on subsequent scan lines. Since ANTIC's internal buffer replays relative to the left side, this pulls more of the data from HBLANK back into view. (I was doing this to figure out what is on the data bus during a WSYNC wait.) I didn't try with mode E or F, but I suspect in those cases it could be as much as 3 bytes of data. You're unlikely to hit this case unless you're doing something really crazy like a water effect.

[ijor]

I think this is an Antic buglet. Antic can't decide if the display width is 176 or 178 color clocks. The main DMA logic is designed for 176 color clocks, but some other logic that sets the borders it does it for "only" 50 color clocks (228 - 50 = 178). The bug is usually harmless because, besides that being relevant only for wide PF, it affects a place in the display too far at the right, normally it won't be visible.

 

It is, of course, in the "collidable" region, because otherwise it won't be displayed. C/GTIA performs collision anytime that ANTIC doesn't signal HBLANK or VSYNC.

 

It is (normally) two color clocks of garbage, as a result of one DMA cycle not being (fully) performed. More is possible with some DMA width/HSCROL trickery.

 

DRAM shouldn't drive the bus on refresh cycles.