Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2797 > unrolled thread

Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-06-29 12:06 -0700
    Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael J. Mahon <mjmahon@aol.com> - 2016-06-29 14:17 -0500
    Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? "Mark D. Overholser" <marko@markoverholser.com> - 2016-06-29 16:11 -0700
      Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-06-29 17:17 -0700
        Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael J. Mahon <mjmahon@aol.com> - 2016-06-30 13:51 -0500
          Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-06-30 11:56 -0700
            Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? "Mark D. Overholser" <marko@markoverholser.com> - 2016-07-01 09:06 -0700
            Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael J. Mahon <mjmahon@aol.com> - 2016-07-01 12:15 -0500
              Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-07-01 12:34 -0700
                Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Antoine Vignau <antoine.vignau@laposte.net> - 2016-07-01 14:59 -0700
                  Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael J. Mahon <mjmahon@aol.com> - 2016-07-02 03:03 -0500
                  Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-07-02 10:21 -0700
                    Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? David Schmenk <dschmenk@gmail.com> - 2016-07-02 13:40 -0700
            Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? "Mark D. Overholser" <marko@markoverholser.com> - 2016-07-02 20:45 -0700
    Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ? John Brooks <jbrooks@blueshiftinc.com> - 2016-07-01 22:52 -0700
    Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c,Laser 128) ? Benoit0123 <bgilon@free.fr> - 2016-07-04 11:54 +0000
      Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c,Laser 128) ? Michael J. Mahon <mjmahon@aol.com> - 2016-07-04 18:48 -0500

#2797 — Benchmark / Profiling / Timing on real hardware (Apple //e, //c, Laser 128) ?

Let's say I want to benchmark my asm. code that slurps ##K off a custom RWTS.

How would I go about benchmarking / profiling / timing this on real hardware? 
Primary will be an enhanced Apple //e, along with optional Apple //c, and a Laser 128.

I don't mean at the granularity of clock cycle timing (I already have AppleWin's TRACE for that :-) and the 602 tables), but of the granularity of Seconds and Milliseconds.

Minimum second accuracy is required (maximum would be ~2 minutes).  Millisecond timing would just be a sweet bonus.

NOTES:

 * I just picked up another ThunderClock Plus so that is what I'm thinking will be the primary means of a clock source.

 * I also have the "No-Slot" option coming soon too ...
https://www.ultimateapple2.com/catalogzen154/index.php?main_page=product_info&products_id=70

I have not searched usenet / forums -- I'll do that later. :-)

TIA !
Michael

[toc] | [next] | [standalone]

#2798

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> Let's say I want to benchmark my asm. code that slurps ##K off a custom RWTS.
> 
> How would I go about benchmarking / profiling / timing this on real hardware? 
> Primary will be an enhanced Apple //e, along with optional Apple //c, and a Laser 128.
> 
> I don't mean at the granularity of clock cycle timing (I already have
> AppleWin's TRACE for that :-) and the 602 tables), but of the granularity
> of Seconds and Milliseconds.
> 
> Minimum second accuracy is required (maximum would be ~2 minutes). 
> Millisecond timing would just be a sweet bonus.
> 
> NOTES:
> 
>  * I just picked up another ThunderClock Plus so that is what I'm
> thinking will be the primary means of a clock source.
> 
>  * I also have the "No-Slot" option coming soon too ...
> https://www.ultimateapple2.com/catalogzen154/index.php?main_page=product_info&products_id=70
> 
> I have not searched usenet / forums -- I'll do that later. :-)
> 
> TIA !
> Michael
> 

Most clocks provide some easily polled location that changes state each
second. This allows timing software to determine subsecond timing by 1)
waiting until an exact second, 2) running the test routine, and then 3)
polling for the next exact second while counting in a timed loop. 

The elapsed clock time in seconds is then added to the subsecond time as
determined by the counted loop. 

This should allow timing with a precision of several microseconds if done
carefully. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2799

On 29-Jun-16 12:06, Michael Pohoreski wrote:
> Let's say I want to benchmark my asm. code that slurps ##K off a
> custom RWTS.
>
> How would I go about benchmarking / profiling / timing this on real
> hardware? Primary will be an enhanced Apple //e, along with optional
> Apple //c, and a Laser 128.
>
> I don't mean at the granularity of clock cycle timing (I already have
> AppleWin's TRACE for that :-) and the 602 tables), but of the
> granularity of Seconds and Milliseconds.
>
> Minimum second accuracy is required (maximum would be ~2 minutes).
> Millisecond timing would just be a sweet bonus.
>

<< SNIP >>

> TIA ! Michael
>


Devices that have a MOS/Rockwell/Sygistics 6522, have Two Timers.

