MiSTer FPGA Forum

Posted: **Mon Aug 03, 2020 7:02 am**

robng15 wrote: ↑Mon Aug 03, 2020 6:48 am 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?

The built in Dial Up Networking for Win95 OSR2 and Trumpet 3.0 for Windows 3.11

Posted: **Mon Aug 03, 2020 8:06 am**

bbond007 wrote: ↑Mon Aug 03, 2020 7:02 am
robng15 wrote: ↑Mon Aug 03, 2020 6:48 am 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?
The built in Dial Up Networking for Win95 OSR2 and Trumpet 3.0 for Windows 3.11

Many thanks for your response. Will have to update to OSR2 I guess.

Posted: **Mon Aug 03, 2020 8:26 am**

I almost forgot, I use this modem .inf for Win95. Maybe that helps...

mdmcisco.zip: (1.23 KiB) Downloaded 307 times

Posted: **Mon Aug 03, 2020 7:24 pm**

Would it be possible to make the uart bios replaceable, like the system and video bioses? That way, the current one could be used, by most people, but, the possibility to use the old one would be available, without needing the more expensive dev tools to compile. I also wonder if this would work for other components that have bios files, available, possibly saving room for adding things like ethernet card and cdrom? (like the other cd based cores do)

Edit: I just realized that this wouldn't necessarily save room on the fpga, since only the digital logic is recreated, in the fpga itself, but, it still should be possible to remove bios type data from the core, and, have it loadable, this way, also making it possible to provide bios changes, without a full core recompile.

Posted: **Mon Aug 03, 2020 7:42 pm**

If there were a fixed-and-common interface to all code, maybe...but there isn't.

Posted: **Mon Aug 03, 2020 8:04 pm**

bbond007 wrote: ↑Mon Aug 03, 2020 8:26 am I almost forgot, I use this modem .inf for Win95. Maybe that helps...

mdmcisco.zip

Thank you for sharing that modem driver!

It works when I use the "Null Modem Cable" device from that driver. I just set up a dial up ppp connection using the Windows 95 internet connection wizard. I entered 1111111111 as phone number, I had to ensure that only TCP/IP protocol was selected for the Dial Up adapter, and NETBEUI etc. was disabled. I use 192.168.0.254 as fixed IP and 8.8.8.8 as DNS.

Holy moly, I am now online with my MiSTer using ao486 Cache35, Win95 OSR 2

: IMG_1344.jpeg (73.26 KiB) Viewed 11379 times

Posted: **Mon Aug 03, 2020 8:31 pm**

https://github.com/tenox7/wrp

Thank me later.

Posted: **Mon Aug 03, 2020 8:44 pm**

rsn8887 wrote: ↑Mon Aug 03, 2020 8:04 pm
bbond007 wrote: ↑Mon Aug 03, 2020 8:26 am I almost forgot, I use this modem .inf for Win95. Maybe that helps...

mdmcisco.zip
Thank you for sharing that modem driver!

It works when I use the "Null Modem Cable" device from that driver. I just set up a dial up ppp connection using the Windows 95 internet connection wizard. I entered 1111111111 as phone number, I had to ensure that only TCP/IP protocol was selected for the Dial Up adapter, and NETBEUI etc. was disabled. I use 192.168.0.254 as fixed IP and 8.8.8.8 as DNS.

Holy moly, I am now online with my MiSTer using ao486 Cache35, Win95 OSR 2

IMG_1344.jpeg

Are you just using the built-in networking device for this (not like an external modem or something)?? This is really awesome!

Posted: **Mon Aug 03, 2020 10:39 pm**

rsn8887 wrote: ↑Mon Aug 03, 2020 8:04 pm
bbond007 wrote: ↑Mon Aug 03, 2020 8:26 am I almost forgot, I use this modem .inf for Win95. Maybe that helps...

mdmcisco.zip
Thank you for sharing that modem driver!

It works when I use the "Null Modem Cable" device from that driver. I just set up a dial up ppp connection using the Windows 95 internet connection wizard. I entered 1111111111 as phone number, I had to ensure that only TCP/IP protocol was selected for the Dial Up adapter, and NETBEUI etc. was disabled. I use 192.168.0.254 as fixed IP and 8.8.8.8 as DNS.

Holy moly, I am now online with my MiSTer using ao486 Cache35, Win95 OSR 2

IMG_1344.jpeg

Any other tips here? Windows just complains that COM1 is in use by another telephony device. In MiSTer menu I have PPP selected. I see a COM1, I have it sent to 115200, 8N1. I try to dial and it immediately says another device is using the COM port.

Edit: I am one step closer. I now have it "Dialing" but it never completes.

Posted: **Tue Aug 04, 2020 12:28 am**

jrronimo wrote: ↑Mon Aug 03, 2020 8:44 pm
rsn8887 wrote: ↑Mon Aug 03, 2020 8:04 pm
bbond007 wrote: ↑Mon Aug 03, 2020 8:26 am I almost forgot, I use this modem .inf for Win95. Maybe that helps...

