PDA

View Full Version : 8-Bit IDE Controller



Pages : [1] 2 3 4 5 6

Agent Orange
September 23rd, 2008, 07:04 PM
I'm "upgrading" my old Tandy 1000SX and need a 8-Bit IDE controller. Something like or similar to an Acculogic sIDE-1/16. Any leads would be greatly appreciated. eBay proves negative at this time.

Thanx,

Agent Orange

Mike Chambers
September 23rd, 2008, 07:24 PM
there should be one or two on ebay in the ebay stores section, but the prices are ridiculous. i'd also love to know if anybody finds something reasonable, but of course Orange has first dibs. :)

hargle
September 24th, 2008, 05:36 AM
have we, as a group, ever looked into building our own and getting a small supply of them made up? After researching alternates to my SCSI problem on an XT, I see there are schematics posted for one, and I know that collectively we have the skillset to design and create such a card. I *might* even be able to ask some of my coworkers to help-we have a hardware design team, a couple board layout guys, and we get custom made PCBs made several times a year. Something like this would probably only take up an hour of their time.

I have no idea what a minimum order would be, or how much they would cost, or if parts can be sourced for such a relic, but I know I'd buy one in a heartbeat if I could, and I bet there are 10-20 others on this board alone would would do likewise.

Just thinkin.

Terry Yager
September 24th, 2008, 10:09 AM
It would have to interface to an AT-IDE drive though, as the XT ones are as hard to find as the 8-bit boards.

--T

kb2syd
September 24th, 2008, 10:27 AM
I have a very simple 8 bit controller that uses 16 bit drives. It has maybe 20 or 30 74ls IC and a boot ROM. I think it is limited to 512meg drives though.

Anyone interested in trying to reverse engineer?

rmay635703
September 24th, 2008, 10:41 AM
I have seen others mention doing this but its never panned out. Where is the schematic to build your own? Given that a dumb 8bit IDE controller requires no logic (just software or bios) I would think that a 16 bit variety would need some sort of flip flop and support chips to break 16bitters into 8 bits for the bus. The most simplistic solution would involve using a device driver to use the HD (I would not be against this solution if someone is willing to write a boot level driver for ide disk access) Or we need to integrate it into a bios which would be more complex for everybody since one would have to write a eeprom if they were assembling it themselves.

I guess I would be game for a pair; if someone was nice enough to take on the endevour!


have we, as a group, ever looked into building our own and getting a small supply of them made up? After researching alternates to my SCSI problem on an XT, I see there are schematics posted for one, and I know that collectively we have the skillset to design and create such a card. I *might* even be able to ask some of my coworkers to help-we have a hardware design team, a couple board layout guys, and we get custom made PCBs made several times a year. Something like this would probably only take up an hour of their time.

I have no idea what a minimum order would be, or how much they would cost, or if parts can be sourced for such a relic, but I know I'd buy one in a heartbeat if I could, and I bet there are 10-20 others on this board alone would would do likewise.

Just thinkin.

hargle
September 24th, 2008, 12:07 PM
The thread in question with schematics and stuff came from here:

http://www.vintage-computer.com/vcforum/showthread.php?t=7243

of which the main point of interest is here:

http://www.mylinuxisp.com/~jdbaker/oldsite/SmallSys/8bitIDE.html

I admit, I have not really absorbed the details from that page yet.

If we designed our own, we could also add an option ROM to it, and I (and a few others here) have x86 assembly experience and could likely write the appropriate hooks for INT13 to double pump the 16 bit data.

edit:
kb2syd: I'd love to disassemble that option rom on your board. I bet just scanning the PCB would get us a layout as well. Those things are pretty simple...

kb2syd
September 24th, 2008, 12:27 PM
How do I go about reading the boot rom on an ISA expansion card?

I'll try to disassemble the binary and see what it is doing. It is socketed so I guess I could pull it and send it out to someone, but I'd rather not.

Kelly

Chuck(G)
September 24th, 2008, 08:42 PM
If you can find one of the 8-bit adapters, try going to an IDE-CF adapter. Most (if not all) CF cards can do 8 bit transfers.

Druid6900
September 24th, 2008, 08:55 PM
The thread in question with schematics and stuff came from here:

http://www.vintage-computer.com/vcforum/showthread.php?t=7243

of which the main point of interest is here:

http://www.mylinuxisp.com/~jdbaker/oldsite/SmallSys/8bitIDE.html

I admit, I have not really absorbed the details from that page yet.

If we designed our own, we could also add an option ROM to it, and I (and a few others here) have x86 assembly experience and could likely write the appropriate hooks for INT13 to double pump the 16 bit data.

edit:
kb2syd: I'd love to disassemble that option rom on your board. I bet just scanning the PCB would get us a layout as well. Those things are pretty simple...


Looks like a pretty simple layout. Probably fit on a 2.5" x 3.5" PCB quite nicely.

Perhaps, if I get some time, I'll fire up Eagle 5.2 and play around with it.

Mike Chambers
September 24th, 2008, 09:38 PM
there is one ebay store seller who has three of them, anally priced at $200 each.

http://cgi.ebay.com/IDE-Controller-Card-IBM-PC-XT-8-bit-ISA-300859202-MS_W0QQitemZ350055349829QQcmdZViewItem?_trksid=p32 86.m20.l1116

http://cgi.ebay.com/IDE-Controller-Card-IBM-PC-XT-8-bit-ISA-300887200-P1-MS_W0QQitemZ130219122312QQcmdZViewItem?_trksid=p32 86.m20.l1116

http://cgi.ebay.com/IDE-Controller-Card-IBM-PC-XT-8-bit-ISA-61-000347-02-WD_W0QQitemZ130255851679QQcmdZViewItem?_trksid=p32 86.m20.l1116

if i had some money burning a hole in my pocket i'd pick one up, but that is pretty crazy!

hargle
September 25th, 2008, 06:07 AM
How do I go about reading the boot rom on an ISA expansion card?

I'll try to disassemble the binary and see what it is doing. It is socketed so I guess I could pull it and send it out to someone, but I'd rather not.

Kelly

http://www.brutman.com/PCjr/pcjr_downloads.html
pcjrcart.zip should work for dumping the image of it out to a file. You shouldn't need to pull the chip off the board or anything, just boot to DOS, run this and it'll locate your option ROMs and save them to files.



there is one ebay store seller who has three of them, anally priced at $200 each.


I certainly think we can get ours made for less than this. We might have to assemble them ourselves, which should be pretty easy, and if we add an option ROM to it, I will break the 512MB barrier in the int 13 support code.

Unknown_K
September 25th, 2008, 06:49 AM
Wouldn't an 8 bit SCSI card be more usefull then a low capacity IDE card? You can still find small SCSI HDs, and SCSI is a lower CPU hog then IDE.

hargle
September 25th, 2008, 07:10 AM
Wouldn't an 8 bit SCSI card be more usefull then a low capacity IDE card? You can still find small SCSI HDs, and SCSI is a lower CPU hog then IDE.

My interest in this stems from the fact that I can't get my future domain 850-MER with 8.2 BIOS on it to work on a true IBM XT machine. It works on a zenith machine, but I wanted to be true blue, so I may have to abandon SCSI.

At work, I'm also working closely with IDE drives, so I'm very familiar with the ATA command set, and oddly enough, as of yesterday, I was actually tasked with creating an option ROM for an IDE controller, so my work and personal interest are running parallel at the moment. It's just meant to be. :)

and here's some scans of a device that I googled up:

http://home.fuse.net/bobwatts/acculogic%208%20bit.htm

It looks incredibly simple, although I'm a software guy, not hardware.

kb2syd
September 25th, 2008, 07:45 AM
http://home.fuse.net/bobwatts/acculogic%208%20bit.htm

It looks incredibly simple, although I'm a software guy, not hardware.

And that is one of the ones I own.

Trixter
September 25th, 2008, 08:14 AM
I own a Silicon Valley ADP50 that I use in my 5160. It won't recognize drives over 500MB so I have it connected to a 340MB drive. Throughput on the machine is decent, 300KB/s read (drive is capable of more).

Would dumping this ROM help you guys?

MikeS
September 25th, 2008, 09:34 AM
Does this mean that there's still a use for those boxes full of < 2GB IDE and SCSI drives in my basement?

m

hargle
September 25th, 2008, 09:39 AM
I own a Silicon Valley ADP50 that I use in my 5160. It won't recognize drives over 500MB so I have it connected to a 340MB drive. Throughput on the machine is decent, 300KB/s read (drive is capable of more).

Would dumping this ROM help you guys?

yes please. I'll take all the option ROMs I can get my hands on.

A nice side effect is that if we disassemble your option rom, it is very possible that adding extended INT 13 support to push your card's capability up to 8.4 gig could be achieved.

This is turning out to be a lot of fun. I'm going to go pester our hardware layout guys and find out how much it costs to get a PCB made.

JoJo_ReloadeD
September 25th, 2008, 09:49 AM
I, as Trixter, only have a ADP50L which works great, but am in need of more cards of this type, so any progress on this issue would be really appreciated.

I have dumps of the ADP50L bios and the Yuko D16-X (another IDE-AT in isa 8 bit card), if you want them, you have them :)

Grindar
September 25th, 2008, 09:50 AM
2 layer or 4 layer? 2 layer runs something like 30 + (number of boards x area in sq inches x 90 or so cents, US currency) it varies, especially if you want silk screens or solder masks. That was with neither, as I recall.

hargle
September 25th, 2008, 10:45 AM
I suspect 2 layer should be enough. This is about as simple as it gets.

My coworker just gave me a couple ads for PCB mfg and they go something like this:

2 layer PCB, up to 60" sq, free silkscreen, tooling and mask, for $25.
No minimum qty.

So, at 60 square inches, I'd think we could drop 4 or more of them onto the same board.
If we were able to assemble them ourselves, the cost could easily be $20 or less per board. (I've no idea what the parts would cost)

That ASCII schematic as seen here:

http://www.mylinuxisp.com/~jdbaker/oldsite/sourcecode/xtide.c

didn't have an option ROM on it, so I think we'd be better off trying to clone one of these ADP50L boards. So that would require a hi-res scan of both sides of the PCB, a dump of the option ROM, and perhaps a few hours with a multimeter to make sure all the connections are known.
If anyone else can handle the PCB layout, schematics and hardware end of it, I am all over the option rom side of it...

Druid6900
September 25th, 2008, 10:47 AM
I did the initial chip and connector placements last night and PCB123 is predicting the PCB will cost about 10 bucks US each in a quantity of 25.

That's a 2.5" x 3.5" XT board with room for a ROM and a dip-switch (which was mentioned but not shown in the schematic) either of which will, no doubt, signifigantly change the layout.

genocho
September 25th, 2008, 12:24 PM
The project sounds amazing, with the add of the bios boot rom, and if you can brake the 512mb barrier, that card will be the dream of all xts fans.

With a simple ide to cf adapter you can use cfs with 0 noise, no mecanic parts and preserve the longevity of the xt machines.

Many old machines have this solution, spectrum divide, msx sunrise, etc, I think is the pc turn to have a modern standard storage card adapter.

Go ahead with the project, and good luck !!!

Offtopic:

If its possible to adapt usb protocol to isa bus, for obtain an usb host adapter, for keyboards, joysticks, hd drives, etc ???
I think usb protocol is designed for pci bus, but perhaps can be adapted to isa one........
Imagine an xt with usb devices................DREAM IS FOR FREE!!!

per
September 25th, 2008, 01:12 PM
Offtopic:

If its possible to adapt usb protocol to isa bus, for obtain an usb host adapter, for keyboards, joysticks, hd drives, etc ???
I think usb protocol is designed for pci bus, but perhaps can be adapted to isa one........
Imagine an xt with usb devices................DREAM IS FOR FREE!!!

It is theoretical possible (if not the transfer-speed exceeds the system bus). All you need is an adaptor (with volt reducers and some controllers), and a Homemade DOS driver. And of course, a Homemade DOS USB Driver for the actual device you have connected to the card.

It would of course take years (escapely because every single USB device need it's own device-driver), but I agree, it would have been cool.

Ec1564
September 25th, 2008, 01:14 PM
I have a Tandy 1000TL/2 that the HDD controller on the MB failed. I am using a 8 bit XT ide card to run a CF card. I have 2 XT ide cards and only one would work with the CF card in the TL/2. The one card I have is a Seagate ST-05x card. this one did not reconize the CF. The other is a Silicon Valley card ADP50 ??(forgot which one till I boot up the TL/2)which works really good on the TL/2.
Some of the boot BIOS may not reconize the CF cards or it was the TL/2 being picky, not sure till I get another CF adapter and get the IBM 5150 running with the Seagate card.

hargle
September 26th, 2008, 07:05 AM
I did the initial chip and connector placements last night and PCB123 is predicting the PCB will cost about 10 bucks US each in a quantity of 25.

That's a 2.5" x 3.5" XT board with room for a ROM and a dip-switch (which was mentioned but not shown in the schematic) either of which will, no doubt, signifigantly change the layout.

Fantastic! I was given some winBoard PCB layout software by my coworker this morning, but it appears you've got it all under control. (thank you for taking it!)

We absolutely need an option ROM on the thing, as well as the bank of dip switches or jumpers to move the address decode around as one would expect on such a card. I suspect a 16k rom at most would be required, having it flashable or at least eeprom programmable is ideal (and socketed), since I don't have a UV eraser at my disposal, but I do have a burner. The BIOS, while most of it stolen from other option ROMs from similar boards, will all be open source.

Questions:
Do we want the I/O decode to be selectable from 1f0 to 170, so you could theoretically put 2 of these boards into a machine?
I don't see any reason why it shouldn't be able to support 2 drives at a minimum.
Do we need CDROM support? I'm not sure what implications this will have on the option rom code. It won't be a priority for me to code, that's for sure.
Can you even run MSCDEX on an 8088?

wow. just wow.

mbbrutman
September 26th, 2008, 07:18 AM
I'm glad to see this thread takeoff like this ... I've looked at the IDE interface quite a bit recently while helping some poor guys hack their Gridcase machines to take other hard drives.

Definitely design the I/O decode to handle alternate ports. You will probably need to debug this on a machine with an existing hard drive.
MSCDEX will run on an 8088. I run it on a NEC V20 equiped PCjr when I use a SCSI setup.
The hard part is the ROM.

So just to be sure I understand, you are going to design the interface to work with 16 bit drives? This is going to require latching all 16 bits from the drive, then feeding it back to the machine 8 bits at a time over two distinct I/O cycles. All of the control and status registers are 8 bits so it is not a problem, but the 16 bit I/O for data will require latching.

That's going to require the option ROM to do an I/O cycle for the first 8 bits, then change addressing on the board to be able to access the second bits before the next I/O cycle.

The good news about the ROM programming is that the bare minimum can be found in the AT technical reference, which was designed with MFM controllers in mind. (IDE is a superset of MFM.) You can learn a lot looking at the BIOS listing and do the debug work of latching and moving the extra bits with an existing known good base to start from.

MikeS
September 26th, 2008, 08:58 AM
Or you could just fageddabout the upper 8 bits; IDE storage is cheap & plentiful.

m

mbbrutman
September 26th, 2008, 09:16 AM
I'm not worried about cutting the capacity of the drive in half. I'm more worried about sector addressing issues.

If you do it that way, then you wind up with the equivalent of 256 byte sectors when they should be 512. Compensating for that is worse than just doing it correctly.

That trick is acceptable on an 8 bit micro where there is no existing API or expectations about sector size. It's not so hot for a PC solution.

Terry Yager
September 26th, 2008, 09:19 AM
Or you could just fageddabout the upper 8 bits; IDE storage is cheap & plentiful.

m

So, a 1Mb drive would actually store only 512K? I could live with that.

--T

hargle
September 26th, 2008, 09:27 AM
So just to be sure I understand, you are going to design the interface to work with 16 bit drives?


Yep. The plan (as far as I can see) is to clone this:
http://home.fuse.net/bobwatts/acculogic%208%20bit.htm
(or similar, like the ADP50L-anything that can do 16bit drives and has an option ROM and no additional ASIC hardware)

ADP50L jumper settings:
http://www.peteweb.com/ftp/mirrors/hardware_specs/c/S-T/20200.htm


Since we can dump-n-disassemble the ROM, and provided the other chips are "off the shelf", at a minimum we should be able to do exactly what that board can do. The only thing we'd want to add would be enhanced INT 13 support for up to 8.4Gig drives. (I really don't think 48bit LBA is required)

Even without the ability to move the I/O decode, we should still be able to debug on a 386+ machine by just disabling the onboard controller(s). That'll free up the I/O range.

Druid6900
September 26th, 2008, 10:48 AM
Fantastic! I was given some winBoard PCB layout software by my coworker this morning, but it appears you've got it all under control. (thank you for taking it!)

We absolutely need an option ROM on the thing, as well as the bank of dip switches or jumpers to move the address decode around as one would expect on such a card. I suspect a 16k rom at most would be required, having it flashable or at least eeprom programmable is ideal (and socketed), since I don't have a UV eraser at my disposal, but I do have a burner. The BIOS, while most of it stolen from other option ROMs from similar boards, will all be open source.

Questions:
Do we want the I/O decode to be selectable from 1f0 to 170, so you could theoretically put 2 of these boards into a machine?
I don't see any reason why it shouldn't be able to support 2 drives at a minimum.
Do we need CDROM support? I'm not sure what implications this will have on the option rom code. It won't be a priority for me to code, that's for sure.
Can you even run MSCDEX on an 8088?

wow. just wow.

Ok, just so we are on the same page, I'm using the schematic from here;

http://www.mylinuxisp.com/~jdbaker/oldsite/documents/xtide.txt

for the design.

If you are going to add other devices (ROM, switches/jumpers), then either modify the schematic and send it to me or provide me with another schematic.

hargle
September 26th, 2008, 11:23 AM
Ok, just so we are on the same page, I'm using the schematic from here;

http://www.mylinuxisp.com/~jdbaker/oldsite/documents/xtide.txt

for the design.

If you are going to add other devices (ROM, switches/jumpers), then either modify the schematic and send it to me or provide me with another schematic.

I think that's a good start, at least getting familiar with the layout, physical size, estimated cost/board, and parts used, etc, but we're going to need someone with one of the cards with a BIOS on it to scan both sides of the card for us and try to draw up a new design from. We've gotta have a BIOS on it.

Now, I'm no hardware engineer. I've never created a schematic or used a layout tool, but I'm willing to try and at least connect the dots off a nice hi-res scan of the card and at least get the part numbers used to see if we can match 'em, and hopefully we can build a new schematic from there.

So, can one of you guys with one of the cards with a BIOS on it please make some scans for us? (and dump the rom?)

Mike Chambers
September 26th, 2008, 11:27 AM
it looks like this project is actually seriously being look into, AWESOME news! i will absolutely buy one the instant you guys get them made. :) (maybe two, one for each of my 8088's)

i wish i could help, but i don't know what i really could do. is there anything? i wonder how much one board would cost to make after everything is said and done.

hargle
September 26th, 2008, 11:59 AM
yeah, it's one of those engineering things:

I'm too cheap to buy one of these cards for $200 of ebay, but I'll spend 600 hours of my time designing, building, testing and debugging one, so I can open source it and give it all away for free when it's finished. heh.

Similarly, I'll spend 4 hours searching the couch for the lost remote control, but I won't just get up and flip the channel.

Mike Chambers
September 26th, 2008, 12:17 PM
lol. i'm exactly the same way with my DOS software. i'm just happy if it helps the community get new uses out of their old computers.

MikeS
September 26th, 2008, 01:15 PM
I'm not worried about cutting the capacity of the drive in half. I'm more worried about sector addressing issues.

If you do it that way, then you wind up with the equivalent of 256 byte sectors when they should be 512. Compensating for that is worse than just doing it correctly.

That trick is acceptable on an 8 bit micro where there is no existing API or expectations about sector size. It's not so hot for a PC solution.
--------
I figured if you're going to split/combine 8 & 16 bits anyway then it'd be just as easy or easier to combine two sectors, but now that I think about it a little more you're right; probably easier to do the 8/16 thing.

m

Trixter
September 26th, 2008, 06:48 PM
yeah, it's one of those engineering things:

I'm too cheap to buy one of these cards for $200 of ebay, but I'll spend 600 hours of my time designing, building, testing and debugging one, so I can open source it and give it all away for free when it's finished. heh.

Similarly, I'll spend 4 hours searching the couch for the lost remote control, but I won't just get up and flip the channel.

Just curious, how will this controller transfer data? My electronics-fu is very weak. PIO, or DMA, or RAM window? (I vote for DMA from port-to-RAM, that is the fastest obviously)

Druid6900
September 26th, 2008, 08:51 PM
So, can one of you guys with one of the cards with a BIOS on it please make some scans for us? (and dump the rom?)

A scan isn't going to do it.

Scanners have almost zero "depth of field" and, although we'd get the chip numbers on one side nice and clear and the same with the solder points on the other side, the chip height may make the traces blurry.

The second problem would be that the light source would show the traces from one side on the other where there was no thick solder mask.

A shadow-mask would be ideal, a schematic would be optimum, an actual card to "ring out" would be good too, but, if worse comes to worse, a super-high res picture of both sides of the board is workable.

When I reverse engineered the buffered interface cable for the TRS-80 Model I expansion interface, I used an ohmmeter to trace each connection from one side of the board to the other.

Jorg
September 26th, 2008, 11:22 PM
yeah, it's one of those engineering things:

I'm too cheap to buy one of these cards for $200 of ebay, but I'll spend 600 hours of my time designing, building, testing and debugging one, so I can open source it and give it all away for free when it's finished. heh.

Similarly, I'll spend 4 hours searching the couch for the lost remote control, but I won't just get up and flip the channel.

Sounds familiar, you must be an engineer ;) Exam passed.

