|
Post by willymanilly on Feb 1, 2024 18:59:32 GMT
Thanks for all these tests and your observations. It seems even/odd cycles does have an impact if an extra z80 command is executed before switching to 8502. I've updated Z64K to match this model and all your tests including the 2-cycle difference on power up one behaves like real hardware now!
|
|
|
Post by willymanilly on Jan 30, 2024 8:22:04 GMT
Very interesting indeed! Z64K has been updated to match real hardware for majority of the tests. Only one where Z64K doesn't behave the same as real hardware is for the power up one where first run is off by 2 cycles on real hardware. ==>"A first run after power-on or reset gives consistently 2 cycles slower values..."
I've confirmed all tests on my real hardware as well.
|
|
|
Post by willymanilly on Apr 13, 2023 16:20:02 GMT
Now there seems to be a consistent 1 cycle difference with the original test and also 2 MHz modified test (result = 10.5058594). Earlier these were in precise agreement with real hw. Fixed in latest release. The 1 cycle off was related to when the CIA etc. responds to the Z80 port instructions.
|
|
|
Post by willymanilly on Apr 12, 2023 22:18:45 GMT
I've been able to improve Z64K's timing when 40 column mode is enabled without breaking anything. Z64K behaves like real hardware with fluctuating results now.
|
|
|
Post by willymanilly on Apr 11, 2023 16:33:36 GMT
With April 12th update Z64K seems to give a stable result (1 MHz, VIC enabled) 11.019043; real hw fluctuates a bit, but the average seems pretty close. I had to sacrifice a little bit of accuracy so other things didn't break. I have a hack in my development environment that fixes the minor timing issues and behaves more like real hardware without breaking anything else, but it is very messy at the moment and probably will not be accurate in other edge cases. More investigations will need to be done before I release a more accurate version.
|
|
|
Post by willymanilly on Apr 11, 2023 12:48:51 GMT
With another modification to keep VIC screen enabled
1020 DATA ...,A9,1B
. f2e1e a9 1b lda #$1b . f2e20 8d 11 d0 sta $d011 the result on real hw was 11.0185547 (there are small fluctuations).
This means the slow C128 z80 is even slower when using 40 column mode! I've tested on real hardware and got similar results. I've updated Z64K with the same behavior.
|
|
|
Post by willymanilly on Jul 13, 2022 10:08:08 GMT
As stated in Mapping the Commodore 128 taking note of the sentence in bold, the maximum number of active pixels per character horizontally is 8 pixels regardless of the total character width.
22 $16 Character horizontal size control Bits 0-3: The value in these bits determines how many of the total horizontal pixels in the character position will be used to display character pattern data. (The total number is specified in bits 4-7 of this register.) If the number of active pixels is less than the total number of pixels, the extra pixels will be blank for intercharacter spacing. If you specify a value here that is greater than the total number of pixels available for the position, only the specified total number of pixels will be visible. However, the value here should not exceed 8, since a maximum of eight bits are available per byte of character pat- tern data. Even for values greater than 8, no more than eight pixels will be active per horizontal scan line within the character position. For graphic mode, the value here should be equal to the total number of pixels; otherwise there will be gaps in the display. The default value for these bits is 8, for eight active horizontal pixels per character-position scan line. This is the same as the total number of pixels per position, so there will be no intercharacter spacing. (For the default character set, the rightmost column of each character pattern is left blank to pro- vide the effect of intercharacter spacing,) Bits 4-7: The value in these bits determines the width of each character position (in pixels). The value stored here should be one less than the desired total number of pixels. If the total is greater than the number of active pixels specified in bits 0-3 of this register, the extra pixels will be blank for intercharacter spacing. The default value for these bits is 7, for eight total pixels per character position. The total number of horizontal pixels is determined by multiplying the value here (plus 1) by the total number of character positions (from register 0/$00).
|
|
|
Post by willymanilly on Jun 30, 2022 17:33:41 GMT
One potential outcome of investing the behavior of pixel width less than 8 in single pixel mode opens the door to get a better understanding of how the VDC works internally. When pixel width is 7 I notice if register 36 is set to 10 (hex a) or above then a 4th corrupted column appears that affects the attribute data! The position of the corrupted columns are determined as follows. I'm assuming the "corrupted" data is what is currently on the VDC bus, probably from the DRAM refresh cycle. Column 0=0 (GFX) Column 1=45-((reg36&0xf)*2) (ATTR) Column 2=63-(reg36&0xf) (GFX) if (reg36&0xf)>9 Column 3=(DRAM1+48) (ATTR) Character data starts displaying in column 1. Cursor is offset by 2 columns. Attribute data starts displaying in column 0. I have implemented the above in Z64K. It still doesn't match real hardware behavior perfectly but it's getting close. 5 rem 7 pixels - press 0-9 or a-f to change dram refresh. 10 sys dec("cdcc"),dec("91"),0 20 sys dec("cdcc"),dec("75"),2 30 sys dec("cdcc"),dec("4a"),3 40 sys dec("cdcc"),dec("68"),22 50 sys dec("cdcc"),dec("46"),25 60 sys dec("cdcc"),dec("00"),36 70 get a$ 80 if a$="" goto 70 90 sys dec("cdcc"),dec(a$),36 100 goto 70
|
|
|
Post by willymanilly on Jun 26, 2022 21:52:23 GMT
I tested with register 4 with decimal 38 (hex 26) and register 36 (DRAM refresh) with 0 and I get a stable screen with @ in columns 0 and 63, and a blank column 45. With a DRAM refresh cycle greater than 0 those 3 columns flicker with "random" values. The attribute data seems affected with the flicker in the middle column of the 3 and the graphics data is affected in the other 2. The position of those columns depends on the refresh cycle value. I suspect they are artifacts from the refresh cycles. The same behavior is seen with the default of decimal 39 (hex 27) for register 4 on my system.
|
|
|
Post by willymanilly on Jun 25, 2022 23:22:42 GMT
I've done some playing around on my real hardware (c128D PAL with 1084S monitor) and it doesn't appear it's possible to get a stable picture in single pixel mode for a font with total pixel width less than 8 pixels. Anything with a total width less than 7 pixels only displays vertical lines that only appear briefly before the screen clears. They reappear whenever the VDC is written to. Total pixel width of 7 shows a corrupted screen with the cursor offset by 2 characters. Worse still it seems block transfer gets corrupted. The effects of this can be seen when listing a program that scrolls the screen. I'd also be interested if anyone has been able to get font widths <8 working in single pixel mode. I know there's a test in the VICE test repository with a pixel width of 6 that works in double pixel mode. I've updated Z64K to simulate some of the odd behaviors I've witnessed but more research will need to be done to determine exactly how the VDC is handling pixel width less than 8 in single pixel mode... 5 rem 7 pixels 10 sys dec("cdcc"),dec("91"),0 20 sys dec("cdcc"),dec("75"),2 30 sys dec("cdcc"),dec("4a"),3 40 sys dec("cdcc"),dec("68"),22 50 sys dec("cdcc"),dec("46"),25
5 rem 6 pixels 10 sys dec("cdcc"),dec("aa"),0 20 sys dec("cdcc"),dec("88"),2 30 sys dec("cdcc"),dec("4b"),3 40 sys dec("cdcc"),dec("58"),22 50 sys dec("cdcc"),dec("45"),25
5 rem 5 pixels 10 sys dec("cdcc"),dec("cc"),0 20 sys dec("cdcc"),dec("a3"),2 30 sys dec("cdcc"),dec("4f"),3 40 sys dec("cdcc"),dec("48"),22 50 sys dec("cdcc"),dec("44"),25
|
|