• Please review our updated Terms and Rules here

XT-IDE rev 4 Development

glitch said:
I don't know if this is the case for your particular card, but sometime around 2007 I had to stop using SanDisk Extreme CF cards in embedded builds due to SanDisk intentionally crippling the native IDE mode on them. I forget which cards it specifically included, but apparently they didn't like that people were using their high-end consumer CF cards as SSDs, instead of buying their much more expensive IDE SSDs or "industrial" rated CF cards.

You can find a lot of reports from the embedded Linux/homebrew router community at the time.
Click to expand...

I see. Is the D7 pull-down a way to circumvent this crippling?
 
I guess this thread is as good as any so here goes nothing;

With XT-IDE cards in High Speed mode, writes are done with two 8-bit OUTs and reads are done with a single 16-bit IN.

Question: can reads be done using two 8-bit INs? Something like this;
Code: 
%ifdef USE_186	; INS instruction available
	insb				; Load low byte from port DX to [ES:DI]
	inc	dx			; IDE Data Reg to XTIDE Data High Reg
	insb				; Load high byte from port DX to [ES:DI]
	dec	dx			; Restore to IDE Data Register
%else	; If 8088/8086
	in	al, dx			; Load low byte from port
	inc	dx			; IDE Data Reg to XTIDE Data High Reg
	stosb				; Store byte to [ES:DI]
	in	al, dx			; Load high byte from port
	dec	dx			; Restore to IDE Data Register
	stosb				; Store byte to [ES:DI]
%endif
If possible, then this would allow for slightly faster reads on Olivetti M24 and friends.
 
I'm lacking some context here -- isn't 2 8-bit reads and 2 8-bit writes how the bios normally works if not configured for anything faster? How would this make things faster?

M24 background: M24 and clones don't handle 16-bit operations on the bus properly without hardware modification to the M24; search this forum for research into the "bus conversion kit"). I remember (nearly a decade ago) when I tried, my KINGSTON CF card showed up as "IKGNTSNO" and of course nothing worked past that. Reconfiguring for plain XT got everything working on the M24.
 
The issue is to do with the byte ordering to trigger the command pass through to the media.

Iirc in the Olivetti, the bus ordering of the 16 bit commands when made to an 8 bit device is reversed. But I don’t really follow the question, about using two commands instead of one?
 
Trixter said:
I'm lacking some context here -- isn't 2 8-bit reads and 2 8-bit writes how the bios normally works if not configured for anything faster? How would this make things faster?
Click to expand...

pearce_jj said:
But I don’t really follow the question, about using two commands instead of one?
Click to expand...

OK, I guess I'm being clear as mud. :)

Since it's not possible to reliably do 16-bit I/O on the M24, people with XT-IDE rev 2+ cards must use Compatibility mode and configure the XUB as if it was an XT-IDE rev 1.

This is what the code looks like when doing reads on this controller;
Code: 
%ifdef USE_186	; INS instruction available
	insb				; Load low byte from port DX to [ES:DI]
	xor	dl, bl			; IDE Data Reg to XTIDE Data High Reg
	insb				; Load high byte from port DX to [ES:DI]
	xor	dl, bl			; Restore to IDE Data Register
%else	; If 8088/8086
	in	al, dx			; Load low byte from port
	xor	dl, bl			; IDE Data Reg to XTIDE Data High Reg
	stosb				; Store byte to [ES:DI]
	in	al, dx			; Load high byte from port
	xor	dl, bl			; Restore to IDE Data Register
	stosb				; Store byte to [ES:DI]
%endif
Switching between the low and high data registers is done using XOR instructions because the registers are 8 bytes apart. When the controller is configured for High Speed mode the registers are next to each other and thus can be read with a single 16-bit input instruction (which is the whole point of the Chuck mod).

But we can't do that on the M24 so my idea is to use 8-bit input instructions but replace the 2-byte XOR instructions with 1-byte INC/DEC instructions. While this optimization won't be as fast as the real High Speed mode it will at least be faster than Compatibility mode. Think of it as XT-IDE 1.5 mode. :)

