|
|
Post by stiggity on Apr 18, 2022 3:32:01 GMT
The program functions well... until i attempt at adding a cursor. im using the $cd6f and $cd9f and other supplied routines. The problem is, when im using a cursor, i get _flicker_ in random positions on my screen. Almost like my irq handler isnt considering a cursoron/off call.. if anyone feels they know this area, and would like to help, I will supply any needed code.
|
|
|
|
Post by oziphantom on Apr 18, 2022 5:28:43 GMT
the VDC has a hardware cursor, so it shouldn't really go wrong.
you are just calling CSSRON once at the start right? and then using CRSR80 to update it position, and only when it is moved? OR you using BSOUT to "print" movement characters?
|
|
|
|
Post by stiggity on Apr 19, 2022 3:59:20 GMT
ozi:
I _was_ using a simple jsr $CAF2 during any getkey area, and everything was working just fine. But then, i began banking out kernal rom, and storing routines underneath. Everything works, but i get random artifacts/color alterations, random garbled characters on the screen. So, i looked at "Mapping the 128" and found another vdc cursor call $cd9f which is supposed to turn the cursor off. Well, i placed the call after the inkey routine, and it doesnt shut off. And i get random artifacts. If i remove the jsr $caf2 and jsr $cd9f the program operates perfect. In short, im using $ffd2 to send data to screen, but using $cdca to send characters, colors to the vdc screen map. All i really need is a generic cursor i can use at an input prompt. I'm starting to believe it is my IRQ handler... If it will help, i can post the routine.
|
|
|
|
Post by oziphantom on Apr 19, 2022 11:22:48 GMT
It all goes fine until I bank out the ROM, says to me you are calling the RAM under it when you think you are calling the ROM. which can cause very odd things to happen.
|
|
|
|
Post by stiggity on Apr 19, 2022 18:47:23 GMT
Yes... The cursor call hasn't been changed, but could there be anything i need to check for, or an address that needs preserved. I copied the $cdca/$cdd8/$cddc kernal calls, and they are 100% external. What kind of debugging would you recommend??
If the cursor calls are removed, there is no artifacts, everthing runs smooth. I do cehck the stack to see if its in the ($CD) area, if so i exit to IRQEND. If not, I write to the screen... i also noticed most of the artifacts, occur after a screen write.. Like, an Idle Timer. on it's last character stored to screen memory/color memory.
|
|
|
|
Post by c128old on Apr 19, 2022 19:48:24 GMT
this reminds me of the problems I had with VDC cursor during the CPM22 design.
I found an answer when I read the mapping128 (carefully ;-)
I wanted the 8502 part of CPM to show the VDC cursor when active and hide it otherwise.
The thing was the way the kernal VDC cursor routines work: they (also) restore the character under the cursor when you disable the cursor.
At cursoroff at cd9f, you need the Y reg to be filled with value stored in $EC so that the restore of the thing under the cursor is done in the correct position.
Maybe that helps in your case too?
LDY $EC ; active columnpos (needed for 80)
JSR $CD9F ; kernal CrSroff
|
|
|
|
Post by stiggity on Apr 19, 2022 19:57:54 GMT
Thanks a lot!! I will definitely attempt to repair this. I use that zp address, but wasn't aware of it usage during cursoff.. !!! gives me hope..
|
|
|
|
Post by wendling on Apr 20, 2022 5:25:47 GMT
All of the suggestions of the others might be true: I don’t know: I have no experience with the cursor. But what I do know is that when you use VDC-registers in an IRQ-routine you will get random artifacts.
Consider $cdcc:
stx $d600
L1:
bit $d600
bpl L1
sta $d601
rts
Random characters appear when an IRQ, that uses VDC registers, fires after stx $d600 and before sta $d601. The value in $d600 before the IRQ, is lost. The sta $d601 from $cdcc will write its value to the last VDC register used by the IRQ routine. If this happens while the c128-rom-editor sets the update address, characters show up at the wrong update location.
So $d600 needs to have the same value before and after the IRQ.
$d600 can’t be restored by reading its value: it gives the statusbyte. But it can be done with a trick:
The c128-rom almost always uses the X-reg to write to $d600 (only the BASIC command COLOR6 ($6a32) uses the A-reg and some init-routines at start-up). (A hunt for $d600 with the monitor: h f4000 fffff 00 d6 will show this.)
And with that X-reg $d600 can be restored:
At the beginning of each IRQ-routine the X-reg is stored on the stack (see $ff17).
Pull the X-reg at the end of the IRQ-routine from the stack and use it to restore $d600.
Like this:
tsx ; save stackpointer
pla ; value of $ff00 (see $ff33)
pla ; value of Y-reg
pla ; value of X-reg
sta $d600 ; restore $d600
txs ; restore stackpointer
Now can this go wrong? Yes it can: If you set/read VDC registers in your own program without using the c128 kernal routines. So then block the IRQ, or use the X-reg to set $d600 and then don’t use the X-reg until $d601 is set (because the IRQ resets $d600 everytime with the X-reg).
|
|
|
|
Post by stiggity on Apr 22, 2022 23:06:10 GMT
Wendling!!!!! Greets!! how the heck have you been?  I'm already using a modified IRQ handler, and I 100% copied the $cdca/$cdd8, put them in free RAM, and used the MMU to be certain each time one of those are called, the banking is right. But i wasn't aware that $d600 is lost each IRQ fire. Here's something else I'm worried about. Will ending my IRQ handler, using the snippet you posted, cause issues with the IRQ handler i was currently using?? I know you should see it, and i actually believe it's in a post on this forum... I'll look. Just a thought. |
|
|
|
Post by stiggity on Apr 23, 2022 7:22:16 GMT
Wendling!!
I've already written my version, but what would a routine look like that copies the $cdca/$cdd8/$cdda/$cdcc, kernal calls, and allows them too slip past the IRQ. All while preserving $d600/$d601?
Something tells me my version is, iffy..
thanks in advance!!!!!!!
|
|