mdmcisco.zip
Thank you for sharing that modem driver!

It works when I use the "Null Modem Cable" device from that driver. I just set up a dial up ppp connection using the Windows 95 internet connection wizard. I entered 1111111111 as phone number, I had to ensure that only TCP/IP protocol was selected for the Dial Up adapter, and NETBEUI etc. was disabled. I use 192.168.0.254 as fixed IP and 8.8.8.8 as DNS.

Holy moly, I am now online with my MiSTer using ao486 Cache35, Win95 OSR 2

IMG_1344.jpeg
Are you just using the built-in networking device for this (not like an external modem or something)?? This is really awesome!

Yes it just works with that nullmodem driver from bbond007 and UART set to PPP. It takes forever to „dial“ but then it is fine. No external modem needed or anything. However most modern webpages don’t display on IE 4.0 because the browser is so ancient and complains frequently about JavaScript errors and encryption errors.

Posted: **Tue Aug 04, 2020 6:00 am**

rsn8887 wrote: ↑Tue Aug 04, 2020 12:28 am It takes forever to „dial“ but then it is fine.

Yes it does take a while but not forever...

I always test with http://www.aminet.net

They tend to keep the HTML retro.

Posted: **Tue Aug 04, 2020 8:55 am**

The Sierra games don't work with MT32 without SOFTMPU. Displays the error "Unable to initialize audio hardware". Tested with SQ3 and LSL1.

Posted: **Tue Aug 04, 2020 6:40 pm**

The new 30x UART option in the latest build does not seem as reliable or as fast as the 10x option in the previous builds. It also disconnects quite often from PPP.

Posted: **Tue Aug 04, 2020 8:47 pm**

skywalky wrote: ↑Tue Aug 04, 2020 8:55 am The Sierra games don't work with MT32 without SOFTMPU. Displays the error "Unable to initialize audio hardware". Tested with SQ3 and LSL1.

With Cache37 there is now hard MPU.

Posted: **Tue Aug 04, 2020 9:12 pm**

Caldor wrote: ↑Tue Aug 04, 2020 8:47 pm
skywalky wrote: ↑Tue Aug 04, 2020 8:55 am The Sierra games don't work with MT32 without SOFTMPU. Displays the error "Unable to initialize audio hardware". Tested with SQ3 and LSL1.
With Cache37 there is now hard FPU.

Hard MPU, not FPU. I know that was probably just a typo, but didn't want to get someone's hopes up. Some games require intelligent mode MPU, which the current hard mpu implementation is not. Those games will still require SoftMPU. Space Quest 3 is one of those games. Here is a list of others: https://github.com/bjt42/softmpu/wiki/C ... Mode-Games

Posted: **Tue Aug 04, 2020 9:41 pm**

SuperBabyHix wrote: ↑Tue Aug 04, 2020 9:12 pm
Caldor wrote: ↑Tue Aug 04, 2020 8:47 pm
skywalky wrote: ↑Tue Aug 04, 2020 8:55 am The Sierra games don't work with MT32 without SOFTMPU. Displays the error "Unable to initialize audio hardware". Tested with SQ3 and LSL1.
With Cache37 there is now hard FPU.
Hard MPU, not FPU. I know that was probably just a typo, but didn't want to get someone's hopes up. Some games require intelligent mode MPU, which the current hard mpu implementation is not. Those games will still require SoftMPU. Space Quest 3 is one of those games. Here is a list of others: https://github.com/bjt42/softmpu/wiki/C ... Mode-Games

Ahh, okay. I do remember intelligent MPU being mentioned before.

Posted: **Wed Aug 05, 2020 2:54 am**

Caldor wrote: ↑Tue Aug 04, 2020 9:41 pm Ahh, okay. I do remember intelligent MPU being mentioned before.

Yes, and for those games you should now use:

Code: Select all

SOFTMPU.EXE /SB:220 /IRQ:5 /MPU:330

Posted: **Wed Aug 12, 2020 12:04 am**

Sorgelig wrote: ↑Sun Aug 02, 2020 1:40 am 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.

Terminal programs such as Qmodem Pro (1.0) and ProcomPlus (2.01) were working with the new UART up to commit 9c63fe4.
There seems to be some regression in the commits on Aug 10, 2020 as these terminal programs stopped working after the build based on commit 100432e.

I am testing with UART : Console & UART : MIDI / Remote / TCP

I understand this is work in progress but I thought it might be important to report a (possible) regression asap.

Thanks

Posted: **Wed Aug 12, 2020 3:54 am**

there were some commits after that which may fix the problem.
Also some commits in Main

Posted: **Wed Aug 12, 2020 4:58 am**

Sorgelig wrote: ↑Wed Aug 12, 2020 3:54 am there were some commits after that which may fix the problem.
Also some commits in Main

