MiSTer PCXT

[spark2k06]

Hi, I can see you guys are working on a higher level, but, I’m trying to get the core working but I’m struggling with the boot.rom. I’m trying to follow this thread but it’s a fair few IQ points beyond me…. It seems like once upon a time the boot.rom I need to get this running was in the SW folder on github but it doesn’t appear to be there now. Also, it seems you can run a “python script” which i’ve tried but I knew I’d fail to get it working correctly…. my level is more ‘plug console in and turn on’.

Is there any other way of obtaining the boot.rom? For instance, could someone message me with it all? That would be very kind!

Thanks for any help.

Cheers,

I think all your questions are answered in the README of the project:

https://github.com/MiSTer-devel/PCXT_MiSTer

[darkavengerbr]

the question is ( sorry if already answered , but couldnt find) how can I easily tranfer files from my windows pc to an hd img file?

It's not that straightforward, though I might be missing something. You can use ao486 core on MiSTer plus Dos Navigator or other file manager, and copy from your "normal" vhds (those made for ao486 and mountable in Windows).

Or use PCem emulator on your PC. The PCXT images will work in that. Problem is then you have to make iso CD images with your files from Windows directories, because you can't mount them directly in that emu. Still, that's what I did when moving large amount of files:
-create a Pentium instance in PCem
-use Win98 SE hdd install as C: (there is one ready made on archive.org)
-use the PCXT hdd image as secondary
-mount a premade iso with my files as CDROM
-copy from iso to PCXT hdd using Total Commander

If there's an easier method I'm all ears, as it is a bit of faffing about.

Just mount in your normal OS the image.

In windows, you'll use Imdisk software.

Linux and Mac, mount or diskutil

Thanks a lot! Imdisk did the trick!

[thera34]

Hi, I can see you guys are working on a higher level, but, I’m trying to get the core working but I’m struggling with the boot.rom. I’m trying to follow this thread but it’s a fair few IQ points beyond me…. It seems like once upon a time the boot.rom I need to get this running was in the SW folder on github but it doesn’t appear to be there now. Also, it seems you can run a “python script” which i’ve tried but I knew I’d fail to get it working correctly…. my level is more ‘plug console in and turn on’.

Is there any other way of obtaining the boot.rom? For instance, could someone message me with it all? That would be very kind!

Thanks for any help.

Cheers,

Simpler way:
Copy the ROM files from Github SW\ROMs folder (ide_xtl.rom etc) and also the scripts there but careful what you download (the actual script is to be found under RAW button, else you will d/l a useless html stuff) to the /media/fat/games/PCXT folder

Even better method below using only the Linux side:
Access the Linux side of MiSTer by either SSH (use Putty or whatever SSH terminal) or by F9 on main screen
Make your way to /media/fat/games/PCXT ("cd /media/fat/games/PCXT")
To get the ROMs mentioned in README issue the following commands:

Code: Select all

wget https://github.com/MiSTer-devel/PCXT_MiSTer/blob/main/SW/ROMs/ide_xtl.rom
wget https://github.com/MiSTer-devel/PCXT_MiSTer/blob/main/SW/ROMs/pcxt_micro8088.rom
wget https://github.com/MiSTer-devel/PCXT_MiSTer/blob/main/SW/ROMs/pcxt_pcxt31.rom

Next get the scripts to make the ROMs you'll be using :

Code: Select all

wget https://raw.githubusercontent.com/MiSTer-devel/PCXT_MiSTer/main/SW/ROMs/make_rom_with_ibm5160.py
wget https://raw.githubusercontent.com/MiSTer-devel/PCXT_MiSTer/main/SW/ROMs/make_rom_with_jukost.py
wget https://github.com/MiSTer-devel/PCXT_MiSTer/blob/main/SW/ROMs/make_rom_with_tandy.py

After that, you simply make whatever ROM file you wish to test :

Code: Select all

/media/fat/games/PCXT# python make_rom_with_ibm5160.py 
/media/fat/games/PCXT# python make_rom_with_tandy.py 
/media/fat/games/PCXT# python make_rom_with_jukost.py 

Hope it helps

[Hodor]

Hi, I can see you guys are working on a higher level, but, I’m trying to get the core working but I’m struggling with the boot.rom. I’m trying to follow this thread but it’s a fair few IQ points beyond me…. It seems like once upon a time the boot.rom I need to get this running was in the SW folder on github but it doesn’t appear to be there now. Also, it seems you can run a “python script” which i’ve tried but I knew I’d fail to get it working correctly…. my level is more ‘plug console in and turn on’.

