Test: the cycle

[Marc S. Ressl]

Hello everyone:

this is very simple, could somebody please test the following code on
an Apple II? It is supposed to split-screen the display without
scrolling:

0300: A2 00 CA D0 FD A2 00 CA
0308: D0 FD A2 00 CA D0 FD A2
0310: 00 CA D0 FD A2 00 CA D0
0318: FD A2 00 CA D0 FD A2 00
0320: CA D0 FD AD 50 C0 A2 00
0328: CA D0 FD A2 00 CA D0 FD
0330: A2 00 CA D0 FD A2 00 CA
0338: D0 FD A2 00 CA D0 FD A2
0340: 00 CA D0 FD A2 49 CA D0
0348: FD AD 51 C0 4C 00 03 00

Thanks a lot!

Marc.-

[Egan Ford]

Any Apple II (e.g. //e), or just a plain old II?

[Bill Garber]

"Marc S. Ressl" <mre...@gmail.com> wrote in message news:7b84
f58f-62b5-4b32-a...@f30g2000yqh.googlegroups.com...

I can't even describe what it does on my IIgs ROM03
with CB card in slot#1. I need to set up my //e in
the next day or two, and I can try it there.

Bill

[Vladimir Ivanov]

Hey Marc,

NTSC - yes, it does provide stable split.

PAL/Euro - not nearby to test, but I bet it won't.


And of course, my corrigenda:

34C: A2 41 CA D0 FD 4C 00 03

Cheers,
-- Vlad

[Marc S. Ressl]

Hi Vlad & everyone:

thanks for all your responses. Vladimir, do you mean it only splits
well on NTSC if you add that code at 34C?

With the best wishes,

Marc.-

[Vladimir Ivanov]

On Wed, 8 Feb 2012, Marc S. Ressl wrote:

> Vladimir, do you mean it only splits well on NTSC if you add that code
> at 34C?

No, no - it works as expected on NTSC.


The "corrigenda" (initially with smiley) is just added bit of fun.

[Marc S. Ressl]

That's great, thanks a lot :-).

[BLuRry]

I haven't tested it on my //e, but I get an awful lot of flickering from JACE. The video renderer isn't perfectly cycle accurate yet, but it's close enough to where I shouldn't see a full screen flicker (which is what I got when I tested it.) By comparison, I can see the split screen on the money munchers intro with some flickering. If my timing is skewed (and it probably still is) I should have seen a split that was slowly traveling along the screen.

-B

[Marc S. Ressl]

On Feb 8, 12:25 pm, BLuRry <brendan.rob...@gmail.com> wrote:
> I haven't tested it on my //e, but I get an awful lot of flickering from JACE.  The video renderer isn't perfectly cycle accurate yet, but it's close enough to where I shouldn't see a full screen flicker (which is what I got when I tested it.)  By comparison, I can see the split screen on the money munchers intro with some flickering.  If my timing is skewed (and it probably still is) I should have seen a split that was slowly traveling along the screen.
>
> -B

I'm glad this helps towards building better emuators :-).

Marc.-

[Antoine Vignau]

Hello There,
A point of view from a *real machine user and more and more emulator*
user.

We have now reached the level where original disks are modified to run
on an emulator. I think that is total nonsense, that should be the
other way round. I have in mind plenty of fast loader cracking disks
which all use some tricks to load well and fast.

Over the years, I have encountered some weird behaviour of some apps
either running well on emulators or on the real machines. See the
recent discussion above about the rainbow display.

I know, emulator programmers are doing a great job but are we going in
the right direction? I mean nowadays, why do emulators do not emulate
at a 100% accuracy rate, our beloved machines? Is that due to the way
the emulators were coded or a lack of knowledge of the real machines?
Or is that due to a lack of power of our modern machines? I do not
have the answer.

From my pirate perspective, does the low-level disk code emulate the
behaviour of the Logic State Sequencer or not?

I think Marc's modern approach of a modular and hardware-accurate
emulator will be the answer. I do not say, todays' emulators do not
behave well, the work done on those is really awesome. I just say the
path to a real emulated machine is still a few steps long.

Keep up the good work, Gentlemen! I am sure that one day, I will write
or crack software on an emulated machine only. For instance, Fishhead
was written within Sweet16 on my Macbookpro despite its horrible
keyboard.

Antoine.cycleaccuracy.isthekey

[BLuRry]

Yes, between this, the rainbow example (which I can get correctly in JACE if I intentionally mess up some timing settings), and Money Munchers title screen (which I can also get working but unfortunately different timing settings than Money Munchers) I have some great test cases to use.

I think that I must have a timing mismatch in my code that varies by graphics mode. But it was fun making some timing adjustments surface in the configuration (I <3 annotations!) Just so I'm clear: HBLANK is 25 cycles long and starts at the beginning of each line, or the end of each line? Also, what is the video scanner picking up during that time? Say that 0 is an offset relative to the leftmost byte on a row -- would it be -25, 0 or 40? Money munchers seems to look **perfect** when I assume HBLANK starts at 0 on the current line.

It's nice to know that JACE *can* render this stuff in some plausible circumstances, because that means I can figure out where things are off and fix it now.

side note: I fixed a big nasty horrible bug that causes JACE to crash when configuration is applied -- and now it is really damn stable for a change. You really can change out hardware while the computer is running. Prodos gets really confused though when you add/remove disk interface cards, as well it should I suppose. :-)

