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

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

How long should DOS 3.3 take to load?

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

Contents

  How long should DOS 3.3 take to load? thomas.harte@gmail.com - 2018-08-02 10:51 -0700
    Re: How long should DOS 3.3 take to load? D Finnigan <dog_cow@macgui.com> - 2018-08-02 20:22 +0000
      Re: How long should DOS 3.3 take to load? qkumba <peter.ferrie@gmail.com> - 2018-08-02 14:33 -0700
        Re: How long should DOS 3.3 take to load? thomas.harte@gmail.com - 2018-08-02 18:25 -0700
          Re: How long should DOS 3.3 take to load? Michael J. Mahon <mjmahon@aol.com> - 2018-08-03 00:55 -0500
            Re: How long should DOS 3.3 take to load? thomas.harte@gmail.com - 2018-08-03 07:30 -0700
              Re: How long should DOS 3.3 take to load? David Schmenk <dschmenk@gmail.com> - 2018-08-03 07:56 -0700

#4662 — How long should DOS 3.3 take to load?

i.e. from placing the disk in the drive and switching on a II+, roughly how long should it be until Integer BASIC is loaded and I'm back at the BASIC prompt?

My emulator appearing to have some sort of DOS 3.3 speed-inhibiting issue is what prompted my curiosity; I've been tracing the boot code and by my count RWTS16 is called upon to load only 59 sectors before returning to the prompt. I also looked at how many sectors pass under the drive head during periods when the shift register is being polled, and got 225, which doesn't feel too far out of whack.

It struck me as odd that RWTS16 appears to switch the motor off and on again between each access, but I don't see what else it could do without a timer to hand or a different API so fair enough.

Assuming that my emulator is in the wrong and I'm not just suffering from rose-tinted spectacles, the next step will be to produce a heat map of processor activity during the boot process to figure out what's going on.

But I thought I'd double check first: how long should the boot actually take?

[toc] | [next] | [standalone]

#4663

thomas.harte wrote:
> i.e. from placing the disk in the drive and switching on a II+, roughly
> how
> long should it be until Integer BASIC is loaded and I'm back at the BASIC
> prompt?
> 
> 
> But I thought I'd double check first: how long should the boot actually
> take?
>

Several seconds. First the drive head is forced back to track 0, making the
clack-clack-clack. Then DOS is loaded from the first couple tracks. Then the
INTBASIC file is loaded, and that's about 42 sectors.

I'm going to guess it's in the neighborhood of 5 to 6 seconds.... Let's time
it and find out for sure. :-)

-- 
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

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

#4664

There's also no harm in DOS turning the motor on and off between accesses.  It's done that way because it doesn't know if another request is about to come in.
For sequential accesses ($B793-style), the spin-down time is long enough that the off request is effectively ignored by the hardware.

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

#4666

That's how I recall it; maybe ten seconds at the absolute worst. A brief period. Somehow it is taking more like a minute in my emulator (!)

Based on some quick debugging, against the disassembly at http://www.textfiles.com/apple/ANATOMY/rwts.s.txt , I observed 49,494,640 cycles spent in the "wait for motor to come up to speed" routine MOTOROF, across loading of 59 sectors.

So obviously something is wrong somewhere around there. Thanks for confirming that this is worth pursuing!

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

#4667

<thomas.harte@gmail.com> wrote:
> That's how I recall it; maybe ten seconds at the absolute worst. A brief
> period. Somehow it is taking more like a minute in my emulator (!)
> 
> Based on some quick debugging, against the disassembly at
> http://www.textfiles.com/apple/ANATOMY/rwts.s.txt , I observed 49,494,640
> cycles spent in the "wait for motor to come up to speed" routine MOTOROF,
> across loading of 59 sectors.
> 
> So obviously something is wrong somewhere around there. Thanks for
> confirming that this is worth pursuing!
> 
> 

RWTSs usually read the disk data latch several times to determine whether
the disk is turning before entering the “motor on” delay loop. 

Since the controller delays motor turnoff for about a second, the normal
behavior is to avoid motor on delays during any multi-sector/block
operation. 

An RWTS intended only for booting might forego this optimization.

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#4668