Its the problem that needs to be solved!

Mike Chambers
September 26th, 2008, 11:56 PM
Just curious, how will this controller transfer data? My electronics-fu is very weak. PIO, or DMA, or RAM window? (I vote for DMA from port-to-RAM, that is the fastest obviously)

DMA would rock. i hate RAM window stuff. my old 3com 3c503 actually has jumpers to shared memory address settings, and also a jumper position to disable it. it is noticeably slower when using shared RAM on an 8088.

Terry Yager
September 27th, 2008, 07:58 AM
Exam passed.

I thought that was the Hacker Test...

--T

hargle
September 27th, 2008, 09:17 AM
A scan isn't going to do it.

Scanners have almost zero "depth of field" and, although we'd get the chip numbers on one side nice and clear and the same with the solder points on the other side, the chip height may make the traces blurry.

The second problem would be that the light source would show the traces from one side on the other where there was no thick solder mask.

A shadow-mask would be ideal, a schematic would be optimum, an actual card to "ring out" would be good too, but, if worse comes to worse, a super-high res picture of both sides of the board is workable.

When I reverse engineered the buffered interface cable for the TRS-80 Model I expansion interface, I used an ohmmeter to trace each connection from one side of the board to the other.

that makes sense...
I remember talking to some of my old timer co-workers and they used to photocopy boards that they wanted to clone. Figured we'd do the same thing, just a bit more 21st century.

So, we're at a bit of a standstill until one of the owners of these cards is able to get us some info on them. If anyone wants to mail me one of the cards so I can spend some quality time with a multimeter on it, that would be even better. (PM me) I'll pay for shipping each way and have it returned to you within 2 weeks.

dongfeng
September 27th, 2008, 11:06 AM
I have an Acculogic sIDE card... but I believe that it is the 8-bit version, rather than 16-bit one, so I've never had success in using it. I'm in the UK, but I'd be happy to send it to you if nobody closer comes up trumps :)

http://th99.dyndns.org/c/A-B/20002.htm

hargle
September 29th, 2008, 05:41 AM
Just curious, how will this controller transfer data? My electronics-fu is very weak. PIO, or DMA, or RAM window? (I vote for DMA from port-to-RAM, that is the fastest obviously)

At a minimum, PIO. Transferring data from a hard drive using PIO is literally a "rep insw" instruction. I honestly don't know how the hardware handles 16bits of data coming in to an 8bit bus, whether it's a matter of reading 2 ports or 2x reading a single port. (this is why I need a BIOS dump to start digging out how it's done on these cards). I suspect these little hardware hurdles may stop DMA from working properly, and there are probably DMA issues on the PC/XT that I don't even know about; I'm pretty DMA dumb, especially on anything earlier than a pentium.

hargle
September 29th, 2008, 05:44 AM
I have an Acculogic sIDE card... but I believe that it is the 8-bit version, rather than 16-bit one, so I've never had success in using it. I'm in the UK, but I'd be happy to send it to you if nobody closer comes up trumps :)
http://th99.dyndns.org/c/A-B/20002.htm

Thanks for the offer!

[a possible question for mbbrutman:]
Wouldn't it be possible to know if it's an 8 or 16bit version by moving the hard drive onto a 16bit controller and examining the 1st sector? If you only see 1/2 the data, then we know it's only an 8bit card and essentially only using 1/2 of the drive?

Trixter
September 29th, 2008, 06:06 AM
At a minimum, PIO. Transferring data from a hard drive using PIO is literally a "rep insw" instruction.

Right, except that 808x doesn't support REP INSW. That was 80286 and later. So it looks like DMA for you, my friend!

Either that, or memory on the adapter that can be REP MOVSW to host memory, but that would require a ton of CPU involvement. There's a reason DMA was included on the original PC (it's the fastest way to do things).

Trixter
September 29th, 2008, 06:07 AM
Thanks for the offer!

[a possible question for mbbrutman:]
Wouldn't it be possible to know if it's an 8 or 16bit version by moving the hard drive onto a 16bit controller and examining the 1st sector? If you only see 1/2 the data, then we know it's only an 8bit card and essentially only using 1/2 of the drive?

You're confusing a few things here: 8-bit ISA cards and 8-bit XT-IDE interfaces. Not the same thing. And no, that idea wouldn't work :)

dongfeng
September 29th, 2008, 06:27 AM
Yes, sorry, I didn't explain too well!

The Acculogic sIDE-1 card I have is 8-bit ISA, but it will only work with 8-bit (XT) IDE drives (and a few limited sizes at that).

Its sister card - the Acculogic sIDE-1/16 is similar, but also works with 16-bit (AT) IDE drives!

Unfortunately, the 20MB XT IDE drive it came with is dead... so I'm unable to test :(

Data sheets below.

Acculogic sIDE-1: http://th99.dyndns.org/c/A-B/20002.htm

Acculogic sIDE-1/16: http://th99.dyndns.org/c/A-B/20003.htm

hargle
September 29th, 2008, 06:37 AM
Right, except that 808x doesn't support REP INSW. That was 80286 and later. So it looks like DMA for you, my friend!


That's fine. I was merely describing how PIO data transfers are done-if there's no rep insw, we simply do an "in al, dx" and loop it. I too would prefer DMA, but we've got I/O latching trickery to deal with which might break our DMA transfer, depending on how it's done. Either way, I'd no plans on changing what's already done in the option rom that the card is already using. I don't want to change the hardware that much-I just want to duplicate an old card, then just upgrade the BIOS a little bit to support enhanced int 13 support.

mbbrutman
September 29th, 2008, 06:51 AM
Drives: 8 bit vs. 16 bit

Any recent IDE drive is going to implement 16 bit transfers. I'm not sure if the 8 bit transfer mode is required. There is a 'set features' command that is used to enable or disable 8 bit mode. If the mode is not supported you probably get a bad return code.


Bus interfaces: 8 bit vs. 16 bit

We're clearly 8 bits here.

Like I said in the previous post, we just have to assume that drives are doing 16 bit transfers. So the IDE card has to do a 16 bit transfer and buffer both incoming bytes when talking to the drive. The first read gets the low byte, and the second read is 'faked' and actually moves the buffered byte so that it can be read by the 8 bit bus.

I'm not a EE, but I'm close. And we're not breaking new ground here - there are a lot of people who have done IDE interfaces for 8 bit machines. We have the potential to do this.


Hargle - you are local to me. This might make more sense over a beer or 3.

hargle
September 29th, 2008, 07:11 AM
Drives: 8 bit vs. 16 bit
Hargle - you are local to me. This might make more sense over a beer or 3.
I think everything makes more sense after 3 beers! :)

I never turn down an offer for a drink; I'll PM you next week-this week is crazy.

I don't suppose you've got one of these magical cards in your collection?

mbbrutman
September 29th, 2008, 07:31 AM
No, but I've got a bit of experience reverse engineering cards and disassembling things. Living with a PCjr makes it kind of a necessity. This isn't the first time I've looked at the IDE interface with lust in my eyes ...

If anybody has a card that they can loan me, I'd be happy to safeguard it and help with the recreation. I'm also local to Hargle, so that is convenient.

Btw, the scanner trick for cards can work for reading components. I've made some fairly decent scans of cards, some of which are on my PCjr web site. One still needs to use a meter to find the point to point connections. But knowing what the discrete components are is a big part of the problem. After one knows what to use and what functions it serves, the point to point connections become much easier.

At worst case a reasonable digital camera with a macro mode can do good work.


Mike

Druid6900
September 29th, 2008, 10:30 AM
Yes, of course knowing what the components are comes in marginally helpful. :)

A net list (point to point to point) would suffice to do the board layout.

Now, the big question is, do we have to modify the design to get around an existing copyright?

On the buffered interface card I did, I used connectors that had two rows of 20 connectors instead of the original 4 rows of 10 for the in and out cables which change the entire layout while preserving the electronic functionality.

We don't want to get our asses sued off down the road.

mbbrutman
September 29th, 2008, 10:59 AM
I don't know if I want to 'clone' the board pin for pin. I think I'm more in the 'reverse engineer' camp.

The copyright issue is real, but it's going to be hard to get somebody interested in suing us unless we are making a serious profit. This is a dead product ... It will be less of a problem if we take the time to understand how the design works and do our own design. It will also be easier to enhance and debug.

hargle
October 8th, 2008, 06:00 AM
ok, back from my busy week, and it's time to continue pushing on this subject.


kb2syd,

Can I bribe you to photograph and/or scan your sIDE-16 card, and dump the option ROM and post all the stuff for us? I've got co-workers who are layout/schematic specialists and are soon to be somewhat bored because we've just sent off our latest circuit board and there's nothing coming down the pipe for them to do.

I think they'd be really happy to have something quirky like this to work on.

greglentz
October 8th, 2008, 07:39 PM
I am unable to contribute hardware or firmware but would definitely buy one or even two cards if your thoughts on price are shown to be true. Currently using two RLL drives in a Tandy 1000SX but one has failed for some reason (still spins up and unparks the heads but the controller card no longer recognizes it, not even for a low level format using the controller low level format routine in the firmware at C800. I can get a "new" 40-60MB drive for <$100 but would much rather go to something newer even if a new IDE drive were mostly unused due to firmware/bios/int 13/OS limitations.

Additional thoughts.
I assume current IDE drives are 16-bit interface??? So if card does 16 bit then any current ide drive should work-just set up a partition, or two, or more, of <504MB each. One could use a modern computer to do it then install the drive in the old computer and the computer should be able to see all those partitions-oh the possibilities

Don't forget there are several size barriers, bios, int 13, OS etc. One could install a driver such as Disk Manager but those are always more trouble than benefit.

Besides jumpers to control where option rom goes in upper memory, also need IRQ setting. At least some cards (RLL or MFM) from that era had option for IRQ 5 vs. 2. I assume an IDE card would also. I personally need IRQ 2 which is different than the std XT of IRQ 5.

If the experts out there are able to pull this off, even in kit form, for the pricing being talked about this would be a real benefit to the vintage hobbyists out there.

Greg Lentz-Waiting anxiously for more news.

hargle
October 9th, 2008, 06:59 AM
I assume current IDE drives are 16-bit interface???

yes. your typical, modern off the shelf IDE drive is (at a minumum) 16bit.
My plan is to use old 10Gig drives from Xbox 1's, of which I have a half dozen of.



Don't forget there are several size barriers, bios, int 13, OS etc. One could install a driver such as Disk Manager but those are always more trouble than benefit.

The BIOS/int 13 size barriers will be eliminated by the option rom, at least up to 8.4gig anyway, and I think 8.4gig on a PC/XT is plenty of space. :)
Disk manager software is basically an INT 13 add-on/enhancement, so we might as well just do that same thing inside the option rom and make it cleaner for everyone. You're still limited to whatever O/S limits there are, but that's your own fault. ;)



Besides jumpers to control where option rom goes in upper memory, also need IRQ setting. At least some cards (RLL or MFM) from that era had option for IRQ 5 vs. 2. I assume an IDE card would also. I personally need IRQ 2 which is different than the std XT of IRQ 5.


If we end up effectively cloning the sIDE-16 card, we'll have IRQ 2 and 5 at a minimum. Not sure what would be required to allow for additional IRQs to be available, but we'll look into it.



If the experts out there are able to pull this off, even in kit form, for the pricing being talked about this would be a real benefit to the vintage hobbyists out there.


I agree-I think this project is certainly within our collective skill set, and I'd really like to see it created as a VC project and sold at cost to other VC members. (I'd even like to see the VC website silkscreened onto the card itself to make it "ours" for example)

My current plan of attack is to get all the info from the sIDE-16, and see if we can still get the same/equivalent parts available as modern surface mount parts. We then disassemble the BIOS, use 90% of what's there already, add enhancements to INT 13 to allow 8.4G, and make any other minor adjustments such as adding additional IRQs and selectable I/O addresses and get them built. It's still cloning the basic functionality, but with our own enhancements.

I'd also be perfectly happy filling and shipping orders for the finished cards/kits, and depending on the complexity of the finished product, could be convinced to solder them up for people too. We can do this.

Dave586
October 9th, 2008, 01:35 PM
I'm not the only crazy one still alive looking for old computer stuff to fiddle with? This is cool. This forum is one of the best forums google has brought to my attention.

Oh yeah and as for this card being discussed, I'll buy one maybe two. Great idea, I can put some of those junky hard drives <--what the wife calls to them- to good use! And the two Tandy 1000s in storage will be happy again. I actually found some V20 chips for sale too.

Anyway, have a nice day!

greglentz
October 10th, 2008, 10:30 AM
Here's someone's picture of the sIDE-1/16 card. It is only the component side though.

http://home.fuse.net/bobwatts/xt.htm


Greg Lentz

per
October 10th, 2008, 11:08 AM
Here's someone's picture of the sIDE-1/16 card. It is only the component side though.

http://home.fuse.net/bobwatts/xt.htm


Greg Lentz

Can you download and run PCJrCart ( http://www.brutman.com/PCjr/downloads/pcjrcart.zip ) on the computer when you have the card installed, then upload the outputted files here?

Druid6900
October 10th, 2008, 12:04 PM
Can you download and run PCJrCart ( http://www.brutman.com/PCjr/downloads/pcjrcart.zip ) on the computer when you have the card installed, then upload the outputted files here?

I don't think it's his computer.

per
October 10th, 2008, 12:30 PM
I don't think it's his computer.

Oh... I'm not actually form an english speaking contery, but I thought a person actually owned a thing when (s)he used the word "the" instead of "a" before an object.

HOWEVER I might be wrong, and I don't want this topic to get off-topic, so I'll post a link to some information I just found. I don't know if you already know the information ,but for those who just are curious about the project, the information on the site would be a good explanation: http://www.pjrc.com/tech/8051/ide/wesley.html

Mike Chambers
October 10th, 2008, 12:33 PM
Oh... I'm not actually form an english speaking contery, but I thought a person actually owned a thing when (s)he used the word "the" instead of "a" before an object.

HOWEVER I might be wrong, and I don't want this topic to get off-topic, so I'll post a link to some information I just found. I don't know if you already know the information ,but for those who just are curious about the project, the information on the site would be a good explanation: http://www.pjrc.com/tech/8051/ide/wesley.html

not quite, in the case of his post he used "the" as in the card, in a general sense. it is correct to use it that way as well. english is a very sloppy language.

:mrgreen:

per
October 12th, 2008, 06:00 AM
http://home.fuse.net/bobwatts/xt.htm

I got in contact with the site owner, and he is willing to suply a BIOS dump and scans of the card. I will have it uploaded here as soon as I get it.

bobwatts
October 12th, 2008, 06:04 AM
Hi Gang !

Per just recently informed me of your August group. I own the XT computer with the sIDE 8/16 IDE controller card, and now that I have been made aware of what is trying to be done, I will dump the BIOS ROM, and get some quality scans of the card to post to a webpage for your use(s).

Great website, great discussions, great that I "found" it, thanks to "Per" !

I'll be in touch !

bobwatts
EartH

Terry Yager
October 12th, 2008, 10:57 AM
Hi Gang !

Per just recently informed me of your August group. I own the XT computer with the sIDE 8/16 IDE controller card, and now that I have been made aware of what is trying to be done, I will dump the BIOS ROM, and get some quality scans of the card to post to a webpage for your use(s).

Great website, great discussions, great that I "found" it, thanks to "Per" !

I'll be in touch !

bobwatts
EartH

Are you the Bob Watts in Ohio?

--T

Terry Yager
October 12th, 2008, 11:03 AM
Oh... I'm not actually form an english speaking contery, but I thought a person actually owned a thing when (s)he used the word "the" instead of "a" before an object.

Unfortunatey, us peeples in Nglish-speeking countrys (specialy USA), do'ntn always tawk much good inglish. R ritin' skills are also attrocious, abd don't even ask bout ar spelin...!!!

--T

Anonymous Coward
October 12th, 2008, 11:44 AM
Whatever happened to that website of yours with the souped up XT in the mini-tower case? I really liked it.

per
October 12th, 2008, 11:48 AM
Unfortunatey, us peeples in Nglish-speeking countrys (specialy USA), do'ntn always tawk much good inglish. R ritin' skills are also attrocious, abd don't even ask bout ar spelin...!!!

--T

Did you read the rest of my post? ;)

I would rather blame my english teacher than blaming you for spelling. :D

bobwatts
October 12th, 2008, 01:13 PM
Hello !

Yes, I am the bobwatts in Ohio, USA, EartH.

But you're not supposed to know that. The statute of limitations has not run out on some things yet.

bobwatts
EartH

Druid6900
October 12th, 2008, 08:46 PM
Hello !

Yes, I am the bobwatts in Ohio, USA, EartH.

But you're not supposed to know that. The statute of limitations has not run out on some things yet.

bobwatts
EartH

Yup, HAS to be an acquaintance of T LMAO

bobwatts
October 14th, 2008, 02:36 AM
Hi Gang !

Finally got the 'ol WhiZZbanG XT out of deep deep storage. The last time this thing saw light, it performed flawlessly. It had been sitting since sometime last century, and hadn't seen the light of day for at least 6 or 7 years.

Naturally, this time I had some problems. First off was operator error. I plugged in an AT keyboard. :rolleyes:

Sat and stared at the "keyboard error" for a couple of seconds, then figured it out. Shut down. Went searching for an XT keyboard ( I know, but I rarely keep one handy ), and plugged that in. :mrgreen:

( how aggravating to use an old IBM XT keyboard. Nothing is in the "right place". :sly:)

Noted that the boot up time was pretty extended, but finally it mentioned that it was going to go ahead and start DOS 6.22. Fine. What the heck, it's only 10MHz, and it's probably not happy about being disturbed.

Went back to WhiZZbanG One, got the PCJRCART.EXE file, and inserted the floppy. ( remember, I have a hi-density controller in this World Class XT, and it supports a 1.44 drive, as well as a 360K ).

Since I had the computer sitting sideways to me, I didn't notice that any floppy drive lights were lit. The floppy drive didn't work. Dammit. :sneaky:

Fine. Shut down, take apart, and become PC Tech. Simple things first. Remove card, stare at it, and threaten it. ( no cuss words yet.... ) Clean contacts, and re-insert.

Reboot computer, starts a LOT faster,( obviously, it was looking for flop drives earlier ) floppy drive lights, and now a message is on boot up concerning the floppy controller, as well as the sIDE controller, and BOCA memory card. ( and the VGA card ). Now we're cooking! :p

Ran the PCJRCART.EXE program, dumped the ROM, and sent the files to PER. As soon as he "approves" of them, I'll pull the sIDE card, and get some better pictures, or scans, whatever it takes. I have a really good camera, and it might do the job, but if not, I can scan the thing.

At this point, if ANYONE wants to see something, let me know, 'cause when I get done with this little project, this computer goes back into long term storage. It's very aggravating to dig it out, and unwrap it. :twisted:

Great project, and put me in line for a controller card if it works out !

bobwatts
EartH

per
October 14th, 2008, 02:57 AM
Here is the HDD BIOS file. There was also a system bios, VGA Bios and a FDD bios, but I figured they wheren't interesting in this thread.

bobwatts
October 14th, 2008, 03:39 AM
Hi Gang!

Some scans of the sIDE controller can be seen here:

http://home.fuse.net/bobwatts/acculogic%208%20bit.htm

( or, if you prefer..... )

http://home.fuse.net/bobwatts/acculogic%208%20bit.htm

bobwatts
EartH

hargle
October 14th, 2008, 08:04 AM
thank you thank you thank you thank you thank you thank you thank you

I've started disassembling the BIOS already. Unfortunately i'm insanely busy at the moment, but this is going to be a top priority task for me to complete.

The images look really good too, I think we can identify the parts and pick apart some of the traces fairly well.

i'll post back more when I get somewhere with the BIOS...

Edit sometime later:
Here's an important snippet of code (IMO)


mov cx, 256
loc_C8437: ; CODE XREF: sub_C83FC+4Bj
mov dx, 360h ; data register
in al, dx
mov es:[di], al
inc di
mov dx, 368h ; upper data register
in al, dx
mov es:[di], al
inc di
loop loc_C8437


So, it looks like the standard IDE registers are being mapped by this card at 360-367. Other code snippets appear to match up when it's checking for busy, seek, etc.

Since it's 8bits only, the upper 8bits of the data are being decoded at I/O 368, and this code is reading both ports and merging the data in memory. This is pretty much exactly how I thought it should/would work, so yay.

hargle
October 15th, 2008, 10:28 AM
hey gang,

the BIOS disassembly is going really well. I'd say I'm about 1/3 finished or better already.

I've come across a few things that I think might require some input:

1) there's code in here for read/write precompensation, and a lot of heavy duty status and error checking while it waits for seek completes and things like that.
With newer hard drives, a lot of this stuff is really pretty useless, especially the precomp.
Do we keep this stuff in there, or optimize it out? We'd break backwards compatibility with ancient IDE drives, but c'mon, if you're putting an IDE drive in an XT, why not use one that is > 40MB and utilize a modern drive's capabilities? Nuking that stuff will get us a smaller option rom, and probably faster performance since it won't be doing so much overhead.
(this can obviously be changed anytime)

