MiSTer FPGA Forum

Here is everything I know so far for the development of an 8-bit XTIDE compatible IDE required by the core.

I think one of the keys might be to have a module similar to the FC1306 IC, details attached. In real life, this IC is used to make SD cards compatible with the IDE interface:

https://es.aliexpress.com/item/1005004418446003.html

I haven't found anything similar written in Verilog/VHDL yet, maybe it's because of my ignorance, because maybe what we need, with a similar function is the following:

https://opencores.org/projects/ata

But I couldn't tell you how to fit it with the SD card interface, which in the end, I think, would be the first step to put it together with the MiSTer HPS.

All this for 16 bits of course, on the other hand, the following circuitry would have to be replicated to convert it to 8 bits and finally be compatible with the XTIDE BIOS. In real life, there are Compact Flash or IDE to 8-bit IDE adapter cards, and there is also a project that has reduced all that conversion logic to 8-bit from a CPLD project (I attach sources too):

http://dangerousprototypes.com/docs/XT_ ... controller

This would be the hard way but compatible with the official XTIDE BIOS version. There may be other options, simpler, by emulation, etc... and adaptation of XTIDE BIOS, because the sources are available, but it would also require a good study of how it works, to be able to adapt it.

In any case, these are issues that for me personally, at least for the moment, would be out of my reach.

In short, we need to:

• incorporate the OpenCore IDE controller project, but this is 16-bit... or maybe we can take advantage of the IDE development used on ao486.

• The core however cannot handle 16 bits, and for that there is the XTIDE BIOS, which requires the accesses to be 8 bits, and would work on the 300h I/O port, so we need to make use of the implementation that is currently in CPLD to move these 16 bits to 8 bits.

Would it be possible to add something like MiSTerFS in the current state of the core, or does that need interaction with the IDE hardware?

That and sysctl would be really useful utilities to have .

Newsdee wrote: ↑Tue Oct 18, 2022 12:10 pm Would it be possible to add something like MiSTerFS in the current state of the core, or does that need interaction with the IDE hardware?

That and sysctl would be really useful utilities to have .

I think it might be able to work with how it currently is, but that it would make more sense to wait for the HDD to be IDE based. But that depends on how much work it would require to develop MiSTerFS for this I guess. I suspect it would also be easier to get to work if its IDE based.

Newsdee wrote: ↑Tue Oct 18, 2022 12:10 pm That and sysctl would be really useful utilities to have .

sysctl and other ctl I do plan to do it later, it's not complicated at all. Just reserve some I/O ports and develop the EXE programs, which are also simple.

What specifically is the difficulty? We have the schematic of the XTIDE controller which is 8-bit, so it should be easy (but maybe time consuming) to implement the controller in Verilog or VHDL. Theoretically, this should be easy to wire the 8-bit connectors into the existing PCXT core. The controller then needs to "hook up" to a virtual hard drive with it's IDE connector. Is that the difficult part? I have an electrical engineering degree, but it is from the 90's and I don't do that for a living, so I am no current expert, and have no MiSTer development experience. I want to help if I can, but I am not the person to actually do the work since I am not a VHDL or Verilog coder currently. I have used Quartas in the past to draw logic circuits and program them into PLCC's successfully. If the difficulty is programming the XTIDE into VHDL or Verilog, maybe Quartas still has the ability to take circuit drawings as input and this can be drawn in from the existing schematic. I don't know how everything ties together with the various MiSTer core components and if they all need to be the same type or if some can be VHDL while others are Verilog and others are circuit drawings.

Another approach is to fake it and capture any calls to the IDE card and return expected results, and on the back end, write your own code to read and write this to a VHD file.

Without looking at the internals, my assumption is that most of a hardware IDE controller wouldn't be applicable, unless you're planning to drive physical IDE drives. I'm not an FPGA dev, and may be saying something stupid here, but I would assume that you'd probably want to wire up the I/O ports for an IDE controller to the Linux side of things, and then have a service program there that accepts IDE commands and returns the correct result after interacting with whatever file it's connected to. It seems like you'd barely use any FPGA resources, since there's no actual drive hardware to talk to, and that most of the effort would need to be in the software driver.

Minimig has a fairly complete IDE implementation; I don't know if it works this way, and don't have the expertise to look, but you might be able to steal ideas or even code from it. It's complete enough to keep AmigaOS perfectly happy, so it might be good enough for the PC BIOS. It was ported from the MiST board, however, and it may be a fundamentally bad design from the Mister point of view.

Malor wrote: ↑Thu Oct 27, 2022 2:34 am Without looking at the internals, my assumption is that most of a hardware IDE controller wouldn't be applicable, unless you're planning to drive physical IDE drives. I'm not an FPGA dev, and may be saying something stupid here, but I would assume that you'd probably want to wire up the I/O ports for an IDE controller to the Linux side of things, and then have a service program there that accepts IDE commands and returns the correct result after interacting with whatever file it's connected to. It seems like you'd barely use any FPGA resources, since there's no actual drive hardware to talk to, and that most of the effort would need to be in the software driver.

