MiSTer FPGA Forum

I have instantiated the module in the same way as the 16550 we are using so far, but it does not recognise the HDD images... with this new module I was hoping that the problems regarding access to them would improve, especially at the maximum speed of the UART (921.6Kbps). Was there any progress on the UART flow control signals? They may be needed...

friendly.joe wrote: ↑Tue Aug 30, 2022 2:55 pm @spark, @MicroLab, @kitune-san

I'm closely following the development of this core.
Congratulations on the achievements done so far!

What a friendly thing to say! Thank you friendly.joe!

This seems to imply that my (oldish) copy of DOSBOX-X is broken in its emulation of LDS/LES wraparound. That, or things are different for 8086 vs 8088 (it doesn't support 8088). The 8088 and 8086 share the same EU core, so they are both the same CPU with only difference being the BIU. Lots of cores implement LDS/LES incorrectly. :) They just add 0...

Not that it matters anymore, but that 00 doesn't make much sense. It matters :) I agree that the results do not look 100% right, even though PKUNZIP is happier with the result. Can we run this test one more time? The MCL86 results should exactly match the real 8088 and PCEM which uses the same algorithm I do. One thing I noticed is that the PCXT B...

It was late last night so I did not get a change to suggest that the problem appears to be in the BIU, but @kitune-san seems to have found it! :) Im very surprised that only PKUNZIP was having trouble as the problem with the BIU appears to have been related to word accesses so you would think many applications would also be failing! Thank you @spar...

Thank you for gathering these results, but I suggest that you populate the two words in memory so we know for certain which ones are being fetched into DI and ES. It would be easier to see what is happening if you populate memory at the end of the segment with an incrementing pattern. DS:0000. 11 DS:0001. 22 DS:FFFC. CC DS:FFFD. DD DS:FFFE. EE DS:F...

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. Sorry I did not answer this. LES fetches two words. The first one goes into the described register and the second word gets stored in the segment register ES. We want to see how LES operates when the beginning address wil...

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 d...

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!

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 t...

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 "...

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 fla...

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 e...

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.

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

Thanks for the heads up, now it's time to pull the thread and find out how to enable it. 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...

I believe the UART flow control needs to be enabled in the Cyclone-V SOC configuration inside of the HPS. I recall reading that it is disabled by default, and they seems to be what you see. Actually, is there no activity in either direction? Maybe your core is also not using flow control on your UART. Once you fix this, you should able to run at me...

I believe you that the UART flow control signals are connected, but I wonder if they are enabled on the host side. They may default to disabled. One easy check is to see if they toggle using SignalTap.

.cts_n (uart_cts_n),
.rts_n (uart_rts_n),

As long as these signals are connected between UART endpoints you should be ok with the hardware flow control, but it might be something worth checking or adding to SignalTap to make sure they are being respected and data does throttle.

Looking at the MiSTeR PCXT output, I think I can spot what's causing some of those display issues... 6845 start address latching isn't implemented; on the real chip (and all clones) new start addresses don't take effect until the next CRTC cycle. The ±VIDEO bit in the Mode Select register is also not implemented (port 3D8h bit 3); when it's clear ...

Is this UART literally a UART? Meaning TX and RX signals, and not some emulated UART which uses registers and not discrete signals?

If it uses TX/RX signals then are we also using the flow-control signals or inserting/sensing XON/XOFF? Without any type of flow-control you will get corrupted and lost data.

This would be the definitive change for an official release or do you think it needs a different solution? It's a definitive change :) The MCL86 has two bits to store the segment override register and another bit to activate this override. The problem is that I was clearing both fields when I should have only cleared the activate bit. When cleared...

Your microcode doesn't seem right. Did you you replace both 4ddf0000 and 5c7f0000 with a single line 4ddf0003? 5c7f0000 is missing in your microcode...

You just want to change the eight instances of 4ddf0000 that precede 5c7f0000 with 4ddf0003. Just the two bits

I think I found the error in the microcode. It looks like the segment override selection is being cleared by mistake across all string opcodes.

For a quick fix can you look for the sequence 4ddf0000 5c7f0000 in the microcode - there should be eight instances of this sequence.

For each one please change the 4ddf0000 to 4ddf0003 and see how it works!

Could you add some MCL86 signals to SignalTap with a trigger on the 0x5C write? The first MOVSB was successful and after this instruction CX equals zero, so it appears that the CX number of bytes were transferred with all but the first being read from or written to the wrong segment. Triggering on the first write and looking at the subsequent cycle...

Of course the SS is necessarily modified when an interrupt is taken. The DS is not. Suspicious, no? :) I believe the sequence you isolated is being interrupted in the middle of the REP, possibly after the first copy. And on the genuine 8088 which has a bug where only the prefix preceding the MOVSB is saved. Also, I suspect that DEBUG will also debo...

this behaviour is reproduced, and both in PCEm and in a real PCXT (8088 in Sergey's Micro8088 project) it works fine. Hmm.. this is not actual 8088 silicon, correct? The testing I did was against the real Intel 8088 to duplicate the exact behavior - especially for things like Interrupts, TRAP, and repeats. There are "bugs" in the real 80...

Exactly, that is the first byte, but 32 should have been copied. Thats good. So the override is working and so is the MOVSB... just something strange about either the REP or the SEG_OVERRIDE. As a quick test, would it be possible to move the CLI to before the repeated MOVSB so see if it is true that an interrupt is messing up the REP? Its been a w...

Does the first byte of the MOVSB get moved successfully? Is the 0x5C the first byte? I am wondering if you are getting an interrupt between repeats of the MOVSB opcode. Remember that the real 8086 will only remember the first prefix opcode in between interrupts. Your sequence of 0xF3 0x36 0xA4 is REPeat, Segment_Override_to_SS, MOVSB. So if there i...

Below is a video of the Area 5150 demo run in this PCXT project for MiSTer:

I'm happy to see that the MCL86 is able to run this new demo for the most part.