MiSTer FPGA Forum

spark2k06 wrote: ↑Sat Jul 16, 2022 2:16 pm I insist, it seems strange to me that it is a problem of the UART speed, but is it possible that you are using the experimental 7Mhz version? That might make more sense.

In any case, if it's the UART speed, it's not necessary to change the core, in the script set it to 115.2K and it will work anyway, but at the previous speed.

suww37 wrote: ↑Sat Jul 16, 2022 3:26 pm

spark2k06 wrote: ↑Sat Jul 16, 2022 2:16 pm I insist, it seems strange to me that it is a problem of the UART speed, but is it possible that you are using the experimental 7Mhz version? That might make more sense.

In any case, if it's the UART speed, it's not necessary to change the core, in the script set it to 115.2K and it will work anyway, but at the previous speed.

I solved it. It was a memory problem. It was cleaned up by using a lo-tech emm driver to use EMS memory. tetris and double dragon are all working fine. I'm sorry and thank you for taking your time.

• Integrate module into core + OSD menu tweaks
• Add video monochrome converter module

wark91 wrote: ↑Sat Jul 16, 2022 7:13 pm Thank you !
One thing I see on the OSD changes, when you modified the display mode, the DSS/Covox also changed.

flynnsbit wrote: ↑Sat Jul 16, 2022 3:48 pm

suww37 wrote: ↑Sat Jul 16, 2022 3:26 pm

spark2k06 wrote: ↑Sat Jul 16, 2022 2:16 pm I insist, it seems strange to me that it is a problem of the UART speed, but is it possible that you are using the experimental 7Mhz version? That might make more sense.

In any case, if it's the UART speed, it's not necessary to change the core, in the script set it to 115.2K and it will work anyway, but at the previous speed.

I solved it. It was a memory problem. It was cleaned up by using a lo-tech emm driver to use EMS memory. tetris and double dragon are all working fine. I'm sorry and thank you for taking your time.

What was the before and after here to fix it? You were not using the lTEMM driver before (had the issue) and you added it (and it corrected the issue in both)?

I always try and make a metal note on things like this so I wanted to make sure I understood what it was.

• Rewiring with sn76489
• Temporary removal of the signal from tandy_snd_rdy
• Fix bug of the access to the CS signal in Tandy sound module
• In tandy mode, the keyboard reset signal is not used
• Added new IORQ signal
• Restructuring of the OSD menu
• Added DSS/Covox support
• UART port speed increase to 921.6Kbps
• CGA Mode Detection 320x200x4
• Add video monochrome converter module
• Integrate module into core + OSD menu tweaks
• Fix COVOX OSD option