2) There's an interactive menu at c800:5 that allows the user to override parameters of the drive. Do we care about it? I suspect it's for incompatibilities and operating system hacks and probably not important anymore. I've so far avoided it, but I'll comment it and flesh it out if people want.

3) there's support for a few obscure disk functions, like read w/ ECC data and the like. I've already fairly well documented them and disassembled them, but does anyone use that stuff anymore?

Oh, and BTW: this thing is using PIO only to do all data transfers. upgrading it to DMA would require more work. Probably doable, but I'd need to do some research on that.

Terry Yager
October 15th, 2008, 11:58 AM
hey gang,
<snip>
Oh, and BTW: this thing is using PIO only to do all data transfers. upgrading it to DMA would require more work. Probably doable, but I'd need to do some research on that.

Would eliminating the older code break compatibility with Tandy 1000-Series machines?

--T

hargle
October 15th, 2008, 12:09 PM
Would eliminating the older code break compatibility with Tandy 1000-Series machines?

--T
to be perfectly honest, I have no idea. I'd think a DMA/PIO option would be selectable via jumper instead of requiring only DMA. The other code eliminations are more IDE drive specific than platform specific, so I think those are safe to eliminate, provide you use a drive that is ATA-3 spec compliant or higher.

per
October 15th, 2008, 12:14 PM
I don't know anything about how IDE works, however, Will it be possible to use the original ROM if I don't choose to have DMA amd swich (replace the IC) to the custom ROM if I want DMA?

In other words, will the card you are planning and working on be compatible witht the original ROM as well as the custom ROM you are making?

hargle
October 15th, 2008, 02:07 PM
In other words, will the card you are planning and working on be compatible witht the original ROM as well as the custom ROM you are making?

right now, that all depends on if we have to change any of the hardware due to parts being unavailable or anything else that comes up. *if* we could get the same parts that are on the board right now and clone the schematics, then you could very well just take the original BIOS as posted right now and use the board exactly as a replacement of this card. I think the chances are small that we're going to be able to locate hardware that does exactly what this stuff does, so some minor changes will be required to the BIOS anyway, so while we're in there, we might as well add some other goodies like DMA support and extended INT 13h.

Before I make any modifications, I'll post a version that compiles to what the BIOS is right now, so we can all have the original source to play with.

Terry Yager
October 15th, 2008, 04:09 PM
Source code? <Shiiivverrrr>!

--T

bobwatts
October 16th, 2008, 03:04 AM
Hello !


hey gang,

the BIOS disassembly is going really well. I'd say I'm about 1/3 finished or better already.

I've come across a few things that I think might require some input:

1) there's code in here for read/write precompensation, and a lot of heavy duty status and error checking while it waits for seek completes and things like that.
With newer hard drives, a lot of this stuff is really pretty useless, especially the precomp.
Do we keep this stuff in there, or optimize it out? We'd break backwards compatibility with ancient IDE drives, but c'mon, if you're putting an IDE drive in an XT, why not use one that is > 40MB and utilize a modern drive's capabilities? Nuking that stuff will get us a smaller option rom, and probably faster performance since it won't be doing so much overhead.
(this can obviously be changed anytime)

2) There's an interactive menu at c800:5 that allows the user to override parameters of the drive. Do we care about it? I suspect it's for incompatibilities and operating system hacks and probably not important anymore. I've so far avoided it, but I'll comment it and flesh it out if people want.

3) there's support for a few obscure disk functions, like read w/ ECC data and the like. I've already fairly well documented them and disassembled them, but does anyone use that stuff anymore?

Oh, and BTW: this thing is using PIO only to do all data transfers. upgrading it to DMA would require more work. Probably doable, but I'd need to do some research on that.

Fascinating project. It's interesting to see great minds at work. I have a few comments:

1)I *would* ( like *I* could ) change the code for compatibility for "later" IDE drives, and forget about compatibility with "older" drives. If you're gonna install an IDE drive in an old XT, might as well go with some of the 1, 2, or 8.4 gigs we all have laying around. Again, this is a personal opinion. Some may want to use a very small 20 or 40 meg drive. In that case, just leave the BIOS ROM alone. Works great the way it is. It's actually pretty fast, even with all the overhead mentioned by hargle.

2) Dunno.
3) Does it hurt to leave the obscure disk functions intact ?

4) I didn't know that direct memory address was available on an XT. I can tell you that the programmed input/output performance on my particular XT is pretty good, but it *is* operating at 10MHz. DMA transfers would be great if available, but if not, no big deal. Just having an IDE card available period would be wonderful.

I have a question that might get me ostracized ( already ) 'cause I don't know if it's possible or not. Would it be possible to add another IDE channel, or IDE CD-ROM support ? I have no idea if an XT could support ATAPI, and the experts could be rolling their collective eyes at this moment, but that would be something interesting. One thing I never got around to, but wanted to, was installing a CD-ROM drive into my XT. I *do* have a NIB Sound Blaster somewhere ( 8bit of course ), and can't remember if it had a proprietary CD-ROM connector on it. I doubt it. That would have been an interesting install. :rolleyes:

At one time, I had an ancient CD-ROM drive that had a switch on it for 8 or 16 bit. Threw it away for some reason years ago. If the proposed IDE controller card was developed ( 8 bit slot with 16 bit capability ) a later CD-ROM drive could be used. I would imagine some type of driver would have to be written, because I doubt that my good 'ol universal CD-ROM driver would work, but again, I don't know.

Looking forward to the lessons I'm sure I'm about to receive. ;)

bobwatts
EartH

hargle
October 16th, 2008, 07:46 AM
here's a disassembly for the option ROM:

Done via IDA, I've commented a good portion of it and named all the subroutines and got it to compile. This will produce a byte for byte match of the original option rom as dumped by bobwatts. (thanks again!)

We'll let this be a baseline source before I go about making any changes or enhancements to the code.

My next step is to break this code apart, optimize it, clean it up more, and then we can start adding features.

--------------
and in answer to your question:

I think CD-ROM support is doable. I'm not really familiar with the interface, but I think a little disassembly of an atapi driver (or a peek at an open source one) would provide me with a lot of insight. Hard drives first though!

per
October 16th, 2008, 08:06 AM
Great :D . I'm looking forward for the final product.

*Edit*
As for I see, there is a third jump vector in the start of the ROM that's not decompilled in your source. It jumps to three bytes before the code after 'rebootMsg'. The instruction that's left as "db ..." at the destination is "BFh 00h 00h", or "MOV DI,0". (problably for some sort of manually entered testing by using some sort of software), but anyway, it is a jump to that code, but I don't know what it is doing.

hargle
October 16th, 2008, 09:24 AM
Great :D . I'm looking forward for the final product.

*Edit*
As for I see, there is a third jump vector in the start of the ROM that's not decompilled in your source. It jumps to three bytes before the code after 'rebootMsg'. The instruction that's left as "db ..." at the destination is "BFh 00h 00h", or "MOV DI,0". (problably for some sort of manually entered testing by using some sort of software), but anyway, it is a jump to that code, but I don't know what it is doing.

you're right-I missed that.

It appears to be a formatting utility.
what's really weird is that it exits with DOS function 31h, which is terminate and stay resident.
Let me update that zip file and you can download it again. I'll also include the IDA files in case anyone wants to play around with it in the disassembler.

Edit: ok, new zip file above with this fixed, and I included IDA workspace and the original option rom that IDA will try to load.
thanks per, and sorry for the other 5 folks who have download it already...

Mike Chambers
October 16th, 2008, 09:34 AM
4) I didn't know that direct memory address was available on an XT. I can tell you that the programmed input/output performance on my particular XT is pretty good, but it *is* operating at 10MHz. DMA transfers would be great if available, but if not, no big deal. Just having an IDE card available period would be wonderful.

yep it has 4 DMA channels. in fact, trixter's 8088 corruption software's speed is thanks to DMA through the sound blaster.

hargle
October 20th, 2008, 11:16 AM
has anyone done anything with identification of the parts on this board yet?

that's a little outta my league, but if no one else steps up to the hardware end of this, I'll do it too.

bobwatts,

is there any chance I buy, borrow, or steal this card from you temporarily?
we need to do some multimetering to get a schematic up, and I was thinking that I could test out my BIOS by disabling the onboard one via jumper and making a DOS driver out of it instead, but I need real hardware to play with. I'll gladly pay for shipping both directions, and promise to to horde it for longer than absolutely necessary.

The new BIOS build is coming along nicely. I've stripped it down to just the vitals we need, removed the ancient HDD precomp stuff, optimized a few of the routines, and broken the 1 .asm file out to a half dozen modules. Still a lot of work to do, but I want to get things in order before I attempt to add any features to it.

kb2syd
October 20th, 2008, 12:13 PM
U1 - can't read
U2 - ROM - based on source code, 8K
U3, U5 - 74ls244 - OCTAL BUFFER/LINE DRIVER. WITH 3-STATE OUTPUTS
U8 - 74LS245 -Octal Bus Transmitter/Receiver
U9, U10 - 74ls343 - OCTAL TRANSPARENT LATCH WITH 3-STATE OUTPUTS
U4,U6 - initial guess, PALs. Figuring out the logic can be pretty time intensive.

hargle
October 20th, 2008, 01:17 PM
Nice!
here's some datasheets:
http://pc.nugnugnug.com/ide/74ls244.pdf
http://pc.nugnugnug.com/ide/74ls243.pdf
http://pc.nugnugnug.com/ide/74ls245.pdf

I couldn't really find much for the 74ls343, but found lots of 243 specs-maybe that was just a typo?

anyway, my layout co-worker says if possible, get all surface mount parts, as through-hole parts are more expensive to manufacturer board-wise. It appears to me that these parts at least are surface mountable (ok, SOIC-I'm learning something new here) so this is a good sign.

The PALs might be tricky indeed. I do have access to a reader/burner though, but I've never worked with them before.

per
October 20th, 2008, 01:20 PM
Nice!
I couldn't really find much for the 74ls343, but found lots of 243 specs-maybe that was just a typo?


it is actually 74ls373.

Datasheet:
http://ece-www.colorado.edu/~mcclurel/sn74ls373rev5.pdf

Druid6900
October 20th, 2008, 07:49 PM
anyway, my layout co-worker says if possible, get all surface mount parts, as through-hole parts are more expensive to manufacturer board-wise.

I'd agree, if this stuff was being manufactured, but, since this is probably going to be a DIY type of thing, unless you have a LOT of years of soldering experience and damn steady hands, SMT components are much more difficult to solder.

I know, I replace large scale SMT devices during some repairs and if you don't have the technique down, chances of getting the device on the VERY closely spaced pads straight AND getting all the legs solder well are slim, at best.

It not a high population board and you can't make the board smaller than the length of the XT connector, so, there is no REAL advantage to SMT over DIP and a LOT of downside. The price different on one-offs is not significant

Terry Yager
October 20th, 2008, 09:30 PM
The price different on one-offs is not significant

MeToo!

--T

hargle
October 21st, 2008, 05:44 AM
I'd agree, if this stuff was being manufactured, but, since this is probably going to be a DIY type of thing, unless you have a LOT of years of soldering experience and damn steady hands, SMT components are much more difficult to solder.


excellent points! DIP packages are also, well, more retro and fit in better with the overall project. ;)

I'm just really happy to see that these parts seem to still be available, at least through a little bit of googling. About 2 years ago, I did an order of some parts via one of those Chinese supply houses. It cost more for the wire transfer than for the parts themselves, but the items were shipped as promised. Overall, the experience was weird, but I'd be willing to go through the whole process again if need be.

Druid6900
October 21st, 2008, 08:23 PM
The parts, even the PALs, are readily available in North America and cheap. I know a couple of places where I can get the identified ones for next to nothing in whatever quantities I want.

The PALs may actually test out to some now-standard chip that wasn't available then, but, I couldn't tell until I dropped them into a chip tester though. PAL chips were used a lot for functions that no chip was available for, at the time, but may have come out later.

The one I'm concerned about is the one that LOOKS like it might have had the number ground off. This was a common practice, at one time, to prevent just what we want to do, and without the original board schematic, the only way to find out what it is would be a chip tester. You COULD spend days working out the Boolean table for it, using a signal injector and a logic probe, or, someone like me could extract the chips, test them, and re-install them so that it would look original (and still work LOL)

bobwatts
October 22nd, 2008, 03:38 AM
Hello Mr. Hargle !



bobwatts,

is there any chance I buy, borrow, or steal this card from you temporarily?
we need to do some multimetering to get a schematic up, and I was thinking that I could test out my BIOS by disabling the onboard one via jumper and making a DOS driver out of it instead, but I need real hardware to play with. I'll gladly pay for shipping both directions, and promise to to horde it for longer than absolutely necessary.

The new BIOS build is coming along nicely. I've stripped it down to just the vitals we need, removed the ancient HDD precomp stuff, optimized a few of the routines, and broken the 1 .asm file out to a half dozen modules. Still a lot of work to do, but I want to get things in order before I attempt to add any features to it.


****************
I have read your request, and am contemplating a response. First of all, in answer to your "wording"......

If I read this correctly, you are asking to buy, borrow, or steal *temporarily* my sIDE 8/16 IDE controller card.

I don't know how they do things in Minnesota, but here in Ohio, people usually permanently steal things. I have to admit that this option should be removed from the list, as it is unacceptable, and *could* hurt my feelings if enacted.

As far as buying the adapter card, this option might be considered, as long as everyone realizes that this particular card is in fact comprised mainly of Unobtanium,and is quite likely one of the rarest things in the Universe. I'm not sure if even the U.S. Government could afford to bail you out on this one, as this particular piece is one of the most treasured items in my entire massive collection of "stuff" here in the BODADC. ( Basement of Doom and Diet Cola. )

So this leaves borrowing. Temporarily. I am seriously considering this option, as long as a few precautions and conditions are observed:

I am (probably) willing to send you the card as long as I am assured that it will be returned to me exactly in the form it will be received in. No magical transformations, no sending me back an 8bit serial card, or a package full of pixie dust. ( I have plenty ). The card is to be handled respectfully, and the inspector should be wearing some of those surgical gloves, preferably white ones. No excessive or painful prodding of the card is allowed, and under no circumstances is the card to be damaged in any way. The card must be returned as fully functional with a smile on it's chips.

As a consideration of my benevolence, should this project reach fruition, and a fully functional 8/16 bit 8 bit ISA card be developed, I bobwatts ( sorry, I spent 4 hours with attorneys yesterday, and it rubbed off. Never go to a deposition as a depositionee unless you absolutely have to. It's not like TV ) will be afforded the opportunity to purchase the above mentioned card at rockbottom prices. Further, some expert somewhere will be considerate enough to assemble the card for me, and I will get subsequent "kits" at reasonable prices. Although I routinely replace bad electrolytic capacitors, MOSFET VR's, etc. on motherboards, I prefer to avoid this if possible. Frankly, I enjoy doing that kind of work, but assuming this project will be made out of the aforementioned Unobtanium, this type of project is best left to the true professionals, not gifted hobbyists.

Lastly, IF POSSIBLE, I would gratefully and humbly accept a "reprogrammed" BIOS ROM chip that * I * would insert into my card upon return. I don't know if you have the capability to program a PROM chip, but I'm betting that you do. :D It would be superneato to see an "improved" version of your reprogramed BIOS in action, and I know that I would be tickled to have an improved BIOS in my possession. The original PROM chip would remain intact, and unmodified, and I would be supplied with the new chip that I will install and test.

I would be delighted to cover shipping to you, and the card will be so carefully packaged that no damage will occur.

Let me know if my *conditions* are acceptable, and I'll have a Brinks Truck transport this rare and priceless artifact to your location.
After I dig the thing back out. Computer was put back into "long term" storage. This means that lots of things were piled in front of it. On the top shelf. :sneaky:

With tongue firmly ensconced in cheek:

Plebe bobwatts
EartH

hargle
October 22nd, 2008, 05:52 AM
wow, that was amazing.
I'll be smiling all day. :)

I'll send you a PM with shipping information and fax you my credit history and SS number.

thank you! I will personally hand assemble, test, and mail board serial #0002 for you when the production run comes into being, and prior to that, I should easily be able to send you an updated BIOS. I'll even put your name in the POST splash screen.

we'd be nowhere without your help on this.

Druid6900
October 22nd, 2008, 10:45 AM
Yeah, I think I can get some of those (used) white gloves from a proctologist friend of mine. :)

Terry Yager
October 22nd, 2008, 11:31 AM
Yeah, I think I can get some of those (used) white gloves from a proctologist friend of mine. :)

Just don't send any of the brown ones.

--T

hargle
October 24th, 2008, 06:17 AM
Just to keep this thread bumpin, I am happy to report that I have roughed in all the required routines to support extended INT 13h. I haven't done any removable media support yet, but as it stands right now, this BIOS should support ATA-3 and higher drives, and allow native support for up to 8.4G of storage, which is all we should ever need on an 8088.

Obviously all this code is in need of debugging and testing and additional organizing, but it really is coming along nicely.


Druid6900, please check your PMs. Bobwatts is ready to mail the card to you for hardware investigation.

Druid6900
October 24th, 2008, 06:13 PM
Druid6900, please check your PMs. Bobwatts is ready to mail the card to you for hardware investigation.

Sorry, nothing in my mailbox from Bobwatts.

One a few days ago from you suggesting it, but, that's it.

hargle
October 26th, 2008, 10:03 AM
Sorry, nothing in my mailbox from Bobwatts.

One a few days ago from you suggesting it, but, that's it.

ok, I just emailed you from here bob's email address and mine.
in short, bob and I think it's best to ship the card to you first, since I still have some work to do that I don't need immediate hardware.

bobwatts
October 26th, 2008, 10:08 AM
We're on it ! :D

