No, that's not possible. There are no jumpers/switches on these boards.
| VCF Latam | Apr 24 - 26, 2026, | Bahía Blanca, Argentina |
| VCF Pac. NW | May 02 - 03, 2026, | Tukwila, WA |
| VCF Southwest | May 29 - 31, 2026, | Westin Dallas Fort Worth Airport |
| VCF Southeast | Aug 01 - 02, 2026, | Atlanta, GA |
| VCF West | Aug 01 - 02, 2026, | Mountain View, CA |
| VCF Midwest | Sep 12 - 13, 2026, | Schaumburg Convention Center, IL |
| VCF Montreal V2.0 | Nov 07 - 08, 2026, | Saint-Lambert, Montreal, Canada |
| VCF SoCal | See you in 2027, | Southern CA |
| VCF East | Apr TBD, 2027, | InfoAge, Wall, NJ |
-
Please review our updated Terms and Rules here
Juko D16-X, can the bios be upgraded?
- Thread starter VERAULT
- Start date
It is possible with normal IDE because it uses from that region only I/O port 3F6, which is not used by FDC. While with XTIDE cards and alike I am, so far, not sure about their usage of 3Fx I/O space. Do you have such JUKO IDE card yourself? Probably Krille knows better how many ports from the control block IDE space are actually used on XTIDE cards?
I checked both of the original BIOS disassemblies and they access 3F4h, 3F5h and 3F6h. IIRC, XUB only accesses 3F6h.
Good news -- I moved the control block from 3F0 to 300 by changing the PLD and that, of course, resolved all floppy drives issues. I can tell from the equations that only ports 3F6/3F7 were used, but no 3F4 , nor 3F5. Check again your disassembly. I can do it myself, but since it is irrelevant to me now, I am no longer interested. Nice card.
Bad news: I tried XUB 633 and it works well. But with the latest version 636 each write to the IDE HDD drive corrupts the data on the HDD/CF. But reading and booting is fine if HDD is prepared on another computer and never written afterwards. Something broke since version 633. It would be nice if you provide each XUB version packed in an archive on your web resource, not like now scattered with numerous files.
Both of the BIOS versions I've disassembled are different from the one on your board (which I found today) so it's likely that the PLD is also different.
It would be helpful to know which build you're using. Also, did you remember to change the control block address in XTIDECFG? Have you tried r635?
EDIT: BTW, did you try r633 before reprogramming the PLD and r636 after? Because I can see a possible reason for the corruption if so.
Last edited:
The tests with failed writing were prior my idea for PLD modification but without floppy controller, to exclude its interference. Of course, the port in XUB is adjusted to reflect the real ports in PLD.
I don't know the builds, 633 I downloaded zipped from your message in this topic, and 636 I downloaded yesterday file by file from your web site. Since the files are not archived, no guarantees they were correctly downloaded.
I don't know the builds, 633 I downloaded zipped from your message in this topic, and 636 I downloaded yesterday file by file from your web site. Since the files are not archived, no guarantees they were correctly downloaded.
Last edited:
@george: I've now disassembled your BIOS and it only accesses I/O port 3F6h in the control block range. The strange thing is it is version 1.0 just like one of the other disassemblies I have, but it's very different and full of weird errors. Is it possible that it's a bad dump? In any case, it seems to be two different versions even though they both claim to be version 1.0.
Regarding the corrupted writes with XUB r636; I'm stumped. None of the changes between r633 and r636 should cause this problem.
What kind of machine/CPU are you using?
Regarding the corrupted writes with XUB r636; I'm stumped. None of the changes between r633 and r636 should cause this problem.
What kind of machine/CPU are you using?
Mainly for this card I am using JUKO XT motherboards, I have resources, it is not motherboard related, especially if 633 works. Just pack with ZIP your versions you'd like me to test, and I will make tests for you. So far, I have only one JUKO IDE clone card operational at hand, I am repairing the second one that currently upon drive detection either does not detect the IDE disk, or prints HDD ID with many wrong characters and 10 exclamation marks after it. There is some hardware fault in it which I will try to find, but all chips are directly soldered on the PCB which requires much more effort and diagnosing.
Don't pay much attention to the BIOS extensions I found on these cards originally, they are probably buggy, that's what Pravetz engineers cloned in 1991, just after the fall of the regime when everything including quality control went away. Now I know (thanks to a forum member here) the original card they cloned, so things became much more clear. JUKO BIOS 1.2 extensions works better on them, you can simply ignore V1.0 but I prefer XUB with the ability to adjust I/O ports and IDE HDD autodetection.
I remember in one of the previous posts you wanted to know if the slave drive worked, well, with R633 it works even as a slave without master.
Don't pay much attention to the BIOS extensions I found on these cards originally, they are probably buggy, that's what Pravetz engineers cloned in 1991, just after the fall of the regime when everything including quality control went away. Now I know (thanks to a forum member here) the original card they cloned, so things became much more clear. JUKO BIOS 1.2 extensions works better on them, you can simply ignore V1.0 but I prefer XUB with the ability to adjust I/O ports and IDE HDD autodetection.
I remember in one of the previous posts you wanted to know if the slave drive worked, well, with R633 it works even as a slave without master.
Last edited:
Okay, but why don't you put all these files in an archive of some sort? The archiving software in addition to compression makes redundancy checks for files' integrity.
Is the configuration utility bound to the specific release?
I had to mention I was using only ide_xt.bin, so far.
I am only several days first time user of XUB Haven't you thought of including a CPU autodetection in XUB?
ADDED: 635 works, thanks.
Is the configuration utility bound to the specific release?
I had to mention I was using only ide_xt.bin, so far.
I am only several days first time user of XUB
Haven't you thought of including a CPU autodetection in XUB?ADDED: 635 works, thanks.
Last edited:
Data corruption is very unlikely over a HTTP transfer. It's just an extra unnecessary step in my opinion.
The short simple answer is yes. The longer answer is it depends on the ROMVARS version and whether they are the same in the BIOS and the configurator (XTIDECFG.COM).
OK, I would like to see at what revision it breaks to try to pinpoint where the problem is. Although, I've got to say that if r633 works then they all should work, including r636, because, aside from possible changes in alignment (which doesn't matter on an 8088) there's nothing in the changes that should affect timing on an XT class machine such as this. (Assuming a timing problem is the root cause of the corruption, of course.)
There's no point in having that. If, say, only the transfer routines would be CPU dependent then yes, in that case it would have been useful to have CPU detection in the BIOS. But all of the code is heavily optimized for size, depending on CPU type which is why we have so many different builds (well, it's one reason at least). Take a peek at the source files and you'll find lots and lots of conditional assembly everywhere. All of it is basically so that we can make the most of what little space we have available in the ROM.I am only several days first time user of XUB
That's good to know! Thanks!
No problem! I'm just glad it works. Perhaps you were using ide_xtl.bin? It is the "Large" version of the 808x compatible builds and contains a more unrolled transfer loop that might possibly be the cause of a timing problem. What size is the ROM by the way? If only 8 KB then none of the Large builds can be used, of course.