• Please review our updated Terms and Rules here

8-Bit IDE Controller

mbbrutman said:
[snip]
So just an idea for now but what do you think of memory mapping?

Mike
Click to expand...

Hi! I think you could make memory mapping work. It would require another set of memory decode logic (jumpers, 74LS688, pull up resistors, etc). If the memory decoding logic is specific to just 2 memory addresses then you would need to check 19 address lines which would lead to a lot of new parts as each 74LS688 can only check 8 each. In addition, whatever changes to the circuit to support the new access mode would be on top of that.

My recommendation is to think through the design and write up a schematic. Then we can look at some prototyping with wire wrap or cuts and jumpers on a PCB version. I strongly recommend prototyping any design before making PCBs. It is *very* easy to have oversights and mistaken assumptions that have dire effects on the design. Prototyping is the only practical method to test the theory, IMO.

Thanks and have a nice day!

Andrew Lynch
 
ok, so now we're at a crossroads.

Change to memory map to bump the performance up a notch, or press on with the existing design and get into production.

The BIOS will change very little between the two, so that's a non issue.

Andrew seems very busy and likely can't dedicate much more time to this project, so someone else hardware oriented could take on the task of trying to prototype this new card, but I can't do it.

Or we do both. Production/2nd proto of our current design, and we play around with DMA and or memory mapped stuff over the next several months and come out with XTIDE mk II sometime next year and see what kind of interest there is.
 
Nah, we are not a crossroads. By all means I want us to keep on the current path. (I intend to buy a few of these current cards - I'm really happy with the way everything has come out, except for the one stinky drive that I have to deliver to you.)

The memory mapping idea is more involved and it is going to require prototyping and debugging, just like this first version of the card did. I think it is a new branch of the tree and not the design direction for the current card.

I am just trying to figure out a low cost/low complexity way to get back some of the performance. We've got a simple card that meets our requirements - there is no sense in messing that up now. But I'm developing some ideas for another version of the card later on down the road. Memory mapping those registers gets rid of that ugliness where we need a flip flop to track whether we are reading the high or low byte - it makes the CPU do that for us. That part is elegant, but it reqiures more thought to make sure it's viable.

If you count cycles, I estimate the current loop takes 70 cycles, not counting the side effects from DRAM refresh cycles and instruction prefect weirdness on the 8088. I think that well over half of the loop would disappear if we didn't have to dink around with two port addresses, the shifting of of the low byte and the xchg. The way I'm wired 2x is hard to leave on the table. ;-)

Mike
 
hargle said:
ok, so now we're at a crossroads.

Change to memory map to bump the performance up a notch, or press on with the existing design and get into production.

The BIOS will change very little between the two, so that's a non issue.

Andrew seems very busy and likely can't dedicate much more time to this project, so someone else hardware oriented could take on the task of trying to prototype this new card, but I can't do it.

Or we do both. Production/2nd proto of our current design, and we play around with DMA and or memory mapped stuff over the next several months and come out with XTIDE mk II sometime next year and see what kind of interest there is.
Click to expand...

I say we move forwards with the current. But we need to do a small run on the new design.

The memory mapping is an interesting idea, but lets save that for PCB rev 2.
 
My goodness! I'm a bit overwhelmed by this thread, but I've managed to read through quite a bit of it.

I'd love to get on the list for a Rev. 2 (or new run of Rev. 1) card. I've just got my first 5150 PC, and I'd love to be able to add mass storage to it. It's got the original 5150's 65W power supply, so it's unable to power an MFM drive, and as you've all already noted, 8-bit IDE cards are rare and expensive. So the solution you've developed is ideal! I could easily power a CF card, or a modern 3.5" hard drive, and not strain the power supply.

Please let me know when the Rev.2 cards or kits are available. I've already got all the parts, and a device programmer for the EPROM, but that PCB is pretty essential ;) I'd also be open to doing a small run of PCBs myself if the gerber files are available (I'm still digging through the thread, but I haven't found them yet!)

I've subscribed to the thread, so I should get updates in email.

Thanks much!
 
Re: The Z80 Reh controller. He's talking about using the same I/O address for both halves of the data lines.

On the 8088, if I code (for example)

mov dx,120h
in ax,dx

The 8088 issues two I/O port reads; the first is for 120H and the second is for 121H (high order byte). It seems to me that it wouldn't take all that much logic to detect that situation and gate the correct byte.

