UHRES? Mistery/curiosity - any explanation?

[pandy71]

UHRES seem to appear in ECS/AGA documentation but it is hard to find any useful explanation for its functionality.

http://www.winnicki.net/amiga/achtun...S_Display.html

[Hombre40]

Popping up this thread 4 year later to signal this Question (by me) and its accepted Answer (by another user, but I reached the same conclusion) from Retrocomputing StackExchange: https://retrocomputing.stackexchange...cs-and-aga-for .

Basically, UHRES mode is a way do drive a second display, most likely using the serial output of VRam chips, to drive an additional RAMDAC/CLUT/VideoDAC (something like Denise/Lisa, just with a completely different way of receiving picture data, potentially layed out in chunky pixel with any depth) while the regular Denise and Lisa fetches the regular bitplane-layed out display.

According to the documentation linked in my StackExchange question, it works in a rather simple way.

There is one addition "UHRES bitplane" pointer to ChipRAM and an additional "UHRES sprite" pointer to ChipRAM, an additional "bitplane modulo" register, and an additional UHRES bitplane and UHRES sprite "sentinel value" register. At some certain 280ns color cycles in each horizontal scan, Super Agnus/Alice will output on the RGA bus the "sentinel value", while outputting on the regular address lines the respective UHRES pointer.

At this point, some other custom chip/gated array/discrete logic snooping the RGA bus (in parallel with Denise/Lisa) can detect the sentinel value, sample the chip address lines, and start a full-row fetch from a VRam's chip bank synchronous serial port.

This video data can now go to a new additional CLUT/VideoDac that can be generate a display, that, according to the UHRES register descriptions, can be up to 1024x1024 pixel.

At the end of the line, Super Agnus/Alice will add the value in the "UHRES modulo" register to the "UHRES bitplane pointer", so that at the next line, new data will be fetched (the next line worth of pixels).

1kx1k and the use of Vram are exactly the features that the Ranger chipset designed by Jay Miner had before he left Commodore, so I update another question of mine on Retrocomputing SE ( https://retrocomputing.stackexchange.com/a/2707/2155 ) to discuss the hypotesis that indeed ECS and/or AGA was Ranger all the time...

[pandy71]

Sorry for late reply, since few months i have very hectic time.
Based on informations provided by You seem this is not implemented feature i.e. writing corresponding registers and bits should NOT trigger any unwanted actions on ECS/AGA or in other words - all resources allocated for UHRES functionality can be safely used for extended/improved ECS/AGA.

[Photon]

Looks like a add-on graphics card that never happened because the motherboard couldn't handle it? As in, you'd set it up and it would DMA to the VRAM, and the add-on board is what's connected to the monitor.

There's a theoretical test, maybe. Depends on Blitter cycle allocation. You'd set it up and turn bitplane DMA on as usual, and see if it leaves less cycles for a cookie-cut blit (blit takes longer than SHRES 1bpl with the same blits). Obviously this is impossible without the chips the registers were meant for.

[chb]

I think there's a more mundane explanation to UHRES than the mythical ranger chipset.

Commodore did in fact produce a VRAM device already in 1988, and that's been the A2024 monitor. Here is a description of the Moniterm card, essentially an A2024 logic board that gets the RGBI signals from the internal video slot, not from the external video connector. But functionally it's identical to the A2024, so the RAM is not directly addressable, only through the video signal.

It would be logical for C= to think about some more integrated video expansion based on the A2024 card, like some Zorro II card with directly addressable VRAM that is synced with/by the traditional video output. UHRES seems to deliver exactly that, plus an additional hardware sprite. The sparse information about UHRES match the A2024 - fixed 1k*1k resolution, fixed color dept, tho it is 4 color on the A2024, but only 1 UHRES bitplane pointer on ECS (but might have be an interleaved bitmap).

EDIT: I do not think using UHRES would influence chipmem bandwidth, maybe with the exception of some cycles needed to put the uhres pointers on the bus.

EDIT2:

Originally Posted by Hombre40

There is one addition "UHRES bitplane" pointer to ChipRAM and an additional "UHRES sprite" pointer to ChipRAM, an additional "bitplane modulo" register, and an additional UHRES bitplane and UHRES sprite "sentinel value" register.
.

I don't think those UHRES bitplanes would have been in chipmen, but rather in separate VRAM. As far as I understood, that's also what Valentino Miazzo says on your first thread on stackexchange.

[Gorf]

I have to oppose that:
I don't think it was meant for am extra gfx-card, with separate VRAM, but for the use of VRAM as Chip-RAM. Hence the use of the RGA-bus.
It would add not too many additional traces on the motherboard to support VRAM and than only some glue-logic and a second "head" (simple VideoDAC/Vidiot) is required.
With just one Bitplane no CLUT is needed and you can perform all usual Blitter operations on that.

It would have beed even a more cost-effective solution for the A3000 (or A2500), instead of the built-in Amber with costly dual-portet RAM, and would have provided a useful HighRes output for a workstation.

Imagine a A2000 with that feature in 88/89 - it would give you a second monitor in addition to the NTSC/PAL compatible video: perfect for all genlock- and video-applications since you can use the independent b/w output to orchestrate everything...

Also nice for CAD and raytracing: HighRes construction screen and a colorful output in parallel.

But as always: Commodore was stupid.

[chb]

Originally Posted by Gorf

I have to oppose that:
I don't think it was meant for am extra gfx-card, with separate VRAM, but for the use of VRAM as Chip-RAM. Hence the use of the RGA-bus.
It would add not too many additional traces on the motherboard to support VRAM and than only some glue-locig and a second "head" (simple VideoDAC/Vidiot) is required.
With just one Bitplane no CLUT is needed and you can perform all usual Blitter operations on that.

After thinking about it again I suppose you're right, the whole setup makes only sense when chipram = vram (or at least a part of it). I guess it works the following way:

1) VRAM is essentially DRAM with a second serial port where it can output the contents of a serial register/buffer (which contains one row, so e.g. 1024 bits). Both ports can be accessed independently. The DRAM port looks like an ordinary DRAM. To transfer a row the serial buffer, the row address is supplied on the DRAM interface (like a normal read access to DRAM), while an additional signal on another pin tells the chip to copy that row to the buffer.

