|
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 bjonte on Sept 16, 2018 13:35:49 GMT
I have been attempting to use Z128K for game development for a while and my most urgent feature requests are:
Boot speed shortcuts. It takes 28 seconds to launch the emulator and get into the game now where it takes 2 seconds in Vice. Emulation in Vice isn’t much faster (47-56 Hz compared to 35-40 Hz in Z128K) so it is mainly because Vice can take shortcuts while loading, skip real drive emulation and use warp speed until the game starts.
Label and breakpoint injection from a file (using 17 bit addresses). This makes all the difference when debugging.
|
|
|
Post by willymanilly on Sept 16, 2018 15:20:40 GMT
Boot speed shortcuts. Label and breakpoint injection from a file (using 17 bit addresses). This makes all the difference when debugging. If you can provide an example of how you start the game, and inject labels and breakpoints into VICE, that would be a great help so I can implement the features in the same format for consistency between emulators. I know you've asked for this before but it just slipped off my radar.
|
|
|
Post by bjonte on Sept 17, 2018 17:42:06 GMT
If you can provide an example of how you start the game, and inject labels and breakpoints into VICE, that would be a great help so I can implement the features in the same format for consistency between emulators. Sure, I can tell you what Vice does. If you add ’-moncommands <file>’ as command line arguments to Vice it will execute all the commands in the file as monitor commands before launching anything. So, to set a breakpoint at an address add a line ’break exec C:4000’ or ’bk exec C:4000’ to break at $4000. ’C’ can be replaced with a device number to add a breakpoint in drive memory. In Vice this only handles 16 bits addresses and will break in both RAM banks, which isn’t desired. To add a symbol add ’add_label C:4000 .hello’ or ’al C:4000 .hello’. For some reason the name has to start with a punction mark. This needs to handle 17 bit addresses and I would like to skip the leading punction mark in the name. In the disassembler, all addresses are replaced with names, if existing.
|
|
|
Post by willymanilly on Sept 18, 2018 12:34:38 GMT
OK, I've added the -moncommands <file> command line option to Z64K. I have also updated the machine monitor breakpoint command to use the same format as you would use for VICE. The example you provided (’break exec C:4000’ or ’bk exec C:4000’ )should work now for setting breakpoints via a file. The C: is ignored at the moment and can be omitted but I will update the command to allow full device breakpoint control. It only handles 16 bit address but I will update it to 17 bits for the C128 soon. I will also add support for labels. This will be a little bit of extra work in the backend but it shouldn't be to hard to implement. Example of use that uses c128 emulator starting in c64 mode to setup a program at c000, run the program and exit back to monitor with a breakpoint. java -jar -Dsun.java2d.uiScale=1.0 Z64K.jar c128 -go64 -moncommands e:\test\breakpointtest.txtbreakpointtest.txt break c00a c:c010 a c000 sei ldx #$00 txa sta $0400,x inx bne $c003 inc $d020 jmp $c00a
cls d c000 c00d m c000 c00f g c000 m 0400 Please note all the commands are executed before the emulator starts so the m 0400 command shows the startup pattern instead of the values you might expect from running the program.
In the monitor if you enter m 0400 it will show the updated values by the program.
The g c000 sets the PC to c000 and only executes after all the commands in the file are executed. The g <address> command is the same as j <address>. Both set the cpu PC to a new address, only difference is g will exit the machine monitor if it was running and restart the emulation. You can use either j or g with a -moncommands file because the emulator will always start once all the commands in the file are executed.
All available monitor commands can be used in the -moncommands file but you should avoid using the cycle and instruction stepping commands for now. The machine monitor is not in the correct state to handle those commands correctly during startup.
Also note in the above example, the additional carriage return after the assembled program is required to terminate the assembler entry mode.
|
|
|
Post by bjonte on Sept 25, 2018 5:22:09 GMT
Really great stuff!
|
|
|
Post by willymanilly on Oct 13, 2018 5:54:38 GMT
Given the amount of updates and testing I've discussed lately with VDC emulation for Z64K, I've attached a preview version that implements most of those discoveries. I have also updated the CRT renderer to have an output closer to real hardware. It's still a work in progress.
In summary
I haven't completed testing yet so I'm only providing this as a preview. I still have some other VDC behavior I want to implement before releasing including the glitches displayed when the VDC runs out of cycles during fetching of character and attribute data.
The only thing I have noticed that doesn't work is mode 1 of Tokra's VGA mode mania doesn't sync correctly. It works in the currently released Z64K so hopefully it will be an easy fix. I haven't been able to any VGA modes on real hardware. Everything else I've tested including iPaint, Tokra's VDC mode mania, Rockfall VGA, Rockfall Interlace, gun fright, VDC demo, Risen from Oblivion, and all of Soci tests from the VICE test repository all work perfectly as well. Once I've completed testing I will upload an official release to my website. Any assistance with testing and letting me know of programs that work on real hardware but not in this unreleased version of Z64K is always welcome.
*EDIT. I found the minor bug and I've uploaded new version of unreleased Z64K which shows mode 1 of Tokra's VGA mode mania correctly. I also fixed another bug where the busy flag of the VDC would occasionally lock with the VGA mode mania modes and couldn't be unset even with at reset. This was caused during times where the screen became out of sync and the pixel buffer overflow wasn't properly captured. Everything that is working in the currently released version seems to be working in this unreleased version now but I still want to do some thorough testing before releasing on my website. I have updated the attachment with the fixes applied.
Z64Kunreleased.jar (2.02 MB) (Last updated 16 October 2018)
|
|
|
Post by willymanilly on Oct 14, 2018 9:15:21 GMT
Note: I've updated the above unreleased version of Z64K to include some fixes to the VBLANK time as discussed in 8x1 vdc mode trick thread. The solution to the fixes resulted in a simpler VDC model which I think is a good sign the emulation is getting pretty close to real hardware.
|
|
|
Post by willymanilly on Oct 16, 2018 4:35:37 GMT
I've updated the unreleased version of Z64K with a much simpler VDC model for 8 x 1 VDC mode trick. The timing and the screen positioning matches my real c128 with all tests I've thrown at it. I still need to implement the VDC glitches when it does not have enough free cycles available to fetch character and attribute data. I also need to do some very minor work to get the BUSY status flag cycle exact. Assuming no other issues are discovered, I will be releasing this version to the public to replace the currently released VDC emulation.
|
|
|
Post by bjonte on Oct 16, 2018 15:49:26 GMT
That sounds great!
|
|