[BLuRry]

Antoine,

I agree a thousand times over on this point. I really want things like the original Flobynoid disk to boot up without requiring a special flobynoid disk to use it. But putting cycle-accurate emulation aside, I like the idea of augmented emulation also. Why not use emulation to enhance the original experience (optionally)? For example, it's pretty easy to trap routines used by games to render sprites/tiles and NOP those in the apple side while providing an alternative drawing engine in the host layer. Think of it like what the kiddos are doing to Minecraft and other games with install-able mods. Could be funny to play Airheart modded to look like Typhoon Thompson (or at least have the music -- the Atari ST used an AY chip and the mockingboard is the same).

There are other games that would play better if only they could have faster drawing routines not possible back then. I recently saw a modded starfox (super nintendo) cartridge that was overclocked. The game was unchanged, things still happened at the same pace. But the framerate was AMAZING.

-Brendan

[BLuRry]

Ok, reworked my scanner routine and now this works to your specification: it does not move. This actually helped me nail down the timing issue that was eluding me on the rainbow example. Unfortunately when I get this and the rainbow working, Money munchers starts to flicker... :-/ ugh.

[Marc S. Ressl]

I can't refrain myself from commenting... and I'm also a bit blushed
by Antoine's comments ;-).

Cycle-accuracy is very hard... it took a lot of of time to tackle this
issue in a generic and efficient way. I finally arrived at a scheduler
that considers these things:

* most CPU emulations have instruction-accuracy, not cycle accuracy.
The scheduler and framework take that into account.
* the scheduler is capable of altering the number of pending CPU
cycles on the fly (for example, when a new event is inserted right at
the top).
* the scheduler uses a master clock as timing base, and it possible to
specify a (floating point) CPU clock multiplier. This is useful for
implementing acceleration in a transparent way on all systems. And you
have absolutely *NO IDEA* how hard this was arghhhh... checking all
the math, all the floating point to integer roundings are correct, all
the many cases... arghhh, it is so good to do a catharsis on that!!! :-
D

So, why is this so useful? In order to implement the Apple II video
timing, I can just tell the scheduler "notify me in 17030" clocks. It
works wonders and should make things very easy on other systems.

In regard to Brendan's comment, I must say I'm a purist. I don't like
emulator extensions, I like the beauty of the original "perfection"
hehe. But I have some good news for Bredan: as OpenEmulator is based
on a component framework, you can just define your additional
components and map them wherever you want. If the component is
standard, there's not even a need to write code, just modify the XML.

Last comment: in OpenEmulator the Apple II emulations emulate only the
original, no extra features. But in case there is consensus, I propose
to add the "Apple IIcomp.sys.apple" :-).

[Marc S. Ressl]

On 8 feb, 17:50, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> From my pirate perspective, does the low-level disk code emulate the
> behaviour of the Logic State Sequencer or not?

BTW, AppleIIGo already implemented a cycle-accurate Disk II, so it
will be very easy to port that to OpenEmulator. The only thing I
didn't do was weak bits and reading the raw FDI format, so there's
still room for improvement!

[Deckard]

On 8 fév, 21:50, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> Hello There,
> A point of view from a *real machine user and more and more emulator*

> We have now reached the level where original disks are modified to run
> on an emulator. I think that is total nonsense, that should be the
> other way round. I have in mind plenty of fast loader cracking disks
> which all use some tricks to load well and fast.

> I know, emulator programmers are doing a great job but are we going in
> the right direction?

Our goal is to have something that works and is easy to manipulate
(more "standard" disks).
Don't forget that the 1st step was to remove the copy protection ;-)
If tricks to load well and fast are important, what about the crazy
routine used to protect the programs?

JM

[Linards Ticmanis]

On 02/08/2012 10:54 PM, BLuRry wrote:

> I think that I must have a timing mismatch in my code that varies by graphics mode. But it was fun making some timing adjustments surface in the configuration (I <3 annotations!) Just so I'm clear: HBLANK is 25 cycles long and starts at the beginning of each line, or the end of each line? Also, what is the video scanner picking up during that time? Say that 0 is an offset relative to the leftmost byte on a row -- would it be -25, 0 or 40? Money munchers seems to look **perfect** when I assume HBLANK starts at 0 on the current line.