2) Now Agnus(?) puts $07A* on the RGA bus at the beginning of a line; that probably is used by some logic to put the VRAM in transfer mode. Then the bitplane address value for the current scanline is put on the address bus, so that row is transferred to the serial buffer. The VRAM interface starts reading the serial bits and puts them to the DAC/output pins.

3) The syncs for the video out are still generated by the ECS chipset, the VRAM interface can be very simple.

There's some more information about BEAMCON0

DUAL
Run the horizontal comparators with the alternate horizontal beam
counter, and starts the UHRES pointer chain with the reset of
this counter rather than the normal one. This allows the UHRES
pointers to come out more than once in a horizontal line,
assuming there is some memory bandwidth left (it doesn't work in
640*400*4 interlace mode) also, to keep the two displays synced,
the horizontal line lengths should be multiples of each other.
If you are amazingly clever, you might not need to do this.

It looks like there are two horizontal beam counters, so the VRAM display could use different line length than the normal one. There need to be some free memory cycles to put the row address for the VRAM display on the bus mid-scanline, hence the remark about hires 4 planes (where there is no bandwidth left).

As there is only 1 bitplane pointer, either it was meant to support monochrome only, or there was going to be some sort of "chunky" format (maybe 2 or 4 bit). The A2024 supported 4 grayscales, so one could think they would not have wanted less than that (and many programs were not well adapted to only 2 colors). But the term "bitplane pointer" indicates the opposite.

*$078 for sprite; not sure how it works; documentation says it comes out 2x every line, so probably just 2 single words nothing VRAM specific?

[Gorf]

1) VRAM is essentially DRAM with a second serial port where it can output the contents of a serial register/buffer (which contains one row, so e.g. 1024 bits). Both ports can be accessed independently. The DRAM port looks like an ordinary DRAM. To transfer a row the serial buffer, the row address is supplied on the DRAM interface (like a normal read access to DRAM), while an additional signal on another pin tells the chip to copy that row to the buffer.

That is for every single VRAM-IC as far as I unterstand.
So on a 16-bit system (in DRAM-Mode) you would use eg. 16 ICs in parallel - if you use 1Mbit chips, that would give you 2MB Chip-RAM...
So you would have also 16 serial-lines of VRAM, outputting 16 pixels at a time
(or less e.g. two pixels in 8-bit chunky mode)

that would probably go into a shift register in the video-DAC.

