|
Post by willymanilly on Jan 22, 2018 12:06:17 GMT
I've just uploaded a first release of the d030 test program to csdb. I'm focusing on exploring the Test Bit behavior of the D030 register now. Z64K is not perfect yet but it's getting closer. csdb.dk/release/?id=161586
|
|
|
Post by willymanilly on Jan 14, 2018 22:50:04 GMT
Thanks. I've got plenty to keep me going regarding testing using my PAL system and I'm hoping everything I discover applies to NTSC as well. I've started doing tests with the D030 testbit and applied some of what I've found to the newUI of Z64K. When I get time I will draft a document that consolidates my observations of the D030 register. I've attached an updated test program with source that includes additional tests for the testbit. Attachments:d030test.prg (3.5 KB)
d030test.asm (24 KB)
|
|
|
Post by willymanilly on Jan 14, 2018 22:42:34 GMT
The keyboard support has been very challenging, especially for keyboards with limited keys on them. I still need to do a lot of work on internationalization of the newUI. I will look into creating a virtual keyboard at some point but for now the physical PC keyboard can be configured via the keyboard editor under the tools menu. I also plan on including full language support in the future. At the moment I am only using Google translate so I will be asking for contribution from native language speakers to assist with proper translation.
|
|
|
Post by willymanilly on Jan 8, 2018 14:20:40 GMT
I've updated the test programs with some interaction (see 6 January post). It should be pretty self explanatory what keys do what but happy to clarify any questions. The source was created using my incomplete inbuilt Z64K assembler so you might need to modify the code to work in other assemblers if you want to modify the code. (note: Z64K's assembler has known bugs so I wouldn't recommend using it for your own projects yet. Use at own risk.) The new program automatically detects PAL/NTSC. I would be very grateful if someone can run the provided 2mhztest.prg file on a real NTSC 128 and post screenshots similar to the above table. Thanks in advance.
|
|
|
Post by willymanilly on Jan 5, 2018 23:35:15 GMT
|
|
|
Post by willymanilly on Jan 5, 2018 10:27:08 GMT
I'm referring to the NTSC128 demo when I mention "blocky line". (see second image below). 3 Lines to right of image in demo NTSC128 (screenshots from Z64K) Blocky line to left of image. I've had confirmation from NTSC 128 users that both of variations sometimes occur. I'm assuming during program initialization it sometimes unintentionally misses a few cycles causing the corrupt graphics to the left or right of the image. I'd be very interested on your result of running the NTSC128 demo.
|
|
|
Post by willymanilly on Jan 4, 2018 21:50:55 GMT
Sorry to hear you almost fried your VDC! I think there are much less options to kill your VICIIe or monitor by messing around with 2Mhz mode or the test bit. From what I know the horizontal frequency of the VICIIe is set and cannot be changed by software. The vertical frequency can be manipulated by using the test bit of $d030 though. I only have a real PAL (8566) version of the C128D to test with so I wrote the test program only for PAL. It should be easy to modify it for NTSC as you pointed out by changing the cycle counts. My VICIIe implementation in Z64K uses the discussed behavior for both PAL and NTSC. NTSC128 demo available at CSDb uses the VICIIe at 2Mhz speed and displays correctly in Z64K (newUI) so the above principles seem to apply for NTSC as well. I have confirmed that the NTSC128 demo works on real NTSC 128's by users that own one. Note: NTSC128 sometimes displays a very blocky line to the left or 3 lines to the right of the image. The NTSC users confirmed this happens on their real NTSC machine as well.
|
|
|
Post by willymanilly on Jan 2, 2018 22:34:33 GMT
I wont really get time to look at your code for a few days at least, but Im very happy that you are going down this particular route. Its one of the C128's avenues of research that I had wanted to explore at some point. Please do keep up the good work. Well done so far! The test program was a quick and dirty but gave me the results I was looking for. When/If I get time I want to write a proper test program. I plan on doing a similar tests for the test bit of $d030. If you do end up exploring the VICIIe 2Mhz behavior please keep me in the loop with what you discover.
|
|
|
Post by willymanilly on Dec 28, 2017 1:34:51 GMT
I just discovered why the symbol after the @ symbol is white on a real C128 in the first test program. It's because the C128 does not immediately release the bus for the VICIIe when going back into 1Mhz mode so the c-access is actually part of the instruction directly after setting the d030 2Mhz mode flag back to zero. In this case the instruction is STA $d021 (8D 21 D0 in memory) so it uses the lower nybble of 21 which becomes white. I have tested this theory by putting another instruction directly after the d030 write and the color changed exactly as expected (I tested with STA $d00x to change to color x). Another note is the last line of the test program is actually the internal VICIIe bus values. It sets itself to 255 when not in use. The @ symbol represents the 0 being writen to d030. The 0 also colors @ symbol and also the 2nd symbol to the left of the @ symbol. I've updated the newUI of Z64K to have this exact behavior. ( www.z64k.com) You can try with the current test program by using another value to reset the d030 flag to 1Mhz mode, making sure bit 0 and bit 1 are set to 0. For example LDX #$08, STX $d030 changes the symbol @ symbol to a 'h'. It also changes the color of the 'h' and the 2nd character to the left of the 'h' to color 8 (orange). Changing to LDX #$04 makes the symbol a 'd' with color 4 (cyan). I will write a better interactive test program when I get time but for now you can just poke 8221,x (PAL) or poke 8224,x (NTSC) before running the 2Mhz.prg test program, with x being the value you want to write to $d030. My 6502 assembly skills are not the best so I'd welcome anyone willing to write one as well.
|
|
|
Post by willymanilly on Dec 28, 2017 1:04:20 GMT
Hehe, well done! You are soon ahead of the demo makers! It would actually be great to see demo makers making demos for the C128. I'm sure there's still many more undocumented features to be explored and exploited.
|
|