Is there any other way of obtaining the boot.rom? For instance, could someone message me with it all? That would be very kind!

Thanks for any help.

Cheers,

Just place the *.rom content in this link inside /games/PCXT , then select either pcxt_micro8088.rom or pcxt_pcxt31.rom in the OSD core menu and reset it:

https://github.com/MiSTer-devel/PCXT_Mi ... in/SW/ROMs

[ShyTalk]

Thank you all for the assistance; I shall give the above a try tomorrow!

Cheers,

[spark2k06]

If you are not able to enable the hardware flow control then perhaps you could use XON/XOFF which requires no additional flow control signals like CTS/RTS. Each side simply adds a byte to the UART stream to tell the other side to stop and start. Software needs to be aware of these bytes though while it does not need to be aware of the RTS/CTS signals.

Ideally, CTS/RTS should be used so that no additional code needs to be added. But now I have to understand why it doesn't work, in the Linux part I see that it is enabled:

ctrscts.png

I was wrong when I said there was no activity on RTS/CTS, but I am only observing it on RTS and only once during the core reset, then it always stays at 0:

uart_rts_n.png

The trigger is only activated twice, once just at the start of the core (at 1) and once when the recognition of COM devices is about to start (at 0). After that, there is no further change during the read or write.

Although the use of CTS/RTS would improve transfer reliability, especially at very high speeds like 921.6Kbps... I am convinced that this is not the problem with file extraction using PKZIP 2.0+.

I have noticed that the CRC failures always occur on the same files, and by doing several extractions at different speeds, the extracted content always matches, i.e. it extracts the same bad bytes every time.

With this I come to the conclusion that there must be some incompatibility with the XTIDE BIOS when using the serial port, I wish I could have tested it on a real PCXT through its RS232 port connected to the PC, but as always happens, right now I lack a NULL-MODEM RS232 cable to test the connection with another PC using serdrive, a connection that probably also makes use of the CTS/RTS signals.

Maybe someone can do this test to confirm my theory, if not, I'll get some cable and try it when I can.

[MicroCoreLabs]

When you use a Ramdisk the extraction on this file is successful?

[spark2k06]

When you use a Ramdisk the extraction on this file is successful?

It also fails... good suggestion. So, the incompatibility with PKZIP2.0+ is either from the IP Core MCL86 or the PCXT core itself:

Code: Select all

C:\PKZIP204G\PKUNZIP -- -+ -d bubblebo.zip

20220827_113118-screen.png (244.61 KiB) Viewed 8161 times

20220827_113138-screen.png (202.67 KiB) Viewed 8161 times

[spark2k06]

Besides PKZIP2.0+, there may be more applications and games that don't work for similar reasons, the main suspect is MCL86 but we'll have to see.

The best way to know if the reason for not loading an 8088 compatible app is the serdrive, from now on would be to make use of RAMDISK, and if it doesn't work here, the problem with serdrive would be ruled out.

For example, I've already found some other game that didn't work, like TAPPER, although not the original pcbooter, that works fine, but a modified and executable one from MSDos... it returns a "Disk Error" message... it could be for the same reason as PKZIP 2.0+ but unlike this one I think it will be easier to debug it, and that will be the next thing I'll do.

[MicroCoreLabs]

Would it be possible to dump the code snippet where it performs the CRC check? I can then examine all of the opcodes involved in the loop and see if there in an error in something like a flag calculation.

[pgimeno]

A CRC check failure does not mean a bug in CRC calculation or comparison; it's probably a bad decompression. Most decompression algorithms supported by PKZIP involve a lot of code, it's not a small and simple loop.

I might try some debugging. I need the exact version of PKUNZIP used, the original zip file that causes problems, and the BAD decompressed result. My idea is to check what is the code doing when it generates the first wrong byte, and what can possibly lead to generate that wrong byte. I think it's the best way to narrow it down to an as small as possible code snippet.

[flynnsbit]

A CRC check failure does not mean a bug in CRC calculation or comparison; it's probably a bad decompression. Most decompression algorithms supported by PKZIP involve a lot of code, it's not a small and simple loop.

I might try some debugging. I need the exact version of PKUNZIP used, the original zip file that causes problems, and the BAD decompressed result. My idea is to check what is the code doing when it generates the first wrong byte, and what can possibly lead to generate that wrong byte. I think it's the best way to narrow it down to an as small as possible code snippet.

