Is BD-DOS lost to time?

[Steve M]

Hi Dr Ray,

Good to hear from you.
I bought Rob Kimberly's BD system. It seems a bit worn and was in storage for a good number of years.
Would you be able to post a picture of the connector from the drive to bas unit of the BD? Kimbo's connectors don't look right. I have a box of connectors that will fit but I want to be sure of getting the connections right.

Just spoke to Dave D yesterday, who has moved down to the south coast.

If I can get my BD system working I can copy some masters for you - if they work.

I'd love to know a bit more about how you got involved with the ByteDrives. Did you have anything to do with ITL Kathmill, or just got involved via BDUG?

Also interested about the Sedoric story. (Allan Whitaker rang me last year also !)

[iss]

@Ray: I've updated Oricutron sources as suggested, thanks!

Can you please share more info about the 'mysterious' 0x317 address and its purpose?

[Ray030471]

Hi Dr Ray,

Good to hear from you.
I bought Rob Kimberly's BD system. It seems a bit worn and was in storage for a good number of years.
Would you be able to post a picture of the connector from the drive to bas unit of the BD? Kimbo's connectors don't look right. I have a box of connectors that will fit but I want to be sure of getting the connections right.

Just spoke to Dave D yesterday, who has moved down to the south coast.

If I can get my BD system working I can copy some masters for you - if they work.

I'd love to know a bit more about how you got involved with the ByteDrives. Did you have anything to do with ITL Kathmill, or just got involved via BDUG?

Also interested about the Sedoric story. (Allan Whitaker rang me last year also !)

Hi Steve.

I am using Oricutron at the moment and making good progress. I will be posting more information on my developments and some technical information for Pete Gordon so that he can update Oricutron for the Byte Drive.
I have attached a couple of picture files as you requested.

"
"Picture1.jpg", the top picture, shows a standard ITL set up. The cable shown goes from the BD interface to the floppy disk drive and the (blue) coloured wire (no 1) is on the right at both ends shown. Both connectors on the BD interface are standard and the floppy connector is a standard card-edge connector.
"Picture2.jpg" which is of a BD interface that I wired up myself shows the ORIC end of it. As you look at it, pin 1 is the one nearest to you on the bottom face of the card (you might be able to make out the red on the wire's insulation). Pin2 is the one nearest to you on the top face of the card and so on. I haven't shown it but the floppy disk end of the BD interface has odd-numbered pins (all common) on the underside and all even-numbered pins on the top with pin number 1 nearest you in the picture.
The interface in "Picture1.jpg" is neater with the standard connectors soldered to the card rather than the wires soldered directly to the card.

I became known to ITL Kathmill initially because the interface and drives which I bought from them didn't work and, as I had to go to London on business, I popped along to Chatham and appeared at their premises. They treated me very well by trying some other of their BD interfaces on my ORIC1 and soon presented me with a stable system. The nice guy who was helping me (John somebody) also slightly upgraded my old ORIC 1 (2 8k Eproms) by disconnecting the lower 8k Eprom's ROMDIS pin from its socket and wiring it to the ROMDIS pin of the other Eprom. Of course, it didn't affect the operation of the system as I saw it as a user but it did use overlay RAM for the whole of the upper 16K of address space. This is information, with more technical detail, which I will pass on to Pete Gordon very soon.

I now have my DOS7 & Basic5 working on Oricutron as it would on the real hardware, ie BASIC5 in a ROM and DOS7 booting up from the floppy disk. This is very much like the SEDORIC set up but I have completely reprogrammed BASIC and DOS with sensible (I think) separation of code. I'll be posting details of this and uploading my (current) beta version very soon so that those interested can play with it and report bugs/improvements. Over time, I will also be modifying my other software to suit (Wordspeed, Assembler, Compiler) and making that available.

Best wishes.

Ray.

[Ray030471]

Welcome @Ray, it's amazing to meet you!

I have quite a bit of useful information which would help in the development of Oricutron for the Byte Drive and I will pass this on in another posting very soon.

I can wait to finish the BD500 support filling the missing functionality!

I would like to know how, on Oricutron for the BD500, I can define another ROM for each of ATMOS and ORIC computer.
I tried the line "atmosrom = 'roms/basic50'" in file "oricutron.cfg" but it didn't seem to have any effect (the original ATMOS
ROM was loaded, I believe). I tried to overwrite the "basic11b.rom" file with mine (to keep the same name) but it didn't have any effect. Perhaps the ROMS are hard-coded into Oricutron and, at the moment, cannot be changed by the user.

