Ratte

8056 (ported driver) // Detected compiler/packer: microsoft // Detected functions: 288 9370 (last without baytrail) // Detected compiler/packer: microsoft linker (11.0) // Detected functions: 383 9385 (first with baytrail) // Detected compiler/packer: microsoft linker (11.0) // Detected functions: 399 Idea, analyze the difference between version 9370 and 9385. In the next step, implement the changes found in version 8056.

Maybe it makes sense to compare the differences between the last version without Baytrail support (9374) and the first version with Baytrail support (9385) and then reproduce this difference in the early Beta8 (8056) version.

My first attempt to compile the NTOSKRNL_Emu code, giving up is not an option for progress. https://youtu.be/cFAR923LUzo

First of all, thank you for the feedback. I have a question, but maybe the idea is fundamentally wrong, so please don't be angry. On current x64 systems (U)EFI is replacing BIOS (at least more and more often and CSM is also disappearing more and more often). Is it possible to use Windows drivers under x64 that rely on (U)EFI? I found an example of a memory driver on the net that allows direct access to the RAM. Couldn't a driver be written in this way that provides a normal hard disk (or BlockDevice) for Windows and does not access the hardware directly on the other side, but redirects access to (U)EFI? In this way you could then address all storage media such as hard disks (EMMC / SD / NVME / USB). You would no longer have to rely on special drivers. If this type of access were possible, perhaps a similar approach could be used for vga.sys by redirecting to (U)EFI/GOP functions. This approach would certainly also be interesting for modern PCIe systems and WindowsXP x64. Just a few thoughts flying through my head...

BayTrail support (sdbus.inf): Win 8.0 9200 - no Beta 8.1 9374 - no Beta 8.1 9385 - yes (first known version with baytrail support) Win 8.1 9600 - yes --------------------- org. files from iso "Microsoft Windows 8.1 (''Blue'' 6.3.9385.0) x64 & x86" Beta81 Build9385 sdbus sdstor x64 x86.7z

Hi! I've been working with the BayTrail ChipSet and Windows 7 x64 (GPT/EFI) again recently (VEN_8086&DEV_0F14 - emmc / VEN_8086&DEV_0F16 - sdcard). As far as I can see, the chipset was first included in the drivers with Windows 8.1. The packages provided here could not be regularly installed on the device. I made the most recent attempts in the CMD with DEVCON.EXE. I copied the .SYS files to the System32 directory in advance and deactivated the driver signing check when Windows started. This way the drivers could be loaded, but no function could be determined. I am currently searching the Beta8.1 versions for the first signs of BayTrail support. Best wishes and a happy new year.

Hello, I find this post very interesting, I will try the driver once on my hardware. I use an Acer Aspire E11 ES1-111M-C56A netbook with Celeron N2840 (Bay Trail) and 32 GB eMMC (Hynix). I am happy to contribute my experience so far, which has led me to a running Windows 7 installation in "BIOS / MBR" mode. However, my personal goal is a "UEFI / GPT" installation, from which I expect a more stable boot behavior and better boot performance. https://www.win-raid.com/t6835f52-emmc-driver-for-legacy-mode-only-searching-for-acpi-solution.html (broken link) https://winraid.level1techs.com/t/emmc-driver-for-legacy-mode-only-searching-for-acpi-solution/35272 (new link) Maybe you can build a solution for the GPT mode from both sources. As a side note, I would like to mention that in Windows ThinPC (Windows Embedded Standard) there is apparently an SD driver that differs from the normal Windows7 driver and allows booting, for example. Unfortunately, this driver does not support the BayTrail chipset. It would be really great if a solution could be found here. BR Ratte