Card goes out this week, maybe tomorrow.

bob

Druid6900
October 26th, 2008, 12:38 PM
Ok, now, that's weird.

I go the e-mail notification and message with your e-mails in it, but, there isn't hide nor hair of it in my mail folders on here.

Anyway, the thing that seems to be up in the air is who is doing the design work? I know I started to do the board layout of the card that was mentioned near the beginning of the thread (the ROMless one).

Shortly thereafter, the Acculogic card came up and Hargle mentioned that the designers where he worked were going to do it because they had nothing to do.

Based on that, as far as I know, I'm just going to see if the PALs decode into any known chip and identify any previously unidentified ICs.

If the PALs come up blank, is there anyone here that has the facilities to copy and program the chips? If not, we're pretty much dead in the water on that card.

bobwatts
October 27th, 2008, 03:53 AM
Hi Gang !

I have (once again pulled the 'ol WhiZZbanG XT out of DEEP storage ) pulled the adapter card out this morning, and wanted to clear a few things up.

There has been a lot of mention about a "scraped off" PAL on this card, but it's just a problem with the scan. If you all were referring to the upper right chip, it reads:

GS 9421
GD 74LS00

All of the chips are pefectly legible, so if that's not the one people were referring to, let me know.

Also, and more importantly, there seems to be just a bit of confusion about who is doing what. I would like clarification about if facilities are going to be provided to clone or reverse engineer one of these cards, and who is going to do it.

Thanks !

bobwatts
EartH

per
October 27th, 2008, 05:51 AM
Hi Gang !
There has been a lot of mention about a "scraped off" PAL on this card, but it's just a problem with the scan. If you all were referring to the upper right chip, it reads:

GS 9421
GD 74LS00


I think the two undefined IC's are maybe some kind of 256 Byte ROM or similar (I got one of them on my Ethernet adapter), PAL's as sombody suggested a little earlier, or just some normal TTL IC's covered with stickets.

They problably got a number under the sticket, since they're not appearing with stickets on the box drawing.

The Boot ROM is problably a standard 27(C)64.

hargle
October 27th, 2008, 06:23 AM
hi all, some catching up to do:

Druid, if you're willing to, ID all the parts, do a pinout and a schematic, even if it's on a napkin, and check the availability of the individual parts themselves.
PALs may be difficult. I do have a PAL reader/burner here, but I have never used it before and I don't know if it can handle the work (I suspect that it could, provided I've got all the adapters needed). If you can figure out how the PALs work and perhaps figure out another piece of hardware that does the same job, even better. Do whatever magic you need to do to understand this beast.

We can at this point attempt to figure out some hardware changes. (movable I/O base address, can we support DMA, can we get an eeprom on there instead of a ROM only, etc)


I have 2 co-workers, who are board layout guys, who at this moment are bored layout guys because they've got nothing to work on. I'd need to pull a couple strings, but I don't see it being too difficult to get a schematic and parts list into their hands, and for them to do the trace and route job. I am not sure what software they use for that stuff, nor how to get things into their hands, but I'll snoop around and see what I need to do and get back to you.

From there, I assume we get a gerber file or whatever with the layout ready to go, and we can send that file off to any manufacturing house to get some boards created, then we hand assemble everything and give it a test. I will gladly pay for the initial run of PCBs.

That's a software guy's perspective on the next order of events.

Druid6900
October 27th, 2008, 11:23 AM
hi all, some catching up to do:

Druid, if you're willing to, ID all the parts, do a pin-out and a schematic, even if it's on a napkin, and check the availability of the individual parts themselves.
PALs may be difficult. I do have a PAL reader/burner here, but I have never used it before and I don't know if it can handle the work (I suspect that it could, provided I've got all the adapters needed). If you can figure out how the PALs work and perhaps figure out another piece of hardware that does the same job, even better. Do whatever magic you need to do to understand this beast.

We can at this point attempt to figure out some hardware changes. (movable I/O base address, can we support DMA, can we get an eeprom on there instead of a ROM only, etc)


I have 2 co-workers, who are board layout guys, who at this moment are bored layout guys because they've got nothing to work on. I'd need to pull a couple strings, but I don't see it being too difficult to get a schematic and parts list into their hands, and for them to do the trace and route job. I am not sure what software they use for that stuff, nor how to get things into their hands, but I'll snoop around and see what I need to do and get back to you.

From there, I assume we get a gerber file or whatever with the layout ready to go, and we can send that file off to any manufacturing house to get some boards created, then we hand assemble everything and give it a test. I will gladly pay for the initial run of PCBs.

That's a software guy's perspective on the next order of events.

OK, I have no problem doing a RevEng on the board, but, there are a few deal busters here;

- If the PALs don't read to anything then they have to be read/duplicated. If not, there is no way the board will work. Period. If they DO read as an available chip then we're good.

- Working out the boolean table from a PAL would be horrendously time-consuming and may require half a dozen chips or an EPROM to emulate. We'd probably be done faster building from scratch. It might be best, if they don't cross to anything usable, to have you ship the reader/burner to me to figure out as I'll have the chips off the board anyway. Even if there is a way to dump the PALs in the same manner as a ROM (which I doubt), we'd still need to burn new ones.

There is no sense having me do the schematic and your guys to the board layout (or vice versa) as, with most modern commercial software, it's two clicks from the schematic to the board layout. If they have nothing to do, it may be best for them to do both as I have LOTS to do.

Just my thoughts on the most expedient way to handle the project.

hargle
October 27th, 2008, 11:48 AM
- Working out the boolean table from a PAL would be horrendously time-consuming and may require half a dozen chips or an EPROM to emulate. We'd probably be done faster building from scratch. It might be best, if they don't cross to anything usable, to have you ship the reader/burner to me to figure out as I'll have the chips off the board anyway. Even if there is a way to dump the PALs in the same manner as a ROM (which I doubt), we'd still need to burn new ones.


ok, we'll cross the PAL bridge when we get to it I guess, and see if there are workarounds if required. I always thought that PALs were at least readable like a ROM and copyable. that's a bummer.


There is no sense having me do the schematic and your guys to the board layout (or vice versa) as, with most modern commercial software, it's two clicks from the schematic to the board layout.


That's cool! I didn't know that was so simple nowadays. Maybe we don't need them then.

I figured 1/2 of the work is going to be IDing the parts and multimetering the pins to find out where they go to each other and duplicating that in some schematic software. Then the other 1/2 was coming up with the correct dimensions of the PCB, laying out the parts, creating the whole ISA slot tooth points, etc. I can have my guys do that 2nd half, but not the 1st.

You do whatever you can, I'll continue carrying the torch when you've had enough of it. If that requires me to take a crash course in board tools, so be it. When you've done everything you can with the card itself, send it my way and I'll at a minimum get the BIOS up to date.

Druid6900
October 27th, 2008, 12:05 PM
ok, we'll cross the PAL bridge when we get to it I guess, and see if there are workarounds if required. I always thought that PALs were at least readable like a ROM and copyable. that's a bummer.


That's cool! I didn't know that was so simple nowadays. Maybe we don't need them then.

I figured 1/2 of the work is going to be IDing the parts and multimetering the pins to find out where they go to each other and duplicating that in some schematic software. Then the other 1/2 was coming up with the correct dimensions of the PCB, laying out the parts, creating the whole ISA slot tooth points, etc. I can have my guys do that 2nd half, but not the 1st.

You do whatever you can, I'll continue carrying the torch when you've had enough of it. If that requires me to take a crash course in board tools, so be it. When you've done everything you can with the card itself, send it my way and I'll at a minimum get the BIOS up to date.

Ok, let me see if I can clarify this.

PALs are readable and copiable, if you have a reader/burner, which I don't.

I have a chip tester that compares the tables of most known chips (TTL, CMOS and DIP RAM), stored in an on-board ROM, against the chip that is inserted into the ZIF socket.

If one of the tables matches what a given chip is set up for, it will display the chip number (and any others that can be substituted for that chip) and allow me to dynamically test it.

If it doesn't find a match, then there is no known chip in its ROM that identifies the target chip.

In that case, we would need your reader/burner to produce the configuration on whatever chip blank they are using.

So, IF the chip doesn't resolve to any known "standard" IC, then either I send you the two PALs and you learn to work the reader/burner, or you send ME the reader/burner and I read the chips to a file.

Then I send you the card with the chips re-installed, the reader/burner and the file (and instructions on how to burn the required PALs).

Gee, thanks. Part two is the EASY part LOL

Fine, I'll do everything except the ROM, but, I want this sucker to be called the "Druid6900 8/16-bit IDE Controller. Mk I" :)

hargle
October 27th, 2008, 02:02 PM
thanks for the clarification. that actually makes me happier-in that just copying a PAL is way better than having to program our own and/or reverse engineering it.

I'm assuming one of the PALs on that board is the thing that decodes the I/O commands off the ISA bus at a specified address. In the BIOS, I see these I/O addresses as being 360-367, 368, and 36E. 360-367 is standard the standard IDE controller register block, 368 is the upper 8 bits of the data, and 36E appears to be some reset. (it gets toggled high and low, but never very often)

Id' think that PAL is most certainly not going to be something that has been reproduced in an IC, so that's the one we'll end up having to copy. That's totally fine with me, provided my burner works and I can get blanks. I'll dig up the model number on the thing, and see where the software is.



Gee, thanks. Part two is the EASY part LOL
Fine, I'll do everything except the ROM, but, I want this sucker to be called the "Druid6900 8/16-bit IDE Controller. Mk I"

well, if you're doing the PCB silkscreen, you can make it say whatever you want!
and since I'm doing the BIOS, I get to make the boot screen say whatever I want, and you'll be looking at the boot screen more often than the silkscreen. :p
----------
edit later:

I have both a BPMicro Bp-1200 and PLD-1128 burners, along with an array of heads/sockets that fit onto the reader itself. If you can send me the part numbers for the PALs themselves, I can look 'em up in the software to make sure the reader can talk to the parts. I don't suspect this will be a problem at all though.

Druid6900
October 27th, 2008, 08:51 PM
The more I think of this, the more fun I think it's going to be (not).

In board design, one calls up a pin-out of the chip to see which pin a signal applied to pin X of the chip comes out. It makes it pretty simple, however, with a PAL, because it's custom programmed, there IS no diagram of the thing.

Never having had to do it before, it should be a challenging (and time-consuming) operation.

However, as I have mentioned, if your readers/burners can't handle the chip (which I'll heat the labels off of and let you know the series) using this board design will come to an abrupt end. I'll get you the series numbers before doing anything else.

hargle
October 28th, 2008, 05:52 AM
However, as I have mentioned, if your readers/burners can't handle the chip (which I'll heat the labels off of and let you know the series) using this board design will come to an abrupt end. I'll get you the series numbers before doing anything else.


excellent, good first step. I feel pretty good that my programmer can handle them; the card and my programmer are of a similar vintage, and the software has support for thousands of different parts. I have been told I have chronic optimism though.

if the PAL thing does come to a dead end, perhaps we could do something through this route?

http://www.pjrc.com/tech/8051/ide/index.html

(using a low power/cost cpu instead of a PAL)

i dunno-this hardware stuff is voodoo to me.

bobwatts
October 29th, 2008, 02:37 PM
Hi Gang !

There is a slight delay in shipping the card, and when I hear back from Richard it should be taken care of.

I was wondering today ( and keep in mind this is not my area of expertise ) if it wouldn't be possible to make a new "up to date" card of similar abilities.

What I mean by this, is for example the difference in a 286 motherboard with support chips all over it, and a newer P4 board with basically most or all functions consolidated into just a couple of chips ( chipsets).

Although I have no (idea what I am typing about ) idea what all the chips on the Acculogic sIDE 8/16 controller card does, wouldn't it seem logical that in the years since that card was created that there is probably a better way to do what it does, with less chips ?

Just a thought....

bobwatts
EartH

hargle
October 30th, 2008, 06:35 AM
As I see it, the largest hurdle we're trying to overcome is the fact that the bus itself is 8 bit, yet the interface to and from the HDD is 16 bit. That means we have to buffer that 1/2 data and store it until the CPU is ready for it.

The problem with moving to newer hardware is that it all assumes that we've got a 16 or 32bit bus already at our disposal, and since we don't we get into timing and buffering problems and all kinds of icky from there.

It's quite likely that we're going to be so smart about IDE after doing this that another round of cards might be on the menu with different hardware. I dunno.

I personally would like to see more cards made-I want to make one that works in a PCjr, and I would love to make a card that has a built in compact flash support. We need to add cheap, big storage to *everything* :)

bobwatts
October 30th, 2008, 02:18 PM
As I see it, the largest hurdle we're trying to overcome is the fact that the bus itself is 8 bit, yet the interface to and from the HDD is 16 bit. That means we have to buffer that 1/2 data and store it until the CPU is ready for it.

The problem with moving to newer hardware is that it all assumes that we've got a 16 or 32bit bus already at our disposal, and since we don't we get into timing and buffering problems and all kinds of icky from there.

It's quite likely that we're going to be so smart about IDE after doing this that another round of cards might be on the menu with different hardware. I dunno.

I personally would like to see more cards made-I want to make one that works in a PCjr, and I would love to make a card that has a built in compact flash support. We need to add cheap, big storage to *everything* :)


OK, understood. Frankly, just having 16 bit IDE support ( and I think you mentioned you broke the 528M limitation, up to 8.4G ?) would be fantastic in a readily available card (and *possibly* ATAPI CD-ROM support) would be neato. :D

The card was mailed out this morning. (Was a ridiculous $24.50 for some reason. ) Sent via USPS. Richard should be getting it soon.

bobwatts
EartH

Druid6900
October 30th, 2008, 08:14 PM
OK, understood. Frankly, just having 16 bit IDE support ( and I think you mentioned you broke the 528M limitation, up to 8.4G ?) would be fantastic in a readily available card (and *possibly* ATAPI CD-ROM support) would be neato. :D

The card was mailed out this morning. (Was a ridiculous $24.50 for some reason. ) Sent via USPS. Richard should be getting it soon.

bobwatts
EartH

How did you send it? Cruise missile? :)

Probably all the insurance.

While it's on it's way, I'm going to try an experiment on some boards to see if, by using a chip-clip wired to a ribbon cable socket, I can test chips on an unpowered board with my chip tester. If so, I won't have to take the PALs off the board at all.

If it works, I can send the cable along with the board to Jeff and he could read them in circuit too.

bobwatts
October 31st, 2008, 12:52 AM
Hi Richard !


How did you send it? Cruise missile? :)

Probably all the insurance.

While it's on it's way, I'm going to try an experiment on some boards to see if, by using a chip-clip wired to a ribbon cable socket, I can test chips on an unpowered board with my chip tester. If so, I won't have to take the PALs off the board at all.

If it works, I can send the cable along with the board to Jeff and he could read them in circuit too.

Cruise missile !? You know what it costs just to fuel one of those things? Besides, they are nowhere NEAR as accurate as those few lucky shot videos you see on the Cartoon Network. Nope, they are still mad at me at the Post Office over that last incident, and are just trying to recoup some of the cost of the rebuild. :twisted:

Richard you do what you have to do, I'm done whining and fretting over it. ;) I'm sure the card is in good hands.

If I ever run across that POS Juko card I bought new many years ago, I'll donate that to someone. I'm pretty sure I threw it away though, 'cause I never got it to work, and (following the directions) that was the ONLY time I ever blew something computer related up. :cool:

Well, there was that other thing.......

Keep us posted !

bobwatts
EartH

Jorg
October 31st, 2008, 01:57 AM
I'm getting really getting excited seeing this might go for real...

I'd certainly be in for buying one or more. I wish I could help, but my hardware development capabilities, they are zero...

But I'll keep reading, its fascinating..

JT64
October 31st, 2008, 05:31 AM
But didn't the old SB AWE32 and 16 have an ATA/IDE interface?
What pins did the data transfer over the last 8?

No possible way to make driver work on 8-bit bus?

JT

Jorg
October 31st, 2008, 06:14 AM
As far as I know the sound card interfaces only supported CD-Roms.

per
October 31st, 2008, 06:15 AM
But didn't the old SB AWE32 and 16 have an ATA/IDE interface?
What pins did the data transfer over the last 8?

No possible way to make driver work on 8-bit bus?

JT

Their ATAPI (E-IDE) interface used the upper 8 bits of the 16-bit bus. In fact, the whole card uses the upper 8 bit too, so it won't work (remember that the bus on the PC/XT is only the first 8 bits and controll lines).

JT64
October 31st, 2008, 08:10 AM
Hello Per i know very little about hardware, but since people here actually talking about building a hardware controller interface from scratch with drivers, i allow myself dream a little bit.

Would it not be possible to build an ISA interface connector to remap the DATA over bus so the upper 8-bit are the actual active bits.

This is probably an oversimplyfication on my part, i guess the Adress connectors is used to reach the hardware in specific manner.

And of course you would have to program drivers that support the way to access the card.
All this would of course be futile if 16 data channels is used in parallell over the IDE interface.

JT

JT64
October 31st, 2008, 11:47 AM
As far as I know the sound card interfaces only supported CD-Roms.

I beleive the IDE/ATA is full in hardware but drivers only supported CD rom.

JT

Druid6900
October 31st, 2008, 08:05 PM
Hi Richard !

Cruise missile !? You know what it costs just to fuel one of those things? Besides, they are nowhere NEAR as accurate as those few lucky shot videos you see on the Cartoon Network. Nope, they are still mad at me at the Post Office over that last incident, and are just trying to recoup some of the cost of the rebuild. :twisted:

Richard you do what you have to do, I'm done whining and fretting over it. ;) I'm sure the card is in good hands.

bobwatts
EartH

I just shipped a Quantum 3.2 GB HD to PA today and, even with $100 insurance, it cost me the equivalent of about 11.50 US, so, they must be mad at you for something, Bob.

Although I'm just an ol' country electronics brain surgeon, I'll treat it like it was my very own card and....oops, just dropped a hard drive...and you can rest assured that it will be....who the hell put that damn computer so close to the edge of the workbench, now I'll have to pound the dents out after I sweep up the CRT from that guy's system...safe and sound in my capable hands... Hey, more Southern Comfort over here, wench!

Druid6900
October 31st, 2008, 08:08 PM
I beleive the IDE/ATA is full in hardware but drivers only supported CD rom.

JT

I think you'd only get PIO response out of a HD on a sound card's IDE connector, but, if you have a lot of time on your hands....

bobwatts
November 1st, 2008, 03:22 AM
Hi Richard !


I just shipped a Quantum 3.2 GB HD to PA today and, even with $100 insurance, it cost me the equivalent of about 11.50 US, so, they must be mad at you for something, Bob.

Although I'm just an ol' country electronics brain surgeon, I'll treat it like it was my very own card and....oops, just dropped a hard drive...and you can rest assured that it will be....who the hell put that damn computer so close to the edge of the workbench, now I'll have to pound the dents out after I sweep up the CRT from that guy's system...safe and sound in my capable hands... Hey, more Southern Comfort over here, wench!

Although I can't reveal the specifics of the "incident", you would have thought they would have been a little more understanding concerning my attempts to actually create a Flux Capacitor. Heck, I even used the correct radiation symbols ! :p

"Dammit Jim, I'm a surgeon, not a bricklayer ! "

You got wenches in your Lab serving up Southern Comfort !!??
All I have is four cats in the BODADC. Not one of them is worth a damn with a soldering iron. Although DooM is becoming proficient in the use of:
FORMAT C:/S :twisted:

( I may go through my "box" this weekend. Might be some more stuff in there of interest. I have typed this before in other places: Don't we all wish we had saved that, in my case anyway, around four pick-up truck loads of stuff we have let go over the years. I once piled more MFM and RLL drives out at the curb than I could lift in one trip. :( )

bobwatts
EartH

Druid6900
November 1st, 2008, 11:03 AM
Hell, I never throw anything out unless it is so screwed that I can't fix it (ROTF, that's a good one, but, may happen SOME day).

Ok, occasionally, something isn't worth fixing and it gets added to the small pile then shoved in the discarded cases for pickup and scrap recycle.

Cats are nice, I have a small herd of them, but wenches are good for serving the Elixer Of Life and sorting out cards into boxes wearing their French Maid outfits. Nah, I'll just leave that as it is and let you figure out the connection.