kitune-san wrote: ↑Sun Jul 17, 2022 3:00 pm 14.318MHz (BIU_CLK_COUNTER_ZERO=1'b1) Test.

spark2k06 wrote: ↑Sun Jul 17, 2022 3:29 pm

kitune-san wrote: ↑Sun Jul 17, 2022 3:00 pm 14.318MHz (BIU_CLK_COUNTER_ZERO=1'b1) Test.

I haven't had a chance to try it yet but it sounds great! @microcorelabs, would it be too complicated to add the instructions for an 186? We could also have with it the equivalent of a NEC v20 up to 14Mhz.

suww37 wrote: ↑Sun Jul 17, 2022 3:38 pm Death track game, but I don't know why. I wonder if it's possible to adjust it with 10Mhz.

spark2k06 wrote: ↑Sun Jul 17, 2022 3:43 pm Can you post a screenshot of CPU benchmark with checkit3?

Newsdee wrote: ↑Sun Jul 17, 2022 3:47 pm

suww37 wrote: ↑Sun Jul 17, 2022 3:38 pm Death track game, but I don't know why. I wonder if it's possible to adjust it with 10Mhz.

Death Track feels too slow for me at 14mhz but I guess the original was slower (from seeing a youtube video)

spark2k06 wrote: ↑Sun Jul 17, 2022 3:43 pm Can you post a screenshot of CPU benchmark with checkit3?

spark2k06 wrote: ↑Sun Jul 17, 2022 3:49 pm If something seems slow at 14Mhz, please do the same test with PCem, same processor and also at 14Mhz, lest your memory plays a trick on you

suww37 wrote: ↑Sun Jul 17, 2022 3:38 pm

spark2k06 wrote: ↑Sun Jul 17, 2022 3:29 pm

kitune-san wrote: ↑Sun Jul 17, 2022 3:00 pm 14.318MHz (BIU_CLK_COUNTER_ZERO=1'b1) Test.

I haven't had a chance to try it yet but it sounds great! @microcorelabs, would it be too complicated to add the instructions for an 186? We could also have with it the equivalent of a NEC v20 up to 14Mhz.

I'm so happy. Thank you for kitune-san . Finally, I can see the normal movement of the prince of persia. But I don't think the speed doesn't apply properly in the Death track game, but I don't know why. I wonder if it's possible to adjust it with 10Mhz.

suww37 wrote: ↑Sun Jul 17, 2022 4:16 pm pcxt cor 14Mhz Test

prince of persia nice play
outrun. nice play
wings of fury nice play
death track. same slow
bubble bobble abnormal
north & south abnormal

kitune-san wrote: ↑Sun Jul 17, 2022 5:21 pm

suww37 wrote: ↑Sun Jul 17, 2022 3:38 pm

spark2k06 wrote: ↑Sun Jul 17, 2022 3:29 pm

I haven't had a chance to try it yet but it sounds great! @microcorelabs, would it be too complicated to add the instructions for an 186? We could also have with it the equivalent of a NEC v20 up to 14Mhz.

I'm so happy. Thank you for kitune-san . Finally, I can see the normal movement of the prince of persia. But I don't think the speed doesn't apply properly in the Death track game, but I don't know why. I wonder if it's possible to adjust it with 10Mhz.

Changed to 10mhz.

flynnsbit wrote: ↑Sun Jul 17, 2022 10:48 pm I wanted to report back that I finally worked through the serdrive disk "Bad Command Checksum" that I have been plagued with from the start of this project. I have been using 86Box/PCem/Windows to create the raw disk images (IMG/VHD). Once created to the size I wanted I would pull over to either AO486 or 86box, fdisk, and format the disk before mounting using serdrive.

On occasion I had to get the geometry for CHS from 86Box so I could specify that in the serdrive mount command. Doing it this way I would run into disk errors, bad command checksum, and serdrive command timeouts when writing to the disk. This would show up randomly with game execution, usually when the higher cluser LBAs were accessed, swapping between EMM and disk, and running OS level commands that were disk heavy like ATTRIB.

The easiest way to set it off was to run Fast Trak 5.0f and optimize the disk. You can see the issues when looking at the screenshot below:Bad Command Checksum.png

You could leave serdrive running and reset the core (back out to Mister main menu) and load it again and it would recover. Resetting within the core would just bring back more Bad command checksum errors.

Resolution:
If you create a IMG/VHD file container directly from serdrive command using "./serdrive -n 500MB 500.img" as an example, then fdisk, format, install the os to that container from something like AO486, then you will not get any disk errors or bad command checksums from serdrive. Also, this will set the CHS geometry to the default expected by the command so you wont have to specify it in the pcxt_uart_hdd script. I tried creating a 512MB image using serdrive and that one had issues mounting so I pulled it down to exactly 500MB with no issues. I had issues with 10MB, 20MB, 200MB containers if created outside of this process.

I copied DOS, all of the games, MyMenu, all memory configs, and ran through a full disk defrag/optimization for 5 hours without a single disk error.

I hope this info helps stabilize some things for people. The primary goal should still be to get off of serdrive and find a developer that can implement either the CPLD or the FPGA logic of the compactflash/sd card components of the XT-IDE card.

500MB IMG/VHD has been stable at 460.8K by following this process. 4+ hours of success:
20220717_174211-jukost.png

suww37 wrote: ↑Mon Jul 18, 2022 1:44 am

flynnsbit wrote: ↑Sun Jul 17, 2022 10:48 pm I wanted to report back that I finally worked through the serdrive disk "Bad Command Checksum" that I have been plagued with from the start of this project. I have been using 86Box/PCem/Windows to create the raw disk images (IMG/VHD). Once created to the size I wanted I would pull over to either AO486 or 86box, fdisk, and format the disk before mounting using serdrive.

On occasion I had to get the geometry for CHS from 86Box so I could specify that in the serdrive mount command. Doing it this way I would run into disk errors, bad command checksum, and serdrive command timeouts when writing to the disk. This would show up randomly with game execution, usually when the higher cluser LBAs were accessed, swapping between EMM and disk, and running OS level commands that were disk heavy like ATTRIB.

The easiest way to set it off was to run Fast Trak 5.0f and optimize the disk. You can see the issues when looking at the screenshot below:Bad Command Checksum.png

You could leave serdrive running and reset the core (back out to Mister main menu) and load it again and it would recover. Resetting within the core would just bring back more Bad command checksum errors.

Resolution:
If you create a IMG/VHD file container directly from serdrive command using "./serdrive -n 500MB 500.img" as an example, then fdisk, format, install the os to that container from something like AO486, then you will not get any disk errors or bad command checksums from serdrive. Also, this will set the CHS geometry to the default expected by the command so you wont have to specify it in the pcxt_uart_hdd script. I tried creating a 512MB image using serdrive and that one had issues mounting so I pulled it down to exactly 500MB with no issues. I had issues with 10MB, 20MB, 200MB containers if created outside of this process.

I copied DOS, all of the games, MyMenu, all memory configs, and ran through a full disk defrag/optimization for 5 hours without a single disk error.

I hope this info helps stabilize some things for people. The primary goal should still be to get off of serdrive and find a developer that can implement either the CPLD or the FPGA logic of the compactflash/sd card components of the XT-IDE card.

500MB IMG/VHD has been stable at 460.8K by following this process. 4+ hours of success:
20220717_174211-jukost.png

I know that using a 500MB HDD on the XT takes too long to load. If I create a PCXT HDD image in your own way, is it possible to use it normally without slowing down? If you are okay, please upload an empty HDD image file (DOS installed) 500MB.

flynnsbit wrote: ↑Mon Jul 18, 2022 2:08 am

suww37 wrote: ↑Mon Jul 18, 2022 1:44 am

flynnsbit wrote: ↑Sun Jul 17, 2022 10:48 pm I wanted to report back that I finally worked through the serdrive disk "Bad Command Checksum" that I have been plagued with from the start of this project. I have been using 86Box/PCem/Windows to create the raw disk images (IMG/VHD). Once created to the size I wanted I would pull over to either AO486 or 86box, fdisk, and format the disk before mounting using serdrive.

On occasion I had to get the geometry for CHS from 86Box so I could specify that in the serdrive mount command. Doing it this way I would run into disk errors, bad command checksum, and serdrive command timeouts when writing to the disk. This would show up randomly with game execution, usually when the higher cluser LBAs were accessed, swapping between EMM and disk, and running OS level commands that were disk heavy like ATTRIB.

The easiest way to set it off was to run Fast Trak 5.0f and optimize the disk. You can see the issues when looking at the screenshot below:Bad Command Checksum.png

You could leave serdrive running and reset the core (back out to Mister main menu) and load it again and it would recover. Resetting within the core would just bring back more Bad command checksum errors.

Resolution:
If you create a IMG/VHD file container directly from serdrive command using "./serdrive -n 500MB 500.img" as an example, then fdisk, format, install the os to that container from something like AO486, then you will not get any disk errors or bad command checksums from serdrive. Also, this will set the CHS geometry to the default expected by the command so you wont have to specify it in the pcxt_uart_hdd script. I tried creating a 512MB image using serdrive and that one had issues mounting so I pulled it down to exactly 500MB with no issues. I had issues with 10MB, 20MB, 200MB containers if created outside of this process.

I copied DOS, all of the games, MyMenu, all memory configs, and ran through a full disk defrag/optimization for 5 hours without a single disk error.

I hope this info helps stabilize some things for people. The primary goal should still be to get off of serdrive and find a developer that can implement either the CPLD or the FPGA logic of the compactflash/sd card components of the XT-IDE card.

500MB IMG/VHD has been stable at 460.8K by following this process. 4+ hours of success:
20220717_174211-jukost.png

I know that using a 500MB HDD on the XT takes too long to load. If I create a PCXT HDD image in your own way, is it possible to use it normally without slowing down? If you are okay, please upload an empty HDD image file (DOS installed) 500MB.

There are multiple things you can do to resolve a larger disk being slow on an XT class machine. I will include all the optimizations when I finish the disk image for everyone. Don't ask when this will be ready...

1. Load freesp on boot for C so that the free disk calculation is quick.
2. use 4dos or ndos.com as your shell and let it swap into high memory
3. use a disk cache like Norton Cache 2 (ncache2.EXE) and carve out EMS space for it
4. use NANSI
5. Carve out a RAMDRIVE.SYS drive using /a for expanded memory and then assign temp to be there (also maybe even copy 4dos or ndos there and set the COMSPEC= variable to load from D: instead of the C: drive.)

these all help tremendously. All of this will make a large drive feel normal on a slow machine.

flynnsbit wrote: ↑Sun Jul 17, 2022 10:48 pm Resolution:
If you create a IMG/VHD file container directly from serdrive command using "./serdrive -n 500MB 500.img" as an example, then fdisk, format, install

get off of serdrive and find a developer that can implement either the CPLD or the FPGA logic of the compactflash/sd card components of the XT-IDE card

• Restructuring the OSD menu