PDA

View Full Version : 8-Bit IDE Controller



Pages : 1 [2] 3 4 5 6

bobwatts
January 9th, 2009, 02:24 PM
Hi Gang !

Well......... I guess it's a good thing I didn't reply....... didn't think it was necessary, just been waiting by my mailbox........glad the vigil is over, I was getting hungry.:o

Do what you godda do.

By the way, the day after you posted you were sending the card back, I couldn't get to work. I work across the street from the PO, and we weren't allowed in the building. Seems there was a "suspicious package", and it had been moved outside because it was "smoking'.

Well, after hours ( hell, I went home ) of waiting, dozens of police officers, dogs, and the bomb squad shows up ( VERY IMPRESSIVE stuff they brought before I left ), they blew up the "package", and all was ok. I was real glad to see that it was apparently a kerosene heater, and not my Acculogic card.
Who woulda thunk that a K-1 heater would stay lit all the way from Washington state ! :twisted:

True.

bobwatts
EartH

NobodyIsHere
January 9th, 2009, 07:26 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.

Hi Hargle!

Have you settled on a circuit? If not, I was going to recommend just getting an ISA prototype board and rigging up a prototype of the XT-IDE circuit. Is that the same as the Linux-IDE controller you are referring to? The XT-IDE is plain 74xx TTL chips and could be done relatively easily.

I would make that work with your software even if it is only loaded as a loadable driver at first. Just getting those steps completed would be a big risk reduction for your project, I think. If nothing else, having some photos is a big boost!

Before I send a PCB to a manufacturing order, I build a prototype at least somewhat representative of the circuit, write some limited software for it, and then capture the design for a PCB. You could place the ROM circuit on to the ISA prototype board at a later date and further test it then.

The main appeal of the XT-IDE circuit, at least to me, is it is simple and would be relatively easy to build on an affordable prototyping board. It may not be the greatest performer ever but at least it'll work decently.

I am going through this process right now with a Zilog Peripherals board. I have a general idea of what I would like to do based on a magazine article. I've modified the design for my system and am building a prototype on a prototyping board in the workshop. Once it is working sufficiently, I'll write some demonstration software to show the hardware works and go to PCB manufacturing with it. You may want to use a similar process on your project.

IMO, it really pays to build the prototype before ordering PCBs. Even with the best intentions some bugs will slip through but making a prototype really catches most. What gets through is usually cosmetic or easily fixed not some major design issue. At least that's my experience.

I hope this helps. Good luck with your efforts! I wish you all the best success!

Thanks and have a nice day!

Andrew Lynch

justjunk
January 10th, 2009, 09:36 PM
I have been reading this thread with great interest. Any chance I could get one of these when they get built? Thanks.

hargle
January 11th, 2009, 08:57 AM
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.

ok, i've sent you a PM with my address, after my co-worker has finished examining it, I'll return it to its rightful owner.

(thanks bob for letting us use it for so long)

I think it's still useful, especially if there are things to learn from how the option ROM is decoded. I can also use it to see if my option ROM can be tweaked slightly to be used as a replacement ROM for that board to break 528MB barrier, which would be my "gift" to bob for letting us use the card.

Should be easy to do.

hargle
January 11th, 2009, 09:12 AM
Hi Hargle!

Have you settled on a circuit? If not, I was going to recommend just getting an ISA prototype board and rigging up a prototype of the XT-IDE circuit. Is that the same as the Linux-IDE controller you are referring to? The XT-IDE is plain 74xx TTL chips and could be done relatively easily.


