How to install this on Pentium II w/o FPU Debian without internet connection?

[superfury]

Anyone knows how to install this on a 80386 debian without internet connection? I know some stuff like python is required and that other library, but all I can find is installation tutorials using online repositories that require an internet connection from debian itself?

Is there a way to perform a (manual) offline installation of this on a fresh debian installation without internet connection on debian itself(I'm using Windows and plain disk images to transfer the files in there)?

[superfury]

So, I've used dselect along with the debian 1.3.1 install CD-ROM being inserted in the CD-ROM drive(and mounted) to select and install gcc. It's currently busy installing some extra dev libraries and tools I didn't select before(autoconf etc.).

I've also created a simple .ISO image with the current sandsifter as a zip file, current ,tgz capstone(4.0.1) and the current python(3.8.2), copied it over to the hard disk image on Debian Bo and extracted those into 3 folders.

After installing the basic tools, headers and development libraries(just the standard ones), would it be possible to compile python, then capstone and run Sandsifter on said emulator running Debian Bo(Debian 1.3.1)?

Would the configure script work on that just like that? And ofc compile and run Sandsifter? I remember that someone(I think it was Domas himself, don't remember off the top of my head) said he ran Sandsifter on a 80386? Anyone knows more about how to accomplish this(the exact steps to follow and what commands to type to accomplish this)?

[superfury]

After installing gcc, I now have problems compiling Python on said platform after running configure of it. It says it's missing inttypes.h? (at Include/pyport.h:6, included by Include/Python.h:63). Anyone knows how to solve this?

[Artoria2e5]

inttypes.h is found in XPG issue 5, so it's a new thing from somewhere between 1992 (XPG4) and 1999 (XPG6). Chances are your Debian Bo actually knows nothing about it. You should be able to get away with copying this header from a modern Linux system.

The 386 support on Linux is dropped not that long ago, and you might be able to get away with a 2007 instead of 1997 system. With Debian, it should be "woody". Starting from there you might be able to build a newer gcc, if that is at all needed. See also https://unix.stackexchange.com/questions/304809/highest-version-of-glibc-working-on-actual-386-hardware.

[superfury]

Is there an easy way to get sandsifter installed and running without an internet connection? I've tried it on Debian Bo with it failing said inttypes.h so far.

Anyone has gotten Sandsifter running on such a system (it can now use a Pentium CPU (no FPU) with 128MB RAM and a i430fx motherboard being minimally emulated (just enough to properly post, boot and run the setup of the bios, with slight hardware support(hard reset, memory hole settings, basic PCI BARs(no busmastering DMA))).

I thought I saw somewhere that the i386 can run sandsifter. Anyone knows how to install it on such an offline system(no internet)?

[Artoria2e5]

Are you adding more information with the last comment, or are you just reiterating stuff? If you are going for i586 pentium instead of literally a 80386, you can use Debian 8.0 (Jessie), the last version before the i686 switch in 2016.

Oh and qemu can emulate a pentium with a i440FX. You can probably set up your image there.

[superfury]

Well, it's almost a Pentium. It has the normal non-FPU opcodes implemented, along with most extensions(except machine check and MSRs not being present(always #GP faulting)). I've also just added Pentium Pro emulation(a handful of new opcodes according to ref.x86asm.net coder32 edition). It just has those extra opcodes impemented together with the normal Pentium I features(except as mentioned before).

FPU instructions still aren't implemented at all(and CPUID gives that bit 0 as being cleared). It does support software emulation, though(using said exceptions and bits in CR0). They're NOPs otherwise.

Weirdly enough, Windows 95 detects Pentium I as Pentium, but Pentium Pro as 80486? EAX of CPUID leaf 1 gives 0x0610. That should be correct? (the eflags are as documented) Edit: Windows 95 OSR 2.5 "C" gives an incorrect processor string instead. It gives 4 characters, the first 2 becoming block characters(it can't properly display those, so they become the default block character for undisplayable characters like "
", it's displaying "wn

" to be exact.
being a rectangular standing border around a transparent block character(like Windows XP used to load it's setup from CD-ROM when performing el-torito boot's first stage, before the boot logo displayed)). The remaining two characters seem garbage as well? Edit: With the strange reporting of the CPU in Windows 95, it seems to have been a bug in the CPUID instruction itself. It was checking what CPU it was emulating, which was a Pentium Pro. But it would only check and parse EAX and give results if it was a Pentium instead. Whoops! :s Edit: Windows 95 "C" now properly detects the CPU :D

[superfury]

Since then, I've managed to improve the CPU emulation a bit further, now supporting the Pentium II instruction set and many of the extensions that came with it(except floating point (both FPU and MMX) of course, as well as the Pentium's MCE, the functionality of the MSRs(except SYSENTER MSRs), APIC, MTRR, MCA, PAT and PCE-36), up to bit 19 of the CPUID leaf 1 being otherwise implemented). So it's a very basic Pentium II CPU that's emulated now.

[superfury]

Would Debian Wheezy be enough too? My emulator unfortunately has a limit of 128MB RAM supported because it's using a i430fx chipset.

I'm now downloading the Debian Jessie ISO images(debian-8.11.1-i386-CD-*.iso files). Would that be enough with 128MB RAM and Pentium 2 with the specs mentioned above?

[superfury]

The Debian Jessie ISO CD 1 image seems to fail booting. It gives me a error 01 when trying to perform the CD-ROM boot drive FF identification(int 13h function 4B). That's on the i430fx BIOS I'm using. It says that it's 'maybe' drive FF, then tries drive FF and fails booting(error code (AH)=01h). That happens within the ISOlinux boot loader? The boot loader code says it's starting at drive FFh and proceeds with 'maybe' down to drive 80h, failing on the very first drive(drive FFh)? That's https://repo.or.cz/syslinux.git/blob_plain/778fcea7d4e3e2a595df0a18475d83d008216117:/core/isolinux.asm , search for the word maybe for the point of failure. It should be syslinux 4.03 that's used? ( https://repo.or.cz/syslinux.git/tag/refs/tags/syslinux-4.03 )

[superfury]

Is it possible to run this as a BIOS? I found Baresifter, but that's only for x86_64 processors, not for IA-32 (which is what I'm requiring tests for)? It doesn't have any port to IA-32 yet?

[superfury]

Debian Jessie seems to boot a bit with the new i440fx(w/ 1GB RAM) and the APIC being partly emulated(no APIC -specific IRQs(the local apic timers etc.) supported yet)! :D But it fails to set video mode 314h on the ET4000AX, hanging on needing to press Enter or Space(IRQ1 is disabled on the APIC)?

[superfury]

With the latest 32-bit version of Baresifter and my pre-NX CPU Baresifter patches, I managed to run it to the finish. It's analyzer only found GRP5 /7 non-#UD opcodes, which were throwing page faults due to reading data from memory before properly #UD faulting(#UD had less priority). I also improved the UD0 exception on all processors(up to Pentium II) to be a two-byte opcode without ModR/M(it doesn't have any according to Bochs and Dosbox-X), although that might be unrelated? Page faults also have been improved to proper fault at lower addresses for doubleword operand sizes(including prefetches and PIQ) to no longer report faulting at n+1 and n+2 to be at n+3 incorrectly.