Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums

Forums > CSDb Discussions > Error message: "Found more than one drive on IEC bus" with C128D metal and recent demos
2017-11-08 10:26
Monte Carlos

Registered: Jun 2004
Posts: 263
Error message: "Found more than one drive on IEC bus" with C128D metal and recent demos

Sorry for this lamer question. I use an C128D(metal), currently (although i have used C64 for years until i got room problems with the complete setup).
I have attached a 1541 ultimate and changed the internal 1571 drive to device no 10 by cutting the solder pads. The ultimate has dev no 8. This way i can watch many, mostly old, demos with 1541U. However, the most current demos always complain about more than one drive being enabled. Ok, i thought, plugging off the internal 1571 from the mainbord should fix the problem. I was wrong. The loaders still complain about more than one drive.
Am i wrong with my understanding that plugging off the internal drive also disables the ATN signal?
... 34 posts hidden. Click here to view all posts....
2017-11-14 13:47
Monte Carlos

Registered: Jun 2004
Posts: 263
So now some good new:

I tested FLT K9 orange with three settings and displayed active drives beforehand. Drive 8 = 1541u, drive 11=1571:

1.) No script ran -> Drive 8 and 11 shown as active.
Demo loader outputs error message that more than one drive is on the bus

2.) Ran script "OPEN 1,11,15,"M-W"+CHR$(119)+CHR$(0)+CHR$(2)+CHR$(0)+CHR$(0):CLOSE 1" to disable drive 11 -> Only drive 8 shown as active. Demo loader does not output error message but instead just hangs up.

3.) Ran Krills script -> Only drive 8 shown as active. Demo loader works perfectly.

I now created a folder 0_scripts in the base dir of the 1571U and put all those successful and unsuccessful code attemps into a d64 in this folder. This way i can quickly disable the internal 1571 before running any demos.
As remarked by Skate, the d64 should be mounted before running any contents. If they are run directly, you will not receive the "ready." prompt after code has been run.
2017-11-14 14:14

Registered: Apr 2002
Posts: 955
Okay, cool, but do both variants work nicely, with and without "tightloop" enabled? :)
2017-11-14 14:31
Monte Carlos

Registered: Jun 2004
Posts: 263
I did not test this up to now. Currently tightloop = 0.
2017-11-15 12:13
Monte Carlos

Registered: Jun 2004
Posts: 263
Tightloop = 1 also works fine.
2017-11-15 12:24

Registered: Apr 2002
Posts: 955
Alright, great, thanks! I guess i'll also post this on Codebase64 on a boring Sunday or so, since this is a problem that many people might face.
2017-11-15 15:10
Monte Carlos

Registered: Jun 2004
Posts: 263
In common it would be interesting to silence all but one drive before irq-loading sth and then awake drives again after loading or at the end of the production.
2017-11-15 15:53

Registered: Sep 2003
Posts: 1168
Nice work here! I second the "awake" bit. Not entierly trivial. Some kind of more advanced port knocking I guess. Maybe it's sufficient with a sequence of well timed ATN toggles?
2017-11-15 16:05

Registered: Apr 2002
Posts: 955
Yes, this is the hard part and one of the main reasons i haven't added this to former releases of my loaders.
2017-11-15 16:18

Registered: Jul 2007
Posts: 355
But in principle, it shouldn't be too difficult in your case, because your loader already supports many different drives. You could add compile-time switches that modify the drivecode to a dummy version that doesn't read from disk, but still follows the state machine of the communication protocol. It shouldn't actually pull the clock/data lines of course, only ATNA. Or are there complexities in the protocol that prevent this, e.g. different-length responses depending on disk contents?
2017-11-15 18:11

Registered: Apr 2002
Posts: 955
I see several potential problems, more or less from the top of my head:

- Not interfering with the protocol in response to ATN toggles requires ATNA-setting loops to respond at least as quickly as the active drive, if not quicker due to asynchronous clocks, various bus delays due to different positions in the daisy chain, and different pull strengths.

This seems done, but:

- Add on top of the ATNA response a state machine to follow, which might make the ATNA setting too slow and also may not be possible without ambiguities due to the inactive drives not knowing which of the two active parties just pulled the clock or data line. These are the main problems. (I haven't thoroughly analysed the protocol from the angle of third-party bus snooping yet.)

- The active drive uses a watchdog timer to exit to KERNAL protocol upon protocol breach, such as the user deciding to reset the computer at any time between or during loading. Adding this to the inactive drives might render them too slow to set ATNA, and again the decision may be impossible due to ambiguities.

- Ultimately, the ideal setup would be being able to load from any of all the connected drives (think RAID-0 setups or games), which implies solid bus arbitration and further complicated code.

So for the first step, i'm thinking of somehow shoehorning in an ATN spike detection, as the current protocol never toggles ATN quicker than 18 cycles between edges. But then proper debouncing might or might not be in order to avoid false positives, potentially complicating already this simple solution.
Previous - 1 | 2 | 3 | 4 | 5 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Tim/Silicon Limited
wozza/Cygnus Australia
Guests online: 33
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 Comaland 100%  (9.6)
5 The Shores of Reflec..  (9.6)
6 Wonderland XII  (9.6)
7 Lunatico  (9.6)
8 We Come in Peace  (9.5)
9 Incoherent Nightmare  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 FMX Music Demo  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Pandemoniac Part 2 o..  (9.5)
4 Treu Love [reu]  (9.5)
5 Merry Xmas 2017  (9.4)
6 Arok 20 Invitation  (9.4)
7 Dawnfall V1.1  (9.4)
8 In Memoriam BHF  (9.4)
9 Dawnfall  (9.4)
10 Synthesis  (9.4)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.4)
5 Crest  (9.3)
Top Hardware-Gurus
1 Soci  (9.9)
2 Wiesel  (9.9)
3 Grue  (9.8)
4 Zer0-X  (9.8)
5 Lemming  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.06 sec.