A Real PC XT Core Perhaps?

[breiztiger]

new pc xt core on zxuno

https://www.youtube.com/watch?v=T8E7zPSBSpk

[jca]

This is the Next186 core which has already been ported to MIST.
https://www.youtube.com/watch?v=i07ioB_pp_I

[vanfanel]

And is a very inaccurate core, btw.

[jca]

In June I made the following post
viewtopic.php?p=28896#p28896
This was before the port to MIST but it did not cause a riot.

[jca]

There is a new post in another thread:
viewtopic.php?p=38147#p38147
VGA compatibility is somewhat limited, which breaks quite a few games.

[breiztiger]

pc xt (8086) have just cga or hercule in the time

pc 1640 from amstrad got an ega card

last xt from ibm have a 286/6Mhz

for vga games we have already ao486

[jca]

The Next186 is not an XT:
https://opencores.org/projects/next186_soc_pc
As the core is not huge there is space left for a FPU (which does not exist at this time).

[spark2k06]

I'm the one who is developing this version of Next186 for ZXUno. In this case I'm adding the FPGA TubeTime's Graphics Gremlin project to have CGA and Tandy modes, the latter partially, I have removed the rest of the modes that the original core had: EGA, MCGA...

As the CGA implementation is based on the Motorola 6845 chip, I have seen the opportunity to have a core to use with those CGA exclusive games of the era. I'll also test composite video output through the use of color burst.

The core is not exact cycle with a real PCXT, but I have lowered the frequency to 4.77Mhz to bring it closer. It still has a cache, but that one is more difficult to remove so you have to see it for what it is, an approximation ... as you can see in the video, the Salomon's Key works quite well.

I still need to include the BIOS routines for the complete handling of the CGA, and I will also add the simulation of different monochrome versions of phosphor monitors. When it's finished I'll share the sources so that whoever wants, to try bringing this core approach to the MiSTer.

[breiztiger]

Thanks a lot for your work

Why do you have remove ega,mcga modes ? It’s xt related

[spark2k06]

Thanks a lot for your work

Why do you have remove ega,mcga modes ? It’s xt related

I replace the BIOS interrupt 10h with the original ones from a PCXT, like the Micro8088:

https://github.com/skiselev/8088_bios/b ... /video.inc

BIOS functions for EGA is an extension of it.

But mostly, I remove the EGA / MCGA implementations from the core due to size on the ZXUno. Whoever is going to make the version for MiSTer can consider reincorporating them from original Next186 project and mix the corresponding extensions in the BIOS, it will be a hard task but I suppose it is possible.

However, my main motivation for this core is CGA / Tandy and, if I see that it is possible, composite video using color burst.

EGA may come back in the future, if the author of the Graphics Gremlin project implements it:

https://github.com/schlae/graphics-gremlin#future-plans

The video improvements here will follow the line of this project ... as long as it fits in the ZXUno, although for MiSTer the size will not be a problem.

[spark2k06]

First version already available (Spanish):

https://zxuno.com/forum/viewtopic.php?f=56&t=6261

I will provide the sources soon.

[akeley]

if I see that it is possible, composite video using color burst.

Fingers crossed.

[spark2k06]

if I see that it is possible, composite video using color burst.

Fingers crossed.

At the moment it is not implemented, let's see if I first fix several issues that are still pending ... but I have it in my to do list

[kathleen]

However, my main motivation for this core is CGA / Tandy and, if I see that it is possible, composite video using color burst.

EGA may come back in the future, if the author of the Graphics Gremlin project implements it:

https://github.com/schlae/graphics-gremlin#future-plans

The video improvements here will follow the line of this project ... as long as it fits in the ZXUno, although for MiSTer the size will not be a problem.

First of all, thank you for your hard work !

I've been crossing my fingers since a while hoping to see coming out of the ground, a Tandy 1000 core.
As your main motivation was CGA & Tandy, does it mean that we can expect also a Tandy 1000 compatible core ?
Is a Hercules 720*348 monochrome graphic card possible as well ? To me this is as important as the CGA (and Tandy) for the XT computers.

Anyway what ever you decide to implement it will be more than welcome.

[spark2k06]

First of all, thank you for your hard work !

I've been crossing my fingers since a while hoping to see coming out of the ground, a Tandy 1000 core.
As your main motivation was CGA & Tandy, does it mean that we can expect also a Tandy 1000 compatible core ?
Is a Hercules 720*348 monochrome graphic card possible as well ? To me this is as important as the CGA (and Tandy) for the XT computers.

Anyway what ever you decide to implement it will be more than welcome.

