Trying to make complete sense of the video scanner, HBL, and the floating bus

[BLuRry]

I was sure that I had implemented everything right, but for some strange reason things aren't right yet. If you all would indulge me, I'm going to brain dump the various things I've gathered on the subject of floating bus. Sather does an awesome job at talking it up from the hardware side, but after re-reading his notes a couple of times I still can't quite make sense of what exactly happens during HBL, except when he talks about what happens on the left-most fringe, where the previous byte in memory affects the left edge (e.g. the upper-right pixel at $2027 affects the middle-left pixel 64 rows down at $2028).

So, for starters, I assume that the video scanner draws the screen from Row 0 ($2000), then row 1 ($2400), and so on up to row 191. Each clock cycle, a byte is read from ram and that byte remains available via the floating bus.

At the end of each row, HBL is started for the next 25 cycles. The row is immediately incremented, and the scanner starts reading the next row at the start address minus 25 bytes, so after writing row 0 the HBL starts the scanner at $2400 - 25, or $2E37. The scanner continues reading bytes, but video doesn't get output until 25 cycles later at $2400.

Once the scanner has finished row 191, VBL starts but the scanner effectively repeats this process over again for the last 70 rows as if it was re-scanning them again.

I get kind of confused on these points, because when I re-read Sather, he talks about the HBL and VBL accounting for the left, right, top and bottom margins. But effectively, there are only left and bottom margins so to speak, because Y is incremented at the very end of the visible scanline, and VBL stops the moment it begins rendering row 0. Am I reading too much into this?

All things being said and done, if I am right about the behavior of the scanner and floating bus then JACE should have worked for money munchers and the rainbow example a couple of iterations ago -- provided I didn't blatantly fat-finger something (ok, so I really shouldn't rule that out either. ;-)

Does this synopsis sound correct or did I miss something?

-B

[Linards Ticmanis]

On 02/11/2012 05:07 PM, BLuRry wrote:
> I was sure that I had implemented everything right, but for some strange reason things aren't right yet. If you all would indulge me, I'm going to brain dump the various things I've gathered on the subject of floating bus. Sather does an awesome job at talking it up from the hardware side, but after re-reading his notes a couple of times I still can't quite make sense of what exactly happens during HBL, except when he talks about what happens on the left-most fringe, where the previous byte in memory affects the left edge (e.g. the upper-right pixel at $2027 affects the middle-left pixel 64 rows down at $2028).

Just a small note here, the artifact at the left edge of the screen does
not happen in IIe and higher machines, only in the II/II+.

> I get kind of confused on these points, because when I re-read Sather, he talks about the HBL and VBL accounting for the left, right, top and bottom margins. But effectively, there are only left and bottom margins so to speak, because Y is incremented at the very end of the visible scanline, and VBL stops the moment it begins rendering row 0. Am I reading too much into this?

Well, the scanner resetting to "column 0" and the electron beam going to
the next line don't don't happen at the same time, and the same is true
for VBL, the scanner reloading the start value and the beam going back
to the top don't coincide either. So of course the picture that you see
on-screen does have left, right, top and bottom margins... even if the
"logical picture" in memory might not.

Not sure whether you got the rest right, I'd have to read it again too.

There's one thing that you have to watch out for: there's a delay
between the time a byte of graphics data is read from memory and the
time it's displayed on screen. You really have to look hard at the
schematics and scratch your head a bit to understand it.

By the way there's something odd about your line formatting, you use
basically one line per paragraph, which causes quotation to not work as
it should.

Regards,
--
Linards Ticmanis

[Vladimir Ivanov]

On Sat, 11 Feb 2012, BLuRry wrote:

> Sather does an awesome job at talking it up from the hardware side, but
> after re-reading his notes a couple of times I still can't quite make
> sense of what exactly happens during HBL, except when he talks about
> what happens on the left-most fringe, where the previous byte in memory
> affects the left edge (e.g. the upper-right pixel at $2027 affects the
> middle-left pixel 64 rows down at $2028).

As pointed, this is fixed after II+. I think it was very noticeable on
Lode Runner while climbing a rightmost ladder.

> So, for starters, I assume that the video scanner draws the screen from
> Row 0 ($2000), then row 1 ($2400), and so on up to row 191.

If you are talking about the vertical count register, it starts before and
finishes after the visible part. And part of this visible part is the
Apple II screen, the rest are just blank lines.

> Each clock cycle, a byte is read from ram and that byte remains
> available via the floating bus.

In the //e case - one byte is read from main and one byte from aux bus, on
the same cycle.

> At the end of each row, HBL is started for the next 25 cycles. The row
> is immediately incremented, and the scanner starts reading the next row
> at the start address minus 25 bytes, so after writing row 0 the HBL
> starts the scanner at $2400 - 25, or $2E37. The scanner continues
> reading bytes, but video doesn't get output until 25 cycles later at
> $2400.

Sather has provided detailed tables of video addresses scanned, for both
text and graphics modes - you can easily check whether you "walk" them
right.

> Once the scanner has finished row 191, VBL starts but the scanner
> effectively repeats this process over again for the last 70 rows as if
> it was re-scanning them again.

Ditto as above.

I choose to made a short program that precalculates scanner addresses into
a table, to save some time on calculating effective address from HCNT /
VCNT.

> I get kind of confused on these points, because when I re-read Sather,
> he talks about the HBL and VBL accounting for the left, right, top and
> bottom margins. But effectively, there are only left and bottom margins
> so to speak, because Y is incremented at the very end of the visible
> scanline, and VBL stops the moment it begins rendering row 0. Am I
> reading too much into this?

As already pointed, there are actually margins. What you call HBL/VBL
contains front porch, sync and back porch+burst.

http://en.wikipedia.org/wiki/Analog_television

> All things being said and done, if I am right about the behavior of the
> scanner and floating bus then JACE should have worked for money munchers
> and the rainbow example a couple of iterations ago -- provided I didn't
> blatantly fat-finger something (ok, so I really shouldn't rule that out
> either. ;-)

I have a weak memory - does Money Munchers work on //e or only on II/II+?

II/II+ and //e have different scan patterns during HBL, IIRC.

[BLuRry]

I found the table you mentioned! It wasn't where I thought it would be but now I understand what it meant. If I set the following values:
HBlank X Offset: 102
HBlank Y Offset: 1
Waits per cycle: 0

Then the rainbow example is **PERFECT** and spot-on. Money munchers still flickers like crazy but I guess this is great progress! No code changes needed.