First, what is your host OS (Windows,Linux,...) ? What version of Oricutron are you using?
Actually for BD500 support are two options: build by yourself from sources or dev-builds from my site - both options should work fine. I think you made all changes in oricutron.cfg correct but here you are:
- put Oricutron in path without spaces (just for any case);
- if your host OS is Linux the names are case sensitive;
- copy your ROM file 'basic50.rom' (16384 bytes long) to roms/ subdirectory;
- check that you have the BD500 ROM file (8192 bytes long) in roms/ too i.e. 'roms/bd500.rom';
- put in 'oricutron.cfg' the names exactly without the 'rom' extension which will be added internally:

Code: Select all

atmosrom = 'roms/basic50'
oric1rom = 'roms/basic50'
bd500rom = 'roms/bd500'
disktype = bd500

- start Oricutron from command line - eventually to see any log messages for Windows:

Code: Select all

oricutron path_to_the_imagefile\bddos_mage.dsk

and for Linux:

Code: Select all

./oricutron path_to_the_imagefile/bddos_mage.dsk

This should work. You can add command line switches to select machine: '-ma' for Atmos or '-m1' for Oric-1.
Hope this helps and waiting for your feedback!

Hello.

Many thanks for this really useful information. My operating system is Windows 7 32 bit) and I am running "Oricutron_win32-20200515" which I downloaded a couple of months ago. Your site currently has this named Oricutron version for download but is it the version which you updated a few days ago?

I have managed to overcome the ROM problem which I reported and your help is much appreciated. I was doing the correct things in the config file and I found out what was actually going wrong. I was writing to the 0x313 and 0x314 addresses (managing ROMDIS and MAP simultaneously) but, when I looked at more of your source code, I realised that Oricutron didn't emulate writing to these addresses. In the real hardware, reading from and writing to these addresses have exactly the same effect. It would be nice if you could add this to Oricutron.

i now have some very important and, I believe, useful information on the other addresses in the range 0x310 to 0x317.

Address 0x310 switches the disk drive motor off. It is called MOTOFF in the ITL assembly listing.
Address 0x311 switches the disk drive motor on. It is called MOTON in the ITL assembly listing.
I think that the motor is switched on by (electronic) default on first powering up the BD interface but it is safer to switch it on in the boot sector (page 4) code.

Address 0x312, as you know is read (BIT instruction) to obtain the FDC's DRQ in bit 7 and IRQ in bit 6. It is called DSTATS in the ITL assembly listing.

Reading or writing address 0x313 enables the ORIC ROM and disables the overlay RAM. It is called MAPOFF in the ITL assembly listing.
Reading or writing address 0x314 disables the ORIC ROM and enables the overlay RAM. It is called MAPON in the ITL assembly listing.

Address 0x315, called PRECMP in the ITL assembly listing, is, I believe, for write compensation on the FDC. I think that it is used in the DOS versions V2.2 & V3.1 of the BD software but not in my latest version - perhaps I should include it.

Reading or writing address 0x316 enables the the lower 8k of the ORIC's EPprom (used where the ORIC has 2 8k Eproms) and therefore disables the overlay RAM in that memory area. This overrides MAPON (see above). It is called SDEN in the ITL assembly listing.
Reading or writing address 0x317 disables the lower 8k of the ORIC's Eprom (used where the ORIC has 1 16k Eprom or ROM) and therefore enables the overlay RAM when MAPON has been accessed. It is called DDEN in the ITL assembly listing.

Reading (or writing, I believe) address 0x380 disables the BD interface ROM which covers addresses 0xE00 to 0xFFFF but before that is done, it takes precedence over the above for that memory space.