All in the bug report with a location to get the exact files and versions: https://github.com/MiSTer-devel/PCXT_MiSTer/issues/6

[pgimeno]

All in the bug report with a location to get the exact files and versions: https://github.com/MiSTer-devel/PCXT_MiSTer/issues/6

Thanks, I got the zipfile and PKUNZIP but not the bad decompressed file.

[MicroCoreLabs]

it's probably a bad decompression.

Thats a good point.

The CRC algorithm is not very complicated and passes for most other files so maybe the x86 opcodes which are used for this section are all ok.

You are probably right that one of the decompression subroutines uses an opcode which is having trouble...

It would be ideal if a real XT (or another emulator) and the MiSTer PCXT were both running a debugger like D86 which can run to breakpoints where registers and flags could be compared. Then the breakpoints could be dialed back to the point where the two CPU's diverge.

This is how I initially debugged the MCL86.. right alongside an XT and single-stepping each one to see where they diverged.

[MicroCoreLabs]

PS: If anyone knows of a suite of opcodes tests for the 8086 please let me know. There was little available when I wrote the core long ago so I developed my own. But it is a little like correcting one's own exam, so another test suite would be helpful. Ideally it would operate like mine which stopped upon failures and identified which opcode or flag has failed...

[spark2k06]

A CRC check failure does not mean a bug in CRC calculation or comparison; it's probably a bad decompression. Most decompression algorithms supported by PKZIP involve a lot of code, it's not a small and simple loop.

I might try some debugging. I need the exact version of PKUNZIP used, the original zip file that causes problems, and the BAD decompressed result. My idea is to check what is the code doing when it generates the first wrong byte, and what can possibly lead to generate that wrong byte. I think it's the best way to narrow it down to an as small as possible code snippet.

Thank you!

I provide you with everything you need, the pkunzip and a test ZIP... along with its badly and well unzipped versions:

https://mega.nz/file/qQoUVTyZ (I'll give you the password to download it privately)

As you can see, there are only two incorrectly unzipped files in this case:

BUBBLEBO_CRC.png (47.72 KiB) Viewed 7808 times

Regarding the tapper game converted to executable from pcbooter, I have already found out the cause, and it is that we don't have a real floppy disk drive controller, being one of the things it checks and that's why it shows the message "DISK ERROR"... when we have this feature ready, which is being checked by kitune-san, it will work, I have checked it with the work he has done so far, and the game will start.

Floppy emulation by serdrive and XTIDE in this case is not valid either, and the reset routine for it doesn't work well... real floppy controller is needed:

INT 13h AH=00h - Reset Disk Controller

Code: Select all

MOV AH,00h
MOV DL,00h ;First floppy
INT 13h

[spark2k06]

I've tried changing the OSD menu text to AO486 and now it passes the diagnostic ROM tests, so the problem is definitely in the Main adaptation, I'll check it out.

However, @kitune-san, the improvements you make, please be from the prerelease branch that would already be ready (for the moment change the text to AO486 for your tests):

https://github.com/MiSTer-devel/PCXT_Mi ... elease-fdd

@kitune-san, I have added a change in the Main and now it seems that it works the same as if it was AO486 in terms of the behaviour of the floppy drive, so with the Main that I attach here you can do your tests returning the PCXT text from the OSD... also, now you have the advantage that it works at the same time as serdrive with the HDD, so you can boot from a HDD image.

[MicroCoreLabs]

Could we try a few experiments?

Try deleting one of the good files within the zip-file and then try to extract the "bad" file which previously had the bad CRC. I would like to know if the problem is the location of the file in the zip-file or if the problem is the file itself. Deleting one of the files may cause the position of the "bad" file to move and get different results.

Another experiment is to just extract the "bad" file and not the other files. I'm interested to know if there is an issue with PKUNZIP usage of memory or if the issue is just with this file.

I also have a question for the 8086 experts: I was reviewing my microcode for LES (opcode 0xC4) and I was wondering what happens when the second word fetch crosses the segment boundary... I believe my microcode will wrap to the beginning of the same segment but maybe I should instead fetch the first word of the next segment?

Which is correct for the LES[DI],BX when the address is [1000:FFFE] ?
A) DI = memory_word @0x1FFFE
ES = memory_word @0x10000