You could look at the "Understandig the Apple II" book by Jim Sather,
which can be found online as a PDF. It explains the scanner in every
detail including those you asked for, at least for the old II/II+
machines. No idea whether the IIe has any marked differences here.

--
Linards Ticmanis

[BLuRry]

I found that our machines are all generally really fast compared to the 1mhz ]['s. Because of this, it makes more sense to let the emulator overclock when the disk drive is active than it does to hack the emulator for some convenient speedups. Compatibility is the chief driver, but also it's easier to save the emulator state if everything runs as originally intended.

I set JACE to overclock when the Disk ][ controller is made active, and then the overclock is disabled when sound is active. Hence, you can leave it running at max speed and it will still produce the same tonality of sound because it slows down until the speaker goes dormant again.

-B

[Michael J. Mahon]

BLuRry wrote:
> I found that our machines are all generally really fast compared to the 1mhz ]['s. Because of this, it makes more sense to let the emulator overclock when the disk drive is active than it does to hack the emulator for some convenient speedups. Compatibility is the chief driver, but also it's easier to save the emulator state if everything runs as originally intended.
>
> I set JACE to overclock when the Disk ][ controller is made active, and then the overclock is disabled when sound is active. Hence, you can leave it running at max speed and it will still produce the same tonality of sound because it slows down until the speaker goes dormant again.

That's what the Zip Chip does with speaker and joystick access, but it
also slows down for Disk ][ access, since it won't work with a real
disk unless it's running at exactly 1MHz.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

[Vladimir Ivanov]

On Thu, 9 Feb 2012, Michael J. Mahon wrote:

> That's what the Zip Chip does with speaker and joystick access, but it
> also slows down for Disk ][ access, since it won't work with a real
> disk unless it's running at exactly 1MHz.

It's the Apple IIgs that slows down on Disk II access - "motor on"
($C0x9) is the key.

ZipChip simply does about 50 msec slow down after I/O access. For normal
disk I/O that will be re-triggered constantly by the nibble read ($C0xC)
polling loop, but a longer than ~50 msec delay will be broken.

http://www.bootzero.com/forum/viewtopic.php?f=3&t=12

http://www.bootzero.com/forum/viewtopic.php?f=3&t=15

I guess that they choose ~50 msec to not interfere with disk stepper. Of
course a track-synchronized copy protection might fail with ZipChip if it
has track-to-track delay of more than ~50 msec.

Same goes for sound - if you have longer than ~50 msec pause/rest, tempo
becomes wrong.

Same goes for any I/O that is separated by longer than ~50 msec lack of
I/O activity.

[Michael J. Mahon]

Exactly. But the net effect is to slow down on Disk ][ access.

I develop on a Zip Chip-equipped //e, so all my cycle-counted code
depends on temporarily disabling the acceleration it provides.

In NadaNet, my approach is to reference the "motor off" softswitch
repeatedly (more often than every 50ms) in NadaNet arbitrate, send,
and receive code. I find this approach much simpler than the IIgs
approach of using multiple instructions to set and reset a speed
toggle.

In my sound synthesis code, the problem of rests does not arise,
because a "rest" is actually a continuous stream of 22kHz speaker
pulses, so speaker references never actually stop.

I've never heard of any program that is incompatible with the
"50ms slowdown" approach, though as Vlad points out, one could
easily be constructed by using a timed disk access delay in
excess of 50ms.

Besides not being particularly useful, such a timed delay would
need to be quite tolerant of variations, since 50ms is 1/4th of
a rotation, and normal disk speed variations would result in a
significant variance in track position after such a long delay.

For cases where a shorter slowdown is appropriate, a reference
to the paddle timer trigger will cause the Zip Chip to slow down
for about 7ms, IIRC, if the chip's mode is set for paddle slowdown.

[Vladimir Ivanov]

On Fri, 10 Feb 2012, Michael J. Mahon wrote:

> I develop on a Zip Chip-equipped //e, so all my cycle-counted code
> depends on temporarily disabling the acceleration it provides.

Yes, as long as they are cyclic enough.

> In NadaNet, my approach is to reference the "motor off" softswitch
> repeatedly (more often than every 50ms) in NadaNet arbitrate, send,
> and receive code. I find this approach much simpler than the IIgs approach
> of using multiple instructions to set and reset a speed
> toggle.

This is definitely a very specific corner case. :-)

> In my sound synthesis code, the problem of rests does not arise,
> because a "rest" is actually a continuous stream of 22kHz speaker
> pulses, so speaker references never actually stop.

PWM can't have problems with ZipChip. I was thinking simpler one-voice
output.

> I've never heard of any program that is incompatible with the
> "50ms slowdown" approach, though as Vlad points out, one could
> easily be constructed by using a timed disk access delay in
> excess of 50ms.