I am up to date but will double check everything, 9c63fe4 seems to be the last build that worked correctly with these terminal programs.

Posted: **Wed Aug 12, 2020 7:37 am**

MIDI mode in ao486 now uses MIDI base clock rate (1.5MHz instead of 1.832MHz). So 38400 baud is actually 31250 now (standard MIDI rate).
You have to use PPP or Console mode if you want standard baud rates.

Posted: **Wed Aug 12, 2020 7:42 am**

Just tested dialup in Win95 on 3Mbps (30x) speed - works fine.

Posted: **Wed Aug 12, 2020 1:33 pm**

Didn't the fake 'modem' require MIDI, which means bauds will be messed up?

Posted: **Wed Aug 12, 2020 7:50 pm**

MIDI is only for MIDI.

Posted: **Wed Aug 12, 2020 7:59 pm**

rhester72 wrote: ↑Wed Aug 12, 2020 1:33 pm Didn't the fake 'modem' require MIDI, which means bauds will be messed up?

Yes

Posted: **Wed Aug 12, 2020 8:18 pm**

bbond007 wrote: ↑Wed Aug 12, 2020 7:59 pm
rhester72 wrote: ↑Wed Aug 12, 2020 1:33 pm Didn't the fake 'modem' require MIDI, which means bauds will be messed up?
Yes

This is definitely incorrect. MIDI has nothing to do with dialup.
PPP is what should be used for dialup. It has special option for high-speed (30x) connection.

Posted: **Wed Aug 12, 2020 8:34 pm**

Sorgelig wrote: ↑Wed Aug 12, 2020 8:18 pm This is definitely incorrect. MIDI has nothing to do with dialup.
PPP is what should be used for dialup. It has special option for high-speed (30x) connection.

This is a BBS dialup (with terminal software) which was popular before PPP...

There are a handful of users who really like this feature and use it frequently.

I fell like maybe it is just a presentation issue and maybe that option would be more appropriate along side the OSD PPP, Console, and MIDI options - rather than under MIDI.

Posted: **Wed Aug 12, 2020 8:47 pm**

Sorgelig wrote: ↑Wed Aug 12, 2020 8:18 pm
bbond007 wrote: ↑Wed Aug 12, 2020 7:59 pm
rhester72 wrote: ↑Wed Aug 12, 2020 1:33 pm Didn't the fake 'modem' require MIDI, which means bauds will be messed up?
Yes
This is definitely incorrect. MIDI has nothing to do with dialup.
PPP is what should be used for dialup. It has special option for high-speed (30x) connection.

Actually, it worked exactly as the C64 described at the bottom of this wiki article:

https://github.com/MiSTer-devel/Main_Mi ... rted-cores

I use Procomm Plus in DOS on a regular basis to 'dial out' to various Internet BBSes, nothing to do with PPP (and long predates it).

Posted: **Wed Aug 12, 2020 8:48 pm**

Well, MIDI mode still can be used for dialup, just linux side should be corrected as the whole line of baud rates in MIDI mode is shifted so 38400 on core side is 31250 on linux side. 115200 on core side should be 93750 on linux side.
But i think it's confusing to use MIDI mode for dialup.

Btw, about dialup: in PPP mode using null modem in Windows, there is a long waiting time when dialing. Probably dialing app waits some specific to modem answers. Would be good to tweak that. Not sure if pppd can mimic the modem handshake.

Posted: **Wed Aug 12, 2020 9:34 pm**

Sorgelig wrote: ↑Wed Aug 12, 2020 8:48 pm But i think it's confusing to use MIDI mode for dialup.

I agree but I think that is a presentation issue that can be addressed in the OSD, and don't think it is necessary to separate it from midilink.exe into its own exe. Maybe I could rename the project MidiModem

Sorgelig wrote: ↑Wed Aug 12, 2020 8:48 pm Btw, about dialup: in PPP mode using null modem in Windows, there is a long waiting time when dialing. Probably dialing app waits some specific to modem answers. Would be good to tweak that. Not sure if pppd can mimic the modem handshake.

I have notice that too...

Sorgelig wrote: ↑Wed Aug 12, 2020 8:48 pm Well, MIDI mode still can be used for dialup, just linux side should be corrected as the whole line of baud rates in MIDI mode is shifted so 38400 on core side is 31250 on linux side. 115200 on core side should be 93750 on linux side.

Ok, I set TCP_BAUD = 93750.

ProcomPlus 2.01 no longer even loads... It hangs on the screen "INITIALIZING" so this I would consider a regression after build 9c63fe4.
Qmodem Pro 1.0 loads but no data is transmitted @ 115200.

If I set TCP_BAUD = 31520 and set QmodemPro to 38400 then it does work.
46875 & 57600 in QmodemPro also seems to work...

MiSTer FPGA Forum

Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?

Re: Why OpenCore Plus UART?