|
Post by Pyrofer on Sept 26, 2019 8:22:49 GMT
Oh nice! Thats awesome work. Thanks so much for this Also, I assume .c64 files are created for c64 images from cc65 etc.
|
|
|
Post by Pyrofer on Oct 4, 2019 19:02:10 GMT
so I finally have a demo that works on Z128K but not on real hardware!
Or at least not on my hardware. I am not sure exactly what the issue is but I think it's the VDC busy flag clearing too soon on the emulation? I can let you have the .prg if you promise not to spoil the surprise of the demo I am working on...
|
|
|
Post by willymanilly on Oct 4, 2019 22:21:06 GMT
so I finally have a demo that works on Z128K but not on real hardware! Or at least not on my hardware. I am not sure exactly what the issue is but I think it's the VDC busy flag clearing too soon on the emulation? I can let you have the .prg if you promise not to spoil the surprise of the demo I am working on... The VDC busy flag emulation in Z64K is getting is reasonably close to real hardware behavior but I know it's still far from perfect. It's something I have on the top of my list to create more tests for and improve. I'll PM you.
|
|
|
Post by remark on Apr 25, 2020 14:08:49 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
|
|
|
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 remark on Apr 28, 2020 14:00:24 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. Your reply made me think . Lets make R2=0,R35=0,R34=25 and see what happens. Now I know where CCKL 0 is (between A an B): (CCKL=Character clock) Translating this to normal timing:
The VDC starts fetching the first character/bitmap data in CCKL 5 and displays it in CCLK 8.
|
|
|
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 c128old on Feb 1, 2021 8:43:13 GMT
Other than VDC: request on the REU. Using Z64K I find that an attempt to do DMA to/from REU, is using the CPU bank. However, real hardware is using the VICbank D506 value (bits 7 and 6) to select the DMA-target.
I'm setting up code in bank0 and the set VIC DMA to use bank1, so that when I finally set FF00 to 'no rom no IO' I get data to/from bank1.
One more little thing I would ask: behavior of some Z80 instructions. Currently these jump to the monitor, can the GUI allow to select which instruction(s) switch to monitor and which don't?
- halt (76h) makes sense to sync to an interrupt,
- ld a,i (ed57) makes sense to detect if interrupts are enabled - in a,(*) (db) makes sense for isolated IN
To put the above in perspective: Usecase halt and ld a,i:
In the cpmfast code (from Linards Ticmanis), the capslock/din key is checked. This uses a 8502 routine in the keypolling. For cpu switching we must disable interrupts and doing that 'close' to the rs232 timing will break it. The speed of polling that key is subjective user experience: not timing critical. Linards put a counter in to test at low speed. Also interrupts mustn't be enabled in the key-check routine (which is also called as a side-effect of regular output).
To stay away from rs232 interrupts: If interrupts are enabled (use ld a,i to test as a user-program may have disabled them) then wait (halt) before testing the capskey-line. Usecase ld a,* + in a,(*): For isolated D505 checks, or DD00 reads: ld bc, $d505 + in a,(c) takes 5 bytes and (10+12) cycles. Improve: ld a,$d5 + in a,($05) takes 4 bytes and (7+11) cycles and does not touch BC.
|
|
|
Post by bjonte on Feb 1, 2021 11:11:54 GMT
Other than VDC: request on the REU. Using Z64K I find that an attempt to do DMA to/from REU, is using the CPU bank. However, real hardware is using the VICbank D506 value (bits 7 and 6) to select the DMA-target. This is used in Volley For Two, so the replays will be broken when REU is activated in emulation.
|
|
|
Post by willymanilly on Feb 1, 2021 20:30:45 GMT
Thanks for the bug report, especially for the information on the REU issue for Volley For Two. I was wondering where I needed to start looking to get replays working. I will apply a fix sometime this week.
|
|