The one that bit me nasty with HDDD A2 - very popular disk copy program (I
think it was Locksmith) doing simple timed delay on drive spin-up. With 4
MHz ZipChip this delay goes less than 200 msec and it's a bit of a miracle
that regular Disk II drive is still able to write reliable data.

> Besides not being particularly useful, such a timed delay would
> need to be quite tolerant of variations, since 50ms is 1/4th of
> a rotation, and normal disk speed variations would result in a
> significant variance in track position after such a long delay.

By quick calculation variation in position (relative to track) due to disk
speed seems to be within +/- 4%, which is comparable to one sector, so a
very pathologically synthetical case seems still possible.

> For cases where a shorter slowdown is appropriate, a reference
> to the paddle timer trigger will cause the Zip Chip to slow down
> for about 7ms, IIRC, if the chip's mode is set for paddle slowdown.

Ouch, I forgot that paddle and speaker enjoy much smaller delay - about 5
msec. That makes my sound prediction much much worse. ;-)

[Michael J. Mahon]

Vladimir Ivanov wrote:
>
> On Fri, 10 Feb 2012, Michael J. Mahon wrote:
>
>> I develop on a Zip Chip-equipped //e, so all my cycle-counted code
>> depends on temporarily disabling the acceleration it provides.
>
>
> Yes, as long as they are cyclic enough.
>
>> In NadaNet, my approach is to reference the "motor off" softswitch
>> repeatedly (more often than every 50ms) in NadaNet arbitrate, send,
>> and receive code. I find this approach much simpler than the IIgs
>> approach of using multiple instructions to set and reset a speed
>> toggle.
>
>
> This is definitely a very specific corner case. :-)

But it is a quite general technique for disabling acceleration
in timing-critical code that has a loop period of less than 50ms.

In the case of NadaNet, the maximum packet size is 256 bytes, plus
an 8-byte header, all of which takes less than 51ms, so a single
instruction in serve, send, receive, and arbitrate subroutines
does the job, with no need to explicitly switch back to fast mode.

I'd venture to say that a very large fraction of timing-critical
code cases can be handled in exactly the same way.

(After Apple released the IIc+, I supposed that they had endorsed
this acceleration switching mechanism, and was surprised to find
that only the "go slow/go fast" switch mechanism was supported by
the IIgs.)

>> In my sound synthesis code, the problem of rests does not arise,
>> because a "rest" is actually a continuous stream of 22kHz speaker
>> pulses, so speaker references never actually stop.
>
>
> PWM can't have problems with ZipChip. I was thinking simpler one-voice
> output.

Certainly the common case, and one that is very common if, for
example, animation is interspersed with sound generation.

>> I've never heard of any program that is incompatible with the
>> "50ms slowdown" approach, though as Vlad points out, one could
>> easily be constructed by using a timed disk access delay in
>> excess of 50ms.
>
>
> The one that bit me nasty with HDDD A2 - very popular disk copy program
> (I think it was Locksmith) doing simple timed delay on drive spin-up.
> With 4 MHz ZipChip this delay goes less than 200 msec and it's a bit of
> a miracle that regular Disk II drive is still able to write reliable data.

Yes, that makes sense. RWTS uses an "interactive" method which
is served well by the Zip Chip approach, but a simple long-delay
loop would fail.

Giving a Disk ][ about one rotation to get up to speed is
certainly pushing the specification! But I suppose it isn't
surprising that it can do it. The drive motor is quite capable,
the belt is relatively "stiff", and the disk and spindle moment
of inertia is small.

>> Besides not being particularly useful, such a timed delay would
>> need to be quite tolerant of variations, since 50ms is 1/4th of
>> a rotation, and normal disk speed variations would result in a
>> significant variance in track position after such a long delay.
>
>
> By quick calculation variation in position (relative to track) due to
> disk speed seems to be within +/- 4%, which is comparable to one sector,
> so a very pathologically synthetical case seems still possible.

Yes, I can imagine a copy-protection scheme that used track sync
with a delay, though I can't quickly come up with anything that
would benefit from using such a delay...

>> For cases where a shorter slowdown is appropriate, a reference
>> to the paddle timer trigger will cause the Zip Chip to slow down
>> for about 7ms, IIRC, if the chip's mode is set for paddle slowdown.
>
>
> Ouch, I forgot that paddle and speaker enjoy much smaller delay - about
> 5 msec. That makes my sound prediction much much worse. ;-)

It sure does. In fact, any simple tone under 100Hz will be
increased since part of its timing loop is accelerated.

[Michael J. Mahon]

Note that blanking just turns off the electron beam. The actual
vertical and horizontal retrace don't start until about halfway
through the horizontal sync pulse and the vertical sync pulses,
respectively.

So blanking starts, retrace starts, retrace completes and normal
scan begins, then blanking ends. The relative positioning of the
sync pulse(s) within the blanking interval determines the "framing"
of the raster.

[Vladimir Ivanov]

