When the conversational boot is waiting for input it uses a BLBC instruction to read the DUART status register and test the RXR bit. This generates an unaligned longword read in Qbus I/O space (Yuk!). I realised that the code to read unaligned data in vax_mmu is broken. It attempts to read the aligned longwords that the data spans, but there was no code to convert the unaligned pa passed in to it's aligned form, thus the wrong bytes are returned and the BLBC never sees the RXR bit.
The vertical sync interrupt generated in vc_svc() was too slow for Ultrix. The driver enables interrupts and then calls DELAY(20000), which I guess is 20ms. This translates to about 10000 simulated instructions, but tmxr_poll works out at ~75000 instructions. I've added a new unit to simulate just the vsync interrupts activating every 8000 instructions.
This approach will completely disable the ability to idle while the QVSS device is enabled.
Prior fix for cursor tracking allowed this to now be observed.
The description of the prior change should have been:
The status bits need to be set in the upper byte of the DUART receiver buffer. This is not mentioned in the DEC manual but I found a Phillips datasheet for the 2681 chip, which has a small footnote about it.
Show IOSPACE doesn't always get the number of devices right due to device creativity.
o The distinction between UNIT and DEVICE has blurred
o MUX devices merge several physical devices into one device/unit
o Dynamic device sizing has made things more volatile.
This edit solves the problem for SHOW IOSPACE by adding an (optional) word to the DIBs.
The word contains the amount of IO space consumed by each instance of the physical device that's being emulated.
E.G., if it's a DZ11, the device is the DZ11 module, or 8 lines, even though the MUX device may support 32.
This enables SHOW IOSPACE to determine the number of physical devices being emulated, which is what folks need when configuring software. The word may have other uses - in a generic dynamic device sizing routine - which is why the amount of IOSPACE per device was chosen rather than the 'number of physical devices.'
The edit should not make any existing device regress. If the new word (ulnt) is zero (not initialized), SHOW IOSPACE will default to the number of units in the device, or if there's no device (CPUs), 1 as before. If it is present, the number of devices is the calculated as total allocation/allocation-per-device.
The edit updates all the devices that seem to require this treatment, and all the processors that define the UNIBUS/QBUS DIBs.
The actual machine can have a max to 260MB of memory.
There are three different memory boards that exists for the 86x0, from a software point of view.
4MB, 16MB, and 64MB. In addition, you can mix different boards.
The rule is to put large boards first, and smaller boards later.
Even more fun is the fact that the 16MB and 64MB boards are stacked and thus take up two backplane slots in the backplane, while the 4MB board only takes up one slot.
To complete the picture, there are 8 slots in the memory backplane. You start by putting boards in slot 1, going to slot 8. The boards taking up two slots actually use slot n, while covering slot n-1. That means that the board in slot 1 does not cover up any other slot.
If you are using 16MB boards, the max memory is 68MB.
Slot 1,3,5 and 7 will have 16MB boards. And then you can place a 4MB board in slot 8.
Same story with the 64MB boards.
- Added validation checks in auto_config to reject enabled devices which aren't Q22 capable on Q22 platforms.
- Changed pdp11_cr device to be default disabled in the PDP11 simulator