These facilities, SDEN & DDEN, are to cater for the different ORIC hardware. The existence of 2 x 8k EPROM machines is one of the reasons for ITL to base their system on the ORIC V1.0 operating system (they couldn't mask the lower 8k Eprom without opening up each of those ORIC machines). Another reason was connected with licensing. They couldn't give the V1.1 (ATMOS) operating system to those who hadn't already bought it from ORIC but they could give the V1.0 (ORIC) operating system to those who had bought an ATMOS machine.

I hope that you find this information interesting and useful.

It would be nice of you could update Oricutron to include the writing of addresses 0x313 & 0x314 (bd->oric->romdis set as SDL_FALSE and SDL_TRUE respectively) as this would enable me to have some slicker code when windowing between ROM and RAM in the top 16k of address space (as I can with the real hardware).

I have downloaded your source code and will look into compiling it when I can. I use Microsoft's Visual Studio (C++ and VB.Net) but, at the moment, I am not sure how to compile your C code. Meanwhile, it would be nice if you could upload the latest (after doing the above) compiled code to this site or to me directly, if that is possible.

I will also be posting the above information on the Oricutron site as soon as I can but it's getting a bit late now.

Best wishes.

Ray.

[iss]

Oricutron sources updated.
Oricutron for developers updated too.

@Ray: This is great! I never expected that we will have any info about BD500.

Now it's clear for me the reason for the strange handling of 56k/64k modes:
when financiers and managers are stepping-in the source codes become weird .

Attached you can find a ZIP file with Quadro-boot images built with my WIP-project BOOTER.

The same image can be used with Microdisk, Jasmin, BD500 and 8D-FDC (the last - 8D-FDC is not working now).
Use the DSK-image in Oricutron with command line swithces: -km, -kj, -kb to select the FDC controller type.
Use the HFE-image with Gotek emulators and any floppy controller.

drvtest.zip

(28.34 KiB) Downloaded 209 times

Waiting for any further info and feedback about BD500.

[Dbug]

The same image can be used with Microdisk, Jasmin, BD500 and 8D-FDC (the last - 8D-FDC is not working now).

That's... interesting, does that mean we could soon patch the FloppyBuilder based games and demos so they run on all of that?

[iss]

The same image can be used with Microdisk, Jasmin, BD500 and 8D-FDC (the last - 8D-FDC is not working now).

That's... interesting, does that mean we could soon patch the FloppyBuilder based games and demos so they run on all of that?

Unfortunately just binary patch will not work.
I'm writing BOOTER from scratch and the goal is to support 2 more devices which are in beta test now.
I will share the booting code and IMHO it will be not difficult to merge it with FloppyBuilder and recompile the demos and games.

[Ray030471]

Welcome @Ray, it's amazing to meet you!

I have quite a bit of useful information which would help in the development of Oricutron for the Byte Drive and I will pass this on in another posting very soon.

I can wait to finish the BD500 support filling the missing functionality!

I would like to know how, on Oricutron for the BD500, I can define another ROM for each of ATMOS and ORIC computer.
I tried the line "atmosrom = 'roms/basic50'" in file "oricutron.cfg" but it didn't seem to have any effect (the original ATMOS
ROM was loaded, I believe). I tried to overwrite the "basic11b.rom" file with mine (to keep the same name) but it didn't have any effect. Perhaps the ROMS are hard-coded into Oricutron and, at the moment, cannot be changed by the user.

First, what is your host OS (Windows,Linux,...) ? What version of Oricutron are you using?
Actually for BD500 support are two options: build by yourself from sources or dev-builds from my site - both options should work fine. I think you made all changes in oricutron.cfg correct but here you are:
- put Oricutron in path without spaces (just for any case);
- if your host OS is Linux the names are case sensitive;
- copy your ROM file 'basic50.rom' (16384 bytes long) to roms/ subdirectory;
- check that you have the BD500 ROM file (8192 bytes long) in roms/ too i.e. 'roms/bd500.rom';
- put in 'oricutron.cfg' the names exactly without the 'rom' extension which will be added internally:

Code: Select all

atmosrom = 'roms/basic50'
oric1rom = 'roms/basic50'
bd500rom = 'roms/bd500'
disktype = bd500

- start Oricutron from command line - eventually to see any log messages for Windows:

Code: Select all

oricutron path_to_the_imagefile\bddos_mage.dsk

and for Linux:

Code: Select all

./oricutron path_to_the_imagefile/bddos_mage.dsk

This should work. You can add command line switches to select machine: '-ma' for Atmos or '-m1' for Oric-1.
Hope this helps and waiting for your feedback!

Hello.

Many thanks for this really useful information. My operating system is Windows 7 32 bit) and I am running "Oricutron_win32-20200515" which I downloaded a couple of months ago. Your site currently has this named Oricutron version for download but is it the version which you updated a few days ago?