On Sat, 11 Feb 2012, Michael J. Mahon wrote:

> Vladimir Ivanov wrote:
>>
>> On Fri, 10 Feb 2012, Michael J. Mahon wrote:
>>
>>> I develop on a Zip Chip-equipped //e, so all my cycle-counted code
>>> depends on temporarily disabling the acceleration it provides.
>>
>>
>> Yes, as long as they are cyclic enough.
>>
>>> In NadaNet, my approach is to reference the "motor off" softswitch
>>> repeatedly (more often than every 50ms) in NadaNet arbitrate, send,
>>> and receive code. I find this approach much simpler than the IIgs
>>> approach of using multiple instructions to set and reset a speed
>>> toggle.
>>
>>
>> This is definitely a very specific corner case. :-)
>
> But it is a quite general technique for disabling acceleration
> in timing-critical code that has a loop period of less than 50ms.
>
> In the case of NadaNet, the maximum packet size is 256 bytes, plus
> an 8-byte header, all of which takes less than 51ms, so a single
> instruction in serve, send, receive, and arbitrate subroutines
> does the job, with no need to explicitly switch back to fast mode.
>
> I'd venture to say that a very large fraction of timing-critical
> code cases can be handled in exactly the same way.

I can see the utility in the ZipChip one-shot throttle mode. But also I am
personally slightly disturbed by the unnecessary debugging it caused me,
so a mixture of this and IIgs' disk-on mode would've been better. ;-)

> (After Apple released the IIc+, I supposed that they had endorsed
> this acceleration switching mechanism, and was surprised to find
> that only the "go slow/go fast" switch mechanism was supported by
> the IIgs.)

The IIgs predates IIc+. IIgs has only on/off mode because they solved I/O
timing differently - mostly by putting the I/O drivers C100..CFFF behind
the slow-clocked Mega II. What needed special attention was Disk II and
thus the user-configurable slot 4/5/6/7 disk-on detection came.

I see the IIgs approach as more deterministic and free from the burden of
carefully tuning loops.

>> PWM can't have problems with ZipChip. I was thinking simpler one-voice
>> output.
>
> Certainly the common case, and one that is very common if, for
> example, animation is interspersed with sound generation.

Game would be possibly unplayable under acceleration if the music is not
always on. :-)

>> The one that bit me nasty with HDDD A2 - very popular disk copy program (I
>> think it was Locksmith) doing simple timed delay on drive spin-up. With 4
>> MHz ZipChip this delay goes less than 200 msec and it's a bit of a miracle
>> that regular Disk II drive is still able to write reliable data.
>
> Yes, that makes sense. RWTS uses an "interactive" method which
> is served well by the Zip Chip approach, but a simple long-delay
> loop would fail.

Yes. Locksmith is smart and simple enough to just do a delay.

> Giving a Disk ][ about one rotation to get up to speed is
> certainly pushing the specification!

It's even slightly short of one revolution with 4 MHz Zip (IIc+). Higher
speeds will shrink some more.

> But I suppose it isn't surprising that it can do it. The drive motor is
> quite capable, the belt is relatively "stiff", and the disk and spindle
> moment of inertia is small.

It might oscillate when the writing begins (it was track writing after the
big delay) so the written pulses will jitter. Hopefully Disk II sequencer
handles that.

I have tested then with a 3rd party half-height floppy drive that is
direct-drive (no belt, heavy spindle load for inertia) and it still seemed
to work. Pure luck.

If somebody has 8 MHz or more Zip/IIc+ they can test - it must've been
Locksmith Fast Disk Copy, when the target drive spins up and begins
writing tracks. The first track written after spin up might fail.

> Yes, I can imagine a copy-protection scheme that used track sync
> with a delay, though I can't quickly come up with anything that
> would benefit from using such a delay...

Internal memory movement, decompression or decryption, then track change
to an expected sector for further encrypted code/data.

[Michael J. Mahon]

Vladimir Ivanov wrote:
>
> On Sat, 11 Feb 2012, Michael J. Mahon wrote:
>
>> Vladimir Ivanov wrote:
>>
>>>
>>> On Fri, 10 Feb 2012, Michael J. Mahon wrote:
>>>
>>>> I develop on a Zip Chip-equipped //e, so all my cycle-counted code
>>>> depends on temporarily disabling the acceleration it provides.
>>>
>>>
>>>
>>> Yes, as long as they are cyclic enough.
>>>
>>>> In NadaNet, my approach is to reference the "motor off" softswitch
>>>> repeatedly (more often than every 50ms) in NadaNet arbitrate, send,
>>>> and receive code. I find this approach much simpler than the IIgs
>>>> approach of using multiple instructions to set and reset a speed
>>>> toggle.
>>>
>>>
>>>
>>> This is definitely a very specific corner case. :-)
>>
>>
>> But it is a quite general technique for disabling acceleration
>> in timing-critical code that has a loop period of less than 50ms.
>>
>> In the case of NadaNet, the maximum packet size is 256 bytes, plus
>> an 8-byte header, all of which takes less than 51ms, so a single
>> instruction in serve, send, receive, and arbitrate subroutines
>> does the job, with no need to explicitly switch back to fast mode.
>>
>> I'd venture to say that a very large fraction of timing-critical
>> code cases can be handled in exactly the same way.
>
>
> I can see the utility in the ZipChip one-shot throttle mode. But also I
> am personally slightly disturbed by the unnecessary debugging it caused
> me, so a mixture of this and IIgs' disk-on mode would've been better. ;-)