B) DI = memory_word @0x1FFFE
ES = memory_word @0x20000

I believe that the MCL86 will implement option A because the segment registers are contained in the BUI and can only be changed by the EU.

Furthermore, what if the BX is an odd address at the end of the segment so that the second byte of the word spans the end of the segment? Does the word-fetch wrap to the beginning of the same segment, or does the segment also get incremented. And then what happens to the ES word fetch?

[spark2k06]

I have made a few adjustments in Main and now the FDD implemented by kitune-san works perfectly, at least the initial tests I have done:

https://github.com/spark2k06/Main_MiSTe ... elease-fdd

I attach RBF again and the updated Main so you can test it before making it official and send pull request to sorgelig.

On the other hand, before making a pull request, it is necessary to refactor, there is a lot of code repeated between the core ao486 and PCXT for this same functionality.

Edit: Well, sometimes it doesn't work...

[Caldor]

I have made a few adjustments in Main and now the FDD implemented by kitune-san works perfectly, at least the initial tests I have done:

https://github.com/spark2k06/Main_MiSTe ... elease-fdd

I attach RBF again and the updated Main so you can test it before making it official and send pull request to sorgelig.

On the other hand, before making a pull request, it is necessary to refactor, there is a lot of code repeated between the core ao486 and PCXT for this same functionality.

Edit: Well, sometimes it doesn't work...

I have been testing this and it seems to have several issues. The floppy drives to work. The first pre-release you shared a few days ago I would mount floppies but it would never see them as mounted. In this one I can mount them and the system can see them. But booting from a floppy seems impossible. It shows the "Booting MS-DOS" and then seems to freeze there. When I boot from the HDD, it can go to the floppy and I can browse around different folders, but its quite prone to get read errors.

The bios menu does not work very well... it does seem to function as it should, practically, but visually it does not show the active bioses. Instead it shows what floppy and HDD you have mounted. A minor issue I guess because I can tell it uses the bioses correctly.

I switched to both the new prerelease main and prerelease core to test and made sure I did a full reboot, even powering the MiSTer off for 5 seconds or more.

[spark2k06]

The bios menu does not work very well... it does seem to function as it should, practically, but visually it does not show the active bioses. Instead it shows what floppy and HDD you have mounted. A minor issue I guess because I can tell it uses the bioses correctly.

This is just the visualisation, it's a bug of the Main which I have already registered:

https://github.com/MiSTer-devel/Main_MiSTer/issues/687

But it doesn't affect the operation, actually the BIOS is well loaded there.

[Mills]

I noticed during the process of working on it that it needs some more improvement for stable operation.
Freeze occurs during disk read.

The image is when trying to read FreeDOS x86BOOT.img.

2022-08-23 232256.png

I will create a temporary branch.
Please help!

The code before the rebase was saved in the following branch

Notes.
Please set the FDD disk every time after reset. If not, the drive does not seem to recognize it.

https://github.com/kitune-san/PCXT_MiSTer/tree/fdd-work

Thanks!

I have been testing this, it seems to read disks most of the time (not always), I also found I can't run any program from a floppy, the core just freezes. The only program I could load from floppy is alley cat (if I boot from a: at startup, using the boot loader image).

[breiztiger]

Hi

Same for me can’t run anything from floppy

[spark2k06]

Could we try a few experiments?

Try deleting one of the good files within the zip-file and then try to extract the "bad" file which previously had the bad CRC. I would like to know if the problem is the location of the file in the zip-file or if the problem is the file itself. Deleting one of the files may cause the position of the "bad" file to move and get different results.

Another experiment is to just extract the "bad" file and not the other files. I'm interested to know if there is an issue with PKUNZIP usage of memory or if the issue is just with this file.

I have carried out two experiments:

Bubble_fit.png (4.23 KiB) Viewed 7334 times

The first one, deleting almost all files from the zip, keeping the previous one (BUBBLE.EXE) to the one that was extracted wrong (BUBBOB.DAT). As a result, again BUBBOB.DAT and SPRITES.ECF have been extracted wrong... however the wrong bytes have changed.

Secondly, I also deleted the previous file (BUBBLE.EXE), and in this case the situation has changed. BUBBOB.DAT and SPRITES.ECF were extracted fine but SPRITES.CCF which was extracted fine before, is now not.

Therefore, it seems conclusive that there is a problem with PKUNZIP's memory usage, as you suggest. However, I'm not quite sure how to debug it to find the exact reason.