I torn between getting a prototyping board and then hand wiring all the connections (that's a LOT of work, especially someone with limited soldering skills) and trying out one of those etch kits to prototype it. Having never done either, I don't know the ins and outs of each. maybe a combination of the two. Anything that will save me from hand soldering all the lines to/from each part (the monkeywork) will help.

What I want to do is build either the linux (XT-IDE) or the tilmann reh design, and then attempt to add an option ROM to the schematic by augmenting my prototype card. Since the option rom is essentially a separate component of the circuit, it really shouldn't matter which design I use. Either design will cause minor changes to the software, but that's to be expected.

The Reh design is (IMO) better because it's using 512 single IO read/writes to do the data transfer instead of separating the data into pairs on different IO ports. That should lend itself to doing DMA transfers, which is the ultimate goal for this project.

The main concern I have now is just getting a card built. Any card! I'll hand wire the option rom stuff to it once the card itself is up, and then hand wire whatever DMA circuitry is required after the option ROM circuit is debugged.

I'm relying on my co-worker(s) to help with the schematic and bill of materials, since this is old hat to them, and druid is too busy. Collectively, I believe I have all the stuff I need, it's just the first hardware hurdle that is holding me back at the moment.

bobwatts
January 11th, 2009, 09:21 AM
Hi Jeff !

Just wanted to let you know that I monitor the forum daily, and like being kept abreast ( or any breast ) of developments. Don't mistake my lack of postings for dis-interest, it's just that I am in the (slightly unusual) position of being unable to be of much help.
It's good to see that you are very enthusiastic about the project !

bobwatts
EartH

NobodyIsHere
January 11th, 2009, 03:43 PM
I torn between getting a prototyping board and then hand wiring all the connections (that's a LOT of work, especially someone with limited soldering skills) and trying out one of those etch kits to prototype it. Having never done either, I don't know the ins and outs of each. maybe a combination of the two. Anything that will save me from hand soldering all the lines to/from each part (the monkeywork) will help.

What I want to do is build either the linux (XT-IDE) or the tilmann reh design, and then attempt to add an option ROM to the schematic by augmenting my prototype card. Since the option rom is essentially a separate component of the circuit, it really shouldn't matter which design I use. Either design will cause minor changes to the software, but that's to be expected.

The Reh design is (IMO) better because it's using 512 single IO read/writes to do the data transfer instead of separating the data into pairs on different IO ports. That should lend itself to doing DMA transfers, which is the ultimate goal for this project.

The main concern I have now is just getting a card built. Any card! I'll hand wire the option rom stuff to it once the card itself is up, and then hand wire whatever DMA circuitry is required after the option ROM circuit is debugged.

I'm relying on my co-worker(s) to help with the schematic and bill of materials, since this is old hat to them, and druid is too busy. Collectively, I believe I have all the stuff I need, it's just the first hardware hurdle that is holding me back at the moment.

Hi Hargle! The issue, I think, which makes the XT-IDE a good choice is that it already has an 8 bit ISA interface. The Tilmann Reh IDE design is great, he is an extremely talented designer, however, it is for the ECB. It is not a simple conversion to reimplement the bus interface from ECB to ISA. The signals are all different and will require conversion and translation. That will require glue logic design and unless someone has a ECB to ISA bridge circuit available you are looking at actually two developments; one for the bridge and another to get the ECB IDE circuit working. That it lacks 8088 driver software doesn't help matters either.

The XT-ISA interface is already designed for a PC ISA bus and there is a schematic and driver software available. Once the basic system is working it could probably be easily modified to include an option ROM. Possibly it could be tweaked to put the IO ports adjacent but I would build per design first to understand it before attempting to modify its operation.

Point to point soldering construction methods aren't nearly as bad as you might think. I use it all the time. Yes, the prototypes can get messy and complicated but for a simple circuit like that you won't have problems. There are few chips and if you space things out and use sufficient wire lengths it should be fine. The ISA prototype boards are relatively cheap too.

I can't say I would recommend going with an etch PCB or having PCB manufactured ($80 for two typically) without building a working prototype. Some experienced designers (not me either, there is no way I'd go straight to PCB) can pull that off but most hobbyists should be making prototypes to verify their design is valid before dumping $$$ into a PCB. Making an etch PCB can be cheaper but you'll still need a schematic capture and PCB design phase and an investment in tools and materials. It may be cheaper to just get some bare bones prototype PCBs (https://www.barebonespcb.com/!BB1.asp) but they'll run about $80 to $100 depending. If you have to respin the PCB it be that much again.

Does the XT-IDE schematic make sense to you? Maybe a good first step would be a schematic capture in a free tool. Then do PCB layout and validate your design by analysis. You could use Eagle, gEDA, or KiCAD. Personally, I like KiCAD and its free for any size PCB but picking which EDA is best is almost a religious preference so I'll leave that alone.

I hope this helps. Please don't get discouraged if it takes a long time and is frustrating. I just made the PCB manufacturing order on the DiskIO board (IDE and FDC) for the N8VEM project and its started its design and prototype phase in April 2007. It got so frustrating I put it on hold for a few months but when I picked it back up again this summer and started working on it again it took another 5 months to get this far. I suspect the Zilog Peripherals board is going down a similar path but hopefully won't be *that* bad.

Thanks and have a nice day!

Andrew Lynch

hargle
January 12th, 2009, 07:05 AM
Hi Hargle! The issue, I think, which makes the XT-IDE a good choice is that it already has an 8 bit ISA interface. The Tilmann Reh IDE design is great, he is an extremely talented designer, however, it is for the ECB. It is not a simple conversion to reimplement the bus interface from ECB to ISA.

ah, that is a deal breaker then. unless my co-worker can come up with a solution there, then the reh design is out. (he did respond to my email searching for him, but didn't respond back when I told him what we were up to, so I likely can't even get support from him)

The linux/XT-IDE design is the light then.



Point to point soldering construction methods aren't nearly as bad as you might think.

thanks for the courage! I spent some time looking at etch kits this weekend, and they look pretty nasty actually. I don't like the chemicals.




Does the XT-IDE schematic make sense to you? Maybe a good first step would be a schematic capture in a free tool. Then do PCB layout and validate your design by analysis. You could use Eagle, gEDA, or KiCAD. Personally, I like KiCAD and its free for any size PCB but picking which EDA is best is almost a religious preference so I'll leave that alone.

I'll give those a shot. I was really hoping that I wouldn't be the one to do the hardware work, but I seem to be the only one with enough free time (or stupidity!) to do it. I am 100% dedicated to the project though, and have already made enough headway to keep me motivated through this learning curve. The schematics don't really make sense to me, but I haven't focused on them either. I have zero electronics background knowledge, but I do have 15 years of software background working on low level hardware designs, so I can muddle through, plus I know who to ask around here to get info I need.

I'm going on a shopping trip this week with my hardware co-worker to a local electronics store, so perhaps I can find all the parts I need and I'll get to work with the soldering iron. No matter what, by the end of this week, I will have at least ordered the parts I need to build that XT-IDE design.

NobodyIsHere
January 12th, 2009, 06:21 PM
Hi Hargle,
I figured you could use a little boost so here is a start. The only thing I guarrantee on this is that it is wrong and needs more work. Surely it needs thorough review and some discussion. Good luck with your project!

Thanks and have a nice day!

Andrew Lynch

http://n8vem-sbc.pbwiki.com/f/XT-IDE.zip

PS, we need a file upload section!

Druid6900
January 12th, 2009, 06:38 PM
Actually, all I've been waiting for is someone to work the option ROM into the schematic.

Now, a third option for bread-boarding something is one of those stand-alone, self-powered boxes with the regulated rails. I used to have several of them (Heathkit, I believe) but auctioned them off long ago.

You place the components, use little flexible wires for power and chip interconnects and screw around until you get your theoretical outputs from your theoretical inputs.

I used to use a (dead) 8-bit card connector with wires soldered to the lands in a working computer or the 8-bit section cut off a 16 bit dead card as my signal source.

NobodyIsHere
January 13th, 2009, 02:49 AM
Hi Richard!

A couple of warnings about the circuit I posted. The 74520 is unobtainium so I substituted a 74LS688. They should be similar but somebody has to compare the datasheets to be sure. Also, for each chip someone has to get the datasheets and compare them against the original schematic and how they are in the circuit to make sure they are connected right. I am doing this all pretty much from memory and things get scrambled pretty easily.

OK, lets think about the ROM option. I don't know what you want for a ROM and I am not a PC designer so this is probably wrong. However, if we start with an 8KB 27C64 EPROM for a CPU to read its contents we need 4 things; a memory decode signal (chip select), a output enable signal, address, and data.

Starting with the memory decode signal, I propose another 74LS688 since it is simple. Put A13-A19 and *MEMR on one side and another 8 position DIP switch on the other. Use the /P=Q output as your memory decode signal. I am unsure if the memory decode should be qualified with *MEMR or not and it may screw up the timing. Like I said, I am not a PC designer so we'll need some technical review from knowledgeable people with PC design experience.

For the 27C64 output enable, just use *MEMR

For address connect A0-A12 to the appropriate pins on the 27C64. I'd tie /PGM high and leave the VPP pin unconnected.

For data connect D0-D7 to the input gates on a 74LS244. Hook the output enable of the 74LS244 attach the memory decode signal (27C64 chip select)

I can pretty easily update the design I posted last night with these changes as it only adds 4 new parts. However this does not settle the more basic issue of whether it works or not. IMO the only way to really know if the design it works or not is to build a hardware prototype and test it.

I am busy already building a wire wrap prototype for the N8VEM Zilog Peripherals board. Thats going to take a while and in the meantime someone can pick up the ball on the design that's available.

If someone is flush with cash and feeling like gambling they could just do some checks on the updated circuit and have some low cost prototype PCBs made for testing. Those are some $100 per hand bets so that option is not for the meek or weak of heart. It surely not an option for me!

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
January 13th, 2009, 03:47 AM
Hi Hargle,
I figured you could use a little boost so here is a start. The only thing I guarrantee on this is that it is wrong and needs more work. Surely it needs thorough review and some discussion. Good luck with your project!

Thanks and have a nice day!

Andrew Lynch

http://n8vem-sbc.pbwiki.com/f/XT-IDE.zip

PS, we need a file upload section!

Hi! I did a quick paper review of the circuit and noticed the outputs on U7 are all screwed up. I fix that tonight when I add the ROM circuit.

Also, the original schematic uses the same net name for different signals which I partially fixed but just discovered another case (A0-A2)

Thanks and have a nice day!

Andrew Lynch

PS, you can double check the simple ROM reading circuit against this neat little board (http://www.heise.de/ct/projekte/flasher/flash_en.shtml)from C'T Projekt. Based on a quick glance I think it would work. Changing from 27C64 to a larger size is no problem but going any smaller than a 27C32 would be tougher.

NobodyIsHere
January 13th, 2009, 08:25 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

Hi! Would you please do me a favor and verify that the MK 36000-4 ROM mentioned in the document is in fact a 27256 or compatible EPROM? I recall the IBM PC/XT used non-standard mask ROMs on its motherboard and I would like to be sure that is not also happening here as well.

I believe your instructions for making the ROM appear in the memory space are correct but I would like to double check in case there is any IBM funny business happening.

Please post a photo of the Xebec IBM fixed disk adapter and the ROM if possible.

Thanks and have a nice day!

Andrew Lynch

per
January 13th, 2009, 08:42 AM
Hi! Would you please do me a favor and verify that the MK 36000-4 ROM mentioned in the document is in fact a 27256 or compatible EPROM? I recall the IBM PC/XT used non-standard mask ROMs on its motherboard and I would like to be sure that is not also happening here as well.

I believe your instructions for making the ROM appear in the memory space are correct but I would like to double check in case there is any IBM funny business happening.

You're reffering to the PC, not the XT. However, since your card has its own memory adress decoder for the ROM, it wouldn't matter anyway. As long as the data is pushed onto the adress lines when the CPU expect it, it'll work.

hargle
January 13th, 2009, 09:57 AM
wow, thank you andrew. that was quite a kick to start seeing actual (non ascii) schematics for this thing! I'll pass them off to my HW co-workers here and see what they have to say. I've also downloaded kicad to play with it.

As for ROMs, is it possible that we can use a more modern ROM in the design?
I would love it if it could be an EEPROM, so that i can then write an update utility for it for any BIOS changes that come along. (provided it's even possible to do the software mechanism to erase and program it on an 8088.) I was thinking a jumper to enable writes and deliver power to vpp.

Since i don't have an UV eraser handy, I'd hate to be stuck with clunky old ROMs that I can't re-program.

I also only need 4k of ROM space. I've only used about 3k in code so far, and the code base itself is pretty complete.
Of course, if you give me 8k, i won't complain.

per
January 13th, 2009, 12:25 PM
wow, thank you andrew. that was quite a kick to start seeing actual (non ascii) schematics for this thing! I'll pass them off to my HW co-workers here and see what they have to say. I've also downloaded kicad to play with it.

As for ROMs, is it possible that we can use a more modern ROM in the design?
I would love it if it could be an EEPROM, so that i can then write an update utility for it for any BIOS changes that come along. (provided it's even possible to do the software mechanism to erase and program it on an 8088.) I was thinking a jumper to enable writes and deliver power to vpp.

Since i don't have an UV eraser handy, I'd hate to be stuck with clunky old ROMs that I can't re-program.

I also only need 4k of ROM space. I've only used about 3k in code so far, and the code base itself is pretty complete.
Of course, if you give me 8k, i won't complain.
EEPROMs are nearly identical to the EPROM. If the EEPROM is protected (by a special page-write), it can actually be used in place of an EPROM of the same size!

hargle
January 13th, 2009, 02:03 PM
EEPROMs are nearly identical to the EPROM. If the EEPROM is protected (by a special page-write), it can actually be used in place of an EPROM of the same size!
yeah, i was thinking there may be issues with finding an eeprom small enough to work on our hardware. i mean most of the common sizes of eeproms now are bigger than our main memory size! :)

Even though eeproms can be accessed in blocks and pages, there may still be weird addressing quirks trying to decode it off the bus. i dunno.

I just think being able to software-update the BIOS is something I'm really going to want to do, especially since the code is open source.

per
January 13th, 2009, 02:28 PM
yeah, i was thinking there may be issues with finding an eeprom small enough to work on our hardware. i mean most of the common sizes of eeproms now are bigger than our main memory size! :)

Even though eeproms can be accessed in blocks and pages, there may still be weird addressing quirks trying to decode it off the bus. i dunno.

I just think being able to software-update the BIOS is something I'm really going to want to do, especially since the code is open source.

I did some investigating after I bought a 28C256 EEPROM off Ebay. I wanted it just in cause I would write some own code for my XT's BIOS some time in the future.

EEPROMs can be found in most of the same sizes as EPROMs. I mean 8Kb, 32Kb, 128Kb, etc...

The only difference between EPROMs and EEPROMs is that the EEPROM got the number "28" instead of "27" (as for EPROMs), and a "Write Enable" active-low line (usually NC on EPROMs smaller and equal to 32Kb). You operate a EEPROM just like a block of DRAM, to enable the chip, just putt _ChipSelect low (by using a demultiplexer [74LS138] tied to the desired adress lines [in your cause, ]), and put _OutputEnable low to output the byte at the addres from the adress lines. Put _WriteEnable low to write the data from the data lines to the adress from he adress lines. You would problably need a bidirectional Bus Transchiver [74LS245] on the data signals to seperate input and output, and you would tie that to either the _WE or _OE signal (depends on what side you use for input/output).

per
January 13th, 2009, 02:52 PM
Here is a sample adress decoder (for the 32Kb Chip).



74LS138
[---U---] Jp1
A15 -----[a y0]-[//]-+
A16 -----[b y1]-[//]-+
A17 -----[c y2]-[//]-+
[ y3]-[//]-+
A18 -|>0-[g2a y4]-[//]-+
A19 -|>0-[g2b y5]-[//]-+
VCC -----[g1 y6]-[//]-+
[ y7]-[//]-+
[-------] Jp8 |
+-|>o- _CE

ROM size = 32Kb

Base adress (when jumper on):
Jp1=C000:0000
Jp2=C800:0000
Jp3=D000:0000
Jp4=D800:0000
Jp5=E000:0000
Jp6=E800:0000
Jp7=F000:0000
Jp8=F800:0000


Leaving more than one jumper on makes the data appear more than once (one time for every jumper) at different base adresses.

NobodyIsHere
January 14th, 2009, 03:27 AM
Hi!

I updated the zip file with new information. The schematic has been cleaned up and reorganized. Several errors have been corrected and some new features added. The design now includes a boot ROM which is a 28C64 style EEPROM. The EEPROM is reprogrammable while in the circuit. The IO address for the device is programmable by switches. The memory address for the ROM is programmable by switches. There is a jumper to enable/disable the ROM.

As you can see, even a minor increase in functionality which only added three chips has had a dramatic increase in complexity of the PCB. I did several designs last night before settling on this compromise. The good news is that the autorouter is able to complete on this layout and is presently doing an optimization run. I'll add the fill zones back in once the optimizer has had a chance to simplify the trace routing.

On a completely different topic:

My intent here was not to take over this project just to give it a little boost since it appears that might be helpful. Obviously everyone has limited time and resources. The design is I think solid but it appears no one has the capacity to do a prototype. That means proceeding with a PCB is high risk in my opinion due to the likelihood of a hidden flaw.

I have been thinking of some ways to do this but without the normal prototype design verification step. There has to be some mechanism to spread the risk so no one person spends their own money and gets stuck with a batch of PCBs that don't work and can't sell. Taking advanced orders is absolutely a non-starter due to the recent disasters associated with that approach. Accepting money in advance such a bad idea I consider it a fatally flawed and I don't want any part of it or even to be associated with a project that does.

Here is the big risk I see with this due to a lack a prototype phase. Someone spends their money, orders the PCBs and ships one to the first hobbyist. The hobbyist builds it and discovers the hidden design flaw and announces it to the world that the board is bad. Naturally, all subsequent orders will be canceled or not placed. The person who ordered the PCBs is stuck with a box of unusable and unsellable PCBs with no way to recover.

However, there may be another way to do this. This may be optimistic but just consider it approach for a moment. I call it the "all for one; one for all" method. It is a PCB ordering approach to risk mitigation which limits the "first finder" risk. Someone does the analysis, takes the lead, and decides on a PCB *fixed* price in advance. Get a list of interested hobbyists and make sure there are enough to make a feasible order. Place the order and when the PCBs arrive, announce they are available. Orders and payments come in as they do but no cancelations or refunds due to known risks. The PCBs packages go into a box and do not ship to anyone until there are enough to cover the persons investment in the order. If insufficient orders come in to cover the expenses, no one gets anything and everyone loses their money. In other words, no one gets any PCBs until enough people have bought them to cover the investment. Every hobbyist takes a gamble with their money and may lose it and get nothing if others back out. All get to share in the risk of discovery if there is a problem with the design. As for the PCB, it may work, it may not, it may catch on fire and/or turn you into a chicken but everyone finds out at the same time or no one does.

In my experience, going with a PCB design usually works. If it has problems they tend to be cosmetic or at least fixable with "cuts and jumpers". However, I normally prototype the designs before ordering so I have a pretty good idea what it is supposed to do in the first place. That isn't the case here. The design is fairly common to one I have already done on the N8VEM project and I know that works just fine. It is the peculiarities of the PC architecture that makes things complicated.

I've given this some thought and am considering doing this project regardless of its known issues. Please don't propose ideas unless you are willing to take the lead and implement! Its easy to spend other peoples money without your own personal risk!

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
January 14th, 2009, 04:48 AM
wow, thank you andrew. that was quite a kick to start seeing actual (non ascii) schematics for this thing! I'll pass them off to my HW co-workers here and see what they have to say. I've also downloaded kicad to play with it.



Hi! Thanks! Its no problem. I am just trying to help. You have a good idea and this deserves to work as its needed for vintage computers. Making it happen is another story!




As for ROMs, is it possible that we can use a more modern ROM in the design?
I would love it if it could be an EEPROM, so that i can then write an update utility for it for any BIOS changes that come along. (provided it's even possible to do the software mechanism to erase and program it on an 8088.) I was thinking a jumper to enable writes and deliver power to vpp.



Fixed. Design now includes 28C64. It is in circuit reprogrammable and doesn't require special voltages. Here is the datasheet

http://www.datasheetcatalog.org/datasheets/320/181600_DS.pdf






Since i don't have an UV eraser handy, I'd hate to be stuck with clunky old ROMs that I can't re-program.

I also only need 4k of ROM space. I've only used about 3k in code so far, and the code base itself is pretty complete.
Of course, if you give me 8k, i won't complain.

Actually 8KB is as small as you are going to get in practical terms and probably the best balance. Going smaller is more difficult since it requires more logic to decode the memory in finer detail. Also, 28C64 is the smallest practical EEPROM part that will work IMO. You could use a 28C16 but that is only 2KB, uses 24 pin sockets, and aren't really common anymore. Atmel did make a 28C32 once but they are unobtainium now. The other benefit of the 28C64 is it uses 28 pin socket which is very common. If a larger ROM is needed like 32KB a chip could put in there but the design would have to be modified (cuts and jumpers or PCB respin) to add the additional address lines.

For a basic boot ROM style device for simplicity's sake, I would just use the 8KB part and it would be good enough. Adding jumpers/switches for more than that adds PCB complexity without value.

Thanks and have a nice day!

Andrew Lynch

per
January 14th, 2009, 05:13 AM
Hi! Thanks! Its no problem. I am just trying to help. You have a good idea and this deserves to work as its needed for vintage computers. Making it happen is another story!



Fixed. Design now includes 28C64. It is in circuit reprogrammable and doesn't require special voltages. Here is the datasheet

http://www.datasheetcatalog.org/datasheets/320/181600_DS.pdf




Actually 8KB is as small as you are going to get in practical terms and probably the best balance. Going smaller is more difficult since it requires more logic to decode the memory in finer detail. Also, 28C64 is the smallest practical EEPROM part that will work IMO. You could use a 28C16 but that is only 2KB, uses 24 pin sockets, and aren't really common anymore. Atmel did make a 28C32 once but they are unobtainium now. The other benefit of the 28C64 is it uses 28 pin socket which is very common. If a larger ROM is needed like 32KB a chip could put in there but the design would have to be modified (cuts and jumpers or PCB respin) to add the additional address lines.

For a basic boot ROM style device for simplicity's sake, I would just use the 8KB part and it would be good enough. Adding jumpers/switches for more than that adds PCB complexity without value.

Thanks and have a nice day!

Andrew Lynch

Do you think it would be smart to add an 74LS245 Bidirectional transcheiver to the outputs from the ROM? connect the /WE from the ROM to the DIR line of the transchiver, /CS to /E, and let D0 - D7 from the EEPROM go to A1-A8, and connect B1-B8 to the data bus.

A jumper to prevent writes would also be nice (tie /WE to VCC instead of /MEMW).

NobodyIsHere
January 14th, 2009, 07:06 AM
Do you think it would be smart to add an 74LS245 Bidirectional transcheiver to the outputs from the ROM? connect the /WE from the ROM to the DIR line of the transchiver, /CS to /E, and let D0 - D7 from the EEPROM go to A1-A8, and connect B1-B8 to the data bus.

A jumper to prevent writes would also be nice (tie /WE to VCC instead of /MEMW).

Hi! Initially I considered making a 244 buffer/245 bus transceiver on the ROM's data bus. However, I found a circuit from the C'T project (http://www.heise.de/ct/projekte/flasher/flash_en.shtml)(there is a URL in a previous post) and they are attaching their Flash ROM directly to the data bus without any buffering so now I don't think its necessary.

It'd be simple enough to do but adds to the part count and complexity of the PCB. For the most part, the EEPROM will be read-only and only rarely written too. I'd just as soon keep it as simple as possible and not add things unless its absolutely necessary to keep costs low and reduce the chance of errors sneaking in.

Regarding the write protection, I think the way to go on that is to use the "software data protection" feature of the 28C64 chip. There are more details in the 28C64 datasheet. That'll be one less part and provide most if not all the benefits of a hardware write protect jumper. Personally, I would just use a 2764 if I were concerned about inadvertent writes.

Thanks for the review and you are doing a great thing. Keep pressing the review of the schematic and ask questions. I have been doing my own review and have found another series of bugs which need to be fixed. I'll roll those in tonight and repost another PCB. Be sure to read the XT-IDE schematic, software, and other text for clues as to missing bits, broken parts, logic flaws and the like. I have no doubts they are in there so it improves everyone's chance of success if we find them now.

Thanks and have a nice day!

Andrew Lynch

PS, I double checked the Xebec/IBM hard drive controller schematic and it places its ROM directly on the data bus without buffering/bus transceiver as well.

hargle
January 14th, 2009, 07:36 AM
wow, things are certainly rolling now. I'm having a hard time keeping up!
Thanks Andrew for putting some of your precious hours into it and getting us closer.

I've passed your latest schematic off to my hardware guy here for comments, and i'm also going to see if kicad can output the design into a format that he can import and work with here, so then it could go right into the hands of our design and layout team. (tee hee)

As far as prototypes go, I'm certainly willing to shell out a couple hundred bucks for initial parts runs and a prototype board or two, just to make sure the design works before we pull the big trigger and make a batch of PCBs. I don't need any pre-order money to get started. I can also recoup some of the R&D costs from selling the kits, since i'm going to be handling orders, at least in the USA. Money is not a concern, within reason of course.

I'll check out that 28C64 datasheet and start investigating a flash program.
I have access to a burner at work (as well as a full debug lab with scopes and logic analyzers) so we're good to go to make this thing happen.

i'm really excited about this thing now... time to go shopping for a prototype card and some parts.


BTW: kicad is complaining about not having o_memory.lib and dips-s.lib when I try and open it. Can you put those in your next zip?
Thanks!

update: never mind. I found those libraries using this: http://per.launay.free.fr/kicad/kicad_php/composant.php

NobodyIsHere
January 14th, 2009, 08:23 AM
Hi Hargle!

If you are going to make prototypes please note the design is not complete, has known problems, and needs a lot more in depth review before its ready for any PCB being made. I will cut in the new stuff and repost tonight. Its not much but important.

One thing that would help is finding some of the senior members on this forum with actual PC design experience to help out. I think M Brutman and/or Chuck G may be able to help. There are probably others as well. Additional technical reviews would mitigate risk of hidden flaws sneaking through.

Thanks and have a nice day!

Andrew Lynch

per
January 14th, 2009, 08:24 AM
Hi! Initially I considered making a 244 buffer/245 bus transceiver on the ROM's data bus. However, I found a circuit from the C'T project (http://www.heise.de/ct/projekte/flasher/flash_en.shtml)(there is a URL in a previous post) and they are attaching their Flash ROM directly to the data bus without any buffering so now I don't think its necessary.

It'd be simple enough to do but adds to the part count and complexity of the PCB. For the most part, the EEPROM will be read-only and only rarely written too. I'd just as soon keep it as simple as possible and not add things unless its absolutely necessary to keep costs low and reduce the chance of errors sneaking in.

Regarding the write protection, I think the way to go on that is to use the "software data protection" feature of the 28C64 chip. There are more details in the 28C64 datasheet. That'll be one less part and provide most if not all the benefits of a hardware write protect jumper. Personally, I would just use a 2764 if I were concerned about inadvertent writes.

Thanks for the review and you are doing a great thing. Keep pressing the review of the schematic and ask questions. I have been doing my own review and have found another series of bugs which need to be fixed. I'll roll those in tonight and repost another PCB. Be sure to read the XT-IDE schematic, software, and other text for clues as to missing bits, broken parts, logic flaws and the like. I have no doubts they are in there so it improves everyone's chance of success if we find them now.

Thanks and have a nice day!

Andrew Lynch

I see that usingthe 74LS688 is a great advantage as of it supports more than just 8 different memory bases (as my version does). However, the Adress Enable is actually only used to make I/O devices aware of that the DMA chip is using the bus, so it won't dissable the ROM by using this. Using one of the power lines + resistor on the /CE signal instead would be a great idea.

Just if anyone are interested, I have attached my version to this thread (this time it is the full thing, not just the adress decoder).

NOTE: I really don't know how to add Capacitors (yet), and how many I should add of what streinghts, so the schematics are without any capacitors. If you ever try to make it into a card, make sure to add capacitors. I don't either know if I should add resistors and where to add them.

Jumper settings:
Jp1: Base adress
1-2 = C0000
3-4 = C2000
5-6 = C4000
7-8 = C6000
9-10 = C8000
11-12 = CA000
13-14 = CC000
15-16 = CE000

Jp2: Writes
1-2 = Enabled
2-3 = Disabled

Jp3: ROM
1-2 = Enabled
3-4 = Disabled

Keep up the good work! :D

hargle
January 14th, 2009, 09:51 AM
If you are going to make prototypes please note the design is not complete, has known problems, and needs a lot more in depth review before its ready for any PCB being made. I will cut in the new stuff and repost tonight. Its not much but important.


loud and clear.
my HW guy here says that he'll take your final schematic and bring it into our tools and give it a review. we collectively here have created everything from PC motherboards to plug-in cards to custom circuit boards, so I think we've got the skillset to catch any design flaws. The only issue is getting any old ISA cobwebs cleared out, since it's been a long time since any of those guys have done that sort of work. :)

NobodyIsHere
January 14th, 2009, 12:05 PM
I see that usingthe 74LS688 is a great advantage as of it supports more than just 8 different memory bases (as my version does). However, the Adress Enable is actually only used to make I/O devices aware of that the DMA chip is using the bus, so it won't dissable the ROM by using this. Using one of the power lines + resistor on the /CE signal instead would be a great idea.



Hi! I am not understanding your comment. The U9 74LS688 is tied to AEN which is an active high signal so it should be low except when DMA has control of the bus. Then the ROM should not be present since the memory decode logic will not generate a ROM chip select signal. There is a 10K ohm pull up resistor tied to the /G input on the U9 74LS688 so that if the ROM enable jumper is not present the /G will always be high. What am I missing?

In the IBM hard drive controller (Xebec) they use a similar circuit but instead they tie the memory decode 74LS688 /G pin to GND. The results should be similar except when DMA is active the ROM should not be in the memory space.

I am getting my definition of AEN from here:

http://www.techfest.com/hardware/bus/isa.htm

AEN
Address Enable is used to degate the system microprocessor and other devices from the bus during DMA transfers. When this signal is active the system DMA controller has control of the address, data, and read/write signals. This signal should be included as part of ISA board select decodes to prevent incorrect board selects during DMA cycles.







Just if anyone are interested, I have attached my version to this thread (this time it is the full thing, not just the adress decoder).

NOTE: I really don't know how to add Capacitors (yet), and how many I should add of what streinghts, so the schematics are without any capacitors. If you ever try to make it into a card, make sure to add capacitors. I don't either know if I should add resistors and where to add them.

Jumper settings:
Jp1: Base adress
1-2 = C0000
3-4 = C2000
5-6 = C4000
7-8 = C6000
9-10 = C8000
11-12 = CA000
13-14 = CC000
15-16 = CE000

Jp2: Writes
1-2 = Enabled
2-3 = Disabled

Jp3: ROM
1-2 = Enabled
3-4 = Disabled

Keep up the good work! :D

There are a mix of pull up and pull down resistors in the circuit

R1 is a current limiting resistor for the activity LED (probably should be 270 but you can put in anything you'd like. 151 ohms means the LED will be bright enough read by at night and will have a shortened life)

R2 is 10K pull up resistor for the U9 74LS688 /G pin to ensure it is always high unless something is actively pulling it down (AEN does normally)

R3-R5 are pull down resistors for the IDE interface itself. Ensures those pins are low unless something actively pulls them up.

R6 is a pull up resistor for the IDE interface pin.

Each integrated circuit gets a 0.1uF ceramic or monolithic filter/bypass capacitor across Vcc to GND to smooth out voltage spikes, noise, etc due to switching. TTL ICs are notorious for generating high frequency garbage that the filter/bypass capacitors soak up.

There is a system filter/bypass capacitor across VCC and GND to catch any incoming or outgoing spikes, noise, bus garbage, etc. Really any electrolytic capacitor 10-100 uF will work here although low ESR is probably better.

Hopefully that explains what I am doing on the circuit.

Have you started actually laying out a PCB? The board is small only about 115x100 mm so the number of components really matters. You can probably stuff more chips and components on the board but it will get increasing difficult to properly route it. Especially with that 20x2 IDE dual row header. That thing is a major pain to route to and near it. I am assuming dual layer PCB only unless someone can make 4 layer units. However, the price goes up exponentially with multiple layers.

Thanks for reviewing the schematic and posting any comments or questions!

Thanks and have a nice day!

Andrew Lynch

per
January 14th, 2009, 12:26 PM
Hi! I am not understanding your comment. The U9 74LS688 is tied to AEN which is an active high signal so it should be low except when DMA has control of the bus. Then the ROM should not be present since the memory decode logic will not generate a ROM chip select signal. There is a 10K ohm pull up resistor tied to the /G input on the U9 74LS688 so that if the ROM enable jumper is not present the /G will always be high. What am I missing?

In the IBM hard drive controller (Xebec) they use a similar circuit but instead they tie the memory decode 74LS688 /G pin to GND. The results should be similar except when DMA is active the ROM should not be in the memory space.

I am getting my definition of AEN from here:

http://www.techfest.com/hardware/bus/isa.htm

AEN
Address Enable is used to degate the system microprocessor and other devices from the bus during DMA transfers. When this signal is active the system DMA controller has control of the address, data, and read/write signals. This signal should be included as part of ISA board select decodes to prevent incorrect board selects during DMA cycles.





Thanks for reviewing the schematic and posting any comments or questions!

Thanks and have a nice day!

Andrew Lynch

I see now that it will work.

However, what I understand is that the AEN line is to prevent I/O transfers durning DMA. Since therse uses the data lines but aren't mapped in memory, they will corrupt data if they output durning DMA. However, since ROM is in the memory map, it will be acessed like all other memory if and only when DMA passes it's adresses. I see no reason why the ROM somehow should output data when the adressing lines are pointing to some other place in memory.

So, the only way the ROM can affect DMA is if DMA tries to read or write it by purpose. This is why I made my comment.

per
January 14th, 2009, 12:38 PM
The U9 74LS688 is tied to AEN which is an active high signal so it should be low except when DMA has control of the bus. Then the ROM should not be present since the memory decode logic will not generate a ROM chip select signal.

Please explain. As of I see from the datasheet, the output will allways be either H or L, not indeterminable. DMA is just like another processor only capable of reading and writing memory, and it operates the adress and data lines exactly the same way the normal CPU does. As of I see form your schematics, there will allways be a valid /CS signal just depending on the adress on the adress lines.

NobodyIsHere
January 14th, 2009, 01:42 PM
Please explain. As of I see from the datasheet, the output will allways be either H or L, not indeterminable. DMA is just like another processor only capable of reading and writing memory, and it operates the adress and data lines exactly the same way the normal CPU does. As of I see form your schematics, there will allways be a valid /CS signal just depending on the adress on the adress lines.

Hi! The ROM will only appear in the memory map when the signals when the ROM chip select signal goes low (/P=R) on the P side match those on the R side and /G is low. If the ROM enable jumper is not present, the pull up resistor will pull /G high and keep it there. The ROM chip select signal will never be produced. If the ROM enable jumper is there and DMA is active (AEN=high), the ROM chip select signal will never appear regardless of what is on the P or R sides. If the ROM enable jumper is there and DMA is no active (AEN=low) then AEN will pull /G low and when P=R the /P=R signal will be generated causing the ROM chip to be selected.

In other words, there are three conditions which must be met for a ROM chip select signal; 1, the ROM enable jumper is present, 2, AEN is LOW (DMA not active), and 3 the P side matches the R side (P=R). Those three conditions are only met when the CPU is doing a memory request in the address region of the ROM.

Thanks and have a nice day!

Andrew Lynch

BG101
January 14th, 2009, 02:46 PM
Personally I look forward to it, and I'm prepared to put my money where my mouth is. If it lets me use a 16-bit IDE drive on my 8-bit 8086 I'll be happy. It'll allow our vintage machines to continue fulfilling their purpose for a long time to come.





BG

Agent Orange
January 14th, 2009, 03:37 PM
Hi Guys,

Way back in August of last year I originated this thread. I'm overwhelmed by the response. I still haven't scored a 8-Bit IDE controller, so I'm your best fan! I did get my old Tandy 1000SX up and running with a 8-Bit Tecram SCSI controller /w a 8 mb SCSI drive. Only problem is the primative BIOS doesn't want to see it on boot. The work-around for that is to boot off the floppy.

If I can help defray some of the R&D costs, please let me know.

Tom D.

NobodyIsHere
January 14th, 2009, 05:02 PM
I see now that it will work.

However, what I understand is that the AEN line is to prevent I/O transfers durning DMA. Since therse uses the data lines but aren't mapped in memory, they will corrupt data if they output durning DMA. However, since ROM is in the memory map, it will be acessed like all other memory if and only when DMA passes it's adresses. I see no reason why the ROM somehow should output data when the adressing lines are pointing to some other place in memory.

So, the only way the ROM can affect DMA is if DMA tries to read or write it by purpose. This is why I made my comment.

Hi! Thank you for making the comments and challenging the design. If its wrong, I'll fix it and your improvements are always welcome. I have a thick skin and short memory from years in engineering so I expect to have to answer technical questions impartially. If I can't then its a risk area and everyone deserves to know about it!

Regarding the 8 bit IDE project; at least AFAIK, Hargle is leading this merry band to an 8 bit IDE product release. He has already written some software and coordinated the help among various experts and volunteers. That is great! I applaud his leadership and will do what I can to support him.

If Hargle can get his crew at work to make a PCBs, then I encourage that 100% as well. Especially a limited run of PCBs for a low rate initial production test. My offer, if Hargle's PCB run falls through for some reason, is to also do a PCB but I don't think many people are going to like my terms. This is not my core interest and as a result I am extremely risk averse. Especially lacking a working hardware prototype, things can get real sporty, real quick like.

However, if I can provide some advice, technical help, or even just light a fire under someone's chair then I'll do my best. In the meantime, I congratulate you on your progress so far and wish you the best of success on your project.

I have a new PCB in the trace routing optimizer grinding away with the fixes I mentioned this afternoon. They are incorporated and the PCB is being fixed up. There is not enough time for a really optimized PCB but I can send you a semi-decent looking PCB layout and schematic tomorrow. However the PCB layout with traces and fill zones incorporated won't be ready until tomorrow.

Regardless, the PCB and schematic are in dire need of some in depth, ruthless scrutiny from experienced technical designers and other experts on this board. The more review you get the better chance of success you'll have. Be polite when requesting reviews and help because you'll be asking for skills that are in demand and their time is valuable.

Also, you'll need to run the final PCB design through the FreeRouting.net autorouter sufficiently long enough to eliminate as many of the vias and unneeded traces as possible. This is a very time consuming process to result in an optimal board. My DiskIO board required 3 MONTHS in the optimizer to get it down to a reasonable level. Of course, the FDC and IDE sections and several dual row headers drove its complexity sky high so that is a really bad case. Your PCB won't be that bad but it will still take days or weeks to fully optimize. I recommend you do that once the design, schematic, and PCB layout are finished.

Thanks and have a nice day!

Andrew Lynch

PS, there is an updated ZIP file in the same place as before.

Druid6900
January 14th, 2009, 07:51 PM
Wasn't there a (or some) programs out there, way back, that let you do a real time circuit simulation?

I remember downloading one by accident once and played with it a bit before deleting it.

It allowed you to set up input conditions to see what your output would be. Problem is, I'll be damned if I can remember the name of the program, but, this circuit shouldn't be beyond its capabilities, IIRC.

NobodyIsHere
January 15th, 2009, 03:01 AM
Hi Richard! That's a great idea! If you or anyone can find a TTL circuit simulator which doesn't cost an arm and a leg I surely would be interested. I recall using PSPICE in college for analog and transistor circuits but haven't used anything like that recently.

The really sad part about this is building a wire-wrap prototype of this board would take like one evening to do. I am wire-wrapping the Zilog Peripherals board on my workbench right now for development and testing on the N8VEM project. I am using one of the N8VEM ECB prototyping boards and it is packed full of sockets (8 misc logic, the 4 Zilog chips, 3 MAX232s with caps, and a couple of configuration headers) and its going to be there for while I can see.

Assuming I had the parts (ISA prototyping board and the WW dual row connectors -- neither are an issue, I just don't have one at home since I haven't needed it) and the *space* (now that's an issue!) for a XT or AT set up, making one of boards would fairly easy. That's what really frustrates me! I have the rest of the stuff just sitting there ready to go but no *room* for another work area. Argh! Oh well!

Thanks and have a nice day!

Andrew Lynch

hargle
January 15th, 2009, 09:12 AM
Regarding the 8 bit IDE project; at least AFAIK, Hargle is leading this merry band to an 8 bit IDE product release. He has already written some software and coordinated the help among various experts and volunteers. That is great! I applaud his leadership and will do what I can to support him.

thank you for the kind words. i won't rest until i see this thing shipping as a finished product. For me, it's a mixture of wanting a board for myself, plus the challenge and opportunity to write some BIOS code and to just create something, plus wanting to make it all open source for the community, plus the fact that i'm too cheap to buy one off ebay. ;)



up. There is not enough time for a really optimized PCB but I can send you a semi-decent looking PCB layout and schematic tomorrow. However the PCB layout with traces and fill zones incorporated won't be ready until tomorrow.

All I really need is the schematic. My guy here said that he will unfortunately just have to enter it in again into our toolset (I don't know what tools we use) but that shouldn't take too much time, and he's bored anyway. :)


In other news, I've started writing a flash program for the eeprom.
It looks really easy to work with, and it's super cool that it has a spare 64 bytes of storage outside the 8k block that I could use for custom options.
Since the eeprom 8k in size, and my BIOS code is only 1/2 that, I could create a boot utility that could allow you to set defaults for booting drive order, passwords, drive options or anything else we wanted to do, all stored in the eeprom itself. Fun!

NobodyIsHere
January 15th, 2009, 06:06 PM
Hi Hargle! As promised, I updated the zip file with all the latest prints and files. It is ready to go. I will keep the PCB in the trace optimizer on a low simmer as a backup in case things don't work out at your work.

It will be good to have a back up and it will be a while before I need that machine to process the Zilog Peripherals board I am presently building. The PCB is simple enough it may actually finish in a reasonable time!

I am excited about the project as well and look forward for PCB availability. Please put me down for a couple!

Thanks and have a nice day!

Andrew Lynch

PS, I checked this morning and the optimizer has reduced the PCB trace routing to 60 vias and like ~357 inches overall trace length. That's pretty good but I suspect it has a long ways to go yet. Has anyone gotten some more reviews of the schematic and/or design? Hargle, please ask your PCB designers to ensure the vias and trace routing are minimized to the extent possible/practical. It makes difference in performance and reliability of the circuit.

NobodyIsHere
January 16th, 2009, 03:26 AM
Wasn't there a (or some) programs out there, way back, that let you do a real time circuit simulation?

I remember downloading one by accident once and played with it a bit before deleting it.

It allowed you to set up input conditions to see what your output would be. Problem is, I'll be damned if I can remember the name of the program, but, this circuit shouldn't be beyond its capabilities, IIRC.

Hi Richard! Thanks! Your comment rather started my brain to thinking and I found this project (http://qucs.sourceforge.net/) which just might be the item we're looking for.

I am back on the N8VEM project but does anyone want to give QUCS a try and see if they can simulate the IDE circuit? It may be possible but I have no idea if it works or not. Surely the schematic would have to be completely re-entered as it does not appear to support any import feature. Maybe I missed it though.

If someone is looking for a way to contribute to this project, here is your chance!

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
January 19th, 2009, 04:50 AM
Hi! My friend Dave pointed out that the R side of the 74LS688s should have pull up resistors and not left to float. Probably it would work with out them and the original schematics did not include them, however, it is good practice to bring an input signal to either HIGH or LOW and not leave it floating.

I have corrected my schematic and will rerun the PCB layout. The changes are minimal but important.

Thanks and have a nice day!

Andrew Lynch

hargle
January 20th, 2009, 11:42 AM
I think I may have found something in the design:
CSEL on the 40 pin connector should be pulled to ground instead of VCC.

http://www.pcguide.com/ref/hdd/if/ide/confCS-c.html
"To use cable select, both devices on the channel are set to the "cable select" (CS) setting, usually by a special jumper. Then, a special cable is used. This cable is very similar in most respects to the regular IDE/ATA cable, except for the CSEL signal. CSEL is carried on wire #28 of the standard IDE/ATA cable, and is grounded at the host's connector (the one that attaches to the motherboard or controller). "

I think this is very minor though. Most of the rest of the schematic is goobledygook to me.

---

Looking at the board layout in kicad, I'm wondering how in the world I could ever hand wire a prototype of this thing. I'm thinking it very well may be worth a hundred bucks of my money to save me 100 hours of soldering and get a prototype board etched for me. Wow that's a lot of wires.

NobodyIsHere
January 20th, 2009, 05:51 PM
I think I may have found something in the design:
CSEL on the 40 pin connector should be pulled to ground instead of VCC.

http://www.pcguide.com/ref/hdd/if/ide/confCS-c.html
"To use cable select, both devices on the channel are set to the "cable select" (CS) setting, usually by a special jumper. Then, a special cable is used. This cable is very similar in most respects to the regular IDE/ATA cable, except for the CSEL signal. CSEL is carried on wire #28 of the standard IDE/ATA cable, and is grounded at the host's connector (the one that attaches to the motherboard or controller). "

I think this is very minor though. Most of the rest of the schematic is goobledygook to me.

---

Looking at the board layout in kicad, I'm wondering how in the world I could ever hand wire a prototype of this thing. I'm thinking it very well may be worth a hundred bucks of my money to save me 100 hours of soldering and get a prototype board etched for me. Wow that's a lot of wires.

Hi Hargle! Thanks! I appreciate your reviewing the schematics and searching for problems! That's how we make it better! Just keep digging and we'll get all the bugs out.

As for CSEL, that is an active high signal since there is no ! or ~ or / or * or - or other special character preceding the name. Active high means that the signal is asserted (do something!) when it reaches the TTL high state (2.0-5v). Pulling CSEL high is basically telling the IDE device that it is being selected and should respond to commands.

I implemented a circuit similar to this on my N8VEM Disk IO prototype board and it worked fine.

http://www.hanssummers.com/computers/cpcng/ide/

You'll notice it also pulls CSEL high with a 10K ohm resistor tied to VCC. At least my prototype worked with this as is. I am pretty confident the CSEL circuit is correct. However if there is more information or view points that could confirm or deny this I would much appreciate it.

However, one thing to note is Hans Summer's circuit and my own IDE controller for the N8VEM project are meant for the older parallel IDE devices. I believe the XT-IDE circuit is as well since it shows a similar heritage in the design. I'll bet they all stem from the same common root design although I don't know what that is. It is possible that newer IDE drives have implemented more recent standards which may or may not work with the IDE interface. I have only tested mine with a 1.2GB IDE which is rather *ahem* elderly.

In general, all related XT IDE technical topics, questions, suggestions, comments, etc should be considered as part of this project. I have no problem explaining my understanding and will gladly make corrections as needed. I would much rather face my problems here in the design phase then after the PCBs are manufactured.

As for wiring up this project, it would be an evening at most. Its not super simple but pretty close. There are about 10 chips and very few passive devices. Only one connector although it is a large one. If I had the ISA prototyping board I am sure I could do this in one evening for construction and another for schematic to wiring test wring out.

Don't sell yourself short! You can do this or could if you set your mind to it! Check this unit (http://n8vem-sbc.pbwiki.com/f/IMG_8624.JPG)out! That's an IDE controller on the top half of the board and an FDC on the bottom. There are other pictures of the other side and there are another three or more "flying" chips (aka dead bugs) wired in backwards to the board because I ran out of space constructing the prototype. I can that that monstrosity to work (IDE and FDC), then you can make this one work!

Its not that hard! Anyone can do it! I think you'd find it is rewarding and a fun hobby too. I know I do. The danger with going direct to a PCB is there is no guarrantee that one PCB spin is all you need. At $100-$200 per hand, this gets to be an expensive game. One error may be serious enough to cause a PCB respin and then the old PCBs *can* be nearly worthless. Usually the problems are fixable with sufficient "cuts and jumpers" but those aren't much fun either and we all want to avoid them if possible.

So how is the rest of the project coming along? Keep those questions and comments coming! Read those datasheets and ask questions! You just might uncover the major "show stopper" bug that saves the project!

Thanks and have a nice day!

Andrew Lynch

PS, while doing a search for "74LS688 IO decoder" I came across this link (http://engr.nmsu.edu/~etti/4_1/4_1s.html) which is in many ways similar to what we are doing here. There are a lot of ideas in it and is a good cross comparison of the IDE circuit.

hargle
January 21st, 2009, 06:31 AM
I am pretty confident the CSEL circuit is correct. However if there is more information or view points that could confirm or deny this I would much appreciate it.

I came across it by comparing the 40 pin connector against the schematic I had of a motherboard my group had produced. We've always pulled CSEL low in our designs (probably a dozen of them), and all of them have also worked just fine. Likely, it doesn't matter 1 iota which way it goes, as the drive itself is going to override it anyway!

Beyond that, i haven't really figured anything else out. Well, I think I figured out the decoding for the IO address decoding dipswitch, where it appears it can be configured anywhere from 3F0h down to 000 in 10h increments. That's an amazing amount of flexibility. (which also means I have to scan all those addresses to find the card!)

I'm currently looking through the 74ls138 datasheet to try and figure out how that is working to flip between the two 74ls573's. I understand the idea; just haven't quite gotten my mind around the logic+inverter+output selects and what makes 'em work. It's really interesting stuff though, but I don't feel i'm very qualified to review it the way it should be, and I'm certainly ignoring everything that has to do with voltage levels and the like. I'm relying on others to chime in and give it some eyes.



As for wiring up this project, it would be an evening at most.
If I had the ISA prototyping board I am sure I could do this in one evening for construction and another for schematic to wiring test wring out.

I'll buy you 5 of them if you build me 1....



So how is the rest of the project coming along?

the schematic is the only thing i'm working on. my coworker got slammed with stuff to do, so he can't review the schematics this week, and I haven't touched the option rom since I released it. I've got ideas bubbling in my head for it, but that's it.

per
January 21st, 2009, 11:06 PM
I have just started to write a debugging tool that might be usefull in debugging the prototype board when it is done, see the attachement for a beta of this program.

What this program does is to print all possible "in ax,dx" or "in al,dx" to the screen in an organized manner, and it even gives you the ability to do either an "out dx,ax" or "out dx,al" with both ax and dx user-configureable. WARNING: playing around with random out's might be dangerous to your system. I'm NOT responsible if you fry anything in or outside your computer.

I will also implement a memory controll senter somewhat similar to this in the final release.

hargle
January 22nd, 2009, 06:00 AM
I've just ordered 2 prototype cards from jameco

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

I'm hoping to go on a shopping trip to a little electronics store here in the twin cities this week, where I will hopefully be able to snag the rest of the parts.
If not, another order will be placed, but no big deal.

either way, forward progress continues...

MikeS
January 23rd, 2009, 03:50 AM
Lynchaj wrote:
Hi Hargle! Thanks! I appreciate your reviewing the schematics and searching for problems! That's how we make it better! Just keep digging and we'll get all the bugs out.

As for CSEL, that is an active high signal since there is no ! or ~ or / or * or - or other special character preceding the name. Active high means that the signal is asserted (do something!) when it reaches the TTL high state (2.0-5v). Pulling CSEL high is basically telling the IDE device that it is being selected and should respond to commands.

I implemented a circuit similar to this on my N8VEM Disk IO prototype board and it worked fine.
-------------
That's not quite my understanding of the CSEL signal; it's not "active high" (or low) because it selects master/slave (Low=master, High=slave) when the drives are set to CS and a special cable is used which only passes it to one drive, and as Hargle says it is usually set low permanently on the MB.

But if the drives are set to master/slave then it is irrelevant AFAIK, which is probably why it worked for you.

NobodyIsHere
January 23rd, 2009, 08:54 AM
Lynchaj wrote:
Hi Hargle! Thanks! I appreciate your reviewing the schematics and searching for problems! That's how we make it better! Just keep digging and we'll get all the bugs out.

As for CSEL, that is an active high signal since there is no ! or ~ or / or * or - or other special character preceding the name. Active high means that the signal is asserted (do something!) when it reaches the TTL high state (2.0-5v). Pulling CSEL high is basically telling the IDE device that it is being selected and should respond to commands.

I implemented a circuit similar to this on my N8VEM Disk IO prototype board and it worked fine.
-------------
That's not quite my understanding of the CSEL signal; it's not "active high" (or low) because it selects master/slave (Low=master, High=slave) when the drives are set to CS and a special cable is used which only passes it to one drive, and as Hargle says it is usually set low permanently on the MB.

But if the drives are set to master/slave then it is irrelevant AFAIK, which is probably why it worked for you.

Hi Mike! Thanks! You are probably right on the CSEL. You'll notice that the circuit uses a 10K ohm pull up resistor tied between Vcc and CSEL. At least in theory, if the pin were shunted to ground the CSEL signal would be low. If it were left without a shunt (open) the pull up resistor would pull CSEL to high. In either case the CSEL signal is forced to a known state which is good. The real danger would be leaving CSEL floating in an indeterminate state in the "no man's land" where its neither high nor low or worse, oscillating.

As it is, leave it alone and CSEL will be HIGH. Use the shunt on the cable and it will be LOW.

That reminds me though, I need to check the specific configuration of the IDE harddrive I have connected to my N8VEM Disk IO prototype board to see what its settings are. I vaguely recall having to jostle around the cable and the jumpers to get the drive to recognise. Probably the CSEL is why. If that drive is set to SLAVE IDE then it makes perfect sense.

It may be worthwhile to put a jumper on the PCB for CSEL or just use jumper on the IDE cable.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
January 23rd, 2009, 05:38 PM
Hi! This is a copy of a message from the N8VEM mailing list on the Disk IO board. The Disk IO board is different from the XT-IDE controller but it does have some similarity and may be useful in helping narrow the drive compatibility/CSEL issues that will no doubt arrise.

Thanks and have a nice day!

Andrew Lynch

Hi All! Well the good news is that I finished building my Disk IO board. It looks fine but I haven’t tested it yet as I don’t want to start that until I get the Zilog Peripherals completed and off the bench or I’ll never finish it. There are some photos in the Disk IO directory on the wiki.

I did want to let the builders know that if they are building a Disk IO board that there are two halves to the design. The IDE section can function separately from the FDC, at least it did with the prototype for quite a while. There is minimal sharing of circuits between the two halves but you’ll need to review the schematic if you are interested in a partial build to ensure the parts you need are present.

Probably the best approach for a build and test of the Disk IO board is to start with the IDE section. It quite a simple design and pretty easy to debug. You can access the IDE registers directly from the RAM monitor and I think they are in the $2x range. There are descriptions online of the IDE interface and there is information in the IDE test program and formatting utility as well as the CBIOS.

Also I used the IDE to interface to a single IDE device so it is entirely likely the software will need to be modified to work with other devices. I used a Seagate ST51270A drive with NONE of the configuration jumpers set. That puts the drive in “single drive mode”. I also used a 40 pin IDE cable with the motherboard connector on the controller and the far end connector on the hard drive.

Hopefully this helps the builders get their own Disk IO board up and running. You could do a full board build all at once but I recommend getting the IDE section working first. Of course, please post your results and lots of photos for the wiki and tell us all about your experiences on the mailing list.

http://www.codemicro.com/support/disc/ata/st51270a.html

http://stason.org/TULARC/pc/hard-drives-hdd/seagate/ST51270A-MEDA-1270SL-1282MB-3-5-SSL-ATA2-FAST.html

http://n8vem-sbc.pbwiki.com/f/IMG_8632.JPG

http://n8vem-sbc.pbwiki.com/f/IMG_8631.JPG

http://n8vem-sbc.pbwiki.com/f/IMG_8630.JPG

Thanks and have a nice day!

Andrew Lynch

hargle
January 26th, 2009, 09:04 AM
Let the prototyping begin!

Last week friday I went out to a local electronics store and was able to pick up all the parts (I hope) required to build it, and on saturday the ISA prototype boards showed up. we're ready to roll!!

I bought 2 sets of everything, and will be sending 1 set to andrew to build, while I (attempt to) build the other one. Hopefully in a few days we can get something plugged in and tested. Unfortunately, I have a bunch of things in my real life schedule that will likely interfere with my building process.

------

My HW guy here mentioned that we should decouple all of the ICs by adding a 0.10uF caps across the power and ground pins. Does that make sense?

per
January 26th, 2009, 09:27 AM
My HW guy here mentioned that we should decouple all of the ICs by adding a 0.10uF caps across the power and ground pins. Does that make sense?

That's problably for removing noise. you don't want all of your latches/flip-flops/etc. to be reset in the middle of an operation ;) .

mbbrutman
January 26th, 2009, 10:08 AM
My HW guy here mentioned that we should decouple all of the ICs by adding a 0.10uF caps across the power and ground pins. Does that make sense?

Wiki has a very good writeup on the use of decoupling capacitors:

http://en.wikipedia.org/wiki/Decoupling_capacitor

The general idea is that you have a bunch of wires and components that are switching state at a high frequency. This generates AC noise in the circuit, which is designed for DC. The noise can effectively be removed from the system by giving it a path to ground (the capacitor) - the capacitor will be charged and will not let DC flow across, but AC will be able to get through.

When used for decoupling the capacitors are supposed to be small (0.10uf is right) and they are supposed to be tantalums.

NobodyIsHere
January 26th, 2009, 11:53 AM
[snip]

My HW guy here mentioned that we should decouple all of the ICs by adding a 0.10uF caps across the power and ground pins. Does that make sense?

Hi All! Yes, you hardware guy is right! That's why I added nine 0.1 uF decoupling capacitors. There is one in front of each IC that does switching and could generate switching transients. There is also a 22 uF across Vcc and GND to keep the bus garbage noise from coming into the card.

I think we are good on the decoupling capacitors! On a related note, my updated PCB layout is either near done or done with the revised trace routing. I am going to update the schematic file tonight and repost. Adding the pull up resistors to the R side inputs on the 74LS688s cost us 15 additional vias but its worth it, I think. That'll buy us a lot of flexibility and more reliable operation. The final PCB has like 70 vias (was 55) and now 367" of overall trace length.

Thanks and have a nice day!

Andrew Lynch

hargle
January 26th, 2009, 12:56 PM
Hi All! Yes, you hardware guy is right! That's why I added nine 0.1 uF decoupling capacitors. There is one in front of each IC that does switching and could generate switching transients.

well, he may be right, but he's an idiot (and me too) for not already seeing those on the schematics. :)

gerrydoire
January 26th, 2009, 02:33 PM
Well today I finally got an Acculogic sIDE-1/16, and when I connected a 2 gig cf card to it.

The problem I ran into, it won't boot from the cf card, it formats, it can do everything a normal hard drive can do, except wont boot, the error I see is "Drive not ready".

When I boot from a floppy I can go to C: and see it like a normal HD, dir, files etc.

The DOS being used is IBM Dos 2000 on a IBM XT

I did sys too of course!!

Any help would be greatly appreciated. :D

NobodyIsHere
January 27th, 2009, 02:53 AM
well, he may be right, but he's an idiot (and me too) for not already seeing those on the schematics. :)

Hi All! Don't worry about it! Its better to ask to the question than miss something obvious. If nothing else, the question made me double check the schematic. It would have been more embarrassing if they had been missing though...

Keep digging and asking the questions! BTW, the PCB layout is finished in the trace optimizer. I uploaded the DSN file but that's as far as I got. Tonight I'll redo the rest of the ZIP file so people can take a look at the updated design. There is really not much different other than the pull up resistors.

I was up late working on the Zilog Peripherals board and never made it to do the update.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
January 27th, 2009, 03:38 PM
Hi! Zip file updated on the N8VEM wiki.

Thanks and have a nice day!

Andrew Lynch

hargle
February 5th, 2009, 02:17 PM
some status from me:

1) went on a shopping trip to a local electronics store and managed to pick up two sets of the parts required to build our board. I've also bought 2 ISA prototype boards from jameco, so we're ready to build. On monday I shipped one of the sets out to andrew, and then I spent a few days searching for wire wrap tools, which I have now located. I'm hoping that I can start building the prototype card this weekend, but real life has had me rather distracted as of late. Andrew will likely finish his board before I do.

2) I've been working on option rom stuff in the meantime, and today I've managed to get extended(enhanced) INT 13 support functional, which means that drive support greater than 8.4G is now possible. I haven't ported it over to our 8088 CPU architecture though. As if 8.4 gig wasn't big enough! :)

Windows 98 DOS (aka DOS 7 I believe) does support eINT13 calls, so if that version of DOS will run on an 8088 machine, we could then have support for drives up to something insane, like 2TB. Otherwise, freeDOS or DR-DOS may also support eINT13 and run on an 8088.

The BIOS will require some changes to work on the prototype card anyway, so when I'm not busy wire wrapping, I can be coding. I need to clone myself.

gerrydoire
February 5th, 2009, 02:41 PM
some status from me:

The BIOS will require some changes to work on the prototype card anyway, so when I'm not busy wire wrapping, I can be coding. I need to clone myself.

We could use many clones of you :+>

NobodyIsHere
February 5th, 2009, 03:17 PM
Hi Hargle!

The parts arrived today and I have started assembling the prototype board. Work continues and I'll post more when there is something to report.

Thanks and have a nice day!

Andrew Lynch

PS, the updated PCB layout and trace routing has finally finished. I will update the zip file with the latest data.

hargle
February 5th, 2009, 06:07 PM
Hi Hargle!

The parts arrived today and I have started assembling the prototype board.

wow. I should definitely start on the software side first then. If we can show some signs of life there, we're in business.

How experienced are you in dos debug? We can pretty much get a feel for functionality with just a few in and out commands.

------

So the next question is this:
Let's say this part of the project goes really well, and we're functional in a week or two. Do we attempt to add DMA capabilities? That is the ultimate goal of something like this, but it will require additional parts and some reworking of the way we're handling the 16 bit data to accomplish it.
Do we make some PCBs as a PIO only card and do another rev later, or is it worth it to wait? How much of a performance gain could we get with DMA vs. PIO? Is it worth the work involved?

Ok, that was more than 1 question.

NobodyIsHere
February 6th, 2009, 03:25 AM
wow. I should definitely start on the software side first then. If we can show some signs of life there, we're in business.

How experienced are you in dos debug? We can pretty much get a feel for functionality with just a few in and out commands.

------

So the next question is this:
Let's say this part of the project goes really well, and we're functional in a week or two. Do we attempt to add DMA capabilities? That is the ultimate goal of something like this, but it will require additional parts and some reworking of the way we're handling the 16 bit data to accomplish it.
Do we make some PCBs as a PIO only card and do another rev later, or is it worth it to wait? How much of a performance gain could we get with DMA vs. PIO? Is it worth the work involved?

Ok, that was more than 1 question.


Hi Hargle! Well as you said this is speculation for now. The design is relying on IDE PIO mode to keep the circuit's control logic simple. I believe the key to DMA support is the correct placement of registers in the IO address. I think the registers have to be adjacent IO addresses or something like that. The XT-IDE design will not support DMA "as is" because the HI-LO registers are separated by 8 addresses. At least in theory, the circuit could be modified but it would require additional "glue" logic to implement.

IDE PIO mode performance is not great that is for sure but on the systems this project is targeting like 5150's and clones we are not talking about high speed systems to begin with. PIO mode becomes much more of a limiting factor on fast CPUs which spend their time waiting for the hard drive to respond. Generally speaking that's not the case with a 4.77 MHz PC running a single threaded DOS. DMA mode is faster but the difference is not as dramatic in practical terms as it is on the newer machines.

My suggestion is to get to a working prototype and some initial software in place so we can get some real data if and how well the PIO mode actually performs on the target systems. It may be acceptable as is or it may be so bad it is worth fixing. We can compare it to other IDE controllers for the XT ISA bus and get some idea of the merits of pursuing higher levels of performance.

The practical issues of complexity versus cost will weigh in the decision process too. Adding features means adding parts. Add too many parts and the board density goes too high for commonly available parts and low cost double layer PCBs. PCB trace routing becomes more complex and time consuming. Once we cross a certain threshold for complexity, programmable parts like GALs become the only practical solution to keep part count and cost low. As I think you've seen already, using programmable logic represents its own set of unique problems such as requiring special tools, programmers, software, etc.

I am somewhat familiar with the use of monitors like MSDOS DEBUG so the manual manipulation of IO registers from the command line is not an issue. I wrote a RAM monitor for the N8VEM SBC with similar functionality. It is for Z80 but the concept is identical. I bought an ISA bus extender do some limited functionality testing on the board with the intention of determining whether the IO ports are responding, chip selects are triggering, the ROM is appearing in the memory map etc. However, once the hardware is working reliably, then it is all software and that is where your talents really get to shine!

Thanks and have a nice day!

Andrew Lynch

PS, as usual the prototype is going to be similiar to the schematic but different from the PCB layout. We'll need to discuss implementation details as I've made several adjustments to accomodate the prototype board and other components. Nothing too dramatic but enough to be visually noticeable.

NobodyIsHere
February 8th, 2009, 06:52 AM
Hi All! Does anyone have an 8 bit ISA bus extender they'd be willing to lend, sell, donate, or otherwise let me use for building the prototype? I bought an ISA bus extender on eBay and just found out due to the geometry of the prototype board PCB that it is incompatible with 16 bit slots. ARGH!

I can still do some hardware testing but it will require an XT to do it which means reconfiguring my workshop and who knows how long that'll take. I would much rather just use the PIII with ISA slots that is already sitting there.

Thanks and have a nice day!

Andrew Lynch

PS, nevermind, I found a cheap one on eBay so I'll get that it instead. It's nice to see Murphy is as active on this as well as my other projects. ;-)

per
February 8th, 2009, 11:32 AM
Hi All! Does anyone have an 8 bit ISA bus extender they'd be willing to lend, sell, donate, or otherwise let me use for building the prototype? I bought an ISA bus extender on eBay and just found out due to the geometry of the prototype board PCB that it is incompatible with 16 bit slots. ARGH!

I can still do some hardware testing but it will require an XT to do it which means reconfiguring my workshop and who knows how long that'll take. I would much rather just use the PIII with ISA slots that is already sitting there.

Thanks and have a nice day!

Andrew Lynch

PS, nevermind, I found a cheap one on eBay so I'll get that it instead. It's nice to see Murphy is as active on this as well as my other projects. ;-)

Can't you just chainsaw one of the 16-bit slots, or would that have been a little too dramaticly?

NobodyIsHere
February 8th, 2009, 11:46 AM
Can't you just chainsaw one of the 16-bit slots, or would that have been a little too dramaticly?

Hi! Yes, using a chainsaw on my test bench PC is a bit too dramatic even for an old clunky PIII. Besides, chainsaws aren't exactly precision instruments. You might accidentally scratch the paint on something nearby. Or shred it. :-)

Probably I could have used a Dremel tool to cut the offending tab bit off the prototype board but once it is full of wires and parts, I am not going to screw with it. It's easier to just let it wait until the proper part arrives. The 8 bit ISA extender will be here in a few days. By then I should be done assembling and testing the prototype.

Thanks and have a nice day!

Andrew Lynch

bobwatts
February 9th, 2009, 02:20 AM
Hi Gang !

Good to see the project progressing. I was curious if anyone knows the approximate return time of the sIDE card I loaned out?

I have a friend coming in from out of town in March, and he was kind of wanting to see my XT system operating. It's no big deal if the card is not back by then, I was just wondering if it would be. From what I can tell, an entirely different design is taking shape anyway, and that is probably good. :D

Thanks

bobwatts
EartH

hargle
February 9th, 2009, 09:31 AM
bob,

check your PMs if you haven't-druid has been waiting to see if it's ok with you if he could send it to me, then I'd send it to you.

My co-worker wanted to see how the power and ground planes were laid out on the acculogic, and I wanted to see if I could upgrade the BIOS past the 528MB barrier that exists on it right now. We can absolutely wait til after march to do that work though, and now that we're prototyping anyway, we likely won't need it beyond the BIOS upgrade work.

We can also tackle that job later on in the year after this card is finished.

So, druid, please send the card back to bob. I'll get it from him later if that's ok.

bobwatts
February 9th, 2009, 11:30 AM
Hello !

I was under the impression that the card was going to be mailed to you a LONG time ago. I thought I had already said: Sure, go ahead.

In any event, if you need to see it, get the thing mailed to you so you can have a look. No big deal.

( just be careful. :) )

bobwatts
EartH

Druid6900
February 9th, 2009, 02:45 PM
It'll go out in the next couple of days (hopefully not for what it cost you to ship it to me, though LOL)

Hargle, I've got your snail-mail address still, so, I'll send you the tracking info if you can PM me an e-mail address to go with it.

NobodyIsHere
February 9th, 2009, 02:57 PM
Hi All! I posted an update of the schematics and PCB layout on the wiki. There is a photo of the partially assembled prototype as well.

Thanks and have a nice day!

Andrew Lynch

PS, the funny coincidence is that the N8VEM builders are just now getting their Disk IO boards built and are starting to test them. I started the Disk IO prototype build in Mar/Apr 2007! Guess what is causing trouble right out of the starting gate? You guessed it -- the IDE! The good news is that the problem seems pretty straight forward and now we're seeing some reports of success. There are two confirmed instances of IDE devices working with Disk IO; my Seagate IDE hard drive and another builders 512M CF unit. Testing continues and I am sure more problems and more successes as per home brew computing. The timing of these two projects overlapping like this is amazing though.

NobodyIsHere
February 10th, 2009, 06:12 PM
Hi! Good news! I finished assembly of the XT-IDE prototype. Installed the ICs, found a cable and a couple of IDE hard drives for testing. Thursday I start the point to point wring out to verify all the connections and then onto live testing. The prototype is too wide to fit in a single slot so it either uses a couple of slots or has to be on an ISA bus extender. Hopefully my 8 bit ISA bus extender will be here soon.

The point to point wring out usually takes a lot less time than the assembly. Building the prototype turned out to be more complex and time consuming than I originally estimated. It is more complex than it looks, that is for sure.

One thing we are finding on the N8VEM project with the Disk IO board is that the IDE "standard" is not very standardized. There are many variations of drives and controllers and not all IDE devices are interchangeable. Some work, some don't, and its not clear why.

One thing is for sure though, I suspect this project is in for the same rude surprise when we finally move to integration and software testing. Be prepared for some ugly IDE compatibility issues to surface. I'll bet that only a subset of IDE devices are going to work with the device, at least at first. So we'll see how this turns out. I am very glad we are prototyping this before investing in a manufactured PCB.

Thanks and have a nice day!

Andrew Lynch

gerrydoire
February 10th, 2009, 08:27 PM
Hi! Good news! I finished assembly of the XT-IDE prototype. Installed the ICs, found a cable and a couple of IDE hard drives for testing. Thursday I start the point to point wring out to verify all the connections and then onto live testing. The prototype is too wide to fit in a single slot so it either uses a couple of slots or has to be on an ISA bus extender. Hopefully my 8 bit ISA bus extender will be here soon.

The point to point wring out usually takes a lot less time than the assembly. Building the prototype turned out to be more complex and time consuming than I originally estimated. It is more complex than it looks, that is for sure.

One thing we are finding on the N8VEM project with the Disk IO board is that the IDE "standard" is not very standardized. There are many variations of drives and controllers and not all IDE devices are interchangeable. Some work, some don't, and its not clear why.

One thing is for sure though, I suspect this project is in for the same rude surprise when we finally move to integration and software testing. Be prepared for some ugly IDE compatibility issues to surface. I'll bet that only a subset of IDE devices are going to work with the device, at least at first. So we'll see how this turns out. I am very glad we are prototyping this before investing in a manufactured PCB.

Thanks and have a nice day!

Andrew Lynch

Wouldn't the best option of compatibility for 8bit IDE be the ability to use CF cards?

Terry Yager
February 10th, 2009, 09:43 PM
Wouldn't the best option of compatibility for 8bit IDE be the ability to use CF cards?

Are you kidding? IDE/CF compatibility is even shakier than with plain-Jane IDE devices. Now you're adding another layer of complexity with having to insert an IDE<==>CF adapter into the equation.

--T

gerrydoire
February 11th, 2009, 09:44 AM
Are you kidding? IDE/CF compatibility is even shakier than with plain-Jane IDE devices. Now you're adding another layer of complexity with having to insert an IDE<==>CF adapter into the equation.

--T

The only problem I've run into with IDE<>CF with the acculogic 1/16
was:

It wouldn't boot from the thing, it will work if I boot from a floppy
then go to c:/ and see my 512megs, but won't boot directly.

:)

justjunk
February 11th, 2009, 09:37 PM
>The only problem I've run into with IDE<>CF with the acculogic 1/16 was:

>:It wouldn't boot from the thing, it will work if I boot from a floppy
>then go to c:/ and see my 512megs, but won't boot directly.

Is that a common problem with all sIDE 8bit controllers? I just ordered one and was hoping to be able to boot from it.

NobodyIsHere
February 12th, 2009, 02:37 AM
Hi! Yesterday was good in that my 8 bit ISA bus extender arrived so that is taken care of for more testing. Tonight I plan on finishing or doing a big chunk of the point to point testing. Once it is done, I can put the new prototype in the test machine for live testing.

BTW, Hargle, what IO port and ROM addresses did you want? I can verify whether the IO ports and/or ROM work without any special software but we are going to be ready for software testing soon.

The good news on the related but different N8VEM DiskIO testing is that several builders have their Disk IO boards done and are testing the IDE section. So far there are about a dozen IDE devices known to work with it which are a mix of IDE hard drives and CF devices. That is pretty good for a completely stock system using the first revision of the CBIOS. The only problems really so far are that I included some resistors in the design which should be optional and that WD & later Quantum hard drives are not showing up on the interface for some reason.

The resistors are an easy fix by just not installing them and I suspect the problem with the WD & Quantum drives is probably a missing pull up/pull down resistor some place or maybe an initialization sequence problem. This is relevant to this project because I suspect we'll be going through a similar process here as well.

How can you help? Gather as many old and new IDE hard drives and/or IDE CF devices as you can and once the PCBs are available participate in the testing and fixing cycle. We are keeping a page on the Disk IO working devices here (http://n8vem-sbc.pbwiki.com/Disk-IO-board%3A-What-works-and-how)

Thanks and have a nice day!

Andrew Lynch

per
February 12th, 2009, 02:44 AM
How can you help? Gather as many old and new IDE hard drives and/or IDE CF devices as you can and once the PCBs are available participate in the testing and fixing cycle. We are keeping a page on the Disk IO working devices here (http://n8vem-sbc.pbwiki.com/Disk-IO-board%3A-What-works-and-how)

Thanks and have a nice day!

Andrew Lynch

I got about 10 of them... Mostly in the 2GB range, but some up to 40GB.

Maybe if you use a socket for the resistors, and include both a jumper pack and a resistor pack. Then the user can choose to have resistors installed or not.

NobodyIsHere
February 12th, 2009, 03:15 AM
I got about 10 of them... Mostly in the 2GB range, but some up to 40GB.

Maybe if you use a socket for the resistors, and include both a jumper pack and a resistor pack. Then the user can choose to have resistors installed or not.

Hi! Thanks! Yes, I think we can apply the lessons learned on the N8VEM Disk IO project here and vice versa. Regarding the pull up/pull down resistors on the Disk IO, its not the pull up resistors in the packs for the 74LS688's that are the problem. Those should be just fine. The issue is the funky non-standard IDE pull up/pull down resistors. There are several variations of hobbyist IDE interfaces and all sorts of combinations of what pins are connected and how. Tilmann Reh has one scheme in GIDE, Phil Ruston at Retroleum another, Hans Summers yet a different one, etc. Some leave pins unconnected, others are grounded, yet others pulled high. The variations are also too numerous to count.

The Disk IO board is based on the Hans Summers IDE interface which included pull down resistors on the /DMACK and DMARQ pins. It also has a pull up resistor on CSEL. Apparently during my build of the original Disk IO prototype, I managed to get my IDE hard drive working but had to remove those resistors (R1, R2, and R3) in the process. When I went to the PCB layout and design it was months later and I forgot to remove those resistors so they carried over. The PCB fix is easy enough, just don't install them. However the issue remains as to *what* the IDE interface is *supposed* to be. It seems completely arbitrary as to what the configuration actually is!

The nice thing about the IDE "standard" is there are so many to choose from! They are all different! Yet most if not all work at least with some IDE hard drives! How do you capture a reliable design for something like that? Adding dozens of jumpers and pull up/pull down resistors for every conceivable combination makes no sense. It complicates the PCB and makes installation and test a nightmare.

Thanks and have a nice day!

Andrew Lynch

per
February 12th, 2009, 03:25 AM
Hi! Thanks! Yes, I think we can apply the lessons learned on the N8VEM Disk IO project here and vice versa. Regarding the pull up/pull down resistors on the Disk IO, its not the pull up resistors in the packs for the 74LS688's that are the problem. Those should be just fine. The issue is the funky non-standard IDE pull up/pull down resistors. There are several variations of hobbyist IDE interfaces and all sorts of combinations of what pins are connected and how. Tilmann Reh has one scheme in GIDE, Phil Ruston at Retroleum another, Hans Summers yet a different one, etc. Some leave pins unconnected, others are grounded, yet others pulled high. The variations are also too numerous to count.

The Disk IO board is based on the Hans Summers IDE interface which included pull down resistors on the /DMACK and DMARQ pins. It also has a pull up resistor on CSEL. Apparently during my build of the original Disk IO prototype, I managed to get my IDE hard drive working but had to remove those resistors (R1, R2, and R3) in the process. When I went to the PCB layout and design it was months later and I forgot to remove those resistors so they carried over. The PCB fix is easy enough, just don't install them. However the issue remains as to *what* the IDE interface is *supposed* to be. It seems completely arbitrary as to what the configuration actually is!

The nice thing about the IDE "standard" is there are so many to choose from! They are all different! Yet most if not all work at least with some IDE hard drives! How do you capture a reliable design for something like that? Adding dozens of jumpers and pull up/pull down resistors for every conceivable combination makes no sense. It complicates the PCB and makes installation and test a nightmare.

Thanks and have a nice day!

Andrew Lynch

Who invented IDE anyways? It would be interesting to see how it should be in the first place.

How is the testing going to take place, will you relay on the N8VEM results, or will you make PCB's of the card and send around to testers?

One last question, will the card support 2 drives on the cable (jumpered to Master and Slave, not CableSelect)?

NobodyIsHere
February 12th, 2009, 04:01 AM
Who invented IDE anyways? It would be interesting to see how it should be in the first place.

How is the testing going to take place, will you relay on the N8VEM results, or will you make PCB's of the card and send around to testers?

One last question, will the card support 2 drives on the cable (jumpered to Master and Slave, not CableSelect)?

Hi! I believe Compaq "invented" the first IDE like drives as a cost savings measure in the mid to late 1980's. They combined a WD1002 MFM controller onto someone's HD assembly to save a bus slot and PCB in their units. Of course the first several generations of proto-IDE drives were highly proprietary and there are lots of variations. The ATA-1 standard didn't come about until the early to mid 1990's. Its more of an evolution of a device rather than an explicit design.

Since I am on both projects I am cross feeding relevant information on both projects back and forth. The N8VEM project is my primary concern, of course, but it can and has helped Hargle's 8 bit ISA IDE controller too. There are definitely a lot of similarity.

Regarding CSEL, most likely the board is going down the Master/Slave drive approach. Common IDE cables and drives support the Master/Slave jumpers and there is not much point in requiring special cable configurations for CSEL. However, there is nothing in the design which would prevent it. As long as the pull up resistor is available on CSEL the drives and/or cables can do whatever they like with it.

There is one thing the members here could do to help to me on both of these projects... If anyone knows or has any WD and/or recent Quantum IDE drives on a home made IDE controller please post the IDE pin out. If the WD/Quantum drives have special initialization codes or sequences I'd like that too. We are doing the experimenting to determine why the WD drives are misbehaving on the Disk IO board and I suspect it is related to either the IDE pull up/pull down resistors or there is something software related like the latches are in the wrong state (HIGH, LOW, or tristate) and its confusing them.

Thanks and have a nice day!

Andrew Lynch

gerrydoire
February 12th, 2009, 05:12 AM
>The only problem I've run into with IDE<>CF with the acculogic 1/16 was:

>:It wouldn't boot from the thing, it will work if I boot from a floppy
>then go to c:/ and see my 512megs, but won't boot directly.

Is that a common problem with all sIDE 8bit controllers? I just ordered one and was hoping to be able to boot from it.

One thing to keep in mind, the CF CARD I tried maybe the problem, not the controller card itself, its a 2 gig high speed version, I haven't tried an older version of a CF Card.

If you can try a 128 meg CF and even better a 512 meg CF, they might work, they are harder to come by these days, which is why I haven't tried one of them out yet..

This is the only CF Card tried with my sIDE:

http://store.lexar.com/?category=21&subcategory=1&productid=CF2GB-80-708

Any luck its the CF card not the sIDE...

kb2syd
February 12th, 2009, 05:25 AM
My guess here about the CF card is the geometry it is reporting to the sIDE. It is probably causing an overflow somewhere and not allowing for boot. I have several 8 bit IDE cards and most do something odd with any drive 2GB or over. Some have problems with drives over 540MB.

That being said, I have a large stock of smaller drives.

NobodyIsHere
February 12th, 2009, 06:48 PM
Hi! I finished the point to point wring out and configuration check on the XT-IDE prototype. It seems to be in good shape so I put it in the test station PC. It seems to check out. The ROM appears at D000:0 as expected. When I place an IDE hard drive on the connector, the IO ports appear at 300 as expected. They are returning seemingly normal values.

The next step is some test software. Please let me know when you are ready to proceed. The prototype is sitting ready with an IDE drive in the test station. I suggest a plain MSDOS application to exercise the ROM and IO ports first. Then make a program to command the disk to IDENTIFY. If we can get those working we should be in good shape.

Thanks and have a nice day!

Andrew Lynch

PS, updated files on the wiki. This is the reference software and would be a good place to start. Preferrably with a tiny C environment for building tools. The smaller the better since then I can use the test station for local modification and debugging.

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

Tiny C Compiler (http://bellard.org/tcc/)(TCC) looks like it'd be just about perfect. Would someone please give this a try and let me know if this works in a plain MS-DOS environment? What would be ideal, I think, is the whole thing fitting on a single 1.44MB floppy disk for easy backup.

hargle
February 13th, 2009, 06:18 AM
amazing!

here's a piece of software to play with:
http://www.waste.org/~winkles/ATA.ZIP

However, this software:
1) will not work on an 8088 machine
2) will need to be modified to read the 2nd half of the data from IOBASE+8.
3) requires a mouse

I can hopefully fix #2 over the weekend, #1 might take a bit longer. Not sure if #3 can be fixed without totally gutting the interface.

To use it, you'll need to boot up to a DOS disk, load a mouse driver and simply run ATA.
Since our device is dipswitched to IO address 300 for the base, click on the "controller base address" field and change it to 300 there, or better yet, launch the program with "ata -p300".

You should then be able to click on the "command" field, type in EC (Identify device ATA command) and click the read button. If the drive is responding correctly, the program should fill the screen with 256 words of data.

I'd assume since only 1/2 of the data is showing up at the data port at 300h, that you'll see 1/2 of the data and FFs mixed in, or maybe 00's? I've no idea what will happen!

Anyway, the list of registers (data, features, sector count...) is a 1:1 display of the IO ports starting at BASE, BASE+1, BASE+2 etc. So that could help you see if all 8 ports are being decoded.


You might want to get used to the program on a real HDD controller first, just so you know what to expect. It'll default to a base address of 1f0, which is where a normal hdd controller should be sitting. You should also use a fairly modern drive (1995 or later) just to make sure we're all LBA compatible.

You can do PIO reads and writes to a drive as well by issuing command 20h, set the LBA to whatever you want to read, and make sure at least BIT6 in the device register is set (for LBA access). PIO write is command 30h, and will write whatever data is currently in the buffer (ie, whatever you just read off the drive, or random data if you just started the program)

apologies that real life has demanded my attention lately, or I'd be a lot more prepared for this.

NobodyIsHere
February 13th, 2009, 07:08 AM
Hi Hargle! Thanks! Is the source code available for the ATA program? I think it might work with the XT-IDE controller as is but would give 256 double values for the sector rather than 512 unique values due to the high low split.

I have no doubt you are busy as it is something I have issues with as well. There is only so much time to work on these things and I can well understand that. However, this is an open project so it can be more than just you and me working on it. For example, if someone else could help with the compilation of the XTIDE.C program using TCC and write down the steps, I can better use the time I do have to actually test the hardware rather than wrestle with the development environment. I can do both but it just takes time.

When I was writing Catweasel software I used DJGPP which was fine but it is rather bulky and my only real interface to the PIII test station is via the floppy drive. To be useful as a test machine it does not load drivers and only a bare minimum MSDOS so getting things in and out of it can be a real PITA especially for large files.

Thanks and have a nice day!

Andrew Lynch

hargle
February 13th, 2009, 09:39 AM
that program is written in x86 assembly, and I'm not sure how releasable the source would be. It was written at and for work, so it's not really as open as I'd like it to be. I consider that program to be pretty throwaway, since it's not really designed for what we're trying to do, but I can ply it to be useful for us for the time being.

I suspect that I can fix the 2nd data port before anyone else would be able to muddle through the source and figure out where all the things would need to be changed anyway. ;) I should be able to hit that this sunday.

It's my birthday tomorrow, so despite my own wishes, I have people who want to steal my time. :( heh.

At least you'll be able to see that data is coming back, and it should be easy to look at every other byte and know that we can at least communicate.

What I really want to do is develop a full card exerciser, which I'd then use for debugging and testing the built PCBs. since I have't written anything like that yet, we've gotta use what we have at hand. It won't be written in C though, as x86 is my native language.

NobodyIsHere
February 13th, 2009, 11:17 AM
Hi Hargle! Thanks! Happy Birthday BTW! Have a beer and think of all your friends here!

Tonight I will give the TCC a try and see if I can get the xtide.c program to compile. TCC needs MinGW which I hope means it can still work in plain MS-DOS. I prefer C as well although if that's not an option assembler is OK.

What I'd really like is the ability to modify the test software on my test station PC so its a nice short loop not involving multiple machines. We'll see if that is possible or not.

So things are going OK. I am fairly confident that the board is working since I checked all the IDE registers and got reasonable values. It is most likely working fine but we need to verify its right before making any assumptions that are going to screw up the software development.

If you really need some time, we can put this on the back burner for a while as I need to do some Disk IO testing. There is some issue with the IDE not recognizing the WD/Quantum drives. The XT-IDE design recognizes them just fine so I am suspecting the difference is in the pull up/pull down resistors.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
February 13th, 2009, 04:01 PM
Hi! I tried the TCC to compile the xtide.c and it almost worked but is missing the BIOS.H header. I tried replacing it with the one from DJGPP and that did not work either. Compiling with DJGPP on a different machine produces a whole page of errors and I really did not want to delve into that tonight.

I also tried the ATA program and the machine has a mouse on it but must be missing the device driver or something since I could not access anything the mouse was unresponsive. Are there keyboard commands? It did not seem to respond to anything I could think of.

There is much going on right now so I am going to just put this on hold pending some test software.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
February 14th, 2009, 08:26 AM
amazing!

here's a piece of software to play with:
http://www.waste.org/~winkles/ATA.ZIP

However, this software:
1) will not work on an 8088 machine
2) will need to be modified to read the 2nd half of the data from IOBASE+8.
3) requires a mouse

I can hopefully fix #2 over the weekend, #1 might take a bit longer. Not sure if #3 can be fixed without totally gutting the interface.

To use it, you'll need to boot up to a DOS disk, load a mouse driver and simply run ATA.
Since our device is dipswitched to IO address 300 for the base, click on the "controller base address" field and change it to 300 there, or better yet, launch the program with "ata -p300".

You should then be able to click on the "command" field, type in EC (Identify device ATA command) and click the read button. If the drive is responding correctly, the program should fill the screen with 256 words of data.

I'd assume since only 1/2 of the data is showing up at the data port at 300h, that you'll see 1/2 of the data and FFs mixed in, or maybe 00's? I've no idea what will happen!

Anyway, the list of registers (data, features, sector count...) is a 1:1 display of the IO ports starting at BASE, BASE+1, BASE+2 etc. So that could help you see if all 8 ports are being decoded.


You might want to get used to the program on a real HDD controller first, just so you know what to expect. It'll default to a base address of 1f0, which is where a normal hdd controller should be sitting. You should also use a fairly modern drive (1995 or later) just to make sure we're all LBA compatible.

You can do PIO reads and writes to a drive as well by issuing command 20h, set the LBA to whatever you want to read, and make sure at least BIT6 in the device register is set (for LBA access). PIO write is command 30h, and will write whatever data is currently in the buffer (ie, whatever you just read off the drive, or random data if you just started the program)

apologies that real life has demanded my attention lately, or I'd be a lot more prepared for this.

Hi Hargle! Good news! I finally got past the mouse issue and got the ATA program running on my test station. When I tell it to do the IDENTIFY command and then READ it does appear to be replying correctly.

I get a sector back but only the lower byte of the words have data. The high byte in the word is $00 so I am getting every other byte as you'd expect. Probably the modifications to ATA to fix that would be pretty easy since instead of reading a word now you read a low byte port and then a high byte port.

Its good news and thought I'd share it.

Thanks and have a nice day!

Andrew Lynch

PS that's with a WD hard drive which are giving us grief over on N8VEM for the Disk IO board. For some reason yet unknown the WD and recent Quantum hard drives are not responding correctly. Probably there is some issue like timing or something in the Disk IO. However, Disk IO does work with enough IDE drives that at least its useful. I believe we'll eventually find out the root cause for the incompatibility with the WD and Quantum drives. Depending on the fix it may be worth it to support them but I guess we'll see.

per
February 14th, 2009, 08:51 AM
Hi Hargle! Good news! I finally got past the mouse issue and got the ATA program running on my test station. When I tell it to do the IDENTIFY command and then READ it does appear to be replying correctly.

I get a sector back but only the lower byte of the words have data. The high byte in the word is $00 so I am getting every other byte as you'd expect. Probably the modifications to ATA to fix that would be pretty easy since instead of reading a word now you read a low byte port and then a high byte port.

Its good news and thought I'd share it.

Thanks and have a nice day!

Andrew Lynch

PS that's with a WD hard drive which are giving us grief over on N8VEM for the Disk IO board. For some reason yet unknown the WD and recent Quantum hard drives are not responding correctly. Probably there is some issue like timing or something in the Disk IO. However, Disk IO does work with enough IDE drives that at least its useful. I believe we'll eventually find out the root cause for the incompatibility with the WD and Quantum drives. Depending on the fix it may be worth it to support them but I guess we'll see.

That's fantastic!

Do you got an price estimation? as of I know, most of the reqired parts are in place, so I guess the part list is somewhat the same on the final product.


I got an 16-bit ISA IDE controller. It got some resistors to GND and VCC. Although I haven't tested it with a WD or Quantum drive, do you want me to list them?

NobodyIsHere
February 14th, 2009, 09:08 AM
That's fantastic!

Do you got an price estimation? as of I know, most of the reqired parts are in place, so I guess the part list is somewhat the same on the final product.


I got an 16-bit ISA IDE controller. It got some resistors to GND and VCC. Although I haven't tested it with a WD or Quantum drive, do you want me to list them?

Hi! Thanks and I appreciate your enthusiaism but we are a L O N G way from selling these boards. Hargle and I are working on it as best we can but as relatively normal people our availability and capacity for hobbies varies with all sorts of things.

If you'd like to speed the project along, there are plenty of things that still need to be done. A good starting place is some test software. All we really need is the XTIDE.C program compiled and send me a binary to test with.

Since the problems with the XTIDE.C program appear to be related to the interrupt service routines, those could even be stripped out for a reduced but still useful test program.

Alternatively, you could use the design information in XTIDE.C to write a completely new program. The primary things it needs to do is read and write the IDE registers ($300-$30F) and allow a tester to inspect and change those values. It also needs to be able to read and write a sector and display the results, preferrably with some ASCII display.

Try the ATA program Hargle posted earlier with a normal PC IDE controller and you'll see the basic functionality we need. If you are going to write from scratch though please pick a lightweight and MSDOS friendly environment like TCC or even BASIC so it can be modified on the test station without a lot of development environment overhead. For example anything requiring Windows or a Linux GUI is a bad choice. Something that runs on MSDOS and fits on a floppy disk would be great with the program and the compiler/assembler/interpreter, etc.

Thanks and have a nice day!

Andrew Lynch

hargle
February 14th, 2009, 09:12 AM
Great to hear that an ID command is working!!! that's a great birthday gift in itself.

In about 24 hours I'll have time to fix ATA, and I will likely be able to fix the BIOS that I released earlier for you to try as well. It's really only the data read/writers that need to change, so it's probably only a 30 minute job. I may even have time to start wire wrapping my own prototype tomorrow.

The BIOS I send out tomorrow will be hard coded to a base address of 300h though; I'll add a scanning routine to it later on, as well as some other features. I'm going to have a lot of fun with this BIOS.

---

Costs: - We don't really have an idea yet as to the costs. The 2 prototype cards+components+wire wrap sockets ended up costing me about $100 total.
Once the thing is prototyped though, we can start to look for cost saving things we can do, for example, the ROM currently is a DIP package, and cost me like $6 each. I've seen the same part in a PLCC package for less than $4. As long as we can find sockets for less than $2, we can save some cash there. All of those changes need to be tested out and adjusted in the design layout, but I've got to think we will eventually get these things down to $20 or less. At the moment I'm so happy that I don't care how much these things cost.

NobodyIsHere
February 15th, 2009, 09:57 AM
Hi All! Hargle is busy working on modifications to the ATA program and that is good.

I cannot get xtide.c to compile after much experimenting in both Linux and MSDOS DJGPP. I think the program is using an old version of libraries or something and I am not familiar enough with it to figure out what's wrong.

Are there some Linux/C gurus who would be willing to modify xtide.c so it will compile with Linux and/or preferrably DJGPP? Even if you are not interested in the 8 bit IDE project this would be very helpful. The source mentions Linux so I assuming it uses GCC.

Thanks and have a nice day!

Andrew Lynch

hargle
February 16th, 2009, 06:08 AM
Just to let everyone know what's going on here, Andrew has gotten an ID command to work successfully in my ATA program, which means the drive is alive and talkable behind the controller itself. He's also dropped in the option ROM and gotten the drive to identify during POST, which means that the ROM portion of the design is also working as expected! First try too!

I'm going to be writing a suite of software tests to verify the IO functionality across a series of write/read/compare tests and working on upgrading the option ROM to support all the eINT13 routines that I'd finished recently.

So I guess what I'm saying is that we're making huge progress.

Once the regression testing is complete, I think we can work on some parts locating and getting a bill of materials set up, and see about reducing some of the parts cost.

JT64
February 18th, 2009, 11:19 AM
Couldn't you get a 8-bit USB 1.0 host project started once you finished this?

Isn't USB host concept real simple it is the software device drivers that maybe the hard part?

Just dreaming:rolleyes:
JT

NobodyIsHere
February 18th, 2009, 07:03 PM
Hi! An 8 bit ISA USB adapter may also be possible but now is not a good time. Hargle and I are up to our eyeballs in this project and it needs time to settle out first. Hopefully that will be soon but you never know.

In the meantime, I would consider an ISA board with an 8255 connected to one of these (http://www.futurlec.com/USBMOD4.shtml). That is assuming you are or can find someone as motivated as Hargle to push the design from dream to reality. Hargle deserves credit for persistence and tenacity which is a major factor in making things happen.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
February 21st, 2009, 07:37 PM
Hi! The 8 bit IDE controller prototype is working. Thanks and congratulations to Hargle for all his hard work in making the BIOS. It works amazingly well. It is just like any other IDE hard drive and can boot, be partitioned, formatted, etc.

See photos of the first boot here (http://n8vem-sbc.pbwiki.com/browse/#view=ViewFolder&param=XT-IDE)

Thanks and have a nice day!

Andrew Lynch

Unknown_K
February 21st, 2009, 09:29 PM
Wow, wiring that must have been a pain. So are you going to start selling them someday?

rangga
February 22nd, 2009, 12:40 AM
Congratulation! Please let us know the detail about what type of ide harddisk that supported by this card. Thankyou

per
February 22nd, 2009, 01:23 AM
Hi! The 8 bit IDE controller prototype is working. Thanks and congratulations to Hargle for all his hard work in making the BIOS. It works amazingly well. It is just like any other IDE hard drive and can boot, be partitioned, formatted, etc.

See photos of the first boot here (http://n8vem-sbc.pbwiki.com/browse/#view=ViewFolder&param=XT-IDE)

Thanks and have a nice day!

Andrew Lynch

But... Isn't that a WD drive?

(I thought you had problems getting them and the Quantum ones to work with the card...)

NobodyIsHere
February 22nd, 2009, 05:50 AM
But... Isn't that a WD drive?

(I thought you had problems getting them and the Quantum ones to work with the card...)

Hi! Thanks! Yes, that is a WD drive. The XT-IDE has never had any problems with the WD drives. They have always worked just fine with the XT-IDE prototype.

My other project, the N8VEM Disk IO IDE, has problems with WD drives. Those problems have been resolved as of last night. There is a timing issue that can be corrected using a modified cable and a small PCB which qualifies reads and writes. Last night I installed a WD drive on my N8VEM system and performed the IDENTIFY command, formatted the drive, accessed the C: drive, copied files, etc. There are probably still some residual issues left but I think we have a handle on the major timing issue.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
February 22nd, 2009, 05:53 AM
Congratulation! Please let us know the detail about what type of ide harddisk that supported by this card. Thankyou

Hi! Thanks! So far I have only tested it with the one WD drive. I'll be building another wire wrap prototype for Hargle for his additional testing and software development. I have a few IDE drives around and may try some more drives for curiosity sake.

Thanks and have a nice day!

Andrew Lynch

hargle
February 22nd, 2009, 06:04 AM
So are you going to start selling them someday?

Yep. The next step is verification that it really is doing what we hope it's doing.
Then we need to see if we can reduce the price somewhat by using parts that are easier/cheaper to locate. That'll require a bit more rework and regression testing. (I discussed this earlier in the thread) Currently costs are over $20 per board just in ICs, and I want to see if we can shave off at least 1/4 of that.
My target price was ~$20 per card, full assembled, with PCB and a slot bracket.

I may be optimistic, but I'd like to start selling by May of this year.



Please let us know the detail about what type of ide harddisk that supported by this card.

It should work with any IDE drive that supports LBA access methods. In other words, any IDE drive that you've picked up since about 1992 should work. Currently the size limitation is at 137G, (28Bit LBA limits) but you will bump into operating system limits before that, likely in the 8.4G range, with several partitions. Hope that's big enough!

I'm also targeting full support for CF cards and CD-ROM support. (completely untested so far)

For software, I'm going to be writing a BIOS flash upgrade utility, and will need to write a CD-ROM driver too. I'm going to try and put as many bells and whistles into the BIOS itself, stuff like being able to boot to different drives (B: drive for example) would be pretty cool if I can do it.

All of it is open source, and gerrydiore has promised a nice PDF manual to go with it.

It'll have a website to download software and stuff from, but I'm wondering if I should ship a 5.25" floppy with it with all the drivers on it? That would be kinda funny.

Terry Yager
February 22nd, 2009, 08:24 AM
Will these be in kit form or fully assembled or both?

--T

hargle
February 22nd, 2009, 08:30 AM
They'll be available as both solder-it-yourself or prebuilt and tested.

Unknown_K
February 22nd, 2009, 08:31 AM
Depending on the final price I think I will be getting one.

84TAVeRT
February 22nd, 2009, 09:12 AM
put me down for 2

rangga
February 22nd, 2009, 09:28 AM
@lynchaj & hargle
Wow.. Pretty Cool ... Salute with all your effort to make our xt machine compatible with the 'modern' peripheral. To be honest..I can't wait to plug this new card on my old 8 bit isa slot.

hargle
February 22nd, 2009, 09:41 AM
Just to get a feel for how many PCBs to order, please use the poll to fill in how many you want.

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

thanks!

NobodyIsHere
February 22nd, 2009, 10:50 AM
Whoa Big Fella! Lets hold on a moment here and consider some facts. First, the prototype has just started working and is a long way from done. Second, it is very premature for discussions on pricing the unit. Very little testing has taken place and although the software is feature complete *with a specific hard drive* but is not done yet. Who knows what other issues remain? Regarding IDE hard drives there are *lots* of variations to consider and throwing CF and CD-ROMs into the mix further complicates the matter.

When a project is done "at cost" that has to realistically include more than just the sum of the costs to purchase the components. There are legitimate costs associated with development as well. Hargle has personally put in at least $100 into just prototype parts, shipping, etc and I have put in my own as well. Selling them "at cost" should include *all* the expenses and some margin for unknown expenses. Pricing too low makes the project "at a loss" for development which dooms future projects. I believe few if any hobbyists realistically expect their purchase price to be subsidized by the developers.

A realistic estimate should take into account some actuals plus some legitimate margin in my opinion. On the N8VEM project, I set my PCB price at $20 because by the time a manufactured PCB arrives and taking in to account all the expenses such as tooling fees, shipping, PCB features, parts consumed, etc which is about what my costs are. I do include a small margin for unknown costs which basically allows me to gather enough funds to reorder additional PCBs without raiding the grocery money. Its non-profit thats for sure but at least I am not losing money with every PCB.

I appreciate the excitement and don't want to be a buzzkill here but people need to have some realistic expectations. $25 assembled and tested is no where near realistic, IMO. Not even close. I doubt very much you could buy even the parts for that much less with the PCB.

Remember, this board has gold fingers on it for insertion into a ISA card edge connector. That fact alone makes it more expensive than a similar sized PCBs. Also, please don't confuse advertised PCB "unit costs" with real expenses. "Unit costs" are what you pay *after* you pay for everything else up front. Real "unit costs" have to amortize the overhead costs of tooling, shipping, etc.

Thanks and have a nice day!

Andrew Lynch

PS, just for discussion purposes and to double check my assumptions, I did a quick check at Jameco to make a parts list and get a first estimate of cost to purchase the components, not including the PCB. My initial parts list cost estimate comes out to be about $28 per board. I suppose that could be improved somewhat with multiple combined orders but probably not a whole lot. The parts list is for just the cheap "valuepro" and generic parts. Nothing fancy like machine pin sockets or name brand parts. Just the basic stuff needed to get it to work and does not include solder, cables, etc. Some parts have slightly higher than necessary minimum order quantities which does affect total price but it does not include shipping, handling, or sales tax if applicable. I think $25-$30 for parts *alone* is probably in the realistic range. The cost estimate for PCB is TBD and will be in addition to that and assumes no further respins. I uploaded the initial parts list on the N8VEM wiki so feel free to double check. I welcome if anyone would like to do their own cost estimates for the parts for comparison purposes. Check with other vendors such as Digikey, Mouser, JDR, etc for a single build so we can have a similar list for comparison.

bobwatts
February 22nd, 2009, 11:34 AM
Hello Mr. Lynch

I agree with your assessment. On Cost. ( And everything else for that matter.)

Before hargle, you, and others project is over, I am pretty sure costs will go up substantially, and the main proponents of this project also deserve to be paid.

I'm quite sure at the end the cost will be reasonable, but people should probably expect previous estimates to be low, possibly real low. :p

I forget what I originally paid for that Acculogic sIDE card many years ago, brand new, but I'm pretty sure it was darn cheap, probably a NOS piece that I found at either a computer show, or at a computer shop.

I have been following this project closely, and am very impressed by what you and others have accomplished. Looking forward to the finished product, should one come out of this. I know that a lot of testing and "polishing" have yet to be done, and wish you continued success.

bobwatts
EartH

frozenfire75i
February 22nd, 2009, 11:36 AM
What about us with the 5161 EXP uint, will that tiny 500MB IDE drive be enough draw to keep that 130Watt XT Power supply happy?
.
.
.
.

Ole Juul
February 22nd, 2009, 01:36 PM
I agree with bobwatts. I think it could easily be much more expensive. Personally I would be happy with a finished card under $100. A bag of parts with software and instructions would certainly be worth $50 and I'd be surprised if you could do it for much less without cutting into the grocery money. We'll see. :) Anyway, this is indeed an impressive project. Congratulaions for getting this far.


frozenfire75i: "... will that tiny 500MB IDE drive be enough draw to keep that 130Watt XT Power supply happy?"
Haha Where I come from power supplies do better with less draw. :)



.

NobodyIsHere
February 22nd, 2009, 07:02 PM
Hi All! OK, tonight I got a chance to do some testing with various IDE hard drives. I didn't get too far because I found two of my recently purchased old IDE drives have turned out to be duds and that took some time to sort out. So we can safely discount the dead Maxtor and Seagate drives as not relevant.

The XT-IDE controller works great with the WD AC28400R. It does everything you'd expect. I tried it with an older Quantum 270LPS and the controller recognizes it but does not work with it. Same thing for a newer Quantum 4.3 GB drive. Similar for an older Fujitsu IDE 1.2GB drive. Its seems there are probably some tweaks needed yet for these drives. I will be going through my limited supply of IDE drives and sorting out which work and which don't.

At least with the N8VEM Disk IO IDE, it tends to favor certain kinds of drives due to timing and other factors. That may be in play here as well although the good news is the XT-IDE BIOS is actually reading the IDENTIFY strings which implies the drive is working but something is amiss in the driver/BIOS. The drives typically are letting me partition them, format them, and seem to be working but when I try to boot with them the controller goes off into never-never land and does not return.

Still, its early with the first feature complete BIOS and these are quite impressive results so far. One for sure drive (the WD AC28400R) and several near misses implies the overall design is sound and with some adjustments the board will work. Soon I will begin work on Hargle's own prototype board and then he can start fixing the issues and expanding the list of known good drives.

More as things develop. Thanks and have a nice day!

Andrew Lynch

gerrydoire
February 22nd, 2009, 07:17 PM
The drives typically are letting me partition them, format them, and seem to be working but when I try to boot with them the controller goes off into never-never land and does not return.
Andrew Lynch

I encountered the same deal with my Acculogic & CF Cards, could do it all except boot from the thing, at least not on a 2 gig CF CARD, no problems with 128 meg card..

frozenfire75i
February 23rd, 2009, 05:46 AM
I think y'all otta be looking at a hardcard type of setup.

kb2syd
February 23rd, 2009, 06:13 AM
I asked this over in the survey thread, but does this use an IRQ? Is it selectable so it could work in a Tandy machine?

I have many smaller IDE drives laying around. I can ship you a few if you need to test more. I would like them back if you do need them.

Kelly

hargle
February 23rd, 2009, 06:14 AM
The XT-IDE controller works great with the WD AC28400R. It does everything you'd expect. I tried it with an older Quantum 270LPS and the controller recognizes it but does not work with it. Same thing for a newer Quantum 4.3 GB drive. Similar for an older Fujitsu IDE 1.2GB drive. Its seems there are probably some tweaks needed yet for these drives. I will be going through my limited supply of IDE drives and sorting out which work and which don't.


how big is the AC28400R?
I could see some issues with drives smaller than ~8 gig. The drive parameter table gets set up a little different in those cases, and I very well may have a bug there. As you've said, the ID string shows up fine, but FDISK and format are wonky. That's exactly how I'd expect a drive that has a weird parameter table set up to act, so this could be 100% my fault. For now, if you can stick with testing drives > 8 gig, then we could move forward while I figure out what the deal is on my end. This is very likely not a hardware problem.

NobodyIsHere
February 23rd, 2009, 06:30 AM
I think y'all otta be looking at a hardcard type of setup.

Hi! Thanks! If that means increasing the size of the PCB to allow for mounting holes then its a non-starter. Increasing the area of the PCB directly increases its cost and price sensitivity is already an issue.

The PCB layout already exists and unless there is a really compelling reason to change it we are well past the time for major changes at this point. Making design changes now would require changes to the PCB and prototype. The prototype and BIOS software both reflect the proposed PCB design and pushes the project back to square one.

Feature creep and cost sensitivity are directly opposing forces and have to be balanced. A low cost design means low part count and small PCB size. Adding features increases part count and PCB size which directly increases the cost of the unit.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
February 23rd, 2009, 06:45 AM
how big is the AC28400R?
I could see some issues with drives smaller than ~8 gig. The drive parameter table gets set up a little different in those cases, and I very well may have a bug there. As you've said, the ID string shows up fine, but FDISK and format are wonky. That's exactly how I'd expect a drive that has a weird parameter table set up to act, so this could be 100% my fault. For now, if you can stick with testing drives > 8 gig, then we could move forward while I figure out what the deal is on my end. This is very likely not a hardware problem.

Hi! Thanks! The WDC AC28400R is a 8.4 GB drive and works fine as is. The three drives I tested (two Quantums and a Fujitsu) are all smaller than 8 GB and did appear in the discovery phase but not fully supported yet. Please don't take this as a criticism as there is no blame or fault. This is normal development and testing. We will find problems and we'll fix them.

As the IDE controller goes through testing with various devices we'll see all sorts of compatibility issues pop up. Some hardware and some software. I have already seen hardware issues on my list of improvements. No show stoppers yet but there may yet be some yet to be found.

What might help is a "verbose" version of the BIOS code. Add print outs and prompts as the BIOS goes through the steps of its discovery and installation phase so we can see where it is choking. Even extend into boot process so its obvious were the problems are or what portions of the code are working. That way I can give you better feedback of the testing of the testing I can do with the stuff I have.

On the N8VEM Disk IO project, while it was having initial problems with the IDE interface, I made a wiki page to document what successes the builders were having and how they did them. Maybe there is something along those lines we can do here as well.

Given the complexity of making a compatible IDE interface and BIOS I recommend we do a pre-release test phase to help shake out the bugs before a general release. It's something to consider to find the problems with experienced hobbyists before releasing the controller to the public who may not have the experience or background to deal with problems they discover.

Thanks and have a nice day!

Andrew Lynch

gerrydoire
February 23rd, 2009, 07:07 AM
Given the complexity of making a compatible IDE interface and BIOS I recommend we do a pre-release test phase to help shake out the bugs before a general release. It's something to consider to find the problems with experienced hobbyists before unleasing the controller to the public who may not have the experience or background to deal with problems they discover.


I have a pile if IDE drives here to try out...

hargle
February 23rd, 2009, 09:37 AM
I have a pile if IDE drives here to try out...

Part of the benefit of this new device is that it works with new hardware.
While lots of us probably have a clunky old 200MB drive from 1990 in our closets, I think we're all better served by using more modern drives, which I'd hope are more compatible/flexible with our design hardware. IOW, I'm not going to spend a whole lot of time figuring out why a drive that is 15+ years old doesn't work, when a perfectly good, bigger and newer drive works just fine.

Just my opinion.

Having said that, I am certainly going to look into drives smaller than 8.4 gig for any BIOS bugs, but beyond that, I wouldn't break out the logic analyzer and scope to find that ancient drives are more finicky than new ones.

kb2syd:
I believe right now we're tied to a single IRQ, 5 IIRC. What needs to be done to work on a Tandy? Does it just have to be selectable to a different IRQ?

Either way, the BIOS at this moment isn't using IRQs anyway, so it'll work! ;)
(that's temporary)

kb2syd
February 23rd, 2009, 10:05 AM
I believe right now we're tied to a single IRQ, 5 IIRC. What needs to be done to work on a Tandy? Does it just have to be selectable to a different IRQ?

Either way, the BIOS at this moment isn't using IRQs anyway, so it'll work! ;)
(that's temporary)

I think that's all that is needed.

See ftp://ftp.oldskool.org/pub/tvdog/tandy1000/documents/t1khdhow.txt

for some notes.

Kelly

gerrydoire
February 23rd, 2009, 10:50 AM
I think that's all that is needed.

See ftp://ftp.oldskool.org/pub/tvdog/tandy1000/documents/t1khdhow.txt

for some notes.

Kelly

Forgive my lack of experteeeze in this stuff.

But what is the difference between using an IRQ and not using an IRQ for this sort of stuff, IRQ=More stable?

per
February 23rd, 2009, 11:01 AM
Forgive my lack of experteeeze in this stuff.

But what is the difference between using an IRQ and not using an IRQ for this sort of stuff, IRQ=More stable?

IRQ's are one of two (DMA is the other) ways for Expansion cards to communicate with the System without help from a program. An IRQ request from a card will make the processor interrupt (unless interrupts dissabled) to run a (usually short) subroutine to take care of the hardware's needs. It's Hardware stuff, and the BIOS only need to store the interrupt vector containing the subroutine(s).

gerrydoire
February 23rd, 2009, 11:57 AM
Speaking of IRQ's, remember when all us fools had to play tic tac toe with cards, trying to get all cards to work without conflicts before Intel blessed us with plug and play, how come people who bought MAC's never had this problem way back when?

Agent Orange
February 23rd, 2009, 02:31 PM
Part of the benefit of this new device is that it works with new hardware.
While lots of us probably have a clunky old 200MB drive from 1990 in our closets, I think we're all better served by using more modern drives, which I'd hope are more compatible/flexible with our design hardware. IOW, I'm not going to spend a whole lot of time figuring out why a drive that is 15+ years old doesn't work, when a perfectly good, bigger and newer drive works just fine.

Just my opinion.

Having said that, I am certainly going to look into drives smaller than 8.4 gig for any BIOS bugs, but beyond that, I wouldn't break out the logic analyzer and scope to find that ancient drives are more finicky than new ones.

kb2syd:
I believe right now we're tied to a single IRQ, 5 IIRC. What needs to be done to work on a Tandy? Does it just have to be selectable to a different IRQ?

Either way, the BIOS at this moment isn't using IRQs anyway, so it'll work! ;)
(that's temporary)
The Tandy 1000SX needs to be selectable. I believe they use IRQ 2. I had to rewire my Western Digital controller back in 1987 to get the Seagate ST-225 to boot. I still have the wiring diagram and jumper settings if anyone is interested.

Agent Orange

hargle
February 23rd, 2009, 02:32 PM
Andrew,
So what ballpark price do you suspect these cards can be manufactured for?

Since I've thrown everyone for a loop on my lowball $25 estimate, I guess I'd like to see what someone who has actually done a PCB run throws out for a $$ amount. ;)

I was figuring:
$8-10 for PCB
$15 for parts

As premature as it may be, we do need to start getting some feedback as to how many potential customers there may be, so that I can start pricing components on a bulk scale. There may be some cost breaks if we do 100 boards for example.

I was also hoping that we could examine each part and try substitutions if there are cheaper, but similar parts available. For example, changing from a DIP BIOS to a PLCC could save a couple bucks each, but if that requires another 3 weeks of job processing and retooling for each change, then maybe it isn't in our best interest to go the cheap route. (although I'll gladly wait!)


And, I've sourced a somewhat cheaper solution for the metal brackets:
http://mouser.com/Search/ProductDetail.aspx?qs=g5fiFmky%2fl4bFM8ICVGfOQ%3d% 3d
(assuming we'd do 100 of them)

The data sheet has all the dimensions of where the mounting tabs are. I just wanted to make sure that our board fits on them.

NobodyIsHere
February 23rd, 2009, 04:40 PM
Hi Hargle! Thanks! My Jameco parts list cost estimate did not include a bracket so that goes in addition. Here is a bracket at Jameco (http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=1582356&)which adds another $2 to the parts cost.

At this point I don't it wise to speculate on a unit cost. It is considerably more than $25 for sure. Typically home brew/hobbyist/small business electronics projects are in the $50-$100 range. I would use my friend Vince Briel as an excellent example of well done electronic kits (http://www.brielcomputers.com/store.html). I think his PockeTerm or replica 1 Multi I/O Board KIT projects are probably comparable in scope and complexity to the XT-IDE board and those is going for $60 (soon to be $65) and $79 respectively plus shipping and handling. I know no one wants to hear this but I feel an obligation to set some realistic expectations to prevent larger problems down the road.

The discussion on price is getting way ahead of ourselves though. Probably what we need is to do a low initial production of the PCBs and do some in depth testing. Let some experienced hobbyists source parts, comment on the design, do some serious research, look for improvements, and try to get the costs back down. Yes, that might mean a respin of the PCB which could cause a significant delay but then we could roll in some of the feedback we've gotten already.

We have to keep "feature creep" under control though or this project is doomed. If we add every possible doodad to support every conceivable combination the board will be so complex the likelihood of escaped defects is enormous. Due to conflicting IDE implementations, writing a BIOS to support it all is at least extremely difficult to do and quite likely impossible. Also the price goes through the roof and no one likes that. Basic simplicity is our only real hope of success and it means trade offs are necessary.

I know this does not answer your question but I hope it helps anyway. Thanks and have a nice day!

Andrew Lynch

PS, here is another somewhat comparable electronic kit as a reference point. It's the Z80ICE (http://www.tauntek.com/Z80-In-Circuit-Emulator.htm) and is roughly approximate for complexity and parts. I am sure there are many examples of electronic kits out there. The SVD (http://www.thesvd.com/SVD/ordering.php) is probably in the comparable zone too. Feel free to post comparable examples which cost more or less to give us a good idea of realistic costs.

NobodyIsHere
February 24th, 2009, 03:35 AM
Hi! If you'd like a good cost estimate, you don't have to rely on just what I am saying. We can do a grass roots estimate and build up the cost to make some of the boards. Just make some assumptions and get some quotes. There are tons of vendors out there who are glad to work with you. I do it frequently. I've already provided a Jameco parts quote. Hopefully some people will gather other comparable quotes and see how much they are. I think $25 in parts is probably a good working estimate.

Regarding the PCB, let's assume a couple of well known domestic suppliers. I've dealt with 4PCB and they are good and PCBexpress is also a commonly used supplier. For an initial lot of 25 units, 2 layer with 62 gold fingers with dimensions of X=4.55" and Y=4.25" (~20 square inches). Leaving all the other parameters at the default setting. 4PCB quotes approximately $30 each plus s/h. PCBexpress quotes $28 plus s/h. I suppose with more quotes we can see the range estimate expand a little but this gives a pretty good idea of what a PCB costs. Using off shore PCB fabricators can reduce costs by probably around 1/4 to a 1/3 but the lower unit costs are often offset by higher shipping costs. The savings are not as dramatic as some might think. However they come with their own issues (non-English speaking, uneven quality, no recourse if things go wrong, etc) and are higher risk.

Increasing the size of the production lot will decrease incremental unit cost but until this design goes through an initial shakedown run I certainly don't recommend going with a large lot. 25 units is a good starting point as you can see we are already talking about hundreds of dollars up front. Going to an initial run of 100 units will scale the total costs upwards significantly. Not many people have that sort of extra cash laying around.

So hypothetically speaking if the price to build a unit is $50-$60 each ($25-$30 for PCB and $25-$30 for parts) to gather enough bench stock for an initial run of 25 units is about $625-$750 for the PCB and $625-$750 for the parts for an approximate total of $1250-$1500 in up front costs not counting your own tooling and supplies. Then assuming no charge for labor, I estimate there is probably around 1 hour each by the time all the setup, assembly, test, debugging, repair of broken units, and packaging is done. That may be low but just for quick math that is ~25 hours of labor. Of course, these are all just quick "back of the envelope" estimates but they are backed up with real quotes.

Getting multiple quotes and some scrubbing might reduce the estimate somewhat but it is not going to fundamentally change. These are all things to consider when computing a price so you can see I do not think we are ready to set a final unit price quite yet. We need more data and some better information. Doing a small initial run can help us get enough expertise and experience to reduce the cost as much as practical.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
February 24th, 2009, 06:09 PM
Hi! More testing tonight. The good news is that the WD400BB (40GB) and WD800BB (80GB) both work perfectly and much quicker than WDC AC28400R (8GB). That is great and the more recent drives work much better.

I tried again with the larger Quantum Fireball SE (4GB) and it almost works. I tried the old "FDISK /MBR" trick thinking that might help but no luck. I suspect there is a BIOS problem with the older pre-8GB drives as Hargle said earlier.

There are still 3 IDE drives on the stack for testing. I don't recall their exact sizes but I think they are two Seagates and a Maxtor. More testing tomorrow. I am also working on a N8VEM ECB prototype board with 6809 SBC on it so I am splitting my time between installing/testing IDE hard drives and wire wrapping.

Thanks and have a nice day!

Andrew Lynch

PS, I do not own any CF components and the controller was designed for IDE hard drives. However, that does not mean IDE to CF adapters *won't* work with the controller. I have seen several N8VEM builders get CF devices working with the Disk IO board so I am fairly sure its possible. I you want to determine if your particular CF device will work with the XT-IDE controller you can send me a test unit to run tests on. If you include a return shipping container with postage I will return it to you when done. Please PM me if interested.

hargle
February 25th, 2009, 05:36 AM
I tried again with the larger Quantum Fireball SE (4GB) and it almost works. I tried the old "FDISK /MBR" trick thinking that might help but no luck. I suspect there is a BIOS problem with the older pre-8GB drives as Hargle said earlier.


Yep. I'm working on a new generation of the BIOS code, much more organized and about 99% of the original acculogic code is now gone. (so I took their name off the sign-on text).
I've got my new code fdisking, formatting, and booting drives properly, and the door is now open to get the eINT13 support working, so that will come up shortly.

I wouldn't even bother testing with anything less than 8.4 gig at the moment, at least not until my new code base comes online. I've got some hard coded >8.4G values in my CHS->LBA conversion routine that may be causing you some troubles.

My only hold up is that I don't have any drives in my stockpile that are smaller than 8.4 gig, so I've got nothing to test with! ;) I'll grab a couple from work this week.



PS, I do not own any CF components and the controller was designed for IDE hard drives. However, that does not mean IDE to CF adapters *won't* work with the controller.


I have an IDE->CF adapter, and a couple CF cards, so I can test some of that on my end too. I will also be testing CD-ROM support (at least identification) when I get a moment as well.

gerrydoire
February 25th, 2009, 05:56 AM
Yep. I'm working on a new generation of the BIOS code, much more organized and about 99% of the original acculogic code is now gone. (so I took their name off the sign-on text).
I've got my new code fdisking, formatting, and booting drives properly, and the door is now open to get the eINT13 support working, so that will come up shortly.

I wouldn't even bother testing with anything less than 8.4 gig at the moment, at least not until my new code base comes online. I've got some hard coded >8.4G values in my CHS->LBA conversion routine that may be causing you some troubles.

My only hold up is that I don't have any drives in my stockpile that are smaller than 8.4 gig, so I've got nothing to test with! ;) I'll grab a couple from work this week.



I have an IDE->CF adapter, and a couple CF cards, so I can test some of that on my end too. I will also be testing CD-ROM support (at least identification) when I get a moment as well.

If I could help I would, unfortunetly I know absolutely nothing about programming..

I'm like Steve Jobs, the artist who is technically clueless...

Trixter
February 25th, 2009, 11:37 PM
I've got my new code fdisking, formatting, and booting drives properly, and the door is now open to get the eINT13 support working, so that will come up shortly.


That is music to my ears.


I wouldn't even bother testing with anything less than 8.4 gig at the moment, at least not until my new code base comes online.


Now THAT is funny. "Minimum drive size: 8.4G"

NobodyIsHere
February 26th, 2009, 04:38 PM
Hi! I did a bit more testing tonight. Since the <8.4GB drives are out due to BIOS issues I decided to focus on a couple of >8.4GB drives. One is a Seagate 15GB and the other is a Maxtor 10GB. Both appear to work at first, the BIOS recognizes them, I am able to use FDISK and make a partition and master boot record. On the Seagate it won't let me format and the Maxtor will let me format.

Neither lets me boot the system and both report some funky values to FDISK. They report they are 540MB drives sometimes and larger at others. They act rather similar but both neither are working properly. This all seems to me like there is some BIOS funkiness going on. This isn't a great report but it does tell us there are some BIOS issues we'll need to chip away at.

Thanks and have a nice day!

Andrew Lynch

hargle
February 27th, 2009, 06:22 AM
Neither lets me boot the system and both report some funky values to FDISK. They report they are 540MB drives sometimes and larger at others. They act rather similar but both neither are working properly. This all seems to me like there is some BIOS funkiness going on. This isn't a great report but it does tell us there are some BIOS issues we'll need to chip away at.

What operating system were you using for this? My (so far) testing has all been done with dos 6.22. Just making sure that your not hitting a 540MB limit due to an OS. 6.22 can do 2gig partitions, and see a drive up to 8.4G.

I'd like to switch over to my new BIOS codebase for all future testing, simply because it's got a better organization setup behind it.

I assume you're still testing on your pentium machine? there may be timeout/timing issues because your machine is running too fast and I'm only using simple loops to wait for timeouts. Perhaps you could turn off your cache to slow your machine down a bit and see if the funkies go away.

bobwatts
March 1st, 2009, 07:53 AM
HI Gang !

Just checking in, and the progress so far looks good!

I was curious about a couple of things however.......

........ what happens if you use the Acculogic sIDE BIOS *as is*? It worked very well the way that it was, albeit it probably didn't support drives above 528/540 meg. Never checked, didn't care.

Which leads me to my next question.... there seems to be a lot of interest in using large hard drives, 2.1G and larger. Although this would be nice, I'm wondering why (?). Are people actually USING 8088/8086 machines to do anything useful ? ( no offense intended of course! )

I would be very surprised if many ( or any ) people are actually using this class computer to access this website, or use them on the internet for many chores. I would be equally surprised if most people here were not using P III or P IV class machines or better for daily computing. ( I could of course be real wrong, after all this is the Vintage Computer Forum :p )

For me, using an XT type computer is only for "fun" or hobby activity, so HUGE HDD's would not be particularly necessary. The OS might be an issue, as you're limited to what OS you can use on an 8088/8086 machine, and most won't support massive HDD's anyway. ( DOS anyway )

Personally, I would like to see support for ATAPI IDE CD-ROM drives, but certainly understand if that is not doable.

Just curious and my 7˘ worth. :mrgreen:

bobwatts
EartH

gerrydoire
March 1st, 2009, 08:42 AM
Which leads me to my next question.... there seems to be a lot of interest in using large hard drives, 2.1G and larger. Although this would be nice, I'm wondering why (?). Are people actually USING 8088/8086 machines to do anything useful ? ( no offense intended of course! )


I have the Acculogic, and I have (1) 128 meg CF Card attached to it and it works as it should. Waiting for a 256meg CF and 512meg CF to come in, currently I don't think anything but type1 cards will work, them 80x type cards do not.

As you stated why would anyone need gigs of space on a computer that can barely run anything of practical use, I for one do not,
Even back in 1985 when I owned one I thought it was a slow worthless piece of crap (lol).

That being said, if the good folks here can make their own ide card for this type of computer (8bit PC/XT) that can push the limits why not, it's more about being able to do it than having any really practical use "i think".

If we were to collect every single program that was made to run on the IBM PC or XT, how much space would it take? I currently have a ton of games that takes about 400 megs of space.

:cool:

Terry Yager
March 1st, 2009, 09:15 AM
bw: I think the purpose of using drives in that category is one of availability mostly. There are just a helluva lot of them sitting around unused (how many boxes full do you have). OTOH, the smaller drives are becoming a littler scarcer these days.

--T

bobwatts
March 1st, 2009, 09:28 AM
Hello Mr. Yager!

Yes, I kinda figured that. Boxes of IDE drives.....yep, lot's of 'em!

But, I have boxes of "old" 540 meg and smaller also. Shame, but I literally threw out MANY boxes of old IDE 540 and smaller drives. Probably a box of Seagate 351A/X 8/16 bit drives.

Sadly, I haven't looked in years... I wonder how many still work.... I constantly read of people finding out that old HDD's simply "die" from sitting. I know that my IBM Server collection shows signs of this.

And a couple of years ago I was going through my motherboard collection, too late for a few boards that the damn bats had destroyed. Broke off the rest.

*****
Gerry, what software/programs are you using to access your CF cards, and what are you attaching them to? ( I think I know, but was curious in your case. Damn, I have used curious three times today...wonder what the limit is?)

bobwatts
EartH

gerrydoire
March 1st, 2009, 11:35 AM
********
Gerry, what software/programs are you using to access your CF cards, and what are you attaching them to? ( I think I know, but was curious in your case. Damn, I have used curious three times today...wonder what the limit is?)
********

Acculogic Side 1/16 Card, CF to IDE connector(cheap and common)
PC Dos 7.0, tried Dos 3.3 and it works as well.

Everything works as is without any modifications.

Its inside an IBM XT, which also has a Orchid 286 card and a 768k Quadram Card. Soundblaster card, MS Mouse Card, 1.44Meg Capable Floppy Card, and IBM CGA Card that came with it, all cards are 8 bit, unmodified as is, everything seems to work, 360k Floppy that came with it, 1.44 Black floppy to replace dead MFM HD.

The MB has a 8087, the Orchid is a 8Mhz 286 with a 80287.

That's about it..

bobwatts
March 1st, 2009, 12:03 PM
Hi Gerry !

We seem to have very similar machines. Don't know if you ever saw this:
http://home.fuse.net/bobwatts/xt.htm

My Acculogic sIDE card is somewhere else right now, don't know exactly where. ;)

How EXACTLY do you access the CF card? What program are you using to "see" it ? I have honestly never checked into using a CF card with anything other than WinXP, VISTA, or previous versions of Windows something. And they see the thing automatically, usually. Some older versions of Windows need drivers of course.

Thanks !

bobwatts
EartH

lither
March 1st, 2009, 11:06 PM
How EXACTLY do you access the CF card?
DOS on XT machine (with my silcon valley ADPL-50)
Fdisk then format
be sure to set partition active if you want to boot from the CF card
and it will be accessed just like a common harddrive

Dos on 286/386/486/586 ,set the bios HD type first(my 586 M/B has a auto-detect function) then it can be accessed under dos
in window XP system , a USB cardreader...

gerrydoire
March 2nd, 2009, 04:54 AM
Hi Gerry !

We seem to have very similar machines. Don't know if you ever saw this:
http://home.fuse.net/bobwatts/xt.htm

My Acculogic sIDE card is somewhere else right now, don't know exactly where. ;)

How EXACTLY do you access the CF card? What program are you using to "see" it ? I have honestly never checked into using a CF card with anything other than WinXP, VISTA, or previous versions of Windows something. And they see the thing automatically, usually. Some older versions of Windows need drivers of course.

Thanks !

bobwatts
EartH

I just used an IDE<>CF Connector, and used it like it was a regular hard drive.

I think you have to use Type1 cards only, I haven't tested more than 2 cards yet.

With a 2gig 80x card, it would read and write to the card, but refused to boot from it.

I have a few more type1 size cards comming in the mail to try out.

I think if you can have two 512meg cards on a PC or XT you have more space than you will ever really need.

Trixter
March 2nd, 2009, 09:41 AM
I think if you can have two 512meg cards on a PC or XT you have more space than you will ever really need.

Not if you're doing development :-) My program partition is 100MB and full. I have to delete old builds and .bak files whenever I start a new project or I don't have room.

I have a 320MB IDE and a 340MB CF-to-IDE-adapter in my XT; the CF is the backup drive. I sync files over to it after every four hours of work or so.

hargle
March 2nd, 2009, 01:38 PM
I managed to find some old drives at work, and have (I believe) gotten them to properly configure in my new BIOS code base. I successfully transferred files from an 800MB drive, a 1.5G drive, and of course, my main 8.4G test drive.
(no eINT13 yet, so I can't test bigger than 8.4G)

One of the drives I managed to find was an 82MB(!) western digital drive, which was manufactured in 1992. It didn't work. Then I realized that it didn't support LBA access methods, which apparently came online about 1994.

This lead me to an interesting dilemma. Do I add CHS support to the BIOS?
I don't really want to. The whole idea behind this controller and breaking all the size barriers was that we'd put drives on there that were more modern and easier to get ahold of.

For now, I just put a warning message up on the screen that the drive is too crusty to work, and then I disable it.

There should be no hardware concerns doing CHS access, but it will require a lot of code debugging and testing, and to be honest, this 82MB drive is so old that the motor is going out and it's hurting my ears, so I really don't want to mess with it any more than I have to.

I personally see no reason to have support for it. If you're too cheap to use a drive manufactured after 1994, I'll send you one for free. ;)

The only reason I could think of would be to transfer some files off an old drive onto a newer one, but you could do that on any machine, not your XT.

opinions?

kb2syd
March 2nd, 2009, 05:46 PM
I was going to grouse because I would have no way to use all my "little" drives. But then I figured why bother. I have plenty of "tweeners" that support LBA. Really, what does it matter. I personally would rather have anything that worked in an a 8-bitter than to add more debugging and development time.

bobwatts
March 2nd, 2009, 06:28 PM
Hi Gang !

Isn't that interesting, on a "Vintage" computer forum, to have to choose between ancient CHS or newer LBA ? :cool:

Easy choice, LBA !

Got lots of ways to access other ancient drives if I have to here in the BODADC ( Basement of DOOM and Diet Cola ) :twisted:

bobwatts
EartH

gerrydoire
March 2nd, 2009, 07:50 PM
Not if you're doing development :-) My program partition is 100MB and full. I have to delete old builds and .bak files whenever I start a new project or I don't have room.

I have a 320MB IDE and a 340MB CF-to-IDE-adapter in my XT; the CF is the backup drive. I sync files over to it after every four hours of work or so.

Wouldn't it make more sense to development in emulation on a faster computer?

Trixter
March 2nd, 2009, 09:56 PM
This lead me to an interesting dilemma. Do I add CHS support to the BIOS?


No. The whole point is to keep up with modern stuff. I would much rather see time spent on attaching SATA drives and/or CF.

Trixter
March 2nd, 2009, 10:15 PM
Wouldn't it make more sense to development in emulation on a faster computer?

Not if your target is the real machine and you have timing/speed-sensitive code you are writing :-) No single emulator gets the timing of old x86 hardware correct, not even MESS (although Andrew Jenner has done wonders with the CGA emulation). (In fact, one of my projects is a benchmark meant to help emulation authors, but I digress.)

When I write a general purpose program/application/whatever, I do so on whatever my modern machine is. When I program for fun, I do so directly on the target machine. My last project (http://www.oldskool.org/pc/MONOTONE) took three months and could have gone much faster on a better machine, but part of the whole point of that project was to answer a dare by a friend. The dare was to write a tracker-like music program in object-oriented code -- something you typically don't do on a 4Mhz 8088 -- that runs on a 128KB machine and can use a speaker for output. Because I coded on the metal itself, it forced me to think of the most efficient way of achieving this goal as I wrote the code. The end result was that I not only met the challenge, but I tossed in Adlib support just to prove it was truly OOP and designed properly (Adlib support was added simply by descending the hardware output object) instead of just a hardwired PC speaker hack.

I think that one trap that plagues developers -- of every era and platform -- is the desire to build applications on the fastest machine they can get their hands on. Sure, this makes builds a lot faster, but if speed is an issue (which it is with my hobbyist programming projects), you don't have any sense of how the program will run on its intended target platform. When I look at OpenOffice (a wonderful program, I'm just using it as an example), I wonder why I need a Pentium and 300MB of RAM just to bring up the word processor.

Me personally, programming directly on the metal gives me the most enjoyment. Why on earth is this? Because it forces me to think deeper and more effectively. On fast machines, it's too easy to get caught up in change-compile-test-change-compile-test in rapid succession. Because building a project takes at least 2 minutes on a slow machine, I find myself sitting and just thinking about what to do next, or re-reviewing what I had written, because I don't have the luxury of frivolous compiles. The end result is better design and the occasional surprise of a program that compiles and runs perfectly on the first try.

Ahem.

All this being said, I am -- gasp -- upgrading (!) to a Tandy TX for my next project, mainly because the project has the unique requirement of needing composite video output and a Tandy sound chip. There are several machines that meet this need -- a PCjr, any Tandy 1000/HD/EX/etc. -- but the TX is the fastest one that meets this need, so why not use it?

gerrydoire
March 3rd, 2009, 06:24 AM
Hargle, forget real hard drives, work on CF compatiblity damn it!! :)

JT64
March 3rd, 2009, 11:08 AM
I just used an IDE<>CF Connector, and used it like it was a regular hard drive.

I think you have to use Type1 cards only, I haven't tested more than 2 cards yet.

With a 2gig 80x card, it would read and write to the card, but refused to boot from it.

I have a few more type1 size cards comming in the mail to try out.

I think if you can have two 512meg cards on a PC or XT you have more space than you will ever really need.

I have an ide ADP50L adapter, my type one CF 512 MB card type one do not work very stable. My 2 GB type II CF work like a charm on my PC XTRA, with reduced size.

However i have discovered that CF card do not generally like the main DOS OS FILES and MBR to be written more then once without a lowlevel format.

JT

NobodyIsHere
March 3rd, 2009, 02:05 PM
Hargle, forget real hard drives, work on CF compatiblity damn it!! :)

Excuse Me? How much hardware, software, money, or time have you personally put into this project?

You are in no position to demand anything.

Andrew Lynch

gerrydoire
March 3rd, 2009, 02:33 PM
Excuse Me? How much hardware, software, money, or time have you personally put into this project?

You are in no position to demand anything.

Andrew Lynch

I'm the Ayatollah of Rock n' Rollah, that's why!!

:yesmaster:

mbbrutman
March 3rd, 2009, 03:35 PM
No, actually you are just contributing to the nosie problem around here.

Time for a time out ...

hargle
March 3rd, 2009, 08:26 PM
BIOS successes today.

Multiple HDDs work now. Tested a few differently sized drives and both drives ID in POST and are able to fdisk, format and copy files as expected.

...and...drumroll please...

Enhanced INT 13 support is now working! I just got finished formatting a 250G* hard drive and it booted fine, and after copying a bunch of files over to it from drive D:, I then moved it onto my modern test system and it booted there too.

the format took close to an hour and half to complete, and that's on my 486-33 machine. I can't imagine what it's going to be like on a 4.77MHz box. I think it's a very, very good thing that you can prep a hard drive on a modern machine and then move it over to the XT.

I've stubbed out eINT13 verify command for now, but the basic routines of presence check, get drive params, read and write all work as they should. I should probably copy a bunch of files over to the drive on another machine and try to read back something that is way out on the drive just to make sure, but so far everything is working perfectly.

Next up, CD-ROM identification and CF support. CD-ROM will require an entire drive to be written, so CF will likely get my attention first.


-----------
* some notes:
1) In order to use eINT13 support, you need an O/S that uses it. I used win98SE DOS to fdisk and format the drive. DOS 6.22 will only see 8.4G, and will only allow partitions to be 2G in size. I do not know if win98SE DOS will work on an 8088 processor.