3) The syncs for the video out are still generated by the ECS chipset, the VRAM interface can be very simple.

exactly - and that why we need two signals per "line" - see explanation below.

As there is only 1 bitplane pointer, either it was meant to support monochrome only, or there was going to be some sort of "chunky" format (maybe 2 or 4 bit). The A2024 supported 4 grayscales, so one could think they would not have wanted less than that (and many programs were not well adapted to only 2 colors). But the term "bitplane pointer" indicates the opposite.

*$078 for sprite; not sure how it works; documentation says it comes out 2x every line, so probably just 2 single words nothing VRAM specific?

I guess "line" still refers to the Denise lines. But that are only about 200 for a 60Hz screen. But we would not want a 1024x200 screen on the second output.

But wait: didn't we fetch 16 pixels at once? Right!

So actually we feed enough data for 16 monochrome lines in each Denise-line
Or 2 lines of 8-bit-chunky ... but that would leave us with with a 1024x400 resolution...

So we need an update mid-Denise-screen: that finally gives us a SVGA like 1024x800@60Hz (or more Hz with less lines) in 256 colors.

But what is with the CLUT???

fortunately many videochips from that era were able to load all CLUT entries from VRAM as well, so you just have to put them on the serial line at a given time - no registers needed.

PS:
I actually do not know the exact configuration of these VRAM-ICs but I guess on a 32bit system like the A3000 you would use e.g. 256k*4 ICs - 8 of them in parallel to provide 1MB in 32-bit ... but that would give you probably also just 8 serial lines ... still enough.

For the second part of the 2MB Chip-RAM you could use traditional DRAM to save costs

[chb]

Originally Posted by Gorf

That is for every single VRAM-IC as far as I unterstand.
So on a 16-bit system (in DRAM-Mode) you would use eg. 16 ICs in parallel - if you use 1Mbit chips, that would give you 2MB Chip-RAM...
So you would have also 16 serial-lines of VRAM, outputting 16 pixels at a time
(or less e.g. two pixels in 8-bit chunky mode)

that would probably go into a shift register in the video-DAC.

True, I conveniently forgot about that.

Originally Posted by Gorf

I guess "line" still refers to the Denise lines. But that are only about 200 for a 60Hz screen. But we would not want a 1024x200 screen on the second output.

If you refer to the sprite pointers: They come out twice in every UHRES cycle (so two sprite addresses for one BPL address). So one can speculate if this a classic 2 bpl sprite or a 32 pixel wide 1 bpl sprite.

Originally Posted by Gorf

But wait: didn't we fetch 16 pixels at once? Right!

So actually we feed enough data for 16 monochrome lines in each Denise-line
Or 2 lines of 8-bit-chunky ... but that would leave us with with a 1024x400 resolution...

So we need an update mid-Denise-screen: that finally gives us a SVGA like 1024x800@60Hz (or more Hz with less lines) in 256 colors.

I think that updating mid-Denise-scanline* is really only necessary in dual mode. As far as I understand, the Denise screen in dual mode uses the traditional PAL/NTSC timings only. The new ECS registers for variable sync are used in dual mode for the UHRES timing. If DUAL bit is not set, I guess both displays share the same timing: Either classical PAL/NTSC or the new variable modes, used e.g. for productivity or Euro72 and the like. Hence, it shouldn't be a problem to generate an ECS non-VRAM 1024-line-mode, with low x resolution of course (like 320*1024).

From my understanding the fact that the UHRES pointer can come out mid-scanline means not necessarily that the additional data is needed; sync and datafetch may be simply hardwired together.

I am also not sure if UHRES really was meant for higher color depth; while the bandwidth would have been there, from what I see it would have been a chunky mode of some sorts. There is AFAIK nothing in the OS preparing for such a mode until OS 3.1, which is strange when they put support for UHRES into ECS from 1990 on. OTOH, b/w is really not well supported on the Amiga, at least four colors/greyscales is rather the minimum. Still scratching my head what they intended to use it for.

* actually, it can happen nearly everywhere in the Denise scanline, as the line lengths do not have to be multiplies of each other (even though they should). I guess reloading the VRAM 4x per Denise line would have been possible, too.

[pandy71]