On my John Bell Cards, the whole 6522 is available..

The MockingBoard and Echo+ have Two 6522s and a Single 6522.  I have not 
tried to directly access the 6522s on either, but that might be possible...


MarkO

[toc] | [prev] | [next] | [standalone]

#2800

On Wednesday, June 29, 2016 at 4:11:32 PM UTC-7, Mark D. Overholser wrote:
> On 29-Jun-16 12:06, Michael Pohoreski wrote:
> Devices that have a MOS/Rockwell/Sygistics 6522, have Two Timers.
> 
> On my John Bell Cards, the whole 6522 is available..
> 
> The MockingBoard and Echo+ have Two 6522s and a Single 6522.  I have not 
> tried to directly access the 6522s on either, but that might be possible...

Thanks for the idea Mark!

I have two sound cards (*) on order ... will have to see if they have the 6522 ... and if it directly accessible from the 6502 ...

* Mockingboard 4c
* MockingBoard-K

--
You know you're getting old when everyone else refers to the computers you grew up with as "vintage" ... what is this, we're taking after the wine industry now? :-)  Retro sounds cooler.

[toc] | [prev] | [next] | [standalone]

#2801

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Wednesday, June 29, 2016 at 4:11:32 PM UTC-7, Mark D. Overholser wrote:
>> On 29-Jun-16 12:06, Michael Pohoreski wrote:
>> Devices that have a MOS/Rockwell/Sygistics 6522, have Two Timers.
>> 
>> On my John Bell Cards, the whole 6522 is available..
>> 
>> The MockingBoard and Echo+ have Two 6522s and a Single 6522.  I have not 
>> tried to directly access the 6522s on either, but that might be possible...
> 
> Thanks for the idea Mark!
> 
> I have two sound cards (*) on order ... will have to see if they have the
> 6522 ... and if it directly accessible from the 6502 ...
> 
> * Mockingboard 4c
> * MockingBoard-K
> 
> --
> You know you're getting old when everyone else refers to the computers
> you grew up with as "vintage" ... what is this, we're taking after the
> wine industry now? :-)  Retro sounds cooler.
> 

The 6522s on the Mockingboard can be easily used for their timers, but the
16-bit counters overflow in about a 30th of a second at 1MHz.

My solution for timing purposes was to connect the overflow of one to the
counter input of the other, making it essentially a 32-bit counter. 