2) win98 DOS has some display bugs. My 250G drive showed in FDISK and format as only having 65533MB available. After formatting, I have ~130,405.59MB free. (I have some files on it, so I'm not sure of the exact size at the moment) Anyway, these appear to be cosmetic bugs only.

3) the reason a 250G drive is only ~130G is because we've only got 24Bit addressing available in LBA mode. It would require 48Bit LBA to break that barrier. It's possible to add support for that in the BIOS, and I likely will do it just for kicks, but it won't be done til a rainy day. 137G is enough for an 8088 machine!

Gerry, these notes are the kinds of things that should go into the PDF documentation for this card when it's ready for production. I'd like to put up a wiki somewhere for it too. I think these types of questions are going to come up often.

MikeS
March 3rd, 2009, 09:28 PM
From a command prompt W98/SE FDISK and FORMAT do indeed report drive sizes >64GB incorrectly (64GB less than actual); a replacement for FDISK is available from Microsoft:
http://support.microsoft.com/?kbid=263044

Format is initially incorrect, but the final size is correct; AFAIK there is no fix from MS:
http://support.microsoft.com/?kbid=263045

BTW, although I don't think I'll have any use for this project, I nevertheless take my hat off and kudos to you guys for making it a reality!
Great stuff!

mike

rangga
March 4th, 2009, 11:21 AM
@hargle
sounds like to good to be true ... but is true.

