Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user mattfp1 ! (Registered 2017-11-20) 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 11:26
Monte Carlos

Registered: Jun 2004
Posts: 249
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?
2017-11-08 20:58
Krill

Registered: Apr 2002
Posts: 902
Unplugging a drive from the bus would of course remove all its signaling lines, including ATN. Drive presence detection is usually done by addressing them directly, and seeing if they respond, which involves all 3 lines, not just toggling ATN and seeing what happens.

Are you sure that all devices (including printers :D) on the bus, except for #8, are removed? And that the 1541U isn't multiplexing drives or so? :)
2017-11-08 21:24
Monte Carlos

Registered: Jun 2004
Posts: 249
I have the 1541U configured so that one 1541 on 8 is active, only. The drive to access USB stick directly is turned off, too.
Thank you for the hint with the printer. I'll check if virtual printer is off, too. No real printer, though.
2017-11-08 22:40
Monte Carlos

Registered: Jun 2004
Posts: 249
Software ICE drives and printers are off.
2017-11-09 10:44
Skate

Registered: Jul 2003
Posts: 469
Is it possible somehow you're running the PRG without mounting the disk? I remember having issues with directly selecting PRG file inside the D64 without mounting the D64 itself. This could be the problem but i'm not infront of my C64 at the moment, i'm only guessing.

You can try mounting D64 first, then running the disk with LOAD command to make sure.
2017-11-09 10:52
Krill

Registered: Apr 2002
Posts: 902
This will print 0 for present devices and something else otherwise:
FORN=8TO30:OPEN1,N,2:CLOSE1:PRINTN;ST:NEXT
What does it say on your mystery system? :)
2017-11-09 12:22
Flavioweb

Registered: Nov 2011
Posts: 344
The drive logic in a 128d is on board, or is "near" the mechanics?
May be that "unplug" the drive mean just unplug the mechanics but logic still active...
No?
2017-11-09 14:17
Krill

Registered: Apr 2002
Posts: 902
The C128D has discrete PCBs for main computer and drive, so the drive part should be completely unpluggable.
The C128DCR has both PCBs merged into one, but what this means for the disconnectibility of the drive portion, i can't say.
2017-11-09 15:22
Krill

Registered: Apr 2002
Posts: 902
Looking at the C128DCR (which is the metal C128D) schematics, it very much seems like there is no way of disconnecting the drive electronics from the serial bus, save cutting their traces.

Uploading a small program to the built-in drive that would disable interrupts and set ATNA according to ATN IN in a loop would probably solve your problem, but alas, i have no time right now to hack it up.
2017-11-09 16:24
Monte Carlos

Registered: Jun 2004
Posts: 249
If its not possible to plug of the drive, there should still be the possibility to cut the ATN line and insert a switch instead? After googling i found an howto on herdware, however there is some pic missing.
http://commodore128.mirkosoft.sk/herdware.html
Somebody knows what they mean with "threethrough-hole solder pads"?
2017-11-09 16:32
Krill

Registered: Apr 2002
Posts: 902
Would you really want to cut traces if there's a viable software solution? Poor C128.
2017-11-09 16:34
Krill

Registered: Apr 2002
Posts: 902
Also, does the little BASIC line above report a drive on #10, as is expected?
2017-11-09 16:43
Monte Carlos

Registered: Jun 2004
Posts: 249
Can't try it at the moment with my two year boy next to me. Will try in the evening.
2017-11-09 21:45
Monte Carlos

Registered: Jun 2004
Posts: 249
Yes, it shows drive on ID 10.I ridiculously just unplugged the mechanics.btw:hw hack would not be the worst solution for me if it permitted a durable, unproblematic operation of 1541u with my 128dcr.
2017-11-09 21:48
Krill

Registered: Apr 2002
Posts: 902
If running a small "shut up everybody who's not #8" program before watching that demo is too much, well yeah. :)
2017-11-09 22:11
Monte Carlos

Registered: Jun 2004
Posts: 249
I did already with this

