MiSTer PCXT

[suww37]

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.

[flynnsbit]

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.

[spark2k06]

New prebeta 1.4 by @Newsdee

https://github.com/spark2k06/PCXT_MiSTe ... c42883a65d
https://github.com/spark2k06/PCXT_MiSTe ... 75eebe85dc

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

[wark91]

Thank you !
One thing I see on the OSD changes, when you modified the display mode, the DSS/Covox also changed.

[spark2k06]

Thank you !
One thing I see on the OSD changes, when you modified the display mode, the DSS/Covox also changed.

Yes, I see what the problem is, I will fix it tomorrow and release beta 1.4 with all these changes. The experimental 7 MHz version will remain in a pre-beta state until stability is confirmed, at which point it will be merged with the main branch and the turbo option in the OSD menu will be reactivated.

[suww37]

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.

I use a utility called MDIR like DOSSHELL. Before using the ems driver, I had to reboot when I quit the game after running the game. After using the ems driver, those symptoms decreased a lot (there are still freezing in some games). Before using ems, the double dragon was freezing when executed on a regular dos rather than mdir at dos 6.22, and executed with mdir (dosshell). TETRIS was even though the graphics were broken in dos or in mdir before using ems, but it was broken differently depending on the game level wallpaper. This symptom disappeared after using ems. I think there is an error when using only the default dos memory (640kb) in pcxt core. I don't know why.

[spark2k06]

beta 1.4

https://github.com/spark2k06/PCXT_MiSTe ... 8cb6664309

• 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

New branches prebeta 1.5 and prebeta 1.5 7Mhz are started, the 7Mhz branch will not be merged with the main branch until it is no longer experimental:

https://github.com/spark2k06/PCXT_MiSTe ... rebeta-1.5
https://github.com/spark2k06/PCXT_MiSTe ... a-1.5-7mhz

Attached is the latest version of 7Mhz with the change of "Fix COVOX OSD option".

On the other hand, I wanted to comment on how developers who want to contribute to the project should proceed. Don't use the main branch to make pull requests, instead, work on the prebeta branch and make pull requests there... if you can also make pull requests on the 7Mhz prebeta branch as long as it is experimental, you will save me the work of mixing between versions, although normally there are no conflicts between these two.

[kitune-san]

14.318MHz (BIU_CLK_COUNTER_ZERO=1'b1) Test.

[kitune-san]

Deleted

[spark2k06]

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]

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.

[spark2k06]

Can you post a screenshot of CPU benchmark with checkit3?

[Newsdee]

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]

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

[flynnsbit]

Can you post a screenshot of CPU benchmark with checkit3?

20220717_105008-ide_xtl.png (258.19 KiB) Viewed 5424 times

[suww37]

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)

The north & south game breaks the graphics and takes a freezing while running.

[Newsdee]

Can you post a screenshot of CPU benchmark with checkit3?

Great results!
Megaman plays really nicely

checkit3.png (18.47 KiB) Viewed 5401 times

[wark91]

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

PCEM proposed those speed. 14Mhz is not on the list.

Screenshot from 2022-07-17 18-08-46.png (56.62 KiB) Viewed 5373 times

[suww37]

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]

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.

Changed to 10mhz.

[spark2k06]

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

A shared spreadsheet will have to be created to keep track of which games and applications work or don't work, and which core versions are used.

[NML32]

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.

With the 10Miz core, I'm getting a bad or missing Command Interpreter error.

[spark2k06]

I have created a shared spreadsheet with editing permissions, I hope I don't need to restrict it any more

Compatibility of software in MiSTer PCXT

https://docs.google.com/spreadsheets/d/ ... sp=sharing

[flynnsbit]

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 (2.44 MiB) Viewed 5125 times

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 (658.61 KiB) Viewed 5125 times

[suww37]

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]

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 on boot in your autoexec and set the COMSPEC= variable to load from D: instead of the C: drive.)
6. for the love of all things, DON'T use MS EDIT. Use something else and rename edit.com (use T.com or Swift Programmers Editor V4.4 written by Alexander Safonenkov "Swift Editor")

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

[suww37]

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.

Your work is really cool. I look forward to your great achievements. Thank you

[Newsdee]

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

Thanks! I always used the default geometry, but it still gave me issues with smaller disks and I had to restart the core.

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

Yes - that's really a big blocker to make the core accessible to others, not to mention the speed benefits. Unfortunately that's way beyond what I am able to achieve in HDL (which isn't much to begin with)

[spark2k06]

prebeta 1.5 updated:

• Restructuring the OSD menu

Bits are reserved for a future CPU speed selector.

I also attach the experimental turbo version, with CPU speed selection from OSD. For the moment we keep it separate in an experimental branch, because with the latest SDRAM changes it loses cycle accuracy in normal mode at 4.77MHz. Also, if 4.77Mhz is selected in the experimental version in turbo mode, serdrive does not work at 460.8K, it must be lowered to 230.4K.

https://github.com/spark2k06/PCXT_MiSTe ... rebeta-1.5
https://github.com/spark2k06/PCXT_MiSTe ... -1.5-turbo

@newsdee, please check the monochrome colour change in the MDA output, since the last changes it looks too dark.

[suww37]

Turbo mode is supported on the pcxt core and tandy mode is also supported. Now all that's left is the built-in pcxt IDE module, not the IDE com port script. I believe this will happen soon as well. Another thing I desperately want is Hercules graphic card mode, not the MDA. I haven't heard that the Hercules FPGA has been implemented yet. I'm not a developer, so I don't have much knowledge of this field. I wonder if it's a difficult process to put Hercules in the pcxt core, so if you try a little bit, it can be implemented like Tandy. If it's difficult, can you tell how long it takes?