this room is on fire now, hargle

two thumbs up!!

Scott_Christensen
March 4th, 2009, 09:41 PM
Today I found the n8vem project on "hackaday" which led me to discover the XT-IDE files there.

And that led me to this project here on this forum.

I think its really cool what you have done with the extended bios rom for this interface.

When I created the XT IDE interface I was using a 386 as a host for development (way back in 1997) with the target of an embedded 80c188 microprocessor board.

This board had its own task switching kernel so doing anything in DOS wasn't in the cards.

With a 10mhz XT I was able to read at about 20k-bytes per second, if memory serves.

(wire wrap proto card)

Anyway, cool that you guys are using this thing.

BTW, xtide.c compiles with Turbo C 2.01 which can be had for free here:

http://altd.embarcadero.com/download/museum/tc201.zip

Terry Yager
March 5th, 2009, 11:44 AM
Scott Christensen...hmmmn, why does that name seem familiar?

--T

hargle
March 5th, 2009, 01:51 PM
yeah, do we owe you royalties on the design? :)

thanks for your work, you saved us a lot of hours.

NobodyIsHere
March 5th, 2009, 05:07 PM
Scott Christensen...hmmmn, why does that name seem familiar?

--T

Hi Terry! There is a Ward Christensen of XMODEM fame. He is/was pretty famous in the CP/M and vintage computer community.