I have managed to overcome the ROM problem which I reported and your help is much appreciated. I was doing the correct things in the config file and I found out what was actually going wrong. I was writing to the 0x313 and 0x314 addresses (managing ROMDIS and MAP simultaneously) but, when I looked at more of your source code, I realised that Oricutron didn't emulate writing to these addresses. In the real hardware, reading from and writing to these addresses have exactly the same effect. It would be nice if you could add this to Oricutron.

i now have some very important and, I believe, useful information on the other addresses in the range 0x310 to 0x317.

Address 0x310 switches the disk drive motor off. It is called MOTOFF in the ITL assembly listing.
Address 0x311 switches the disk drive motor on. It is called MOTON in the ITL assembly listing.
I think that the motor is switched on by (electronic) default on first powering up the BD interface but it is safer to switch it on in the boot sector (page 4) code.

Address 0x312, as you know is read (BIT instruction) to obtain the FDC's DRQ in bit 7 and IRQ in bit 6. It is called DSTATS in the ITL assembly listing.

Reading or writing address 0x313 enables the ORIC ROM and disables the overlay RAM. It is called MAPOFF in the ITL assembly listing.
Reading or writing address 0x314 disables the ORIC ROM and enables the overlay RAM. It is called MAPON in the ITL assembly listing.

Address 0x315, called PRECMP in the ITL assembly listing, is, I believe, for write compensation on the FDC. I think that it is used in the DOS versions V2.2 & V3.1 of the BD software but not in my latest version - perhaps I should include it.

Reading or writing address 0x316 enables the the lower 8k of the ORIC's EPprom (used where the ORIC has 2 8k Eproms) and therefore disables the overlay RAM in that memory area. This overrides MAPON (see above). It is called SDEN in the ITL assembly listing.
Reading or writing address 0x317 disables the lower 8k of the ORIC's Eprom (used where the ORIC has 1 16k Eprom or ROM) and therefore enables the overlay RAM when MAPON has been accessed. It is called DDEN in the ITL assembly listing.

Reading (or writing, I believe) address 0x380 disables the BD interface ROM which covers addresses 0xE00 to 0xFFFF but before that is done, it takes precedence over the above for that memory space.

These facilities, SDEN & DDEN, are to cater for the different ORIC hardware. The existence of 2 x 8k EPROM machines is one of the reasons for ITL to base their system on the ORIC V1.0 operating system (they couldn't mask the lower 8k Eprom without opening up each of those ORIC machines). Another reason was connected with licensing. They couldn't give the V1.1 (ATMOS) operating system to those who hadn't already bought it from ORIC but they could give the V1.0 (ORIC) operating system to those who had bought an ATMOS machine.

I hope that you find this information interesting and useful.

It would be nice of you could update Oricutron to include the writing of addresses 0x313 & 0x314 (bd->oric->romdis set as SDL_FALSE and SDL_TRUE respectively) as this would enable me to have some slicker code when windowing between ROM and RAM in the top 16k of address space (as I can with the real hardware).

I have downloaded your source code and will look into compiling it when I can. I use Microsoft's Visual Studio (C++ and VB.Net) but, at the moment, I am not sure how to compile your C code. Meanwhile, it would be nice if you could upload the latest (after doing the above) compiled code to this site or to me directly, if that is possible.

I will also be posting the above information on the Oricutron site as soon as I can but it's getting a bit late now.

Best wishes.

Ray.

I forgot another bit of information. Memory register 0x312 (DSTATS), when read, also indicates, in bit 0, whether the disk drive motor is on or off. If b0 is 0 then the motor is ON but if b0 is 1 then the motor is OFF.

I mentioned before that it would be nice of register 0x31a could be used, in addition to indicating the drive number in bits 6 & 7, to indicate the disk side in bit 5. If that is possible then, at least in the emulator, I could upgrade my DOS7 to cater for double-sided disks.

[iss]

I forgot another bit of information. Memory register 0x312 (DSTATS), when read, also indicates, in bit 0, whether the disk drive motor is on or off. If b0 is 0 then the motor is ON but if b0 is 1 then the motor is OFF.

I mentioned before that it would be nice of register 0x31a could be used, in addition to indicating the drive number in bits 6 & 7, to indicate the disk side in bit 5. If that is possible then, at least in the emulator, I could upgrade my DOS7 to cater for double-sided disks.

Well, new release again today!

Implemented are all changes so far. But I found that adding bit 0 (motor status) when reading from 0x312 hangs ver.2.2.
So I've added the option 'dos70; in 'oricutron.cfg': dos70 is by default disabled and ver.2.2 works, to enable it set in CFG file:

Code: Select all

dos70 = yes

Here is summary of all info so far:

Code: Select all

0x310 MOTOFF  R   switches the disk drive motor off.
0x311 MOTON   R   switches the disk drive motor on.
                    NOTE: (probably)the motor is switched on
                    by (electronic) default on first powering up
                    the BD interface but it is safer to switch it
                    on in the boot sector (page 4) code.

0x312 DSTATS  R   bit 7 - DRQ
                  bit 6 - IRQ
                  bit 0 - motor status (): b0=0 ON, b0=1 OFF (NOTE: DOS7 only).

0x313 MAPOFF  R/W enables the ORIC ROM and disables the overlay RAM.

0x314 MAPON   R/W disables the ORIC ROM and enables the overlay RAM.

0x315 PRECMP  R   (probably) forwrite compensation on the FDC.
                    NOTE: maybe it's used in the DOS versions V2.2 & V3.1
                    of the BD software but not in Ray's latest version,
                    perhaps it will be included.

0x316 SDEN    R/W enables the the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 2x8k EPROMS) and therefore
                  disables the overlay RAM in that memory area.
                  This overrides MAPON (see above).

