MiSTer FPGA Forum

Just curious as to why the choice to use the licensed Intel IP versus one of the several full-featured 16550 implementations that have been around for a while...seems odd to tie a hobbyist project to a minimum $3000 US worth of IP.

Only the Core creator can answer this factually, but I would guess it was just a matter of convenience? (i.e. it was available to him at the time and he can clearly compile it).

Maybe in the future this will be replaced (maybe not).

I'm fairly convinced that this is one of the reasons that this core has (until recently) received little attention and has been heavily downplayed for a long time. A $3k investment for a hobbyist core is a pretty substantial amount of cash to tie up in something, and until there's a way to free the core from that load, I don't see many people being willing to devote much time and effort to addressing the many issues present within it (present company excepted, of course! )

I wish that was different, because the fact that we can have a (potentially) easily reconfigured DOS-era machine in FPGA is a very, very tasty thing indeed, and it would be positively amazing to have it as fully-featured as some of those older systems were capable of being (486DX-100, SB 16, MPU-401 MIDI control, 1024x768/256 color SVGA on Windows 3.1... ).

All so we could once again ask, "Who the heck is General Protection and what was his fault?!"

So this is why it costs 3000 dollars to compile? Interesting. I have been reading about this being mentioned, but did not know this was why... or maybe there are other reasons as well? I have not even used the UART feature yet. It does seem useful though, for Internet and maybe other stuff.

I believe that there were previously other reasons, but they have been replaced with open source code little by little, and this is all that's left.

if you believe there is really full featured opensource UART IP, then you are welcome to replace it and make pull request.
I know none of really full-featured opensource 16550 UARTs.
It's more excuse "why i don't do anything". Devs wanting to contribute are contributing. You want to replace UART with open source and it will be fully working in DOS and Windows - fine. Do it.

Sometimes i'm shocking from some people making such weird conclusion about having $3000 to work on core. People has nothing to do than imagine weird stories it seems

P.S. You don't need paid license to work with core even with current UART version.

Sorgelig wrote: ↑Thu Jul 30, 2020 2:28 pmP.S. You don't need paid license to work with core even with current UART version.

So it can be compiled without the paid license? Mainly because I think it could be interesting to try it out, but there are already people releasing compiled cores very regularly, so that is enough for me. But if there is a way to compile without the license, it could be interesting to try. Or are you referring to how it is possible to alter the code and such without the license?

As I went into earlier, I guess if someone really wants to develop on the core and be able to compile it, I am thinking it should be possible to just remove the UART part... not sure how deeply integrated that is, but that could be a way to alter other parts of the core and try that out.

I once got everything install to try to develop for the FleaFPGA, which supported an AO186 core. I just never got much further than installing all the tools and SDKs, and then I had reinstalled Windows before I got any further. Might have been some of the same tools.

You can build a time-limited .sof that can be loaded through the USB programming port, or if you really want a .rbf it's possible to modify the core to remove the UART (I've booted DR-DOS with a core modified like this, but I don't know if Win9x or Linux would be okay, e.g. if they load a serial driver at boot).

Yes, you can build a time-limited sof and load it from quartus. It's pretty much enough to provide core improvements.

But as i've told above, if you think you have fully working open source 16550 UART then you are welcome to replace it. All open source UARTs i've saw was just basic UART functionality far from full featured 16550.

Sorgelig wrote: ↑Thu Jul 30, 2020 6:03 pm Yes, you can build a time-limited sof and load it from quartus. It's pretty much enough to provide core improvements.

But as i've told above, if you think you have fully working open source 16550 UART then you are welcome to replace it. All open source UARTs i've saw was just basic UART functionality far from full featured 16550.

I don't think that, I was only asking if that was the case since rhester72 claimed that to be the case. Well, I was asking if UART was the only part of the core that required the license to compile it to RBF.

But it is interesting that its possible to use those SOF files directly. Once I am done constantly experimenting and trying out things with the so far daily updates of the AO486 cores, I think I will try to experiment with this.

This is the one I was referring to, specifically:

https://opencores.org/projects/a_vhd_16550_uart

I didn't perceive any issues with parity locking or FIFOs as affecting any normal functionality of ao486, but perhaps I was mistaken.

i will check it

Sorgelig wrote: ↑Fri Jul 31, 2020 2:40 ami will check it

You are not wasting time are you? I see notes about open source UART in the dev branch. With so much work being done on this core I feel like trying to help, so I will look into the development software and experiment a bit.

Cache29 seems very stable to me though, good speed. I had a lot of problems even in Windows 95 with earlier ones, but now I have been able to run Windows without issues, while installing games, installing software, running scandisk, playing games and so on. Also Duke Nukem 3D is running much better than it used to. It ran just 5 fps a few cores ago, now its 20 fps... might be down to some settings or something though, not sure what I might have done wrong though... pretty sure its some of the latest updates that did something.

The new UART seems to have adversely affected SoftMPU.

