X-Received: by 10.140.229.6 with SMTP id z6mr1403049qhb.0.1452441373506; Sun, 10 Jan 2016 07:56:13 -0800 (PST) X-Received: by 10.50.225.101 with SMTP id rj5mr180501igc.3.1452441373477; Sun, 10 Jan 2016 07:56:13 -0800 (PST) Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!6no4097700qgy.0!news-out.google.com!l1ni9484igd.0!nntp.google.com!h5no2628968igh.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.sys.apple2.programmer Date: Sun, 10 Jan 2016 07:56:12 -0800 (PST) In-Reply-To: <1mgta11.f2v4tqhqttmaN%dempson@actrix.gen.nz> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.83.118.46; posting-account=BEcBJwoAAADnWuRoZDUhMSNKNGG-dTV7 NNTP-Posting-Host: 71.83.118.46 References: <8d952af9-df3e-4675-b94a-f117edd0c0f4@googlegroups.com> <053d1a75-02a9-48b7-9dc8-c019df995ccd@googlegroups.com> <1mgta11.f2v4tqhqttmaN%dempson@actrix.gen.nz> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4a590ece-e4d6-4641-b844-8be957dfd32d@googlegroups.com> Subject: Re: Uthernet II manual updated, probe algorithm corrected From: David Schmenk Injection-Date: Sun, 10 Jan 2016 15:56:13 +0000 Content-Type: text/plain; charset=ISO-8859-1 Lines: 60 Xref: csiph.com comp.sys.apple2.programmer:2092 On Saturday, 9 January 2016 18:07:22 UTC-8, David Empson wrote: > David Schmenk 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...