A2024 is same class device as DCTV, Graffiti, HAM-E & HAM-E Plus and similar - Video Port is used as 4 bit data port. UHRES is something else - this is real extension to OCS - and based on all informations it is not clear if this feature is implemented in ECS/AGA or not (or implemented partially).
I can imagine many different ways to improve usage of already existing memory cycles - real case is: did UHRES works or not...? AGA introduced possibility to bypass internal CLUT and output plane data directly on 8 bit video out - perhaps UHRES was similar idea - not clear.
Usage of VRAM looks also valid - VRAM is internally equipped with R/W shift register (SAM) thus combination chipset logic and external VRAM glue logic may be sane way to implement UHRES without severe penalty on OCS/ECS/AGA memory bandwidth (VRAM can perform R/W on regular bus and independent R/W cycle on SAM), CLUT is also not a problem as VRAM are equipped with dedicated CLUT. I could imagine for example 1.75MB DRAM CHIP + 0.25MB VRAM CHIP visible to system as continuous 2MB CHIP RAM and combined in external logic or provided as 2 independent video outputs.
There is lot of unanswered questions on UHRES...

[chb]

Originally Posted by pandy71

A2024 is same class device as DCTV, Graffiti, HAM-E & HAM-E Plus and similar - Video Port is used as 4 bit data port.

Yes, but the A2024 has it's own memory for a complete frame (unlike Graffiti etc.) and it is VRAM-based, so it might have been an related for UHRES or some parts of it were supposed to be used in the external UHRES logic. The A2024 has an own custom controller chip by Commodore (MOS Technology 390562).

But let's have a look at the timeline: The A2024 came out in 1988, the earliest ECS Agnus 8372A chips (AFAIK Agnus generates all the video syncs, not Denise, so there's nothing UHRES related in the latter) were produced also already in the 10th week of 1988 (according to this facebook post).

Of course we do not know, but IMHO it's reasonable to assume A2024 and UHRES were somehow related, given the similar specs and the time frame. Whether the one inspired the other (or the other way round), or if they were both descendants of a Ranger project, who knows? That UHRES stuff in Agnus is really old, it may still have originated from the Los Gatos team, and maybe Commodore just left it in because they wanted the additional chip mem range and a redesign would have been more costly than a few unused transistors on the die.

Originally Posted by pandy71

UHRES is something else - this is real extension to OCS - and based on all informations it is not clear if this feature is implemented in ECS/AGA or not (or implemented partially).

To me it looks like it is implemented in ECS/AGA. That means, it is not useful without external logic. But you can probably test it:
Start a blitter job that takes all available cycles. Measure the time it takes once with UHRES enabled and once without. As far as I understand, UHRES will take three additional dma cycles per scanline (1x bitplane, 2xsprite) that won't be available to the blitter, more if DUAL is enabled in BEAMCON0.

Best would be of course a logic analyzer on RGA and address bus.

Originally Posted by pandy71

I can imagine many different ways to improve usage of already existing memory cycles - real case is: did UHRES works or not...? AGA introduced possibility to bypass internal CLUT and output plane data directly on 8 bit video out - perhaps UHRES was similar idea - not clear.

Most likely UHRES has nothing in common with the AGA CLUT bypass. That one looks more like a testing mode and is not terrible useful IMHO.

Originally Posted by pandy71

Usage of VRAM looks also valid - VRAM is internally equipped with R/W shift register (SAM) thus combination chipset logic and external VRAM glue logic may be sane way to implement UHRES without severe penalty on OCS/ECS/AGA memory bandwidth (VRAM can perform R/W on regular bus and independent R/W cycle on SAM), CLUT is also not a problem as VRAM are equipped with dedicated CLUT. I could imagine for example 1.75MB DRAM CHIP + 0.25MB VRAM CHIP visible to system as continuous 2MB CHIP RAM and combined in external logic or provided as 2 independent video outputs.
There is lot of unanswered questions on UHRES...

VRAM itself doesn't have anything like a CLUT, the video controller would have to take care of that. It could read the CLUT from VRAM, tho, but I doubt that there would have been one; first because of the chunky issue, second because a CLUT at the very high frequencies needed (>60 MHz) is harder to manufacture than a simple direct output (b/w or fixed palette).

[Toni Wilen]

Second post in this thread appears to be correct. It is seems to be really simple way for Agnus to send few words of data/scanline to some external device using RGA + data bus. Perhaps the main point was to make it copper controllable. I don't see if having anything to do with chip ram, all the actual graphics data is located on external device, Agnus only basically sends start address, one for graphics, one for sprite per scanline. (Perhaps it was designed to be memory mapped in CPU address space, using VRAM)

