MiSTer FPGA Forum

Some people are on the fence about thi, but I think there is a lot of untapped potentiel here. Yeah, I believe the argument for keeping the CPU and peripherals in the FPGA fabric is because it is easier to port between FPGA vendors. SOC CPUs are less so... But that said, these processors in the FPGA are only going to get more powerful giving more ...

Hi, I thought I would share some of my results with this thread as another datapoint on hybrid emulation. One of my recent projects is the MCL86+ which is an 8088 emulation running on an 800Mhz Teensy 4.1. There is enough CPU power to emulate the 8088 at near x386 speeds as well as the local bus interface. Using this platform I am able to run a 650...

Archon is my favorite game, and one of the first programs I try when testing a new core! I enjoy watching the demo to see who wins: The computer or the computer!

I already saw it, but specifically for the BIOS ROM and XTIDE part, I still think it is possible to use the RAM module already developed by kitune-san, which in turn uses the SDRAM controller also developed by him, for loading from IOCTL at the beginning of the core, when the ioctl_download signal is active... but tests should be carried out to ma...

unfortunately the current development in MiSTer is using too much BRAM for many FPGAs, I wonder why such high BRAM usage? The MCL86 CPU core uses a small number so maybe the other controllers are using up the space. At one point I think they were using BRAM for the system DRAM up to 256KB, but now that they have SDRAM working I hope these BRAMs ha...

In the current design, as the clock frequency is increased, the sdram read time exceeds the machine cycle time. The Ready signal can be used, but the effect of increasing clock frequency is reduced. SDRAMs usually have sub 100ns access times and the controller is running at 100Mhz, correct? So shouldn't we be able to perform a complete read/write ...

Achieving speeds faster than 7 MHz is more difficult with SDRAM.

Why is this?

I changed biu_max.v to run on the edge of the CPU clock.

Looks good, thanks!

kitune-san wrote: ↑Thu Jul 14, 2022 4:18 pm

kitune-san wrote: ↑Tue Jul 12, 2022 11:58 pm I am trying 7MHz on the core right now.
It will take time.
Wait.

7 MHz test.
Will not work except for 8088BIOS due to problems with DMA address switching.

Can you share how you are achieving 7Mhz?

The load speed right now is limited by the use of the UART port, up to 115.2Kbps,

What is limiting the speed to 115,200? If the UART and signal nets are all on-chip then can it be set to a higher speed?

Thanks for the quick update. Now, the most important thing left is the turbo mode (7.16Mhz). "prince of persia" is too slow. This should be fun! As I mentioned before, to run the BIU at anything other than 4.77 Mhz will require some updating to make it sensitive to the bus clock. Currently it only looks at a single 4.77 Mhz clock edge an...

Also this is a comparison of an 8088mph effect, the top part shows how it should look, and the bottom one shows this core, it is getting close :): Yeah, the Kefrens Bars part of 8088 MPH are one of the more timing sensitive parts of the demo. It's interesting then when I run the MCL86 in a real IBM PC the bars only reach about 70% of the screen wh...

Apparently it happens when the room(device) temperature is low. Temperature dependence is an indicator of a timing error in the FPGA. I suggest examining every instance where signals cross clock domains and also make an effort to completely constrain the design so you can achieve consistent results between synthesis passes and across devices. Some...

Apparently it happens when the room(device) temperature is low. Temperature dependence is an indicator of a timing error in the FPGA. I suggest examining every instance where signals cross clock domains and also make an effort to completely constrain the design so you can achieve consistent results between synthesis passes and across devices. Some...

set_clock_groups -asynchronous -group {SDRAM_CLK} -group {clk_14_318 clk_4_77 peripheral_clock} I would check that all of your clocks are tagged as asynchronous of each other, that 100Mhz clock is included, and that the full module path of your clock names are correct. An example might look like this: set_clock_groups -asynchronous \ -group [get_c...

I suggest making some clock domains asynchronous with each other using "set_clock_groups -asynchronous " in the .sdc file Without this constraint Quartus will assume there is a phase relationship between all clock domains and will take much longer to Fit. I also suggest constraining the 100Mhz clock which the MCL86 uses if it is not alrea...

The NIOS soft processor sounds interesting. I am not sure if that would allow PCEM code to convert to FPGA with some massaging, but if so, that would be awesome, assuming the end result is cycle accurate reproduction of hardware in FPGA. The NIOS could respond to the same ISA bus IO addresses as the disk controller and could bridge to the MiSTer S...

edit: also, building a convincing SCSI chip on an FPGA would probably be a freaking science project. That could take a year or more, all by itself.

Perhaps if a NIOS soft-processor was integrated into the FPGA a disk controller could be handled in software written in C...

Why can't the MCL86 core replace the x86 core on the ao486 project to take advantage of the existing motherboard and disk emulation elements?

Seems that there should be some clean division point where the CPU cores could be swapped, perhaps at the BIU level...

It turns out that at some point it stopped working as "well" as it used to. It used to go further but now, even with 640Kb of RAM, it stays in this part of the demo, in a loop: The demo uses multiple HALT opcodes in a row in combination with an interrupt to synchronize timing. If your timer interrupts or the 8288 handling of the HALT com...

With 640KB the 8088 MPH Demo should be able to run to completion. The music at the end uses the prefetch queue extensively, so it's a good test of the BIU.

Does your SDRAM controller have exclusive access to the physical SDRAM or does it share it with the SOC-CPU? If it is sharing, then when there are conflicts then you may need to assert wait-states back to the BIU. It would be better if the SDRAM access was exclusive to the MCL86, otherwise it may be difficult to be consistently cycle accurate if th...

The next big challenge is to get the SDRAM working, so that the 640Kb of main memory is available for testing larger games

You will get some nice acceleration if you provide the option to bypass the cycle-accurate BIU and access block-ram located BIOS ROMs and SDRAM at full-speed.

Awesome!

The MicroCoreLabs tests also show that it doesn't pass this test... maybe it's not a big deal and does not affect the proper functioning of the system. Hmm... the MCL86+ failed because it was running greatly accelerated. When it is running cycle-accurate it passes all tests. My other core, the MCL86 which is the one you are using, also passes all ...

https://camo.githubusercontent.com/c258 ... 442e706e67

The two 7407's, sourced by the 8255, drive the keyboard clock and data for the loopback test.

The PC motherboard has a keyboard loopback path which the IBM POST is checking and needs to be present to pass. I don't think this path is ever used after this test though.

You may need to duplicate this and other logic paths on the motherboard to fully emulate the PC successfully.

The motherboard DIP Switch-1 is for IBM's continuous POST self-test which will run forever if the switch is on. Maybe this is why the IBM BIOS locks up for you?

You could also try the SuperSoft Diagnostic ROM which also performs a few interrupt/NMI tests.

Actually, I also experienced some IRQ and keyboard errors when I ran my other 8086 core, the MCL86+, in a very accelerated mode...

Here's a video of it: https://www.youtube.com/watch?v=xXVImaMU7Hw

When I run cycle accurate there are no errors.

Also as a curiosity, I have tried other ROMs, such as the original IBM ROMs like ibmjr, ibm5150/5160 and they don't work. The PCjr ROM will not work in an IBM 5150/5160. The IBM 5150 and 5160 ROMs do a check of the timer and IRQ early in the POST which will result in the BIOS just halting if it fails. This code executes before anything is displaye...