The online community for MiSTer FPGA enthusiasts
https://misterfpga.org/
kitune-san wrote: ↑Fri Apr 28, 2023 6:56 amIt may be due to the fact that I fixed the CHS of the drive to h=15 S=63 in this design.
Will reformatting it with a new drive make it usable?
Okay, I understand that it is not dynamic to obtain CHS. I will prepare an image of these characteristics and let you know. I will first try running FDISK and formatting.
spark2k06 wrote: ↑Fri Apr 28, 2023 7:36 amkitune-san wrote: ↑Fri Apr 28, 2023 6:56 amIt may be due to the fact that I fixed the CHS of the drive to h=15 S=63 in this design.
Will reformatting it with a new drive make it usable?Okay, I understand that it is not dynamic to obtain CHS. I will prepare an image of these characteristics and let you know. I will first try running FDISK and formatting.
In my case, what is happening is that it is not writing anything to the SD. With FDISK I make changes, but then they are not effective when I reboot, and formatting, it goes very slow and when I finish it doesn't transfer the OS with the /S option, because it hasn't actually written anything. From Windows you see the same content as before trying to write from MiSTer, I have tested it with SD cards of various sizes:
It is strange.
Would the results be the same using this?
In my environment I use 2GB and 32GB cards.
The 2GB card boots successfully.
The 32GB card can be formatted successfully and access FAT, but there is a problem with not being able to boot, which I am investigating.
kitune-san wrote: ↑Fri Apr 28, 2023 2:10 pmIt is strange.
Would the results be the same using this?
I still can't try it today... let's see if someone has the opportunity to try it in the meantime.
kitune-san wrote: ↑Fri Apr 28, 2023 2:19 pmIn my environment I use 2GB and 32GB cards.
The 2GB card boots successfully.
The 32GB card can be formatted successfully and access FAT, but there is a problem with not being able to boot, which I am investigating.
I have also tested with 2 and 32Gb.
When you have time, please try increasing the value of normal_spi_clock_cycle.
in my case...
kitune-san wrote: ↑Fri Apr 28, 2023 2:10 pmIt is strange.
Would the results be the same using this?
I have tried it and it doesn't work either, same symptoms. Let's see if someone else tries it and confirms the problem.
kitune-san wrote: ↑Fri Apr 28, 2023 2:39 pmWhen you have time, please try increasing the value of normal_spi_clock_cycle.
All the same, I have made several value increases, up to 20, same result. Slow access from FDISK or formatting, and the results were not applied. Reading does seem to do it, because FDISK recognises the previously created partitions... but any attempt to change, it's not actually doing it. Anything else you want me to try, let me know.
Fixed a bug in which the read/write command did not return an error status when an error occurred.
Not sure if this will solve the current problem, but I will upload it here.
kitune-san wrote: ↑Sat Apr 29, 2023 4:14 pmFixed a bug in which the read/write command did not return an error status when an error occurred.
Not sure if this will solve the current problem, but I will upload it here.
The operation is similar, however... I have found a 2Gb card that seems to work well, both in this one and in the previous ones. However, when it comes to using FDISK to create partitions, performance is erratic. The slowness when creating them is noticeable, and sometimes it even hangs and I have to restart the computer, if warm restart, the SD stops working... it's as if the SD had been left in an unstable state.
The good news is that with this card, at least I managed to get the ZXUno version to recognise it and boot 
Have you tried using FDISK and managing the SD partitions?
I use FDISK, which is certainly slow, but I don't feel it is unstable in my environment.
Anyway, I will buy some SD cards and try them out.
I found some bugs in KFMMC. I will fix it.
I've gone ahead, grabbed the latest sources you've posted and now it's working perfectly with several cards I've already tested
I'll keep testing, but here is a benchmark at 4.77Mhz and full CPU speed:
That's good 
Updated MMC drive options.
Thanks to kitune-san's latest improvements to SD access, which is now via SPI, it is no longer necessary to turn the ZXUno off and on after updating this core and there is no longer any problem with SD card corruption, it works perfectly!
It also takes up much less space, so it has been possible to reincorporate the Adlib sound in the whole LX9 range models, including the ZXUno
The repository of the full range of Xilinx ISE-based ZXUno clones can be found here:
https://github.com/spark2k06/PCXT_Xilinx_Spartan_6
Soon I will include the UART module to be able to use the mouse, and as before, the timing constrains improvement is pending (which I have no idea about by the way), meanwhile, don't expect cycle precision in the 4.77Mhz that is set by default.
For now, access to a turbo mode is in experimental mode and you have to activate it from the MS-Dos debug, run it and launch the command o 8888 1
As always, thanks @kitune-san for your outstanding work with the SD access via SPI, and for everything else. Without your help, and that of @MicrocoreLabs I would never have made it this far and to so many FPGAs
After testing it for a while and finding that it works very well, and although it is totally dispensable for MiSTer, since we have VHD mounting, I have decided that this functionality cannot be missing in the main branch and available to all users, although it may probably arouse more interest among advanced users or developers:
As I said, the main beneficiary of this development is the Xilinx Spartan 6 family... it's a pity that the timing is not as polished as in MiSTer, where it's already close to perfection, but little by little I'm sure it will be improved, making it much more stable than it is now.