Posted By
Litwr
on 2005-09-28
03:56:23
|  emulators bug
Can somebody test next sequence on a real +4 a few times? If anybody could do this, please write down for me the value at $d8 after the break. I've found very tricky bug common to ALL emulators, but without real hardware I cannot easily fix it. So I need your help.
Press SPACE (only SPACE) to stop the program.
2000 lda#$40
2002 cmp$c6
2004 bne$2002
2006 cmp$c6
2008 beq$2006
lda$ff08
sta$d8
brk
|
|
Posted By
Litwr
on 2005-09-28
03:57:53
| Re: emulators bug
By the way Does anybody know about presence of port of CPU TEST-SUITE for C64
PC64 emulator for our +4 or something like it?
|
|
Posted By
Crown
on 2005-09-28
14:24:17
| Re: emulators bug
$d8 has #$ff on the real machine and both in Vice and Yape...
What else did you expect and why?
|
|
Posted By
Litwr
on 2005-09-29
02:20:12
| Re: emulators bug
Thanks. Try to run Turbo Assembler 6.0 (converted from C64 by csory) notes. This Hungarian notes wait for SPACE key activity. I tried hit space in the any emulator but without any effects. I analyzed its code and found that it reads $FF08 without previous write to it. Standard IRQ kbd sequence places $ff to $fd30 in the its end - this means for all emulators that in $ff08 will be latched $ff. I wanted to test real hardware to prove one my hypothesis. Your results show that another hypothesis required.
|
|
Posted By
Crown
on 2005-09-29
06:22:36
| Re: emulators bug
Thanks, I've fixed this now in Vice...
The issue was that the keyboard status is latched at reading $ff08 not at writing it. So any change after the last $ff08 write was not went through to the emulator.
|
|
Posted By
Crown
on 2005-09-29
06:50:09
| Re: emulators bug
Standard kbd irq only puts $ff into $fd30 when it is doing a full scan, but before it does that, it checks if any button is pressed at all writing $00 into $fd30, and that's the state this particular program expects. Full scan is only performed if this particular check come back as any key being pressed.
When you are not touching the keyboard, the standard keyboard routine writes the following sequnce into $fd30 at every frame
$7f $7f $00
at every 5th frame it writes
$7f $7f $7f $7f $00
This is probably when it checkes for repeating keys...
The turbo assembler instuctions actually turns off the writing of the $7f $7f sequences, and the irq only writes $00 into $fd30 at every frame. Most likely it turns off keyboard repeating, I believe there is a zero page or low memory area variable where you can turn that off...
|
|
Posted By
Gaia
on 2005-09-29
18:49:24
| Re: emulators bug
Latching on reading FF08 is somewhat surprising, as all sources claim the exact opposite (ie. latching on writing to FF08). Make sure Laser Squad's main selection menu still works after you have fixed VICE.
|
|
Posted By
Crown
on 2005-09-29
20:02:28
| Re: emulators bug
Yeah, I've realized that double checking it on the real hardware....
By the looks of it, this software should not work at all on the real hardware.
|
|
Posted By
Gaia
on 2005-10-03
08:39:44
| Re: emulators bug
Crown: how did you check? I double checked, too, and it really looks like latching occurs at writing a value to $FF08 and not at reading. Until a new value is written to $ff08 it will just read back the last latched result even if you update $fd30.
|
|
Posted By
Crown
on 2005-10-03
10:17:16
| Re: emulators bug
Yes that's what I meant too, that latching happens on write, it was just a little bit confusing the way I put it...
There was tough one test where the read out value changed after a while on a button press, sometimes it was enough to press one button sometime it needed more buttons pressed at one, but I need to investigate that further to see what is happening.
Back to the particular program, it should not work, beacuse it basically just loops on a $ff08 read, and its interrupt rutine calls the ROM keyboard handling directly. The ROM keyboard handling only writes $00 to $ff08 when it checks if there is any button pressed, and if one is pressed than it goes through the full keyboard scan, and the last written value to $ff08 and $fd30 is $ff, so basically it should never be able to detect a button press....
If this runs on a real hardware than thats something really strange...
|
|
Posted By
Gaia
on 2005-10-03
10:59:32
| Re: emulators bug
Ah well, I have totally misinterpreted your words then  I thought you were referring to Laser Squad as non-working I agree that would be something close to a magic if this Turbo Assembler intro worked on the real thing...
|
|
Posted By
Litwr
on 2005-10-05
03:57:20
| Re: emulators bug
Can anybody test these notes at real +4? I don't have any cbm hardware since 1991 so I cannot do this. 
|
|
Posted By
TLC
on 2005-10-06
14:57:27
| Re: emulators bug
Guys, the answer is that the $ff08 latch is broken in some TEDs. These TEDs don't latch the keyboard input ports at all, the value you read from $ff08 is straightly the current state of the P0-P7 lines of the TED, regardless if you wrote the register before or not.
(If you connect a joystick to the computer, and find that you cannot select between Joy0 and Joy1 (you don't see 5,R,6,D,T or 3,w,4,a when moving the joystick while the computer is on), then you probably have such a TED in the computer) .
There have been problems with at least one version of Laser Squad because of this same bug, as I remember. On some computers, the game worked, on others: it didn't. I presume Csory must have had such a broken TED in his computer.
|
|
Posted By
Gaia
on 2005-10-07
06:40:48
| Re: emulators bug
TLC: I knew you would know the right answer On the other hand... there are at least 3 TED revisions known (the prototype R0, of which we have a data sheet, R1 and R2). I wonder if this very bug have been fixed in R2? Anyway, R1 TED's are rather rare and I could yet only find them in C16's.
I have one such C16 machine with a (working!) TED 8360R1, so I will test this latch thing on that, too.
|
|
Posted By
TLC
on 2005-10-07
14:53:26
| Re: emulators bug
Nope, this hadn't anything to do with revisions; I also received my C16 with a working 8360R2, that I could transform once to this kind of "non-latching" 8360R2 in a minute or so  . The process didn't take more than once soldering the joystick with an instant soldering iron, while the joystick was connected to the computer |-D . ...The problem was caused by electric shocks. Bad joysticks, badly interfaced C64 joysticks and the like... AFAIK, Solder/Syn even sold something like a "TED protector"... with which one could have possibly avoided such accidents...
|
|