Minimig has a fairly complete IDE implementation; I don't know if it works this way, and don't have the expertise to look, but you might be able to steal ideas or even code from it. It's complete enough to keep AmigaOS perfectly happy, so it might be good enough for the PC BIOS. It was ported from the MiST board, however, and it may be a fundamentally bad design from the Mister point of view.

I suppose it is also possible to do something like you say, the bad thing is that it closes the development to the particularities of MiSTer and its Linux part... as it happens right now with the floppy solution, we depend a lot on Linux and it closes the doors to port to other FPGAs.

From what I understood from Malor is that you just need what we say in development 'duck typing'. "If it walks like a duck and it quacks like a duck, then it must be a duck".

If it talks like an IDE, then it must be an IDE.

I wish someone would answer my questions. Not sure what I did to get blacklisted. Also, I am not sure how other platforms handle writing to the microSD card when writing to VHD files if they are all the same or not, so maybe each platform needs to deal with that part of the development separately anyway. I don't know.

thorr wrote: ↑Thu Oct 27, 2022 5:05 pm I wish someone would answer my questions. Not sure what I did to get blacklisted.

No, not blacklisted. From what I understood from the core author he lacks the knowledge to do this from scratch, even the duck typing implementation of ide.

So any help I guess will be appreciated from spark

thorr wrote: ↑Thu Oct 27, 2022 5:05 pm I wish someone would answer my questions. Not sure what I did to get blacklisted. Also, I am not sure how other platforms handle writing to the microSD card when writing to VHD files if they are all the same or not, so maybe each platform needs to deal with that part of the development separately anyway. I don't know.

Indeed, I do not have sufficient knowledge to develop this implementation. The idea of this thread is to provide information and ideas so that someone can implement it, I appreciate your ideas too... don't feel excluded or blacklisted

Thanks. I am still not sure exactly what specific knowledge is missing so it is difficult to know what information is needed to help solve it. Is it about how IDE works, or about having already written Verilog or VHDL code for an 8-bit IDE card, or about getting information out of the core into the VHD file once an IDE card is connected to it? From the first post above, it sounds like you may just need Verilog or VHDL code for an 8-bit IDE card. If this is all that is needed, then I almost feel like this is within my reach of providing if I spent a lot of time on it since I have no experience with the MiSTer development or coding in Verilog or VHDL, but I do know some logic circuit design. For any other core developer that can take a schematic and create a core, this should be super easy and maybe just asking some known core developers directly to help might work.

I found this article that might be very helpful, but maybe not. I hope it is: http://blog.retroleum.co.uk/electronics ... interface/ Perhaps with the knowledge in this article, an existing MiSTer 16-bit IDE card can be implemented in the core with the few bits of logic to convert it to 8-bit.

Starting with this part, and the paragraphs after. There are additional links at the bottom of the article with even more information.

"A basic 8 bit interface must handle the 16 bit databus, a 3 bit address bus, 2 chip select lines, /Read & /Write lines. (/Reset can be tied to the host system’s reset line) To convert 8 to 16bit you can use two 8 bit latches, one for outgoing data and one for incoming data. When reading the low half of the IDE data bus, the high 8 bits can be latched, you can then read the contents of the latch afterwards. When writing, you write the high byte to the other 8 bit latch, and this byte is presented to the high part (D8:D15) of the IDE databus when you write the low half (D0:D7) directly. It’s probably best to also include a bus-transceiver (EG: 74HC245) in the interface to provide a single load point to the host’s databus, it isn’t absolutely necessary though."

spark2k06 wrote: ↑Thu Oct 27, 2022 7:11 am

Malor wrote: ↑Thu Oct 27, 2022 2:34 am Without looking at the internals, my assumption is that most of a hardware IDE controller wouldn't be applicable, unless you're planning to drive physical IDE drives. I'm not an FPGA dev, and may be saying something stupid here, but I would assume that you'd probably want to wire up the I/O ports for an IDE controller to the Linux side of things, and then have a service program there that accepts IDE commands and returns the correct result after interacting with whatever file it's connected to. It seems like you'd barely use any FPGA resources, since there's no actual drive hardware to talk to, and that most of the effort would need to be in the software driver.

Minimig has a fairly complete IDE implementation; I don't know if it works this way, and don't have the expertise to look, but you might be able to steal ideas or even code from it. It's complete enough to keep AmigaOS perfectly happy, so it might be good enough for the PC BIOS. It was ported from the MiST board, however, and it may be a fundamentally bad design from the Mister point of view.