#include <cbm.h>
#include <stdio.h>


char openFile(void){
	char openErr;
	if ( (openErr = cbm_k_open()) ){
		printf("Open failed: Return value = %d\n", openErr);	
	}
	return openErr;
}

void main(void){
	char drivecmd[] = "u0>\x09";
	char openErr;
	
	cbm_k_setlfs (15, 8,15);
	cbm_k_setnam (drivecmd);
	if ( !(openErr = openFile()) ){
		cbm_k_close(15);
		printf("Successfully changed device\n");
		
	}else{
		printf("Could not change device\n");
		cbm_k_close(15);
	
	}
}


and this

OPEN 1,ID,15,"M-W"+CHR$(119)+CHR$(0)+CHR$(2)+CHR$(0)+CHR$(0):CLOSE 1 


My software solution attemps were not of much use up to now.
However, your drive code suggestion is different.
I could place an installation code into the root dir of the 1541U usb stick, so that i could execute it anytime before watching demos.
Didn't know that ATN call and answer chain could be influenced by software.
2017-11-09 22:32
Krill

Registered: Apr 2002
Posts: 902
The ATN problem is automatic acknowledgement by hardware on the physical layer, not the drive's address on the protocol layer.
The drive automatically pulls the DATA line low if the incoming ATN signal does not match the drive's ATNA setting.

Since the typical demo loader uses a 2bit+ATN protocol, ATN is used for clocking and is being toggled all the time. Any device on the bus not setting its ATNA value to match the incoming ATN signal in time would then invalidate what's sent on the DATA line by the current talker.

So the solution is to have a small routine running on all other drives than the one you're running the demo from, which would sample ATN and set ATNA accordingly, in a very tight loop, while it leaves the DATA and CLK lines unasserted.

(Note: 1581 ATN acknowledgement can be turned off, but 1541 and 1571 in all their variants must run software to achieve the same effect.)
2017-11-09 23:09
Monte Carlos

Registered: Jun 2004
Posts: 249
Unfortunately i did not bother very much about drive code and iec protocol and so on during my scene times. However, thank you very much for the discussion. Maybe i should have a look in the floppy chapter of my holy c64 bible.

No one who still uses a C128 dcr?
2017-11-09 23:20
Krill

Registered: Apr 2002
Posts: 902
I will hack up something as soon as time permits, and your problem has finally convinced me to add this feature to the upcoming next iteration of my loader. :)

Oh, and i have a C128DCR which Graham once gave me, but i rarely use it, and then only with the built-in drive.
2017-11-11 15:01
Krill

Registered: Apr 2002
Posts: 902
Here it is now, a little program to silence offending drives when running demos with 2-bit+ATN loaders. This one is hardcoded for #9. ACME source. Not tested on realthing yet.

        tightloop = 0; 1 might work better on 1541, 0 might work better on 1571

        !to "busoff.prg", cbm

        * = $0801

        !word 2048, 2017; link, line number
        !byte $9e; SYS
        !text "2064"
        !byte 0, 0, 0; end

        !text "+H!"

        lda #9   ; device number
        jsr listen

!if tightloop {
        ldx #0
datalo: lda atnlo,x
        jsr $ffa8; IECOUT
        inx
        cpx #atnloend - atnlo
        bne datalo
        jsr $ffae; UNLSTN

        lda $ae  ; FA
        jsr listen
        ldx #0
datahi: lda atnhi,x
        jsr $ffa8; IECOUT
        inx
        cpx #atnhiend - atnhi
        bne datahi
        jsr $ffae; UNLSTN

        lda $ae  ; FA
        jsr listen
}
        ldx #0
exec:   lda command,x
        jsr $ffa8; IECOUT
        inx
        cpx #endcommand - command
        bne exec
        jmp $ffae; UNLSTN

listen: ldx #0
        stx $90  ; STATUS
        sta $ae  ; FA
        jsr $ffb1; LISTEN
        lda #$6f ; open channel 15 (command/error channel)
        jsr $ff93; LSTNSA
        lda $90
        bmi error
        rts