I can compile SoftMPU.EXE from github source so maybe I can fix it there.

It seems like its trying to detect the port address and failing. I notice the same issue with dosmid.

"dosmid /COM1" used to work but no longer does, however "dosmid /COM=3F8" does work


EDIT:

This code gets the com port address from BIOS and seems to be failing:

https://github.com/bjt42/softmpu/blob/b ... S.ASM#L372

I have included a copy of SoftMPU that I hard-coded the addresses for COM1-COM4 {0x3f8, 0x2f8, 0x3e8, 0x2e8}

https://github.com/bbond007/softmpu/com ... 06fd084e4a

So the new one is already implemented? That sure was fast. I was not sure if it was a work in progress or if the notes on the dev branch meant it was implemented. I guess that is why someone with just the lite version could compile it now Awesome.

I can say that the new UART is working well in Windows 95. Was able to use Netscape to download an IRC client and connect to an undernet server. Just like old times.

bbond007 wrote: ↑Sat Aug 01, 2020 12:38 am The new UART seems to have adversely affected SoftMPU.

I can compile SoftMPU.EXE from github source so maybe I can fix it there.

It seems like its trying to detect the port address and failing. I notice the same issue with dosmid.

"dosmid /COM1" used to work but no longer does, however "dosmid /COM=3F8" does work


SoftMPU_Error.png


EDIT:

This code gets the com port address from BIOS and seems to be failing:

https://github.com/bjt42/softmpu/blob/b ... S.ASM#L372

I have included a copy of SoftMPU that I hard-coded the addresses for COM1-COM4 {0x3f8, 0x2f8, 0x3e8, 0x2e8}

SOFTMPU.ZIP

yeah, these so-called full-featured UARTs aren't so full..

Sorgelig wrote: ↑Sat Aug 01, 2020 7:05 am yeah, these so-called full-featured UARTs aren't so full..

Still, after overcoming the detection glitch, and after further testing, I am happy to report that the new UART implementation works well for SoftMPU so far.

Win 3.11 com-port seem broken though...

SuperBabyHix wrote: ↑Sat Aug 01, 2020 5:11 am I can say that the new UART is working well in Windows 95. Was able to use Netscape to download an IRC client and connect to an undernet server. Just like old times.

Ah Pirch best IRC client outside of Amiga Amirc Nice!

somehow midi stopped to work for me..
even latest released ao486 version doesn't work.. I don't know when it happened..
midilink with its myriads options getting too complicated.
Sigh..

for me ao486_core29_8ad57c2 work with midi (fluidsynth)
and mega mid work with vesa mode (et4000)

Sorgelig wrote: ↑Sat Aug 01, 2020 9:52 am somehow midi stopped to work for me..
even latest released ao486 version doesn't work.. I don't know when it happened..

maybe just try:
#uartmode 0
#midilink FSYNTH
or
#midilink MUNT

and you can see if ts getting serial data... or having any other sort of error while starting...

was something in vhd. Switch to reserved copy fixed the problem.

For me does not work.
Using "dosmid /com=3f8" works fine on this program but, for softMPU do not work.
The params for softMPU I use are: "softmpu /sb:220 /irq:5 /mpu:330 /com:3f8"
If I change 3F8 for com1 (to 4) also don't work.
Any suggest?

Regards.

Sorgelig wrote: ↑Sat Aug 01, 2020 12:26 pm was something in vhd. Switch to reserved copy fixed the problem.

The original unmodified SoftMPU.EXE works again. Thanks!

bbond007 wrote: ↑Sat Aug 01, 2020 8:19 pm

Sorgelig wrote: ↑Sat Aug 01, 2020 12:26 pm was something in vhd. Switch to reserved copy fixed the problem.

The original unmodified SoftMPU.EXE works again. Thanks!

Even small seemed as useless feature not implemented in UART sooner or later becomes a problem. That's why i've used really full-featured 16550 module before. Who needs fifo-less UART you would ask. And then in real use you realize that even BIOS doesn't recognize such UART.
I've added workaround. Hopefully i won't need to be involved more deep in FIFO disabling.

bbond007 wrote: ↑Sat Aug 01, 2020 8:19 pm

Sorgelig wrote: ↑Sat Aug 01, 2020 12:26 pm was something in vhd. Switch to reserved copy fixed the problem.

The original unmodified SoftMPU.EXE works again. Thanks!

Really, not for me

Apolonius wrote: ↑Sun Aug 02, 2020 7:19 am Really, not for me

After testing, under DOS the following seem to work:
SoftMPU
Windows 3.11 & Trumpet 3.0
Qmodem Pro
Procomm+

Windows 95:
Roland Serial MIDI Driver
Dial Up Networking (PPP)

bbond007 wrote: ↑Mon Aug 03, 2020 12:50 am Windows 95:
Roland Serial MIDI Driver
Dial Up Networking (PPP)

Can I just ask what you used for PPP in this instance? Do we still need to use Trumpet or does the built in winsock work now?

Rob.