Scott, are you related to Ward Christensen?

Thanks and have a nice day!

Andrew Lynch

Scott_Christensen
March 5th, 2009, 06:16 PM
Royalties? Ha, no.

Besides I borrowed heavily from the CoCo schematic described on the same website where you can find XT-IDE, adapting it to the XT bus.

http://mylinuxisp.com/~jdbaker/oldsite/images/CoCoIDE.gif

I published it for exacty what you guys are doing here.

Ward Christensen, nope. Not a relative.

I'd love to see the source to the bios driver at some point.

Terry Yager
March 5th, 2009, 08:18 PM
Ah, CoCo IDE...yeah, that's it.

--T

hargle
March 6th, 2009, 07:32 AM
Scott, do you still have an XT/PC? I'd very much like to send you a complimentary board of this design when we're finished with it.

The entire project will be open source: schematics, layout, BIOS, drivers, and even the BIOS flash update program. I'm not quite ready to unleash this BIOS onto the world source-wise just yet, due to some cleanup and further debugging that we're doing. There's also no revision control yet.

We need a wiki and some other webspace to host such source+binaries.

I have some spaces that I could use, but they aren't exactly vintage-computer related domain name wise, so maybe I might be able to convince one of the folks here to do a little subdomain hosting for it. Anyone?