I agree, but for backward compatibility, the 50ms trigger approach
was a fine approach--just not perfect. Now if the "fast/slow" switch
of the IIgs were a simple softswitch, I'd be even happier.

>> (After Apple released the IIc+, I supposed that they had endorsed
>> this acceleration switching mechanism, and was surprised to find
>> that only the "go slow/go fast" switch mechanism was supported by
>> the IIgs.)
>
>
> The IIgs predates IIc+. IIgs has only on/off mode because they solved
> I/O timing differently - mostly by putting the I/O drivers C100..CFFF
> behind the slow-clocked Mega II. What needed special attention was Disk
> II and thus the user-configurable slot 4/5/6/7 disk-on detection came.
>
> I see the IIgs approach as more deterministic and free from the burden
> of carefully tuning loops.

I'm afraid that shows how little time I spent thinking about the IIgs...

A fairly long 50ms timout allows for pretty simple/sloppy tuning!

>>> PWM can't have problems with ZipChip. I was thinking simpler
>>> one-voice output.
>>
>>
>> Certainly the common case, and one that is very common if, for
>> example, animation is interspersed with sound generation.
>
>
> Game would be possibly unplayable under acceleration if the music is not
> always on. :-)
>
>>> The one that bit me nasty with HDDD A2 - very popular disk copy
>>> program (I think it was Locksmith) doing simple timed delay on drive
>>> spin-up. With 4 MHz ZipChip this delay goes less than 200 msec and
>>> it's a bit of a miracle that regular Disk II drive is still able to
>>> write reliable data.
>>
>>
>> Yes, that makes sense. RWTS uses an "interactive" method which
>> is served well by the Zip Chip approach, but a simple long-delay
>> loop would fail.
>
>
> Yes. Locksmith is smart and simple enough to just do a delay.

But the RWTS approach detects that the motor is still on and
doesn't wait at all--even smarter. ;-)

[Steve Nickolas]

On Wed, 15 Feb 2012, Michael J. Mahon wrote:

> I agree, but for backward compatibility, the 50ms trigger approach
> was a fine approach--just not perfect. Now if the "fast/slow" switch
> of the IIgs were a simple softswitch, I'd be even happier.

Though if software is GS-aware and needs to cripple itself to 1 MHz there
is a softswitch.

I used to have a modified version of NEWBASIC LOADER (from Beagle Basic)
that loaded a neutral modified ][+ ROM then clocked a GS down to 1 MHz and
set the colors to white on black.

-uso.

[Antoine Vignau]

38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60 will set to slow speed
on a IIgs only.

IIRC, disk accesses on slot 6 are automatically switched to slow speed
on the IIgs,
av

[Michael J. Mahon]

Steve Nickolas wrote:
> On Wed, 15 Feb 2012, Michael J. Mahon wrote:
>
>> I agree, but for backward compatibility, the 50ms trigger approach
>> was a fine approach--just not perfect. Now if the "fast/slow" switch
>> of the IIgs were a simple softswitch, I'd be even happier.
>
>
> Though if software is GS-aware and needs to cripple itself to 1 MHz
> there is a softswitch.

I thought it involved reading a loaction, modifying a bit, and replacing
it. So it requires that the accumulator be free.

If there's a one-instruction way, I'd like to know.

[ict@ccess]

Have you tried

CLC
ROR $C036

the rest of the bits are not being used in $C036 and this has no
effect on non IIGS computers

Rob

[Michael J. Mahon]

Looks good! I'll see if it helps. (I still have
a multiple-exit problem...)

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[Vladimir Ivanov]

On Wed, 15 Feb 2012, Michael J. Mahon wrote:

>> I can see the utility in the ZipChip one-shot throttle mode. But also I am
>> personally slightly disturbed by the unnecessary debugging it caused me, so
>> a mixture of this and IIgs' disk-on mode would've been better. ;-)
>
> I agree, but for backward compatibility, the 50ms trigger approach
> was a fine approach--just not perfect. Now if the "fast/slow" switch
> of the IIgs were a simple softswitch, I'd be even happier.

But isn't it simpler than ZipChip's lock/unlock sequence required for
on/off change?

