VOGONS


Reply 360 of 591, by mr.cat

User metadata
Rank Member
Rank
Member

OK let's see if I have any better luck with the old 3.3.0 version (on Ubuntu 18.04LTS).
I checked out v3.3.0 from "Stichting-MINIX-Research-Foundation" and launched "bash releasetools/x86_hdimage.sh". Oh wow, I didn't realize that this is from 2014!

EDIT: So far, so good...
The script seems to have built clang++ successfully and going forward without a hitch. It will still take a couple of hours to get to the end.

EDIT2: OK the build script finished without problems. So the conclusion is that you have some problem in your build environment.

EDIT3:
Looks like the x86_cdimage.sh script cannot be directly used with 3.3.0...I guess there have been some changes in these 6 years.
(It will launch if image.defaults and image.functions are present, but will fail with "File is obsolete or flist is out of date"...so I guess that flist needs updating too)

If you want ISO, it's probably easier to just use a more recent version. The first commit that includes x86_cdimage.sh is 69eead77f (that's Sep-2015).

Btw, does your Ubuntu vm have internet access?
I remember I had *some* build fail a while back because of I was offline, but I can't remember if it was this Minix script or maybe something else. One would assume the error message to give some indication about that, though...

Last edited by mr.cat on 2020-12-23, 17:39. Edited 5 times in total.

Reply 361 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++
mr.cat wrote on 2020-12-23, 14:03:
OK let's see if I have any better luck with the old 3.3.0 version (on Ubuntu 18.04LTS). I checked out v3.3.0 from "Stichting-MIN […]
Show full quote

OK let's see if I have any better luck with the old 3.3.0 version (on Ubuntu 18.04LTS).
I checked out v3.3.0 from "Stichting-MINIX-Research-Foundation" and launched "bash releasetools/x86_hdimage.sh". Oh wow, I didn't realize that this is from 2014!

Btw, does your Ubuntu vm have internet access?
I remember I had *some* build fail a while back because of I was offline, but I can't remember if it was this Minix script or maybe something else. One would assume the error message to give some indication about that, though...

It should have internet access, seeing as I cloned the minix repo using git.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 362 of 591, by mr.cat

User metadata
Rank Member
Rank
Member
superfury wrote on 2020-12-23, 14:54:
mr.cat wrote on 2020-12-23, 14:03:
OK let's see if I have any better luck with the old 3.3.0 version (on Ubuntu 18.04LTS). I checked out v3.3.0 from "Stichting-MIN […]
Show full quote

OK let's see if I have any better luck with the old 3.3.0 version (on Ubuntu 18.04LTS).
I checked out v3.3.0 from "Stichting-MINIX-Research-Foundation" and launched "bash releasetools/x86_hdimage.sh". Oh wow, I didn't realize that this is from 2014!

Btw, does your Ubuntu vm have internet access?
I remember I had *some* build fail a while back because of I was offline, but I can't remember if it was this Minix script or maybe something else. One would assume the error message to give some indication about that, though...

It should have internet access, seeing as I cloned the minix repo using git.

OK. I tried running the script while offline, and sure enough it fails...so a working internet is a requirement here, that's good to know.
(When the connection is restored, the script can be run again and it should continue where it was cut off).

EDIT: Gave it a go on a LM20 host (should be quite close to Ubuntu 20), the build fails there too.

Last edited by mr.cat on 2020-12-24, 10:52. Edited 1 time in total.

Reply 363 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Well, the machine was online all along (Latest Ubuntu running under the latest Virtualbox). So that shouldn't be part of the problem?

All I did was executing "git clone URLHERE" followed by "git checkout R3.3.0" and during later tests a "git checkout master".
The only other command executed was the packages installing(and installing Ununtu at the start and a reboot after the packages installing and virtual guest additions).
The compilation fails on said step no matter if it's online or not?

Could it be a Ubuntu version issue after all (the latest being corrupted or something like that)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 364 of 591, by mr.cat

User metadata
Rank Member
Rank
Member
superfury wrote on 2020-12-23, 20:01:
Well, the machine was online all along (Latest Ubuntu running under the latest Virtualbox). So that shouldn't be part of the pro […]
Show full quote

Well, the machine was online all along (Latest Ubuntu running under the latest Virtualbox). So that shouldn't be part of the problem?

All I did was executing "git clone URLHERE" followed by "git checkout R3.3.0" and during later tests a "git checkout master".
The only other command executed was the packages installing(and installing Ununtu at the start and a reboot after the packages installing and virtual guest additions).
The compilation fails on said step no matter if it's online or not?