That would let your read loop look something like this:

mov dx,<dataport>
mov cx,256
L1:
in ax,dx
stosw
loop L1

It'd be hard to do much better on an 8088.

I apologize if this has been already discussed--I didn't feel that I had enough time to read the 90 or so pages of previous posts, so I only went back a couple of pages.
 
Hi! One idea would be to set aside a separate range of 16 IO ports immediately above the $300-$30F range that implemented the alternating reads/writes to the port. That way little additional changes would be necessary just remove the lowest address line (A4) from the 688 and use the A4 line to distinguish between the upper 16 and lower 16 IO port ranges.

The first read to the upper 16 would reveal LO port the next HI port. Basically implement using a 74LS74 flip flop on A3 to mirror the IO ports and toggling with subsequent reads using the upper 16 IO ports address decoder as a clock. Possibly tying the flip flop's reset line to the lower 16 IO ports decoder to prevent it from getting out of sync. Use AND gates to qualify A0, A1, and A2 with /A4 so that any read to the upper 16 make the existing circuit appear that A0, A1, and A2 are LOW and A3 comes from the flip flop but would have to be qualifed with the ISA bus A3 to ensure compatibility with the existing circuit.

In theory the design would preserve compatibility with the current BIOS since the existing IO ports and circuitry would still be in place (lower 16). You could basically ignore the upper 16 until the BIOS was modified to use the upper 16 IO ports. Still, this is notional stuff off the top of my head so it would still need the normal design, schematic, prototype, etc cycle. At a minimum, it would require 4 more chips (74LS32, 74LS04, 74LS08, 74LS74) unless there are spare gates we could use (I don't remember).

This is a pretty major change to the design. However, since the existing circuitry is largely unmodified someone could implement proof of concept prototype using an existing PCB with just cuts and jumpers to a "dead bug" modification. Any takers? Mike? Richard? Chuck?

Thanks and have a nice day!

Andrew Lynch
 
I'd be willing to work it out, but I've only been watching this project from the peanut gallery, so I don't know if I'm the person to begin hacking on this thing.

But leaving that, my change is pretty basic. You've already got the circutry to gate the upper or lower 8 bits onto the bus. So you could use a flip-flop to toggle the upper/lower accesses; said flip-flop would be reset by any I/O or memory access that isn't to the data port+1 address, since the two 8-bit accesses of a 16-bit I/O instruction happen without any intervening memory or I/O references.
 
hargle said:
i'm speaking for per, and i certainly shouldn't be.
Flash does program the part-that's the only thing I have ever used.
If you aren't moving the IO space, then flash is all you need.

If setcard can flash the part as well, then the 2 programs should be merged together so you just load up the binary image, then tweak IO address as required, and flash it all is one swell foop.

I'll leave the rest of these flash program issues for per to answer.
Click to expand...
I'm not really home from vacation yet, but I just got a minute of internet access.

The only similarity between the setcard and the flasher is the flashing engine. The rest of the two programs are not similar; Setcard gets the image from ROM, and asks for new settings, while Flash gets the image from a file, and doesn't need the signature to be present at the target address.

I've been thinking of combining them, but I figured they work best as two seperate utilities because they use the same command line options for different purposes. In addition, it's impossible to fit the entire "syntax" line on the screen if both programs are combined ;) .


The errors reported by the flasher is simply because (for some strange reason) the flasher can't properly read the first bytes after a write. It's just normal move instructions, so I don't understand why it fails on some cards.
 
lynchaj said:
Any takers? Mike? Richard? Chuck?
Click to expand...

If you mean ME, I don't even HAVE one of these cards.

However, it could be easily done by sticking chips on top of existing chips, soldering the ground and Vcc legs to the chip below, bending the other pins out parallel to the board, make your cuts and use wirewrap wire to connect the appropriate pins on the new chips into the circuit.
 
Richard, I am sorry, I thought you had a card. I'd like to do it myself as I don't think this would be very hard to do but I am a bit overwhelmed at the moment.

I have N8VEM three boards in work right now (6809 host processor PCB build and debugging, VDU PCB trace optimization, and PropIO prototype and test phase). It is a bit of a juggling act but it sure is fun!

Thanks and have a nice day!

Andrew Lynch
 
Where do we stand on the design for the next run of the card? I am looking at the design now and its pretty good IMO.

