The WIN32 configuration for the cdrom was not closing the image file on
eject. This left the handle open while Bochs was running, not allowing
the image file to be modified.
This improves and enhances the floppy emulation.
This adds the ability to specify a controller type.
This adds all but one, known, controller command.
This fixes the format command. Issue #123
This fixes the error with older Windows guests.
When the user presses the "Reset" button on the gui ribbon, we need to
clear the active status of all statusbar items or they remain set after
the reset occurs.
This is mentioned in issue https://github.com/bochs-emu/Bochs/issues/136
This allows you to change the CD-ROM via the Bochs Ribbon, as well as
properly "ejecting" a CD from the guest.
Before the CD path would change, but the guest (tested with WinXP and
DOS as guests) would not see the change.
This fix simulates an open tray and then a closed tray for all CD
changes.
avoid using ull modifyer for consts, use BX_CONST64() instead
move definitions from header file to cpp file when possible
add 'const' modifyer for obviosly const methods and pointers
This adds support for the UFI_SEND_DIAGNOSTIC command in USB_FLOPPY.CC
and
This changes the list of defines to enum to match the current changes
made to recent files.
This fixes the CD-ROM hardware by making sure the `drive_ready` flag is
zero after an `ATAPI_DEVICE_RESET` command. As far as I know, no other
Guest needed this fix except for the TEAC-CDI driver referred to below.
This also adds an assumption fix so that the TEAC_CDI driver will work.
The TEAC_CDI driver relies on the fact that the TEAC drive it is
designed for, sets the `interrupt reason` register (`sector count`
register) after the `ATAPI_IDENTIFY` command is issued. It uses this
`i_o` bit of this register to determine the direction of transfer for
the 0xA1 command, even though this is a read-only direction command.
Through other tests, I see no other Guests effected by this addition.
I also added a few minor syntax modifications, tab spacing, and
comments. The DEBUG out string will display the ATAPI command as well as
the 0xA0 command.
This PR adds the ability to choose which companion controller the EHCI
uses.
`#usb_ehci: enabled=1, companion=uhci`
`#usb_ehci: enabled=1, companion=ohci`
UHCI is enabled by default:
`#usb_ehci: enabled=1`
This breaks up `usb_ohci.cc/h` into `usb_ohci.cc/h` and `ohci_core.cc/h`
to be like the existing `usb_uhci.cc/h` and `uhci_core.cc/h`.
This adds the ability to define a Port Routing string in the
`HcspPortRoute` register, and is optional via the `EHCI_PORT_ROUTE`
define.
Currently `EHCI_N_CC` and `EHCI_N_PCC` must remain as currently set (3
and 2 respectively), however with a little more work, I think these can
be modified and have up to 7 companion controllers with more ports per
companion, as long as the combined total is <= 15 total ports.
Please verify the `Makefile.in` changes. I do not use GCC and can not
verify it is correct.
Made all devices pass USB 2.0 Compliance on WinXP (old version of the
compliance test).
USB Hub still needs a little work to be in complete compliance.
Fixed potential bug in EHCI to UHCI hand-off.
Fixed compilation error with Floppy CB/CBI emulation.
Minor syntax fixes (tabulation, old irrelevant comments)
MSD serial numbers must be 12 chars.
Added to CHANGES file
This changes a BX_INFO to a BX_DEBUG. It does not needed to be a
BX_INFO.
Second, this adds (very) minimal support for SCSI command 0xAC.
When emulating a .iso image via USB CD-ROM on Win10, without this
command, the emulation freezes when trying to access the CD-ROM. I don't
know if it is Bochs or Win10. I think Win10 expects the command to work,
or Bochs is not failing correctly.
This PR simply adds code to acknowledge the command and returns a zero
length report. This SCSI (MMC) specification states that a zero length
report is allowed.
The 8 byte header is returned, but the header indicates a zero byte
return: No report segments returned.
This seems to keep Win10 from freezing at USB CD-ROM device access time.
The code also BX_DEBUG's the command sent to the "controller", for
future use when adding the actual support of the command.
This PR allows larger VHD image files. The size in question doesn't
necessarily mean the size of the VHD file on disk. The size is the total
size of the image emulated. This total size is in question.
Without this patch, the total size allowed is 65535 * 16 * 255, or
roughly 32gig.
With this patch, the total size is calculated by who the creator of the
image is, what the CHS values are, and possibly a total size of up to a
limit of 2TB.
Since the original code was ported from QEMU, I ported an updated QEMU
code snippet.
https://gitlab.com/qemu-project/qemu/-/blob/master/block/vpc.c?ref_type=heads#L305
This PR now allows VHD image files with a total size emulated less than
or equal to 2TB.
This improves the detection of the default speed of a device when given
in bochsrc.
It will first get the max speed of the port given. For example, uhci and
ohci will return FULL, ehci will return HIGH.
xHCI will return SUPER if the port is a super-speed port, else it will
return HIGH.
Then it will compare this with the max speed allowed for that device,
returning the highest common speed.
Of course, if the speed option is given, the above is overwritten by the
specified speed.
Both checks are still performed on the result.
1) does device allow the result speed?
2) does the controller allow the result speed?
This adds three additional checks to make sure the Guest is working
correctly.
- checks that the guest allocated the Scratchpad Area. If left zero
(NULL) the controller may access low memory.
- checks that the guest uses correct segment sizes in the interrupter
ring(s)
- checks the burst size value given to be within normal range
This also adds an internal register value for the HcCrcr (Command Ring
Control) register. Since this register reads zero by the Guest, we keep
an internal value so that the emulation can read the value, internally.
This is for features soon to be released.
Minor other syntax/comment changes (misspelled word, etc)
Checked with WinXP, Win7, and Win10
This fixes zero length packet handling.
See the following example that requests 128 bytes:
```
SETUP(8)
IN(64)
IN(64)
STATUS(0)
```
The current code erroneously assumes that there are no more IN packets
after the first two 64-byte packets.
However, what happens with the following:
```
SETUP(8)
IN(64)
IN(64)
IN(64) <--- current code assumes this will be, and expects a STATUS packet
STATUS(0)
```
Currently, the third IN(64) above will result in a coding error because
the code is expecting the STATUS packet, not another IN packet.
The "controller" must allow for more packets than expected, returning a
short packet detect on the third IN(64) packet shown above, actually
returning zero bytes, hence the Short Packet Detect.
This patch was tested on WinXP, Win7, and Win10.
The check for the amount of byte transferred in one frame time was done
before the update of the vertical pointer in the current Queue of the
last executed TD. Therefore, on the next frame time, the last executed
TD was being "executed" again. The check has now been moved to the top
of the loop.
