Apple IIe MouseCard/screen emulation is wrong

[colinleroy]

The Apple MouseCard is supposed to fire interrupts synced on VBL (cf https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Interface%20Cards/Digitizers/Apple%20Mouse%20Interface%20Card/Documentation/Apple%20II%20Mouse%20Technical%20Notes.pdf for example).

However, doing so flickers a lot when using the mouse interrupt as VBL detection, even when it should not:
https://www.youtube.com/watch?v=NJsZvI407XI

On the contrary, emulating a IIc or IIgs never flickers, even when the drawing is too slow to stay ahead of the beam.

None of those situations are ideal and make debugging more complicated than it should be. I workaround the issue by using the $C019 softswitch on IIe, but that's not great.

I would love to help fix it, but have so far no idea where to look for what to fix.
Thanks!

[rb6502]

Hi Colin,

The Technical Notes mention that the mouse card can generate either 50 or 60 Hz interrupts via a setting, but they don't say the interrupt is synced to the actual vertical blank anywhere that I'm seeing. I'm not even sure how that would work, as there are no video-related signals on slot 4 where the mouse typically was installed.

I guess it's possible that the 6502 firmware polls $C019 on a IIe and tries to sync it that way, but first we need to determine if the interrupts are really synced on a IIe (or II Plus, for that matter).

-RB

[peterferrie]

The card polls $C019 on the IIe, or vapor-lock on the II+, as a best-effort starting point. It really is trying to sync.

…

On Wed, 16 Apr 2025 at 18:05, R. Belmont ***@***.***> wrote: Hi Colin, The Technical Notes mention that the mouse card can generate either 50 or 60 Hz interrupts via a setting, but they don't say the interrupt is synced to the actual vertical blank anywhere that I'm seeing. I'm not even sure how that would work, as there are no video-related signals on slot 4 where the mouse typically was installed. I guess it's possible that the 6502 firmware polls $C019 on a IIe and tries to sync it that way, but first we need to determine if the interrupts are really synced on a IIe (or II Plus, for that matter). -RB — Reply to this email directly, view it on GitHub <#13598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWSFM3ZVQWBHLGRCEGA6C32Z344BAVCNFSM6AAAAAB3JLL3TOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJRGM3TSMRVHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> *rb6502* left a comment (mamedev/mame#13598) <#13598 (comment)> Hi Colin, The Technical Notes mention that the mouse card can generate either 50 or 60 Hz interrupts via a setting, but they don't say the interrupt is synced to the actual vertical blank anywhere that I'm seeing. I'm not even sure how that would work, as there are no video-related signals on slot 4 where the mouse typically was installed. I guess it's possible that the 6502 firmware polls $C019 on a IIe and tries to sync it that way, but first we need to determine if the interrupts are really synced on a IIe (or II Plus, for that matter). -RB — Reply to this email directly, view it on GitHub <#13598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWSFM3ZVQWBHLGRCEGA6C32Z344BAVCNFSM6AAAAAB3JLL3TOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJRGM3TSMRVHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rb6502]

If it does that, then it should just work in MAME.

[colinleroy]

If it does that, then it should just work in MAME.

And yet, it doesn't.

I have questioned my sanity over that, and I have questioned Apple engineer's sanity. I made schematics with theories:

I have sent the binary that you saw running under MAME in the video linked in the issue and I got, so far, two different persons telling me "I do not see any flickering and yes it drawn clearly.", "I don't see any flickering at 60Hz, also the puck moves SO SMOOTHLY".

Which is why I think something is wrong with MAME, and would love some help figuring it out. I have a theory but I don't really want to go on a multiple-evenings-long sidequest blindly, one of them is this comment in apple2e.cpp:

m_screen->set_raw(1021800*14, (65*7)*2, 0, (40*7)*2, 262, 0, 192);

I also see nothing related to the screen in src/devices/bus/a2bus/mouse.cpp.

This does not seem to take into account the stretched cycle. Could it be a lead?

Thanks in advance.

[colinleroy]

Maybe another lead, MAME outputs warnings from the a2bus/mouse PIA:

[:sl4:mouse:a2mse_pia] Warning! No port CB2 write handler. Previous value has been lost!

[colinleroy]