hargle
March 9th, 2009, 06:15 AM
I spent most of the weekend trying to locate my CF to IDE adapter. Couldn't locate it at all. I'll have to pop onto ebay or pick one up locally. User justjunk here has sent me a CF card for testing, so I have a couple of them that I can play with whenever I get an adapter.

I did get CD-ROM drives to ID during POST now. There's a ton of work to do there making a driver, but at least we can prove out that we can transfer a little bit of data off of ATAPI devices now too.

that's all from this corner of the world.

hargle
March 12th, 2009, 07:37 AM
something interesting to get a few PCBs made perhaps:

http://hackaday.com/2009/03/11/batchpcb-now-even-more-a-la-carte/

hargle
March 24th, 2009, 06:26 AM
even though I seem to be talking to myself here lately, here's the latest status on the project:

1) Andrew sent me a wire-wrapped prototype board, so now each of us have our own test platform to work with. It's a work of art. The wire wrap stuff is really fascinating to look at, but it's functional too!

2) I got the BIOS flash program working, so now we have a software means of updating the BIOS in case of bugs or new features. It's by no means finished, but it is functional.

3) I'd been developing all of my code on a 486 test platform, but last night I dropped the card with my latest BIOS into an actual XT, and the machine signed on and detected the drive exactly like you'd expect it should. It didn't boot, but that's because I haven't been hooking INT 19 (oopsie!) that would enable booting. That should be a pretty easy fix to make though, and then I can give a full status report about performance and interoperability.

All in all, we are making really good progress in getting this card up and running.

I think the next step would be to do a very small run of PCBs (5 or 10) and get some components soldered down. Those cards will then become the next debug platforms and we will distribute some cards to a few others who might be willing to help out in debugging and regression testing to get the BIOS in shape.

If we don't find any major respin issues on the PCB, then it'll be production time! I don't know the ETA of any of these things.

kb2syd
March 24th, 2009, 07:33 AM
I was getting worried ;-) 10 days and no updates!

Sounds great.
Kelly

NobodyIsHere
March 24th, 2009, 10:20 AM
even though I seem to be talking to myself here lately, here's the latest status on the project:

1) Andrew sent me a wire-wrapped prototype board, so now each of us have our own test platform to work with. It's a work of art. The wire wrap stuff is really fascinating to look at, but it's functional too!

2) I got the BIOS flash program working, so now we have a software means of updating the BIOS in case of bugs or new features. It's by no means finished, but it is functional.

3) I'd been developing all of my code on a 486 test platform, but last night I dropped the card with my latest BIOS into an actual XT, and the machine signed on and detected the drive exactly like you'd expect it should. It didn't boot, but that's because I haven't been hooking INT 19 (oopsie!) that would enable booting. That should be a pretty easy fix to make though, and then I can give a full status report about performance and interoperability.

All in all, we are making really good progress in getting this card up and running.

I think the next step would be to do a very small run of PCBs (5 or 10) and get some components soldered down. Those cards will then become the next debug platforms and we will distribute some cards to a few others who might be willing to help out in debugging and regression testing to get the BIOS in shape.

If we don't find any major respin issues on the PCB, then it'll be production time! I don't know the ETA of any of these things.

Hi! Thanks! Good to hear the prototype is working. When you are ready, please post the BIOS updating utility and I'll use it on my prototype so we can get more testing. I've been busy on the workbench with the N8VEM 6809 host processor but if there is something specific I can do to help with the testing please let me know.

Your work on the BIOS update utility is critical since it minimizes remove and replace cycles on the prototype. Even with a ZIF, they are rather delicate and I prefer to leave them alone as much as possible.

Your idea of making a small production run of prototype PCBs is very good. I'd be glad to help make a limited run of PCBs using the same method I use for N8VEM. Let me know what you'd like to do.

Before we do a small prototype PCB run we need to settle on if we want a PCB respin. I have about 4 small issues which could be fixed (presumably) in a respin but that'll add another 3 weeks at least. I recommend extremely thorough testing of the two prototypes and shaking down the requirements one more time to get in all the PCB changes. PCB respins are time consuming so we have to be very selective as to if they are needed. Right now, I think the value of a respin is highly questionable but more testing may turn up something critical.