What I want to do is get a table made up for the switch settings and jumper settings to be silk screened on the back side of the card, but in order to do this I need a re-cap of what Andrew did with them.
 
lutiana said:
Where do we stand on the design for the next run of the card? I am looking at the design now and its pretty good IMO.

What I want to do is get a table made up for the switch settings and jumper settings to be silk screened on the back side of the card, but in order to do this I need a re-cap of what Andrew did with them.
Click to expand...

I too would like to see us move to the next level. I think the BIOS is pretty solid, barring any weird tandy issues and a few straggling hard drives.

I don't recall the current list of hardware issues, but the one that I do know about is the CSEL one. Currently the CSEL line is pulled high, which is something that andrew did in previous designs that helped some WD drives work.
I've found that on our card, the CSEL line being pulled high caused issues with drives which were jumpered for cable select. By pulling that line low, my issues went away.
The new design has a 3 pin jumper so it can be configured either way. I personally don't see the need for this, and would like it just pulled low and taken out of the design altogether to simplify the design and build. I'm a sample size of one though, so if someone else with a bit of soldering skill could try that on their end, that would be nice to get another opinion on.


As for jumpers and a silkscreen, here's the data we're working on:
Andrew should really double check this!!
IO Range, dipswitches 8:5
Code: 
0000 = 200h
0001 = 220h
0010 = 240h
0011 = 260h
0100 = 280h
0101 = 2A0h
0110 = 2C0h
0111 = 2E0h
1000 = 300h
1001 = 320h
1010 = 340h
1011 = 360h
1100 = 380h
1101 = 3A0h
1110 = 3C0h
1111 = 3E0h
The above assume IO line 9 is pulled high, and 4:0 are pulled low, and the dipswitches are acting as bits 8:5.

Memory address, switches 4:1
Code: 
0000 = C0000-C1FFF (likely invalid, since that would clash with video)
0001 = C4000-C5FFF (ditto)
0010 = C8000-C9FFF
0011 = CC000-CDFFF
0100 = D0000-D1FFF
0101 = D4000-D5FFF
0110 = D8000-D9FFF
0111 = DC000-DDFFF
1000 = E0000-E1FFF
1001 = E4000-E5FFF
1010 = E8000-E9FFF
1011 = EC000-EDFFF
1100 = F0000-F1FFF (probably invalid here onward too)
1101 = F4000-F5FFF
1110 = F8000-F9FFF
1111 = FC000-FDFFF

That's assuming bits A19=1 and A18=1, and A13=0.
The dipswitches represent A17:A14
 
Hi! I will be gone this weekend camping with the family. I'll pick this back up on my return Sunday night. Thanks and have a nice day!

Andrew Lynch
 
Hi All! I uploaded new a schematic and PCB layout on the N8VEM wiki in the XT-IDE folder. Please check it out and make any comments.

I think there are two things we need:
1. someone to find out the old "to do" list and see if those have been checked off. I think so but its good to double check. Also run against the schematic and PCB layout to ensure everything is there.

2. volunteer trace routing station. Needs to be a fast computer than can run undisturbed for at least 3-4 weeks for trace optimization run. It will require some minor care and feeding to tend to the process as its running. Normally I would do this but my machines are all booked solid running other N8VEM jobs. I run a 3.2 GHz P4 with 512MB RAM Linux w/Java 6 and it is painfully slow

Thanks and have a nice day!

Andrew Lynch
 
lynchaj said:
Hi All! I uploaded new a schematic and PCB layout on the N8VEM wiki in the XT-IDE folder. Please check it out and make any comments.

I think there are two things we need:
1. someone to find out the old "to do" list and see if those have been checked off. I think so but its good to double check. Also run against the schematic and PCB layout to ensure everything is there.

2. volunteer trace routing station. Needs to be a fast computer than can run undisturbed for at least 3-4 weeks for trace optimization run. It will require some minor care and feeding to tend to the process as its running. Normally I would do this but my machines are all booked solid running other N8VEM jobs. I run a 3.2 GHz P4 with 512MB RAM Linux w/Java 6 and it is painfully slow

Thanks and have a nice day!

Andrew Lynch
Click to expand...

Is it threaded? I've got a newer Intel quad core with 3GB of RAM that should make short work of that.

Mike
 
You must log in or register to reply here.
Back
Top