Address Not Found

www.ivattochtorrt.se could not be found. Please check the name and try again.

The browser could not find the host server for the provided address.

* Did you make a mistake when typing the domain? (e.g. "ww.mozilla.org" instead of "www.mozilla.org")
* Are you certain this domain address exists? Its registration may have expired.
* Are you unable to browse other sites? Check your network connection and DNS server settings.
* Is your computer or network protected by a firewall or proxy? Incorrect settings can interfere with Web browsing.

That's what I got.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

problem at your end, don't know why:
www.ivattochtorrt.se has address 193.202.110.32

you could try adding it to your /etc/hosts of course

Possibly. Since the BIT operation is asynchronous to the operation of the FDC, it's conceivable you are occasionally hitting the register right about when the FDC's internal logic tries to flip whatever internal circuit is in charge of asserting DRQ. So the DRQ flop (or whatever is in there) gets reset before you exit your polling loop. The data sheet may shed some light on it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I ran that machine name against nslookup, which reported that the top-level DNS server (at 4.2.2.2) says there is no DNS server for the ivattochtorrt.se domain that is authoritative. Usually this indicates an improperly configured name server, but could also mean the domain isn't properly registered. As the server here is authoritative for my domains (bcstechnology.com and bcstechnology.net) and fully secured, it will not pass through IP addresses that are served by non-authoritative servers. Adding it to /etc/hosts wouldn't do anything, since all DNS lookups are handled by BIND before being passed on to the local resolver. Hence the non-authoritative response will occur and the request will never be seen through local resolution.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It's a lovely picture!

BDD is right to be on the lookout for issues like that, especially when results are sporadic, which is a meaningful clue. But in this case (according to the schematic), the BIT operation is NOT asynchronous to the operation of the FDC -- the FDC and cpu share the same 2 MHz clock.

Good idea -- I think this will correct your problem. Polling the Status Register is not a good approach. The Western Digital data sheet states, "INTRQ is reset either by reading the status register or [loading a new command]." So, although the intent is to learn the status of the DRQ bit, your polling loop is also capable of clearing an interrupt.

-- Jeff

I can't see the schematic, so I'm guessing.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That did the trick, formating now goes through the entire disk without any hickups and it seems that the correct data is written to the disk. A quick test reading a few sectors worked as expected.

Thanks for all input, I really appreciate it.

The schematic can also be downloaded in the first post of another thread that I am running on a Swedish forum (http://elektronikforumet.com/forum/viewtopic.php?f=3&t=50053)

Oops, I forgot! That's right, you really CAN'T see it! (because the link was giving you trouble)

At first I though you were just joking, BDD. I know you like to make playful remarks about your age, so when you said you couldn't see the schematic I thought you were teasing us young 'uns again -- that your Dinosaur eyes were too ancient to make out the details of the drawing.

-- Jeff

ps- Congrats, PontusO!

I have noticed that the overall performance when doing disk accesses have been quite slow. So yesterday I decided to introduce a sector interleaving scheme to see if i could get the speed up a bit. My algorithm for translating logical sectors to physical maps even sectors to side 0 and odd to side 1 and I wanted (for some reason) to keep that scheme. My first attempt was a bit naive, using a dual side 1:1 scheme (side 1 sectors come directly after side 0) which is no better than a single side disk without interleaving. But it did show that I was on the right track. After a lot of testing with both my own translation algorithm and the one in DOS/65 I ended up with that 1:4 interleave would yield the best diskette performance.

It was indeed a very interesting day with a lot of experimenting, measuring, thinking and ending it with two episodes of Star Trek Enterprise