VOGONS


Reply 20 of 194, by Pierre32

User metadata
Rank Oldbie
Rank
Oldbie
ALEKS wrote on 2021-03-27, 16:32:
My system is made of hardware entirely designed by me: - ISA System Backplane - ISA 80386DX Singleboard Microcomputer - ISA ET40 […]
Show full quote

My system is made of hardware entirely designed by me:
- ISA System Backplane
- ISA 80386DX Singleboard Microcomputer
- ISA ET4000/W32i Video Card
- ISA I/O Interface
- ISA Audio Interface
- 32 Mb SIMM Modules

Art. Just beautiful.

Reply 21 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

Can you explain what you see (or perhaps screen captures) during the start of the accelerator tests that start after that final screen capture in your second post ALEKS?

In my emulator it starts rendering different colors over each other from the top-left of the screen, keep overwriting the top half or quarter of the screen with colors?

A screen capture while it moves the sprite around the screen(the last test before the crash of the "Stat" register error it aborts":

23-ET4000_W32_during_hardwarecursor_sprite_test.png
Filename
23-ET4000_W32_during_hardwarecursor_sprite_test.png
File size
4.11 KiB
Views
1614 views
File comment
UniPCemu hardware cursor sprite test
File license
Fair use/fair dealing exception

Although the brightness is adjusted with that screen capture by the new 7.5 IRE black pedal.

I see various tests being applied at the start (which now properly work on the current ET4000/W32 emulation). Simply reversing the order of the tests using F9 makes it start straight at the accelerator tests I'm interested in in this case (seemingly the final tests. All other tests run without errors now).

Filename
screencaptures_runningtheAcceleratorTests.zip
File size
58.68 KiB
Downloads
59 downloads
File comment
Captures of running the W32 accelerator tests.
File license
Fair use/fair dealing exception

Those captures were made while it was blitting each of the W32 accelerator tests, before the sprite test and also one screen capture directly after the sprite test.

Last edited by superfury on 2021-03-28, 15:26. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 22 of 194, by ALEKS

User metadata
Rank Newbie
Rank
Newbie

Thank you, Pierre32!
superfury I will try to make a videoclip with the Tseng tests. Especially that yesterday I just scored locally a very little used AOC 17" CRT monitor for $ 5.
My trusty EIZO just started developping a redish tint a couple of minutes after power on -- I will try to fix it when I will have time.

TX486DLC / 40 MHz | 32 Mb RAM | 16-bit ISA Backplane | Tseng Labs ET4000/W32i 2 Mb | I/O Interface | Audio Interface | PC Speaker Driver | Signal View Interface
3.5" & 5.25" FDD | 4 x 512 Mb CF | HP 82341D Interface | Intel EtherExpress 16

Reply 23 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++
ALEKS wrote on 2021-03-28, 15:24:

Thank you, Pierre32!
superfury I will try to make a videoclip with the Tseng tests. Especially that yesterday I just scored locally a very little used AOC 17" CRT monitor for $ 5.
My trusty EIZO just started developping a redish tint a couple of minutes after power on -- I will try to fix it when I will have time.

That would be very helpful in determining the errors in my emulation (not just if the W32 accelerator etc. is working as it should in what I've implemented so far).

It's still kind of weird that the W32 BIOS refuses to detect anything less than it's full 4MB of VRAM having been installed (weird, since it's built for a video card officially supporting 2MB max)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 24 of 194, by ALEKS

User metadata
Rank Newbie
Rank
Newbie

Regarding the RAM, it's not really weird. The ET4000/W32i can access:
* maximum 4 Mb of RAM in linear mode
* maximum 2 Mb of RAM in interleaved mode (that is still physically 4 Mb of RAM but only the addressing mode differs in a way that the CAS pre-charge time of one bank is happening at the same time with the CAS for the other bank)

Furthermore the RAM can be used by:
* CRT controllers (CRTC/CRTCB)
* Host
* Accelerator
* Image Processor (but that's out of scope)

At page 17, the datasheet describes the memory mapping unit (MMU) and how it maps DRAM either in a linear mode or with 8K apertures.

However I honestly haven't looked which registers specify the memory configuration and I don't really know how BIOS determines the amount of RAM physically installed. But the physical RAM connections differ very much in terms of standard versus interleaving. Since my card has physically 4 Mb FPM DRAM installed, I initially wanted to make the card configurable through jumpers for both RAM configurations. But that would've added a lot of complexity and failure points.

My point is that if the BIOS probes the RAM signals and determines the configuration in that way, then it might be useful to adjust the emulator so that the BIOS is aware of the addressing mode.
Then again, I don't know if the BIOS just reads configuration registers directly or the ET4000/W32i chip allows an interface to probe directly the /RAS, /CAS, AAx, ABx, /MWA, and /MWB signals.

Later edit: Here is the videoclip with the color-mode tests with VDIAG.EXE: https://www.youtube.com/watch?v=7yrONWLKvN8
Note: I filmed at 30 fps so that CRT vertical retrace flicker is reduced. That's why the image is lagging. In reality the animation parts are very fluent.

TX486DLC / 40 MHz | 32 Mb RAM | 16-bit ISA Backplane | Tseng Labs ET4000/W32i 2 Mb | I/O Interface | Audio Interface | PC Speaker Driver | Signal View Interface
3.5" & 5.25" FDD | 4 x 512 Mb CF | HP 82341D Interface | Intel EtherExpress 16

Reply 25 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

So UniPCemu almost completes the entire tests. Only at the point it says Press any key to continue at 2:09 is the error given with UniPCemu's implementation. That's when it says Press any key to continue... and W32 Diagnostic complete, in UniPCemu's case it shows the errors shown in my screen captures.

Although the WS=1 part isn't shown in your capture, while UniPCemu somehow shows it? No idea what it means by that?

Probably did manage to disassemble the video BIOS far enough that it does some (un)documented things like memory detection. That's just past the part it displays the video card name (CHIPSET:TSENG LABS ET4000/W32\r\n) on the screen.
Edit: Hmmm... Address 722h in the ROM is the location of the actual addresses display memory texts.
So far I see it reading the register 37h from the CRTC.
What's following it after that (" display memory") is at address 73Bh. The actual KB/MB entries are 5 bytes for each entry ("256KB","512KB"," 1 MB"," 2 MB"," 4 MB").
I'm currently at the function just before said location, so very close.

So far gotten some progress. It seems to check the CRTC registers inversely (BW CRTC address range in color mode and Color addresses in BW mode), where it runs in color mode when segment A800 is selected (B800 otherwise).
It for some reason sets up the Misc Output Register to the inverse of the selected color mode.
Then if the CRTC register read/write check fails (which it always does due to the inversed color bit in the Misc Output Register being used, thus always addressing literally nothing and failing the very first register it checks), it selects segment A800 (bits 2:3 of GDC 06h to 01h (or in the entire register or'ed 04h)).

Edit: After lots of disassembly of the BIOS and documenting most, if not all of it's initial functions, I've found a block of code that seemingly tries to verify the settings of bitness when it's not in 1M mode(as specified by the values of bit 3 and 1 of register 37h):

mainlinearVRAMbitnesstestfunction proc near
seg000:0646 ; CODE XREF: sub_C05EE+41↑p
seg000:0646 ; someFunctionCalledOnLinearVRAMwithDSbeingLinearVRAM+6↓p
seg000:0646 push dx
seg000:0647 push si ; CL=8 SHL 32bitness. SI=0 from the memory test function.
seg000:0648 push di
seg000:0649 mov di, bx ; Address from BX to DI
seg000:064B sub si, si ; SI=0
seg000:064D mov bl, 0 ; Segment select cleared
seg000:064F call writeSegmentSelectAndExtended_BL ; Segment select cleared.
seg000:0652 mov dl, [si] ; Move VRAM [0] to DL
seg000:0654 mov bl, cl ; BL=8 SHL 32bitness
seg000:0656 call writeSegmentSelectAndExtended_BL ; Segment Select = 8 SHL 32bitness
seg000:0659 mov dh, [di] ; Read VRAM [0] to DH.
seg000:065B mov ch, 55h ; 'U'
seg000:065D mov [di], ch ; 55h to VRAM [0].
seg000:065F mov bl, 0
seg000:0661 call writeSegmentSelectAndExtended_BL ; Segment select cleared again.
seg000:0664 mov bx, si ; BX=SI=0
seg000:0666 call readBXblockIn8times20hIncrementsIntoALAndDiscardIt
seg000:0669 cmp ch, [si] ; Became 55h?
seg000:066B jnz short VRAMtestfailed
seg000:066D mov ch, 0AAh
seg000:066F mov [si], ch ; AA to VRAM [0].
seg000:0671 mov bl, cl
seg000:0673 call writeSegmentSelectAndExtended_BL
seg000:0676 mov bx, di
seg000:0678 call readBXblockIn8times20hIncrementsIntoALAndDiscardIt
seg000:067B cmp ch, [di] ; Became AAh?
seg000:067D
seg000:067D VRAMtestfailed: ; CODE XREF: mainlinearVRAMbitnesstestfunction+25↑j
seg000:067D pushf
seg000:067E mov bl, cl
seg000:0680 call writeSegmentSelectAndExtended_BL
seg000:0683 mov [di], dh
seg000:0685 mov bl, 0
seg000:0687 call writeSegmentSelectAndExtended_BL
seg000:068A mov [si], dl
seg000:068C popf
seg000:068D pop di
seg000:068E pop si
seg000:068F pop dx
seg000:0690 retn
seg000:0690 mainlinearVRAMbitnesstestfunction endp

Can you make something of what's happening here?
'32bitness' is a bit 0 of register 37h(so it switches between 0x08(16-bit) and 0x10(32-bit)). Bit 3 is always set to 1M mode in this case when this is running.
The full current disassembly of said W32ISA BIOS: https://www.dropbox.com/s/vg81vze6rr8w2oc/ET4 … 00_W32.i64?dl=0 (IDA Freeware 7.0 file)

Edit: Slight review! Finally figured the remaining part out of the startup routine:

interrogateCRTCregister37hMemorySizeToAL proc near
seg000:06F3 ; CODE XREF: mainStartupVideoBIOSfunction↓p
seg000:06F3 ; seg000:079C↓p ...
seg000:06F3 push dx
seg000:06F4 call getCurrentCRTCindexport_toDX
seg000:06F7 mov ah, 37h ; '7' ; Select CRTC register 37h.
seg000:06F9 call readIndexedPort_AHisIndex_DXisIndexPort_ALbecomesReadValue
seg000:06FC mov ah, 4 ; AH=04h. AL=Register 37h contents.
seg000:06FE test al, 8 ; 256k if set, 1M if cleared on ET4000/W32.
seg000:0700 jz short DRAMis1M_entries4and5frombit0 ; 1M DRAM/VRAM if cleared?
seg000:0702 mov ah, 2 ; AH is 2 instead of 4.
seg000:0704 push bx
seg000:0705 push cx
seg000:0706 and al, 1 ; 16-bit becomes 0, 32-bit becomes 1.
seg000:0708 mov cl, al
seg000:070A mov bx, 8 ; BX=10h if 32-bit, 08h if 16-bit.
seg000:070D shl bx, cl
seg000:070F mov cx, bx
seg000:0711 sub bx, bx ; BX=0, CX=10h if 32-bit, 08h if 16-bit.
seg000:0713 call funcBX0CX8SHL32bitnessALis32bitness
seg000:0716 jz short restoreCXBXandcheckbit0_resultIsSize2and3frombit0 ; result had zero flag set? Thus no comparison errors during the test?
seg000:0718 mov ah, 3 ; No? 3 and 4 added bit 0 when comparison errors occur.
seg000:071A
seg000:071A restoreCXBXandcheckbit0_resultIsSize2and3frombit0:
seg000:071A ; CODE XREF: interrogateCRTCregister37hMemorySizeToAL+23↑j
seg000:071A pop cx
seg000:071B pop bx
seg000:071C
seg000:071C DRAMis1M_entries4and5frombit0: ; CODE XREF: interrogateCRTCregister37hMemorySizeToAL+D↑j
seg000:071C and al, 1 ; 16 or 32-bitness + 3 if comparison error occured in the test function.
seg000:071E add al, ah
seg000:0720 pop dx
seg000:0721 retn
seg000:0721 interrogateCRTCregister37hMemorySizeToAL endp

So the result in AL is actually a combination of bit 3 being set(more choices) or cleared(text entry 4 if bit 0 is cleared, text entry 5 if it's set).
Then, if bit 3 is cleared, bit 0 still selects between 2 different entries, depending on whether the write tests succeed or fail. If they succeed the test function then entry 2 for bit0=0 and entry 3 for bit0=1. If they fail the test function for memory, then 3 for bit 0=0 and 4 for bit 0=1.
bit 0 and bit 3 are the contents of the CRTC register 37h.
Just for reference, the entry numbers are:
0="256KB"
1="512KB"
2=" 1 MB"
3=" 2 MB"
4=" 4 MB"
So, combining those:
bit 3 cleared:
bit 0=0:4=2MB,
bit0=1:5=4MB.
bit 3 set:
bit0=0 and success:2=1MB
bit0=1 and success:3.=2MB
bit0=0 and fail:3=2MB
bit0=1 and fail: 4MB
256KB and 512KB would never happen in that case, unless AH is somehow modified by subfunctions to become 0 by funcBX0CX8SHL32bitnessALis32bitness?

The full disassembly I did in IDA Freeware 7.0: https://www.dropbox.com/s/vg81vze6rr8w2oc/ET4 … 00_W32.i64?dl=0
Edit: Whoops. The entry number is decreased by 1 after it returns from said function. So:
Just for reference, the entry numbers are:
0="256KB"
1="512KB"
2=" 1 MB"
3=" 2 MB"
4=" 4 MB"
So, combining those:
bit 3 cleared:
bit 0=0:3=2MB,
bit0=1:4=4MB.
bit 3 set:
bit0=0 and success:1=512KB
bit0=1 and success:2.=1MB
bit0=0 and fail:2=1MB
bit0=1 and fail:3 2MB
256KB doesn't occur (not supported by the chip).

So far managed to get all those cases but 512KB to work by setting the following values in register 37h (no wrapping applied to the VRAM addresses, other than the limit being applied):
- 4MB: value 01h (bit 3 cleared bit 0 set): as above.
- 2MB: value 00h (bit 3 cleared bit 0 cleared): as above.
- 1MB: value 09h (bit 3 set bit 0 set): matching the bit0=1 and fail case.
- 512KB: value 08h (bit 3 set bit 0 cleared): reporting 1MB because bit 0 is 0 and fails?
Somehow, the tests always seem to fail for the 1MB/512KB versions?
This is matching what WhatVGA is testing somehow (except the 512KB/1MB cases because those tests somehow fail in the memory tests giving 1MB(instead of 512KB) and 2MB instead of 1MB)?
Edit: Managed to make the 512KB and 1MB cases work properly, by making the 512KB and 1MB cases wrap the memory addressed (before limiting or checking for overflow) around their own memory sizes (so 512KB aliases at 512KB multiples and 1MB does the same at 1MB multiples). Then, selecting the success cases (bit 3 set with bit 0=0 for 512KB and bit 0=1 for 1MB) causes the BIOS to detect the VRAM correctly!
😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 26 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've managed to get it to detect the VRAM correctly:
- On both poweron and when setting bit 1 of register 37h(Unmentioned bit in WhatVGA/W32i manuals. W32p manual only says "Reserved") it will load bits 3 and 0 with the appropriate bits for the installed VRAM (it also does this for bit 6, since it's enabling some diagnostics mode? Not sure about this. Unused by the BIOS ROM.).
They are loaded as WhatVGA specifies in it's W32 memory detection routine in IDVGA.PAS.
UniPCemu also wraps 512KB and 1MB around said blocks (AND with 7FFFF and FFFFF and mask before applying out of range bounds and limit checks(extended bit of the Sequencer Mode Control register)) to make the memory tests succeed for 512KB/1MB.

This causes the BIOS to correctly detect the VRAM that's installed. 😁
Any idea about the bit 1 of said register? And about the test mode of bit 6?

Did this with a combination of the disassembly to find the point it's only read onward in the BIOS(C000:06F3) during POST and looking at register writes during POST(first 2F from the BIOS ROM itself, then 2*(unchecked source of that, but somewhere in the ROM or previous register value before the determination of VRAM installed), but bit 2 is set in both cases, after which it's read for a final time for the display of installed VRAM based on bits 3 and 0).

The register values(after masking with 0x9) seems to be as follows:
- 01h: 4MB
- 00h: 2MB
- 09: 1MB
- 08: 512KB

Mainly figured it out with a breakpoint at C000:06F3 and the writes made to register 37h and of course the documentation that's present(WhatVGA explains the above partly, the rest is figured out by viewing the BIOS disassembly in IDA).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 27 of 194, by ALEKS

User metadata
Rank Newbie
Rank
Newbie

That was a great read! And good thing you are now detecting the RAM correctly. Thank you for the analysis.
Indeed 256K is not supported by the W32i variation.

I did a quick search on the Internet and found out the following source code that targets the ET4000/W32i amongst other stuff.
Maybe it is of help to you (if you haven't already found it): et4000.c
It has some memory information as well.

I did some reverse engineering of the video BIOS myself last year, but not that deep as you went. I will disassemble it at some point to check if I can inject some jumps and a piece of code at the end of the ROM that alters the character attributes directly in the VGA RAM so that I can highlight the EXCELGRAPH text at PC BOOT. It appears there is sufficient empty space in the ROM image for a small routine.
But I was mainly interested in replacing the VGA ROM fonts (which I succeeded) and also replacing of some strings so that the card displays EXCELGRAPH and other stuff instead of the old strings.

TX486DLC / 40 MHz | 32 Mb RAM | 16-bit ISA Backplane | Tseng Labs ET4000/W32i 2 Mb | I/O Interface | Audio Interface | PC Speaker Driver | Signal View Interface
3.5" & 5.25" FDD | 4 x 512 Mb CF | HP 82341D Interface | Intel EtherExpress 16

Reply 28 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++
ALEKS wrote on 2021-03-29, 12:26:
That was a great read! And good thing you are now detecting the RAM correctly. Thank you for the analysis. Indeed 256K is not su […]
Show full quote

That was a great read! And good thing you are now detecting the RAM correctly. Thank you for the analysis.
Indeed 256K is not supported by the W32i variation.

I did a quick search on the Internet and found out the following source code that targets the ET4000/W32i amongst other stuff.
Maybe it is of help to you (if you haven't already found it): et4000.c
It has some memory information as well.

I did some reverse engineering of the video BIOS myself last year, but not that deep as you went. I will disassemble it at some point to check if I can inject some jumps and a piece of code at the end of the ROM that alters the character attributes directly in the VGA RAM so that I can highlight the EXCELGRAPH text at PC BOOT. It appears there is sufficient empty space in the ROM image for a small routine.
But I was mainly interested in replacing the VGA ROM fonts (which I succeeded) and also replacing of some strings so that the card displays EXCELGRAPH and other stuff instead of the old strings.

Already read it a longer time ago and implemented said method partly with the ET4000AX chip.
I still find it weird that the code claims to be for a ET4000/W32, but uses bit 0/1 as if it were an ET4000AX chip (which obviously isn't the case, as bit 0&1 are widly different on a ET4000/W32 chip(bit 0 select between 16-bit and 32-bit, while bit 1 does nothing according to the documentation and BIOS). So those multipliers by 2 and 3 are for the ET4000AX, but not for the ET4000/W32 (reserved according to the W32P manual even, not mentioned in the W32i manual). Don't have any W32-specific manual (it doesn't even exist according to a Google search? It only finds W32i and W32p datasheets).
The definitions on bits 0/1 even conflict between ET4000AX and ET4000/W32 chipsets (
0=16-bit on ET4000/W32, 8-bit on ET4000AX. Incompatible results between the chipsets. Always 8-bit in VGAlib (incorrect on ET4000/W32).
1=32-bit on ET4000/W32, 8-bit on ET4000AX. Incomparible results between the chipsets. Always 8-bit in VGAlib (incorrect on ET4000/W32).
2=16-bit on ET4000/W32, 16-bit on ET4000AX. Since the ET4000/W32 ignores bit 1 for this, it's compatible with the ET4000AX?
3=32-bit on ET4000/W32, 32-bit on ET4000AX. Since the ET4000/W32 ignores bit 1 for this, it's compatible with the ET4000AX?
). So that's definitely NOT compatible. The code you've linked to (and pretty much all linux VGAlib code it seems) uses the ET4000AX method of determining memory (the only one it 'supports') on the ET4000/W32 chipsets. Even though the exact meaning of the bits are completely incorrect when bit 3 is cleared(1M instead of the 64K it uses, thus detecting way too little RAM) and the lowest 2 bits differ as mentioned above. So anything using 1M chips gets 100% incorrectly decoded, as does the 8-bit ET4000AX getting used instead of the proper 16-bit/32-bit that's actually installed!
So only 2 out of 8 cases of memory configuration(cases when masked with 0xB giving 09h and 0Ah(the bottom 2 cases with 256K RAM chips) actually get correctly decoded. All other cases get 100% incorrectly decoded!
Worst case, it detects 64K when it's actually 4MB(1MB times 32-bit, with input 001b). Or even the same: 64K (1MB times 16-bit(thus actually 2MB), with combined bits 000b). The highests register bit (bit 3) being bit 2 in my notations of it left of this sentence.

Also, I only decoded the entire POST part itself (minus the int10h vector and it's exact subroutines).
So the code it executes when jumpting to the start of the video BIOS (at C000:0003h) until said routine returns to the BIOS ROM (it's RETF instruction) (I just omitted disassembling the entire interrupt 10h handler (though I did a partly disassembly of such a handler on the ET4000AX BIOS to figure out how the DAC gets properly detected on Tseng chips (it can be found in the same folder as my uploaded IDA disassembly of the ET4000/W32 init routines))).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 29 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

It's still a bit weird that although 256K isn't supported by the chips the BIOS supports (cannot be detected or implemented on the W32 chip), it still is included in the lookup tables to the texts and of course the texts itself (It literally says "256KB", entry 0 in the list).
Perhaps it's used for some special EGA or VGA-compatible mode?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 30 of 194, by ALEKS

User metadata
Rank Newbie
Rank
Newbie

I have seen the memory range array in the ASM code as a string of DBs. Maybe the ROM BIOS image was made for ET4000AX as well? That one can handle 256K.
Then again, at page 186 of the datasheet, the hardware memory addressing lines are described. And the minimum is 512K. I think the BIOS might be compatible with other ET4K variants.

memory-limit.jpg
Filename
memory-limit.jpg
File size
85.14 KiB
Views
1449 views
File license
Fair use/fair dealing exception

Inspired by your work, I wrote a small assembly routine (only 35 machine code bytes) that highlights the name of the video card. Then I wrote a patcher program so that I can automate the operation of modifying the binary ROM BIOS image.
I disassembled the ROM and seen where I could insert my own JMP instructions. There is some empty space in the ROM BIOS image at multiple locations. I chose the most convenient one at the end.
Half an hour later I got what I wanted.

excelgraph.png
Filename
excelgraph.png
File size
4.78 KiB
Views
1449 views
File license
GPL-2.0-or-later

It's only an emulator screen. Now I will burn a 27c256 UV-erasable EPROM with this updated microcode for the real deal.

PS: I wanted to download a compiled version of UniPCEmu for Windows but I haven't found one. And I don't have MSVC to compile it. So I ended up using PCem instead.

Cheers,

TX486DLC / 40 MHz | 32 Mb RAM | 16-bit ISA Backplane | Tseng Labs ET4000/W32i 2 Mb | I/O Interface | Audio Interface | PC Speaker Driver | Signal View Interface
3.5" & 5.25" FDD | 4 x 512 Mb CF | HP 82341D Interface | Intel EtherExpress 16

Reply 31 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++
ALEKS wrote on 2021-03-30, 07:30:
I have seen the memory range array in the ASM code as a string of DBs. Maybe the ROM BIOS image was made for ET4000AX as well? T […]
Show full quote

I have seen the memory range array in the ASM code as a string of DBs. Maybe the ROM BIOS image was made for ET4000AX as well? That one can handle 256K.
Then again, at page 186 of the datasheet, the hardware memory addressing lines are described. And the minimum is 512K. I think the BIOS might be compatible with other ET4K variants.

memory-limit.jpg

Inspired by your work, I wrote a small assembly routine (only 35 machine code bytes) that highlights the name of the video card. Then I wrote a patcher program so that I can automate the operation of modifying the binary ROM BIOS image.
I disassembled the ROM and seen where I could insert my own JMP instructions. There is some empty space in the ROM BIOS image at multiple locations. I chose the most convenient one at the end.
Half an hour later I got what I wanted.

excelgraph.png

It's only an emulator screen. Now I will burn a 27c256 UV-erasable EPROM with this updated microcode for the real deal.

PS: I wanted to download a compiled version of UniPCEmu for Windows but I haven't found one. And I don't have MSVC to compile it. So I ended up using PCem instead.

Cheers,

If you want to compile it with free tools, simple Msys2 with MinGW can be used to compile UniPCemu for Windows as well. It's what I use for the Windows releases of the app (a slight manual is in the MSYS text file inside the UniPCemu folder for setting it up and then use the command from the README to compile it).

I did notice something weird, though: if I use less than 4MB of VRAM, the VTEST app will detect that, but hang in text mode when it starts the final tests(the accelerator tests) for some reason?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 32 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

Does QMOD(bit 4 of the status register) exist on the W32/W32i?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 33 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Just made a fix for the terminate/suspend to be loaded into the queue as a non-value write (behaving the same as a written value that doesn't process anything other than termination, but with the exception it's sort of side-loaded as an extra status to MMU register writes(so the MMU register write that's queued will be processed first, finishing up with the suspension/termination immediately after said operation completes and the accelerator is idle)). This should theoretically fix issues with said contention on the queue.
But now weird stuff happens in VDIAG. I see it actually receiving stuff like performing BitBlts and properly taking CPU inputs, but after the first screen rendering(the yellowish screen), no other differences are displayed except for the sprite test, after when it completes, it gives a bunch of errors on unwritable registers(unchanged behaviour queue-wise, since the registers should still be writable as they always did) and the display seems to be incorrectly updated during the tests after the first blit? It also complains about almost all the tests performed during the first phase of the accelerator having failed?
I do see the accelerator still processing small chunks of processing (one horizontal line BitBlt of 80h bytes at a time) while it's processing?
So is this actually a problem with the inputs that's given to the accelerator (reading/writing the queue)? Or would some other problem be the cause? Windows 95 still acts the same as it did before, with correct windowing etc. (which mainly uses automatic BitBlts without CPU input) and changed less corrupted text (a bit readable, but mostly incomprehensible).
Edit: All the transfers made once I've modified the new queue behaviour somehow cause all but the first BitBlt operation on the ET4000/W32 to effectively have no effect on VRAM anymore? That's weird?

Only when I actually decouple the terminate mechanism from the queue mechanism (although still queued in a way, it will silently be queued anyways until it's processed) will it actually render more than the first BitBlt on the different tests until it starts the CRTCB/Sprite test, which seems to work. After that it will give a lot of errors still?
Any idea what's going on?
The current Tseng ET3000/4000/W32 source code: https://bitbucket.org/superfury/unipcemu/src/ … ga/svga/tseng.c

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 34 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

One little question: if the registers exist in a queue format (queue and internal), does that mean that the registers themselves when written cause the queue to be filled up? If the queue is byte-sized, does that mean that disabling waitstates for the ACL causes a dword write to only have 1 byte written to the queued registers with the others ignored (as the documentation implies) when the sync enable bit is cleared and interrupts aren't enabled for this case?

Also, a little sidenote: I managed to get the accelerator to properly work now (after improving the ACL terminate/suspend behaviour to at least match the documentation's given suspend behaviour)! The only thing left in the VDIAG program tests is that it still complains about a "Error powerup: VSS"?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 35 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmmm... Looking at VDIAG.EXE inside a hex editor looks interesting... I see all kinds of string in there (even EGA/VGA support apparently, with as low as 16KB VRAM installed?).
I also see what looks like C runtime libraries in there(stdlib etc.) with even main.c in a string... Perhaps a C decompiler can give roughly the source code to it and perhaps shed a light on the whole "Error at power up: VSS" message? It's followed by a dollar sign in the hex editor, so it's just a seperate string it displays?
Any idea what it means with said message? It looks like a register induced (bit 4 of operation state register being set) terminate function isn't doing what it's expecting?

Any idea what it means by the power-up state of the registers? All cleared?

Last edited by superfury on 2021-04-11, 22:26. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 36 of 194, by mr.cat

User metadata
Rank Member
Rank
Member
superfury wrote on 2021-04-11, 20:36:

Hmmmm... Looking at VDIAG.EXE inside a hex editor looks interesting... I see all kinds of string in there (even EGA/VGA support apparently, with as low as 16KB VRAM installed?).
I also see what looks like C runtime libraries in there(stdlib etc.) with even main.c in a string... Perhaps a C decompiler can give roughly the source code to it and perhaps shed a light on the whole "Error at power up: VSS" message? It's followed by a dollar sign in the hex editor, so it's just a seperate string it displays?
Any idea what it means with said message? It looks like a register induced (bit 4 of operation state register being set) terminate function isn't doing what it's expecting?

Well it's a mixture of C and asm, so idk how useful decompilation might be in this case... Additionally, it's for DOS so maybe give IDA a try? You get some extra hints as comments, so that's a plus at least.
Btw, Cutter can't even find the xref for that string! BUT you can search the address (as part of assembly instruction) and with that it's revealed that the printing happens at fcn.00009a8f (routine starts at fcn.00009a68).
So that's at least one place to start reversing.

EDIT: Cutter's newly forked version has some problem with decompilation, the older version seems to work. Yeah I'd say it does help a bit:

fcn.00009afa
void fcn.00009afa(void)
{
uint8_t uVar1;
undefined2 unaff_DS;

out(0x3d4, 0x22);
in(0x3d5);
uVar1 = fcn.0000a10e();
if ((uVar1 & 8) == 0) {
in(0x3c3);
uVar1 = fcn.0000a10e();
if ((uVar1 & 1) != 0) {
*(undefined *)0x4ad7 = 1;
}
} else {
in(0x46e8);
uVar1 = fcn.0000a10e();
if ((uVar1 & 8) != 0) {
*(undefined *)0x4ad7 = 1;
}
}
return;
}

Cutter's decompilation module originates from Ghidra, I'm not sure but maybe it works with IDA too.

Last edited by mr.cat on 2021-04-12, 09:51. Edited 1 time in total.

Reply 37 of 194, by ALEKS

User metadata
Rank Newbie
Rank
Newbie

I would deffinetely go with IDA. Or if you'd like to dig deeper then give SoftICE a try. That would bring back interesting memories of the old times. You can step into each asm routine in real-time. But, as you might've guessed already, it takes a lot of time. And reversing a poorly written procedural program with lots of routines... is the death of all passions.

You can seek the offsets of different interesting strings and then just fool around wih SoftICE, BPXing different print string or character interrupt service routines. That should be fun. With a little luck you might just trace the VSS error checking routine. If you have $ terminated strings then just look no further than INT 21h printing routines. If it's C then I am pretty sure there is no direct VGA RAM addressing involved.

From a hardware point of view there is no logic as if there is no VSS signal then the chip doesn't receive power. If it helps you, I will publish the schematic on my site shortly and you can see which additional pins I have tied to VSS, besides the standard VSS signals.

Indeed VDIAG.EXE might've been compiled with MS C for DOS.

And at that .EXE size, it sure does contain a lot of bloat. And there is also an overlay embedded. I'd say that's either amateur programming or the tool was designed for multiple purposes. Or both. In my oppinion a program like that shoulde've not exceeded 20K or so. Even if it was written in C.

TX486DLC / 40 MHz | 32 Mb RAM | 16-bit ISA Backplane | Tseng Labs ET4000/W32i 2 Mb | I/O Interface | Audio Interface | PC Speaker Driver | Signal View Interface
3.5" & 5.25" FDD | 4 x 512 Mb CF | HP 82341D Interface | Intel EtherExpress 16

Reply 38 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

Did manage to botch up the ET4000/W32 emulation somewhat.
I've slightly changed the conditions for the ACL destination address (offset A3) writes always causing a load of the queue into the accelerator and starting a graphics operation (instead of depending on bit 4 of the ACL Operation State Register to be set as well for that to happen).
Then I've also changed the queueing of larger than 1 byte writes during a single transfer by the CPU (word or doubleword transfers) to enforce waitstates (forcing of the waitstate setting in ACL Sync Enable Register bit 0 as if it were set) after enqueueing the first byte. Thus allowing 16-bit and 32-bit transfers to succeed when the first byte is accepted (but not when it's not accepted during said write by the CPU).

I now also see something new, though: I see it's drawing lines during the poly line drawing tests. 😁

Although the BItBlt and pattern tests are failing now?

1420-VDIAG failing tests.png
Filename
1420-VDIAG failing tests.png
File size
9.08 KiB
Views
1249 views
File comment
VDIAG failing tests.
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 39 of 194, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just managed to find the issue (it was effectively the same kind of issue as before with said BitBlt transfers): when the memory aperture write while it wasn't transferring anything is written, it loads the destination address according to the mode(mixmap or not, combined with the aperture base address during the write).
But since said values weren't loaded in this case, the loading of the destination offset misbehaved, causing incorrect behaviour.
Having fixed that using a peek operation that doesn't clear the buffer(required for the CPU to view the operation is done and stop spinning in a loop) but does decode the information inside it's write information (all addressing information used for loading the destination address register and latch), this once again fixed the VDIAG software to perform correctly, now with the added multibyte write support. 😁

The VSS error is still present, though?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io