Terry Yager
November 1st, 2008, 11:58 AM
I too have been known to do my computer work at the local pub, where the serving wenches are as slippery as catsh!t on a dooorknob (lucky for them), but...what's yer point???

--T

Terry Yager
November 1st, 2008, 12:05 PM
bob,

Be sure to stamp (in huge red letters) BOMB PARTS on the package, or it'll be held up in Canadian Customs for five weeks (again) while they try to figger out what the hell it is.

--T

bobwatts
November 1st, 2008, 12:21 PM
bob,

Be sure to stamp (in huge red letters) BOMB PARTS on the package, or it'll be held up in Canadian Customs for five weeks (again) while they try to figger out what the hell it is.

--T


OK, that one got a huge laugh. Sometimes my fertile imagination immediatly tries to picture "stuff", and I had a glimpse of just what would actually happen with "BOMB PARTS" in HUGE red letters on a package.

Too late to do it actually, package is winging it's way as I type. I gotta try that on the next one!

( To anyone offended, I realize the world is a little different today, but damn, you have to lighten up sometime. :twisted: )

Frankly, they know me WELL at the PO. I have shipped probably 500+ carburetors, computer thingies, and other "stuff". They are very particular about any "fumey" smell, and have no compunctions about making me repackage stuff. And rightly so.

Bomb parts. :mrgreen:

bobwatts
EartH

Terry Yager
November 1st, 2008, 12:43 PM
Actually, the local PO rejected a package from me a few days ago because the dumpster-rescued box had the word 'opium' on it (in.re. the fragrance, not the drug). And, I'm not kidding about Canadian customs, it was about 5 weeks, wasn't it, D?

I realize it's a different world, but do they really need to carry this (false) security thing to the absurd...?

--T

bobwatts
November 1st, 2008, 12:54 PM
Actually, the local PO rejected a package from me a few days ago because the dumpster-rescued box had the word 'opium' on it (in.re. the fragrance, not the drug). And, I'm not kidding about Canadian customs, it was about 5 weeks, wasn't it, D?

I realize it's a different world, but do they really need to carry this (false) security thing to the absurd...?

--T

Yes, been there. I once tried sending a box that was originally full of really dangerous chemicals. Brake cleaner I think. Terrible stuff. Wars have been fought over it. Box didn't have Brake Cleaner in it, probably some innocent little computer part. But they called S.W.A.T. of course. Showed 'em my badge, and secret handshake.

Had to leave, take it back to the BODADC, and cover the offending words. Matter of fact, I actually did this for the sIDE card I just mailed, but I used one of those Magic Marker thingies to cover up the Magic Words. I guess that's why it's called Magic Marker.

bobwatts
EartH

Terry Yager
November 1st, 2008, 01:05 PM
Oh yeah, and if ya ever hafta ship a laptop, never, ever tell them that there's a battery in there. They made me re-package one once, and send the battery separately.

--T

Ec1564
November 1st, 2008, 05:06 PM
While looking for some CoCo2 programs and emualtors I found this site:
http
h??p://bitchin100.com/files/hardware/


There is a 3.4M zip file called: 8bit_ide.zip
Its a pdf file when unzipped but it has alot of info and schematics of a 8 bit ide controller.

Hope this is what you are all looking for.

Eddie

Druid6900
November 1st, 2008, 07:54 PM
And, I'm not kidding about Canadian customs, it was about 5 weeks, wasn't it, D?

--T

Nope, 72 hours maximum if they even bother to look at it.

I think that five weeks figure was how long it took you to pack the last stuff you shipped to me LOL

If you REALLY want to get something into Canada quickly and not have it touched, stamp "Counterfeit Canadian Passports" on the box :)

Terry Yager
November 1st, 2008, 08:14 PM
Hey, I've been to Canadia, and 72 hours is about five weeks up there...

--T

hargle
November 4th, 2008, 09:44 AM
While looking for some CoCo2 programs and emualtors I found this site:
http
h??p://bitchin100.com/files/hardware/

There is a 3.4M zip file called: 8bit_ide.zip
Its a pdf file when unzipped but it has alot of info and schematics of a 8 bit ide controller.

Hope this is what you are all looking for.

Eddie

whoa. that really looks interesting. I haven't read through everything just yet, but I did see that the article talks about 2 ways of dealing with the 16/8bit data issue, and that one way (the way the acculogic card works) is to map the other 8bits to a different I/O port. This breaks DMA access, which has been one of my fears about this project.

The other way is to map the 16bit data onto 2 consecutive reads of the same I/O address, which is what this article is all about it seems. AND it includes source code for the GAL/PAL that gets used! Top notch.

So, if we could take this project, and somehow get an option rom decoded in there, we would be set.

Before I get too excited about this new information, I'll let druid weigh in.
95% of the source code I've got right now would still be usable with this new design, so I'm happy. ;)

MikeS
November 4th, 2008, 09:48 AM
Hey, I've been to Canadia, and 72 hours is about five weeks up there...
--T
--------
Well, yeah, duh! We use metric hours up here, dontcha know?

m

Terry Yager
November 4th, 2008, 02:26 PM
--------
Well, yeah, duh! We use metric hours up here, dontcha know?

m

Some places up there are so boring that you can even contract a disease from being there too long, like Winnepegosis, right Lawrence?

--T

Druid6900
November 4th, 2008, 07:32 PM
whoa. that really looks interesting. I haven't read through everything just yet, but I did see that the article talks about 2 ways of dealing with the 16/8bit data issue, and that one way (the way the acculogic card works) is to map the other 8bits to a different I/O port. This breaks DMA access, which has been one of my fears about this project.

The other way is to map the 16bit data onto 2 consecutive reads of the same I/O address, which is what this article is all about it seems. AND it includes source code for the GAL/PAL that gets used! Top notch.

So, if we could take this project, and somehow get an option rom decoded in there, we would be set.

Before I get too excited about this new information, I'll let druid weigh in.
95% of the source code I've got right now would still be usable with this new design, so I'm happy. ;)

I took a quick look at it, but didn't get too into it just yet, but, I will.

Druid6900
November 9th, 2008, 06:03 PM
Keep forgetting to mention the card arrived Friday, but, I was out walking the dog, so, I picked it up Saturday.

No wonder it cost over 24 bucks, you could have shipped a truck battery in the box and there was enough packing to ship an egg to Jupiter and have it made a soft landing on the (hypothetical) surface :)

I'll start my work in a couple of days and report back.

Druid6900
November 11th, 2008, 06:59 PM
OK, I'm going to start working on the board design soon, so, I want to know if we are going to clone the Acculogic card or modify the one from here http://bitchin100.com/files/hardware/

Cloning the card will, as mentioned before, require reading and duplicating two PLA chips, but the ROM is already worked into the design.

Building from the article gives us the code for the GLA, but, someone is going to have to figure out how to interface the ROM and jumpers on to the board. Converting this from an ECB to a standard 8-bit bus shouldn't be too difficult, while getting rid of the LEDs, parallel port and switches.

However, on page 29 of the PDF, right side column, second paragraph from the bottom, last sentence in the paragraph has me a bit confused.

So, what are we going to do?

hargle
November 12th, 2008, 05:35 AM
I think i'm leaning toward the tilmann reh design, for these reasons:

1) it maps the additional 8bits of data to a second read of the same data port, so we could use DMA for the transfers. (I think-the example code he provides still use PIO, so that's a little fuzzy)

2) it's newer, and the author (tilmann) of that article is still out there, and could provide us with assistance if we asked. I'd be happy to get ahold of him, perhaps I should just to thank him for his article.

3) code for the GAL is provided.
--------
As for adding an eeprom, I think (ok, i hope!) that stealing that portion of the design from the acculogic card might not be that bad, and the jumpers are a part of that subsystem. I'd think that I could pin out that section for you using any other ISA board with an option ROM, like my 8bit SCSI card, since it would use the same size eeprom, and has all the same address selection jumpers. Is one of the PALs on that acculogic card is for the eeprom address decoding? that could get ugly, but again, I do have similar hardware here that I could start playing with immediately, like seeing if I can read it using my burner.
---------

page 29, 2nd paragraph from the bottom, last line says:

"The connector is a 40pin header, not to be confused with the XT-type IDE interface connector, which is also a 40pin header, but needs somewhat different hardware and totally different software!"

My interpretation of that is that is comparing 16bit IDE drives to really old 8bit XT drives and cabling, perhaps in reference to the /IO16 line (pin32), which obviously would not exist on an XT based drive/cable/interface.

All the more reason I should contact tilmann and get some direct answers.

Edit later: Tilmann Reh has been contacted and made aware of our project. Hopefully he's interested in lending a hand!

Trixter
November 12th, 2008, 02:39 PM
1) it maps the additional 8bits of data to a second read of the same data port, so we could use DMA for the transfers. (I think-the example code he provides still use PIO, so that's a little fuzzy)


This is KEY to achieving speed. If DMA can do all of the port-to-mem transfers in a single burst then you'll be able to exceed 300KB/s on an XT.

Druid6900
November 12th, 2008, 08:19 PM
I think i'm leaning toward the tilmann reh design, for these reasons:

1) it maps the additional 8bits of data to a second read of the same data port, so we could use DMA for the transfers. (I think-the example code he provides still use PIO, so that's a little fuzzy)

2) it's newer, and the author (tilmann) of that article is still out there, and could provide us with assistance if we asked. I'd be happy to get ahold of him, perhaps I should just to thank him for his article.

3) code for the GAL is provided.

I agree that, provided that we can get rid of the extraneous crap and mount the PROM and jumpers, this would be the way to go.


--------
As for adding an eeprom, I think (ok, i hope!) that stealing that portion of the design from the acculogic card might not be that bad, and the jumpers are a part of that subsystem. I'd think that I could pin out that section for you using any other ISA board with an option ROM, like my 8bit SCSI card, since it would use the same size eeprom, and has all the same address selection jumpers. Is one of the PALs on that acculogic card is for the eeprom address decoding? that could get ugly, but again, I do have similar hardware here that I could start playing with immediately, like seeing if I can read it using my burner.
---------
Ok, that works for me and, seeing as we have a schematic, adding the new circuitry would be pretty easy.

As for the Acculogic, I can't say for sure, but, I'm willing to bet it is. I haven't actually done anything with the card until we decide on this.


page 29, 2nd paragraph from the bottom, last line says:

"The connector is a 40pin header, not to be confused with the XT-type IDE interface connector, which is also a 40pin header, but needs somewhat different hardware and totally different software!"

My interpretation of that is that is comparing 16bit IDE drives to really old 8bit XT drives and cabling, perhaps in reference to the /IO16 line (pin32), which obviously would not exist on an XT based drive/cable/interface.

Yes, I was working on that assumption as well, but wanted to see if others were reading it the same way I was, so, it's a non-issue

hargle
November 13th, 2008, 05:52 AM
ok, this weekend I'll pinout my future domain SCSI controller and see if I can figure out where all the pins from the ROM are heading through the jumpers. Having never created a schematic before, expect it to be fairly ugly, but well documented. ;) If the lines end up going to a PAL, I'll pull it off and see if I can read it. I doubt I have any spare PALs here to try and program though, but if my burner can read it, there's no reason it can't write it.

Is there any software I should use to do schematic layouts that you can import into your project, or should I just ascii it up or scan it off paper?

Once that's done, i do want to upgrade the ROM to an EEPROM, so the card can upgrade it's BIOS through a software update. I'll assume (perhaps incorrectly) that the differences should be minor, aside from pulling in additional power to be used during the erase cycle. (we can jumper that) I've written flash upgrade programs before, so the software side of an update tool isn't too complex for me, and I do have schematics available from PC motherboards my group has designed that I can work from too, so i'll keep my spirits up that we can make that work.

per
November 13th, 2008, 06:36 AM
I'll assume (perhaps incorrectly) that the differences should be minor, aside from pulling in additional power to be used during the erase cycle.

You're partly right there. The only difference from a EPROM to a EEPROM is that A14 is moved to pin 1 and pin 27 replaced with the "write enable" (active low) line.

The IBM PC/XT BIOS ROM socets has support for both EPROMs and write-protected EEPROMs because A14 was connected to both pin 1 and pin 27.

Chuck(G)
November 13th, 2008, 10:36 AM
I have a couple of questions, strictly out of curiosity.

Why are the PC-AT port addresses being used on a PC-XT? Given that the operation of the controller isn't compatible with PC-AT driver software, what's the point? Why not use the PC-XT addresses?

One of the problems in trying to use 286 code on an 8088-based machine is the use of the 286 INS and OUTS block transfer instructions. You could replace the 8088 with a V20, but that just adds an extra layer of confusion. And you don't have IRQ 14 and 15 anyway on an XT.

If you want to use DMA, you need circuitry on the adapter to handle it. I don't see that on the Reh design.

If running in PIO mode and using the PC AT port addresses is desirable, why not a simple state machine that would allow an access to the (data port +1) address after an access to (data port) using the 8088 IN/OUT word instructions? It seems to me that you'd get the best programmed-I/O transfer speed.

Just tossing a couple of thoughts out there to be shot down...

hargle
November 13th, 2008, 11:52 AM
I have a couple of questions, strictly out of curiosity.
Why are the PC-AT port addresses being used on a PC-XT? Given that the operation of the controller isn't compatible with PC-AT driver software, what's the point? Why not use the PC-XT addresses?

I guess I don't see why it matters what I/O range we're using? I wasn't aware that we had made that decision yet?

As long as it's dropped into a range that doesn't conflict with other devices that are commonly used in a PC/XT, we should be fine. If 1F0-1F7 and/or 170-17f used by other stuff, then by all means it should be moved.

Having it jumper selectable from 4 or more address ranges is of course the ideal solution.

I think there are plenty of ranges of I/O that should be available.
Not having it on top of the existing XT HDD port addresses would allow for MFM drives to be used at the same time as our card, for the truly insane.




One of the problems in trying to use 286 code on an 8088-based machine is the use of the 286 INS and OUTS block transfer instructions. You could replace the 8088 with a V20, but that just adds an extra layer of confusion. And you don't have IRQ 14 and 15 anyway on an XT.

we're not using any 286+ instructions. The original dump of the BIOS used only 8088 code, and I've only augmented that to support larger hard drives. (and fixed a lot of stupid stuff) The end result BIOS will likely be 95% written by me from scratch, and i've so far only done PIO based transfers using single byte reads, because the code came from the acculogic card and they did weird stuff to get the 2nd half of the data. If we change the design, I have to change the core reader/writers, but that's fairly minor.

Since it's all PIO at the moment, there's no IRQ usage.
If the design changes to support DMA, then that'll change, but there's no reason we need IRQ 14 or 15 to work.



If you want to use DMA, you need circuitry on the adapter to handle it. I don't see that on the Reh design.

I'll defer that one to a hardware guy, as I have no idea what hardware would be required there. The reh article does mention that the way his design works (512, 8bit reads from the same data port) is ideal for DMA transfers, so I assumed all the stuff required was in the design already. If you can help with that hardware design, please do.



If running in PIO mode and using the PC AT port addresses is desirable, why not a simple state machine that would allow an access to the (data port +1) address after an access to (data port) using the 8088 IN/OUT word instructions? It seems to me that you'd get the best programmed-I/O transfer speed.

Agreed, that would be better, if we're still forced to do PIO, and nobody accidentally touches the data port register and gets us into a weird state!
I wonder how much of a boost that would be?

Chuck(G)
November 13th, 2008, 01:24 PM
I guess I don't see why it matters what I/O range we're using? I wasn't aware that we had made that decision yet?

As long as it's dropped into a range that doesn't conflict with other devices that are commonly used in a PC/XT, we should be fine. If 1F0-1F7 and/or 170-17f used by other stuff, then by all means it should be moved.

Having it jumper selectable from 4 or more address ranges is of course the ideal solution.

I think there are plenty of ranges of I/O that should be available.
Not having it on top of the existing XT HDD port addresses would allow for MFM drives to be used at the same time as our card, for the truly insane.

Yeah, I guess I could see that. But might it be better to use some non-AT-HD I/O port range to avoid getting a false positive ID from a piece of software that probes for a HDC?


The reh article does mention that the way his design works (512, 8bit reads from the same data port) is ideal for DMA transfers, so I assumed all the stuff required was in the design already. If you can help with that hardware design, please do.

You need handshaking with the appropriate DRQ/DACK signal pair. A look at the PC XT HDC schematics would be instructive.


Agreed, that would be better, if we're still forced to do PIO, and nobody accidentally touches the data port register and gets us into a weird state!
I wonder how much of a boost that would be?

Well figure this:



in al,dx
mov ah,al
in al,dx
stosw


versus:



in ax,dx
stosw


So there are a few cycles saved there. And, on a V20, it's simply:



insw

Ec1564
November 15th, 2008, 04:50 PM
I found this web site with more info on 8 bit IDE controllers.

http://www.mylinuxisp.com/~jdbaker/oldsite/SmallSys/8bitIDE.html

Druid6900
November 15th, 2008, 06:54 PM
I found this web site with more info on 8 bit IDE controllers.

http://www.mylinuxisp.com/~jdbaker/oldsite/SmallSys/8bitIDE.html

Yeah, that's the same one as near the beginning of this thread and I had already started doing the board layout when we switched to another design, and then another one.

Someday, we'll finalize on a design and I'll actually build it.

NobodyIsHere
November 16th, 2008, 06:06 AM
Hi Richard!

I have been lurking on this thread for some time but a bit hesitant to add anything because I am currently swamped with the N8VEM project. Ironically, my current task is making an ECB Disk IO board which contains IDE and FDC interfaces. I can "feel your pain" as adding an interface seems so simple at the outset but quickly gets very complicated.

May I make a suggestion though? I have found to make a project "real" it has to be very simple so that the circuit is "buildable." With that in mind, maybe the approach this project should refocus to simplify the objective. Early in this thread, Hargle suggested this approach:

http://www.mylinuxisp.com/~jdbaker/oldsite/sourcecode/xtide.c

Given this circuit has already been designed and software exists for it, I think this may be your best approach. I understand it does NOT contain the boot ROM and probably doesn't have all the bells and whistles some of the other designs have. However, if you look at the circuit schematic closely you'll notice the entire design is implemented in bog standard 74LSxxx TTL chips and a prototype could be relatively easily implemented on an 8 bit ISA prototype board.

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=21532&

Once that existed and the circuit and software verified to work properly, I believe the design could be extended to include a boot EPROM socket.

The bottom line is I recommend building a working prototype and extending it before you commit anything to a PCB manufacturing run. Frankly, I would love to do it myself but I do not see any opportunity to do so due to previous commitments on the N8VEM project.

Thanks and have a nice day!

Andrew Lynch

Druid6900
November 16th, 2008, 12:28 PM
Andrew,

We all appreciate your input since you've "built from scratch" for your project.

I'm just, basically, waiting to see what happens.

Of course, whatever design we choose is going to have bread-boarded, at some point and that protoboard seems like it would make it very easy.

However, if we go with the latest design, and someone works in the ROM and jumpers, then Hargle's people could do the schematic to board work as they have nothing to do.

As I mentioned before, I have LOTS to do and just offered because no one else was.

Terry Yager
November 16th, 2008, 12:53 PM
Prob'ly better this way. If you two geniuses ever pooled your brainpower, all the rest of our heads would surely explode.

--T

hargle
November 16th, 2008, 03:13 PM
i too agree with andrew that building up one or two protoboards is the way to go before we mass produce anything. it just makes sense. I had no idea that ISA slot edge prototype boards still existed in the market...

Software wise, all of the designs we're playing with are all pretty similar, so only the really low-level reader/writers need to change if we switch to DMA in the future, and it's pretty minor to jump to option ROM in the future too, so I suggest stages of design are ideal.

I'd love to have either the reh or linux design in a protoboard right now-I could probably finish off and debug the software in a solid weekend.

anyone want to build me one? :) I'd even buy all the parts if you put it together.

hargle
November 16th, 2008, 04:31 PM
here's some preliminary work on the option rom hookup, as pinned out from my TMC-850 card, hopefully this is somewhat useful.

This rom is an intel d27128-4