0x317 DDEN    R/W disables the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 1x16k EPROM or ROM)
                  and therefore enables the overlay RAM when MAPON
                  has been accessed.

0x31a DRVSEL  R   bit 7,6 - current drive
                  bit 5   - current side
              W   bit 7,6 - select drive
                  bit 1   - select side

0x0380        R/W disables the BD interface ROM which covers addresses
                  0xE000 to 0xFFFF but before that is done, it takes
                  precedence over the above for that memory space.

Please update if something is wrong. I'm ready to push new versions on every changed bit

[Ray030471]

I forgot another bit of information. Memory register 0x312 (DSTATS), when read, also indicates, in bit 0, whether the disk drive motor is on or off. If b0 is 0 then the motor is ON but if b0 is 1 then the motor is OFF.

I mentioned before that it would be nice of register 0x31a could be used, in addition to indicating the drive number in bits 6 & 7, to indicate the disk side in bit 5. If that is possible then, at least in the emulator, I could upgrade my DOS7 to cater for double-sided disks.

Well, new release again today!

Implemented are all changes so far. But I found that adding bit 0 (motor status) when reading from 0x312 hangs ver.2.2.
So I've added the option 'dos70; in 'oricutron.cfg': dos70 is by default disabled and ver.2.2 works, to enable it set in CFG file:

Code: Select all

dos70 = yes

Here is summary of all info so far:

Code: Select all

0x310 MOTOFF  R   switches the disk drive motor off.
0x311 MOTON   R   switches the disk drive motor on.
                    NOTE: (probably)the motor is switched on
                    by (electronic) default on first powering up
                    the BD interface but it is safer to switch it
                    on in the boot sector (page 4) code.

0x312 DSTATS  R   bit 7 - DRQ
                  bit 6 - IRQ
                  bit 0 - motor status (): b0=0 ON, b0=1 OFF (NOTE: DOS7 only).

0x313 MAPOFF  R/W enables the ORIC ROM and disables the overlay RAM.

0x314 MAPON   R/W disables the ORIC ROM and enables the overlay RAM.

0x315 PRECMP  R   (probably) forwrite compensation on the FDC.
                    NOTE: maybe it's used in the DOS versions V2.2 & V3.1
                    of the BD software but not in Ray's latest version,
                    perhaps it will be included.

0x316 SDEN    R/W enables the the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 2x8k EPROMS) and therefore
                  disables the overlay RAM in that memory area.
                  This overrides MAPON (see above).

0x317 DDEN    R/W disables the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 1x16k EPROM or ROM)
                  and therefore enables the overlay RAM when MAPON
                  has been accessed.

0x31a DRVSEL  R   bit 7,6 - current drive
                  bit 5   - current side
              W   bit 7,6 - select drive
                  bit 1   - select side