One of my 4 respin items is adding a bracket. Have you decided on whether you want a bracket? If so, which one? The PCB needs mounting holes if there is going to be a bracket and that affects the PCB layout. Would you send me a sample or at least a supplier part number so I can investigate what it'd do to the PCB layout?

Thanks and have a nice day!

Andrew Lynch

hargle
March 24th, 2009, 01:32 PM
When you are ready, please post the BIOS updating utility and I'll use it on my prototype so we can get more testing.

Sent it to you in email last night.



Before we do a small prototype PCB run we need to settle on if we want a PCB respin. I have about 4 small issues which could be fixed (presumably) in a respin but that'll add another 3 weeks at least. I recommend extremely thorough testing of the two prototypes and shaking down the requirements one more time to get in all the PCB changes. PCB respins are time consuming so we have to be very selective as to if they are needed. Right now, I think the value of a respin is highly questionable but more testing may turn up something critical.


If one of the things we wanted to do was really simple, like say a header for an external LED, could that layout work be done by hand, considering 99% of the layout between parts would be the same? Just thinking of ways that we might be able to avoid a 3 week turnaround for something easy and essentially bulletproof.



One of my 4 respin items is adding a bracket. Have you decided on whether you want a bracket? If so, which one?

Yes, absolutely we want a bracket.

the ones that jameco sells:
hxxp://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=1582356&

are PCI only, and $1.99 each, or $1.92 in 100+ quantities, so scratch that.
I munged the link to avoid confusion. we don't want those.


The ones we need (the keystone 9202) is available here:

http://mouser.com/Search/ProductDetail.aspx?qs=g5fiFmky%2fl4bFM8ICVGfOQ%3d% 3d

and are $1.45 in 100+ quantities.

There is a data sheet available on either page that shows the exact dimensions of where the tabs+holes are. If you want me to order a couple anyway, I'd be happy to.


Overall, I think that we should debug/test various hard drives on the wire wrap boards for about 1 more week, then if nothing major comes up, we should kick out an order of 5-10 PCBs with the current design and continue testing.
If need be, I will gladly just drill 2 holes in each PCB for mounting for now.

Those PCB get sent off to friends of the project, who can then continue the testing work in parallel.

NobodyIsHere
March 24th, 2009, 02:56 PM
Hi Hargle! Yes, I think Keystone 9202 is the right part. I don't have a preference though. Whatever you'd like is OK with me. The important thing is the bracket I use to make the measurements has to be a real production representative part so I get the dimensions right or the PCB is going to be all screwed up.

http://www.jameco.com/Jameco/Products/ProdDS/1582356.pdf

Jameco or Mouser, I don't have a preference.

OK, it sounds like the bracket is a requirement. The developers are on their own but having regular people drilling PCBs to add their brackets is not a good idea, IMO. Almost certainly that'll lead to damaged PCBs and be a real PITA. Adding a bracket is alright, however, my real question is: "where do the bracket holes go on the PCB?" I need a sample bracket to make a mockup to determine the precise location of the holes.

As the way forward, I will make a cardboard mockup PCB and manually find where the holes should go. Adding the holes to the PCB layout once I know the location is not a problem other than I am 90% confident it'll force a PCB respin.

The timing for a PCB respin is about right though as my N8VEM Zilog Peripherals board is almost done in the trace router optimizer. Once it has finished I can run a job for the XT-IDE controller. That should happen in the next few days.

My list of PCB revisions is:

1. reverse P inputs on U6
2. bracket holes
3. IRQ option jumpers (which ones?)
4. CSEL GND/VCC jumper -- Does this even matter anymore? I forget.
5. LED jumper

Suggested way forward:

1. get a sample bracket. Either send me one or I'll order one along with my next Jameco order. I have no idea when that'll be.
2. I'll build a cardboard mockup to find bracket mounting holes.
3. shake out the rest of the PCB requirements.
4. redo the PCB layout and start the respin.

Thanks and have a nice day!

Andrew Lynch

hargle
March 24th, 2009, 04:18 PM
Jameco or Mouser, I don't have a preference.


I do!

Jameco doesn't sell the ISA version!! They only have the PCI 9203 in their catalog. We need the 9202.

Are the specifications with the measurements in that PDF file enough for you to go off of for the PCB mounting holes, or should I actually get one and ship it to you? I may also have one among my scrap pile that fits the measurements of the one in the PDF file. lemme look.
Lemme also investigate the IRQ requirements. Currently we're not even using interrupts, so this is rather moot!

And, here's a picture to brighten everyone's day:
http://www.waste.org/~winkles/xtboot!.jpg

yep, I BOOTED to that sucker.

NobodyIsHere
March 24th, 2009, 04:42 PM
I do!

Jameco doesn't sell the ISA version!! They only have the PCI 9203 in their catalog. We need the 9202.

Are the specifications with the measurements in that PDF file enough for you to go off of for the PCB mounting holes, or should I actually get one and ship it to you? I may also have one among my scrap pile that fits the measurements of the one in the PDF file. lemme look.
Lemme also investigate the IRQ requirements. Currently we're not even using interrupts, so this is rather moot!



Hi Hargle! Yes, I need the actual bracket part to make the dimensions on the PCB. I don't know where the holes are supposed to be on the PCB. All the data sheet tells me is where the mounting holes are on the bracket relative to itself.

This is almost a chicken and egg kind of problem which is why I am proposing to make the cardboard mockup. I'll install the bracket in the test station and the cardboard mockup in an ISA slot. Then mark on the mockup where the holes are supposed to be on the PCB. I'll make the diameter of the holes large enough for a little wiggle room but still a snug fit. Hopefully that'll be close enough.

Maybe someone has a better idea?

As for the IRQs... I don't need them either but somebody was saying something about the Tandy needing special IRQ support. As long as they are present on the 8 bit ISA slot its doable. I'll just put on some jumpers for the usual suspects... 2, 3, 4, 5, & 7. If we are doing a PCB respin this shouldn't be a problem to add.






And, here's a picture to brighten everyone's day:
http://www.waste.org/~winkles/xtboot!.jpg

yep, I BOOTED to that sucker.


Nice! Excellent work!

Thanks and have a nice day!

Andrew Lynch

Trixter
March 24th, 2009, 06:30 PM
And, here's a picture to brighten everyone's day:

yep, I BOOTED to that sucker.

My god, that's beautiful.

Unknown_K
March 24th, 2009, 09:00 PM
How does this design deal with drives that are very fast (8 bit ISA bus cannot move much data), any issues with this?

kb2syd
March 25th, 2009, 05:10 AM
And, here's a picture to brighten everyone's day:

yep, I BOOTED to that sucker.

This is a beautiful sight. It brings tears to my eyes. Hats off to Hargle and Andrew. As for IRQs, 2, 5 and 7 would be a dream, but I'm not above cutting in a "field patch" if I need to.

Druid6900
March 25th, 2009, 06:15 AM
This is a beautiful sight. It brings tears to my eyes. Hats off to Hargle and Andrew. As for IRQs, 2, 5 and 7 would be a dream, but I'm not above cutting in a "field patch" if I need to.

Yes, WELL DONE, gentlemen.

My compliments to the "chefs".

I have to agree with Andrew. Positioning of the bracket is critical. If it's out a little too much, the card may not sit in the slot right, may be tilted to one side or the top of the bracket may not come down enough to sit on the backplane well enough to screw it down without bending it.

hargle
March 25th, 2009, 07:26 AM
How does this design deal with drives that are very fast (8 bit ISA bus cannot move much data), any issues with this?

I've not seen any issues, but then again, I *just* moved the card over from my 486 development station to the XT last night, so timing stuff might creep in now. There were no issues that I saw on my 486, and I was playing around with everything from 600MB drives up to 250G drives.
There may be some tricks I can do to the drive as well, like forcing the drive into PIO 0 mode (the slowest) by using a set features command at startup. We'll just have to see how things go during this phase of the debugging.

---------

Looks like andrew has the IRQ request jumper block in the works already, so that shouldn't be a problem. As I've said, right now, the card isn't using *any* IRQs, which does impact performance, but should make the device work on any platform. I will have IRQ and non IRQ versions of the BIOS available.

---------
I'll order a few brackets.
First I need to get ahold of my IC vendor to see if he can put together a complete list of components for the card, and if not, I'll add whatever he's missing in my shopping cart. I should be able to get an order in by the weekend I'd think.

frozenfire75i
March 25th, 2009, 08:16 AM
I did some looking on Google and it looks like the 8 bit bus has a bandwidth of 7.9Mb/s, Now I don't know if that's true with the 5150.

The Hard drive I plan to use in my final setup is a quantum pro drive 271MB. With two 10MB's under dos 2.1

Info about the drive here:

http://stason.org/TULARC/pc/hard-drives-hdd/quantum/PRODRIVE-LPS-270-AT-271MB-3-5-SL-ATA2-FAST.html

Under the "Data Transfer Rates" near the bottom of the page it says "Data is transferred from the disk to the read buffer at a rate up to 5.8 MB/s in burst. Data is transferred from the read buffer to the AT
bus at a rate up to 4.0 MB/s, using programmed I/O without IORDY, up to 11 MB/s using programmed I/O with IORDY, or at a rate of up to 13.0 MB/sec using multi-word DMA."

Not sure what all the means but it sounds like if you use it without IORDY then it's well under the 8 bit bus bandwidth. I think if a person use's a 1gb and under HDD, I don't think there will be any problems with speed on the 8bit bus...

But I know nothing really, just rambling!

Great Hierophant
March 25th, 2009, 01:13 PM
I did some looking on Google and it looks like the 8 bit bus has a bandwidth of 7.9Mb/s, Now I don't know if that's true with the 5150.!

I do not think it is. That 7.9MB figure assumes a bus speed of 8.3MHz. The 5150 runs its bus at 4.77MHz because it is really just an extension of the 8088 data bus. Therefore, the bandwith cannot be greater than 4.77MB/sec. However, on the plus side, there are few wait states to worry about here.

Those numbers refer to the drive being run on a more modern IDE controller and through a faster bus. Fast ATA is almost always implemented on faster buses, VLB and PCI. Programmed I/O is something that was introduced when 286 processors were recognized as efficient enough to support that method of transfer. 8088 processors must rely on 8-bit DMA transfers, which are no speed demons.

I don't claim to know much either ;)

per
March 25th, 2009, 01:38 PM
And, here's a picture to brighten everyone's day:

yep, I BOOTED to that sucker.

That's just awesome. I now really REALLY start to like this project.

bobwatts
March 25th, 2009, 02:14 PM
Nice work gentlemen, truly impressive.

Now that it appears that you have everything in order, do you have any idea when my Acculogic sIDE card will be returned to me?

Thank you.

bobwatts
EartH

NobodyIsHere
March 25th, 2009, 03:08 PM
Hi! I updated the schematic and PCB layout with the changes as far as I can go without the bracket. Attached is a notional PCB layout.

The design with probably it will be something close to this with the bracket holes repositioned and with traces routed. This should give you a good idea of the PCB layout. The PCB layout favors trace routing and will include a silkscreen layer with some descriptive labels etc.

Please post your comments, questions, suggestions, etc.

Thanks and have a nice day!

Andrew Lynch

tezza
March 25th, 2009, 05:22 PM
I haven't been following this thread as I'm not looking at modding any of my vintage stuff (yet) but I've just read over what you've done and I have to say "WELL DONE GUYS!"

Tez

MikeS
March 25th, 2009, 05:51 PM
Same here! I've still got enough MFM drives & HDCs to keep my few XTs & clones going for a while so I don't need one, but I can still appreciate this terrific cooperative effort!

Fascinating reading, watching something like this (and Andrew's N8VEM project) come to life and grow; one of the things that really makes this hobby special.

Great stuff!

gerrydoire
March 25th, 2009, 05:57 PM
Nice work gentlemen, truly impressive.

Now that it appears that you have everything in order, do you have any idea when my Acculogic sIDE card will be returned to me?

Thank you.

bobwatts
EartH

I'm still testing everything IDE with my Acculogic.

So far the only CF card that will work with it is a 128meg.

256 CF didn't work, a 2 gig CF didn't work, waiting for a 512meg one to come in, probably won't work, but never know till you try.

:>

frozenfire75i
March 25th, 2009, 06:22 PM
I am not in to modding my vintage stuff yet either, however until someone finds a way to repair old dead MFM drives such as the ST-412, I am going to make that choice to retire my working drives so 5 or 10 years from now it will still be working. and someone like your self mike that makes the choice to keep useing the MFM drives will eaither have to use the IDE card or not have any MFM drives left, they are all running on borrowed time!


I haven't been following this thread as I'm not looking at modding any of my vintage stuff (yet) but I've just read over what you've done and I have to say "WELL DONE GUYS!"

Tez


Same here! I've still got enough MFM drives & HDCs to keep my few XTs & clones going for a while so I don't need one, but I can still appreciate this terrific cooperative effort!

Great stuff!

Druid6900
March 25th, 2009, 06:57 PM
Nice work gentlemen, truly impressive.

Now that it appears that you have everything in order, do you have any idea when my Acculogic sIDE card will be returned to me?

Thank you.

bobwatts
EartH

Well, Bob, due to circumstances, I'm actually just going to be shipping the card to Hargle tomorrow, so, when he's done, it'll be returned safe and sound.

MikeS
March 25th, 2009, 09:03 PM
<snip>...someone like your self mike that makes the choice to keep useing the MFM drives will eaither have to use the IDE card or not have any MFM drives left, they are all running on borrowed time!
So am I ;-) It's just a tossup who/what goes first, but if I outlast the last MFM drive I'll be happy. On the other hand I hope that by that time I'll have managed to get rid of all this junk, and I've also made a solemn vow to not spend another cent on more "stuph."

Terry Yager
March 25th, 2009, 09:29 PM
I am not in to modding my vintage stuff yet either, however until someone finds a way to repair old dead MFM drives such as the ST-412, I am going to make that choice to retire my working drives so 5 or 10 years from now it will still be working. and someone like your self mike that makes the choice to keep useing the MFM drives will eaither have to use the IDE card or not have any MFM drives left, they are all running on borrowed time!

You're obviously overlooking that many of them go tits-up from sitting around unused. If ya keep 'em running there's less chance of stiction gluing the heads to the platters.

--T

MikeS
March 25th, 2009, 09:41 PM
You're obviously overlooking that many of them go tits-up from sitting around unused. If ya keep 'em running there's less chance of stiction gluing the heads to the platters.

--T
You're preaching to the choir; FF was making that very point, while I'm the fool putting my faith in Miniscribe (RIP). Actually, the only drives I've had stiction issues with have been certain Seagates; the small Miniscribes and Micropolis drives seem to be just crude enough to last a long time. Even one of the infamous Kaloks still worked last time I tried it (and you knew it - one of the loudest drives ever).

But see above; like the buddy that you only need to stay one step ahead of when you're both being chased by a bear, just a few of the drives need to outlast me (or just stay running until I flog 'em).

frozenfire75i
March 26th, 2009, 06:43 AM
No I am not overlookin' it, that why I will fire up a few times a year to keep that from happening!


You're obviously overlooking that many of them go tits-up from sitting around unused. If ya keep 'em running there's less chance of stiction gluing the heads to the platters.

--T

gerrydoire
March 26th, 2009, 08:27 AM
No I am not overlookin' it, that why I will fire up a few times a year to keep that from happening!

I have several MFM hard drives fail on me over the last while, one was brand new, died 3 months of use.

I gave up buying MFM HDS and use IDE to CF now.

MikeS
March 26th, 2009, 08:37 AM
I have several MFM hard drives fail on me over the last while, one was brand new, died 3 months of use.

I gave up buying MFM HDS and use IDE to CF now.
HERESY! *Real* men scoff at IDE and CF! In my day we made new disk platters out of old hubcaps and stole heads and motors out of cassette players...

hargle
March 26th, 2009, 09:11 AM
I'm still testing everything IDE with my Acculogic.

So far the only CF card that will work with it is a 128meg.

256 CF didn't work, a 2 gig CF didn't work, waiting for a 512meg one to come in, probably won't work, but never know till you try.

:>

I know why! (preliminary results anyway)
I found my IDE-CF adapter last night and gave it a whirl on our card. It worked, sorta. The 1G card I had worked with some minor timing issues that I need to try and address. The 128MB card that I received from justJunk to help with this project didn't work. I could ID the device, but it reports zero user addressable sectors.

Here's why:
It looks to me like cards below a certain size will report back to the IDE adapter as requiring CHS addressing mechanisms only. Our controller doesn't support CHS, so it failed on the 128MB card.

My 1G card would report as being LBA addressable, so the the card worked.

The acculogic card has the exact opposite problem. It only can address cards up to 528MB, and only in CHS mode. If the CF device doesn't respond to CHS addressing because it uses LBA, then it'll fail on that card.

The 512MB card you're about to receive could be anyone's guess as to how it'll work. It may even vary from vendor to vendor. Both cards I had were from sandisk.

That kinda seals the deal for me that I need to add CHS addressing in my BIOS though, which makes me sad, but does mean that it'll be that more robust in the end, so that's a good thing.

gerrydoire
March 26th, 2009, 02:29 PM
I know why! (preliminary results anyway)
I found my IDE-CF adapter last night and gave it a whirl on our card. It worked, sorta. The 1G card I had worked with some minor timing issues that I need to try and address. The 128MB card that I received from justJunk to help with this project didn't work. I could ID the device, but it reports zero user addressable sectors.

Here's why:
It looks to me like cards below a certain size will report back to the IDE adapter as requiring CHS addressing mechanisms only. Our controller doesn't support CHS, so it failed on the 128MB card.

My 1G card would report as being LBA addressable, so the the card worked.

The acculogic card has the exact opposite problem. It only can address cards up to 528MB, and only in CHS mode. If the CF device doesn't respond to CHS addressing because it uses LBA, then it'll fail on that card.

The 512MB card you're about to receive could be anyone's guess as to how it'll work. It may even vary from vendor to vendor. Both cards I had were from sandisk.

That kinda seals the deal for me that I need to add CHS addressing in my BIOS though, which makes me sad, but does mean that it'll be that more robust in the end, so that's a good thing.

Well for the hell of it, I tried the 256 meg card again, this time as a slave, drive D:, guess what, it worked, formatted as 256 megs etc, as a primary boot drive the computer just sits there and hangs.

I haven't filled the 256 meg card with much data, to see if there was any other quirks, but as it stands, the card seems to work fine as a slave.

With this in mind, I figured I'd try my 2gig card as slave, it worked also as a slave and it formatted to the dos limit of 500megs.

So if you have an Acculogic, put a 128 meg on it as a boot hd C:,
us the second connector as a d: drive and it will more than likely accept any CF card and format it to the dos limit.

The 2Gig card is modern, Lexar Platinum II 80x, reduced to dos level 1/2 gig on a computer made in the dark ages :mrgreen:

BG101
March 26th, 2009, 03:28 PM
Have you tried creating extra partitions on the 2GB card?



BG

gerrydoire
March 26th, 2009, 04:15 PM
Have you tried creating extra partitions on the 2GB card?



BG


I'm using PC Dos 2000, and it only sees up to 512 megs or so.

hargle
March 27th, 2009, 07:22 AM
I'm using PC Dos 2000, and it only sees up to 512 megs or so.
That's all you're going to get on the acculogic. It has the 528MB barrier in full force in its BIOS. When I'm finished with our card, I am still planning on updating that acculogic BIOS with barrier breaking enhancements, so just hang in there and we'll get that card seeing even bigger drives.

that is really interesting that it works as a slave and not as a master.
I have a *lot* of playing around to do on our card to make sure all of this stuff works as expected. This is putting of my writing of a CD-ROM driver, but I think its work that should be done first.

gerrydoire
March 27th, 2009, 10:10 AM
That's all you're going to get on the acculogic. It has the 528MB barrier in full force in its BIOS. When I'm finished with our card, I am still planning on updating that acculogic BIOS with barrier breaking enhancements, so just hang in there and we'll get that card seeing even bigger drives.

that is really interesting that it works as a slave and not as a master.
I have a *lot* of playing around to do on our card to make sure all of this stuff works as expected. This is putting of my writing of a CD-ROM driver, but I think its work that should be done first.


I figured if the CF card didnt work as a master, why would I try it as a slave, but there you go...

When you going to enhance my Acculogic bios, I'm dying out here :rolleyes:

hargle
March 27th, 2009, 12:03 PM
I figured if the CF card didnt work as a master, why would I try it as a slave, but there you go...

When you going to enhance my Acculogic bios, I'm dying out here :rolleyes:

or just buy one of our cards and sell your acculogic on ebay. you'll get 5x the amount you paid for our card, so you'll come out ahead and end up with a better piece of hardware!

seriously though, our card gets top priority, so it won't be until after our card is shipping til I could possibly do any work on the acculogic. a few months minimum.

gerrydoire
March 27th, 2009, 02:02 PM
or just buy one of our cards and sell your acculogic on ebay. you'll get 5x the amount you paid for our card, so you'll come out ahead and end up with a better piece of hardware!

seriously though, our card gets top priority, so it won't be until after our card is shipping til I could possibly do any work on the acculogic. a few months minimum.

How about we start our own company,
you can be woz and you can call me mr. jobs, i bet we could make millions on your inventions :D :D :D
ok ok that idea was taken already...

It will be interesting to see how many 8-bit PC enthusiasts are out there when the card is ready..

Terry Yager
March 27th, 2009, 10:40 PM
It will be interesting to see how many 8-bit PC enthusiasts are out there when the card is ready..

A whole lot more than we're expecting. I predict that the first run (50-100) will fly off the shelves in a few days to a couple weeks (especially if the price can be kept in around the $50.00 range).

--T

lutiana
March 31st, 2009, 04:46 PM
What kind of web hosting do you need? I may be able to help there, just let me know.

This is an awesome project, and I am pleased with the results, and if the final card is $50 I'd buy it, in fact I'd even buy it at $100.

gerrydoire
March 31st, 2009, 05:14 PM
A whole lot more than we're expecting. I predict that the first run (50-100) will fly off the shelves in a few days to a couple weeks (especially if the price can be kept in around the $50.00 range).

--T

I will be picking up 2 myself.

84TAVeRT
March 31st, 2009, 05:44 PM
i still think this is awesome...

too bad it doesn't include a floppy controller with 1.2/1.44 support as well...

but i guess you can get those for about $30 bucks anyway...

keep up the good work... and keep us updated with progress...

when does the beta program start :)

i got 2 XT machines itching for ide :) and a couple of 4gb microdrives ready to rock...

later,
Chris

hargle
April 2nd, 2009, 09:10 AM
Latest status:

PCB: we're likely to send off to have a small run (5 or 10) boards built sometime this month. Those will be distributed to other testers to try and break the design/code.

Hardware: Minor hardware tweak to get some slightly faster buffering in place. This fixed all the various timing issues I had during ID through POST. Hardware seems to be very stable. Works both in an XT and in my 486 test platform, so there are no CPU specific speed issues.

Software: EEPROM Flash program written and functional. Slight tweaks required, but it is working to do software BIOS updates.

BIOS is working well. Basic INT 13 and Enhanced INT13 is working fine. All drive manufacturers that I've tested (conner, seagate, WD and maxtor) all work to read/write sectors. Fdisk, Formatted and booted to my 1G compact flash card last night. The 128MB card does not support LBA access, so that doesn't work.

Todo: CHS support, boot menu/options, optimizations, IRQ support, CD-ROM driver.

Needs testing: cable select, 2 drives, drive w/CD-ROM, failing hard drive error reporting, multiple controllers.

Known issue: Old HDD benchmark called coretest doesn't work. It's doing something outside of INT13 that I don't understand yet, as it ends up issuing read commands to device 80h, which is normal, and then to device 41h, which should (and does) fail. Same test on a normal controller never accesses device 41h. All INT13 responses appear the same.

Overall, we're on target for a release this summer.

Trixter
April 2nd, 2009, 09:23 AM
I can't tell you how much I'm looking forward to these.

I should "warn" you, though, that I plan to use mine almost exclusively with CF cards + CF->IDE adapters. Shouldn't be a problem, right?

hargle
April 2nd, 2009, 11:33 AM
I should "warn" you, though, that I plan to use mine almost exclusively with CF cards + CF->IDE adapters. Shouldn't be a problem, right?
That should be fine, probably the larger/newer CF the better, especially since i'm going to be lazy about adding CHS support for awhile. My sample size of 2 CF cards may not be very indicative of how CF support is working overall though. Anyone want to send me additional cards to test with?

My generic CF->IDE adapter and a Sandisk Extreme III 1Gig card seems to work beautifully.

http://www.amazon.com/SanDisk-SDCFX3-1024-901-Extreme-CompactFlash-Package/dp/B0007876PC
(that seems really expensive though)

I suspect that there's no need to be "extreme" at 4.77MHz. ;)

kb2syd
April 2nd, 2009, 11:38 AM
At what size did IDE move away from CHS and over to the newer (LBA?) system? I have drives at home (45+) ranging in size from 170 meg up to 10 gig. I'd like to be able to use some of the 1 or 2 gig drives (of whic I have the most).

Any easy way to tell what system is used by a particular drive?

