The online community for MiSTer FPGA enthusiasts
https://misterfpga.org/
When I used ZXUno files in MiSTer, the MMC module behaved strangely.
It appears that there are some incorrect conversions of reg and wire.
This will be corrected manually, so it will take some time.
Also, there was one undeclared signal that I will fix as well.
kitune-san wrote: ↑Fri Mar 03, 2023 1:50 pmWhen I used ZXUno files in MiSTer, the MMC module behaved strangely.
It appears that there are some incorrect conversions of reg and wire.
This will be corrected manually, so it will take some time.
Also, there was one undeclared signal that I will fix as well.2023-03-03 224904.png
Good idea to use the verilog version in MiSTer for debugging!
I fixed the wrong declaration of signals that occurred during conversion.
Please give it a try when you have time.
kitune-san wrote: ↑Fri Mar 03, 2023 2:52 pmI fixed the wrong declaration of signals that occurred during conversion.
Please give it a try when you have time.
None of these changes is possible, all of them result in errors like these in the synthesis:
oh. I've been using SystemVerilog so much that I've forgotten the Verirlog specs... 
The previous commit is revert.
kitune-san wrote: ↑Sat Mar 04, 2023 5:54 amoh. I've been using SystemVerilog so much that I've forgotten the Verirlog specs...
The previous commit is revert.
Don't worry. It would seem strange to me, because I have already converted all your KFPCXT project with the tool that I comment (sv2v) and already worked so far everything well, I have only made some small adjustments in what is the each module declaration with respect to the output provided by the tool, but all the regs and wires assigns them correctly 
I installed ISE, but I don't know how to do timing analysis...
kitune-san wrote: ↑Sat Mar 04, 2023 1:36 pmI installed ISE, but I don't know how to do timing analysis...
Timing constrains have always been one of my pending tasks, I can't help you with this, but maybe this link will help you:
https://support.xilinx.com/s/article/38 ... uage=en_US
By the way, later I will make an analysis of MMC controller, to see at what point the command state is left.
I am not so sure about ISE as this is the first time I am using it.
...Apparently, since the input clock was not constrained, the DCM clock using it was also not constrained.
Removed comment on input clock constraints.
I have also added TIG constraints between cross-clock domains.
https://github.com/kitune-san/PCXT_ZXUn ... uggestion2
kitune-san wrote: ↑Sat Mar 04, 2023 2:32 pmI am not so sure about ISE as this is the first time I am using it.
...Apparently, since the input clock was not constrained, the DCM clock using it was also not constrained.Removed comment on input clock constraints.
I have also added TIG constraints between cross-clock domains.
https://github.com/kitune-san/PCXT_ZXUn ... uggestion2
This worsens the times, your changes make that when synthesizing it does not generate a timing score = 0, without the changes you can see that it does:
However, there is good news... if you disconnect and reconnect the SD you can detect it, it's a bit random. 
I can't be 100% sure right now, but I think the problem when it is not recognized, is that it doesn't return a 1AAh in response and goes into a loop.
Another problem is that the write doesn't work, but it may be because I don't have it updated to the latest changes you made in MiSTer, which I will do soon.
I think I know what's going on. Everything indicates that, when the SD card has been previously used in SPI mode, the PCXT core doesn't recognize it... it's like it's in that mode. That's why it seems that when I unplug it and plug it in again, it works fine.
And the thing is, before switching to the PCXT core, I usually use it to write the core to the UnoXT SPI flash, the core that I have just synthesized... and then I reset it instead of turning it off and on... because if I had done it like that, there is no need to drop and insert the SD card. In fact, once writed in the SPI flash, when I connect the UnoXT to power and switch to the PCXT core, it always works.
It would be nice to see how to reset the SD or something, before use... so that this scenario is controlled.
Anyway, once the problem is understood, in reality the problem is not so serious, nor does it have to do with timing or anything like that.
kitune-san wrote: ↑Sat Mar 04, 2023 2:32 pmI am not so sure about ISE as this is the first time I am using it.
...Apparently, since the input clock was not constrained, the DCM clock using it was also not constrained.Removed comment on input clock constraints.
I have also added TIG constraints between cross-clock domains.
https://github.com/kitune-san/PCXT_ZXUn ... uggestion2
Question - Constraints affect to routing or only validation?
I'm not familiar with ISE, so I could be wrong...
it probably affects both.
The reason the result is "All constrains met" before my constraints are added is because it is unconstrained.
Since they are unconstrained, they can be freely placed and are not analyzed.
kitune-san wrote: ↑Mon Mar 06, 2023 2:17 amI'm not familiar with ISE, so I could be wrong...
it probably affects both.
The reason the result is "All constrains met" before my constraints are added is because it is unconstrained.
Since they are unconstrained, they can be freely placed and are not analyzed.
Good to know. The fact is that with and without the change, everything seems to work apparently the same... but if such a change without further revision is really convenient, I won't hesitate to adopt it, thanks
On the other hand, I have noticed that the latest modifications to enable writing cause it not to boot from the drive, even though it still recognizes it. This also happens in the secondary SD version in MiSTer, at some of the available CPU speeds... I have slowed down mmc_clk with normal_spi_clock_cycle, but not even so:
https://github.com/kitune-san/PCXT_MiST ... 6b7a066747
and
https://github.com/kitune-san/PCXT_MiST ... 8a1eda1117
For the moment I will continue preparing the ZXUno port, I still have some pending issues. If there is any improvement regarding the writing, please let me know. For my part, I have changed the branch I am currently working on for the ZXUno port:
Lately I have not been improving my MMC module.
I will restart that soon.
kitune-san wrote: ↑Mon Mar 06, 2023 6:51 amLately I have not been improving my MMC module.
I will restart that soon.
For my part, I have redesigned the core for the ZXUno and derivatives, both clones and higher-resource Xilinx FPGA versions:
https://github.com/spark2k06/PCXT_ZXUno
ZXUno 2Mb model
Now there are a few models, but soon I will expand the repository with others, such as ZXDos, ZXTres, NGo, etc... I just need to add some TOP, ISE and UCF files per model (also its splash screen), as well as the clock ipcores corresponding to their FPGA versions.
The resources of the original ZXUno FPGA (Xilinx XC6SLX9) are starting to become too scarce for this core, the SD implementation takes up enough space and I had to disable Adlib and Tandy Sound. Also, the 512Kb versions will be limited to the PCXT, not being possible to access the graphics features of Tandy:
Older siblings will have a better chance in this case, you know, evolve or die
At the moment, although it works quite well in general, the core has serious timing problems, the CPU speed is not similar to a PCXT as we have in MiSTer, I still have problems with the SD module, it's not stable enough sometimes, and it's better to use SD cards that we don't like too much, just in case it might happen.
When all this is sorted out, especially the implementation of SD, I'm planning to develop a BIOS to make up for the lack of resources, especially those of the original ZXUno to have a demistify OSD. The idea is to use the SD as a means of storing ROM of BIOSes and the configuration of various aspects, such as CPU speed, the BIOS to load (Tandy/PCXT), video modes (RGB/VGA), etc ... all through typical BIOS menus, but this development will be little by little, when we have all the above I mentioned ... it will be a great challenge of development on my part 
Soon I will also finish adding the missing modules, such as the UART and the mouse, which will be available for the models that have enough resources, of course... on ZXUno, as I say, it is already very tight on space.
By the way, I am using the latest version of the KFMMC module, except for the following line related to the SET_MULTIPLE command, because it hangs before starting the operating system:
The following changes can be made to stop using the open drain output (change to push-pull output) to speed up the transfer rate.
It is working fine in my development environment.(32GB SD + MiSTer)
However, releases should be made with caution, as incorrect implementation can damage hardware.
https://github.com/kitune-san/PCXT_MiST ... 74b11b125a
UPDATE:
Changed the MMC to operate in open-drain mode during reset.
This avoids high current during clock transmission when resetting a card in an indeterminate state.
spark2k06 wrote: ↑Mon Mar 27, 2023 5:34 amThe resources of the original ZXUno FPGA (Xilinx XC6SLX9) are starting to become too scarce for this core, the SD implementation takes up enough space and I had to disable Adlib and Tandy Sound. Also, the 512Kb versions will be limited to the PCXT, not being possible to access the graphics features of Tandy:
It might be better to replace the KFMMC state machine with a micro sequencer.
kitune-san wrote: ↑Mon Mar 27, 2023 1:57 pmThe following changes can be made to stop using the open drain output (change to push-pull output) to speed up the transfer rate.
It is working fine in my development environment.(32GB SD + MiSTer)
However, releases should be made with caution, as incorrect implementation can damage hardware.
Thank you. With this modification I was able to lower normal_spi_clock_cycle to 4... if I set 3 or 2, it becomes extremely slow to read in the current ZXUno implementation, but with 4, a higher speed can be seen.
kitune-san wrote:UPDATE:
Changed the MMC to operate in open-drain mode during reset.
This avoids high current during clock transmission when resetting a card in an indeterminate state.
I have not yet been able to test this modification, I will do it tomorrow and let you know.
I also want to do a thorough test on writing, I have the feeling that sometimes writing to a certain file, has ended up corrupting others, curiously... but I'll check it with a review of the full content of the SD when I write a file, if I find something I'll let you know.
kitune-san wrote: ↑Mon Mar 27, 2023 1:57 pmUPDATE:
Changed the MMC to operate in open-drain mode during reset.
This avoids high current during clock transmission when resetting a card in an indeterminate state.
I confirm that this change also works well, I notice that it works better... however, I still have to do some writing tests, and check that the SD is not corrupted with them.
New core update for ZXUno and based on this one:
https://github.com/spark2k06/PCXT_ZXUno/commits/main
I have added new models based on Xilinx XC6SLX:
https://github.com/spark2k06/PCXT_ZXUno
kitune-san wrote: ↑Mon Mar 27, 2023 2:00 pmIt might be better to replace the KFMMC state machine with a micro sequencer.
I've already seen that you've started a new microsequencer project in your GitHub repository
If it is finally applied to SD handling, the more modest, XC6SLX9-based models will be greatly favoured... and possibly it will be possible to add Adlib sound again, among others.
spark2k06 wrote: ↑Sun Apr 02, 2023 10:21 amkitune-san wrote: ↑Mon Mar 27, 2023 2:00 pmIt might be better to replace the KFMMC state machine with a micro sequencer.
I've already seen that you've started a new microsequencer project in your GitHub repository
If it is finally applied to SD handling, the more modest, XC6SLX9-based models will be greatly favoured... and possibly it will be possible to add Adlib sound again, among others.
Having created a simple assembler, I am creating a program to access the SD card using SPI.
However, since this is just replacing a complex combinational circuit with a RAM or ROM block, I am not sure how much of a resource reduction I can expect.
Don’t get your hopes up. I’m not that good.
kitune-san wrote: ↑Sat Apr 08, 2023 4:54 pmHaving created a simple assembler, I am creating a program to access the SD card using SPI.
However, since this is just replacing a complex combinational circuit with a RAM or ROM block, I am not sure how much of a resource reduction I can expect.
Don’t get your hopes up. I’m not that good.
No matter, any improvement is good, and for me it is, in the sense that SPI is used, because the rest of the ZXUno cores use SPI, and you can't switch directly to native mode, it requires disconnecting and connecting the ZXUno before accessing the PCXT core. Also, it is possible to improve the write accesses, which right now are not very reliable, at least in the ZXUno version and derivatives (Spartan 6)... possibly due to timing issues, it needs a thorough revision. By the way, I've renamed it to represent the Spartan 6 family, and I've automated the generation of all supported models, currently 12 no less!
PCXT core of the MiSTer FPGA was recently updated.But However, the screen shakes slightly overall in Hercules mode. There was no such symptom before. It runs normally in CGA mode. Can you please check?
When the Display option is set to full color, there is no shaking, but this symptom appears when it is set to mono color (green, amber, white).
I have already seen this same question in two threads, this thread does not seem appropriate for this question, I refer you to the other one:
spark2k06 wrote: ↑Sat Apr 08, 2023 5:00 pmkitune-san wrote: ↑Sat Apr 08, 2023 4:54 pmHaving created a simple assembler, I am creating a program to access the SD card using SPI.
However, since this is just replacing a complex combinational circuit with a RAM or ROM block, I am not sure how much of a resource reduction I can expect.
Don’t get your hopes up. I’m not that good.No matter, any improvement is good, and for me it is, in the sense that SPI is used, because the rest of the ZXUno cores use SPI, and you can't switch directly to native mode, it requires disconnecting and connecting the ZXUno before accessing the PCXT core. Also, it is possible to improve the write accesses, which right now are not very reliable, at least in the ZXUno version and derivatives (Spartan 6)... possibly due to timing issues, it needs a thorough revision. By the way, I've renamed it to represent the Spartan 6 family, and I've automated the generation of all supported models, currently 12 no less!
Hi again!
I created an MMC drive using SPI, although it took me a while.
https://github.com/kitune-san/PCXT_MiST ... re-spi-mmc
kitune-san wrote: ↑Wed Apr 26, 2023 4:48 pmHi again!
I created an MMC drive using SPI, although it took me a while.
https://github.com/kitune-san/PCXT_MiST ... re-spi-mmc
Great job, I have been following your updates.
This weekend without fail I will test it for ZXUno and its derivatives based on Xilinx ISE, I will let you know.
Thank you very much for your work.
spark2k06 wrote: ↑Wed Apr 26, 2023 5:24 pmkitune-san wrote: ↑Wed Apr 26, 2023 4:48 pmHi again!
I created an MMC drive using SPI, although it took me a while.
https://github.com/kitune-san/PCXT_MiST ... re-spi-mmcGreat job, I have been following your updates.
This weekend without fail I will test it for ZXUno and its derivatives based on Xilinx ISE, I will let you know.
Thank you very much for your work.
I was able to do a quick test by synthesising this version for MiSTer, however, although it recognises the drive I get the following failures during the boot of the operating system, or during direct read with the operating system already booted by another IDE drive:
I have checked that the SD card boots without problems to another version of MMC based on native access to it. Is it working well for you? Did I do something wrong?
It 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?