Commit Graph

6 Commits

Author SHA1 Message Date
joevt
cf9237f7d6 control: Fixes.
- Fix video vram endianness. It should behave like RAM.
- Add read for registers ENABLE, INT_STATUS, INT_ENABLE.
- Add write for registers CNTTST, INT_ENABLE.
- Add support for 16bpp and 32bpp.
- Add vbl interrupt.
2024-01-13 00:41:08 +01:00
joevt
190718fbee Add BAR 0 to control.
BAR 0 exists on a real Power Mac 8600 and the dingusppc 7500.

On a Power Mac 8600, the initial value is 0x84000003. In Open Firmware, you can write to all bits of the BAR and read the value back except the 2 least significant bits are always %11. Bit 0 indicates I/O space. Bit 1 is reserved and should be zero so maybe this is not a real I/O space BAR. 0x8400000 is written to the BAR by Open Firmware. It doesn't look like a normal I/O address which are usually 16 bits.

On the emulated 7500, 0x02000000 is written to the BAR by Open Firmware sometime during probe-all. The BAR did not behave as it does in the Power Mac 8600. This commit fixes that.

Two questions remain:
1) Which fcode writes to the BAR? Is it the probe fcode or is it the control fcode? There's no config-_! in the control fcode.
2) What is the purpose of the BAR? Writing to it can cause a hang. The testbits code below seems to succeed - it restores the original value after reading the result of testing each bit and before displaying the result. The values shown for the MSB (0x84 on the 8600 and 0x02 on the 7500) could be three flag bits.

```
dev vci0
: testbits { adr ; org }
	cr
	adr config-l@ dup -> org ." original : " 8 u.r cr
	20 0 do
		1 1f i - << dup 8 u.r ."  : "
		adr config-l!
		adr config-l@
		org adr config-l!
		8 u.r cr
	loop
	;

15810 testbits \ 15810 is the address of the BAR on the emulated 7500.
```
2023-01-11 00:05:23 -08:00
Maxim Poliakovski
3a5c61797c
Revert "PCI fixes" 2022-09-02 23:24:06 +00:00
joevt
a08e70781a Add BAR 0 to control
BAR 0 exists on a real Power Mac 8600 and the dingusppc 7500.

On a Power Mac 8600, the initial value is 0x84000003. In Open Firmware, you can write to all bits of the BAR and read the value back except the 2 least significant bits are always %11. Bit 0 indicates I/O space. Bit 1 is reserved and should be zero so maybe this is not a real I/O space BAR. 0x8400000 is written to the BAR by Open Firmware. It doesn't look like a normal I/O address which are usually 16 bits.

On the emulated 7500, 0x02000000 is written to the BAR by Open Firmware sometime during probe-all. The BAR did not behave as it does in the Power Mac 8600. This commit fixes that.

Two questions remain:
1) Which fcode writes to the BAR? Is it the probe fcode or is it the control fcode? There's no config-_! in the control fcode.
2) What is the purpose of the BAR? Writing to it can cause a hang. The testbits code below seems to succeed - it restores the original value after reading the result of testing each bit and before displaying the result. The values shown for the MSB (0x84 on the 8600 and 0x02 on the 7500) could be three flag bits.

```
dev vci0
: testbits { adr ; org }
	cr
	adr config-l@ dup -> org ." original : " 8 u.r cr
	20 0 do
		1 1f i - << dup 8 u.r ."  : "
		adr config-l!
		adr config-l@
		org adr config-l!
		8 u.r cr
	loop
	;

15810 testbits \ 15810 is the address of the BAR on the emulated 7500.
```
2022-09-02 03:39:50 -07:00
joevt
3ee2ea1871 Fix read/write argument names
base class uses reg_start so derived classes should do the same.
Some derived class already uses reg_start for read method.
2022-08-22 17:16:22 -07:00
Maxim Poliakovski
8dfdf55dff Initial emulation for the Control video. 2022-08-07 15:25:58 +02:00