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

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

Re: Uthernet II manual updated, probe algorithm corrected

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Uthernet II manual updated, probe algorithm corrected D Finnigan <dog_cow@macgui.com> - 2016-01-08 17:49 +0000
    Re: Uthernet II manual updated, probe algorithm corrected David Schmenk <dschmenk@gmail.com> - 2016-01-08 22:38 -0800
      Re: Uthernet II manual updated, probe algorithm corrected D Finnigan <dog_cow@macgui.com> - 2016-01-09 21:33 +0000
        Re: Uthernet II manual updated, probe algorithm corrected David Schmenk <dschmenk@gmail.com> - 2016-01-09 14:24 -0800
          Re: Uthernet II manual updated, probe algorithm corrected dempson@actrix.gen.nz (David Empson) - 2016-01-10 15:07 +1300
            Re: Uthernet II manual updated, probe algorithm corrected David Schmenk <dschmenk@gmail.com> - 2016-01-10 07:56 -0800
              Re: Uthernet II manual updated, probe algorithm corrected dempson@actrix.gen.nz (David Empson) - 2016-01-11 10:11 +1300
                Re: Uthernet II manual updated, probe algorithm corrected David Schmenk <dschmenk@gmail.com> - 2016-01-11 08:59 -0800

#2069 — Re: Uthernet II manual updated, probe algorithm corrected

D Finnigan wrote:
> The programming section is pretty good, but still not complete. Today I
> added a new section on probing for the Uthernet II on page 37. It suggests
> an algorithm to use for programmatically detecting the presence of the
> Uthernet II based on the behavior of the W5100 chip. I also fixed some
> typos
> in the manual, including one in the sample source code on page 23.
> 
> Visit the http://a2retrosystems.com/ web site, and click the manual link
> where it says "Please download the manual".
> 

I updated the manual again today to correct the new Uthernet II/W5100
probing algorithm on page 37. It failed to detect the W5100 if it had
previously been used and its internal address pointer was not at zero.

I had *assumed* that sending the $80 software reset command to the W5100
would also reset the internal address pointer to 0, but noooooooo, that
doesn't happen.

So I removed the last test which was to LDA $C0x7,X and CMP #3, because we
can't assume the state of the address pointer.

Hum-ho…..

Also coming soon: an improved and less headache-inducing data transfer loop
that eradicates that ridiculous split-copy algorithm for buffer wraparound.
Ugh.

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[toc] | [next] | [standalone]

#2072

On Friday, 8 January 2016 20:04:26 UTC-8, D Finnigan  wrote:
> D Finnigan wrote:
> > The programming section is pretty good, but still not complete. Today I
> > added a new section on probing for the Uthernet II on page 37. It suggests
> > an algorithm to use for programmatically detecting the presence of the
> > Uthernet II based on the behavior of the W5100 chip. I also fixed some
> > typos
> > in the manual, including one in the sample source code on page 23.
> > 
> > Visit the http://a2retrosystems.com/ web site, and click the manual link
> > where it says "Please download the manual".
> > 
> 
> I updated the manual again today to correct the new Uthernet II/W5100
> probing algorithm on page 37. It failed to detect the W5100 if it had
> previously been used and its internal address pointer was not at zero.
> 
> I had *assumed* that sending the $80 software reset command to the W5100
> would also reset the internal address pointer to 0, but noooooooo, that
> doesn't happen.
> 
> So I removed the last test which was to LDA $C0x7,X and CMP #3, because we
> can't assume the state of the address pointer.
> 
> Hum-ho.....
> 
> Also coming soon: an improved and less headache-inducing data transfer loop
> that eradicates that ridiculous split-copy algorithm for buffer wraparound.
> Ugh.
> 
> -- 
> ]DF$
> The Marina IP stack for Apple II--
> http://marina.a2hq.com/

David-

I read the pointer first and see if it gets incremented by a read instead of assuming it starts at zero. Seems to work well for me.

Dave...

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

#2083

David Schmenk wrote:
> 
> David-
> 
> I read the pointer first and see if it gets incremented by a read instead
> of assuming it starts at zero. Seems to work well for me.

Thanks for the suggestion. How much of a concern do you think it is to be
blindly poking at the $C0 space? In other words, do you have personal
experience or anecdotal evidence that other peripherals may be affected?

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

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

#2086