The software alternative, taking interrupts on the fast counter and keeping
the extended count in software, is incompatible with Disk ][ timing (or
anything else that might be disturbed by interrupts). 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2802

On Thursday, June 30, 2016 at 11:52:01 AM UTC-7, mjm...@aol.com wrote:
> > On Wednesday, June 29, 2016 at 4:11:32 PM UTC-7, Mark D. Overholser wrote:
> >> Devices that have a MOS/Rockwell/Sygistics 6522, have Two Timers.
> The 6522s on the Mockingboard can be easily used for their timers, but the
> 16-bit counters overflow in about a 30th of a second at 1MHz.
> My solution for timing purposes was to connect the overflow of one to the
> counter input of the other, making it essentially a 32-bit counter. 

You wouldn't happen to have any code for that by chance?
Or a link to the reference/programming guide?

> The software alternative, taking interrupts on the fast counter and keeping
> the extended count in software, is incompatible with Disk ][ timing (or
> anything else that might be disturbed by interrupts). 

That's why I figured the clock was probably the route to go.

I'm assuming the NoSlot clock doesn't use interrupts sine memory is latched.  What about the ThunderClock?  Guess I need to dig up the manual ...

[toc] | [prev] | [next] | [standalone]

#2807

On 30-Jun-16 11:56, Michael Pohoreski wrote:
> On Thursday, June 30, 2016 at 11:52:01 AM UTC-7, mjm...@aol.com
> wrote:
>>> On Wednesday, June 29, 2016 at 4:11:32 PM UTC-7, Mark D.
>>> Overholser wrote:
>>>> Devices that have a MOS/Rockwell/Sygistics 6522, have Two
>>>> Timers.
>> The 6522s on the Mockingboard can be easily used for their timers,
>> but the 16-bit counters overflow in about a 30th of a second at
>> 1MHz. My solution for timing purposes was to connect the overflow
>> of one to the counter input of the other, making it essentially a
>> 32-bit counter.
>
> You wouldn't happen to have any code for that by chance? Or a link to
> the reference/programming guide?
>
>> The software alternative, taking interrupts on the fast counter and
>> keeping the extended count in software, is incompatible with Disk
>> ][ timing (or anything else that might be disturbed by interrupts).
>>



As part of the Documentation I received with the John Bell Engineering 
Cards, there was a Re-Print of part of the MAR-1982 Byte Magazine..

The second project is a Real Time Clock using Chained Timers, with 
Corrections for DOS 3.3 Interrupting the IRQ...

Here is a PDF of that Article..
<http://filedump.glitchwrks.com/manuals/john_bell/6522_parallel_interface_review.pdf>

Here is a slightly better copy of Byte at Archive.org:
<https://archive.org/details/byte-magazine-1982-03>
Source Code starts at page 420 ( PDF Page 422 )

I am this very moment, copying/typing in the Source Code from this 
Article to try with my John Bell Cards...


MarkO

[toc] | [prev] | [next] | [standalone]

#2808

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Thursday, June 30, 2016 at 11:52:01 AM UTC-7, mjm...@aol.com wrote:
>>> On Wednesday, June 29, 2016 at 4:11:32 PM UTC-7, Mark D. Overholser wrote:
>>>> Devices that have a MOS/Rockwell/Sygistics 6522, have Two Timers.
>> The 6522s on the Mockingboard can be easily used for their timers, but the
>> 16-bit counters overflow in about a 30th of a second at 1MHz.
>> My solution for timing purposes was to connect the overflow of one to the
>> counter input of the other, making it essentially a 32-bit counter. 
> 
> You wouldn't happen to have any code for that by chance?
> Or a link to the reference/programming guide?
> 
>> The software alternative, taking interrupts on the fast counter and keeping
>> the extended count in software, is incompatible with Disk ][ timing (or
>> anything else that might be disturbed by interrupts). 
> 
> That's why I figured the clock was probably the route to go.
> 
> I'm assuming the NoSlot clock doesn't use interrupts sine memory is
> latched.  What about the ThunderClock?  Guess I need to dig up the manual ...
> 

If the problem at hand is to time an interval with reasonable precision,
and you get to choose when to invoke the function being tested, then two
calls to a timing routine are about the simplest way to proceed. Interrupts
are not only unnecessary, they may distort the results. 

Wait for an exact second, run the test function, and wait again for the
next exact second. Elapsed clock time (to the second) plus (1 - measured
final wait time to next second) gives the total time to sub-second
precision. 

This technique can be used with any clock that can be read to the second,
and the achievable precision is determined only by the variation in time
required to poll the clock, typically much less than a millisecond (and
just a few microseconds if you can poll a "second" pulse directly). 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2809

On Friday, July 1, 2016 at 10:15:27 AM UTC-7, mjm...@aol.com wrote:
> If the problem at hand is to time an interval with reasonable precision,
> and you get to choose when to invoke the function being tested, then two
> calls to a timing routine are about the simplest way to proceed.

Yup, I'm timing my own code so I have complete control over "injection".

> Interrupts are not only unnecessary, they may distort the results. 

More so, interrupts won't work for timing disk read/writes so I've already discounted that solution.

> Wait for an exact second, run the test function, and wait again for the
> next exact second. Elapsed clock time (to the second) plus (1 - measured
> final wait time to next second) gives the total time to sub-second
> precision. 

Yes, multiple "samples" are required to get an accurate result. i.e. at least 3 times.
 
> This technique can be used with any clock that can be read to the second,
> and the achievable precision is determined only by the variation in time
> required to poll the clock, typically much less than a millisecond (and
> just a few microseconds if you can poll a "second" pulse directly). 

Still waiting for my clock hardware to arrive ...

[toc] | [prev] | [next] | [standalone]

#2810

Disk I/O on the Apple II will stop interrupts and prevent one from getting accurate results.

My idea would be a send an info to an external timing box at both begin and end of the test and display the results.

Antoine

[toc] | [prev] | [next] | [standalone]

#2813

Antoine Vignau <antoine.vignau@laposte.net> wrote:
> Disk I/O on the Apple II will stop interrupts and prevent one from
> getting accurate results.
> 
> My idea would be a send an info to an external timing box at both begin
> and end of the test and display the results.
> 
> Antoine
> 

That's unnecessary. Any clock will do the job, as I've described. 

And a single wire added to a 6522 on a card (like a Mockingboard) will
accumulate timer overflows in the second counter regardless of interrupt
status. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2815

On Friday, July 1, 2016 at 2:59:31 PM UTC-7, Antoine Vignau wrote:
> My idea would be a send an info to an external timing box at both begin and end of the test and display the results.

That would be awesome except:

a) I'm a software guy
b) My soldering skills are, uhm, lacking. :-)
c) Annnd where would I find the plans to make it, or
d) Get one "off the shelf" ? :-)