I also have a question for the 8086 experts: I was reviewing my microcode for LES (opcode 0xC4) and I was wondering what happens when the second word fetch crosses the segment boundary... I believe my microcode will wrap to the beginning of the same segment but maybe I should instead fetch the first word of the next segment?

Which is correct for the LES[DI],BX when the address is [1000:FFFE] ?
A) DI = memory_word @0x1FFFE
ES = memory_word @0x10000

B) DI = memory_word @0x1FFFE
ES = memory_word @0x20000

I believe that the MCL86 will implement option A because the segment registers are contained in the BUI and can only be changed by the EU.

Furthermore, what if the BX is an odd address at the end of the segment so that the second byte of the word spans the end of the segment? Does the word-fetch wrap to the beginning of the same segment, or does the segment also get incremented. And then what happens to the ES word fetch?

I don't quite know how to test this. Provide me with a complete instruction set and I could compare between PCEm and PCXT core.

The DOS debug doesn't seem to support the LES [DI], BX instruction as you put it, what would be the equivalent to make it work in this basic debugger?:

dos_debug.png (1.78 KiB) Viewed 7334 times

[MicroCoreLabs]

The DOS debug doesn't seem to support the LES [DI], BX instruction as you put it, what would be the equivalent to make it work in this basic debugger?:

Sorry.. I meant to type LES DI,[BX]. Do you have access to a real 8088 to try this on? I can see some emulators simply increment the linear address by 0x2 while others do what I am doing and have the next fetch wrap to the beginning of the segment.


The PCEM code snippet is below. For the second word fetch it wraps over 64KB and does not increment the segment which is what I do in my code.

case 0xC4: /*LES*/
fetchea();
cpu_state.regs[cpu_reg].w = readmemw(easeg, cpu_state.eaaddr); // geteaw();
tempw = readmemw(easeg, (cpu_state.eaaddr + 2) & 0xFFFF); // geteaw2();
loadseg(tempw, &cpu_state.seg_es);
cycles -= 24;
break;

[MicroCoreLabs]

I am noticing that those two "bad" files are also larger than 64kb! I definitely think this is a memory issue.. and possibly a segment issue!

[spark2k06]

I am noticing that those two "bad" files are also larger than 64kb! I definitely think this is a memory issue.. and possibly a segment issue!

But note also the second test I have done, they are still larger than 64Kb, and yet in the second test they extracted fine... and another file that was extracting fine before was extracted wrong.

[spark2k06]

The DOS debug doesn't seem to support the LES [DI], BX instruction as you put it, what would be the equivalent to make it work in this basic debugger?:

Sorry.. I meant to type LES DI,[BX]. Do you have access to a real 8088 to try this on? I can see some emulators simply increment the linear address by 0x2 while others do what I am doing and have the next fetch wrap to the beginning of the segment.

I do have an 8088, running on a Sergey Kiselev Micro8088 , I'll re-run the tests you suggest... and compare results. Thanks!

[MicroCoreLabs]

But note also the second test I have done, they are still larger than 64Kb, and yet in the second test they extracted fine... and another file that was extracting fine before was extracted wrong.

Hmm.. this could also be an alignment issue for words.... When a word spans two segments do we wrap and fetch the second byte from the same segment, or do we automatically increment the segment and fetch the first byte of the segment+1?

We may need multiple tests. One to see which segment the second word is fetched from when the words are aligned, and the second test is when the
1) words aligned to even address and second byte either wraps into the same segment or is fetched from the next segment
2) words misaligned. Word_1 spans over the end of the segment
3) words misaligned. Word_2 spans over the end of the segment

[spark2k06]

The DOS debug doesn't seem to support the LES [DI], BX instruction as you put it, what would be the equivalent to make it work in this basic debugger?:

Sorry.. I meant to type LES DI,[BX]. Do you have access to a real 8088 to try this on? I can see some emulators simply increment the linear address by 0x2 while others do what I am doing and have the next fetch wrap to the beginning of the segment.

I do have an 8088, running on a Sergey Kiselev Micro8088 , I'll re-run the tests you suggest... and compare results. Thanks!

Here is the test in all three environments, PCEm, Micro8088 y core de PCXT:

PCEM.png (7.22 KiB) Viewed 7259 times

Micro8088.jpg (110.08 KiB) Viewed 7259 times

CORE_PCXT.png (157.69 KiB) Viewed 7259 times