search

MiSTer-devel / Main_MiSTer

Main MiSTer binary and Wiki
GNU General Public License v3.0
3.01k stars 324 forks source link

Bring PCXT_MiSTer repo to mister-devel? #648

Closed jsmolina closed 1 year ago

jsmolina commented 2 years ago

This is a very interesting development, as many XT games (and apps) won't work on ao486. Examples of not working games on ao486 are: Prohibition, Tapper, Popcorn.

https://github.com/spark2k06/PCXT_MiSTer

The core is just missing a simpler way of loading FDD or HDD, as now it is using loopback serial interface.

sorgelig commented 2 years ago

Looking at TODO list, it's too early to talk about it. Some time ago i wanted to port Next186, but that core require direct SD card access. It's possible to use VHD as virtual SD card, but handling this core will be too difficult as you have to put all disk images inside VHD. So, yes, basically FDD and IDE must be implemented properly so images will be able to mount directly without VHD container.

spark2k06 commented 2 years ago

In this case nothing related to Next186 is used anymore, it is a combination of the MCL86, Graphics Gremlin and KFPC-XT projects as chipset, still with issues to be solved by its author, @kitune-san.

However, I have implemented a partial and temporary solution in beta 1.0, so that it can be used by more users and receive feedback, and it is nothing else than the internal UART loading of the MiSTer, with the help of serdrive running on the Linux side via a script.

There is still the challenge of providing 8-bit IDE support, but this has nothing to do with the complexity of the Next186, thanks to KFPC-XT, we have at our disposal a bus much easier to understand, even so, I for my part without some clear examples or implementation already developed, I find it difficult to provide IDE support ... and this is the point where the project is.

sorgelig commented 2 years ago

The way it mounts disk now is completely different than user may expect. It's not ready for wide audience. It also better to keep it away from downloader so normal users won't get strange core which they will complain about. I don't see a problem to do a beta testing on MiSTer forum providing a link to repository. When it will get usual way to mount through OSD file browser then there will be a time to move to MiSTer-devel and normal release.

spark2k06 commented 2 years ago

Yes, there is already a thread related to this core in the forum, and it is already starting to be tested by users from this latest beta:

https://misterfpga.org/viewtopic.php?p=54369#p54369

jsmolina commented 2 years ago

@sorgelig could you please give a tip on how floppy/HD access could be added to this core? Now it's pretty awesome and it's missing the 'productization'. Lof of thanks.

sorgelig commented 2 years ago

I gave tip on that thread: https://misterfpga.org/viewtopic.php?p=54419&sid=eb23e654827169037ca58447bbb57738#p54419 It will involve BIOS modification and specific to MiSTer I/O registers. So with custom interface it will be easier to implement than full IDE/FDC implementation. If it works with serial disk i/o, then should work with MiSTer i/o.

spark2k06 commented 2 years ago

I prefer the use of original BIOS to custom ones, for many reasons. Especially, maintenance and support of model-specific video modes, like Tandy.

Once we have a real IDE 8 bit/floppy implementation, the BIOS maintenance will be 0

spark2k06 commented 2 years ago

The IDE implementation must be compatible with XTIDE Universal BIOS, which is the one currently in use. It is a solid and mature BIOS for this purpose.

sorgelig commented 2 years ago

It's up to you. I just gave advice of probably simpler implementation for disk i/o.

As for IDE/FDC - probably it's worth to check which commands are used in BIOS and implement only that subset of commands in IDE and FDC. MiSTer already has IDE implementation available for cores. May be it's already enough, or just add missing commands if any.

jsmolina commented 2 years ago

@sorgelig sorry for my ignorance (I'm a developer, spark is the author):

If I understood correctly, the suggestion is to connect one PC_XT port directly to to sd_* signals of hps_io module and directly read/write sectors from mounted images.

Maybe to port 300h (IDE) directly? Or replacing COM1 source code of XT IDE source code to read instead of 0x3F8 for an unused port and adapt the interface to the expected by sd_* signals

sorgelig commented 2 years ago

I didn't look into code of core. So i cannot answer for specific question. Yes, my idea is to use custom BIOS code to mimic IDE/FDC read/write operation using sd_* signals. HDL code can add some wrapper for easier access, like sector transfer to a specific PC_XT memory address directly.