I did manage to pick up these prototype / debug breadboards .. but without any knowledge on adding a custom IO address I'd be flying a little blind. :-/

http://www.nkcelectronics.com/Apple-II-prototyping-and-debugging-board-PCB-only_p_594.html

or

http://www.ebay.com/itm/351415599198?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

While there is project .. it would take a bit of working to convert it into something into timing needs for someone who doesn't do hardware:
http://mcukits.com/2015/07/04/apple-ii-address-led-display-using-the-prototyping-and-debugging-board/


> Antoine

[toc] | [prev] | [next] | [standalone]

#2816

On Saturday, 2 July 2016 10:21:46 UTC-7, Michael Pohoreski  wrote:
> On Friday, July 1, 2016 at 2:59:31 PM UTC-7, Antoine Vignau wrote:
> > My idea would be a send an info to an external timing box at both begin and end of the test and display the results.
> 
> That would be awesome except:
> 
> a) I'm a software guy
> b) My soldering skills are, uhm, lacking. :-)
> c) Annnd where would I find the plans to make it, or
> d) Get one "off the shelf" ? :-)
> 

Maybe Mike still has a few of his SuperProto boards left: http://www.willegal.net/appleii/appleii-first_page.htm

Great for software people who want to plug-n-play some simple hardware projects.

Dave...

[toc] | [prev] | [next] | [standalone]

#2817

On 6/30/2016 11:56, Michael Pohoreski wrote:
> On Thursday, June 30, 2016 at 11:52:01 AM UTC-7, mjm...@aol.com wrote:
>>> On Wednesday, June 29, 2016 at 4:11:32 PM UTC-7, Mark D. Overholser wrote:
>>>> Devices that have a MOS/Rockwell/Sygistics 6522, have Two Timers.
>> The 6522s on the Mockingboard can be easily used for their timers, but the
>> 16-bit counters overflow in about a 30th of a second at 1MHz.
>> My solution for timing purposes was to connect the overflow of one to the
>> counter input of the other, making it essentially a 32-bit counter.
>
> You wouldn't happen to have any code for that by chance?
> Or a link to the reference/programming guide?
>

I have checked this code over a few times for Typos, but I have not 
Assembled it, yet...  ALL Tabs should be Spaces


This is the Code for a Real Time Clock with the John Bell Engineering 
6522s..  It has been tested under DOS 3.3, and "should" correct for DOS 
Disabling Interrupts..

I am not sure what Assembler it was for, you will need to Remove Line 
Numbers most likely...  And possibly change the Defines..

It is Assembled to Overlay the Last Half of the Keyboard Input Buffer 
and part of the 0x0300 area..

( INTEGER ) BASIC PROGRAM
10 REM
20 REM
30 REM
40 REM ROUTINE TO LOAD AND START THE DOSCLOCK
50 REM
60 PRINT "BLOAD DOSCLOCK.BELL.OBJ"
70 POKE 34,0: CALL -936
80 PRINT "THE CURRENT TIME IS -- >" : POKE 34,2
90 VTAB 10
100 INPUT "ENTER HH,MM,SS ",H,M,S
110 POKE 1535,H: REM HOURS
120 POKE 1407,M: REM MINUTES
130 POKE 1279, S: REM SECONDS
140 CALL 640: REM START THE CLOCK
150 POKE 1919,1: REM DISPLAY TIME
160 END