Thanks!

Hercules or other graphics cards will be ported to this core when the author of the Graphics Gremlin decides to dedicate time to this task.

On the other hand, I have already made the sources available in the following repository of my GitHub account:

https://github.com/spark2k06/next186lit ... cs_gremlin

For more technical details, you can see the following post that I have created in forofpga (spanish):

http://www.forofpga.es/viewtopic.php?f=8&t=430

[Televicious]

So if you're going Tandy, will Tandy sound replace the adlib? Will Deskmate and DOS be rom bootable?

[spark2k06]

So if you're going Tandy, will Tandy sound replace the adlib? Will Deskmate and DOS be rom bootable?

Tandy Graphics initially only, and only because it comes standard on TubeTime's Graphics Gremlin project... let us also remember for the moment, partially.

For sound, my preference is Adlib. And on a ZXUno, with limited resources, I would be lucky if it fits the OPL2 module that @jotego is currently developing, the jtopl2:

https://github.com/jotego/jtopl/blob/master/README.md

[pgimeno]

I've read the thread you linked, thanks for posting it!

"Packed file is corrupt" is a message emitted by the decompressing stub generated by EXEPACK.EXE, an RLE compressor that I believe was created by Microsoft and distributed with MASM. It was used by a wide number of programs, so if the problem manifests itself in the stub, it's 100% certain that many more programs will be affected. I've made a scan in my DOS disk and found 156 executables packed with EXEPACK, among them many DOS utilities.

Note also that early versions of the stub also had a bug that resulted in "Packed file is corrupt" when the executable was loaded in a very low address; for that reason there was a program called loadfix.com that just reserved some memory and executed the argument.

By the way, the ao486 core had the same issue with self-modifying code. Here's the commit that fixed it in case it can serve as inspiration: https://github.com/MiSTer-devel/ao486_M ... fbf24a5c51

On a different subject, there's an emulator that is apparently cycle-accurate, called PCem https://github.com/sarah-walker-pcem/pcem/ which might be useful for creating an 8086/8088 module.

[spark2k06]

Thanks for the information, I did not know that format. I have carried out a fix in the management of the instruction cache, specifically after the execution of MOV memory access instructions.

Although the problem has been solved for me with a different stub used in a version of the AlleyCat game (whose executable occupies 61Kb), it has not been the case with the exepack, at least not with the MadMix game:

https://github.com/spark2k06/next186lit ... e4fd00f645

Regarding the PCem, thank you, I knew it ... in fact it is the one I use to do quick debugging. However, trying to develop an IP Core starting from 0, and integrating everything that surrounds it, is beyond my possibilities ... I am satisfied with gradually fixing bugs that I observe in the Next186, knowing the limitations that we have in many ways, including cycle accuracy, but any approximation to a 4.77Mhz PCXT will be welcome.

[pgimeno]

Although the problem has been solved for me with a different stub used in a version of the AlleyCat game (whose executable occupies 61Kb), it has not been the case with the exepack, at least not with the MadMix game:

Good to know that the instruction cache issue is fixed.

Does MadMix run if you execute it with loadfix? (loadfix.com comes with certain versions of MSDOS) Something like: C:\>loadfix madmix.exe

If so, the problem is NOT the core; it's a bug in certain old versions of the ExePack stub, which require being loaded in a segment number >= 1000h, and the core is running just fine (it will happen on a real computer too). https://home.csulb.edu/~murdock/loadfix.html That's consistent with the fact that it works when launching it with debug, because the size of debug is enough to cross the 64K barrier. The segment shown in the snapshot of the other forum is 1A35h, well above 1000h.

If you can't find loadfix.com, try loading some resident programs until the first 64KB of RAM are full, then run MadMix.

I think UPX is able to unpack ExePack files. Unpacking it should suffice as a fix, as the ExePack stub will no longer be there. But if the goal is to run the original, the only solution is to load it above segment 1000h with any of the tricks mentioned.

Edit: Wait, ackerman is right, it's a problem of the core, with lack of segment wrap-around. In an XT, if you attempt to write to e.g. FFFF:0010 you're actually writing to address 0, due to wrap-around caused by the 20-bit address bus of 8086/8088. That's what the A20 gate is about: it's a setting, configurable via software in PC-AT and greater, to force compatibility with XT by making the segments wrap around like that. To fix it, you need to get the CPU module to wrap around addresses.
Try this in debug:

Code: Select all

-d 0:0 l 1
-e ffff:10 <something different to what 0:0 contains>
-d 0:0 l 1