0x0380        R/W disables the BD interface ROM which covers addresses
                  0xE000 to 0xFFFF but before that is done, it takes
                  precedence over the above for that memory space.

Please update if something is wrong. I'm ready to push new versions on every changed bit

Your response time is super. Many thanks

I have downloaded your latest version, Oricutron_win32-20210213.zip, and it runs well.

I have found that by choosing the "dos70=yes" option in the config file when running DOS7 leads to "Drive Error" which might mean that the motor is switched off.
However, dos70=no" gives normal operation when running DOS7 and so I will run with that - no need as yet for me to read to find out if the motor is running.
A little mystery to be solved at some point, perhaps.

I wasn't clear enough about my request concerning disk side (head). Please could you change the writing of 0x31a (DRVSEL) to
W bit 7,6 - select drive
bit 5 - select side

I can then ROR in the carry flag (suitably set, of course).

Leave the read as it is but I'm not sure if the actual hardware has read access.

When that is done, I can start on development of DOS7.0 to cater for double-sided disks.


There is no great rush on my part but please can you post the link to the new download when it is done.

Best wishes.

Ray.




mplemented are all changes so far. But I found that adding bit 0 (motor status) when reading from 0x312 hangs ver.2.2.

[iss]

@Ray: 0x31a (DRVSEL) updated! Oricutron download as usual .

[Steve M]

I have attached a couple of picture files as you requested.

Thanks. It was the power connection at the back that I'm not sure of, rather than the hybrid.

I became known to ITL Kathmill initially because the interface and drives which I bought from them didn't work and, as I had to go to London on business, I popped along to Chatham and appeared at their premises. They treated me very well by trying some other of their BD interfaces on my ORIC1 and soon presented me with a stable system. The nice guy who was helping me (John somebody) also slightly upgraded my old ORIC 1 (2 8k Eproms) by disconnecting the lower 8k Eprom's ROMDIS pin from its socket and wiring it to the ROMDIS pin of the other Eprom. Of course, it didn't affect the operation of the system as I saw it as a user but it did use overlay RAM for the whole of the upper 16K of address space. This is information, with more technical detail, which I will pass on to Pete Gordon very soon.

It seems a common problem that the drives, or cables, had issues.
The Astrosyn boss was John Melville. Might have been him?

I now have my DOS7 & Basic5 working on Oricutron as it would on the real hardware, ie BASIC5 in a ROM and DOS7 booting up from the floppy disk. This is very much like the SEDORIC set up but I have completely reprogrammed BASIC and DOS with sensible (I think) separation of code. I'll be posting details of this and uploading my (current) beta version very soon so that those interested can play with it and report bugs/improvements. Over time, I will also be modifying my other software to suit (Wordspeed, Assembler, Compiler) and making that available.

I think DOS6 and Basic 4 is the most recent I have. I have Wordspeed but I think it is an earlier version than the Sedoric one.
I'm a bit confused as to which versions worked with the FORMAT command as some seem to need an earlier version for it to work. But still - I need to get the hardware sorted first.

[Ray030471]

Hello again.

Here are some more pictures, this time from the back of the disk drive (BD500 40 track, single sided).

"ByteDrive FDC.jpg"

shows where the hybrid cable (or cable from Cumana board) connects. The numbering is there and you can see that the even numbers are on the top, with 2 on the left, and therefore the odd numbers are on the bottom.
"ByteDrive Cable.jpg"

shows the hybrid cable attached ( I looped the cable under the drive for easier viewing). You can just about make out the blue strip which, here, indicates wire 1. This cable would only fit one way with wire 1 where it is indicated on the disk drive. I haven't tried it out live but I believe that this is correct.
"ByteDrive Power.jpg"

shows the underside of the disk drive where the standard power connector fits and you can read the voltages.

I hope that this helps.

best wishes.

Ray.

[Steve M]

Thanks. Sorry if I wasn't clear. It's the power connector I'm looking for. From the drive to the base unit. There should be a little short connector.4 wires.

[Ray030471]

The power connectors (4 wires) are standard PC power cables, male at one end and female at the other end.
5 1/4" drives with inbuilt power supply can be used to connect directly to the BD 3" drive power input.
The "ByteDrive Power.jpg" picture (underside view) tells you where the BD disk drive expects 12v, 5v and 0v if you need to test.