Machine Code
1000 *
1010 *
1020 *       DOSCLOCK -- REAL TIME CLOCK WITH CORRECTION
1030 *       FOR DISK USE. THIS PROGRAM USES THE JOHN BELL
1040 *       ENGINEERING PARALLEL BOARD AS A REAL TIME DIGITAL
1050 *       CLOCK.
1060 *
1070 *       NOTE -- THIS ROUTINE IS ASSEMBLED TO START NEAR
1080 *       THE END OF THE INPUT LINE BUFFER. THIS MEANS THAT
1090 *       YOU WILL NOT BE ABLE TO ENTER REALLY LONG LINES
1100 *       OF TEXT. THIS ROUTINE IS NOT COMPATABLE WITH
1110 *       THE PROGRAM LINE EDITOR BECAUSE THAT PROGRAM USES
1120 *       LOCATION $45 WHICH IS WHERE THE MONITOR STUFFS
1130 *       THE ACCUMULATOR DURING INTERRUPT PROCESSING.
1140 *
1150 *       BECAUSE THE 6522 IS ATTACHED TO THE APPLE
1160 *       BUSS, THE PUSHING OF THE RESET BUTTON WILL RESET THE
1170 *       6522 AS WELL AS THE APPLE. THAT MEANS THAT YOU WILL
1180 *       HAVE TO RESTART THE CLOCK EVERY TIME RESET IS PUSHED.
1190
1200 *       IN ORDER TO USE THIS ROUTINE WITH THE JBE BOARD, YOU
1210 *       HAVE TO ENABLE TIMER T2 TO COUNT THE NUMBER OF TICKS
1220 *       OF TIMER Tl . THIS IS ACCOMPLISHED BY JUMPERING PINS
1230 *       7 AND 8 ON J2 TOGETHER
1240 *
1250 *
1260 *
1270 * RAM VERSION FOR SLOT 3
1280 *
1290 *   DJG 4/81 ( DERIVED FROM AN AIM CLOCK ROUTINE
1300 *              BY DEJONG IN MICRO )
1310 *   NWR 8/81 ( MODIFIED FOR SLOT 3 AND THE
1320 *              JBE PARALLEL BOARD )
1330 *
1340 *
1350 * PROGRAM ADDRESSES:
1360 *
1370 *    ENTRY POINT (TO START CLOCK):
1380 *        $0280     ( CALL 640 )
1390 *
1400 *    TO CONTROL SCREEN. TIME DISPLAY:
1410 *        $77F (POKE 1919,X)
1420 *        (NON-ZERO VALUE DISPLAYS TIME CONTINUOUSLY)
1430 *
1440 *    TO STOP CLOCK:
1450 *
1460 *     LOAD LOCATION $C30E WITH $40
1470 *     ( POKE - 15602,64 )
1480 *
1490 *
1500 * PROGRAM EQUATES
1510 *
1520 *
1530 ACC  .EQ $0045     MONITOR SAVE ACC HERE ON IRQ
1540 SCRN .EQ $0420     RIGHT HAND TOP LINE OF SCREEN
1550 FREE .EQ $047F     SLOT 7 SCRATCH RAM -- SEE APPLE REFERENCE MANUAL
1560 FRAC .EQ FREE      INTERRUPT COUNTER
1570 SEC  .EQ FREE+$8O  SECONDS COUNTER
1580 MIN  .EQ FREE+$100 MINUTES COUNTER
1590 HOUR .EQ FREE+$180 HOURS COUNTER
1600 TMPL .EQ FREE+$200 TEMP STORAGE
1610 TMPH .EQ FREE+$28O TEMP STORAGE
1620 FLAG .EQ FREE+$300 DISPLAY FLAG
1630 IRQV .EQ $03FE IRQ VECTOR
1640 *
1650 *
1660 * 6222 REGISTER EQUATES
1670 *
1680 *
1690 DS1 .EQ $C300      SLOT 3 6522 ADDRESSES
1700 PB  .EQ DS1        PORT B
1710 T1L .EQ DS1+4      TIMER 1 LOW LATCH
1720 T1H .EQ DS1+5      T1 HIGH
1730 T2L .EQ DS1+8      TIMER 2 LOW LATCH
1740 T2H .EQ DS1+9      T2 HIGH
1750 ACP .EQ DS1+$B     CONTROL REG
1760 IFR .EQ DS1+$D     INTERRUPT FLAGS
1770 IER .EQ DSl+$E     INTERRUPT ENABLE
1780 *
1790 *
1800   .OR $0280        START IT HERE
1810   .TF DOSCLOCK.BELL.OBJ
1820 *
1830 *
1840 * CLOCK ENTRY POINT
1850 *
1860 *
1870 * SET UP IRQ VECTOR AND START THE CLOCK
1880 *
1890 *
1900 CLOK   SEI         DISABLE IRQ
1910        LDA $ISR    ADDRESS OF INTERRUPT SERVICE ROUTINE
1920        STA IRQV    LAST HALF OF ADDRESS
1930        LDA /ISR    LAST HALF OF ADDRESS
1940        STA IRQV+1  SAVE IT
1950 *
1960 *
1970 * SET UP THE 6522
1980 *
1990 *
2000        LDA #$C0	ENABLE T1 INTERRUPT
2010        STA IER		BY LOADING THIS LOCATION
2020        LDA #$E0	T1 FREE RUN MODE
2030        STA ACR		AND T2 COUNTS FB6
2040 *
2050 *
2060 *     YOU CAN PLAY WITH THE VALUE IN T1L AND T1H TO
2070 *     CORRECT TIME INACCURACIES.
2080 *
2090 *
2100        LDA #$20    SET Tl TO F920
2110        STA T1L	    WHICH IS 1/16TH OF
2120        LDA #$F9    A SECOND
2130        STA T1H	    START T1
2140        LDA #$08    T2 OVERFLOWS AFTER 1 SECOND IF
2150        STA T2L	    DOS TURNED OFF IRQ INTERRUPT
2160        LDA #00	    $800 IS ONE SECOND
2170        STA T2H	    T2 COUNTS T1
2180        LDA #$FO    COUNT 16 INTERRUPTS
2190        STA FRAC    PRELOAD THE LOCATION
2200        CLI	        ENABLE IRQ
2210        RTS	        RETURN
2220 *
2230 *
2240 * INTERRUPT SERVICE ROUTINE
2250 *
2260 *
2270 ISR 	INC FRAC    BUMP COUNTER
2280 		BNE UNDO    NOT A FULL SECOND
2290 		LDA #$FO    RESET INTERRUPT COUNTER
2300 		STA FRAC    SAVE IT HERE
2310 		LDA PB      IF T1 HAS ALREADY TICKED
2320 		BPL TOUT    WE HAVE TO ADD
2330 		INC FRAC    ONE TO THE COUNT
2340 TOUT 	LDA #$20    GET MASK
2350 		BIT IFR     T2 TIMED OUT??
2360 		BNE CORR    NO
2370 		LDA #$08    RESET T2 COUNTER
2380 		STA T2L     WITH A $8OO
2390 *
2400 *
2410 * INCREMENT THE SOFTWARE CLOCK
2420 *
2430 *
2440 SECS   INC SEC     BUMP SECONDS
2450        LDA SEC     GET CURRENT SECONDS
2460        CMP #60     60 SECONDS??
2470        BCC SHOW    NO
2480        LDA #00     RESET SECONDS
2490        STA SEC     TO ZERO
2500 MINS   INC MIN     BUMP MINUTES
2510        LDA MIN     GET CURRENT MINUTES
2520        CMP #60     60 MINUTES??
2530        BCC SHOW    NO
2540        LDA #00     RESET MINUTES
2550        STA MIN     TO ZERO
2560 HRS    INC HOUR    BUMP HOURS
2570        LDA HOUR    GET CURRENT HOUR
2580        CMP #24     24 HOURS??
2590        BCC SHOW    NO
2600        LDA #00     RESET HOURS
2610        STA HOUR    TO ZERO
2620 *
2630 *
2640 * DISPLAY THE TIME IF DESIRED
2650 *
2660 *
2670 SHOW   LDA FLAG    DISPLAY TIME??
2680        BEQ DONE    NO
2690        STX TMPL    SAVE X
2700        STY TMPH    SAVE Y
2710        LDX #00     CLEAR X
2720        LDA HOUR    GET THE CURRENT HOUR
2730        JSR DSPL    PRINT IT
2740        LDA MIN     GET CURRENT MINUTE
2750        JSR DCOL    PRINT IT
2760        LDA SEC     GET CURRENT SECONDS
2770        JSR DCOL    DISPLAY IT
2780        LDX TMPL    RESTORE X
2790        LDY TMPH    RESTORE Y
2800 *
2810 *
2820 * INTERRUPT DONE
2830 *
2840 *
2850 DONE   LDA #00     GET A ZERO
2960        STA T2H     START T2
2870 UNDO   LDA T1L     CLEAR INTERRUPT FLAG
2880        LDA ACC     RESTORE ACCUM.
2890        RTI         INTERRUPT RETURN
2900 *
2910 *
2920 * CORRECTION TO TIME WHEN DOS TURNED OFF IRQ
2930 *
2940 *
2950 CORR   SEC         SAVE 2'S COMPLEMENT OF T2
2960        LDA #00     BY SUBTRACTING
2970        SBC T2L     FROM ZERO
2980        STA TMPL    SAVE PARTIAL RESULT
2990        LDA #00     ANOTHER ZERO
3000        SBC T2H     AND THE SUBTRACT
3010        STA TMPH    SAVE IT
3020 *
3030 *
3040 * DO THE CORRECTION
3050 *
3060 *
3070 SETF   LDA TMPL    SET FRACTION
3080        AND #$07    TO CORRECT
3090        ASL         1/16
3100        ADC         FRAC OF A SEC
3110        STA FRAC    SAVE IT BACK
3120        AND #$0F    CORRECT T2
3130        LSR         TO THE PARTIAL
3140        EOR #$FF    NUMBER OF
3150        CLC         OF TICKS
3160        ADC #$09    LEFT IN ITS INTERVAL
3170        STA T2L     AND SAVE BACK
3180        LSR TMPH    DIVIDE BY EIGHT
3190        ROR TMPL    TO GET NUMBER
3200        LSR TMPH    OF FULL SECONDS
3210        ROR TMPL    TO ADD TO THE
3220        LSR TMPH    TIME TO CORRECT
3230        ROR TMPL    FOR DOS BEING ON
3240        CLC         SETUP THE CARRY
3250        LDA SEC     ADD THE FULL
3260        ADC #01     SECONDS
3270        ADC TMPL    AND STORE IN
3280        STA SEC     SECONDS COUNTER
3290        SEC         CHECK FOR GREATER
3300        SBC #60     THAN 60 SECONDS
3310        BCC SHOW    TO SEE IF A MINUTE
3320        STA SEC     UPDATE IS
3330        JMP MINS    REQUIRED
3340 *
3350 *
3360 * DISPLAY SUBROUTINE
3370 *
3390 DCOL   TAY         SAVE COUNT
3400        LDA #$BA    GET A COLON
3410        STA SCRN,X  SHOW IT
3420        INX         BUMP COUNTER
3430        TYA         RESTORE COUNT
3440 DSPL   LDY #$FF    DISPLAY TIME
3450 CNTY   INY         Y WILL COUNT BY 10
3460        SEC         SET CARRY
3470        SBC #10     MINUS 10
3480        BCS CNTY    GET RID OF TENS
3490        ADC #1O     RESTORE REMAINDER
3500        PHA         AND SAVE
3510        TYA         DISPLAY TENS DIGIT
3520        ORA #$BO    MAKE IT ASCII
3530        STA SCRN,X  SHOW IT
3540        INX         BUMP X
3550        PLA         GET ONES DIGIT
3560        ORA #$BO    MAKE IT ASCII
3570        STA SCRN,X  SHOW IT
3580        INX         BUMP THE COUNT
3590        RTS         RETURN
3600 .EN