Could it be a Ubuntu version issue after all (the latest being corrupted or something like that)?

I compared the packages and it seems to be an issue with the new gcc/g++.
You need to install the gcc-7 and g++-7 packages, and issue these commands:
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 7
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 7

to switch to the older version. With the changing to the older compiler, the build could then be continued and it finished ok. There's also version 8, haven't tested with that (EDIT: According to the minix3 Google group, v8 works too).

You can have multiple versions installed at the same time. In that case you can switch the version with update-alternatives, e.g. something like:
sudo update-alternatives --config gcc

EDIT: There are some fixes available for new gcc versions now. See here: https://gist.github.com/Santurysim/1973b8f723 … c9558a23408d469

Last edited by mr.cat on 2021-10-03, 22:45. Edited 2 times in total.

Reply 365 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++
mr.cat wrote on 2020-12-23, 21:37:
I compared the packages and it seems to be an issue with the new gcc/g++. You need to install the gcc-7 and g++-7 packages, and […]
Show full quote
superfury wrote on 2020-12-23, 20:01:
Well, the machine was online all along (Latest Ubuntu running under the latest Virtualbox). So that shouldn't be part of the pro […]
Show full quote

Well, the machine was online all along (Latest Ubuntu running under the latest Virtualbox). So that shouldn't be part of the problem?

All I did was executing "git clone URLHERE" followed by "git checkout R3.3.0" and during later tests a "git checkout master".
The only other command executed was the packages installing(and installing Ununtu at the start and a reboot after the packages installing and virtual guest additions).
The compilation fails on said step no matter if it's online or not?

Could it be a Ubuntu version issue after all (the latest being corrupted or something like that)?

I compared the packages and it seems to be an issue with the new gcc/g++.
You need to install the gcc-7 and g++-7 packages, and issue these commands:
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 7
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 7

to switch to the older version. With the changing to the older compiler, the build could then be continued and it finished ok. There's also version 8, haven't tested with that.

You can have multiple versions installed at the same time. In that case you can switch the version with update-alternatives, e.g. something like:
sudo update-alternatives --config gcc

That seems to work! It's happily continuing now afaics!

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 366 of 591, by mr.cat

User metadata
Rank Member
Rank
Member
superfury wrote on 2020-12-24, 11:53:
mr.cat wrote on 2020-12-23, 21:37:
I compared the packages and it seems to be an issue with the new gcc/g++. You need to install the gcc-7 and g++-7 packages, and […]
Show full quote
superfury wrote on 2020-12-23, 20:01:
Well, the machine was online all along (Latest Ubuntu running under the latest Virtualbox). So that shouldn't be part of the pro […]
Show full quote

Well, the machine was online all along (Latest Ubuntu running under the latest Virtualbox). So that shouldn't be part of the problem?

All I did was executing "git clone URLHERE" followed by "git checkout R3.3.0" and during later tests a "git checkout master".
The only other command executed was the packages installing(and installing Ununtu at the start and a reboot after the packages installing and virtual guest additions).
The compilation fails on said step no matter if it's online or not?

Could it be a Ubuntu version issue after all (the latest being corrupted or something like that)?

I compared the packages and it seems to be an issue with the new gcc/g++.
You need to install the gcc-7 and g++-7 packages, and issue these commands:
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 7
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 7

to switch to the older version. With the changing to the older compiler, the build could then be continued and it finished ok. There's also version 8, haven't tested with that.

You can have multiple versions installed at the same time. In that case you can switch the version with update-alternatives, e.g. something like:
sudo update-alternatives --config gcc

That seems to work! It's happily continuing now afaics!

Great! There's also the possibility to patch the Minix source to make it work with the newer compiler, since that error seemed like there's just a cast missing in there.
But there could more problems than just that, maybe better to leave that to Minix folks anyway (seems to be a well known issue, see the minix3 Google group for gory details).

Last edited by mr.cat on 2020-12-25, 14:22. Edited 1 time in total.

Reply 367 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Eventually failed because of hard disk data shortage.

Now need to create a 40GB HDD to move it to and recompile... 😖

Edit: It compiled and generated the ISO disk image without issues! 😁
Now I have a valid base for finding the issues?

Now I can use addr2line for finding the code locations?

This is what happens on the Master branch:

19-Minix 3.4.0 boot crash.jpg
Filename
19-Minix 3.4.0 boot crash.jpg
File size
52.76 KiB
Views
1530 views
File comment
Crash on the Minix Master branch
File license
Fair use/fair dealing exception

Even with telnet connected, nothing is logged?