Finally, but this proves about nothing as these are also not the real hardware, AppleWin and Virtual][ don't show this behaviour and my code does not flicker when ran by thoses emulators.

[rb6502]

We don't emulate the stretched cycle, but we don't emulate it for either the CPU or the video generation so vapor lock and CPU/video cycle sync work.

AppleWin and V][ make no attempts to emulate the actual mouse card hardware so that's not useful data, as you surmised.

[rb6502]

Oh, and CB2 on the PIA is not connected, as per the schematic on A2DP.

[rb6502]

Try setting the 68705 clock to 1021800 in mouse.cpp. That seems to make the cursor smoother in Apple II Desktop, and the schematic shows both the microcontroller and the PIA are connected to the slot's phase 0 so I'm not sure why it was double that before.

[colinleroy]

Thanks. I tried that, and it doesn't really help.
I've patched MAME to verbosely log the RDVBL reads, the PIA, and the MCU, and... I don't really know what to do with it :/

Does this log give you any idea ? Right after the "RD VBLBAR 80" is when, I suppose, the firmware should tell the PIA that should tell the MCU to reset its timer?

Thanks in advance!

log.txt

pia_mcu_verbose.patch.txt

[colinleroy]

Adding a bit more log in m6805_timer::update, I see no timer reset either at the end of the VBL polling. I suppose that's at least part of the problem ?

...
RD VBLBAR 80
RD VBLBAR 80
[:sl4:mouse:a2mse_mcu] PORTC is unset
[:sl4:mouse:a2mse_mcu] m_tdr 216, m_source 0, prescale 10, m_divisor 0, decrements 10, interrupt 0 <=
RD VBLBAR 80
RD VBLBAR 80
RD VBLBAR 80
RD VBLBAR 80
RD VBLBAR 80
[:sl4:mouse:a2mse_mcu] PORTC is unset
[:sl4:mouse:a2mse_mcu] m_tdr 206, m_source 0, prescale 10, m_divisor 0, decrements 10, interrupt 0 <=
RD VBLBAR 80
RD VBLBAR 80
RD VBLBAR 80
RD VBLBAR 00
[:sl4:mouse:a2mse_mcu] PORTC is unset
[:sl4:mouse:a2mse_mcu] m_tdr 196, m_source 0, prescale 10, m_divisor 0, decrements 10, interrupt 0 <=
[:sl4:mouse:a2mse_pia] PIA port B read = 04
[:sl4:mouse:a2mse_pia] PIA port B read = 04
[:sl4:mouse:a2mse_pia] PIA port B write = 0C DDRB=3e
[:sl4:mouse:a2mse_mcu] PORTC is unset
[:sl4:mouse:a2mse_mcu] m_tdr 186, m_source 0, prescale 10, m_divisor 0, decrements 10, interrupt 0 <=
[:sl4:mouse:a2mse_pia] PIA port B read = 0C
[:sl4:mouse:a2mse_pia] PIA control A write = 00
[:sl4:mouse:a2mse_pia]  - CA1 interrupts disabled
[:sl4:mouse:a2mse_pia]  - CA1 interrupts active on high-to-low transition
[:sl4:mouse:a2mse_pia]  - Port A DDR register selected
[:sl4:mouse:a2mse_pia] PIA DDR A read = 00
[:sl4:mouse:a2mse_pia] PIA DDR A write = FF (output mode)
[:sl4:mouse:a2mse_pia] PIA port A write due to DDR change = 50 DDRA=ff
[:sl4:mouse:a2mse_pia] PIA control A write = 04
[:sl4:mouse:a2mse_pia]  - CA1 interrupts disabled
[:sl4:mouse:a2mse_pia]  - CA1 interrupts active on high-to-low transition
[:sl4:mouse:a2mse_pia]  - Port A Data register selected
[:sl4:mouse:a2mse_mcu] PORTC is unset
[:sl4:mouse:a2mse_mcu] m_tdr 176, m_source 0, prescale 10, m_divisor 0, decrements 10, interrupt 0 <=
[:sl4:mouse:a2mse_pia] PIA port A read = 50

Edit: Sorry, there's one just ten lines after, it goes back to 255.

[rb6502]

I'm going to have to read up on how the timer works on the 68705, but it probably auto-repeats if you don't do anything.

[cuavas]

The 68705 timer is working. We’ve got lots of nasty test cases for it. The Zorba keyboard and Xain’d Sleena MCU were particularly nasty to get right. It isn’t free-running like the 68HC05 timers.

[cuavas]

Edit: Sorry, there's one just ten lines after, it goes back to 255.

That’s correct, it triggers an interrupt when it passes zero and continues to count down, wrapping around to 255. This allows the software to determine how long it was from when the timer triggered to when it the interrupt is serviced. This is important for things that use it to generate asynchronous serial timings (like the Zorba keyboard does), etc.

[cuavas]

OK, after looking at the schematics, I noticed the 6821’s CB1 is tied high, but we haven’t hooked this up in MAME. It’s worth giving that a shot just to eliminate it as a possibility. Try setting it in device_start:

void a2bus_mouse_device::device_start()
{
	// register save state variables
	save_item(NAME(m_port_a_in));
	save_item(NAME(m_port_b_in));
	save_item(NAME(m_last));
	save_item(NAME(m_count));

	m_pia->cb1_w(1); // tied high via 10k resistor
}