|
Post by willymanilly on Sept 8, 2018 9:23:46 GMT
This is amazing work! More knowledge of the inside of the VDC is very welcome. Especially the vblank bit! I totally failed to get smooth horizontal scrolling working. With lots of effort I got vertical smooth but could never crack horizontal. Smooth horizontal scrolling does seem bit of a challenge and part of my experiments will be to find out exactly at what point the VDC latches the display and attribute pointers because they do affect the smooth scrolling. As you're probably very familiar with, if you get the timing wrong the scroll is more than likley to jitter very noticeably.
I've attached a simple program where smooth horizontal smooth scrolling works on my real PAL C128D. I've provided source code with comments for more information.
Attachments:vdcsmoothx.zip (945 B)
|
|
|
Post by willymanilly on Sept 5, 2018 22:26:02 GMT
There has been the "VDC-Raster-Demo" in 128er Sonderheft 95. You can find the disk-image here: www.idealine.info/emuecke/index_quereinstieg.htm?/emuecke/sonderheft_128.htmAlthough, the author apparantly did not know that each VDC has a slightly different timing. I was able to have this run nicely on my newer C128, but not my old 128D. Either way, he is using raster-interrupts. The magazine itself and the disk-image also has a small demo-creator for these raster effects, but without the timing-correction, this is only good for some machines. Regarding the tests above: Never seen the lightpen-registers used and don't know how accurate they are. For my little VDC 8x1-demo I just used the VBLANK-bit of $d600. Although this is fired only once per frame, maybe you can get more exact results with that? VDC Risen From Oblivion also has a nice raster effect as well hence why the speed test at the start of the demo is required to determine exact timing so it works on multiple machines.
The lightpen register seems quite accurate, at least on my C128D. With the VBLANK-bit method alone I usually get about a 12 character jitter which is OK in most instances. With the additional lightpen check I reduce it to about a 2 character jitter with the standard VDC 80 column mode. This is what is expected when running in ~1 MHZ mode because the VDC draws ~2 characters/CPU cycle. Not sure if this can be improved because even setting the CPU to fast mode, the CPU still goes back to 1Mhz mode for the DRAM refresh cycles and reading/writing to IO. Maybe Z80 has a way to reduce the jitter...
Using the lightpen register I've been able to write some tests to get some insight in how the internal timing of VDC works including the busy status bit in register $d600. I will share them soon when I make them a bit more user friendly and where they can demonstrate meaningful results.
|
|
|
Post by willymanilly on Sept 5, 2018 21:53:28 GMT
IIRC, the commercial product, Colorez 128, was able to do that. I just checked that product and it seems to only copy the character data to bitmap which gives the illusion that the screen is split between text and bitmap. Still a good trick though.
|
|
|
Post by willymanilly on Sept 3, 2018 15:31:08 GMT
Has anyone ever explored splitting the VDC screen into a bitmap and text modes similar to what can be done the VICII?
I've done some preliminary testing to see if it can be done and am using the VDC lightpen register triggered by the CIA to assist with removing as much jitter as I can as an attempt to get a stable raster.
I'm not sure if is is possible to remove the jitter totally because of the different clock the VDC uses compared to the rest of the computer but I'm getting promising results.
Attached is a simple test program I'm working on which I welcome others to build upon.
At the moment there are only 5 tests available by pushing keys 1-5
1. Change background color at trigger point 2. Change from mono text ==> mono bitmap at trigger point
3. Change from color text ==> color bitmap at trigger point
4. Change from mono bitmap ==> mono text at trigger point
5. Change from color bitmap ==> color text at trigger point
Other keys:
A - shifts trigger point to the left. *
D - shifts trigger point to the right. *
X - exits the program
*note: trigger point can be shifted off screen to next raster line.
You should be in 80 column mode and enusre there is text on the screen before running the program to see best results. I plan on updating the program in future to automatically configure the screen to show text.
I have not been able to get a jitter free screen for Test 4 or 5.
Test 2 and 3 are jitter free by default on my PAL c128D. Other machines might need to adjust the trigger point by using keys A and D. I would be interested in results from other setups and welcome any suggestions on how to further reduce the VDC jitter.
I've done a lot of updates recently to the VDC emulation in Z64K to support more features and screen modes but there seems to be a lot more to explore to get it perfect.
See source for more information on how the test program works and feel free to ask me any questions.
Test 1
Test 2
Test 3
Test 4 (Unstable - can't remove jitter)
Test 5 (Unstable - can't remove jitter)
Attachments:vdcsplit.zip (3.45 KB)
|
|
|
Post by willymanilly on Aug 28, 2018 1:17:20 GMT
Thanks for your feedback.
Regarding the 40/80 indicator, it's toggling correctly. I think the issue might be because the color of the OFF LED is more obvious than the color of the ON LED. I can see now how the OFF LED color could be confused as the currently selected option indicator. I'll look into some more obvious colors for this.
|
|
|
Post by willymanilly on Jul 31, 2018 3:03:58 GMT
As promised I've uploaded a new version to the website that has command line options to start the emulator with dual screens and 80 column mode. In summary the 2 extra options are:- -80 -dualscreen eg. java -jar Z64K.jar c128 -80 -dualscreen will start the C128 emulator with dual screens and 80 column mode enabled in the main screen.
|
|
|
Post by willymanilly on Jul 30, 2018 14:56:59 GMT
Yes, there are some command line options to be able to start with your choice of emulator and to autostart programs. The VICE test repository makes good use of this and you can look at the Z64K specific testbench scripts there for good examples of what commands Z64K supports.
The option for emulator are [atari2600|c64|c128|vic20]. eg java -jar Z64K.jar c128 will start Z64K using the C128 emulation.
To autoload a program you only need to include the complete path and name of the program you want to run in the command line. The program needs to end with .prg.
You can also insert disks and cartridges using the complete path and name of the disk image/crt image.
Snapshots can be loaded without the need of the emulator type option and will automatically restore Z64K with the correct emulator and settings.
An example of a batch file I use on windows to assign .zsf files (Z64K snapshot files) to Z64K is as follows. You could create batch files to do custom startup of Z64K including starting in C128.
@echo off start javaw -jar -Dsun.java2d.uiScale=1.0 C:\Users\William\IdeaProjects\Z64K\out\artifacts\Z64K_jar\Z64K.jar -snapshot %1 exit Some other useful command line options relevant to C128, most having the same functionality as VICE for consistency, are:-
-pal -ntsc -ntscold -warp -ciamodel [0|1] -sidenginemodel[256|257] -snapshot filename.zsf -go64
-8 filename.[d64|d71|d81|g64] -cartcrt filename.crt
I haven't included a command line option to enable 2nd screen on startup yet but I will include it in the next release. While I'm thinking of it I will include an option to select 40/80 column screen on startup as well.
An example command line option to start Z64K in C128 mode and run a program is java -jar Z64K.jar c128 E:\testprogs\c128\d030tester\d030tester2.0.prg
I will eventually document all the undocumented features of Z64K. I hope the above makes enough sense to be useful at this stage but please let me know if you need me to clarify anything I said above. I will let you know when I include options to enable 2nd screen at startup. One workaround to start with 2 screens is to create a snapshot image with both screens enabled and just load that snapshot on startup...
|
|
|
Post by willymanilly on Feb 2, 2018 23:42:34 GMT
All the links I've provided are just for peoples information. I use those programs along with many others for testing the emulation accuracy of Z64K. I've already confirmed VDCDUMP shares the results of the author of the program on my real hardware. It is always useful to get other peoples results but I have no real need for it at this stage. VDCDUMP should be run in 40 column mode so it doesn't mess with the VDC memory during test. The test does take a long time to complete, seemed like an hour from memory on real hardware. I warp it on Z64K. I've actually just fixed the memory mapping of Z64K when using the 16/64 Ram configuration bit of register 28 to allow it to successfully run VDCDUMP (each test has a result of OK 64K, same as real hardware). I still need to do some more testing to make sure it hasn't broken anything else but I will upload a new version of Z64K soon with the fix. That will probably be when I get back home on Monday though.
|
|
|
Post by willymanilly on Feb 2, 2018 21:26:07 GMT
Z64K has only 64KB VDC physical ram option. When in 16KB mode via register 28, Z64K simply masks the address with $3fff. A real c128 does not mask the address that simply hence you will witness the behavior that Pyrofer describes above. The actual mapping is detailed in the vdcdump test program I linked to in my previous message. It's on my to do list to fix in Z64K.
Thanks for the source to your program. I will use it as another test program to compare results between my real c128 and Z64K.
I'm currently researching the behaviour of to d030 register and implementing what I find into Z64K. I plan on writing similar test programs for VDC in the near future including timing of the ready bit. The behavior of the ready bit is partly implemented on Z64K but should not be relied on yet
|
|
|
Post by willymanilly on Jan 27, 2018 19:50:16 GMT
Bit 4 of register 28 is not fully emulated yet when in 16K mode on Z64K. There is a test and some information on VICE's test repository here ==> sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VDC/vdcdump/ Z64K passes 3 out of 4 for the test. I know the fix and it's something on my list to do. I suspect it has something to do for the reason why the screenshots you provided don't match. If you upload any program that has different behavior on Z64K compared to the real thing and you are happy to share, it would very useful for me to improve the VDC emulation. Tokra's images from VDC mode mania and VDC VGA mania are the reasons why I was able to get Z64K's VDC emulation to where it is now. I'm glad you find the inbuilt assembler useful. You should note though it is incomplete and I know of a few bugs that need to be fixed but for simple programs it is functional. I will release information on all assembler options once I find time to get rid of all the bugs and update the assembler functionality. For now it's a use at your own risk category but in saying that I've been using it for my programs. The latest source code for d030 tester uses the inbuilt Z64K assembler and can give you some hints on what options are available. csdb.dk/release/?id=161586
|
|