Copper Demo ?

weedeewee wrote on 2021-03-29, 19:56:

Copper Demo ?

Never tried that one yet. At least the vertical timings should work. The same with horizontal, as long as CRTC timings itself aren't changed outside of retraces (both horizontal and vertical).
And of course stuff like the rendering dword latched don't reload until the next time a boundary is reached (every 8 pixel clocks).
And the CPU can run in both cycle-accurate and IPS clocking mode. It would probably need cycle-accurate mode, though? CPU Timings above 386 (486+) instructions are 1 cycle execution timings and 1-cycle memory access timings, though. (BIU ticking 1 byte/word/dword every cycle and CPU instruction duration outside of BIU transfers take 1 cycle (instead of for example 2 cycles for a SUB instruction). So for example a SUB using memory as destination is 3 cycles (1 for read, 1 for processing, 1 for write), not counting instruction fetching (1 cycle for dword/word/byte to fill the prefetch queue, 1 cycle in parallel(EU) to read an operand or opcode(8/16/32-bit chunks) with 1-cycle waitstate on the prefetch unit not having data ready(1/2/4 bytes)).
CRTC timings work using horizontal and vertical 'rails'-style precalcs, with each entry being the next pixel handling to perform. It takes the current x and y position from both rails to determine the current CRT and VRAM handling to perform. Besides said rails style precalcs determining the CRTC actions to perform, there's a secondary horizontal rails that determines what to do with VRAM(dot clock determination to tick or not, reload intervals(depending on text/graphics mode), character clock subticking (every 4 ticks) for said reloading timings), NOP cycles etc.). That one restarts at entry 0 only every scanline, always ticking it's next entry each clock.
8088MPH for example runs it's effects fine with it (only failing in part due to 8088 CPU cycle timing not being 100% yet(~100 cycles off during startup tests)).

superfury wrote on 2021-03-29, 19:01:

Weirdly, I can easily find documentation on the W32i and W32p on Google, but somehow plain W32 documentation is non-existent? Are there even graphics cards with a ET4000/W32 chip (not i/p) in existence? Or did they immediately skip to W32i, never producing any ET4000/W32 boards (and thus no documentation exists on said chip itself)?

I have a VLB ET4000/W32 (non i/p), let me know if it would be useful to run any utilities/diagnostics on it.

The card seems to have been made in early 1993 by Tseng Labs themselves according to the FCC ID. One thing I noticed is that the W32 chip gets really hot, especially when compared to my W32p which barely gets warm, I find this odd since these two chips shouldn't be THAT different. I haven't made any serious performance comparison between the two yet.

Any idea how exactly the register 30h and extended CPU VGA VRAM memory aperture works? Is it just the bits 22-29 of the memory address by the CPU in the register 30h? Or just bits 22-23(thus choices of a base address of 4MB, 8MB, 12MB and 16MB, where RAM might also be (which would explain why it wouldn't 'work' according to documentation)? Or is i 1-bit with the highest/upper(bit 1 of said register) bit being an enable flag of sorts (docs say SEGE)?
Unfortunately, the mapping chip connecting it to SEGE/lines 20-24 from said chip(the inputs to said chip being the CPU's address lines and CS16 from the ISA bus?
Anyone?

I'm having troubles with getting the emulated chip to work(windows 95 text blitting issues and VDIAG having more accelerator problems somehow with the newly added handling of the suspend/terminate register bits(bit 0&3 of said register triggering it when written set)).
VDIAG seems to complain a lot having added it (two simulataneous buffers, one byte queue for the queued stuff(containing either registers to write(80h+ range) or memory aperture writes from MMU 0-2 aperture)) and another containing a simple OR-toggle (only cleared by hardware processing) for the terminate/suspend bits.
Loading the queue and/or suspend/terminate register(with 01h or 10h or 11h) sets bit 0 of thr status register. Only clearing and hardware processing of those two clear said but when both queue and suspend/terminate are cleared in their buffers.
Bit 1 of the status is set when one of the queues and suspend/terminate are loaded. It's only cleared when the accelerator checks for new data from the queue(indicated by bit 0 in the status register) and finds it cleared(thus no data has been supplied when it expects the queue to deliver the next 1 or 8 pixel data or register write to process (and also requiring the suspend/terminate latch to not be 'filled' with bit 0/4).
Suspend/terminate happens when it's finished procesding the pixel data that's loaded already and it finds the flags set internally.
Would that be correct behaviour?