I suppose it is also possible to do something like you say, the bad thing is that it closes the development to the particularities of MiSTer and its Linux part... as it happens right now with the floppy solution, we depend a lot on Linux and it closes the doors to port to other FPGAs.

I think IDE support would have to be a per-platform thing. I don't think there are enough pins free on the Mister to talk to real IDE hardware, so you're going to be stuck with a software implementation pretty much no matter what. And if you have to talk to the software side to get anything done anyway, then putting the brains on that side is probably going to be the best approach. Complex work on the FPGA side is probably not going to be useful, it's just making things more difficult without actually accomplishing anything.

So, yes, this is a sort of duck typing; you'd be providing the I/O ports only on the FPGA side, and then using software to make it walk like an IDE controller. I think the same approach would be required on every board that's trying to talk to virtual files instead of real hardware, so the interface and at least a little bit of the driver code would need to be customized per-board. Boards without a Linux side wouldn't be able to do it, but I don't see any other way they could do it, either, short of connecting to real hardware.

Ok, I just now thought of a possible FPGA-based solution; you could potentially connect to an SD card in the secondary slot, which other cores have done in the past. But that would be a heck of a lot of work for very little actual benefit, at least on the Mister. It probably wouldn't be that portable, either. It would be easier and far more flexible to do the driver code on the Linux side. And there should be lots of software IDE code out there to look at. PCEM would probably be the first spot I'd look.

As an additional thought: the transition from FPGA to software has to happen *somewhere* in the stack. You could potentially implement a full IDE controller, and then use software to emulate only the drive, but I suspect you might need more pins that way.

It seems to me that there's basically a choice between a software IDE drive and a software IDE controller, and doing it as a controller should be easier.

I had the same thoughts, but there needs to be enough of the hardware there so the core thinks there is an IDE card in there and it needs to be able to keep up with the strict clock cycle timing it is expecting. Then it is a matter of knowing how to take the data out of and into the FPGA side and manipulate the VHD file on the software side to read from and write to it.

I know that in real life there were IDE cards that could operate as either 8-bit or 16-bit but when used on an 8-bit bus only half the physical drive space was accessible. I don't know if that information helps at all.

dmckean wrote: ↑Thu Oct 27, 2022 9:17 pm I know that in real life there were IDE cards that could operate as either 8-bit or 16-bit but when used on an 8-bit bus only half the physical drive space was accessible. I don't know if that information helps at all.

Xt-ide has a multiplexing circuit to do so.

thorr wrote: ↑Thu Oct 27, 2022 8:43 pm I had the same thoughts, but there needs to be enough of the hardware there so the core thinks there is an IDE card in there and it needs to be able to keep up with the strict clock cycle timing it is expecting. Then it is a matter of knowing how to take the data out of and into the FPGA side and manipulate the VHD file on the software side to read from and write to it.

My knowledge is pretty vague, but I don't think the hardware detection takes very much. If you look at the XT-IDE BIOS, it's probably just poking a few memory locations for I/O, and there may be a RAM buffer of some kind. DOS will be calling into the BIOS for I/O services, so as long as the BIOS thinks a card is there, it should respond appropriately.

It's possible that some of the queries could take very tight timing, which could force them to be implemented on the FPGA side, since the software side can be delayed by the kernel. It could be that the correct point to transition from hardware to software actually is at the drive level, rather than the controller level, because drives were expected to be variable speed, delayed for any number of reasons, where the controller itself usually wasn't.

At *some* point in the stack, lag will be acceptable, and it's probably at that interface that the system should transfer from FPGA to software driver. As soon as a few milliseconds delay doesn't matter anymore, that's a likely handoff point.

Malor wrote: ↑Thu Oct 27, 2022 10:00 pm

thorr wrote: ↑Thu Oct 27, 2022 8:43 pm I had the same thoughts, but there needs to be enough of the hardware there so the core thinks there is an IDE card in there and it needs to be able to keep up with the strict clock cycle timing it is expecting. Then it is a matter of knowing how to take the data out of and into the FPGA side and manipulate the VHD file on the software side to read from and write to it.

My knowledge is pretty vague, but I don't think the hardware detection takes very much. If you look at the XT-IDE BIOS, it's probably just poking a few memory locations for I/O, and there may be a RAM buffer of some kind. DOS will be calling into the BIOS for I/O services, so as long as the BIOS thinks a card is there, it should respond appropriately.

It's possible that some of the queries could take very tight timing, which could force them to be implemented on the FPGA side, since the software side can be delayed by the kernel. It could be that the correct point to transition from hardware to software actually is at the drive level, rather than the controller level, because drives were expected to be variable speed, delayed for any number of reasons, where the controller itself usually wasn't.

At *some* point in the stack, lag will be acceptable, and it's probably at that interface that the system should transfer from FPGA to software driver. As soon as a few milliseconds delay doesn't matter anymore, that's a likely handoff point.

