I am not sure is this forum a proper place to ask my question. However I would be happy to get some help. A link to the best Apple II forum can be the last remedy for me.
I am doing some coding for the Apple II. I need a timer which is provided by the mouse card. My code works on MAME emu but it doesn't work on other emulators (microM8, jace, and AppleWin). It seems that microM8 has problem with the mouse support, it can't run Mouse Paint. So it is possible that my problems with microM8 and other emus are caused by the emu bugs.
I do the next steps in my code:
1) disable interrupt;
2) seek the mouse card page;
3) call INITMOUSE;
4) call SETMOUSE with AC=8;
5) set interupt vector at $3fe to my handler;
6) enable interrupt.
This works for the Apple IIe/IIc/IIgs which are emulated by MAME/MESS. However this doesn't work for the Apple II+. It seems that a call to a mouse card function changes memory bank at $2000 on the Apple II+.
I am not sure, if my program can work on a real Apple IIe/IIc/IIgs or not. It would be great if someone could try to run this program on real hardware. Thanks a lot in advance.
I have attached an archive which contains a boot-disk image (DOS). Sources are available on GitHub. To run the program just boot the disk or type RUN HELLO. Then select a proper driver. Then enter a number of digits, I suggest 100. If timer interrupts work the time of calculation will be printed in the end. If they don't work, 0 will be printed. You can rerun the program just with RUN.
BTW is it possible to accelerate the Apple II by disabling screen or something else?

_________________
my blog about processors

That's a bit puzzling, as I don't think I've ever heard of a non-slot0 card being allowed to mess with anything outside of $Cxxx.

I would love to try, but my genuine hardware is either buried in my 130°F attic or given away. I'm an AppleWin guy for now.

AFAIK, the II and II+ have no such provision. The video generation on those two is practically transparent anyway, with the tiny exception of one slightly stretched clock cycle from time-to-time (sorry, the details elude me at this moment, and I have to get to work).

Good luck in your little adventure!

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Thank you. The Apple II is a great architecture to learn.
BTW I've just tried to call SETMOUSE with AC=9 and interrupts start working on AppleWin. But this didn't help for microM8 and jace.

_________________
my blog about processors

I have just found another good Apple IIe emulator - https://sourceforge.net/projects/agatemulator/ - it starts interrupts also only if AC=9.

_________________
my blog about processors

On an Apple II+, the mouse card firmware will clear the memory from $2000 to $4000 in order to synchronize the mouse interrupt with the vertical retrace. As the Apple II+ doesn't have a direct way to check for vertical retrace, it uses a technique known as "vapor lock" to figure it out. It uses the high res graphics page, thus the clearing of $2000-$4000. The newer Apple II models don't use this technique as they can directly check for vertical retrace. Anyway, it can be a pain to keep your code and data away from $2000-$4000 when first calling the mouse card firmware (and it isn't really documented in any of the official manuals).

I needed to look into that 'vapor lock' method a bit. I found this
https://groups.google.com/g/comp.sys.ap ... -E_j_ADgAJ
which directs us to this telling:
https://www.folklore.org/StoryView.py?p ... e_Card.txt
and to this code and explanation:
http://web.archive.org/web/201510211203 ... /2015/vbl/
and this observation:
> Actually, the last-read video byte can be read from any "unconnected" soft switch address. This is the principle behind Bob Bishop's "vapor lock".

Thank you very much for this very interesting information. You know I have another problem around a value for the SETMOUSE call. So I dare to ask you. Is it correct to use AC=8 to activate VBL interrupts? Or I must use AC=9?


What an unusual way to work with VBL interrupts!

_________________
my blog about processors

If you aren't interested in mouse position or status, you *should* be able to get away with just mode 8. Mouse compatibility between all the Apple II models is sketchy at best, so you will want to test on each version.


Note that this is only used to initially set up the mouse card's h/w timer, synchronizing it to the VLB. Once set, the "vapor lock" technique isn't used again.

I've been toying with the Apple's VBLK signal, and hope I can tag onto this thread.

VBLK - the vertical blanking signal - is at the frequency of the display. This is either 50Hz or 60Hz. Is there a way to find out which it is, so you can count them, divide by the correct number, and get the correct wall-clock answer? ie, is there a way that executing code can find out what to set count to here to get 1.00sec:

LDX count
loop:
wait for VBLK
DEX:BNE loop

ta.

_________________
--
JGH - http://mdfs.net

In the absence of interrupt functionality, I think it might be easier to just count ~1,023,000 clock cycles, especially on an unadorned ][ or ][+.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I agree. Let me present an example of a delay loop for approximately 1s.

_________________
my blog about processors

But a) I want to do something else while waiting and b) with a clock accellerator that will execute faster than 1/50sec.

_________________
--
JGH - http://mdfs.net

The fault could definitely be at my end, but I somehow can't fully grok the scenario you're trying to describe. Until I get a better brain or a better description of the task, I'll have to defer to others.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

1) it is quite easy if you use a proper interrupt handler, your code will be something like

The interrupt handler may be something like this

However on the Apple II+/IIe you may need some more code.
2) IMHO it seems impossible to find out the proper vsync frequency with a loop if your CPU frequency is arbitrary. Maybe it is easier to check ROM difference to detect 50/60 Hz cases.

_________________
my blog about processors

I seem to recall people doing this by putting certain patterns in the graphics memory and then reading unmapped addresses or something similar where the "phantom" values that you read are related to what was just placed on the bus in the previous half cycle by the graphics system reading memory during Φ1.


I don't think there is any ROM difference. Page 10 of the Apple 2 Reference Manual gives instructions for converting an Apple II to PAL: you simply cut two X-pads and solder three O-pads. (I have also heard that you need a slightly different master crystal, but the manual doesn't mention that.)

This is obviously a bit of a hack, since you then get only B/W output, but this sort of cheap and cheerful thing is pretty typical of Woz.

I don't see anything else that would require a detectable ROM change for European versions, either. The keyboard has its own ASCII encoder, so there's no keyboard scanning routine to change, and likewise the character generator has its own ROM not readable by the CPU.

_________________
Curt J. Sampson - github.com/0cjs