The IIgs manual recommends TSB/TRB instructions for manipulating the bits,
so you have the one-instruction approach. Except it does not work on NMOS
6502.

>>> Yes, that makes sense. RWTS uses an "interactive" method which
>>> is served well by the Zip Chip approach, but a simple long-delay
>>> loop would fail.
>>
>>
>> Yes. Locksmith is smart and simple enough to just do a delay.
>
> But the RWTS approach detects that the motor is still on and
> doesn't wait at all--even smarter. ;-)

That was my small attempt at humor. :-)

Actually, RWTS mostly does read/write sectors. Did it use the same
approach for spin-on before formatting? Can't remember without looking at
the code.

In Locksmith's defense, it does a whole track write ("Fast Backup"). I'd
have done it exactly the same way - simple delay.

[Vladimir Ivanov]

On Thu, 16 Feb 2012, ict@ccess wrote:

> On Feb 16, 7:29 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

>> If there's a one-instruction way, I'd like to know.
>

> Have you tried
>
> CLC
> ROR $C036
>
> the rest of the bits are not being used in $C036 and this has no
> effect on non IIGS computers

As I just mentioned, TSB/TRB for 65C02, 65802 and 65816.

$C036 is full of other bits - there's the slot 4/5/6/7 disk-on control,
there's the global shadowing bit, the ROM3 motherboard power-on bit, and
even one reserved bit. Usually only slot 6 is set for compatibility and
the bank shadowing is zero.

Modifying with rotate seems catastrophical to me, even if it doesn't bite
you at the instant.


Also, ROR $C036 on non-IIgs computers will toggle the speaker few times.
:-) Just as any other access to $C030 .. $C03F.

[Antoine Vignau]

Second try!

The HEX way:

38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60
38 20 1F FE 90 01 60 AD 36 C0 29 7F 8D 36 C0 60

The ASM way:
SEC
JSR IDROUTINE ($FE1F)
BCC iigs
RTS

iigs:
LDA $C036
AND £%0111_1111
STA $C036
RTS

av :-)

[Vladimir Ivanov]

A-ha, that must be what "Safe Hex" is like.


In little more seriousness:

LDA #$80
TRB $C036

is bit shorter and safer (atomic). There's this miniscule opportunity for
the user to go into CDA just after "LDA $C036" and mess with the settings.

[ict@ccess]

My Apple IIGS technical reference manual does not even list $C036, but
even if all these bits are used on startup as you say, then they can
be preserved since they don't have any immediate effect on any
hardware, other than possibly the shadow bit. But I notice that
shadowing does not take effect until something is stored in shadowed
memory, but turning of shadowing of any screen, text or graphics, ,
then immediately back on should not show any effects on the screen.
To preserve the $C036 register without using the accumulator, you can
do it this way

CLC
ASL C036
ROR C036

[ict@ccess]

Missed a CLC

should be

CLC
ASL C036
CLC
ROR C036

So, yes this works

Type in this program and you can hear the difference

300:A2 10 20 20 03 CA D0 FA A0 00 88 D0 FD 18 0E 36
310:C0 18 6E 36 C0 A2 10 20 20 03 CA D0 FA 60 00 00
320:A9 20 85 A4 A9 02 20 A8 FC 8D 30 C0 A9 24 20 A8
330:FC 8D 30 C0 C6 A4 D0 EC 60 D0 EC 60 00 00 00 00

Nothing else is affected and probably only works on a real IIGS

Rob

[Antoine Vignau]

If there's one softswitch we shouldn't play with, this is CYAREG
($C036) on the IIgs. One bit handles shadowing in all RAM banks and
that should be used with precaution.

Please prefer Vlad's or my code to set the fast/slow mode switch,
otherwise the behaviour of the IIgs is not guaranteed:

38 20 1F FE B0 05 A9 80 1C 36 C0 xx xx

SEC
JSR IDROUTINE ($FE1F)
BCS notiigs
LDA #%1000_0000
TRB CYAREG ($C036)

notiigs:
xx
xx

[ict@ccess]

Unless I misunderstood Mike, he wanted to keep the ACC free.



Mikes Quote "I thought it involved reading a loaction, modifying a

[Vladimir Ivanov]

On Fri, 17 Feb 2012, ict@ccess wrote:

> Unless I misunderstood Mike, he wanted to keep the ACC free.
>
>
>
> Mikes Quote "I thought it involved reading a loaction, modifying a
> bit, and replacing
> it. So it requires that the accumulator be free. "

Yes, I also think he prefers Acc to be unclobbered.

[Vladimir Ivanov]

On Fri, 17 Feb 2012, ict@ccess wrote:

>> My Apple IIGS technical reference manual does not even list $C036

Check the Hardware Reference, page twenty-something IIRC.