+--\/--+
ISA B29 (+5v)<-vpp-| |-vcc->ISA B29 (+5v)
ISA a19 (address bit12)<-a12-| |-pgm->ISA B29 (+5v)
ISA a24 (address bit 7)<--a7-| |-a13->? no connect?
ISA a25 (address bit 6)<--a6-| |-a8-->ISA a23 (address bit 8)
ISA a26 (address bit 5)<--a5-| |-a9-->ISA a24 (address bit 7)
ISA a27 (address bit 4)<--a4-| |-a11->ISA a27 (address bit 4)
ISA a28 (address bit 3)<--a3-| |-oe-->jumper W1, pin 2
ISA a29 (address bit 2)<--a2-| |-a10->ISA a21 (address bit 10)
ISA a30 (address bit 1)<--a1-| |-ce-->jumper W1, pin 2
LS244 pin 3<--a0-| |-o7-->LS244 pin 8
LS244 pin 5<--o0-| |-o6-->LS244 pin 12
LS244 pin 7<--o1-| |-o5-->LS244 pin 16
LS244 pin11<--o2-| |-o4-->LS244 pin 20
gnd-| |-o3-->LS244 pin 15
+------+



So the outputs go to some kinda buffer-I should ohm that out to see where they go. I didn't have any specs with me when I multimetered this out.

I don't quite understand why bit 7 and 4 are duplicated and go to the same connector. I may have to 2x check that with the data sheets handy next time, likewise with the a0 output-i guess I would have suspected that to go the ISA a31. This is why you should never send a software guy in to do hardware work.

the jumpers themselves all end up at the asic on the card, so there's little hope in figuring out how the address selection is changed.

JT64
November 21st, 2008, 01:14 PM
Hello guys what happened to idea it did seem great but suddenly not a word, did it just roll over an die?

Will you implement DDO code for the bios?
Will it will be 8086 code.

Couldn't you at least program and implement the DDO driver before you give up the great idea, i need it for my ADP50L controller :D

Well if you still working on it good luck, it seems like a reall good idea to me.

JT

Druid6900
November 21st, 2008, 01:21 PM
Hello guys what happened to idea it did seem great but suddenly not a word, did it just roll over an die?

Will you implement DDO code for the bios?
Will it will be 8086 code.

Couldn't you at least program and implement the DDO driver before you give up the great idea, i need it for my ADP50L controller :D

Well if you still working on it good luck, it seems like a reall good idea to me.

JT

Looks like we are just waiting for someone to prototype the (whatever) design after the schematic is augmented to include the desired options and exclude the ones that aren't necessary.

Judging from the number of people fighting over the honour of doing it, I'm getting the sinking feeling that'll be me.....

NobodyIsHere
November 21st, 2008, 04:22 PM
Hi All,

I have a couple of questions for the XT IDE team. First, do you have an EDA like Eagle or KiCAD that supports the form factor for the XT card? KiCAD has the PC bus connector as a supported component but it still requires an "EDGES" outline of the PCB itself. Second, have you found a source for the PC card bracket connector? It has mount points which will affect the design of the PCB layout.

My suggestion is that if you already have some candidate PC cards as prototypes you could trace it to build the EDGES outline of the PCB and also determine the bracket mounting holes location.

The above things can be done by someone with no electronics experience or skills. All that would be required is getting a free EDA program and building the PCB outline. I recommend KiCAD although Eagle would work too. There are others like gEDA as well.

Next, do you have an example of the memory address decoding logic for the ROM? I see you have a ROM pin out but the most important pins (OE and CE) disappear into the bowels of an ASIC which tells you nothing about the actual actual decoding logic. It is probably pretty simple but it is important to capture the details if you'd like to add a ROM to the design. Check out the IBM technical reference for schematics to the CGA/MDA card since they contain onboard ROMs or possibly the original IBM XT hard drive controller to seperate out the address decoding logic. They have useful schematics there but there are probably others available.

Thanks and have a nice day!

Andrew Lynch

Druid6900
November 21st, 2008, 08:25 PM
Yeah, I have both Eagle 5.2.0 and a proprietary package that both have a XT card layout and I have several cards that have screw-in backplanes although I'll have to look around to see what is available now.

Your suggestion of checking out the CGA/MDA cards is certainly a good one to see how they work the ROM into the design since I was wondering how someone was going to work out the "plug-in" points between "here" and "there".

As always, Andrew, thanks for your insight.

JohnElliott
November 22nd, 2008, 08:21 AM
Your suggestion of checking out the CGA/MDA cards is certainly a good one to see how they work the ROM into the design since I was wondering how someone was going to work out the "plug-in" points between "here" and "there".

CGA and MDA wouldn't help, because they don't map their ROMs into the PC's memory space. EGA or a real hard drive controller would.

modem7
November 22nd, 2008, 01:55 PM
The schematic for one of the variations of the 10MB Xebec controller for the 5150/5160 is at:
http://members.dodo.com.au/~slappanel555/misc/IBM_Xebec_fixed_disk_adapter.pdf

That board has an 8KB ROM at C800:0

In that schematic, the ROM is designated 12J and is in the top-left corner of sheet 1.
You can see that the decode for the ROM's CE pin is done by a single chip, 11J, a 74LS688.

If you wanted to use that part of circuitry as is but instead use the first 8KB of a 27256 EPROM:
1. On the 27256, tie VPP to VCC and tie /CE to ground (both actions put the 27256 into READ mode)
2. On the 27256, tie all unused address pins to ground.
3. Tie pin 19 on the 74LS688 to the 27256's /OE pin

Terry Yager
November 23rd, 2008, 12:04 AM
Judging from the number of people fighting over the honour of doing it,.....

You can borrow my Louisville Slugger, if you need to beat 'em all away from your door...

--T

hargle
November 24th, 2008, 05:56 AM
Hello guys what happened to idea it did seem great but suddenly not a word, did it just roll over an die?

Will you implement DDO code for the bios?
Will it will be 8086 code.


DDO - Yes. The finished BIOS will support drives up to 137G, using 28bit addressing.
Your operating system is however the next limitation of addressable space.

8086 code - yes. well, 8088 code, but no 32bit registers will be used.

The original BIOS that I disassembled came from an acculogic IDE controller which was PC/XT compatible. IMO, it's poorly written and I've even found a couple minor bugs. I've been slowly re-writing it and I've added the enhanced INT13 support that we need to do big drives, and my big plan for the holiday weekend here is to port it over to a DOS TSR and see if I can make my own "disk manager" type driver that you could use on any machine to upgrade INT13 up to 137G. It'll all be open source and if things go well, available here for download by monday!

hargle
November 24th, 2008, 06:22 AM
The schematic for one of the variations of the 10MB Xebec controller for the 5150/5160 is at:
http://members.dodo.com.au/~slappanel555/misc/IBM_Xebec_fixed_disk_adapter.pdf

That board has an 8KB ROM at C800:0

In that schematic, the ROM is designated 12J and is in the top-left corner of sheet 1.
You can see that the decode for the ROM's CE pin is done by a single chip, 11J, a 74LS688.

If you wanted to use that part of circuitry as is but instead use the first 8KB of a 27256 EPROM:
1. On the 27256, tie VPP to VCC and tie /CE to ground (both actions put the 27256 into READ mode)
2. On the 27256, tie all unused address pins to ground.
3. Tie pin 19 on the 74LS688 to the 27256's /OE pin

wow, that's good stuff!
How do we implement selectable addressing via jumpers? Is it really as simple as having jumpers to break/connect other address lines, or is there other logic behind that? Ideally, it would have a minimum of 4 different addresses available, from C800-E000 or so. All my poking on my SCSI card only showed me that the jumpers end up at an ASIC, so that's no good.

per
November 24th, 2008, 07:30 AM
DDO - Yes. The finished BIOS will support drives up to 137G, using 28bit addressing.
Your operating system is however the next limitation of addressable space.

8086 code - yes. well, 8088 code, but no 32bit registers will be used.

The original BIOS that I disassembled came from an acculogic IDE controller which was PC/XT compatible. IMO, it's poorly written and I've even found a couple minor bugs. I've been slowly re-writing it and I've added the enhanced INT13 support that we need to do big drives, and my big plan for the holiday weekend here is to port it over to a DOS TSR and see if I can make my own "disk manager" type driver that you could use on any machine to upgrade INT13 up to 137G. It'll all be open source and if things go well, available here for download by monday!

The 8088 instruction is EXACTLY the same as 8086, the hardware timing is the only difference.

As for Int 13h, Will DOS (talking of version 2.1 to 3.1) support drives up to 137GB as well, or does it need a patch?

NobodyIsHere
November 24th, 2008, 07:36 AM
wow, that's good stuff!
How do we implement selectable addressing via jumpers? Is it really as simple as having jumpers to break/connect other address lines, or is there other logic behind that? Ideally, it would have a minimum of 4 different addresses available, from C800-E000 or so. All my poking on my SCSI card only showed me that the jumpers end up at an ASIC, so that's no good.

Hi! Just adjust the reference side of the 74LS688 8 bit comparator. It appears the A side is the for the address bus and the B side is the preprogrammed address setting. Put three way jumpers on the B side pins to set their levels to either HIGH or LOW depending on what the address is you are specifying for the ROM to appear at. When the upper address bits appear on the address bus, the 8 bit comparator will "trigger" sending a /CS signal to the ROM (OE and CE).

Thanks and have a nice day!

Andrew Lynch

PS, thanks for the catch on the CGA/MDA. You are correct as they have character generator ROMs only. I was thinking EGA/VGA with its BIOS ROM resident in main memory and misspoke.

hargle
November 24th, 2008, 09:18 AM
The 8088 instruction is EXACTLY the same as 8086, the hardware timing is the only difference.


IIRC, POP CS (at a minimum) works on an 8086 and not much else, but there's no such thing in any of my code!



As for Int 13h, Will DOS (talking of version 2.1 to 3.1) support drives up to 137GB as well, or does it need a patch?

http://en.wikipedia.org/wiki/Comparison_of_x86_DOS_operating_systems
(2nd table)

Nope. old MS/IBM DOS versions will only do 32MB partitions.
you'll want to switch to freedos or DR-dos 7 to do a bigger partition, although I'm not sure if those run on anything less than a 32bit CPU. It's an interesting problem that we're going to want to find the best DOS that supports big hard drives and still runs on an 8088!

I suppose at a minimum, DOS 4.01 with many 2G partitions could be fun.
I doubt I will put anything bigger than a 10gig drive in my machine.

per
November 24th, 2008, 09:38 AM
IIRC, POP CS (at a minimum) works on an 8086 and not much else,

I know, but it works on the 8088 too! It wasn't removed until 80186/80188. The only difference is the input/output controll part of the architecture.


but there's no such thing in any of my code!

That's nice. It isn't really usefull because it is a lot better to use normal far jumps. The problem is: you can only get to a multiply of 16 bytes to/from the adress of the instruction AFTER the "POP CS" instruction. It's worser than using IRet to pop the flags.

JT64
November 25th, 2008, 01:24 AM
DDO - Yes. The finished BIOS will support drives up to 137G, using 28bit addressing.
Your operating system is however the next limitation of addressable space.

8086 code - yes. well, 8088 code, but no 32bit registers will be used.

The original BIOS that I disassembled came from an acculogic IDE controller which was PC/XT compatible. IMO, it's poorly written and I've even found a couple minor bugs. I've been slowly re-writing it and I've added the enhanced INT13 support that we need to do big drives, and my big plan for the holiday weekend here is to port it over to a DOS TSR and see if I can make my own "disk manager" type driver that you could use on any machine to upgrade INT13 up to 137G. It'll all be open source and if things go well, available here for download by monday!

Almost seem to good, i wish you all success with the project. Look forward to try the TSR out on my ADP50L. (I have backup on CF)

When DDO is installed does that mean OS utilities like "fdisk", "scandisk" "chkdsk" recognize a bigger driver or must you prepare and format the drive from another HD? Will you post a compiled version of the TSR or just source code?

JT

hargle
November 25th, 2008, 06:16 AM
Almost seem to good, i wish you all success with the project. Look forward to try the TSR out on my ADP50L. (I have backup on CF)