That is assuming it works of course. I have already done the necessary changes in code so it's ready for testing if anyone feel up to it. I just wanted to ask if this has any chance of working before possibly wasting someones time on doing tests.
 
Ah I see now! Yes that should work. Read the low byte first as this trigger the command to the media, then retrieve the cached (high) byte second. And of course the reverse for writes.
 
Incidentally it would be possible to modify the board for the machine to reverse the port mapping to alleviate this problem.
 
pearce_jj said:
Ah I see now! Yes that should work. Read the low byte first as this trigger the command to the media, then retrieve the cached (high) byte second. And of course the reverse for writes.
Click to expand...
Don't you mean the opposite of what you wrote (reading the high byte makes the next word available on the bus)?

pearce_jj said:
Incidentally it would be possible to modify the board for the machine to reverse the port mapping to alleviate this problem.
Click to expand...

Not sure what you mean here? Reversing the port mapping would allow for 16-bit writes (on regular machines, not the M24 and friends) but would also prevent 16-bit reads - not very useful. Or am I missing something?
 
If this new transfer mode works then future revisions of the XT-IDE card could simplify the design by dropping the Compatibilty/High Speed jumper altogether as it's only really needed on the M24. Though I realise that would prevent people from using older versions of the BIOS so might not be what everyone wants. Still, it would be an option.
 
I'll at least be leaving the jumpers on to allow folks to use the older revisions of the XUB and Hargle's BIOS, though being able to use the newer BIOS in an 8-bit mode even in high speed/Chuck Mod mode will make configuration a lot simpler for newcomers!

I don't see why doing 8-bit I/O on a card in high speed mode wouldn't work. Happy to test, though I don't have any of the "we did it in the wrong byte order" machines on hand.
 
Hi Peace & Krille

I have a M24, just next to me, with a Rev2 XT-IDE board (currently running R566) and a 128Mb CF that would be happy to help in testings.

Regards - Hervé
 
My kit finally got through customs, and the generous German postal service even dropped the package off without collecting the import duties they advanced. :D
Today I got around to assembling it and everything went great, except one thing: I can't for the life of me get the jumpers/breakaway header parts through the holes. It feels like I would need a hammer. That doesn't seem right. Is there too much through-hole plating on those holes, or did I get the wrong header? Or am I missing something else completely?
 
Kit or PCB, I'm assuming PCB as the Kit would have everything needed, If you bought the PCB from Glitch i would say it sounds like you bought or got sent the wrong size headers, Where did you get the headers from got a link ?.
 
Sumo said:
My kit finally got through customs, and the generous German postal service even dropped the package off without collecting the import duties they advanced. :D
Today I got around to assembling it and everything went great, except one thing: I can't for the life of me get the jumpers/breakaway header parts through the holes. It feels like I would need a hammer. That doesn't seem right. Is there too much through-hole plating on those holes, or did I get the wrong header? Or am I missing something else completely?
Click to expand...
I assembled a glichworks kit from tindie this week and experienced something similar but I was able to push them in with a screwdriver and, past a certain point, they would just "click" into place. I think the corners of the square header pins were catching the sides of the round hole.
 
Exceter said:
I assembled a glichworks kit from tindie this week and experienced something similar but I was able to push them in with a screwdriver and, past a certain point, they would just "click" into place. I think the corners of the square header pins were catching the sides of the round hole.
Click to expand...

Thanks. I'll try again later tonight. Your report gives me hope that I don't have to apply enough force to push the plating out of the holes.
 
Thanks again, Exceter. With force and a screwdriver I got the pins through the holes. The "click", at least in part, seems to be the pins disconnecting from the header. :D Got them through with some heat.

And sorry for the disconnected replies. I still need them to be approved by a mod.
 

Attachments

  • IMG_20190716_221933.jpg
    IMG_20190716_221933.jpg
    64.2 KB · Views: 1
Sumo said:
Thanks again, Exceter. With force and a screwdriver I got the pins through the holes. The "click", at least in part, seems to be the pins disconnecting from the header. :D Got them through with some heat.

And sorry for the disconnected replies. I still need them to be approved by a mod.
Click to expand...
Glad you got it working!
 
You must log in or register to reply here.
Back
Top