MiSTer PCXT

[spark2k06]

I have started the development of a new core for MiSTer, it would be a PCXT. The idea is to try to implement a core as reliable as possible to the original one, to achieve it, we start using MCL86 from MicroCore Labs as CPU core.

Additionally, it has also implemented the Graphics Gremlin project project from TubeTimeUS. In the future, it is possible that new graphics modes can be added, such as EGA, or the proper implementation of Tandy modes, as well as the simulation of composite video color burst mode.



At the moment, I am not getting the hardware interrupts to execute, so the keyboard does not work. I have proceeded to publish the sources, and will be working on them, I welcome any help on this from other developers.

In this initial stage, naeloob has helped me with the MiSTer project base, as well as various tips and help on this system. Several modules are inherited from Next186, and many things may not make sense in this project, so some cleanup will have to be done.

About IBM Basic, in the repository I have not published the ROM of it, but it can be downloaded from here and resynthesize the core. Anyway, it's something that doesn't matter much now, since the keyboard doesn't work. One of the pending tasks would be to support ROM selection from the OSD.

[jordi]

Oh
That's really nice!!!!

[Alkadian]

That's great news, many thanks!

[NML32]

That’s great, thank you.

[JasonA]

I will help you as I have been working heavily on the Next186 port.

[dmckean]

If anyone wants to have a go at Tandy/PC Jr. graphics support, the Video Gate Array appears to be well documented in the technical reference.

http://bitsavers.trailing-edge.com/pdf/ ... _Nov83.pdf

[tontonkaloun]

Many thanks !

[Mills]

Thanks a lot, hoping to see more .

[spark2k06]

As for running the IRQs, @JasonA has given me the clue, and that is that I was using the latest version of the PIC module modified by gyurco in the MiST version, which supported ISR, and for whatever reason, it doesn't work properly here.

I have downgraded the module version to the original version as well as the INT08 call in the much more basic Next186 project BIOS, and the IRQs are already running. However, it now seems to hang often during the execution of these IRQs. It's time to investigate why, but in the meantime, I've already updated the sources in the GitHub repository with these changes.

I have added the possibility to turn IRQ0 on and off from the OSD menu, but this would be a temporary feature until I fix this other issue

[spark2k06]

I have not been able to devote much more time to the project at the moment, I have caught up a bit with a simulator, Active HDL, to be able to follow the execution flow and the signals. The last clue I have is one that gyurco gave me and which makes a lot of sense:

The Next186 modules are not handling CS, WR, etc. in an edge triggered way, but expects these signals as a single cycle pulse. If a CS & WR lasts for more cycles, it might have unwanted consequences (for example, the PIC acks all interrupts, not just the last one in service).

This should therefore be taken into account when identifying the issue.

[spark2k06]

Beta 0.2

• Scancodes SET 2, temporarily.
• Automation of the boot0.rom file generation with a python script, from the bios and optionally ibm basic via minuszerodegrees.net download.

Apparently, after downgrading the PIC module, it seems that the keyboard responds in two circumstances:

• CPU at 7.16Mhz
• IRQ0 disabled

However, it doesn't seem to be switching to the scancodes SET 1, possibly the cause is the same as the reason why IRQ0 doesn't work, in general the timmings and the signal processing. But for the moment, and to get by, I have updated the BIOS to work with the scancodes SET 2, and we can now say that we have the Basic ROM working

MiSTer PCXT - Beta 0.2.gif (4.22 MiB) Viewed 114825 times

At the moment, I don't know how to make the boot0.rom file boot automatically or from the OSD, so the loading of the boot0.rom file is implemented like this:

Code: Select all

module bios(
  input clka,
  input ena,
  input wea,
  input [15:0] addra,
  input [7:0] dina,
  output reg [7:0] douta
);

reg [7:0] bios[65535:0];

initial $readmemh("bios.hex", bios);

always @(posedge clka)
  if (ena)
		if (wea)
			bios[addra] <= dina;
		else
			douta <= bios[addra];