error:  brk

command:
        !text "M-E"; memory-execute
        !word drivecode
!pseudopc $0205 {
drivecode:
    !if tightloop = 0 {
        ; the simple approach
        sei
        lda #$20
        sta $1801; 2 MHz on 1571
        lda #$00 ; ATNA cleared, CLK OUT low, DATA OUT low
        ldx #$10 ; ATNA set, CLK OUT low, DATA OUT low
--      bit $1800; wait for ATN IN high
        bpl --
        stx $1800; set ATNA
-       bit $1800; wait for ATN IN low
        bmi -
        sta $1800; clear ATNA
        bpl --   ; loop
    } else {
        ; the not-so-simple approach
        sei
        lda #$ff
        sta $1803; set all port bits as outputs
        lda #>$0300
        sta $1801
        lda #$7f
        sta $1802; set only ATN IN as input
        lda #$00 ; ATNA cleared, CLK OUT low, DATA OUT low
        ldx #$10 ; ATNA set, CLK OUT low, DATA OUT low
        sta $1800
        jmp ($1800)
    }
} 
endcommand:

!if tightloop {
atnlo:  !text "M-W"; memory-write
        !word $0300
        !byte $16
        jmp ($1800)
        !byte 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
        sta $1800
        jmp ($1800)
atnloend:

atnhi:  !text "M-W"; memory-write
        !word $0380
        !byte $13
        stx $1800
        jmp ($1800)
        !byte 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
        jmp ($1800)
atnhiend:
}
2017-11-12 22:40
Monte Carlos

Registered: Jun 2004
Posts: 249
Wow that was fast. I'm very curious to test it on the real hw.
2017-11-13 10:49
Krill

Registered: Apr 2002
Posts: 902
Would be cool if you could check both variants. Both should work, but i'm not so sure about various bus setups. The internal 1571 has the shortest physical path to the host computer's serial port, so it should all just work.

Anyhow, if your tests prove successful, i can safely add this feature to the loader. :)
2017-11-13 12:03
Bitbreaker

Registered: Oct 2002
Posts: 430
Might shamelessly copy that, been too lazy so far :-)
2017-11-13 12:24
Krill

Registered: Apr 2002
Posts: 902
As long as i show up in the credits under "help" or "additional code" or something, all is well. Open source works fine as long as there is proper attribution. :)
2017-11-13 16:59
Monte Carlos

Registered: Jun 2004
Posts: 249
Hhhm, i just compiled it with acme (compiled without problems). However, when executed i just get the ready prompt as with run/stop restore. Maybe something went wrong when the src was copied into csdb? Or do i have to specify specific compile options? I disassembled code which showed that branch and jump targets were ok.
2017-11-13 17:05
Krill

Registered: Apr 2002
Posts: 902
It executes a BRK if there's an error, such as device not present. Have you changed "lda #9 ; device number" to #10 for your setup?
2017-11-13 17:37
Monte Carlos

Registered: Jun 2004
Posts: 249
Ahh fuck,sorry!
2017-11-14 14:47
Monte Carlos

Registered: Jun 2004
Posts: 249
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 15:14
Krill

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

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

Registered: Jun 2004
Posts: 249
Tightloop = 1 also works fine.
2017-11-15 13:24
Krill

Registered: Apr 2002
Posts: 902
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 16:10
Monte Carlos

Registered: Jun 2004
Posts: 249
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 16:53
tlr

Registered: Sep 2003
Posts: 1126
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 17:05
Krill

Registered: Apr 2002
Posts: 902
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 17:18
lft

Registered: Jul 2007
Posts: 314
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 19:11
Krill

Registered: Apr 2002
Posts: 902
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.
2017-11-15 21:37
lft

Registered: Jul 2007
Posts: 314
Good arguments.

There's no need to debounce a digitally controlled signal; You might be thinking about spike suppression. But if you don't need it on the active drive, you probably don't need it on the passive drives, right?