Last night I got it working to the point where it ID's a master and slave drive, prints the model # to the screen, stores the drive's parameters internally, and installs the INT 13 handler. I verified that the floppy access via INT 13 still works as expected, and saw the first call from FDISK enter my code. (that's when I stopped for the night)
...and I wasn't even expecting to start working on things until wednesday!



When DDO is installed does that mean OS utilities like "fdisk", "scandisk" "chkdsk" recognize a bigger driver or must you prepare and format the drive from another HD?
JT
It's up to the software itself to call the enhanced INT13 functions to see larger drives. Essentially there are now 2 copies of INT13. Software that knows about bigger drives can call the big routines, and older software calls the old routines. fdisk from dos 4.01 won't see the whole drive. fdisk from windows98 will.

I don't really know how everything is going to work out in the end, but in a perfect world, you should be able to take a newer copy of DOS, setup a brand new hard drive on your XT, pull that drive out and move it over to your P4 machine and it should see your partitions just fine. That's what I'm shooting for anyway.

here's the specification:
http://www.phoenix.com/NR/rdonlyres/9BEDED98-6B3F-4DAC-BBB7-FA89FA5C30F0/0/specsedd11.pdf

It came out in 1995, so the problem now is that at the end of the day, we want to run this on old machines, using software written before 1995.
So I think that DOS should be fine running on a big drive, stuff like norton utilities or other software written pre-1995 could choke. We'll see! (and maybe make some compatibility lists too.)


The first big question is what is the best version of DOS to run on an 8088 machine, which provides the greatest forward compatibility to other O/Ses, and supports drives as big as possible, and doesn't break old applications like PCtools and Norton. I don't have an answer yet-maybe others can chime in?




Will you post a compiled version of the TSR or just source code?

Both. I don't expect people to have access to everything required to compile it, including the desire to, so I'll release everything and a nice readme on how to get it installed on a typical machine for each release I do.

This first release is PIO only, no DMA, no IRQs, no CD-ROM support, 2 drives maximum, standard IDE controller only. Future releases will expand upon that.

Trixter
November 26th, 2008, 08:22 AM
The first big question is what is the best version of DOS to run on an 8088 machine, which provides the greatest forward compatibility to other O/Ses, and supports drives as big as possible, and doesn't break old applications like PCtools and Norton. I don't have an answer yet-maybe others can chime in?


There are several, but my vote goes to IBM PC DOS 2000, if anything for the Y2K fixes.

BTW, there's no way to avoid breaking PCTools and Norton, unless you're using Norton Utilities 8, the last version released for DOS. 8 is the only one I would trust with large drives and long filenames -- earlier versions of both PC and N fail on such things miserably because they were created before such things existed.

JT64
November 26th, 2008, 08:30 AM
There are several, but my vote goes to IBM PC DOS 2000, if anything for the Y2K fixes.

I think my old PC-Xtra did came with IBM dos 1.0, i have the feeling that the sys files and command.com take longer to load on DR-DOS, MS-DOS.

Could it be that the extra functionality make a heavier load on an old xt, and what about the system size?

How much space take PC DOS 2000 compared with IBM DOS 1.0, if i only had the helper application functionality provided from the never versions. I would go for a real old dos, because XT with IBM DOS 1.0 was fast.

JT

per
November 26th, 2008, 11:15 AM
I think my old PC-Xtra did came with IBM dos 1.0, i have the feeling that the sys files and command.com take longer to load on DR-DOS, MS-DOS.

Could it be that the extra functionality make a heavier load on an old xt, and what about the system size?

How much space take PC DOS 2000 compared with IBM DOS 1.0, if i only had the helper application functionality provided from the never versions. I would go for a real old dos, because XT with IBM DOS 1.0 was fast.

JT

The difference is rather huge... PC DOS 2000 has many many MANY times the feautres of DOS 1.0 (talking about number of Int 21h functions)

*Edit*
The version of DOS you have doesn't really mater for the speed of your computer. The only thing DOS does is to use some RAM and provide usefull functions for programmers. DOS leaves all CPU power to the program executed, so then DOS acts like a normal TRS driver. The program has to return controll to DOS with an "Int 20h" (or "RET" with the word "0000" at the top of the stack). A custom program can compleetely take over controll of your computer and set up it's own Operating system over DOS in RAM. This is partly how earlier versions of Windows works.


Minimum System requirements for PC DOS 1.0:
1 IBM PC or compatible with Mono/CGA compatible monitor with adapter
1 Single Sided Double Density Floppy Disk Drive (5.25")
16Kb of RAM (more for big programs)

Minimum System requirements for PC DOS 7.0 (2000):
1 IBM PC or compatible with Mono/CGA compatible monitor with adapter
1 Double Sided High Density Floppy Disk Drive (3.5")
1 Hard Disk Drive with at least 6Mb of free space
512Kb of RAM

Terry Yager
November 26th, 2008, 01:55 PM
Subdirectories? You'll need v.2.0 or higher.

--T

Trixter
November 26th, 2008, 02:59 PM
I think my old PC-Xtra did came with IBM dos 1.0, i have the feeling that the sys files and command.com take longer to load on DR-DOS, MS-DOS.

Could it be that the extra functionality make a heavier load on an old xt, and what about the system size?


PC DOS 2000 boots nicely on my 4.77MHz 8088 XT. The only drawback with most DOSes that support large drives (ie. MS-DOS 6.x and later, IBM PC-DOS 7.x, FreeDOS) is that the first time you do a DIR, it takes between 14-20 seconds to return. After that it's fine. No idea why the first DIR takes a while.



How much space take PC DOS 2000 compared with IBM DOS 1.0, if i only had the helper application functionality provided from the never versions. I would go for a real old dos, because XT with IBM DOS 1.0 was fast.



The point of this exercise is to get a DOS that supports hard drives. DOS 1.0 does not support hard drives, nor most functionality that people actually need (subdirectories, for one).

PC DOS 2000 takes up around 7MB; MS-DOS 6.22 and DR-DOS 7.03 both take up around 4mb.

JT64
November 26th, 2008, 04:31 PM
PC DOS 2000 boots nicely on my 4.77MHz 8088 XT. The only drawback with most DOSes that support large drives (ie. MS-DOS 6.x and later, IBM PC-DOS 7.x, FreeDOS) is that the first time you do a DIR, it takes between 14-20 seconds to return. After that it's fine. No idea why the first DIR takes a while.

The point of this exercise is to get a DOS that supports hard drives. DOS 1.0 does not support hard drives, nor most functionality that people actually need (subdirectories, for one).

PC DOS 2000 takes up around 7MB; MS-DOS 6.22 and DR-DOS 7.03 both take up around 4mb.

I was more thinking about the memory space for the resident system files.

Ok i did not know that 1.0 didn't support HD and directories was along time since i used it.

JT

bobwatts
November 27th, 2008, 04:41 AM
Hi Gang !

Good to see the IDE XT controller is "progressing". :mrgreen:

My 7 worth on the DOS version: I find DOS 6.22 to work very well on an XT. DOS 5 is also very good, but DOS 6.22 has almost all of the features that a person would want, and doesn't seem to need much overhead to perform.

Anyone remember the "Graphics Menu for DOS" ? It was a fantastic little *GUI* program that would fit on a 720k disk, and had a lot of great features. Very advanced for such a small program, allowed the use of a mouse, and in my humble opinion, one of the best GUI's for an ancient 10MHz or lower computer.

Happy Thanksgiving gang !

bobwatts
EartH

Druid6900
November 27th, 2008, 01:02 PM
Yeah, it's progressing into a software thing while my cats are playing hockey with your Acculogic card :)

BTW, I resisted the urge to sell it to someone on here that was looking for one LOL

bobwatts
November 27th, 2008, 01:34 PM
Yeah, it's progressing into a software thing while my cats are playing hockey with your Acculogic card :)

BTW, I resisted the urge to sell it to someone on here that was looking for one LOL

Yes, I know. You have been under satellite surveillance since receiving the Acculogic XT-IDE card.

Strange....I have seven cats, and none of them showed any interest in the card. Josie and DOOM won't play witn anything earlier than P4 computers anyway.

Probably a Canadian cat thing. :rolleyes:

bobwatts
EartH

hargle
December 1st, 2008, 06:23 AM
well, here we are monday, and I have no deliverable yet.

I spent many hours over the holiday working on the BIOS for the card, and got really hung up on the CHS to LBA translation end of things. I'm trying to make sure that we can prep a drive on a new motherboard and be able to move that drive into our systems and still have all the data available. For the moment, my CHS->LBA code seems to be calculating things incorrectly, since I'm pulling up sectors that don't contain the data DOS is looking for. I'll get it figured out, but it just took up a bit more time than I was anticipating, particularly since I had to write some of my own debugging tools to diagnose the problem.

However, even with my LBA translations wrong, I am able to take a DOS 6.22 bootable disk, load my software up, see a blank drive, partition it as an 8.4G drive (DOS 6.22 doesn't know about extended INT13 support), format it, and copy files to the drive. So it's really close, just not compatible with other machines. I haven't been able to test any of the EINT13 code I've written yet-that'll require freeDOS or something newer than 6.22.

Druid6900
December 1st, 2008, 07:57 PM
Yes, I know. You have been under satellite surveillance since receiving the Acculogic XT-IDE card.

Strange....I have seven cats, and none of them showed any interest in the card. Josie and DOOM won't play witn anything earlier than P4 computers anyway.

Probably a Canadian cat thing. :rolleyes:

bobwatts
EartH

Yeah, it's much easier to play hockey with the card on the igloo floor :)

hargle
December 2nd, 2008, 06:01 AM
For the moment, my CHS->LBA code seems to be calculating things incorrectly, since I'm pulling up sectors that don't contain the data DOS is looking for.

HA! I wasn't wrong at all, it was DOS that was telling me the wrong place to go.
There are so many pitfalls to deal with here. Essentially by the time you've booted into DOS (at least 6.22) it has already asked what size drive is available and stored that data internally somewhere.
Then I come along and re-detect the hard drive information, and update the "get disk parameters" function from INT 13. Unfortunately, DOS doesn't ask what the disk parameters are anymore, and I don't know of a way of telling DOS to update that information.

So I now have to convert my option ROM BIOS, which was already converted into a TSR, into a device driver so I can attempt to get loaded earlier in the boot process. Hopefully that'll let me inject my code in before DOS sniffs out the hard drives available. jeeze.

hargle
December 2nd, 2008, 06:50 AM
ok, so I'm thinking I want to try my hand at building one of the controllers from the schematic (ide-linux) as posted earlier, since no one else seems to be volunteering to build one for me. :)

this place, bottom of the page (i hope "standard PCI bus connector" is a typo!)
http://www.futurlec.com/ProtoBoards.shtml

has ISA prototyping boards for $14, which I think should work nicely.
Then it's just a matter of shopping for the ICs needed and spending a few hours at the soldering station.

i'm going to order 2 of them and 2x the ICs, and hopefully by xmas I'll have something working. if all goes well, i'll build the 2nd one and send it to druid.

*edit*
wow, ok, i have no idea how to order ICs. The schematics say 74245, and www.jameco.com has stuff like 74F245 and 745F24N with options for N channel and P channel, etc. I'm very confused and am feeling very dumb. Any chance someone can put together a shopping cart full of the parts I'd need to build one of those things?

Druid6900
December 2nd, 2008, 07:33 PM
Well, firstly, the bottom board IS a PCI and the ISA one above it is a 16-bit board.

Your best bet is to go with the 74LS series of TTL chips as they are more common, usually cheaper and will work in all but the most finicky circuits.

Which schematic are you going to use?

I think Andrew referenced an 8-bit ISA protocard in there somewhere.

per
December 2nd, 2008, 10:17 PM
Well, firstly, the bottom board IS a PCI and the ISA one above it is a 16-bit board.

Your best bet is to go with the 74LS series of TTL chips as they are more common, usually cheaper and will work in all but the most finicky circuits.

Which schematic are you going to use?

I think Andrew referenced an 8-bit ISA protocard in there somewhere.

I think he reffered to this (bold text):




ISA Bus Computer Board
Heavy Duty Phenolic Pre-Drilled ISA Bus Connector Board. Ideal for computer control and interface projects. Plus directly into your computers ISA Bus. Mountings for DB25 connector, Power Connections and IDCC Male Headers.
Part Code: ISABUSBRD
Pricing:

Features
• Pre-drilled and cleaned
• Heavy Duty Phenolic with Green Solder-Mask
• Standard PCI Bus Connector
• Fittings for DB25 Connector, PCB Terminals, 40 Pin and 16 Pin IDCC Male Header
• Board Dimensions: 182 x 110mm


Qty
1 +
25 +
100 +
US$ (each)
$13.90
$12.90
$11.90

Order Now for $13.90

Druid6900
December 3rd, 2008, 08:43 PM
I think he reffered to this (bold text):

Yes, I know what hargle referred us to, but Andrew referred this 8-bit ISA protocard

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=21532&

Which I think would be the better board.

gerrydoire
December 4th, 2008, 03:08 AM
Yes, I know what hargle referred us to, but Andrew referred this 8-bit ISA protocard

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=21532&

Which I think would be the better board.


Do you think these is enough market demand for 8-bit IDE cards for the 8Bit PC as there is for the 8-bit Apple ][.

Reactive Micro sells them and they are constantly in demand to some degree.

Recently on Ebay an Acculogic 8-bit IDE went for $100ish, except for the firmware the rest of the card looked like it had nothing special chips onboard.

greglentz
December 4th, 2008, 06:07 AM
Just jumping in here. I see you guys are close to starting a board design. One of the critical things for me would be board length. My Tandy 1000sx can only take 3/4 length cards, 1/2 length would be better like what the ide Acculogic card or some of the WD or Seagate MFM/RLL cards are. I hope 8 bit 1/2 or 3/4 length cards are still available.

Greg Lentz

hargle
December 4th, 2008, 06:14 AM
Yes, I know what hargle referred us to, but Andrew referred this 8-bit ISA protocard

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=21532&

Which I think would be the better board.

I couldn't tell that the board andrew pointed us to was ISA. the picture didn't help, and the description didn't say ISA on it anywhere. Not that I'm doubting andrew's ability to find what we need, it's just as a software guy, that stuff is confusing!

The board I found was most certainly an ISA board, looked exactly like I was expecting in the picture. 16bit makes not 1 iota of a difference for us (hell i'll dremel that part off if I need to), and mine was 6 bucks cheaper!! :)

whatever though. i'm still more hung up on the parts selection than I am on what to nail them all to when i get all the pieces together. i've asked some of my co-workers for assistance it parts pulling and design. the guys here are really, really bored, it's just a matter of getting it through the upper boss to have them work on a non-work related project.
--------

on the software front, i've found that a .sys driver also doesn't load early enough to get it's hooks in before DOS figures out what hard drive is attached. this means that i need to create either a type of boot sector virus to load before DOS (disk manager does that), or perhaps try and bundle all the code into a block type driver and let it work with DOS to create a new drive letter and handle all the read/write support. I've basically spent the last 4 days working on finding ways to co-exist with DOS, and not actually testing any of my BIOS code like I was hoping to be doing.

hargle
December 4th, 2008, 06:20 AM
Just jumping in here. I see you guys are close to starting a board design. One of the critical things for me would be board length. My Tandy 1000sx can only take 3/4 length cards, 1/2 length would be better like what the ide Acculogic card or some of the WD or Seagate MFM/RLL cards are. I hope 8 bit 1/2 or 3/4 length cards are still available.

Greg Lentz

we should be able to work with that. the board is going to be a custom PCB, so we can make it any size we want, but i'm likely jumping the gun here.

the first step is to build a giant, bulky prototype card that so we can debug it and nail down the specific design and software support. once that's in place, the board should be pretty compact since there isn't that much hardware on it to begin with, so I'd think a 3/4 length card at most should be totally doable.

gerrydoire
December 4th, 2008, 06:40 AM
we should be able to work with that. the board is going to be a custom PCB, so we can make it any size we want, but i'm likely jumping the gun here.

the first step is to build a giant, bulky prototype card that so we can debug it and nail down the specific design and software support. once that's in place, the board should be pretty compact since there isn't that much hardware on it to begin with, so I'd think a 3/4 length card at most should be totally doable.

What about firmware, where will that come from?

hargle
December 4th, 2008, 07:01 AM
What about firmware, where will that come from?

that's coming from me, with a little help from acculogic.
if you go back in the thread, we dumped the acculogic BIOS, I disassembled it, and I have been working it over to include support for enhanced INT13 support to give us 137G drives, as well as re-working the drive parameter translations so that O/Ses that don't use Eint13 (like DOS 6.22) can still see it as a 8.4G drive, as opposed to 504MB. I think 8.4G is plenty for an 8088 machine. :)

The original source is nearly all been removed by now, since it was ugly, poorly written (in my opinion) and kinda buggy. It will all be open source when it's finished and debugged.

I'd like it if we can build the card to allow software updates to an eeprom as well, in case other features or CD-ROM or compact flash support requires any firmware changes. In that case, I'll be writing a flash utility as well.

I'm a software engineer by day, and spent a pretty good portion of my career working with phoenix BIOS. I've written BIOS support for IDE controllers before (more at the chipset level than the INT13 level though)
Oddly enough, here at work, i am working on solid state drives, and one of the tasks i'm to do is build an option rom for a custom drive/controller we're building. So, work is getting someone who is really, really motivated to work on their option rom, and the community here is getting someone who has the experience of having done it before. It's a little gray as far as code written at work being shared to an open source project and vice versa, but really, these two projects are about as far apart on the spectrum as you can get-i don't see a conflict of interests at all.

so yeah, sorry for the horn tooting, but firmware is in good hands.

per
December 4th, 2008, 07:09 AM
For DOS support, an idea would be to use switch settings for heads, sectors and cylinders data... Another by using a block driver, as you said (it won't work in DOS 2.1 anyways).

hargle
December 4th, 2008, 07:32 AM
For DOS support, an idea would be to use switch settings for heads, sectors and cylinders data... Another by using a block driver, as you said (it won't work in DOS 2.1 anyways).

well, the crux of the problem is that i need to replace INT13 so that all calls to read/write/query the drive come from me, and I need to do this before DOS loads up, because DOS does a get drive parameters call very early during boot, before I can get in there to hook INT13. After booting, DOS never again asks the size of the drive, so I can't force an update of the drive parameters. If I hook INT13 after boot, DOS then tries to read invalid sectors when doing even a simple "dir c:" because the drive geometry has changed because I detect the drive differently than the existing BIOS does.

If I set the drive type to none in CMOS setup, DOS doesn't think there's a drive there at all, and doesn't ask for the parameters, and then doesn't provide you with a C: drive, even after I've replaced INT13. (I assume it looks at 40:75 and sees that the BIOS has provided no drives, so it installs no drive letters)

If this were done during POST, through an option ROM, i'd be set-i'd have my hooks in before DOS even knew where to boot from, and all would be happy, but I don't have the ability to load in that early at the moment.

A block device driver may work, although I'm discovering that device drivers too seem to be limited to old <2gig parameters, so that may also be a dead end too.

I've no problems doing a boot sector loader, but then that entails me writing an installer for it if others want to use it, and all the headaches involved with debugging that. All I really want to do is debug my INT13 code and I keep getting pushed further and further back trying to wedge myself in.

per
December 4th, 2008, 07:56 AM
I will prefere to have it as a Boot ROM on the final product, but I understand that might be a problem in the testing process.

If you got an EEPROM and an EEPROM burner, you could use that... Of course you'll need an EEPROM-to-EPROM adapter, but that's pice-of-cake to make.

MikeS
December 4th, 2008, 08:24 AM
When I did this sort of thing in prehistoric times I found battery-backed NVRAM a godsend; pin-compatible with (EP)ROM, no flashing, no erase/burn, no write cycle limits, etc. I wonder if that's still an option for this sort of thing: cobble up a protoboard, or even pop one into an old HD controller, and modify to your heart's content.

Maxim (Dallas) used to make smallish ones; not sure if they still do, but now there's also ST Micro.

Better check the batteries in mine now that I think of it...

hargle
December 4th, 2008, 10:28 AM
I will prefere to have it as a Boot ROM on the final product, but I understand that might be a problem in the testing process.

yeah, an eeprom on the final product is mandatory. i'm really just trying to get some debugging done ahead of time to keep the project rolling along, hence trying to get it debugged in DOS on a normal IDE controller right now.



cobble up a protoboard, or even pop one into an old HD controller, and modify to your heart's content.

that's pretty much my next step-I'm trying to gather the pieces to put together a proto-controller.

Somewhere I have a PROM-ICE that I plan on trying out with this once I get a piece of hardware to play with, but you might just be onto something here... pull the rom off any old card, even SCSI, since all I need to do is hook INT 13 and return back to the POST.
(insert sound of hargle's gears turning in his head) thanks for the idea!

gerrydoire
December 4th, 2008, 11:19 AM
that's coming from me, with a little help from acculogic.
if you go back in the thread, we dumped the acculogic BIOS, I disassembled it, and I have been working it over to include support for enhanced INT13 support to give us 137G drives, as well as re-working the drive parameter translations so that O/Ses that don't use Eint13 (like DOS 6.22) can still see it as a 8.4G drive, as opposed to 504MB. I think 8.4G is plenty for an 8088 machine. :)

The original source is nearly all been removed by now, since it was ugly, poorly written (in my opinion) and kinda buggy. It will all be open source when it's finished and debugged.

I'd like it if we can build the card to allow software updates to an eeprom as well, in case other features or CD-ROM or compact flash support requires any firmware changes. In that case, I'll be writing a flash utility as well.

I'm a software engineer by day, and spent a pretty good portion of my career working with phoenix BIOS. I've written BIOS support for IDE controllers before (more at the chipset level than the INT13 level though)
Oddly enough, here at work, i am working on solid state drives, and one of the tasks i'm to do is build an option rom for a custom drive/controller we're building. So, work is getting someone who is really, really motivated to work on their option rom, and the community here is getting someone who has the experience of having done it before. It's a little gray as far as code written at work being shared to an open source project and vice versa, but really, these two projects are about as far apart on the spectrum as you can get-i don't see a conflict of interests at all.

so yeah, sorry for the horn tooting, but firmware is in good hands.

Will you be selling this card? I will be wanting 2 of them :mrgreen:

per
December 4th, 2008, 12:12 PM
Will you be selling this card? I will be wanting 2 of them :mrgreen:

Yes, when the card is finnished, it will be sold for a reasonable price (not 200$).

wmmullaney
December 4th, 2008, 12:26 PM
How far are you?

hargle
December 4th, 2008, 01:03 PM
How far are you?

on the software side, i'm going to go out on a limb and say it's 80% finished.
adding support for DMA, whatever might be required for CD-ROM and CF may push that back another 10%.

hardware side is nowhere close. druid is very busy, and we keep changing the design. I'd love to help out more with the hardware side, but I don't have the skillset to do it.

we've got 2 schematics to play with, but neither have option rom support, we don't have DMA support or jumper selections for addresses or IRQ/DMAs, and all of that needs to be added and tested as a hand built prototype. Then when the design is finalized we'll released it to a PCB manufacturer.

All of the boards will also be built by hand. I suspect we'll do a run of maybe 200 PCBs and build them up as people order them, or we can of course sell it as a kit and you can build your own. I think total cost for the card+parts should be $20 or less. Since I'm a slow solderer, if I build one for you, it may easily double the cost. ;) With DIPP based ICs and a PCB though, it should be pretty quick work to build one of these.

I'd like to see the whole thing be open source, from the schematic to the source code to the PCB layout and the bill of materials. I would be very angry if someone from here buys one and tries to re-sell it on ebay for $200.

Anyway, this is my big winter project-I'll do whatever I can to make this thing a reality by spring of 09.

Druid6900
December 4th, 2008, 02:01 PM
God Save The Queen....Hic...thud.

I'm on top of stuff and I figure that, worse case, the card MAY be a little longer than a full-height 1/4 length card.

Depends on how much extra stuff goes in there.

On my initial board layout (several designs ago), it all fit on a quarter length card with room to spare for a ROM and some jumpers without any crowding.

Jorg
December 5th, 2008, 12:22 AM
on the software side, i'm going to go out on a limb and say it's 80% finished.

Hi Hargle,

You might want to set up a 'sign up here' thread to have an idea how many people are interested..
I would certainly expect to sign up for at least two myself.
Then there is a dutch mailing list I could drop it.. but only after you are ready for it :)

NobodyIsHere
December 5th, 2008, 05:43 AM
Hi All!

One small piece of advice... do not accept any orders until you have hardware in hand. Accepting money in advance sets unrealistic expectations, commits you to delivery, and it is the road to hell.

When you receive the parts shipment, then take orders and deal in a "cash on the barrel head" only format. PayPal is a great way to go.

Arranging group buys, advance orders, etc are complex, time consuming, and just plain dangerous. There are many examples of this but the most recent one is the IMSAI II disaster well documented on comp.os.cpm.

Take it for what its worth...

Thanks and have a nice day!

Andrew Lynch

hargle
December 5th, 2008, 07:43 AM
good advice all around, thanks andrew.

i have no problems bankrolling the entire thing as a startup and then taking orders as the hardware becomes available. i won't take a dime until i can actually ship something that works as promised. it's just the right thing to do. i also have plenty of storage space for spare cards and parts if need be.

i do think a show of hands for how many orders to anticipate might be a good idea though. i mean if we're looking at 500+ then maybe it does start to make sense to get them built by the manufacturer instead of doing them by hand.
i'll set up something for that once the prototype is further along and we're actually thinking about pulling the PCB trigger.

---
on the software side, i have now abandoned the driver idea, and am down to either creating a boot sector loader or putting my bios code into a rom emulator and plugging it into my SCSI controller. I think I've got all the parts I need to do that-just need to dust them off. that'll be quite the hoot-using a SCSI controller do load my option rom that talks only to hardware on a different card. hehe. hopefully I can work that out this weekend.

Terry Yager
December 5th, 2008, 01:06 PM
<Holding up two hands>...

--T

gerrydoire
December 6th, 2008, 05:58 PM
Here is my 8-bit IDE Card, when it boots up you see a memory address and it then goes to nothing, won't boot any IDE HD's I have tried or that CF IDE Card contraption either.

Perhaps the settings on the card are wrong?

http://www.barfs.biz/wd.jpg

WDC (c) 1988

strollin
December 7th, 2008, 07:53 AM
I'm in for at least 2 when you have them available.

You might want to consider a kit that would include the printed circuit card, hardware, all components and software. That would save a bunch on manufacturing/assembly costs.

hargle
December 7th, 2008, 08:09 AM
Here is my 8-bit IDE Card, when it boots up you see a memory address and it then goes to nothing, won't boot any IDE HD's I have tried or that CF IDE Card contraption either.
Perhaps the settings on the card are wrong?
WDC (c) 1988

that might be an 8bit only card, which would require an XT-IDE type hard drive to work in it, or as you say, it may just be a jumper setting. that's exactly what we're going to eliminate with our card. you should (soon) be able to buy any hard drive off the shelf currently in stock and throw it on this card and drop it into your PC/XT and have it just work. Cd-ROM and CF support would be icing on an already delicious cake.

-----
in my world, i've got a prom-ice ROM emulator box, but the cable I have for it is for a 32 pin dipp eprom, not the 28 pin rom I have on my scsi controller, so I need to go wire up an adapter for it. shouldn't be that big of a deal, but it's yet another setback in my road to debugging. typical me.

gerrydoire
December 7th, 2008, 08:17 AM
that might be an 8bit only card, which would require an XT-IDE type hard drive to work in it, or as you say, it may just be a jumper setting. that's exactly what we're going to eliminate with our card. you should (soon) be able to buy any hard drive off the shelf currently in stock and throw it on this card and drop it into your PC/XT and have it just work. Cd-ROM and CF support would be icing on an already delicious cake.


It will be interesting to see if 8-Bit PC users are as plentyfull as 8-Bit Apple II users looking for this sort of device..

:D

hargle
December 7th, 2008, 09:42 AM
You might want to consider a kit that would include the printed circuit card, hardware, all components and software. That would save a bunch on manufacturing/assembly costs.

yep, that's been considered. I think it'll be available like this:

software: free download from some web homepage. everything is always free (compiled binary, drivers, firmware source, schematic, layout files, etc)
All software info that i've collected through this project will be addressed on the website. gerrydoire has volunteered to make some nice pdf documents of all the info you'll need for jumper settings, etc. that'll all be online too.
kit: PCB+loose parts in a bag, you solder: $xx.xx (will include already programmed eeprom if we don't create a flash program)
Hopefully under $20.
built: finished card (a fully assembled and tested card in a static bag) $xx.xx
Hopefully under $40, depending on how much time it takes for me to hand assemble and test.
deluxe kit: finished card+8 or 10gig hard drive. I may have a lead on getting a lot of used xbox 1 hard drives, which are the perfect size for this application.*
$xx.xx (since the drives are used I'd sell them at whatever my cost is)

Just ideas. I think i'm getting a bit ahead of myself though.

* DOS 6.22 can see 8.4 gig drives without any drivers via multiple 2gig partitions, and 8.4g on an XT is an insane amount of storage. It's pretty pointless to put anything bigger in there, but the card should support up to 137gig natively, but your OS will need to as well, so be warned.

MikeS
December 7th, 2008, 12:41 PM
I'm constantly amazed at all the fabulous developments happening for the old machines:

I was just at the World of Commodore here in Toronto, where Jim Brain was assembling some of his tiny 1 1/2" square SD card boards that replace the Commodore IEC disk drives, and Brian Lyons had one of his VIC20 Denial carts that contains pretty well every program ever created for the VIC; work is underway on IEEE SDcard and IDE HD interfaces for the PETs etc. as well, and of course everyone knows of Jeri Ellsworth's C64-on-a-chip, and the CommodoreOne... I still remember my amazement the first time I saw a joystick with the whole C64 inside it; too bad the marketing was such a disaster.

Meanwhile on the Radio Shack front, there's a new device just out that sticks a PC-compatible SD(HC)card on the serial port of a model 100 type notebook computer to replace the TPDD disk drive, as well as an internal flash RAM device that lets you select any option ROM you like as well as adding RAM storage, which make that old favourite remarkably useful even in today's environment.

And of course the Apple and Atari groups haven't been idle either, and there are folks like Andrew building 'new' CP/M systems, not to mention the replicas of the old favourites being built; exciting times, wish we'd had this stuff then...
;-)

Best of luck with your 8-bit IDE card!

mike

Druid6900
December 7th, 2008, 07:47 PM
When we get to the build stage, I'll work on that after we get the board designed.

The only problem I can see is getting back-plane brackets. We might have to have them made.

Ole Juul
December 8th, 2008, 12:47 AM
>Druid6900: "The only problem I can see is getting back-plane brackets. We might have to have them made."
Good point, but I suspect that kind of thing could be pricey in small quantities unless they are generic. Perhaps better to rip them off Winmodems and other useless cards that would otherwise be thrown out. :)

hargle
December 8th, 2008, 06:28 AM
here's some brackets:

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=1582356&

there's a datasheet there, and it appears they have various ones that have screw-in mounting tabs off the back of the bracket like we'd need.

holy crap though, 2 bucks each!??! That's likely to be the most expensive part on the whole board!

Ole Juul
December 8th, 2008, 12:35 PM
Two 2 bucks is berable I suppose, but I notice that the catalogue only lists model 9203 which is PCI. I wonder if other models are the same price or if they are special order. Presumably a 9206 for EISA/ISA is the appropiate one.

hargle
December 8th, 2008, 12:46 PM
hmmmm.
there's a metal stamping place about a block away from where I work.
I wonder if I could just pull the bracket off my ISA SCSI controller, take it in there, and see if they could make more of them, and at what cost.

it really seems like we shouldn't have to make any more of them though-they should be in surplus computer electronics shops around the globe. I mean, provided the connecting tabs are on the correct side of the bracket, we can develop the PCB around the connector-it's not like we need to do anything custom.

Ole Juul
December 8th, 2008, 02:59 PM
There's another way to go. The regular cover brackets, which we all have lots of, can be drilled with two holes and little "L" brackets used. That procedure would only entail a little more complexity than the traditional way. In total, two holes drilled and two more little bolts used. I actually got a bag of little brackets like that from LeeValley, although I can't put my mitts on them right now. They're a pretty standard item.

Edit: I found threaded (4-40) "L" brackets for 20 cents each in 100's. Item number 1581530 in Jameco catalogue P.88: http://www.jameco.com/Jameco/catalogs/c284/P88.pdf

Druid6900
December 8th, 2008, 07:41 PM
Ok, but, we have to standardize on something because the screw-holes have to designed into the board (unless you LIKE the smell of burning G-10 epoxy).

Terry Yager
December 8th, 2008, 08:58 PM
How 'bout plastic clips? I dunno where to get them, but I have seen 'em on a few boards before. It just slides onto the top edge of the board (assuming full height) and extends over to the screw hole. Anybody know what I'm talking about? Do I???

--T

MikeS
December 8th, 2008, 09:20 PM
Yeah, I was going to mention those; some of the short WD HDCs used 'em, but where are ya gonna find 'em? Might be able to do something similar though, maybe a metal bracket, that's less trouble than attaching to the slot cover.

Chuck(G)
December 8th, 2008, 09:38 PM
If you're running on a 5150/5160, you're not going to be running special hard disk drivers, right? Just code the card BIOS to block 2 256-byte half-sectors up into a 512 byte one.

No biggie.

dongfeng
December 9th, 2008, 02:39 AM
Why not leave a margin at the board edge so the user can drill their own holes?

bobwatts
December 9th, 2008, 03:41 AM
Hello Mr. Yager !


How 'bout plastic clips? I dunno where to get them, but I have seen 'em on a few boards before. It just slides onto the top edge of the board (assuming full height) and extends over to the screw hole. Anybody know what I'm talking about? Do I???

--T

That is exactly how the Acculogic sIDE board connects. A simple plastic thingy on the top of the board that goes under a slot cover screw. A standard slot cover is still used. No need to even remove one already present.

Frankly, if a card is produced, I'll figure out a way to mount it. :sly:
Not worried 'bout that. Tarp strap should do it.

bobwatts
EartH

hargle
December 9th, 2008, 06:29 AM
Why not leave a margin at the board edge so the user can drill their own holes?

i think this is a good idea if we can't come up with anything else.
leave 1/2" open at the entire edge of the PCB so that if someone had a slot cover with tabs on it, they could make it fit any way they can. the board may be a tad longer, but i still think we've got room to spare and it'll still fit into those tandys.

i find it comically lame that we can do all this work, make a custom PCB and generate this amazing piece of hardware, and we're stumped on a good way to mount the thing in the computer! we'll find a way though.

--------
in the software world, i managed to get my rom emulator up and running on my SCSI card. I had to build a 32->28 pin adapter for it, and i even ended up plugging it in backwards, but after the smoke cleared (j/k) I was able to load the original future domain bios in via the emulator and see it sign on during post. So, I am set now for creating an actual option rom and being able to debug it completely without trying to wedge my way in around DOS. Yay! Progress should go significantly faster now.

gerrydoire
December 9th, 2008, 06:40 AM
The world awaits the "hIDE" Card from Hargle Cards Inc. :D

Druid6900
December 9th, 2008, 10:48 AM
Why not leave a margin at the board edge so the user can drill their own holes?

See my previous post regarding "burning G-10 epoxy". Toxic, ya know.

We are going to all the trouble of reverse engineering a BIOS, building a quality card, converting (as far as the choice we are at now, I believe) a ECB design to an 8-bit ISA design and you guys want to mount it with Duct Tape?

2 bucks for a stinkin' backplane mount. I think you are taking cheapness to a whole new level.

MikeS
December 9th, 2008, 12:05 PM
Hey, duct tape RULES!

Seriously, if I understand correctly this board'll have through-hole chips and an EPROM?
FWIW, I have a pile of 27128s if you can use 'em; might be an idea to provide some pre-connected pads to allow selecting different size EPROMs?

Ole Juul
December 9th, 2008, 02:50 PM
1. @ dongfeng and hargle: as you know, the traditional mounting involves two holes on the end of the board which are used to attach it to the bracket. I'm supposing the boards will come like that already, or at least, be easily made to come like that. :)

2. The little "L" brackets which I suggest are an easily available, and cheap, solution. They are made for just this sort of thing and they look good.

3. The plastic brackets are a simple solution. I've seen them, but would be concerned that they've dropped off the planet - atleast in the of-the-shelf sence.

4. I agree with Druid6900, 2 bucks is not too much for such a fine project. There is no need to go cheap if it will compromise the end result. This kind of bracket is definately the best way to go. However, we still don't know if it is 2 bucks. The needed bracket is not actually in the Jameco catalogue but rather in the factory spec sheet, and we don't know if we can get them from the manufacturer or if Jameco will bring them in at an affordable price . The Jameco catalogue contains a similar but unusable bracket, and that is the one which was quoted at 2 bucks. We're still at square one in the 2 bucks deparmtment. :) Anyway, getting a nice bracket would be worth a premium.

5. For the doityourselfers: The same design concept as the plastic brackets can easily be realized by taking a regular blank metal bracket and modifying it with a couple of snips and bends. I could do that and make it look quite professional, but someone without metalworking skills or available workshop may have trouble making it look really good.

CONCLUSION:
6. To me the best solution is either the traditional bracket with the "L" extentions built in. This requires only two screws in addition to the bracket. We don't know the price of that yet.
Or,
the blank bracket with the two "L" brackets (http://www.jameco.com/Jameco/catalogs/c284/P88.pdf) as seperate pieces. That will cost 40 cents plus the cost of 4 screws and a (presumably free) blank bracket.

hargle
December 9th, 2008, 03:47 PM
woo!
http://www.waste.org/~winkles/1strom.jpg

we have an option rom!
I have a bug-I don't actually have 2 drives. oh well.

BG101
December 9th, 2008, 04:48 PM
I'm happy to provide assembly services, if needed. Will save export/import costs as components can be bought locally ;) have a good few years' experience with PCB manufacturing

hargle
December 12th, 2008, 05:14 AM
here's something to think about wrt the option rom:

If you have a 286->486, and it doesn't have BIOS support for at least 8.4g IDE drives built in, and you have a spare, possibly junked SCSI controller or other device with a BIOS that you could replace, you could replace the BIOS chip on an old card with my option rom, and it'll upgrade your onboard BIOS support to give you a big hard drive. The IDE controller in your machine would need to be using standard IO addresses (ports 1f0-1f7), which should be common.

if I could get some folks to do that, that would provide me with a more robust testing grounds, as i'm sure there are folks using some obscure disk utilities out there and alternate operating systems than just DOS 6.22.

Just to be perfectly clear, this is not going to work on an XT or PC-you will need a 16bit IDE controller for this to work.

This could be another option for another PCB too. Just a plain ole plug in card that has nothing but a BIOS on it for upgrading your INT13 support.

mbbrutman
December 12th, 2008, 05:19 AM
Not too long ago Promise used to sell an IDE BIOS that did exactly that - it was a small card with a ROM on it that used the existing controller elsewhere in the machine. One would 'disable' the existing controller by setting the drive type to zero in the BIOS, which would still allow the hardware to respond if it was accessed. The Promise ROM would then do the rest.

StickByDos
December 12th, 2008, 10:25 AM
you have a spare, possibly junked SCSI controller or other device with a BIOS that you could replace, you could replace the BIOS chip on an old card with my option romif you use your computer networked, how about network boot rom socket ? You won't loose any slot for junk card

Plasma
December 12th, 2008, 09:17 PM
Not too long ago Promise used to sell an IDE BIOS that did exactly that - it was a small card with a ROM on it that used the existing controller elsewhere in the machine. One would 'disable' the existing controller by setting the drive type to zero in the BIOS, which would still allow the hardware to respond if it was accessed. The Promise ROM would then do the rest.

Yep, the Promise DriveMax. I have a few of those ROMs in my computers. Modified one to always install regardless of BIOS drive settings and skip the secondary IRQ check to speed things up.

This is a cool project hargle. I Don't need really need an 8-bit IDE anymore now that I got a TMC-850 and a SCSI-IDE bridge but I might buy a few just to have around. :cool:

hargle
December 14th, 2008, 06:06 PM
ok gang, good progress was made today.

Here's stab #1 at a working option ROM.

Tested:
1. single drive, drive was 10gig.
2. DOS 6.22 fdisk sees the drive as 8033MB
3. partitioned into 4 drives, each ~2gig each (the maximum for FAT-16)
4. formatted C:/s and copied other files to the drive
5. booted to C:
6. formatted d: and copied files to the drive
7. ran chkdsk and scandisk without errors
8. put drive in a via epia board, and was able to boot to it, see all the files. Drive appears to be completely interoperable with my single modern test system

Untested:
1. drives smaller than 8.4gig - i can definitely see a possible issue there.
2. 2 drives
3. any other OS other than 6.22
4. interoperability with other modern platforms with AMI BIOS or other
5. any extended INT13 functions. There will absolutely be bugs there.
6. any funky INT13 commands like format track or diagnostics
7. most disk utilities, benchmarks
8. failing drives with ecc errors or something to test the error reporting

To use this option rom, you will need a card with a blank socket on it, and a 16bit IDE controller elsewhere in the system. As suggested by StickByDos, a NIC card typically has a blank rom socket on it-this could be a brilliant solution!

At the moment, it's a 4k option rom. It will likely not grow beyond this size.

Set your drive types in CMOS setup to *none*! If the onboard BIOS sees the drive there, my bios will not hook INT13 and won't install.


To build this option rom, you will need MASM 6.11 (or higher) in your path, and I use debug.exe to help truncate the file to the correct size. Just type "build" at the DOS prompt to build it. You should have a 4k file called oprom.bin when you're finished.

The code is still fairly nasty looking, but I figured this is a bit of a milestone, so might as well get it out there.

have fun!

Druid6900
December 14th, 2008, 07:01 PM
Good work, Hargle.

You're a credit to the, ummm, what did you say you did again? LOL

Seriously though, your hard work won't soon be, umm, what was I saying?

JT64
December 15th, 2008, 07:41 AM
ok gang, good progress was made today.

Here's stab #1 at a working option ROM.

Tested:
1. single drive, drive was 10gig.
2. DOS 6.22 fdisk sees the drive as 8033MB
3. partitioned into 4 drives, each ~2gig each (the maximum for FAT-16)
4. formatted C:/s and copied other files to the drive
5. booted to C:
6. formatted d: and copied files to the drive
7. ran chkdsk and scandisk without errors
8. put drive in a via epia board, and was able to boot to it, see all the files. Drive appears to be completely interoperable with my single modern test system

Untested:
1. drives smaller than 8.4gig - i can definitely see a possible issue there.
2. 2 drives
3. any other OS other than 6.22
4. interoperability with other modern platforms with AMI BIOS or other
5. any extended INT13 functions. There will absolutely be bugs there.
6. any funky INT13 commands like format track or diagnostics
7. most disk utilities, benchmarks
8. failing drives with ecc errors or something to test the error reporting

To use this option rom, you will need a card with a blank socket on it, and a 16bit IDE controller elsewhere in the system. As suggested by StickByDos, a NIC card typically has a blank rom socket on it-this could be a brilliant solution!

At the moment, it's a 4k option rom. It will likely not grow beyond this size.

Set your drive types in CMOS setup to *none*! If the onboard BIOS sees the drive there, my bios will not hook INT13 and won't install.


To build this option rom, you will need MASM 6.11 (or higher) in your path, and I use debug.exe to help truncate the file to the correct size. Just type "build" at the DOS prompt to build it. You should have a 4k file called oprom.bin when you're finished.

The code is still fairly nasty looking, but I figured this is a bit of a milestone, so might as well get it out there.

have fun!


What happened with the TSR, version?

per
December 15th, 2008, 08:05 AM
What happened with the TSR, version?

Because TSR's don't work with drives as large as 8Gb, and have to be loaded after DOS has BOOTed. The program for E-INT 13h have to be loaded before DOS.

kb2syd
December 15th, 2008, 08:19 AM
Am I correct in assuming that this will NOT work in an 8-bit machine?

Kelly

hargle
December 15th, 2008, 09:58 AM
> Am I correct in assuming that this will NOT work in an 8-bit machine?

Correct. Although this will eventually get rolled into the 8bit version, once we get the hardware available. This code is currently using 16bit data port access, and we can't do that without some hardware trickery on an 8bit machine. All I need to do is tweak the read and write routines and this will be ready to roll on whatever hardware we come up with.

This version will work on any 286 or higher only, and requires a standard IDE controller (at base address 1F0). My test platform was a 486.



> What happened with the TSR, version?

The crux of the problem was that DOS, upon booting, goes and gets the drive parameters from INT13 and then never gets them again. This is done before any TSR or even device driver could get loaded and hook INT13. So I needed something to get in before the operating system loaded, and it was either write a boot sector loader, or switch to loading in at POST through an option rom.

It's possible that Extended INT13 support, which would allow for drives > 8.4g to be used, could be loaded in as a TSR after boot, but that would also require freeDOS or some other E-INT13 aware operating system to be used.
[I don't know if those calls are done during boot on freeDOS, so we might be in the same boat]

I also tried a device driver, but there were lots of legacy rules to follow there, and it didn't look like there was going to be support for drives larger than 2gig there.

This is only the first round in what I hope to be a suite of software solutions. I'd even like to someday write that boot sector loader so you wouldn't even need an option ROM to make this work.

Terry Yager
December 15th, 2008, 02:57 PM
Good work, Hargle.

You're a credit to the, ummm, what did you say you did again? LOL

Seriously though, your hard work won't soon be, umm, what was I saying?

Pass it, Bogart!

--T

bobwatts
January 3rd, 2009, 01:52 PM
Hi Gang !

It's a new year ( not that I really care much about that kind of stuff. I'm usually annoyed to be woken up by silly humans setting off bombs in my neighborhood at 12AM Jan 1 ), and I was getting curious to know if there was any progress on the XT IDE controller project.

I know that I have one of the Worlds Most Advanced XT computers with a huge gapping hole where the Acculogic XT IDE controller used to be. :-D

Not that I'm complaining.....I have lots of stuff to keep me occupied, most of which are off topic for this forum. Herding gerbils on the wide open plains of Death Valley Ohio USA for example. Had to put off getting my Metro over 75MPG now that gasoline is so cheap. 61MPG will have to do. :twisted:
Soldering capacitors is always exciting. Inventing a holographic televison is really keeping me busy. And now that Einsteins Theory of Relativity has been proven (again) ( I wonder when they will call it Einstiens Axiom? ) I can put down my chalkboard.

So what's up with the project ?

bobwatts
EartH

Druid6900
January 3rd, 2009, 07:32 PM
Pretty much nothing for the last few weeks. Holiday season, ya know.

I'm going to ship your card back to you though, as it seems that we are not going to be cloning it.

hargle
January 4th, 2009, 02:24 PM
i too have been off on holiday til today, but will be re-focusing efforts again shortly.

My next trick is to come up with a DMA+IRQ version of the option ROM, so if/when we go that route, I'll have the basic stuff ready to drop into some hardware.

Prior to my break, i'd asked one of my hardware co-workers to help me put together a bill of materials for a shopping trip to one of those component sites, but nothing has come of it yet. I want to frankenstein together one of those linux-IDE controllers for playing, and then I can work on adding the physical option ROM to it.

hargle
January 9th, 2009, 12:22 PM
Pretty much nothing for the last few weeks. Holiday season, ya know.
I'm going to ship your card back to you though, as it seems that we are not going to be cloning it.

Has this card been shipped yet?
Any way I can intercept it?

My co-worker wants to take a look at it and see how some of the bits are done, like how the voltage planes are split and stuff like that.

I'm not sure how much help i can get outta my co-workers, but i'll take anything i can get. Our workload here varies from week to week, so there's a chance we can still get some professional hardware help from some of these old-timers here.

Edit: oh, and i've got a shopping list to create the tilman reh design that I'm hopefully going to get done next week.
I'm then thinking about trying to do one of those copper etch boards instead of hand-wiring it, entirely because that's still a LOT of soldering to throw all those wire together... Of course I've never done an etch before, but I've heard they're pretty easy to do.

Druid6900
January 9th, 2009, 12:25 PM
No, I haven't shipped it yet, I was waiting to hear back from BobWatts.

I haven't done anything with it as I was under the impression we were taking a different route on this project.