Commit Graph

17 Commits

Author SHA1 Message Date
Maxim Poliakovski
cb8c2cb450 Wire CONTROL interrupt. 2024-02-12 01:46:21 +01:00
Maxim Poliakovski
7d06c5b37a control: use RaDACal emulation from appleramdac. 2024-02-11 22:59:43 +01:00
Maxim Poliakovski
44b1d34cc7 control: support interlaced modes. 2024-02-11 22:22:27 +01:00
Maxim Poliakovski
5f06be6226 control: implement HW cursor rendering. 2024-01-19 23:48:22 +01:00
Maxim Poliakovski
d413e4a278 control: incorporate recent HW knowledge. 2024-01-19 09:48:54 +01:00
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
7c3bb41728 videoctrl: Add more convert frame methods.
Also rename 1bpp and 8bpp methods to 1bpp_indexed and 8bpp_indexed.
2023-12-03 20:38:01 +01:00
Maxim Poliakovski
4872af1053 control: use new refresh task control. 2023-07-31 03:53:13 +02:00
Maxim Poliakovski
3e545bdef9 Handling host events in video controllers. 2023-04-02 03:01:13 +02:00
Maxim Poliakovski
888d919ae7 videoctrl: refactor palette access. 2023-04-02 03:01:13 +02:00
Maxim Poliakovski
cc17035e67 pcidevice: improve BAR configuration. 2023-02-04 17:57:46 +01:00
joevt
2a64f547cc Add 64-bit BAR support.
While dingusppc only emulates 32-bit Macs (for now), it is possible for a 32-bit Power Mac to use a PCIe card that has 64-bit BARs.

finish_config_bars is added to scan the cfg values of the BARs and determine their type. The type is stored separately so that it does not need to be determined again.
The type can be I/O (16 or 32 bit) or Mem (20 or 32 or 64 bit). A 64 bit bar is two BARs, the second contains the most significant 32 bits.

set_bar_value uses the stored type instead of trying to determine the type itself. It is always called even when the firmware is doing sizing. For sizing, It does the job of setting the bar value so do_bar_sizing is now just a stub.

Every PCIDevice that has a BAR needs to call finish_config_bars after setting up the cfg values just as they need to setup the cfg values. Since they need to do both, maybe the cfg values should be arguments of finish_config_bars, then finish_config_bars() should be renamed config_bars().
2023-02-02 02:47:34 -08: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