Sorgelic already said something like this:

"Just define your own ports close match to sd_* signals of hps_io module and directly read/write sectors from mounted images."

I guess other fpga should have another way to read sd cards.

jordi wrote: ↑Fri Oct 28, 2022 5:20 am

Malor wrote: ↑Thu Oct 27, 2022 10:00 pm

thorr wrote: ↑Thu Oct 27, 2022 8:43 pm I had the same thoughts, but there needs to be enough of the hardware there so the core thinks there is an IDE card in there and it needs to be able to keep up with the strict clock cycle timing it is expecting. Then it is a matter of knowing how to take the data out of and into the FPGA side and manipulate the VHD file on the software side to read from and write to it.

My knowledge is pretty vague, but I don't think the hardware detection takes very much. If you look at the XT-IDE BIOS, it's probably just poking a few memory locations for I/O, and there may be a RAM buffer of some kind. DOS will be calling into the BIOS for I/O services, so as long as the BIOS thinks a card is there, it should respond appropriately.

It's possible that some of the queries could take very tight timing, which could force them to be implemented on the FPGA side, since the software side can be delayed by the kernel. It could be that the correct point to transition from hardware to software actually is at the drive level, rather than the controller level, because drives were expected to be variable speed, delayed for any number of reasons, where the controller itself usually wasn't.

At *some* point in the stack, lag will be acceptable, and it's probably at that interface that the system should transfer from FPGA to software driver. As soon as a few milliseconds delay doesn't matter anymore, that's a likely handoff point.

Sorgelic already said something like this:

"Just define your own ports close match to sd_* signals of hps_io module and directly read/write sectors from mounted images."

I guess other fpga should have another way to read sd cards.

The IDE controller on the AO486 core is terrible, so while that may work, it may not be the best approach.

Malor wrote: ↑Fri Oct 28, 2022 7:39 am The IDE controller on the AO486 core is terrible, so while that may work, it may not be the best approach.

It might be a starting point, and the developers of this core want everything to be perfect, so maybe it can be fixed after it is implemented.

Malor wrote: ↑Fri Oct 28, 2022 7:39 am The IDE controller on the AO486 core is terrible, so while that may work, it may not be the best approach.

It would still be an improvement over serdrive

If I'm not mistaken, using the 2nd SD card is simpler and similar to how MiST handles file load. But it also means that you can't access that data via FTP (because that card is directly wired to the FPGA).

Maybe it can be an intermediate step to keep it compatible with MiST. But personally I'd rather have the ao486 controller as it is more convenient.

Given that Minimig comes from a different FPGA, I'd say that studying that implementation is a better idea than focusing on ao486's.

My understanding is that in MiSTer, you have to communicate with the Linux side via the HPS_IO to read or write data from VHD image files. I still don't know how that works, but there are plenty of cores that do this so it seems like it's a question of looking into it in enough detail.

If it's AO486 or nothing, then that would be much better than serdrive. But it would be nice to see an IDE controller that looks more correct to the BIOS and OS.

Don't pay too much attention to my opinion, however, as my knowledge of the PC is at the software level, definitely not down in the hardware weeds. I can't meaningfully help with this effort, so what I think about the problem is mostly irrelevant.

pgimeno wrote: ↑Sat Oct 29, 2022 8:49 pm Given that Minimig comes from a different FPGA, I'd say that studying that implementation is a better idea than focusing on ao486's.

Minimig relies heavily on the FPGA board's "firmware" for disk access, same as MiSTer.
One difference is that (like MiST) it's coded in C and runs on a dedicated MCU, whereas for MiSTer it was ported to be a C++ Linux executable.

AFAIK Sidi uses the same firmware code, so that approach would work at least on 2 other boards then MiSTer. Others will probably need a dedicated port.

I Know Scsi is not the same as IDE, but, this might have clues

https://github.com/Grabulosaure/ss/blob ... csi_sd.vhd

Is anyone else working on this?
I would like to try just the XT-IDE bus conversion part first.

kitune-san wrote: ↑Mon Oct 31, 2022 12:58 pm Is anyone else working on this?
I would like to try just the XT-IDE bus conversion part first.

I think nobody is working on this topic at the moment so your work would be more than welcome.

kitune-san wrote: ↑Mon Oct 31, 2022 12:58 pm Is anyone else working on this?
I would like to try just the XT-IDE bus conversion part first.

There is no news that anyone is currently actively working on this feature, so of course it will be a welcome thing, so that we can finally get rid of serdrive

Progress report:
I used an AO486 IDE and connected it to the PCXT bus.
When a VHD file is set, universal BIOS returns recognition.
However, after this, it does not work properly.
For some reason, it also recognizes slave that do not exist.