|
Post by willymanilly on Apr 30, 2020 23:05:32 GMT
What are the specifications of your C128? It's saying" Sorry, for you having no C128..." on my real C128D!
|
|
|
Post by willymanilly on Apr 29, 2020 22:54:48 GMT
This is awesome! Thanks for sharing. The data you are providing from the logic analyser is motivating me to review and improve Z64K's VDC emulation.
|
|
|
Post by willymanilly on Apr 27, 2020 23:51:52 GMT
It's taking longer than expected to get the Version 2 of Z64K ready to the point I'm happy to formally release it. In the mean I've decided to start uploading updates to the website. Link available here ==> z64k.com/resources/version2/Z64K.jar
|
|
|
Post by willymanilly on Apr 27, 2020 23:49:24 GMT
These results are very useful. Thanks for posting. I plan on revisiting the VDC emulation again soon so this all helps to improve it.
|
|
|
Post by willymanilly on Apr 27, 2020 23:48:05 GMT
willymanilly Where do you place the start of a scanline? I currently have a logic analyzer connected to the VDC and want to share some observations, but I don't know where the VDC 'starts from zero' on a scanline. If you decrease the value in R34 (Display enable begin), you see the left border 'growing'. With value 122 or lower you don't see any change at the left side of the screen. Would that be the start of the scanline? Or should i also take part of the blankingperiod in to account. What are your thoughts on this?
Edit: I actually mean rasterline instead of scanline
It's been awhile since I've played with the VDC so I will need to review my code and notes to be able to give an in depth answer. In a nutshell I have an offset of 7 character positions added to the internal character position counter to determine LPX when the light pen input is triggered. HBLANK is disabled/enabled when the internal character position counter matches the respective registers. A new scanline occurs when the internal character position equals VDC register 0.
|
|
|
Post by willymanilly on Mar 10, 2020 10:00:26 GMT
In my haste to reduce the size of the file I broke the IO extensions in the previous file I uploaded. I have now replaced it with a fixed version.
|
|
|
Post by willymanilly on Mar 10, 2020 9:05:29 GMT
I haven't touched base for awhile but I have not been neglecting doing updates to Z64K. It's been a challenge finding time to work on the emulator as much as I would like but I will be dedicating a substantial amount of time over the next few weeks to get version 2 of Z64K ready for release! I have most of the core features implemented but a huge amount of the options to access them are not available via the UI yet. Some of the notable inclusions is the monitor "bank" command( similar functionality as the VICE version), format disk via UI, and multi IO extensions support. There will be many more features that I will share closer to release date. Attached is a preview version. Please note the attached version is far from complete and I reduced the quality of some of the images and removed some features so it could fit into under the 1mb file limit this forum allows. Please note some options available in the UI aren't enabled yet and it's missing menu items etc but it will at least give you a nice sneak preview. The core emulation is fully functional but a lot the extra features the current version of Z64K has are currently disabled. Most new features people have requested over the years will be implemented before release, especially tools for debugging in the machine monitor. Watch this space.
|
|
|
Post by willymanilly on Feb 22, 2020 11:16:18 GMT
Quote from the Commodore Ram Expansion Unit Controller - 8726R1 Technical Reference Documentation.
"If a transfer is programmed for 0xFF00 trigger option, bit 7 of register 0xDF01 remains set to 1 and no DMA transfer takes place, until the trigger event happens. For this reason command execution could be taken back by clearing bit 7 of register 0xDF01, as long as the trigger event did not happen. The trigger gets activated by writing some arbitrary value into C64/C128 address location 0xFF00. For the C128 at this address location there sits the Memory Mapper Unit (MMU) which organizes different memory banks, ROMs and the I/O area within this computer. By using write to this memory location as trigger event, with one write access a decent memory configuration can be programmed and a transfer started just after that. With the next cycle available to the main CPU the former memory configuration can be restored. On the C64, the MMU (actually a simple 6-bit processor port) sits at address locations 0x00 and 0x01 which makes MMU programming and DMA execution not so smoothly combinable."
|
|
|
Post by willymanilly on Feb 22, 2020 10:55:51 GMT
On my 1084s monitor I get the same result as your attached image. I have noticed this behaviour before and have tried to emulate parts of it but I need to do more research. I removed it from bitmap mode emulation as a result of the discussion starting here. From your program it seems smooth x scrolling plays a part in the width of the black line at the right of the screen...
|
|
|
Post by willymanilly on Nov 30, 2019 2:31:02 GMT
As discussed here, apparently the order of writing to the update location VDC registers(18 and 19) seems to matter. Is that behaviour common knowledge? I've seen no mention of this in the c128 programmers reference guide or mapping the c128. Long story short expect data corruption with your VDC programs if you attempt to update VDC register 19 (least significant byte) before updating register 18 (most significant byte).
|
|