Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minor 6522 issues #652

Open
tomcw opened this issue Jun 3, 2019 · 7 comments
Open

Minor 6522 issues #652

tomcw opened this issue Jun 3, 2019 · 7 comments
Labels
bug

Comments

@tomcw
Copy link
Contributor

@tomcw tomcw commented Jun 3, 2019

Cross-referencing with 6522 datasheet:

  1. TIMER2's mode is defined by ACR.bit5 (not bit7-6 like TIMER1).
  2. TIMER2 modes are one-shot and counting pulses on PB6.
  3. TIMER2 only has a low-order latch (T2L-L), unlike TIMER1 which has both high & low-order latches.
  4. TIMER1/2 decrements. "Upon reaching zero, an interrupt flag is set ..."
    • so an interrupt is generated for a transition from 0x0001 -> 0x0000 (currently AppleWin does it on underflow from 0x0000 -> 0xFFFF).
    • but the timing diagram for one-shot mode (fig. 15) shows the interrupt generated after N+1.5 cycles or midway through 0xFFFF. (The timing diagram for free-run mode (fig. 16) doesn't show T1 values.)
    • so AppleWin accounts for the extra cycle (due to underflow at 0x0000 -> 0xFFFF), but should only generate the IRQ on 0x0000 -> 0x0001?
  5. What if TIMER1 is loaded with 0x0000. Is this equivalent to 0x10000?
@tomcw tomcw added the bug label Jun 3, 2019
@Archange427

This comment has been minimized.

Copy link

@Archange427 Archange427 commented Jun 4, 2019

Just my 2 cents, very poor technically but could be related to your fourth point:
On the ORIC scene, they usually set a delay minus -2 to define a precise timing for interrupt.
You can find a reference to this here:
http://forum.defence-force.org/viewtopic.php?f=25&t=1816&start=15#p17131
Ok it's just forum's gossip, with not technical reference...
I remember reading something about that behavior at the time but I can not find where anymore.
And it's been several days that I'm looking for (funny to see you're wondering about this particular point). Without success...
I'm pretty sure it came from Twilighte (a real genius on the ORIC scene).
But impossible to find the reference for the time being.

You should maybe have a look at the source code of ORICUTRON, the best emulator.
Maybe the part on the VIA would bring you information on this point (if this "-2 behavior" is implemented).

@Archange427

This comment has been minimized.

Copy link

@Archange427 Archange427 commented Jun 4, 2019

Another thought:
can you test the program I sent you that display a visual use of the CPU during a PT3 track on a real machine ? (I am unfortunately no longer able to do)
If the start of the display is NOT stable but move forward or backward, it will probably mean that the delay I used is not good and therefore that the timing used by AppleWin to generate the IRQ is not the right one.
If the display is stable, either everything is OK or so delay and IRQ timing are both not good but neutralize themselves ;)

@tomcw

This comment has been minimized.

Copy link
Contributor Author

@tomcw tomcw commented Jun 4, 2019

can you test the program I sent you that display a visual use of the CPU during a PT3 track on a real machine ?

Yes, I want to (and will) do this.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

@tomcw tomcw commented Jun 14, 2019

OK, I have tested this TEST_INT_SYNC.zip (test.dsk) on a real Apple IIe (6502, 50Hz PAL). NB. Not enhanced, so not 65C02.

You can see (from the attached pictures) that the interrupt is not sync'ed with the display and the white "interrupt time" gradually moves (slowly) down the screen. The fact that it moves slowly means that it's very close the correct interval.
DSC00044

NB. I tried this same test.dsk on AiPC (v0.1.42.1, PAL/50Hz mode), and it is stable on that emulator... therefore the emulator is wrong!

So I hex-edited test.dsk and changed the PAL interval to 0x4F36 (was 0x4F38), and it's now stable on my PAL Apple IIe. (NB. I first tried 0x4F37 and that was not stable either.)

@tomcw

This comment has been minimized.

Copy link
Contributor Author

@tomcw tomcw commented Jun 14, 2019

But why -2 ?!

If you look at the 6522 datasheet (mine is Rockwell), Fig.18 "Timer 2 one-shot mode timing" shows that !IRQ OUTPUT goes low (active) after N+1.5 cycles. Perhaps this is rounded up to 2?

If interrupt in AppleWin really occurs between $0000 and $FFFF... why -2 more ?!!

Well I think AppleWin is wrong, and the interrupt should occur from a $0001 -> $0000 transition.

And then there's this extra 0.5 cycle from the 6522 datasheet.

btw. I can only tested on a PAL Apple IIe, but since it looks like this is an artifact of the 6522, then it should be true for NTSC Apple IIe too. But it would be good to ask someone with an NTSC Apple II + Mockingboard to verify this.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

@tomcw tomcw commented Jun 15, 2019

@Archange427 - new AppleWin 1.28.7 here: fixes this issue where the 6522 TIMER's period is actually N+2 cycles (and also fixes Sather's "Little Text Windows").

Precise 6522 frame intervals are:

  • NTSC: $4284
  • PAL: $4F36 (verified on a real Apple IIe)
@tomcw

This comment has been minimized.

Copy link
Contributor Author

@tomcw tomcw commented Nov 4, 2019

  1. What if TIMER1 is loaded with 0x0000. Is this equivalent to 0x10000?

No. I checked this on a real (original) //e, and the T1 interrupt occurs immediately. And T1C=0xFFFF takes the longest time to underflow. This was for both FRT and one-shot modes.

tomcw added a commit that referenced this issue Nov 10, 2019
. Changed to 6522.TIMER underflowing at 0x0000 -> 0xFFFF (#652)
. Changed MB_Update() to be based on cycle delta (was TIMER1 interval)
  . this improves support for small 6522.T1C interval
  . removed MB_GetFramePeriod()
  . removed overly-complex dual-timer support
. Replaced MB_EndOfVideoFrame() with MB_PeriodicUpdate()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.