>> but even if all these bits are used on startup as you say, then they
>> can be preserved since they don't have any immediate effect on any
>> hardware, other than possibly the shadow bit.  But I notice that
>> shadowing does not take effect until something is stored in shadowed
>> memory, but turning of shadowing of any screen, text or graphics, ,
>> then immediately back on should not show any effects on the screen. To
>> preserve the $C036 register without using the accumulator, you can do
>> it this way
>>
>> CLC
>> ASL C036
>> ROR C036
>
> Missed a CLC
>
> should be
>
> CLC
> ASL C036
> CLC
> ROR C036
>
> So, yes this works
>
> Type in this program and you can hear the difference
>
> 300:A2 10 20 20 03 CA D0 FA A0 00 88 D0 FD 18 0E 36
> 310:C0 18 6E 36 C0 A2 10 20 20 03 CA D0 FA 60 00 00
> 320:A9 20 85 A4 A9 02 20 A8 FC 8D 30 C0 A9 24 20 A8
> 330:FC 8D 30 C0 C6 A4 D0 EC 60 D0 EC 60 00 00 00 00
>
> Nothing else is affected and probably only works on a real IIGS

The problems here are:
- eventual write on reserved bit (don't know what value it is)
- eventual write on global shadow enable bit (should be 0)

If we assume that all floppy disks are off, shuffling their enable values
for a bit isn't a problem.

For the two problematic bits, trouble might arise if CDA is entered at
this time or an interrupt occurs. Global enabling of shadowing will make
each page (not just $00 and $01) thrash something in $E0/$E1.

Disabling interrupts (which I think also disables CDA?) should prevent
this. I guess Michael's case is his PWM, so interrupts are disabled. I
just want to stress upon the risks of this technique for general use.

As to the reserved bit - no idea what the ASIC does with it. I wouldn't
change it myself.

[ict@ccess]

Nooooooo! Please prefer my code. :)

I agree with you that your way is the right way.

And on a discussion point of view, my understanding was that the goal
was to keep the ACC free.

I don't want to get into the hardware aspect of this discussion of
what happens to the hardware when the bits get changed in this
register.

So as a final note I am making a disclaimer.

Use my way at your own risk! :)

[Antoine Vignau]

On 17 fév, 15:49, "ict@ccess" <gids...@sasktel.net> wrote:
>
> Nooooooo!  Please prefer my code. :)
>
> I agree with you that your way is the right way.
>
> And on a discussion point of view, my understanding was that the goal
> was to keep the ACC free.
>
> I don't want to get into the hardware aspect of this discussion of
> what happens to the hardware when the bits get changed in this
> register.
>
> So as a final note I am making a disclaimer.
>
> Use my way at your own risk!  :)

:-)
OK OK, I missed the accumulator-free request!

PHA
SEC
JSR IDROUTINE ($FE1F)
BCS notiigs:

PHP
SEI

LDA #%1000_0000
TRB CYAREG ($C036)

PLP

notiigs:
PLA
xx
xx

===

I like the carry way :-)
av

[Vladimir Ivanov]

On Fri, 17 Feb 2012, Antoine Vignau wrote:

> PHP
> SEI
> LDA #%1000_0000
> TRB CYAREG ($C036)
> PLP

Toto, you don't need the interrupt disable/enable. That's the beauty of
the atomic TRB (read-modify-write).

[Antoine Vignau]

I know, I know but who knows with ROM 5???

ah ah hah ahaahahahahahahahahahahahahahahahahahahahhhhhh :-)

av

[Jerry]

"ict@ccess" <gid...@sasktel.net> writes:

> On Feb 17, 7:22 am, "ict@ccess" <gids...@sasktel.net> wrote:
>
> Missed a CLC
>
> should be
>
> CLC
> ASL C036
> CLC
> ROR C036

Not really sure why you wouldn't just do:

ASL $c036
LSR $c036

CLC is pointless when followed by ASL, and CLC, ROR is the same as LSR.

What am I missing?


--
--
Jerry awanderin at yahoo dot ca

[ict@ccess]

On Feb 29, 11:25 pm, Jerry <awande...@yahoo.ca> wrote:

> "ict@ccess" <gids...@sasktel.net> writes:
> > On Feb 17, 7:22 am, "ict@ccess" <gids...@sasktel.net> wrote:
>
> > Missed a CLC
>
> > should be
>
> > CLC
> > ASL C036
> > CLC
> > ROR C036
>
> Not really sure why you wouldn't just do:
>
>   ASL $c036
>   LSR $c036
>
> CLC is pointless when followed by ASL, and CLC, ROR is the same as LSR.
>
> What am I missing?

Good catch.
Usually, I type without thinking, then I start to second guess what I
type. Then I get confused with the instructions of where the carry
goes with an ASL ROL LSR ROR. Then I left the CLC instruction in play
to show the preservation of the LSB bit going one way and the MSB
going the other way. Then I ....

Oh Hell! I screwed up. :)