endmodule

I don't want to keep in the repository copyrighted roms or releases containing these roms by default, so the release I have published is about the BIOS without IBM Basic. The procedure to have a release with this one is as simple as running the tool make_boot0_with_ibmbasic.py that I have prepared that will generate boot0.rom, then with a hex editor update the bios.hex file with the result of the values of this one and finally, resynthesize the core.

Edit:

What really happens is that the keyboard initialization is not completed at 4.77Mhz, but at 7.16Mhz... so, it is enough that at the start of the BIOS core is set to 7.16Mh, then with the Basic ROM running you can switch to 4.77Mhz from the OSD if you want.

[spark2k06]

It takes the same time at 4.77Mhz as it does at 7.16Mhz, how strange this is, I wonder how long this sequence of code will take in IBM BASIC on a real PCXT:

Chrono.jpg (81.17 KiB) Viewed 114646 times

[kathleen]

It takes the same time at 4.77Mhz as it does at 7.16Mhz, how strange this is, I wonder how long this sequence of code will take in IBM BASIC on a real PCXT:

Chrono.jpg

I own a Tandy 1000 (4.77mhz/7.16Mhz as well) I can try this loop on it tomorrow evening and let you know how long it last to get it completed.

I also have a µ8088-XT (https://github.com/skiselev/micro_8088) where I can give a try if you fell this relevant.
This one is equipped with a VGA card however, don't know if this won't affect positively the results.

Just let me know.

EDIT : I've just made a quick test under 86box which is quite accurate and this loop takes also a little more than 11s so to me you're not far from the reality, anyway I'll confirm this tomorrow on hard.

[spark2k06]

EDIT : I've just made a quick test under 86box which is quite accurate and this loop takes also a little more than 11s so to me you're not far from the reality, anyway I'll confirm this tomorrow on hard.

It might make sense that it takes a bit longer, but keep in mind that in my test I have disabled IRQ0, which executes int8 18 times per second.

However, what I find strange is that I'm getting 11s at both 4.77Mhz and 7.16Mhz, it's throwing me off.

[kathleen]

However, what I find strange is that I'm getting 11s at both 4.77Mhz and 7.16Mhz, it's throwing me off.

Agree, this is weird. I'll test at both frequencies, but I'm pretty sure that the time will be reduced

[remax]

Code: Select all

import binascii
filename = 'boot0.rom'
with open(filename, 'rb') as f:
    content = f.read()
out=binascii.hexlify(content, b' ', 1)
out = out.upper()

fp = open('bios.hex', 'wb')
fp.write(out)
fp.close()

For the lazy ones, i made another python script that produce the bios.hex file from the bios0.rom.

The code is probably ugly as i am i no way a programmer but i think it does the trick (at least it produce an identical bios.hex with the non basic rom).
May be useful to someone testing the core until direct rom loading is supported

[kathleen]

Here are my today's results.

1st try on my Tandy 1000. As you can see I set the speed to LOW which corresponds to 4.77Mhz. The output is CGA (on a LCD monitor thanks to the interface MCE2VGA (https://www.serdashop.com/MCE2VGA).

20220513_144832.jpg (673.75 KiB) Viewed 114407 times

Then I run the small basic program and.... it last 11 sec 31.

20220513_145958.jpg (423.96 KiB) Viewed 114407 times

Then I changed the setting to run the Tandy 1000 in fast mode (7.16 Mhz)

20220513_150111.jpg (730.63 KiB) Viewed 114407 times

end yes, I do confirm the duration is different, in this case : 9 sec 35. (A gain af almost 2 seconds from 4.77 Mhz to 7.16 Mhz)

20220513_150354.jpg (656.61 KiB) Viewed 114407 times

Then I did the same exercise with the µ8088XT equipped with a VGA card (I checked with a CGA/Hercule card and the results were equals)

20220513_154444.jpg (680.39 KiB) Viewed 114407 times

And with the setup, also running at 4.77 Mhz, the duration to complete the loop was : 10 sec 80

20220513_154801.jpg (604.51 KiB) Viewed 114407 times

BUT, I realized that this µ8088XT board was equipped with a 8087 coprocessor I do not know if this could have an impact on a lopp in Basic.
If needed I'll ask to get the 8087 removed and I'll repeat the test.
Hope this will help.

[spark2k06]

Thank you very much for the test, it is very useful.

There is one thing that seems to be more or less clear, and that is that even though we have it configured at 7.16Mhz, it always seems to be running at 4.77Mhz, any limitation of MCL86? Some mistake on my part at some point in the process? We will see.

[spark2k06]

I've just found a mine for the goal of having a PCXT...

https://github.com/kitune-san/KFPC-XT

We'll have to dig deeper into all this and see how it all fits together with MCL86.

[spark2k06]

I've just found a mine for the goal of having a PCXT...

https://github.com/kitune-san/KFPC-XT

We'll have to dig deeper into all this and see how it all fits together with MCL86.

I've been having a look at it and it's really complete, I'm definitely going to work on putting it all together, that is: KFPC-XT + MCL86 + Graphics Gremlin

It will take time, I'll keep you posted on it.

[pgimeno]

1st try on my Tandy 1000. As you can see I set the speed to LOW which corresponds to 4.77Mhz. The output is CGA (on a LCD monitor thanks to the interface MCE2VGA (https://www.serdashop.com/MCE2VGA).
20220513_144832.jpg
Then I run the small basic program and.... it last 11 sec 31.
20220513_145958.jpg
Then I changed the setting to run the Tandy 1000 in fast mode (7.16 Mhz)
20220513_150111.jpg
end yes, I do confirm the duration is different, in this case : 9 sec 35. (A gain af almost 2 seconds from 4.77 Mhz to 7.16 Mhz)
20220513_150354.jpg
Then I did the same exercise with the µ8088XT equipped with a VGA card (I checked with a CGA/Hercule card and the results were equals)
20220513_154444.jpg
And with the setup, also running at 4.77 Mhz, the duration to complete the loop was : 10 sec 80
20220513_154801.jpg
BUT, I realized that this µ8088XT board was equipped with a 8087 coprocessor I do not know if this could have an impact on a lopp in Basic.
If needed I'll ask to get the 8087 removed and I'll repeat the test.
Hope this will help.

Is that ROM BASIC? If not, the results may not be comparable. I think GWBASIC's interpreter is somewhat different, and the timings for running from ROM may differ from those for running from RAM. In fact I wonder if the core has any wait states when reading from ROM that could explain the lack of differences; that's a very long shot though.

The 8087 should have no influence whatsoever.

[pgimeno]

Just noticed this thread:

viewtopic.php?p=51297#p51297

Relevant highlight (emphasis added):

The CPU core has been written from scratch (its based on the work of https://www.reenigne.org/blog/8086-micr ... assembled/) and thus its timings should be accurate to the original chip. Its not complete yet, but I`m making slow progress

From the link (emphasis added):

8086 microcode disassembled

Recently I realised that, as part of his 8086 reverse-engineering series, Ken Shirriff had posted online a high resolution photograph of the 8086 die with the metal layer removed. This was something I have been looking for for some time, in order to extract and disassemble the 8086 microcode. I had previously found very high resolution photos of the die with the metal layer intact, but only half of the bits of the microcode ROM were readable. Ken also posted a high resolution photograph of the microcode ROM of the 8088, which is very similar but not identical. I was very curious to know what the differences were.

The README.md in the repo says:

8088 Bus Interface 90%
8086 Bus Interface 0%
Microcode Translation 61%

Sounds like the best option if you want a really, really accurate 8088 core. It's still WIP though.

[spark2k06]

Is that ROM BASIC? If not, the results may not be comparable. I think GWBASIC's interpreter is somewhat different, and the timings for running from ROM may differ from those for running from RAM. In fact I wonder if the core has any wait states when reading from ROM that could explain the lack of differences; that's a very long shot though.

The 8087 should have no influence whatsoever.

You can see in the image that GWBasic is being used, and I am aware that there may be some differences, I was looking for an approximation. Regarding the issue of the wait states, and the fact that there are no time differences of 4.77MHz and 7.16MHz, I'm sure it's an implementation failure on my part at some point.


Anyway, as I am changing the approach, using KFPC-XT which is much more complete than the implementation leftovers inherited from Next186, we will see what results it gives when everything is assembled, from then on it will be fine-tuned.

[spark2k06]

Sounds like the best option if you want a really, really accurate 8088 core. It's still WIP though.

This is very good, when the implementation is 100% complete, we will assess it. I will also evaluate the 8088 implementation currently being developed by the same author of KFPC-XT:

https://github.com/kitune-san/KF8088

As you will see in the README file, it is also based on the research from the same blog you provided.

However, let's give MCL86 a try, I don't think it will disappoint either and its development is currently complete.

[dmckean]

Even if we found inaccuracies in the MCL86 microcode implementation, I would think that the author would want to fix them.

[spark2k06]

As for the line of work from the KFPC-XT project, it is not going to be easy at the moment. There are many signals from the chipset module that I don't know how to fit together, and they are important for the correct functioning of the system:

CHIPSET_SIGNALS.png (18.94 KiB) Viewed 113690 times

We have to wait for the author to move forward with the associated KF8088 project (last updated a month ago), where he will implement the CPU to understand how he connects all these signals. We will then also be able to assess whether to use this same CPU as implemented by him or the MCL86:

https://github.com/kitune-san/KF8088

In the meantime, I will go back to the original line of work, and try to solve the problem with the PIC module, now that I have become more practised in using the Active-HDL simulator.

[spark2k06]

I create a separate branch with the KFPC-XT integration, it does not run the opcodes, it is not functional at all. I will also contact the author of KFPC-XT to see if he can give me some hints for further development... if I can get his email or contact details, because he hasn't made this information public on his GitHub account.

@JasonA, if you want to give him a go too, it's available here

https://github.com/spark2k06/PCXT_MiSTe ... PC-XT-test

[JasonA]

Sure, I will be involved.

Regarding the PCXT test branch: verilator is integrated but might have some issues to solve today. I am investigating. Therefore, anyone looking at the repo should be cautious on that branch and using verilator for the time being.

I have forked the upstream, and am also investigating the possibility to reuse this core with additional work to use Next186, rather than having two separate cores for PCXT and Next186. Next186 this month has been a bit problematic. Lots of work has been done in attempting to get the Next186 core to boot properly. This PCXT core though, has video outputting correctly, and doesnt use various megafunctions (especially the cache controller) that might fail in attempting to convert to reasonable modules to use in verilator. Moving Next186 over to this core in its current state will be easier to simulate in verilator. These are the reasons for this new approach.

Thanks to all who have shown an interest in PCXT and Next186, and also for all the testing that has been done this month

[kitune-san]

Hi

Thank you for your interest in my repository. ツ

.io_channel_ready is commented out.
Please set "1'b1" if you unuse this signal.

---
Sorry, I am not good at English.

[spark2k06]

Hi

Thank you for your interest in my repository. ツ

.io_channel_ready is commented out.
Please set "1'b1" if you unuse this signal.

---
Sorry, I am not good at English.

Yes, that was the first thing I did. It started executing instructions, but then it didn't make the jump to the coolboot section of the BIOS. That's when I gave up and thought that other unassigned commented signals might be influencing it, and that's why I put the project on hold.

Considering that no other signals can be really important for the correct operation, I will keep on investigating.

Thank you very much!

By the way, I'm not very good in English either, but the deepl translator helps me a lot:

https://www.deepl.com/es/translator