On Saturday, 9 January 2016 13:35:47 UTC-8, D Finnigan  wrote:
> David Schmenk wrote:
> > 
> > David-
> > 
> > I read the pointer first and see if it gets incremented by a read instead
> > of assuming it starts at zero. Seems to work well for me.
> 
> Thanks for the suggestion. How much of a concern do you think it is to be
> blindly poking at the $C0 space? In other words, do you have personal
> experience or anecdotal evidence that other peripherals may be affected?
> 
> -- 
> ]DF$
> The Marina IP stack for Apple II--
> http://marina.a2hq.com/

Well, there is always a chance it could mess something up. Reading is usually somewhat benign - you may clear a status bit or something. The best approach is to probably look for a ROM signature in the slot first, and skip it unless its slot 3. I don't know of any other phantom ROM except for the //e 80 column card that would be present in the same slot as the Uthernet. Multi-IO perhaps?

Other than that, if I poke something that doesn't work out, I try to restore the value I found when I got there. I've had better success with the Uthernet II than the Uthernet I (which I can find the first time, not afterwards).

Dave...

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

#2087

David Schmenk <dschmenk@gmail.com> wrote:

> On Saturday, 9 January 2016 13:35:47 UTC-8, D Finnigan  wrote:
> > David Schmenk wrote:
> > > 
> > > David-
> > > 
> > > I read the pointer first and see if it gets incremented by a read instead
> > > of assuming it starts at zero. Seems to work well for me.
> > 
> > Thanks for the suggestion. How much of a concern do you think it is to be
> > blindly poking at the $C0 space? In other words, do you have personal
> > experience or anecdotal evidence that other peripherals may be affected?
> 
> Well, there is always a chance it could mess something up. Reading is
> usually somewhat benign - you may clear a status bit or something.

There are many cards where merely reading a soft switch will do
something to it. Off the top of my head:

- A RAMFactor or similar will auto-increment its address register if you
read its data register. In that case, it is probably innocuous, because
the driver will set the address register before transferring data
to/from it.

- Reading the input buffer register from a serial card will lose the
received character.