Sort of like Opalvision, it has simple "copper" that can do few basic operations per scanline that affects how graphics data in onboard VRAM is shown.

I can check if UHRES "registers" appear on RGA using my logic analyzer connected A500 (assuming it is implemented in 8372A Agnus) Both RGA + chipset side data lines are connected.

I always thought "UHRES" wasn't even implemented or that those words appear during refresh cycles and won't affect timing but if they really use actual cycles, it will make a difference and needs at least partial emulation support

[Gorf]

@Toni

What exactly would speak against the theory "VRAM=ChipRam" in this case?
For the rest of the chipset it would make no difference to use VRAM as it would appear as usual DRAM - a second "head" could be using the second port of the VRAM chips.

[pandy71]

Originally Posted by chb

Yes, but the A2024 has it's own memory for a complete frame (unlike Graffiti etc.) and it is VRAM-based, so it might have been an related for UHRES or some parts of it were supposed to be used in the external UHRES logic. The A2024 has an own custom controller chip by Commodore (MOS Technology 390562).

Don't mix two things - A2024 need few frames to create larger bitplane with lower refresh rate - as such it is mandatory to use internal frame buffer. MOS Technology 390562 is glue logic - patent http://www.freepatentsonline.com/4851826.html cover most of details - it can be implemented as CPLD, FPGA, PAL or discrete.

Originally Posted by chb

But let's have a look at the timeline: The A2024 came out in 1988, the earliest ECS Agnus 8372A chips (AFAIK Agnus generates all the video syncs, not Denise, so there's nothing UHRES related in the latter) were produced also already in the 10th week of 1988 (according to this facebook post).

Well - it need some time to develop product and i doubt that A2024 and similar devices share something with UHRES beside traditional pursue of higher resolution (case of Atari ST - main Amiga competitor where 640x400 @70Hz was so popular and efficiently gained lot of market).
Yes, Denise address some aspects of sync generation but it is controlled by Agnus.

Originally Posted by chb

Of course we do not know, but IMHO it's reasonable to assume A2024 and UHRES were somehow related, given the similar specs and the time frame. Whether the one inspired the other (or the other way round), or if they were both descendants of a Ranger project, who knows? That UHRES stuff in Agnus is really old, it may still have originated from the Los Gatos team, and maybe Commodore just left it in because they wanted the additional chip mem range and a redesign would have been more costly than a few unused transistors on the die.

Don't think so, A2024 can work also on OCS

Originally Posted by chb

To me it looks like it is implemented in ECS/AGA. That means, it is not useful without external logic. But you can probably test it:
Start a blitter job that takes all available cycles. Measure the time it takes once with UHRES enabled and once without. As far as I understand, UHRES will take three additional dma cycles per scanline (1x bitplane, 2xsprite) that won't be available to the blitter, more if DUAL is enabled in BEAMCON0.

There is no pin's on Denise and/or Agnus thus i could imagine additional IC connected to RGA and other signals (logic + sync/clk + data and address bus)

Originally Posted by chb

Best would be of course a logic analyzer on RGA and address bus.

true

Originally Posted by chb

Most likely UHRES has nothing in common with the AGA CLUT bypass. That one looks more like a testing mode and is not terrible useful IMHO.

Perhaps, CLUT bypass for sure simplify additional hypothetical signal modifier (as A2024 and HAM-E and similar devices)

Originally Posted by chb

VRAM itself doesn't have anything like a CLUT, the video controller would have to take care of that. It could read the CLUT from VRAM, tho, but I doubt that there would have been one; first because of the chunky issue, second because a CLUT at the very high frequencies needed (>60 MHz) is harder to manufacture than a simple direct output (b/w or fixed palette).

Second (like 44C251) and later generations of VRAM's are equipped with CLUT, Write Mask, Block Write and even in some additional primitive graphic operation (such as Clear, Block Copy etc) - UHRES could use second generation thus no external CLUT required - Video DAC as on AGA (or even plain resistor DAC a.k.a Vidiot) would be sufficient.

[Gorf]

I don’t think the color registers in VRAM are working as a CLUT ... at least I can not imagine how this should work...

Here is a description by IBM that makes more sense:

Color Register
The Color Register stores the color data for one or more screen colors. This data is then written to memory locations in the DRAM corresponding to the portions of the screen that will use the stored color. Color Register data is primarily used to rapidly store the color data associated with large areas of a single color, such as a filled polygon.
For example, to fill the polygon, the fill color is stored in the Color Register. Then, using Block Write, all of the memory locations that make up the polygon's area are written with the fill color data.

http://personal.ee.surrey.ac.uk/Pers...as/vrmsgrm.pdf

Edit:
Yes it is like the description says: these "color registers" are just a fancy fill mode ... 4-bit wide pattern of any kind, not just color.

See datasheet for the 44C251:
https://img.ozdisan.com/ETicaret_Dosya/8560_3213072.pdf

But as said before: I think to remember some videochips being able to load their clut entries via vram automatically...

[Toni Wilen]

Originally Posted by Gorf

What exactly would speak against the theory "VRAM=ChipRam" in this case?
For the rest of the chipset it would make no difference to use VRAM as it would appear as usual DRAM - a second "head" could be using the second port of the VRAM chips.

I didn't mean it can't use VRAM chip ram, only that Agnus UHRES stuff does not depend on chip ram in any way (except if copper is used to update UHRES registers)

I still don't think it would have used vram chip ram. It would only make sense if Agnus had direct VRAM support. In that case UHRES registers could directly control which row of VRAM is going to output port instead of using RGA hack.

[Gorf]

Originally Posted by Toni Wilen

I didn't mean it can't use VRAM chip ram, only that Agnus UHRES stuff does not depend on chip ram in any way (except if copper is used to update UHRES registers)

I still don't think it would have used vram chip ram. It would only make sense if Agnus had direct VRAM support. In that case UHRES registers could directly control which row of VRAM is going to output port instead of using RGA hack.

Agnus does have that control: by putting the address on the address-lines and triggering some glue logic via RGA it would tell the VRAM which ROW to store in the SAM registers.
Without any additional pins or further modifications on Agnus.
Sure it is kind of a hack or workaround, but wouldn’t that be typical for Commodore?

[Toni Wilen]

Right, I guess it could have been possible..

AGA.guide also mentions same address space (5 + 15 bits) that normal Agnus DMA channel registers also have and because it says 15 (not 16), even data width is same.

Or perhaps someone simply copy&pasted those

[Toni Wilen]

Ok, some quick logic analyzer test results:

At least 8372A Agnus does have some kind of UHRES "support".

If BPLCON0 bit 7 is set and

If UHRES sprite line is active (line is between values in registers $1d0 and $1d2), $78 will appear twice/scanline in RGA bus.

Same with UHRES bitplane (registers $1d4 and $1d6). $7a will appear one/scanline in RGA bus.

Locations does not seem to match documentation because it is always between refresh slots and it will steal cycles from copper.

[ref][78][ref][7a][ref][78][ref] (both bitplane and sprite enabled, bitplane 7a gets replaced with usual idle 1fe cycle if disabled, same with bitplanes)

Unfortunately data bus does not change at all during those cycles (previous data is kept). I am not sure whats going on or if UHRES is actually not really fully implemented after all..

DUAL etc.. later..

[chb]

Thank you very much for testing! Did you also set bit 9 in DMACON to enable UHRES dma?
http://amiga-dev.wikidot.com/hardware:dmaconr

Originally Posted by Toni Wilen

If UHRES sprite line is active (line is between values in registers $1d0 and $1d2), $7a will appear once/scanline in RGA bus.

Same with UHRES bitplane (registers $1d4 and $1d6). $78 will appear twice/scanline in RGA bus.

Hmm, according to the documentation $78 belongs to sprite and $7a to bitplane, and sprite should appear twice and bitplane only once. But maybe they got it mixed up?

EDIT 2:
Also from docs (BPLHPTH/BPLHPTL):

When UHRES is enabled, this pointer comes out on the 2nd 'free' cycle
after the start of each horizontal line. It‘s modulo is added every
time it comes out. ’free' means priority above the copper and below
the fixed stuff (audio,sprites….).
BPLHDAT comes out as an identifier on the RGA lines when the pointer
address is valid so that external detectors can use this to do the
special cycle for the VRAMs, The SPRHDAT gets the first and third
free cycles.

Seems to match your measurements, AFAICS. Maybe they simply did not put any data on the bus, as it is not needed for row->SAM transfer, only the address?