84TAVeRT
April 2nd, 2009, 12:15 PM
528MB - The maximun drive capacity that is supported by 1024 cylinders, 16 heads and 63 sectors (1024x16x63x512). This is the limit for CHS addressing in the original IBM PC/XT and IBM PC/AT INT 13H BIOS.

Raven
April 2nd, 2009, 05:09 PM
I'd love to have one of these. I'd buy a whole range of 8-bit IDE cards, but an all-in-one would be nice (floppy/IDE/MFM/sound/ram expansion/ethernet) or some combo of the aforementioned, since many machines (like my Sr. Partner) have only one or two ISA slots. Can't wait though, as even just IDE capability for my Sr. Partner would open up an essentially infinite storage possiblity - Zip drives, CD/DVD, HDD, tape, and more...

gerrydoire
April 3rd, 2009, 06:14 AM
I can't tell you how much I'm looking forward to these.

I should "warn" you, though, that I plan to use mine almost exclusively with CF cards + CF->IDE adapters. Shouldn't be a problem, right?

IDE to CF is the only realistic way to go on a vintage computer, CF cards have nothing but benefits.

Low power consumption, small space, light, shock proof, low heat, more than enough capacity and speed than any vintage computer will ever need.

My acculogic "as is" from the manufacturer, will only boot from a 128 meg CF Card, won't boot any higher capacity cards, but will format and use up to 512megs on a CF card connected as a slave drive (No major tests done here), it will fdisk and format to that capacity so I'm assuming I will be able to actually use the space, never filled a card yet to be absolutely sure.

This is what I use for my drive D: as a slave:

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


THE BENEFITS ARE OBVIOUS!

hargle
April 3rd, 2009, 06:15 AM
huh. I never thought about zip drives or tape drives.

I'm not sure how zip drives talk to the IDE controller. If it's just like a normal hard drive that uses INT13, then that should work just fine, but I suspect there are drivers required. Tape drives certainly don't use standard interfacing methods, so that's right out.

Since this controller is not a typical IDE controller, using industry standard IDE I/O ports, every IDE device that needs direct access to the hardware would require a custom driver to be written, and that includes CD/DVDs unfortunately.

I do plan on supporting DVD/CD drives eventually. I need to write an entire CD-ROM driver that MSCDEX would then talk to, and the driver development documentation I've read says that it will take roughly 4-6 weeks of full time work to develop such a thing. That likely equates to 20-40 weeks of part time work, especially if I get frustrated and abandon it. ;)

----------
Depending on how these cards go, and depending on how tortured and gray haired from stress andrew wants to end up being, I'd be totally on board for future geek projects, such as floppy controllers and USB devices and anything else anyone wants. I think I've found that BIOS and low level DOS work is certainly my calling in life.

gerrydoire
April 3rd, 2009, 06:24 AM
huh. I never thought about zip drives or tape drives.

I'm not sure how zip drives talk to the IDE controller. If it's just like a normal hard drive that uses INT13, then that should work just fine, but I suspect there are drivers required. Tape drives certainly don't use standard interfacing methods, so that's right out.

Since this controller is not a typical IDE controller, using industry standard IDE I/O ports, every IDE device that needs direct access to the hardware would require a custom driver to be written, and that includes CD/DVDs unfortunately.

I do plan on supporting DVD/CD drives eventually. I need to write an entire CD-ROM driver that MSCDEX would then talk to, and the driver development documentation I've read says that it will take roughly 4-6 weeks of full time work to develop such a thing. That likely equates to 20-40 weeks of part time work, especially if I get frustrated and abandon it. ;)

----------
Depending on how these cards go, and depending on how tortured and gray haired from stress andrew wants to end up being, I'd be totally on board for future geek projects, such as floppy controllers and USB devices and anything else anyone wants. I think I've found that BIOS and low level DOS work is certainly my calling in life.


I connected a zip 250meg ide drive to my Acculogic, it gave no response whatsoever.

Deader than S%iT

84TAVeRT
April 3rd, 2009, 06:32 AM
There are at least four different kinds of IDE Zip drives - the original ATA version, the ATAPI version which replaced it, an ATAPI2 version which seems to have replaced the original ATAPI Zip, and an ATAPI3 version which will probably replace the ATAPI2 .

source: http://home.netcom.com/~deepone/zipjaz/atapi.html

84TAVeRT
April 3rd, 2009, 06:36 AM
i have an ATA and an ATAPI zip100

gerrydoire
April 3rd, 2009, 08:00 AM
i have an ATA and an ATAPI zip100


I bought two 250meg zip drives for $1.00 each :>

I figured for that price, why not, put one of them in my spare multi purpose computer.

The reads are reasonable, the writes: totally gag the system.

Chuck(G)
April 3rd, 2009, 08:02 AM
IDE to CF is the only realistic way to go on a vintage computer, CF cards have nothing but benefits.

THE BENEFITS ARE OBVIOUS!

Limited number of write cycles, slower speed... :confused:

gerrydoire
April 3rd, 2009, 08:07 AM
Limited number of write cycles, slower speed... :confused:

Do you really think on a 8bit PC computer you would notice?

Chuck(G)
April 3rd, 2009, 08:31 AM
Do you really think on a 8bit PC computer you would notice?

Depends on what you're doing with it. If I'm using one 24/7 for data logging, that write-cycle limitation can be hit in just a few months.

If I'm used to a high-performance ISA bus-mastering hard disk controller with a big cache, I think I'd notice the speed difference, particularly where there are lots of little files.

On the other hand, if you just turn the box on every now and then to look at the quaint pictures and sniff the musty smell, you probably won't care.

gerrydoire
April 3rd, 2009, 09:12 AM
Depends on what you're doing with it. If I'm using one 24/7 for data logging, that write-cycle limitation can be hit in just a few months.

If I'm used to a high-performance ISA bus-mastering hard disk controller with a big cache, I think I'd notice the speed difference, particularly where there are lots of little files.

On the other hand, if you just turn the box on every now and then to look at the quaint pictures and sniff the musty smell, you probably won't care.

I just have my 8bit computer loaded with programs made during that era, when someone wants to see how it works, I turn it on, the programs are all there, and viola, other than that I have 0 use for it.

More like a workable antique for the curious.

I could restore IT to ITS original condition, mfm hd and all that nice stuff, but after having many of them fail, I figure an IDE<>CF was less of a hassle.

No more taking the computer apart when hd's fail, not to mention the shipping costs to buy these old bricks.

I had a brand new MFM and two used ones die on my after medicore use,
that was enough for me.

:cool:

hargle
April 3rd, 2009, 09:32 AM
There are at least four different kinds of IDE Zip drives - the original ATA version, the ATAPI version which replaced it, an ATAPI2 version which seems to have replaced the original ATAPI Zip, and an ATAPI3 version which will probably replace the ATAPI2 .

source: http://home.netcom.com/~deepone/zipjaz/atapi.html

Interesting. I don't suspect you'll have any luck with zip drives though.
There's currently no support for ATAPI anything, and only basic ATA support through INT13 is available, so it would probably require a reverse engineering job on that guest.exe program to figure out how it's talking to the hardware to do anything. Not enough time or energy to take that one on. Since there's CF support though, and CF has all the advantages and more over zip, I think there's really no reason to pursue zips.

---------
Gerry,
you should try and market your CF-IDE->bracket device. Maybe we could sell them together as a deluxe kit with our card?

While I think adding a CD rom to my XT would be cool, having an IDE drive and CF support externally could be equally cool.

I wish we had 3 connectors on an IDE cable! I suppose I could always use 2 IDE cards...

Chuck(G)
April 3rd, 2009, 10:59 AM
Why not develop an ATASPI driver for the thing? It might let you use ASPI drivers to handle the more unusual ATAPI devices (e.g. Zip drives).

It shouldn't be that complicated, as ATAPI is basically a lookalike of SCSI, just done over the ATA bus.

Hargle, that's weird about your experience with MFM hard drives. The Quantum 30MB drive that I have in my XT clone is the original--and I use the thing quite frequently. I've got other 5.25" hard disks that are still working just fine--but they're all FH--and none is a Seagate.

gerrydoire
April 3rd, 2009, 01:32 PM
you should try and market your CF-IDE->bracket device. Maybe we could sell them together as a deluxe kit with our card?

While I think adding a CD rom to my XT would be cool, having an IDE drive and CF support externally could be equally cool.

I wish we had 3 connectors on an IDE cable! I suppose I could always use 2 IDE cards...


I wish I had knowledge of electronics and programming, I would help out, unfortunetly, that stuff is beyond me.

I'm a photoshop and illustrator only guy!

JT64
April 6th, 2009, 03:21 PM
Limited number of write cycles, slower speed... :confused:

Well how fast was an old 20, 30 MB drive ide and rfl. The Sandisk Ultra writes and read with minimum of 9 MB per second. I do not think a 20 MB drive can write 500 KB per second i would guess they did write and read at 100-200 KB per second.

I have no idea what the adapter and the old IDE do to the CF though but i can not see how an old HD could be faster than a CF.

JT

hargle
April 6th, 2009, 05:26 PM
here's some interesting news:

I received Bob Watts' Acculogic card in the mail the other day, and tonight I took the ROM off and put our EEPROM on it, and well, it just worked!
All I had to do was change the base address of where our BIOS is looking for the code. (it will auto-detect eventually)

So, that means, that for all of you acculogic users out there, you will soon have a new BIOS image that should let you break that 528MB barrier.

What didn't work is the flash update program. Not sure what the reason is, but the eeprom when installed in the acculogic, is write protected. Any idea what that might be andrew? (I haven't looked at the datasheet yet)

Pretty cool! we have cloned the acculogic card. Now I really feel sorry for all those chumps who buy $200 cards off ebay.

JT64
April 6th, 2009, 06:00 PM
here's some interesting news:

I received Bob Watts' Acculogic card in the mail the other day, and tonight I took the ROM off and put our EEPROM on it, and well, it just worked!
All I had to do was change the base address of where our BIOS is looking for the code. (it will auto-detect eventually)

So, that means, that for all of you acculogic users out there, you will soon have a new BIOS image that should let you break that 528MB barrier.

What didn't work is the flash update program. Not sure what the reason is, but the eeprom when installed in the acculogic, is write protected. Any idea what that might be andrew? (I haven't looked at the datasheet yet)

Pretty cool! we have cloned the acculogic card. Now I really feel sorry for all those chumps who buy $200 cards off ebay.

Any chance make a ROM for the ADP50L?

JT

hargle
April 6th, 2009, 07:48 PM
Any chance make a ROM for the ADP50L?
JT
I did start working on the disassembly of it. There's a thread here somewhere about it.

It's way, way different (memory mapped IO) compared to our card, so it's going to be a completely different ROM altogether, which will require extensive BIOS updates and I will probably need someone to send me a card for testing.

Gotta get this one done first though. Maybe toward the end of the summer I can tackle that one.

gerrydoire
April 6th, 2009, 07:57 PM
here's some interesting news:
Pretty cool! we have cloned the acculogic card. Now I really feel sorry for all those chumps who buy $200 cards off ebay.

I paid $100 for mine :rolleyes:

JohnElliott
April 7th, 2009, 12:20 AM
What didn't work is the flash update program. Not sure what the reason is, but the eeprom when installed in the acculogic, is write protected. Any idea what that might be andrew? (I haven't looked at the datasheet yet)

It's a pretty obvious suggestion, but: if the card was designed for a ROM or EPROM, they probably wouldn't have bothered connecting up what, on an EEPROM, would be the 'write' pin.

NobodyIsHere
April 7th, 2009, 03:08 AM
here's some interesting news:

I received Bob Watts' Acculogic card in the mail the other day, and tonight I took the ROM off and put our EEPROM on it, and well, it just worked!
All I had to do was change the base address of where our BIOS is looking for the code. (it will auto-detect eventually)



Hi Hargle! Great! Interesting to see more people maybe helped by the project.

However, this seems rather suspicious to me. I can see the IDE control port working fine but the 16 bit data port is split between a HIGH and LOW port. Are you sure you are seeing all the data going to/from the drive and not losing the upper or lower byte along the way? If not then the Acculogic board is using a similar port configuration as the XT-IDE board and that is good news.



So, that means, that for all of you acculogic users out there, you will soon have a new BIOS image that should let you break that 528MB barrier.

What didn't work is the flash update program. Not sure what the reason is, but the eeprom when installed in the acculogic, is write protected. Any idea what that might be andrew? (I haven't looked at the datasheet yet)



I don't know for sure since I haven't seen the schematic but my first suspicion is that the Acculogic board probably does not include a *MEMW line to signal the EEPROM to do a memory write. If the board is designed to use a ROM then there would be no need for it. Check if pin 27 is connected to anything on the Acculogic ROM socket. Preferably its connected to pin 11 of the ISA bus.




Pretty cool! we have cloned the acculogic card. Now I really feel sorry for all those chumps who buy $200 cards off ebay.

Ouch! I'd hold off on the victory lap until some further testing though. IDE is a strange beast and will gladly seem to work but not really be entirely there for you.

Good idea to test though. Please let me know how it works out.

Thanks and have a nice day!

Andrew Lynch

PS, does the Acculogic board allow the use of DMA modes?

hargle
April 7th, 2009, 05:59 AM
However, this seems rather suspicious to me. I can see the IDE control port working fine but the 16 bit data port is split between a HIGH and LOW port. Are you sure you are seeing all the data going to/from the drive and not losing the upper or lower byte along the way? If not then the Acculogic board is using a similar port configuration as the XT-IDE board and that is good news.

Yep, all 16bits of data is there. They are using the same latch mechanism as we are, even putting the 2nd data port at IOBASE+8. It all just worked.
The only other thing they do, is they have a 2nd copy of the command/status register mapped to IOBASE+E. I suspect it's acting as the alternate status register, which is where resets are sent to, and you can read it without triggering an IRQ ACK. I haven't found that we need such a thing yet, but then I haven't implemented IRQs yet either.

The other thing that is interesting is that they hard code their IO base address to 360-368, plus a single IO port at 36E. On my XT, without the card in, I had something responding to all those IO ports already. My port list says that 360-367 are for a "PC network (XT only)" but I don't have anything in my XT other than my CGA card and floppy controller.



I don't know for sure since I haven't seen the schematic but my first suspicion is that the Acculogic board probably does not include a *MEMW line to signal the EEPROM to do a memory write. If the board is designed to use a ROM then there would be no need for it. Check if pin 27 is connected to anything on the Acculogic ROM socket. Preferably its connected to pin 11 of the ISA bus.

Yep, that makes sense. thanks to both you and john elliot for pointing that out. I'll scope out that line and see if it's a NC on the card. Probably is.
So what that means is that anyone with an acculogic card who would want to have flash upgrade ability would just need to add a single wire from ISA pin 11 to pin 27 on the ROM. easy enough. Otherwise, the andrew lynch ROM burning service might be of use. :)




PS, does the Acculogic board allow the use of DMA modes?

Nope. I saw nothing in the BIOS disassembly to do DMA transfers. To be honest, I didn't even see anything in their BIOS to handle IRQs either! You can jumper select the IRQ line, but I didn't notice any ISRs in place.

per
April 12th, 2009, 11:06 AM
What didn't work is the flash update program. Not sure what the reason is, but the eeprom when installed in the acculogic, is write protected. Any idea what that might be andrew? (I haven't looked at the datasheet yet)

My guess is that the Acculogic is designed for EPROMs, not EEPROMs. Maybe the /WE signal might be permanently held high by the Acculogic card.

hargle
April 17th, 2009, 11:08 AM
So what that means is that anyone with an acculogic card who would want to have flash upgrade ability would just need to add a single wire from ISA pin 11 to pin 27 on the ROM. easy enough. Otherwise, the andrew lynch ROM burning service might be of use. :)


just had a chance to check this out. I assume we're talking B11 on the ISA bus, (System Memory Write) and alas, there isn't even a tooth there to connect to the ISA bus. So, acculogic users will not be able to flash upgrade their cards. I will enclose the latest working BIOS in bob watts' card when I ship it, but it'll be up to you to upgrade it in the future, should there ever be any changes required. (there certainly will be)

channelmaniac
April 17th, 2009, 08:12 PM
Jeff,

You have 2 emails from me tonight about parts. One is my cell # in case you wished to call me about them.

Raymond

Mike Chambers
April 18th, 2009, 12:29 AM
i'm just so glad this is actually getting done. how soon do you guys estimate these should be ready for purchase? i'm getting at least one for SURE! so cool that we'll be able to use 16-bit AT style drives without shelling out hundreds for the increasingly rare acculogic or similar cards. 8-bit drives are only going to get more scarce anyway. soon enough, none will be left working at all.

can i be a tester? muahahaha.

hargle
April 18th, 2009, 12:02 PM
At the moment, both PCBs (first prototype run of 10) and some parts are racing their way toward me via UPS. I suspect I'll have everything by the end of next week. I'm then going to pack everything up and ship at least 1 set of everything to andrew for first assembly, and we'll see where that takes us.

With luck, we will having working PCBs and a combination of ICs that work solid and are readily available. Then I'll build up some more boards and those get distributed to testers.* Once it's been through the wringer a few times, we will then push the big button and get 100 cards made up and the madness begins! No ETA on the big order because we have no idea what sort of things will creep up in the beta phase.

stay tuned...


* Not sure how the testers scene is going to be handled yet:
1) each card is expensive. do testers buy them, and then forced to do work too? that's not really fair. do i just add the costs of these cards to the bulk order price per card to recoup?
2) hardware is in flux at the moment. how do we change parts on cards that have been scattered around the world?
3) are testers expected to able to solder to make mods? How about debugging code? We need testers who are able to get their hands dirty and say more than "xyz doesn't work" and help us find out why/where/how something may be at fault.

ideas and suggestions are welcome!

Mike Chambers
April 18th, 2009, 12:45 PM
At the moment, both PCBs (first prototype run of 10) and some parts are racing their way toward me via UPS. I suspect I'll have everything by the end of next week. I'm then going to pack everything up and ship at least 1 set of everything to andrew for first assembly, and we'll see where that takes us.

With luck, we will having working PCBs and a combination of ICs that work solid and are readily available. Then I'll build up some more boards and those get distributed to testers.* Once it's been through the wringer a few times, we will then push the big button and get 100 cards made up and the madness begins! No ETA on the big order because we have no idea what sort of things will creep up in the beta phase.

stay tuned...


* Not sure how the testers scene is going to be handled yet:
1) each card is expensive. do testers buy them, and then forced to do work too? that's not really fair. do i just add the costs of these cards to the bulk order price per card to recoup?
2) hardware is in flux at the moment. how do we change parts on cards that have been scattered around the world?
3) are testers expected to able to solder to make mods? How about debugging code? We need testers who are able to get their hands dirty and say more than "xyz doesn't work" and help us find out why/where/how something may be at fault.

ideas and suggestions are welcome!

i was kidding about the tester bit, but i actually could do it if you'll be sending a few off for that purpose. i'm far from an ASM expert though, which is probably vital in debugging the code. i do have a massive variety of 8088 motherboards i can try it in though. i could also try it in my tandy 1000tx. there are probably a number of better choices of people to send to here, but i can definitely give the card a workout with diff machines/drives.

per
April 18th, 2009, 01:43 PM
At the moment, both PCBs (first prototype run of 10) and some parts are racing their way toward me via UPS. I suspect I'll have everything by the end of next week. I'm then going to pack everything up and ship at least 1 set of everything to andrew for first assembly, and we'll see where that takes us.

With luck, we will having working PCBs and a combination of ICs that work solid and are readily available. Then I'll build up some more boards and those get distributed to testers.* Once it's been through the wringer a few times, we will then push the big button and get 100 cards made up and the madness begins! No ETA on the big order because we have no idea what sort of things will creep up in the beta phase.

stay tuned...


* Not sure how the testers scene is going to be handled yet:
1) each card is expensive. do testers buy them, and then forced to do work too? that's not really fair. do i just add the costs of these cards to the bulk order price per card to recoup?
2) hardware is in flux at the moment. how do we change parts on cards that have been scattered around the world?
3) are testers expected to able to solder to make mods? How about debugging code? We need testers who are able to get their hands dirty and say more than "xyz doesn't work" and help us find out why/where/how something may be at fault.

ideas and suggestions are welcome!

As long as the final board will be under $75 each, you will be able to sell them. If you mannage to stay under $50, you will be safe to sell most if not all of them.

What is the actual total cost per card if a bulk of 100 is made the same way you make the 10 beta cards?

NobodyIsHere
April 18th, 2009, 03:46 PM
[snip]

* Not sure how the testers scene is going to be handled yet:
1) each card is expensive. do testers buy them, and then forced to do work too? that's not really fair. do i just add the costs of these cards to the bulk order price per card to recoup?
2) hardware is in flux at the moment. how do we change parts on cards that have been scattered around the world?
3) are testers expected to able to solder to make mods? How about debugging code? We need testers who are able to get their hands dirty and say more than "xyz doesn't work" and help us find out why/where/how something may be at fault.

ideas and suggestions are welcome!

Hi Hargle! My recommendation is to count the initial batch of PCBs and parts as development overhead and spread the cost across the production units. You are certainly entitled to recoup your costs and even make a fair profit considering the money, time, blood, sweat, and tears that have gone into this project. The vintage computer community as a whole will benefit from making this part available so I do not think it unreasonable to ask for some help to make it happen. I am sure there people willing to help if given an opportunity. I know am willing to help and will continue to support the project as best I can. Life isn't fair and I think we all know that.

My recommendation is the initial round testers should be chosen from a pool of willing and able volunteers. By able, I mean those with the resources and patience to deal with the design hardware and software in an early developmental state. Like be ready with the technical skills, parts, DEBUG, a razor blade, a hot soldering iron, and an oscilloscope warmed up and ready to go. Most likely the initial round testers are going to discover problems that will range from minor to severe and everything in between. More than just find problems the initial testers should be capable of delving into the design to make recommendations on hardware and software fixes.

In addition, I recommend that the initial round testers be given an option of just receiving the PCB alone and letting them supply their own parts. That will lower your costs, hopefully, improve some variety in the testing and possibly lead to improvements in parts selection as the discussion ensues. I strongly recommend all the initial round testers use sockets for parts and be ready to desolder components for replacement as needed. In addition, they should be prepared with techniques like "cuts and jumpers" and "dead bug" modifications to tweak the design as needed. I don't think that would be necessary but who knows what is lurking in the bowels of this thing waiting to be discovered.

I believe there are plenty of qualified people here based on the above description and would be willing to volunteer to test. If the cost of ordering the initial round of PCBs is too much of a burden, I also think it reasonable that the testers or any other interested volunteers be allowed to *donate* some funds to cover the costs. I don't know what your PCB unit costs finally turned out to be but I suspect its probably in the $20 range or so. I have no problem sending you $20 plus shipping for an initial round PCB. That being said, please PLEASE do not accept pre-paid orders, advance orders, etc as those are the short path to hell.

Frankly, I consider any of my time, effort, money, or whatever in this project to be ENTERTAINMENT and if it ended tonight I'd consider it a success. That's my $0.02. I hope it helps.

Thanks and have a nice day!

Andrew Lynch

gerrydoire
April 18th, 2009, 04:12 PM
You can add me to the first round of testers..

:-D

Mike Chambers
April 18th, 2009, 09:35 PM
same here if you think i am qualified enough. i'm no electrical engineer, but i'm handy enough with a soldering iron and a razor blade if there needs to be some rewiring done for testing. my 1000tx would also be a good oddball machine to test it in. even more so with the 1000hx if i get an ISA adapter for it.

per
April 19th, 2009, 12:43 AM
I would recomend that participating for testing should be done basically by PM as it might flood the board. If voting is to take place, that'll be in another thread.

Speaking for myself, where do you get oscilloscopes?

Ole Juul
April 19th, 2009, 01:43 AM
per: Speaking for myself, where do you get oscilloscopes?
Even a small electronics store should have one or two in stock. It may be best to do mailorder though - look for "test instruments". Good scopes are expensive so be careful that it can do what you want - especially frequency wise. There's a big difference in scopes. That said, if you don't have one, then any old used scope can be great to have, just be aware that many old ones are not worth more than 20 bucks. Someone into ham might be able to give you a junker. You'll learn a lot!

per
April 19th, 2009, 04:53 AM
Even a small electronics store should have one or two in stock. It may be best to do mailorder though - look for "test instruments". Good scopes are expensive so be careful that it can do what you want - especially frequency wise. There's a big difference in scopes. That said, if you don't have one, then any old used scope can be great to have, just be aware that many old ones are not worth more than 20 bucks. Someone into ham might be able to give you a junker. You'll learn a lot!

Problem solved. My uncle got one I can borrow (he actually never use it, however he don't want to sell it to me).

barythrin
April 20th, 2009, 12:30 PM
I got mine from a ham radio conference. The only catch would be to know if what you're troubleshooting would have a higher frequency than the oscilloscope can handle. Borrowing one is also a good choice as you found.

hargle
April 21st, 2009, 05:32 PM
PCBs are in!

They look great, even fit into an ISA slot! :)

I think these things will be really easy to build up, with probably the most intensive soldering part being the 40 pin connector.

Fantastic job andrew!

Unknown_K
April 21st, 2009, 06:17 PM
Looks nice, how many did you make (I asume they are for testers at this point)?