Just added a new little thing to the packet server (not released yet, but in the current commits).
It now supports IP blacklisting based on invalid login attempts.

So it will simply keep a counter that starts at 0. Then, for every invalid PPP or text-based login it will increase the counter.
When the setting for max login attempts is reached (in other words: the IP address has invalidly tried to login the set amount of times), it will consider the IP address blacklisted.
Of course, performing a valid login will clear the counter.
The counter for an IP address can also be set to a value less than 0 to whitelist the IP address instead (it won't increase or modify it if that's the case). All attempts in that case will always succeed the checks.

The checks are made during both text-based authentication (username/password if required) and during PPP PAP/CHAP failed/succeeded attempts to login.
Edit: Just fixed a few little bugs with the counter increasing too much when a PAP/CHAP response for a failed login is kept pending (it would increase the counter until hitting the limit for each attempt to send the failed login packet while the client's receiver buffer isn't ready to send the packet back yet). It now instead only increments the counters when the packet is successfully sent to the user as it should (only one increase for each failed attempt).

Just fixed the CHAP challenge identifier for a CHAP challenge response when formulating it to be properly used (instead of leaving it at it's uninitialized value).
So now the CHAP response that's sent back when it can send it back properly has the correct challenge Identifier field.

OK. For fun just added a second virtual serial port to verify UniPCemu's extra second serial control port support.

I found https://freeserialanalyzer.com/ , connected it to the second serial port UniPCemu was connected to and looked at the RTS and DTR lines on it.
I started a simple putty session, connected it to the normal serial port (with the other end connected to UniPCemu's serial port).

Then ran simple commands (AT&S0 and AT&S1), dialed a bit with it, ran telnet to connect to the emulated modem to make it ring and connect.

I see on the second serial port the RTS and DTR lines working as programmed: When it's ringing, RTS starts to set and clear, until picking up (tested using AT&S0=2). I saw it ringing twice (RTS going high, low, high, low, followed by DTR on the second serial port being set(which indicated the DCD line being raised)).
Then hang up using ATH, after which the DTR(DCD line input on the second serial port) gets lowered again.

The first serial port must be working properly as well, seeing as they're the normal inputs as UniPCemu and Dosbox use them as well (although not connected to combined DCD/RI outputs on the modem in the dual serial port configuration).

So that pretty much confirms the dual serial port Hayes modem emulation to be working properly 😁

Hi Superfury,

wanted to try UniPCemu on Switch - yuzu/Ryujinx - unfortunately nothing happens after starting ... can't find any hints how to get it up and running there .. a short guide would be helpful ..

There's a video guide and link to getting started on the manual of the app(wiki).

It's explained for the PC version, but counts for other platforms as well (although there might be a difference where to place the files on different consoles (the root path of the app)).
Mostly place the ROMs according to the manual in the ROM folder, Soundfonts in soundfonts folder, disk images in disks folder.
The hard disks/floppy disks (empty) can be createn from the app itself. CD-ROM images (cue/bin or iso) must be supplies yourself, as do any bootable floppy disks createn with running OSes of course (like Linux/DOS/Windows 9x/NT running inside UniPCemu).

Just found a small bug in the serial mouse initialization when it's not being emulated. In that case, it would allocate another serial port (which it shouldn't). Now, with the latest commits, it's properly handled (thus not allocating extra serial ports for emulation incorrectly).

Just found another issue with the CHAP messages given with the Success/Failure receiving and sending. It was trying to use a length field for the message like with PAP, but CHAP doesn't have such a length field (instead it's start and end is marked by the container size of the CHAP packet header (which contains the Code, ID and Length fields) itself (the Length field to be exact, after substracting the headers fields from it).

Edit: With said bugfixes, managed to get Debian Bo (If I remember the distro correctly) to connect to the server in PPP mode.
IPCP successfully negotiates at least. IPX still unconfirmed (assuming it's compiled into the kernel).
Edit: It seems that IPXCP/IPX isn't supported by the kernel build.
But at least IPCP/IPv4 is working correctly, although I didn't check with ping and other commands yet.
Is anything needed in the ip-up file to prepare the ppp0 device for IPv4 internet?
The local IP address properly points to what the PPP server gives it as the IP address allocated from the host network.
The remote IP address is set to the default gateway of the host of the network.
I don't see ip-up being called though?

Does Debian need commands after IPCP finishes for IPv4 ping etc.?

OK. Just improved the packet server a bit:
- Improved subnetting to be more accurate.
- Added support for the packet server to be login with empty credentials(username/password) when using the ppp protocol. The actual credential-based login will then be done using the PPP protocol's login facilities, if any username is specified in the settings.
This should theoretically allow the non-passive method of PPP (like with Linux) that starts when the server starts sending PPP packets to work properly (as long as empty credentials and the "ppp" protocol is entered during the login prompts to start the ppp service).

Just added some more functionality to the sfdimg and img file support:
- sfdimg variables are now always stored in little-endian format. Although this makes big-endian written files unreadable or unusable, this improves portability if using a big-endian machine using the image format. A method of converting to the new format is by using older versions of the app (up to 2022/09/18 20:46, which isn't released officially yet (just some PS Vita and PSP bugfixes)) to static image format, then using the newer versions of the app to convert it back to the new format (which has everything in stored in little endian format in the file).
- Both sfdimg (dynamic) and static disk images(img files) now support having custom geometries set to them and can convert back and forth to either format (with the new custom CHS parameters remaining intact in both formats).

The newly added custom CHS formats can be specified by having or creating a static disk image, removing any of the metadata text files (if any) and adding a .chs.txt file with the contents of the file being a single row of text with the value "C,H,S", for example "1,2,3" for 1 cylinder, 2 heads per cylinder and 3 sectors per track.

This allows it to boot from custom disk images with non-standard geometries without visible issues.

Edit: OK. Just made a little disk with CHS mode enforced in the BIOS after copying some files over.
FreeDOS's (from the Bochs website) with it's custom geometry boots alright, but somehow the dir command of it still doesn't work properly.
Running software off the second, custom CHS formatted, disk seems to work properly.

Hi superfury,

I've been struggling to get UniPCemu running as basic XT.
So far I have :
A ROM folder with the files
BIOSROM.U18.BIN (original filename BIOS_5160_09MAY86_U18_59X7268_62X0890_27256_F800.BIN)
BIOSROM.U19.BIN (original filename BIOS_5160_09MAY86_U19_62X0819_68X4370_27256_F000.BIN)
VGAROM.BIN (The IBM VGA BIOS... )

in SETTINGS.INI
architecture=0
executionmode=4

when I run it all i get is a dark red screen. Is there some way i can troubleshoot what the emulator is doing or what it doesn't like about this configuration?

edit: There are two versions of the VGA bios out there looks like, basically identical except one is 32K and padded in front with 8k of zeros and the other is 24K with no padding. There is a hardcoded reference to C000 segment in the VGA BIOS so loading the 32k rom at C0000 will put the expansion BIOS at C2000, and will fail to properly set the registers because the register initialization table is hardcoded to C000. I get a little farther now, but i am just seeing '101' on the screen with a blinking cursor and it is not booting the DOS 3.3 diskette I have selected...

GloriousCow wrote on 2022-09-20, 17:16:

Hi superfury, […]
Show full quote

Hi superfury,

I've been struggling to get UniPCemu running as basic XT.
So far I have :
A ROM folder with the files
BIOSROM.U18.BIN (original filename BIOS_5160_09MAY86_U18_59X7268_62X0890_27256_F800.BIN)
BIOSROM.U19.BIN (original filename BIOS_5160_09MAY86_U19_62X0819_68X4370_27256_F000.BIN)
VGAROM.BIN (The IBM VGA BIOS... )

in SETTINGS.INI
architecture=0
executionmode=4

when I run it all i get is a dark red screen. Is there some way i can troubleshoot what the emulator is doing or what it doesn't like about this configuration?

edit: There are two versions of the VGA bios out there looks like, basically identical except one is 32K and padded in front with 8k of zeros and the other is 24K with no padding. There is a hardcoded reference to C000 segment in the VGA BIOS so loading the 32k rom at C0000 will put the expansion BIOS at C2000, and will fail to properly set the registers because the register initialization table is hardcoded to C000. I get a little farther now, but i am just seeing '101' on the screen with a blinking cursor and it is not booting the DOS 3.3 diskette I have selected...

Just ran my own XT BIOS (U18/U19 enforced using the settings menu for BIOS ROM mode set to Enforce normal U-ROMs).
With VGAROM.BIN it runs without issues (other than some 301 error, which is an unknown keyboard error). The display starts up fine.
Could you try with CGA or MDA (doesn't require a ROM other than the BIOS ROMs)? In my case it gives the same results as the VGA ROM (other than the usual CGA color flashes when it's testing the adapter).

If that's not running, perhaps there's an issue with your BIOS ROMs? Are they indeed the correct ROMs (correctly labeled U18/U19 or are they actually reversed (noticed someone having the ROMs somehow reversed in their setup in the past))?

You could check the first instruction it executes by making it start with the debugger. If it's not a JMP instruction, the BIOS ROMs are probably swapped or perhaps corrupted somehow.

I'm using these ROMs with my own emulator so I'm fairly confident they work. Also the '101' is coming from the POST routine, I believe from one of the PIC, timer or DMA tests.

I tried with a CGA and it does do slightly more.
301
640 KB OK
601
ERROR (RESUME = "F1" KEY)

hitting F1 at this point does nothing. I have a DOS3.3 diskette in drive A.

GloriousCow wrote on 2022-09-20, 17:47:

I'm using these ROMs with my own emulator so I'm fairly confident they work. Also the '101' is coming from the POST routine, I b […]
Show full quote

I'm using these ROMs with my own emulator so I'm fairly confident they work. Also the '101' is coming from the POST routine, I believe from one of the PIC, timer or DMA tests.

I tried with a CGA and it does do slightly more.
301
640 KB OK
601
ERROR (RESUME = "F1" KEY)

hitting F1 at this point does nothing. I have a DOS3.3 diskette in drive A.

OK. It didn't give a 601 error in my case. I'll look at that later, when I have some time to check it out.
A quick lookup says it's got something to do with the 'floppy controller card'?

I was getting 601 a lot in my emulator when working on the FDC, yes. I see the A and B indicators go on and off during boot.

I'm on Windows 10, 64 bit, using the 64 bit build of UniPCemu

GloriousCow wrote on 2022-09-20, 18:54:

I was getting 601 a lot in my emulator when working on the FDC, yes. I see the A and B indicators go on and off during boot.

I'm on Windows 10, 64 bit, using the 64 bit build of UniPCemu

Well, it probably shouldn't give that FDC error. Unless there's something undocumented at work at the 82077AA chip that's implemented somehow?
It doesn't give that error in my configuration?
Are the floppy disk drives set to a appropriate size the BIOS accepts? Like 360K?
That's the Floppy A/B without disk type setting in the Manage mounted drives menu.
Although I have them set to 1.44MB formatted tracks (it basically only affects the tracks that are able to be seeked without any disk inserted, since most other operations fail anyways due to no disk being inserted).
Or perhaps the XT-IDE BIOS is doing something to that (since HDDs are added in my case).

superfury wrote on 2022-09-20, 20:53:

Are the floppy disk drives set to a appropriate size the BIOS accepts? Like 360K?
That's the Floppy A/B without disk type setting in the Manage mounted drives menu.

I have them set for 360K, and the DOS disk is a 3.3 diskette. Tried a few other bootable floppies as well.
Can you try running it from a fresh folder and new settings.ini without XT-IDE? maybe you could repro then.

Just removed the XT-IDE ROM.
Now it just gives 101 and seems to hang?
All that's loaded is U18&U19.
Edit: OK.
http://minuszerodegrees.net/5160/post/5160%20 … 20breakdown.htm

With reduced data bus size (8-bit), it hangs at POST 02. So that's the 8253 timer chip timing check failing somehow?
With full data bus size (16-bit), it gives a 101 after the display initializes (POST 03). That's test 12 failing?

You could always still use the Generic Super PC/Turbo XT BIOS, which will work in all cases I normally use it (including cycle-accurate software like 8088 MPH).

Just managed to get it quite a bit faster (some 5% on average) by optimizing all active CPU references to become a simple pointer that's precalculated each time the active CPU variable is loaded. 😁

31% during POST, 25% loading Knoppix, ~20% running Linux after that. (all at 3 MIPS speed being setup in the settings on a i7-4790K CPU@4.0GHz)
So quite a bit faster than it used to be (as each CPU[activeCPU].<something here> is now changed to a simple currentCPU-><something> insteaed).
Edit: Just did the same to the BIU[activeCPU].<something here> references, as they run off the same activeCPU base with BIU structures instead of the CPU(which is the EU) structures. This sped it up slightly more, to 33% speed (during POST clearing RAM).

So it's performing it at roughly 1 MIPS at that point (33% at 3MIPS being rougly 1 MIPS speed, so about 4 MB/s throughput with 32-bit instructions?).
Although task manager in Windows 10 (counting used memory pages as it's clearing the RAM) says rougly 2 MB/s instead?

Just improved the dynamic disk image (sfdimg file)'s headers (both the main image header (in both padded and unpadded formats) and the geometry header (if present)) properly perform in little endian format always, with all data being cross-platform now (instead of relying on the structures being compatible on the used platforms by reading the headers into memory as a block).

So any stuff like padding (with only the first disk image formatted disks using the original header with padding) and now also the endianness of the data stored in the disk image (the sfdimg metadata and it's headers) is always stored cross-platform.
Although the other custom disk image formats (not being a raw image with a text file added to it) don't do this yet (they still assume the used platform is little-endian).