If 0:0 is not modified by the second instruction, then the core does not behave like an XT and you need to fix it by somehow getting it to wrap around.

[spark2k06]

Edit: Wait, ackerman is right, it's a problem of the core, with lack of segment wrap-around. In an XT, if you attempt to write to e.g. FFFF:0010 you're actually writing to address 0, due to wrap-around caused by the 20-bit address bus of 8086/8088. That's what the A20 gate is about: it's a setting, configurable via software in PC-AT and greater, to force compatibility with XT by making the segments wrap around like that. To fix it, you need to get the CPU module to wrap around addresses.
Try this in debug:

Code: Select all

-d 0:0 l 1
-e ffff:10 <something different to what 0:0 contains>
-d 0:0 l 1

If 0:0 is not modified by the second instruction, then the core does not behave like an XT and you need to fix it by somehow getting it to wrap around.

Thank you! Indeed, that was the reason. We have another 512KB version of SRAM for this core where that problem doesn't happen. Soon I will disable access to more than 1MB to bring it closer to a real PCXT, perhaps in the future we can consider using the remaining memory as EMS.

[spark2k06]

ZXUno PCXT CGA (Beta 0.1)

• First Beta version.
• 2MB version of SRAM with 1MB addressable.

Changes on GitHub:

https://github.com/spark2k06/next186lit ... 82597b5ac6



TODO

• Software and game debugging for continuous BIOS and core improvement.
• EMS memory support for the megabyte available in the 2MB version.
• Complete removal of the cache used by the Next186.
• If possible, integration of the JTOPL2 module from @jotego to support Adlib when it is available.
• Integration of the composite video (burst colour) module of the Graphics Gremlin project by @schlae.
• Check why the VGA signal generated by the Graphics Gremlin module does not work on some monitors. Example: FLATRON M1917A
• Continuous improvement and fix another bugs.

[spark2k06]

All traces of access to the old VGA support of the Next186 have been removed, but aside from the pending improvements, one of the important points is the bug fixes. I have already identified a few games that are not playable, because either they do not work or if they do they do not go well, they crash, etc ...:

• Army Moves: Graphic glitches
• Capitan Trueno: Hangs during key redefinition
• Paku Paku: 160x100 mode not displayed correctly, rows are duplicated
• Tapper: It starts but the game does not start, it hangs.
• Fernando Martin: It works but the character font is not displayed correctly

Besides we have the small problem of the first ghost line in text mode, which I have not yet found the reason for.

Then there are many other games that do work, but before continuing with the solution of these bugs, I would like to rule out that they are bugs of the synthesizer ISE of Xilinx, bugs that are really difficult to detect, like the following one that I had to fix:

http://www.forofpga.es/viewtopic.php?f=32&t=432

To rule it out, I'm going to wait for this core to be ported by someone to another FPGA, and see if they happen there too. In the meantime, I will continue adding functionality such as the use of expanded memory for the MByte remaining of the 2Mb version, or when the @jotego jtopl2 module is available, well Adlib support.

[spark2k06]

Soon EMS available for the 2Mb version of SRAM of the ZXUno and ZXUnCore, thanks to Lo-Tech's LTEMM manager, modified to support 1Mb of memory with 64 pages. We will also have a lot of conventional memory available making use of high memory

ems.jpg (47.19 KiB) Viewed 41784 times

[spark2k06]

Beta 0.2

• EMS memory support for the megabyte available in 2MB versions.
• Fixed some bugs.
• Refactoring and cleaning of project files.

Changes to my GitHub repository:

https://github.com/spark2k06/next186lit ... f8aa48a7cd

[held]

If you can run this CGA 8088MPH demo, I will be impressed:


And for those that are confused: https://trixter.oldskool.org/2015/04/07 ... emulators/

[spark2k06]

If you can run this CGA 8088MPH demo, I will be impressed:
https://www.youtube.com/watch?v=hNRO7lno_DM

And for those that are confused: https://trixter.oldskool.org/2015/04/07 ... emulators/

I know this demo and the answer is no, not at the moment at least. There are several things to fix in this project and the one it is based on (Graphics Gremlin). It is for this reason that I consider it a beta version. In this sense, I have just released an improvement to correct the bug of the first ghost line in text mode:

https://github.com/spark2k06/next186lit ... 9e78a14319

fixed_first_line.jpg (43.88 KiB) Viewed 51860 times

[held]

I know this demo and the answer is no, not at the moment at least.

Then I will be patiently waiting

[breiztiger]

me too

[jordi]

This core would be a must in Mister, as a preservation project! I vote for porting it.