- Disk ][ controller motor control is activated by reading $C0n9.

> The best approach is to probably look for a ROM signature in the slot
> first, and skip it unless its slot 3. I don't know of any other phantom
> ROM except for the //e 80 column card that would be present in the same
> slot as the Uthernet. Multi-IO perhaps?

The Apple IIgs, where some slots have built-in firmware mapped to $CnXX
but don't use the $C0nX space for their I/O. For some of these, the I/O
addresses are accessible from a card in the slot while the internal
firmware is active. (I don't know if I still have enough reference
material handy to confirm the details - I've thrown out most of my Apple
II books and manuals due to water damage a few years ago.)

> Other than that, if I poke something that doesn't work out, I try to
> restore the value I found when I got there. I've had better success with
> the Uthernet II than the Uthernet I (which I can find the first time, not
> afterwards).

-- 
David Empson
dempson@actrix.gen.nz

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

#2092

On Saturday, 9 January 2016 18:07:22 UTC-8, David Empson  wrote:
> David Schmenk <dschmenk@gmail.com> wrote:
> 
> > On Saturday, 9 January 2016 13:35:47 UTC-8, D Finnigan  wrote:
> > > David Schmenk wrote:
> > > > 
> > > > David-
> > > > 
> > > > I read the pointer first and see if it gets incremented by a read instead
> > > > of assuming it starts at zero. Seems to work well for me.
> > > 
> > > Thanks for the suggestion. How much of a concern do you think it is to be
> > > blindly poking at the $C0 space? In other words, do you have personal
> > > experience or anecdotal evidence that other peripherals may be affected?
> > 
> > Well, there is always a chance it could mess something up. Reading is
> > usually somewhat benign - you may clear a status bit or something.
> 
> There are many cards where merely reading a soft switch will do
> something to it. Off the top of my head:
> 
> - A RAMFactor or similar will auto-increment its address register if you
> read its data register. In that case, it is probably innocuous, because
> the driver will set the address register before transferring data
> to/from it.
> 
> - Reading the input buffer register from a serial card will lose the
> received character.
> 

That was the case that came to mind, it clears the character available status.

> - Disk ][ controller motor control is activated by reading $C0n9.
> 
> > The best approach is to probably look for a ROM signature in the slot
> > first, and skip it unless its slot 3. I don't know of any other phantom
> > ROM except for the //e 80 column card that would be present in the same
> > slot as the Uthernet. Multi-IO perhaps?
> 
> The Apple IIgs, where some slots have built-in firmware mapped to $CnXX
> but don't use the $C0nX space for their I/O. For some of these, the I/O
> addresses are accessible from a card in the slot while the internal
> firmware is active. (I don't know if I still have enough reference
> material handy to confirm the details - I've thrown out most of my Apple
> II books and manuals due to water damage a few years ago.)

Right, probably like the mouse firmware on a //c or IIIgs.

> 
> > Other than that, if I poke something that doesn't work out, I try to
> > restore the value I found when I got there. I've had better success with
> > the Uthernet II than the Uthernet I (which I can find the first time, not
> > afterwards).
> 
> -- 
> David Empson
> dempson@actrix.gen.nz

Perhaps looking for a ROM *boot* signature would be better? There could be phantom disk slots though. Does the 3.5 drive firmware do that for slot 5? Ugh.

Dave...

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

#2096

David Schmenk <dschmenk@gmail.com> wrote:

> On Saturday, 9 January 2016 18:07:22 UTC-8, David Empson  wrote:
> > David Schmenk <dschmenk@gmail.com> wrote:
> > 
> > > On Saturday, 9 January 2016 13:35:47 UTC-8, D Finnigan  wrote:
> > > > David Schmenk wrote:
> > > > > 
> > > > > David-
> > > > > 
> > > > > I read the pointer first and see if it gets incremented by a read
> > > > > instead of assuming it starts at zero. Seems to work well for me.
> > > > 
> > > > Thanks for the suggestion. How much of a concern do you think it is
> > > > to be blindly poking at the $C0 space? In other words, do you have
> > > > personal experience or anecdotal evidence that other peripherals may
> > > > be affected?
> > > 
> > > Well, there is always a chance it could mess something up. Reading is
> > > usually somewhat benign - you may clear a status bit or something.
> > 
> > There are many cards where merely reading a soft switch will do
> > something to it. Off the top of my head:
> > 
> > - A RAMFactor or similar will auto-increment its address register if you
> > read its data register. In that case, it is probably innocuous, because
> > the driver will set the address register before transferring data
> > to/from it.
> > 
> > - Reading the input buffer register from a serial card will lose the
> > received character.
> 
> That was the case that came to mind, it clears the character available status.
> 
> > - Disk ][ controller motor control is activated by reading $C0n9.
> > 
> > > The best approach is to probably look for a ROM signature in the slot
> > > first, and skip it unless its slot 3. I don't know of any other phantom
> > > ROM except for the //e 80 column card that would be present in the same
> > > slot as the Uthernet. Multi-IO perhaps?
> > 
> > The Apple IIgs, where some slots have built-in firmware mapped to $CnXX
> > but don't use the $C0nX space for their I/O. For some of these, the I/O
> > addresses are accessible from a card in the slot while the internal
> > firmware is active. (I don't know if I still have enough reference
> > material handy to confirm the details - I've thrown out most of my Apple
> > II books and manuals due to water damage a few years ago.)
> 
> Right, probably like the mouse firmware on a //c or IIIgs.
> 
> > 
> > > Other than that, if I poke something that doesn't work out, I try to
> > > restore the value I found when I got there. I've had better success with
> > > the Uthernet II than the Uthernet I (which I can find the first time, not
> > > afterwards).
> 
> Perhaps looking for a ROM *boot* signature would be better? There could be
> phantom disk slots though. Does the 3.5 drive firmware do that for slot 5?
> Ugh.

Certainly looking for the ROM signature of a Disk ][ controller or other
bootable ProDOS/SmartPort devices would be a good start.

The 3.5 drive remapping logic is not in the firmware or hardware, it is
done as a logical remapping within the ProDOS MLI.

ProDOS-8 1.2 and later map slot 5 drives 3 and 4 to slot 2 unit numbers,
if there is a suitable card in slot 5, such as the //c or IIgs SmartPort
controller, and nothing that looks like a disk controller in slot 2.
This doesn't affect other cards such as a serial interface in slot 2,
nor its I/O locations.

ProDOS-8 2.x extends this to remapping drives/volumes from SmartPort
controllers in any slot to any "unused" slot, e.g a SCSI card in slot 7
of a IIgs could use the unit numbrs for slots 1, 2, 3 (drive 1 only) and
4, potentially giving it nine units including the two from its own slot
(assuming those slots had no disk controller and weren't already being
used for "overflow" units from slot 5).

The other type of card that can be reliably detected by ROM signature is
serial/parallel interfaces using the BASIC and Pascal firmware
interface, which includes many 80-column cards.

-- 
David Empson
dempson@actrix.gen.nz

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

#2100

On Sunday, 10 January 2016 13:11:29 UTC-8, David Empson  wrote:
> David Schmenk <dschmenk@gmail.com> wrote:
> 
> > On Saturday, 9 January 2016 18:07:22 UTC-8, David Empson  wrote:
> > > David Schmenk <dschmenk@gmail.com> wrote:
> > > 
> > > > On Saturday, 9 January 2016 13:35:47 UTC-8, D Finnigan  wrote:
> > > > > David Schmenk wrote:
> > > > > > 
> > > > > > David-
> > > > > > 
> > > > > > I read the pointer first and see if it gets incremented by a read
> > > > > > instead of assuming it starts at zero. Seems to work well for me.
> > > > > 
> > > > > Thanks for the suggestion. How much of a concern do you think it is
> > > > > to be blindly poking at the $C0 space? In other words, do you have
> > > > > personal experience or anecdotal evidence that other peripherals may
> > > > > be affected?
> > > > 
> > > > Well, there is always a chance it could mess something up. Reading is
> > > > usually somewhat benign - you may clear a status bit or something.
> > > 
> > > There are many cards where merely reading a soft switch will do
> > > something to it. Off the top of my head:
> > > 
> > > - A RAMFactor or similar will auto-increment its address register if you
> > > read its data register. In that case, it is probably innocuous, because
> > > the driver will set the address register before transferring data
> > > to/from it.
> > > 
> > > - Reading the input buffer register from a serial card will lose the
> > > received character.
> > 
> > That was the case that came to mind, it clears the character available status.
> > 
> > > - Disk ][ controller motor control is activated by reading $C0n9.
> > > 
> > > > The best approach is to probably look for a ROM signature in the slot
> > > > first, and skip it unless its slot 3. I don't know of any other phantom
> > > > ROM except for the //e 80 column card that would be present in the same
> > > > slot as the Uthernet. Multi-IO perhaps?
> > > 
> > > The Apple IIgs, where some slots have built-in firmware mapped to $CnXX
> > > but don't use the $C0nX space for their I/O. For some of these, the I/O
> > > addresses are accessible from a card in the slot while the internal
> > > firmware is active. (I don't know if I still have enough reference
> > > material handy to confirm the details - I've thrown out most of my Apple
> > > II books and manuals due to water damage a few years ago.)
> > 
> > Right, probably like the mouse firmware on a //c or IIIgs.
> > 
> > > 
> > > > Other than that, if I poke something that doesn't work out, I try to
> > > > restore the value I found when I got there. I've had better success with
> > > > the Uthernet II than the Uthernet I (which I can find the first time, not
> > > > afterwards).
> > 
> > Perhaps looking for a ROM *boot* signature would be better? There could be
> > phantom disk slots though. Does the 3.5 drive firmware do that for slot 5?
> > Ugh.
> 
> Certainly looking for the ROM signature of a Disk ][ controller or other
> bootable ProDOS/SmartPort devices would be a good start.
> 
> The 3.5 drive remapping logic is not in the firmware or hardware, it is
> done as a logical remapping within the ProDOS MLI.
> 
> ProDOS-8 1.2 and later map slot 5 drives 3 and 4 to slot 2 unit numbers,
> if there is a suitable card in slot 5, such as the //c or IIgs SmartPort
> controller, and nothing that looks like a disk controller in slot 2.
> This doesn't affect other cards such as a serial interface in slot 2,
> nor its I/O locations.
> 
> ProDOS-8 2.x extends this to remapping drives/volumes from SmartPort
> controllers in any slot to any "unused" slot, e.g a SCSI card in slot 7
> of a IIgs could use the unit numbrs for slots 1, 2, 3 (drive 1 only) and
> 4, potentially giving it nine units including the two from its own slot
> (assuming those slots had no disk controller and weren't already being
> used for "overflow" units from slot 5).
> 
> The other type of card that can be reliably detected by ROM signature is
> serial/parallel interfaces using the BASIC and Pascal firmware
> interface, which includes many 80-column cards.
> 
> -- 
> David Empson
> dempson@actrix.gen.nz

Thanks for the nice description. I'll look into incorporating the ROM signature into the probe algorithm.

Dave...

[toc] | [prev] | [standalone]

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

csiph-web