MarkO

[toc] | [prev] | [next] | [standalone]

#2812

On Wednesday, June 29, 2016 at 12:06:32 PM UTC-7, Michael Pohoreski wrote:
> Let's say I want to benchmark my asm. code that slurps ##K off a custom RWTS.
> 
> How would I go about benchmarking / profiling / timing this on real hardware? 
> Primary will be an enhanced Apple //e, along with optional Apple //c, and a Laser 128.
> 
> I don't mean at the granularity of clock cycle timing (I already have AppleWin's TRACE for that :-) and the 602 tables), but of the granularity of Seconds and Milliseconds.
> 
> Minimum second accuracy is required (maximum would be ~2 minutes).  Millisecond timing would just be a sweet bonus.
> 
> NOTES:
> 
>  * I just picked up another ThunderClock Plus so that is what I'm thinking will be the primary means of a clock source.
> 
>  * I also have the "No-Slot" option coming soon too ...
> https://www.ultimateapple2.com/catalogzen154/index.php?main_page=product_info&products_id=70
> 
> I have not searched usenet / forums -- I'll do that later. :-)
> 
> TIA !
> Michael

FWIW, Apple II load times typically live and die due to rotational latency. At 200ms per rotation, missing a header and waiting for another head pass really hurts.

While writing and optimizing custom RWTS routines for Apple II/GS 5.25" & 3.5" drives, I've found three main areas for big speed-ups:

1) Single-pass read per track. See qkumba's bootloaders for example 1:1 interleave 'gather' reads.

2) Disk spin-up, recalibrate, and head settle times. Apple was overly conservative with all these times. Easy wins here are to skip spin-up delay and go right into looking for sector headers. Settle times can be greatly reduced by leaving the stepper phase enabled so head settle happens during track read.

3) Improve track density: 18 sectors per track (19 on GS) & data compression are nice wins to reduce the wait time from slow media. LZ4/LZSS/RLE can be done after track reads finish, if you have enough memory to decompress after reading.

BTW, the IIGS is handy for timing 1.023MHz 6502 code. The GS has a built-in real-time clock (1sec accuracy), an NSTC scan-line counter (63.6ms accuracy) @ $C02E, and a short-duration 6-bit 1usec timer @ $C02F.

Also, I've yet to see an emulator with accurate timing for the Sony 3.5" drive mechanism, and many emulators just fail when dealing with custom RWTS controlling 3.5" drives directly. 

The 'smart' 3.5" drives for //e & //c have embedded CPU & RAM which are probably less likely to work accurately in emulators than the dumb IWM drives.

I guess the bottom line is that I've been burned by numerous compatibility gotchas with the various emulators, so I recommend avoiding them for timing-sensitive code.

Hope that helps,
-JB
Twitter: @JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#2820 — Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c,Laser 128) ?