On Friday, 3 August 2018 01:56:03 UTC-4, mjm...@aol.com  wrote:
> RWTSs usually read the disk data latch several times to determine whether
> the disk is turning before entering the “motor on” delay loop. 
> 
> Since the controller delays motor turnoff for about a second, the normal
> behavior is to avoid motor on delays during any multi-sector/block
> operation. 
> 
> An RWTS intended only for booting might forego this optimization.

I think that provides the full explanation. My emulation has a magical disk motor, with brakes. Turn it off at the controller and the the platter ceases to move — instantly! No one-second delay in communication to the drive, no spin-down period.

Looking further at DOS 3.3's RWTS, I note that the test for whether a disk is already spinning enough for it not to be worth a spin-up period is whether the shift register changes _before_ the motor is turned back on at the controller*.

In my faulty logic, any time the motor is off, the disk isn't spinning. So that test fails and the new ~1 second spin-up delay happens.

That probably also explains the bit I hadn't really mentioned: Pro-DOS and 8DOS** both seem to work at the proper speed, as does saving data***, so DOS 3.3 had been a bit of a prima facie head scratcher.

Thanks again!

* in http://www.textfiles.com/apple/ANATOMY/rwtsdrvr.read.txt see STRBAGN onwards and note the motor on isn't until below, at BD4F; in http://www.textfiles.com/apple/ANATOMY/rwts.s.txt check out NOTSURE1 for the same segment of code.

** Pravetz's reimplementation of DOS 3.3 for their interface that connects a Disk II to their Oric clone, the Pravetz 8D. All the other Pravetz 8s were Apple II clones so I guess they decided to use a common disk interface.

*** using the original state machine ROM, so just sampling the data bus and generating the flux as commanded by the state machine, completely independently of whatever the 6502 is up to. With later successful reading back implying a proper relationship of disk rotation and controller clock speed.

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

#4669

On Friday, 3 August 2018 07:30:14 UTC-7, thomas...@gmail.com  wrote:
> On Friday, 3 August 2018 01:56:03 UTC-4, mjm...@aol.com  wrote:
> > RWTSs usually read the disk data latch several times to determine whether
> > the disk is turning before entering the “motor on” delay loop. 
> > 
> > Since the controller delays motor turnoff for about a second, the normal
> > behavior is to avoid motor on delays during any multi-sector/block
> > operation. 
> > 
> > An RWTS intended only for booting might forego this optimization.
> 
> I think that provides the full explanation. My emulation has a magical disk motor, with brakes. Turn it off at the controller and the the platter ceases to move — instantly! No one-second delay in communication to the drive, no spin-down period.
> 
> Looking further at DOS 3.3's RWTS, I note that the test for whether a disk is already spinning enough for it not to be worth a spin-up period is whether the shift register changes _before_ the motor is turned back on at the controller*.
> 
> In my faulty logic, any time the motor is off, the disk isn't spinning. So that test fails and the new ~1 second spin-up delay happens.
> 
> That probably also explains the bit I hadn't really mentioned: Pro-DOS and 8DOS** both seem to work at the proper speed, as does saving data***, so DOS 3.3 had been a bit of a prima facie head scratcher.
> 
> Thanks again!
> 
> * in http://www.textfiles.com/apple/ANATOMY/rwtsdrvr.read.txt see STRBAGN onwards and note the motor on isn't until below, at BD4F; in http://www.textfiles.com/apple/ANATOMY/rwts.s.txt check out NOTSURE1 for the same segment of code.
> 
> ** Pravetz's reimplementation of DOS 3.3 for their interface that connects a Disk II to their Oric clone, the Pravetz 8D. All the other Pravetz 8s were Apple II clones so I guess they decided to use a common disk interface.
> 
> *** using the original state machine ROM, so just sampling the data bus and generating the flux as commanded by the state machine, completely independently of whatever the 6502 is up to. With later successful reading back implying a proper relationship of disk rotation and controller clock speed.

For Appalm, the Apple II PalmPilot emulator, I would check how long it had been since the last disk access. If it was brief (~300 clocks) but not longer than a *long* time (an arbitrary value I pulled out of the air but roughly equivalent to 1/4 second) I would advance my internal track pointer by the amount the disk should have spun, then magically align it to the next sector boundary. This made a significant improvement in load times, without a great deal of additional logic.

Dave...

[toc] | [prev] | [standalone]

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

csiph-web