Perhaps the timer interrupt is the answer to this one. If your protocol requires a keepalive signal anyway, then you might be able to put it on the ATN line. Then you have to make the passive drives reset the timer whenever ATN toggles (which causes a jump in the program flow anyway). But resetting the timer takes four cycles, which makes it tricky to pull off.
2017-11-15 23:37
Krill

Registered: Apr 2002
Posts: 902
Quoting lft
There's no need to debounce a digitally controlled signal; You might be thinking about spike suppression.
True, but same difference when seen from and handled by software, innit? :)

Quoting lft
But if you don't need it on the active drive, you probably don't need it on the passive drives, right?
Yes, it's probably not required. Although i've always wondered why Commodore did this in the KERNAL's serial code. But then they were extremely cautious in everything disk or tape. Probably wanted to err on the safe side.

Quoting lft
If your protocol requires a keepalive signal anyway
Only for the parts when the host computer sends or receives data. There is no keep-alive mechanism when the loader is idle, but a transition away from that state is easy to detect and not timing-critical.
But there's also no keep-alive signal whenever the host computer is waiting for the next block to become ready to download (i.e., when the drive reads and decodes it).
Furthermore, once the block ready signal is sent by the drive, it waits up to 16 regular timer periods (about 64K cycles each), as the computer might still be busy decompressing (copying a large chunk of data - there is no serial bus interrupt on C-64, unlike with C-128+1571, so it's polled at a few select strategic points in the code).
So, no, i don't think it's possible to simply wake up from effective bus-off by letting a keep-alive timeout expire.
2017-11-15 23:53
Krill

Registered: Apr 2002
Posts: 902
It might, however, be possible to split up the protocol into bigger logical parts and then apply the timer thing.

I have no reason to believe that this wake-up thingy is impossible to pull off, it's just non-trivial and i haven't so far spent much effort on that. It's been on the list for years, but alas, so do other things above it. :)
2017-11-16 19:15
Monte Carlos

Registered: Jun 2004
Posts: 249
Isn't it merely a matter of installing the tight loop in the right drive(s)? Can't the tight loop be simply removed again after loading? Then the drive should become active again.
2017-11-16 19:26
Monte Carlos

Registered: Jun 2004
Posts: 249
Can the decision be left to the top level program? Let have four entry points: Install loader code in the main drive, install tightloop in the other drives,start loading,remove tight loop from the lower priority drive.call 1and 2 before loading,then call 3 and when you are sure, loading has finished call 4
2017-11-17 12:19
Krill

Registered: Apr 2002
Posts: 902
Adding detection of a special wake-up signal to the tight loop would make it less tight, potentially making it too untight for the original purpose it is serving.
2017-11-17 13:53
Groepaz

Registered: Dec 2001
Posts: 8275
YO! reminds me of that famous Moses P. quote: "You guys are so tight, when i am done with you, it will burn"
2017-11-17 14:12
Krill

Registered: Apr 2002
Posts: 902
Quoting Groepaz
YO! reminds me of that famous Moses P. quote: "You guys are so tight, when i am done with you, it will burn"
Klostein: Not. Even. Once.
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
Advanced
Users Online
Acidchild/Padua
thesuperfrog
Pantaloon/Fairlight
Guests online: 51
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 The Shores of Reflec..  (9.6)
5 Lunatico  (9.6)
6 Comaland 100%  (9.5)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 FMX Music Demo  (9.6)
2 Pandemoniac Part 2 o..  (9.6)
3 Daah, Those Acid Pil..  (9.5)
4 Dawnfall V1.1  (9.5)
5 Synthesis  (9.5)
6 Dawnfall  (9.4)
7 Treu Love [reu]  (9.4)
8 Field Sort  (9.4)
9 Pro Memoria 4  (9.3)
10 KAOS 64  (9.3)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 The Judges  (9.3)
Top Mega Swappers
1 Nightshade  (9.4)
2 Aslive  (9.3)
3 R.C.S.  (9.3)
4 Dishy  (9.2)
5 Calypso  (9.2)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 0.451 sec.