|
|
Post by oziphantom on Oct 22, 2020 9:37:42 GMT
Having a few issues with the VDC.
So if one sets the screen to be 64 wide, and offsets by 64 (i.e r27) and then places Bitmap at 0 and Attributes at 64. You get a perfect interleave of bitmap and attributes for a 64byte wide bitmap.
And in emulator this looks perfect
But on hardware you get So not only is bitmap data wrong in places, but it doesn't get the colour data correct for most of it either. Any ideas?
_values := [
(1,64),
(6,64),
(25,$c7), ; bitmap with attributes
(20,>kVectors.Screen),
(21,<kVectors.Screen),
(12,>kVectors.Bitmap),
(13,<kVectors.Bitmap),
(36,5), ; make sure we have DRAM refresh
(9,2), ; 3 pixel high chars
(4,103),
(7,90), ;32
;(28,16), ; enable 64K mode
(27,128-64)
] |
|
|
|
Post by tokra on Oct 22, 2020 13:02:09 GMT
Interesting :-) Can you post a full test-program to try out? For testing I always set reg 36 to 0 to minimize side-effects because of that. You can always go up later. Otherwise this "should" work. Looks like work for willymanilly  |
|
|
|
Post by oziphantom on Oct 22, 2020 14:19:04 GMT
|
|
|
|
Post by wendling on Oct 22, 2020 15:19:04 GMT
I see a semicolon in your values list before reg28, making it a comment.
In your testprogramm reg28 is missing where you set the registers.
So the vdc sees only 16k.
|
|
|
|
Post by oziphantom on Oct 22, 2020 15:22:31 GMT
its meant to be 16K
also VICE and Z64K are confiq for 16K when tested in.
|
|
|
|
Post by tokra on Oct 22, 2020 18:41:31 GMT
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.
|
|
|
|
Post by oziphantom on Oct 23, 2020 5:21:17 GMT
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.
|
|
|
|
Post by wendling on Oct 28, 2020 8:55:59 GMT
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. See these posts about vdc timings: c-128.freeforums.net/thread/600/vdc-raster-split?page=4About 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) |
|
|
|
Post by willymanilly on Nov 25, 2020 12:57:47 GMT
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.
Screenshot from updated Z64K
 |
|
