My latest build, has some bugs fixed concerning the OSK not being hidden when disabled and an input menu to apply custom colors to the OSK (font/inactive border/active border and LED font/LED inactive border/LED active border) to customize your OSK to your needs (all colors have the 16 colors from the CGA palette). Square can be used to remove gaming mode key assignments and triangle is used, when selecting a color, to load the default color for the keyboard colors. The same applies to mounted disks, but they unmount the disk, since, by default, there is no disk mounted.
The keyboard works simple:
It has three modes: The mouse mode, the keyboard mode and gaming mode (used for playing games).
- The mouse mode:
The analog stick is mapped for mouse movement in the given direction and speed(speed differences by pulling it to a side more or less only works with joysticks (PSP joystick or joystick on a PC)).
Square, Triangle and Circle are used for left, middle and right mouse button.
The ctrl, alt and shift keys are the same as on a keyboard.
- The keyboard mode:
The analog stick is used to select a block of 4 keys, for a total of 8 directions plus neutral state (not pulled to any direction). The keyboard is mapped like an actual keyboard on the OSK. Pull the analog stick to a direction to select an area (upperleft, up, upperright, left, centered, right, bottomleft, bottom, right are the areas).
The four face buttons (Square, Triangle, Cross and Circle) are used to press a key.
Left is mapped to Ctrl, Right is mapped to Alt, Up is mapped to ctrl and alt together, R is mapped to shift.
L switches between keyboard pages (3 pages total for an entire keyboard).
By pressing down in both mouse and keyboard mode, gaming mode is enabled.
- The gaming mode:
Almost all buttons are directly mapped to key presses. The only exception is SELECT, which exits the gaming mode and returns to the last used mode.
Ctrl is mapped in windows to the PSP's HOME button. This isn't yet supported on the PC, on the PSP it handles the normal program termination menu.
Regardless of the keyboard mappings, on Windows:
- ALT-F4 quits the application.
- F12 toggles fullscreen operations (still buggy, it makes the program hang atm after fullscreen is toggled by SDL_SetVideoMode).
There's one problem with the BIOS from Bochs: It's for at least a 80286+. My emulator emulates a 80186 or 8086 (configurable) atm. 80286 is partly implemented (it's about a 80386 without any 80286 opcodes, real mode will work as a 80186, protected mode will work, without multitasking, 80286+ opcodes and protected mode interrupt support atm). Since the 80286+ isn't done yet, only 8086/80186 is currently selectable in the BIOS Menu. Programs written for a 8086 or 80186 will work, except for the found errors till now.
Any BIOS you can recommend to use for getting my CPU emulation right (which will work on 8086/80186 real mode)? So no 0x0F opcodes, nor any 80286+ opcodes or 32-bit opcodes. It has to be a BIOS that can run on a 80186 or 8086.
This is my latest source code of my 80(1)86 emulation. Anyone knows what's going wrong here? (The CPU8086_OPXX/CPU186_OPXX functions are the actual opcode handlers, in opcodes_80(1)86.c.)
Is there anyone that can answer my question(s) active on this forum? Do you have time peterferrie? Or maybe anyone from the Dosbox/Bochs/QEMU team can help?
Edit: The error is supposed to happen before 0:04:57:44.0.0206 and after 0:03:25:05.4.0105 after looking at it. Anyone can find an error there?
I now got the Turbo PC XT BIOS running up to the point it starts booting the floppy, but the DMA controller seems to go wrong: it doesn't seem to detect correctly when to start or stop. Anyone knows how the DMA controller operates (the differences between the 4 modes (Demand, SIngle, Block, Cascade(not used for transfers)))? How does the TC bits affect this?
Afaik I now have my DMA and floppy controller fully working. After the BIOS starts booting, first sector 0 of floppy #0 is read to 0000:7C00. When MS-DOS tries to load the FAT, it reads sector 19 to address 0x500 (debugging the DMA controller addresses)? After that, it says the disk is not a system disk (MS-DOS 6.22 floppy).
peterferrie wrote:I'll have to investigate later what you're seeing. However, if you see reads to segment 0x70 while running from segment 0x70, t […] Show full quote
I'll have to investigate later what you're seeing. However, if you see reads to segment 0x70 while running from segment 0x70, then that's your problem.
These are the reads that you should see:
9ea0:0 (9 sectors)
690:0 (6)
690:c00 (0x12)
690:3000 (0x12)
690:5400 (0x11)
986:10 (1)
b72:10 (1)
b72:10 (1)
b51:10 (1)
c8b:0 (1)
c8b:200 (0x12)
c8b:2600 (0x12)
c8b:4a00 (0x0c)
b30:10 (1)
My emulator isn't currently loading anything at those locations. Are you actually talking about MS-DOS 3.3 here?
This is the dump log of the very first sector read (after calculation and a INT13 Reset call(function 0)):
So it reads the first FAT entry to ES:BX=0000:0500, not 9EA0:0000. Can you tell me why this happens? As far as I can see at a certain point in the boot loader:
As far as I can see it relocates IO.SYS from segment 0x48D to 0x9DFD(0x203 words before start of VRAM). Anyone can verify if this is correct?
Btw how much memory is installed in your environment? My BIOS returns 640K installed, which, after substracting the IO.SYS calculated information, is used as a relocation segment (segment 0x9DFD for IO.SYS).
When I open MSDOS.SYS in a hex editor, the JMP 7211(bytes E9,0E,72) match the first three bytes of MSDOS.SYS. After that it starts executing NULL bytes (unfilled memory or cleared memory). Anyone can see what's going wrong here?
As mentioned previously, I'm using BOCHS BIOS, which uses the Extended BIOS Area at 9FC0, so all segment values will be shifted a bit. The point of the earlier post was the number of sectors being read.
However, to your most recent question:
I notice that it has something to do with my handling of the "max sector size" byte of the floppy disk read command:
1 FLOPPY.databuffersize = translateSectorSize(FLOPPY.commandbuffer[5]); //Sector size into data buffer! 2 if (!FLOPPY.commandbuffer[5]) //Special case? Use given info! 3 { 4 FLOPPY.databuffersize = FLOPPY.commandbuffer[8]; //Use data length! 5 } 6 FLOPPY.disk_startpos = floppy_LBA(FLOPPY.DOR.DriveNumber, FLOPPY.commandbuffer[3], FLOPPY.commandbuffer[2], FLOPPY.commandbuffer[4]); //The start position, in sectors! 7 FLOPPY_LOG("FLOPPY: Read sector #%i", FLOPPY.disk_startpos) //We're reading this sector! 8 FLOPPY.disk_startpos *= FLOPPY.databuffersize; 9 FLOPPY_LOG("FLOPPY: Requesting transfer for %i sectors.", FLOPPY.commandbuffer[6]); //Transfer this many sectors! 10 FLOPPY.databuffersize *= FLOPPY.commandbuffer[6]; //How many sectors to transfer!
I notice that in the case you mentioned, FLOPPY.commandbuffer[6] contains 0x09 (the AL byte set during the INT13 call, how many sectors to transfer). But the other calls have large values in the amount of sectors to transfer (0x12 in the other cases, 0x08 when reading the boot sector by the BIOS). How should I handle this?
Hmm, the issue appears to be that a loop is timing out while waiting for 3d4 to return some status bits.
Check the ROM disassembly to see it. It's right before the STC instruction.
I've updated the FDC to better represent the command status bits in the MSR (the high 3 bits), depending on the current state of execution (command byte, parameters, data(execution phase? data transfer using DMA or PIO), result and error(essentially the result phase, but with only 1 result byte: ST0)). It now seems to send the commands correctly and retrieves the whole result during read commands (command x6h).
This is my latest executable (run after setting it up (press backspace before the yellow option text disappears after starting it, the controls are as said a few posts back)). Enable BIOS mode and put the BIOS ROM (in my case the Turbo XT BIOS 2.5 and VGA BIOS from fake86 emulator (Tseng BIOS afaik (looking using hex editor says: "This is not } a product of IBM (IBM is a trademark of International Business Machines Corp.) ë[ * Copyright(c)1988 Tseng Laboratories, Inc. 01/10/92 V8.02X", guess it's a Tseng VGA BIOS? Don't know which one exactly.)))
Put the ROMs in ROM/BIOSROM.BIN (Turbo XT BIOS) and ROM/OPTROM.1 (Tseng VGA BIOS).
I've fixed the FDC and DMA. It now correctly loads requested sectors (tested with DMA only). For some reason it doesn't continue to load MS-DOS 3.3? Anyone can see what's going wrong here?
Here's the full emulator with required files (BIOS ROMs, Disk image and settings(BIOS.DAT)). Just run the executable to generate the log in logs/debugger.log (floppy disk is logged to logs/floppy.log and logs/debugger.log(double logging to find errors)). The logs/debugger.log file contains the instructions executed after arriving at the Boot Sector (at 0000:7C00).