Edit: Although, it might have sent something, but since Windows 10's loopback adapter(127.0.0.1) doesn't work properly with a raw TCP connection, it will receive junk instead of the actual sent data(I remember it being some byte value that kept getting received for any byte that's sent instead of the actual byte that's sent).
Although said issue won't happen when it's using a non-loopback adapter connection(like though the public WAN IP address back to the same computer and other instance of UniPCemu, Dosbox or whatever is connected to the TCP server).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 368 of 591, by mr.cat

User metadata
Rank Member
Rank
Member
superfury wrote on 2020-12-24, 14:38:

Edit: It compiled and generated the ISO disk image without issues! 😁
Now I have a valid base for finding the issues?

Now I can use addr2line for finding the code locations?

Minix looks like a nice match for your particular use-case 😁

Never used addr2line much, here are some hints:
https://stackoverflow.com/questions/7648642/h … ommand-in-linux

The -f switch seems useful, but idk about that comment about offsets...

Reply 369 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Managed to improve the connection some and fix some bugs with it.

When connecting to a TCP server(making a TCP connection) as a client(dial-up modem dialling) it now won't count the connection as established instead of failing to make a connection(this was due to an incorrect result code when failing to establish a TCP connection). So dialing an invalid address will now no longer make the serial modem(or pseudo-client for a passthrough connection) think it's connected(while in reality it isn't).

I also added two new options to the passthrough connection. The first is a simple sending of the DTR/RTS signal to the other side(using Dosbox's protocol 0xFF escape). Said signal is the ANDed with UniPCemu's connected status in much the same way on a receiving UniPCemu connected. The signals mentioned before are simply ANDed with said bits for their effective results on the DSR/CTS inputs to the UART.
RTS is completely ignored for being able to receive in these new modes.
The second mode is like the first one, but it dials out to the first entry in the phone book(without command parsing and ignoring (stuff like ; etc.), although ip:port is still interpreted in the same way(using 12 digits and a variable sized port number)) whenever DTR is raised(hanging up and redialing when raised again will lower the other side(in the second of those mode) and will disconnect and reconnect(like the ATHDT0 command) whenever becoming high again.

I also added a settings menu option to change the passthrough mode(between the mentioned four modes(which includes the normal modem mode as the first mode)). This setting requires a emulator restart to apply(due to switching modem emulation modes).

When the settings menu sees that the modem is put in a passthrough mode, it will show a new option. This option is the connect/disconnect option. It will allow effectively dialing out to an inputted entry like the phonebook(but using normal text input, using the keyboard(Direct Input mode) or OSK in UniPCemu, instead of a setting of the loaded settings(not stored)). Once confirmed, it will make the modem in passthrough mode dial said address. That's a normal IP:port address, or alternatively an address like "google.com:80". The slash-character is allowed as well(besides alphanumeric, colon and dot).
It's function can also be used to hang up the connection when connected (since the DTR signal lowering doesn't do this).

So basically it's emulated what Dosbox does as well, within UniPCemu's constraints(except telnet protocol, special delays and having a forced transparent/non-local setting(both disabled effectively) as far as I can see from the code/manuals of Dosbox). Also a slight difference on the masking instead of plain receiving of the 0xFF parameter on the connected line with the connected status. Although that shouldn't be a problem?
Also, the 0xFF break bit is stored, but currently unused by both the modem and UART emulation. This is mainly because I don't know how this works in actual hardware.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 370 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just added the break signal transmitting and receiving on the UART and modem functionality.

It will still only trigger a break error on the UART when the signal goes high and doesn't retrigger when it stays high for an unspecified amount of time.

While break is active, the TCP connection won't receive data other than the status lines. Any other data received is discarded(since the RxD line is pulled to logical "0", nothing can be received anyways, according to the specs).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 371 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just modified break signal handing a bit.
When the modem module receives a break signal update, it will check the signal's break line(like DTR and RTS). When the signal goes high(not when it stays high), the signal is latched (which will cause it to report to the UART when the input buffers are drained). While the latch is sent, no data is received anymore until the input buffers drain empty and the UART starts receiving the 'break' data byte from the serial modem(normal data transfer). Said receiving clears the flag, which will allow it to be set again by going from low to high (as well as re-enabling the receiving of the TCP data). This latch is used during the modem status register updates. Said latch will set the bit returned when updating it, provided that the input buffers have been drained empty (so all data before the trigger is received).

The UART still handles the signal by latching it until lowered (through the modem status register's fifth input bit), but instead of just putting a 0x00 byte in the receiver buffer directly, it will start a new receive cycle, receiving what's read from the data read function(which for the case of the drained buffers with trigger set will clear the trigger and give the 0x00 byte, which is what's actually received on the RxD line(together with parity and stop bits)). Starting said cycle will also set the accompanying error bits(bits 4 and 3), with bit 0 being set when the transfer completes.

So in that way, the modem should always properly 'receive' the trigger, instead of (when timing goes weird or not enough in sync with TCP input) skipping the input being received on the UART.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 372 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Found another bug in the connection code(noticed it when trying Rise of the Triad). It was filling the modem's receiver buffer with a response to handle, causing it to constantly receive data, while it in fact shouldn't(there was nothing to receive).
That's because the checks for receiving have two parts: the receiver buffer for the modem(which is used in this case) and receiver buffer for the responses(which was filled, reporting that it got data to receive, but never received).
So the UART tried to receive data, which the modem couldn't receive, as the only used buffer(the connected buffer) wasn't filled, causing the normal received data be interleaved with lots of 0x00 bytes being received, instead of proper RxD line silence!

Edit: Confirmed the connection properly working now! 😁

So now full null modem connection is supported in UniPCemu's current git version.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 373 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just managed to fix an issue with UniPCemu's RCR 32-bit instruction shift amount. It was performing modulo 33 instead of just masking the lower 5 bits.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 374 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Noticed something weird with the mouse when booting up the UniPCemu windows guest. Somehow, the horizontal movement ended up at around negative 4 billion mm. The mickey counters were at around -4000 both on the x and y axis, which is a ridiculous negative movement? Perhaps an SDL issue or a buffer overflow?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 375 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Eventually just implemented seperate grayscale modes. It can now act based on either luminance or averaged RGB values.

After implementing the Dosbox-style DAC (which was just a few minor changes), I've then started implementing the AT&T 20C490 DAC into the Tseng chipsets.
WhatVGA eventually ran all tests without much issues (although a few small graphical ones, perhaps due to CPU issues?). The only one that was giving some trouble was the 24BPP true color mode (some scanlines ending up on the next line).

Eventually gave Windows 95 OSR 2.5 ("C") a go with the new DAC emulation. It immediately could use all DAC modes except the true color (24BPP) mode.
Then I found out what was causing it to crash on it: the precalcs used for horizontal and vertical timing caused it to create such large horizontal timings that the inputs to the precalcs went out of the range it was originally intended for!
Thus I increased the buffers a bit to be on the safe side (8x larger buffers). Now, Windows 95 properly renders itself in 24BPP 640x480 true color glory! 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 376 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just was increasing accuracy for the other DAC chips (UMC 70C178 and Siera SC11487), when I noticed some weird documentation on WhatVGA's part:
- The SC11487 chip description on the register mentions the UMC 70C178 and describes the Sierra SC11487 behaviour with regards to reads and writes.
- The UMC chip is mentioned further down, with most of the description matching the SC11487 chip description. There's one difference there, though: it's supposed to return to normal mode (DAC mask register accesses) when the register is written.

But when the DAC mask register is written, looking at the AT&T 20C490/493 documentation's identifcation routine, this will cause said routine to identify the chip as a 49X device(to be exact a 491 or 492 device of said chipsets). So the only correct behaviour should be the SC11487 without the low 5 bits as mentioned at the top of the WhatVGA documentation's RAMDAC.TXT document, thus staying in command mode until one of the other registers(other than port 3C6's command register/DAC Mask register) is read/written.
That's obviously an error in the WhatVGA documentation. In fact, said entry on the UMC UM70C178 only adds a description of the lower 5 bits, with the rest of the chip explained at the SC 11487 part of the documentation in the WhatVGA document.

So it's indeed correct that Dosbox's implementation is detected a UMC 70C178, as that's exactly the register it's emulating when combining said information in the documents on the 3 chips(sierra and AT&T's own documentation and WhatVGA for the UMC chip, as I can't seem to find the chip's documentation anywhere on the net using Google) UniPCemu now emulates!

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 377 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... My Minix 3.3.0's compiled CD-ROM has different results with the latest bugfixes commits of UniPCemu:

vm(8): panic: vm: boot process load of process rs (ep=2) failed

Then it follows with a stack trace etc.

Interesting!

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 378 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm.... Running the DAC gamma correction test of WhatVGA gives weird results?

The red,green,blue colors are broken into four repeating ranges?
Edit: Hmmm.... The DAC should have been written with 8-bit values in the LUT, but it looks like it's only 6-bit somehow?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 379 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've added some information on the manual's controls page with information on how to use the light pen inputs on the CGA/EGA graphics cards (afaik UniPCemu is actually the only emulator supporting this functionality?).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io