VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

Anyone knows the exact differences in mapping memory from the CPU's point of view?

Also, is the rendering in 8-bit and 16-bit the same as on VGA 8-bit(using normal VGA-compatible rasterizing), using the four planes in the same way?

I'm still having difficulty on the 8-bit and above modes, as well as anything past 800x600x16(e.g. 640x480x256, 1024x768x16, 800x600x256 and the 16-bit color variants as well(same modes as 256 colors, using modes 2Eh etc.).

The display of text rendered using WHATVGA in the 8-bit and 16-bit high-res color modes(640x480 and up) seems to have round holes punched(looks like) into the text, like cheese? The text is slightly garbled and almost unreadable. 8/16-bit rendering itself(DAC) is confirmed working(using mode 13h in 8-bit and 16-bit color modes, although the WHATVGA seems to write it's color gradients(from left to right R, G, B and White gradient bars on top of the 8-bit color gradient bars?)?

Is there a memory addressing error there somewhere?

VGA renderer: https://bitbucket.org/superfury/unipcemu/src/ … /vga_renderer.c
ET3K/ET4K specifics: https://bitbucket.org/superfury/unipcemu/src/ … ga/svga/tseng.c
CPU aperture handling: https://bitbucket.org/superfury/unipcemu/src/ … e/vga/vga_mmu.c

Also, oddly enough in 32K/64K mode it's running in 4-bit pixel mode(instead of the proper 8-bit mode), according to the attribute controller?

Edit: Perhaps a banking bug(bank >0 to 15)?

VRAM usage of banks and planar access(as a DWORD containing all planes) or single access: https://bitbucket.org/superfury/unipcemu/src/ … /vga/vga_vram.h

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

Reply 1 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

I see something odd happening. I've changed banks to always select 64K/128K(on ET3000 only) to be added to the raw VRAM address(low 2 bits being the plane).

But when I test mode 2Eh in the WHATVGA software, the Attribute Controller is setup for 4-bit pixels and no other mechanism of selecting the 8-bit pixel clock is enabled?

Anyone?

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

Reply 2 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've modified the ET3000/ET4000 to actually also set the 8-bit graphics mode latch's rendering(on the Attribute controller side) when the Chain-4 bit is set in the Sequencer Mode Control register. Is that correct on those graphics cards?

Edit: Just added ignoring of the Write Plane Mask for said mode(Chain-4 mode on ET3K/ET4K). Reads aren't affected by any such register in my emulator(only in Odd/Even modes and Planar modes, which are not used when Chain-4 overrides them).

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

Reply 3 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've made some progress, with adding linear addressing modes to the ET3000/ET4000 emulation.

911-ET4000_linearmode_8bit.jpg
Filename
911-ET4000_linearmode_8bit.jpg
File size
77.42 KiB
Views
1157 views
File comment
640x480 in 8-bit colors.
File license
Fair use/fair dealing exception
912-ET4000_linearmode_16bit.jpg
Filename
912-ET4000_linearmode_16bit.jpg
File size
92.9 KiB
Views
1157 views
File comment
640x480 in 16-bit colors.
File license
Fair use/fair dealing exception

The only odd thing left there is that it somehow only renders half a screen on each scanline?

Looking at the rendering process using a debugger shows that it correctly loads new pixels every four pixels that are processed(as are buffered in the processing buffer, the whole 32-bit dword being rendered). It renders 4 pixels(2 pixels in 16-bit mode) from those.

But somehow past 320 pixels isn't displayed?

The Dot Clock Rate is set for single clocks(so every dot clock a pixel is rendered as far as I can remember).

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

Reply 4 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Tried the DCR with said mode. No effect?

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

Reply 5 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Tried a slight rewrite of the DCR logic, adding a second precalc bit(which only has effect on the CRTC signal generator, but not on the character generator(required for 8-bit pixel reads from VRAM to succeed).

Now the 8/16-bit modes work! 😁

At least up to 800x600 pixels.

Edit: Verified graphics modes up to mode 30h working, according to WHATVGA. Text modes just quit back to the main menu?

Advanced non-VGA textmodes return to the main menu.

Mode 36h returns to the main menu. Mode 37h(1024x768x16) oddly hangs the screen output? Same with mode 38h(1024x768x256).
Mode 3Dh returns an oddly rendered screen(with valid text). Mode 3Eh fails and returns to the main menu.

Mode 313h/413h is once again valid.

Mode 32D/42D is invalid(around left 1/3 of the screen), with the right part oddly wrapping.
Same with 32E/42E and 32F/42F.
330 has the first 2/3 of the screen incorrectly drawn.

Perhaps said 1/3 screen and 2/3 screen being incorrectly drawn is some odd line width issue? Maybe an issue with the byte/word/dword mode selection that affects the whole scanline only(e.g. it's not in byte mode?)

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

Reply 6 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found the problem with those 3XX and 4XX modes. The problem was with the GPU framebuffer itself(where the emulator stores it's video buffer before resizing it to the used size(if any resizing is enabled, depending on the used video settings).

The framebuffer was only 2048x2048 pixels large, but the rendering had more than 2048 pixels horizontally. So of course it was rendering lines over each other(due to lines overflowing into the next line when rendering), due to the offset between lines being fixed(2048 in this case).

Increasing said lines to 4096 for the bigger framebuffer of course fixes that, but increases the memory usage drastically.
Edit: Just decreased the vertical framebuffer to 1024 to keep the size(4M 32-bit pixels, so 16MB framebuffer in total) the same as before. Although 1024p being framebuffered might not work on the old graphics cards anymore(due to vertical being cut off due to memory protection and unavailable memory area).

Of course the PSP builds have more extreme limits(since they only actually have 32MB RAM, which becomes about 20MB for all memory to use, thus only having a 1MP(1024x1024) framebuffer, which in effect makes all those SVGA 256-color modes and up being cut off(16-color should still work, though)).

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

Reply 7 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

So with those latest bugfixes, all graphics modes till 800x600 and all VGA modes work without problem afaik(up to 800x600x64K).

914-ET4000_800x600x64K.jpg
Filename
914-ET4000_800x600x64K.jpg
File size
142.3 KiB
Views
1089 views
File comment
ET4000 on UniPCemu in 800x600x64K colors
File license
Fair use/fair dealing exception

Of course, all non-VGA text modes seems to fail somehow(immediately returning to the main menu, probably a mode set error?).

Now the question is: what makes 1024x768 fail? It doesn't give ANY output on the screen for some odd reason.

Edit: Horizontal timings seems to be correct: it's reaching 1024 pixels active display, HRetrace at x location 1112, Horizontal total at 1265 clocks. So horizontal timings are fine.

Oddly enough, vertical retrace and vertical total are never applied? Hmmm...
Edit: Hmmmm.... I see both the logical scanline(by which to keep the CRTC timings) and CRT scanline being ridiculously high.... Hmmmm...
Edit: Hmmmm.... The vertical parameters are in the 1000-2000 range, but the cutoff of the valid usable range is actually 1024... I should increase it to 2048...
Edit: It's already 4096 as a range. The renderer was still using the old 1024 cutoff(ANDed with 3FFh) instead of the proper cutoff(FFFh).
Edit: Looking at the frame, it's a 1112x1615 large frame. Vertical limits are actually cut off(no overflow allowed), so that shouldn't be the problem. Now what's going wrong...

915-1024x768x16 colors going wrong..jpg
Filename
915-1024x768x16 colors going wrong..jpg
File size
77.44 KiB
Views
1085 views
File comment
1024x768x16 going wrong.
File license
Fair use/fair dealing exception

Looking at the renderer, I see everything going fine.

Maybe the some bug in the Read/Write banks(planar and odd/even modes)?

Edit: Hmmm... Maybe not. Looking at the generated vretrace signal(as horizontal timings works just fine), it's about 2300 lines in height(at 1280x1024). So having reversed it back to 4K resolution shows the whole picture(1280x1024), but the second half is still incorrect somehow.

So maybe that very large size isn't correct after all?

Edit: So the vertical timings are off in this case? The 1024x768 mode has double the vertical amount of lines it actually needs to have.... Hmmmm...
Edit: Wait a sec.... I seem to remember that mode using interlacing... Maybe there's a problem...

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

Reply 8 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Oddly enough, even though all modes but 1024x768 and up do work with the WHATVGA program, the 640x480x256 mode still goes wrong on Windows 3.0?

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

Reply 9 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Just trying Windows 3.1 with the ET4000 Win3.1 VGA disk from Vogons Drivers. So far tried 640x480x256 and 640x480x64K. Both run fine. The only problem that still seems to be there is some precalculations not updating when required it seems(seeing as pausing the emulator using the settings menu and then resuming it(which refreshes all video precalcs) fixes the screen display). Until those precalculations have ran, the display is stuck at two times too wide(off the displayable area for some odd reason). The active display is either not (half instead of full) wide enough by normal precalcs, or the division counters that handle that aren't working properly. I suspect the first(as the display still looks fine, only half an active display is shown).

Edit: Seemed to already have found it: updating the linear mode updating the CRTC and updating the character width from non-init value(to 8/9) or by main VGA module also needs to check the DCR(since the DCR gets combined with it and provides the Dot Clock halving required for linear mode to run properly).

917-Windows 3.1 on 640x480x64K colors.jpg
Filename
917-Windows 3.1 on 640x480x64K colors.jpg
File size
165.91 KiB
Views
1067 views
File comment
Windows 3.1 on UniPCemu running at 640x480x64K!
File license
Fair use/fair dealing exception
918-The current display mode 640x480x65K.jpg
Filename
918-The current display mode 640x480x65K.jpg
File size
159.52 KiB
Views
1066 views
File comment
The mode Windows 3.1 is running in on the ET4000 graphics card.
File license
Fair use/fair dealing exception
919-Windows 3.1 on 800x600x256 running.jpg
Filename
919-Windows 3.1 on 800x600x256 running.jpg
File size
178.5 KiB
Views
1065 views
File comment
Windows 3.1 on 800x600x256 also running.
File license
Fair use/fair dealing exception
920-Windows 3.1 on 800x600x64K.jpg
Filename
920-Windows 3.1 on 800x600x64K.jpg
File size
184.36 KiB
Views
1065 views
File comment
At 800x600x64K.
File license
Fair use/fair dealing exception

Of course, 1024x768 fails. Perhaps a problem with the interlacing?

Attachments

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

Reply 10 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

So, now all modes but @1024x768 are running without problems.

The odd thing is that it's the only 'interlaced' mode in the whole list of modes. Although I don't know if it's already interlaced or if that's something done on a real monitor only?

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

Reply 11 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Looking at the display, it looks like it's either wrapping at 2/3 of the screen during rendering or during plotting somehow? So that would be happening at line 512 and higher?

The logic to apply the horizontal rendering seems to work properly? Maybe an error in vertical rendering? Why would line 512 and up wrap to the beginning of VRAM?
Edit: It seems at that point, it reaches planar address 0x10000?

So the wrapping happens at exactly 512KB(assuming lines of 1024 pixels in 1024x768x16, which is the case(the value added to each scanline is 80h, so 1024 pixels per scanline). At line 512, it reaches planar address 0x80000, although it might also be another cause(e.g. 64K overflow)?

Edit: Hmmm... Maybe an issue with the mapping of the 64K read/write 3CD register? It was using the value shifted left by 16, but documentation says it's 16, 17 or even 18 shifted left and added to the address, depending on whether it's LG(Chain-4), OE0(Odd/Even submode?), OE1(Another Odd/Even submode?) or PG(Planar?)? Apparently PLX/PLY are the effective value of either the Segment Select register for the current read/write or the low 2 bits of the address bus(MA16/MA17 in effect in linear mode instead of segmented mode)?

Edit: Having modified the bits to be restricted to 2/3/4 bits depending on the mode and shifting the value to the upper bits of the address(18/17/16 respectively), the 1024x768 mode renders correctly now! 😁

Edit: Even 1280x1024x16! 😁

927-1280x1024x16 works!.jpg
Filename
927-1280x1024x16 works!.jpg
File size
104.02 KiB
Views
1021 views
File comment
1280x1024x16 even works!
File license
Fair use/fair dealing exception

Edit: So that means that now, when WHATVGA doesn't simply return to the main menu(on some lesser video modes than the highest??? E.g. 1280x9XX pixels), the images that are drawn are actually correct on the ET4000 emulation! 😁

So with those fixed, pretty much all ET4000 modes work on the ET4000 emulation! 😁

Edit: Just released these bugfixes on itch.io with a new UniPCemu update!

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

Reply 12 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

One odd thing that's occurrjng is that the mode set of all SVGA text modes and some graphics modes seems to fail? Anyone knows what might be the cause? Why does it return to the main menu with those?

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

Reply 13 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Looking at the mode set of all registers on all VGA resolutions render registers seems fine, but oddly enough the ET3000 BIOS improperly sets bit 1 of the Sequencer register 1 for DCR instead of bit 3. It also doesn't seem to set the Sequencer mode control Chain-4 bit when using VGA mode 13h, instead incorrectly rendering said mode in a planar method incorrectly(all pixels get skipped over 4 times with wrapping when rendering?

Anyone knows something about this?

Edit: Looks like that bit 1 being set is supposed to be set. But the sequencer memory mode register is supposed to be 0xE, which it obviously isn't? Perhaps a CPU bug?

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

Reply 14 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Said problem seems to be the same as I had with older builds: ET3000-AX BIOS contains problems?

So there is some odd CPU bug(or maybe ET3000AX ROM table error) that's causing the register to be loaded incorrectly somehow?

Edit: Perhaps interrupt 1Dh data errors?

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

Reply 15 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Maybe there's some CPU emulation problem that causes a misparsing of the ET3000 mode tables at interrupt 1Dh? Anyone knows the correct CRC of a ET3000 BIOS ROM?

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