I've tried the mode you described in BASIC, but did not get better results than you did. By my thinking the mode you set up should have 192 bitmap-bytes (3 lines of 64 bytes) follwed by 64 attribute-bytes. But I don't even get that far, in fact using reg 27 in hires-mode seems to screw up the VDC. I've tried monochrome-mode and when I set reg 27 to $40 and try to write consecutive bytes they are duplicated in the picture (about 8 kilobytes later) and some bytes are even not written it seems. Totally unreliable results. I think reg 27 is only meant to be used in text-mode and the VDC can not handle it in hires.
r27 and bitmap is all weird if you set r27 to 0 above you will get a logic consistent image. I've been doing some more experiments to try and work out how it does wrong but it doesn't make any sense. For example the first row of bitmap data is always "correct". When it gets the 2nd row the bitmap data is correct for 112 bytes then it starts to read in attribute data. If you fix attribute data and then start change bitmap data well again the first row is right, but you get 2.5 rows before it start to get attribute data as bitmap data while bitmap data is used as attribute data.
Perhaps it’s a timing problem and perhaps the adding of reg27 takes many vdc-cycles every line. This gives the vdc less time to get the attribute data. Try higher attribute heights or less characters in reg1.
About the 16k, when reg1=64, reg27=64, reg6=64, reg9=2: Vertical = reg1 * (reg9+1) = 64 * 3 = 192 bitmaplines. Horizontal: on screen:64 bytes, in memory due to reg27: 64 bitmap bytes+64 skipped bytes=128 In 16k you have only room for 16k / 128 = 128 lines. For 192 lines you’ll need: 192 lines * 128 bytes = 24k. In 16k chips lines 128-191 will mirror lines 0-63. The 16k-mode with 64k chips gives you access to not 16k but 32k. The highbyte times 2 of a 16k-mode address gives you the address in 64k-mode. $3445(16k)=$6845(64k), $7000(16k)=$e000(64k)
The VDC is definitely one weird beast. I've had a quick look at this to see if I can work out what's happening.
In summary my observations so far for bitmap mode:-
If register 27 >0 increase the attribute latch value by 1.
After the first attribute row has been read increase the attribute pointer by (register 27)-2 if (register 27) >0 in addition to the normal increase of the attribute pointer by register 27.
I've updated Z64K's model (the new Version 2 only) with the above. Let me know if you notice it breaks anything else. On a side note this actually makes the VDC FLI image in Risen from Oblivion work without any hacks!
I'm guessing the other oddities are related to timing issues that wendling pointed out. They are not currently emulated. I will need to do a lot more testing to have enough info to be able to update the emulator model to show those.
This post has my interest and I definitely welcome other peoples insights to what is happening or any other test programs in bitmap mode with register 27 greater than 0.