Michael Pohoreski wrote:
> Let's say I want to benchmark my asm. code that slurps ##K off a custom
> RWTS.
> 
> How would I go about benchmarking / profiling / timing this on real
> hardware? 
> Primary will be an enhanced Apple //e, along with optional Apple //c, and
> a
> Laser 128.
> 
> I don't mean at the granularity of clock cycle timing (I already have
> AppleWin's TRACE for that :-) and the 602 tables), but of the granularity
> of Seconds and Milliseconds.
> 
> Minimum second accuracy is required (maximum would be ~2 minutes). 
> Millisecond timing would just be a sweet bonus.
> 
> NOTES:
> 
>  * I just picked up another ThunderClock Plus so that is what I'm thinking
>  will be the primary means of a clock source.
> 
>  * I also have the "No-Slot" option coming soon too ...
> https://www.ultimateapple2.com/catalogzen154/index.php?main_page=product_info&products_id=70
> 
> I have not searched usenet / forums -- I'll do that later. :-)
> 
> TIA !
> Michael
>fetaure
May I suggest that you get a look at the timing measurement routines I wrote
for the companion program of a utility I've written in the past months.
I've used them to evaluate the performance gain I get by using some features
of the utility instead of using plain vanilla Applesoft code.
The subroutines themselves are written for:
a) The Thunderclock peripheral cards (the first one advertised as being
fully ProDOS compatible) (file TCPRECON.S from source disks);
b) The internal 2GS circuitry (file TCPRECON.S from source disks);
c) The SMT NoSlotClock chip (file SMTRECON.S from source disks)
However, the accuracy I've got would not be above a second of time. That
would mean that many iterations would be measured between two "clock"
circuit pollings to be meaningful.

HopeTHisHelpsAsTheySay,
Benoît



-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#2823 — Re: Benchmark / Profiling / Timing on real hardware (Apple //e, //c,Laser 128) ?

Benoit0123 <bgilon@free.fr> wrote:
> Michael Pohoreski wrote:
>> Let's say I want to benchmark my asm. code that slurps ##K off a custom
>> RWTS.
>> 
>> How would I go about benchmarking / profiling / timing this on real
>> hardware? 
>> Primary will be an enhanced Apple //e, along with optional Apple //c, and
>> a
>> Laser 128.
>> 
>> I don't mean at the granularity of clock cycle timing (I already have
>> AppleWin's TRACE for that :-) and the 602 tables), but of the granularity
>> of Seconds and Milliseconds.
>> 
>> Minimum second accuracy is required (maximum would be ~2 minutes). 
>> Millisecond timing would just be a sweet bonus.
>> 
>> NOTES:
>> 
>> * I just picked up another ThunderClock Plus so that is what I'm thinking
>> will be the primary means of a clock source.
>> 
>> * I also have the "No-Slot" option coming soon too ...
>> https://www.ultimateapple2.com/catalogzen154/index.php?main_page=product_info&products_id=70
>> 
>> I have not searched usenet / forums -- I'll do that later. :-)
>> 
>> TIA !
>> Michael
>> fetaure
> May I suggest that you get a look at the timing measurement routines I wrote
> for the companion program of a utility I've written in the past months.
> I've used them to evaluate the performance gain I get by using some features
> of the utility instead of using plain vanilla Applesoft code.
> The subroutines themselves are written for:
> a) The Thunderclock peripheral cards (the first one advertised as being
> fully ProDOS compatible) (file TCPRECON.S from source disks);
> b) The internal 2GS circuitry (file TCPRECON.S from source disks);
> c) The SMT NoSlotClock chip (file SMTRECON.S from source disks)
> However, the accuracy I've got would not be above a second of time. That
> would mean that many iterations would be measured between two "clock"
> circuit pollings to be meaningful.
> 
> HopeTHisHelpsAsTheySay,
> Benoît
> 
> 
> 

Generally, the only API needed for timing is "elapsed". Call "elapsed"
returns the time elapsed since the previous call, to some precision. 

Since any clock can be read repeatedly, timing resolution much better than
the least significant unit of the clock (often, one second, but could be a
minute) can be obtained by repeatedly polling the time until it changes.
Then "elapse" returns and the test code is executed. Upon the next call to
"elapse", the time is read initially, then the clock is repeatedly read
until it changes again, while a counter keeps track of the number of reads.


Since the duration of a single read has been determined previously, a
simple multiplication gives the duration between when "elapse" was called
and when the time changes next. 

The more accurate elapsed time is then the final (changed) time read minus
the final time read on the previous call, minus the time determined by
counting iterations until the final time change. 

For most clock reading schemes, this will result in a timing accuracy of a
few milliseconds--without any unusual equipment. 

It's easy--make it a standard part of your measurement repertoire!  ;-)
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web