VOGONS


IBM EGA and text mode woes

Topic actions

Reply 20 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

I get one long beep, three short beeps, some delay, then one beep(the same as the Turbo XT BIOS POSTing normally gives). Usually that last beep is before booting any available storage medium(floppy, HDD).

The hang occurs at C400:0173, with 3 instructions:

IN AL,DX
SHRB AL,1
JC 0173

The screen is black for some reason, dumping VGA reveals that it's properly programmed: 640 pixels horizontally and 350 pixels vertically of active display(first 15 pixels horizontally being overscan only). 365 pixels vertical total and 800 horizontal total.

Edit: Inspecting the VGA dump(made using the Settings menu option to dump the VGA), I see that the (VGA) font ROM isn't loaded at all?

Last edited by superfury on 2017-02-20, 15:05. 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 21 of 37, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

(sorry if you read this in the manual already)

One long and 3 short beeps means EGA_MEM_ERROR (page 116 in the pdf). Which can come from a bunch of places on page 115. This is the attribute read/write stage. Which is actually very good as you passed the point where I error out.

That is if nothing else in your emulator also generates same beeps.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 22 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

Inspecting the VGA dump(made using the Settings menu option to dump the VGA), I see that the (VGA) font ROM isn't loaded at all? So the BIOS seems to POST until clearing the screen(probably a AH=00 function of the Video BIOS to set the new video mode to continue on), which makes it hang waiting for (V)Retrace.

Why would the character ROM not be loaded at all on the EGA?

Edit: those beeps are also generated by the XT BIOS POST tests before showing display(kind of an All OK message from the BIOS afaik. Then that second beep after some time could be the start of the Screen clear(mode set) and passing control to the hard disk ROM to boot(INT19 call), which clears the screen and shows hard disk info and start booting. It could be the clear screen using INT10 function 00h that's locking it up. Although, since the VRAM is empty, it's probably some kind of percieved 'RAM errror'. Does the EGA handle VRAM the same way as the VGA? So the entire memory map is identical?
Also, is the RAM enable(enabling the VRAM window) on VGA the same way as EGA?

Edit: Just looked at the BIOS code within http://minuszerodegrees.net/oa/OA%2520-%2520I … 2520Adapter.pdf and I couldn't find any mention of the code I listed earlier. Maybe the 8086 CPU has an error?

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

Reply 23 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just made a big dump file(1.5GB of raw text dump) of the BIOS running for a few minutes. I see it executing a INT10 call to the BIOS it self at F000:XXXX, until eventually INT10 with AX=0007 is executed, which vectors into C000:0CD7.
The next call to INT10 is at C000:0165 with AX=0003.
Then at C000:0155 with AX=0001.
Then C000:037A with AX=0500.
Then F000:E335 with AX=1200,
F000:E350 with AX=0100,
F000:F9D2 with AX=0600,
F000:F9DA with AX=0228 etc. (At the end of the log it's executing the normal BIOS as far as I can see, so probably POSTing).

https://www.dropbox.com/s/0he5r9xveeork84/deb … 21_1442.7z?dl=0

The hanging point is at C400:0173(IN AL,DX, SHRB AL,1; JC 0173). So the problem is actually the XT-IDE BIOS for some reason(configured for VGA)?

One thing I notice though: the entire VRAM is cleared(zeroed), with the Misc Output register bit 1(VRAM enable) being 0, disabling VRAM from CPU access? Why would this be the case?

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

Reply 24 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

Looking at the source code of the BIOS at http://minuszerodegrees.net/oa/OA%20-%20IBM%2 … s%20Adapter.pdf , I'm a bit confused about the switches:

INFO ... 07 - HIGH BIT OF MODE SET, CLEAR/NOT CLEAR REGEN 06 - MEMORY 06 05 = 0 0 - 064K 0 1 - 128K 05·- MEMORY 1 0 - 192K 1 1 […]
Show full quote

INFO ... 07 - HIGH BIT OF MODE SET, CLEAR/NOT CLEAR REGEN
06 - MEMORY 06 05 = 0 0 - 064K 0 1 - 128K
05·- MEMORY 1 0 - 192K 1 1 - 256K
04 - RESERVED 03 - EGA ACTIVE MONITOR (0), EGA NOT ACTIVE (1)

02'" WAIT FOR DISPLAY ENABLE (1)

01 - EGA HAS A MONOCHROME ATTACHED (1)

DO - SET C_TYPE EMULATE ACTIVE {OJ

The code loading the switches:

POR_l PROC NEAR
0092 EE 660 C OUT DX,Al
0093 50 66' e PUSH AX
0094 58 662 C POP AX
0095
0096
0098
009A
EC
24 10
DO E8
C3
66.
664
665
666
e
e
C
C
IN
AND
SHR
RET
Al,OX
AL,010H
AL,l
009B 667 C POR_l ENDP
668 C
66. 0 ;----- READ THE SWITCH SETTINGS ON THE CARD
610 0 009B 671 0 RO_SWS PROC NEAR 612 0 ASSUME DS:ABSO
009B
0090
009F
B6 03 B2 C2
BO 01
613
61.
615
0
0
0
HOV
HOV
HOV
oH,3
Dl, M t SC_OUTPUT Al, ,
OOAl EE 616 0 OUT DX,Al
611 0
618
61. 0
0
;----- COULD BE 0,4,6,C
00A2
00A4
00A7
00A9
OOAB
OOAO
BO 00
Show last 91 lines
E8 0092 R
DO E8
DO E8
DO E8
8A 08
680
681
682
68.
68'
685
0
0
0
C
0
C
HOV
CAll
SHR
SHR
SHR
HOV
Al,ODH
POR_'
Al,l
Al,1
Al,l
Bl,Al
686 C OOAF
OOBl
00B4
00B6
00B6
BO 09
E8 0092 R
DO E6
00 E8
0'\ 08
681
688
68'
6'0
691
0
0
C
e
e
HOV
CAll
SHR
SHR
OR
Al,9
POR_'
Al,l
Al,l
Bl,Al 692 e 008A 80 05 6'3 e HOV Al,5
ooae E8 0092 R 694 e CAll POR_l OOBF
OOCl 00 E8 OA 08 695
696 e
e SHR
OR Al,l
~ Bl,AL
691 e
DOC3
00C5
BO 01
E8 0092 R
698
699
e
e HOV
CAll
Al,l
POR_l OOC8 OA 08 100
101
e
e
OR Bl,Al
OOCA
OOCO
80 E3 Of
C3
702
703 e
e AND
RET
Bl,OFH
OOCE 104 e RD_SWS ENOP

The start of the procedure sets the Misc Output register to 1.
POR1 writes the value in AL to the Misc Output Register(to set the register), then reads the Input Status #0 register shifted right by 1 into AL.

First switch 4 is read, shifted to position 0(bit 0) and moved into BL.
Then switch 3 is read, shifted to position 1(bit 1) and ORed into BL.
Then switch 2 is read, shifted to position 2(bit 2) and ORed into BL.
Finally switch 1 is read, shifted to position 3(bit 3) and ORed into BL.

So at this point, BL contains the values of the four switches, bit 0 being switch 4 and bit 3 being switch 1(stored in that order).

Finally the high(unused) bits of BL are masked off. BL contains the value of the switches read from the hardware switches(bit0=switch 4, bit1=switch 3, bit 2=switch 2, bit3=switch 1, so essentially the four switches reversed in bit order(bit0=highest switch, bit3=lowest switch)). So it's the literal value of the four switches(currently "Off On On Off"=Enhanced Display Hi-res mode), converted to binary(On=Switch Closed=0) making the switches value read contain the value 1001b.

So the switches are read raw and not being XORed? So the variable containing 1001b(with Enhanced Display Hi-res mode), causing the BIOS to see the values as being "MONOC SECONDARY. EGA HI RES ENHANCED"(according to line 594)? So, the switches are read correctly? CGA being Off Off Off On=1110=Reserved? And MDA being Off Off On Off=1101=Reserved?

So, according to http://www.minuszerodegrees.net/ibm_ega/ibm_e … ch_settings.htm (Off being Open):
EGA = Off On On Off => 1001b=MONOC SECONDARY. EGA H I RES ENHANCED
CGA = Off Off Off On => 1110b=RESERVED
MDA = Off Off On Off => 1101b=RESERVED

That cannot be right? Unless the value read from the switch isn't reversed:
EGA = Off On On Off = 0110b=HONOC SECONDARY, EGA COLOR, 40X25
CGA= Off Off Off On => 0001b=MONOC PRIMARY, EGA COLOR. 80X25
MDA=Off Off On Off=>0010b=MONOC PRIMARY, EGA HI RES EMULATE (SAME AS 0001)

The second case would be correct(since the first case would have invalid values)? So On=Closed=1?

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

Reply 25 of 37, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

According to PCem:

/*3C2 controls default mode on EGA. On VGA, it determines monitor type (mono or colour)*/
int egaswitchread,egaswitches=9; /*7=CGA mode (200 lines), 9=EGA mode (350 lines), 8=EGA mode (200 lines)*/

When I return 9 value for switches (1001 - Off On On Off) the EGA BIOS will set up 320x350 (basically 640x350 with with half clock). When I return 7 or 8 the EGA BIOS will set up 320x200 mode.

Of course for me it fails the self verification. Had it not I assume I would get 640x350 for switches value 9 and 640x200 for switches value 7 or 8.

SarahWalker might know more about this.

I also do not understand what the "PRIMARY" and "SECONDARY" means in the EGA doc referring to monochrome display. As in I have 2 cards? Or 2 monitors?

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 26 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

This is what I get, trying to use the EGA emulation(VGA is working without problems):

Filename
EGA_VGAdump_UniPCemu_20170221_1512.zip
File size
10.2 KiB
Downloads
62 downloads
File comment
VGA dump of Turbo XT BIOS booting on UniPCemu's EGA emulation.
File license
Fair use/fair dealing exception

As can be seen in VGA_VRAM.DAT, the VRAM is completely empty(so no font ROMs). Also the Misc Output register(first byte in VGA_ExternalRegs.DAT, followed by the Feature Control register, Input Status 0 register, Input Status 1 register and the four data latches for each plane(ordered plane 0, plane 1, plane 2, plane 3; 1 byte for each plane)) is cleared. Why does it clear the Misc Output Register, disabling all VRAM access for the BIOS?

UniPCemu currently flips all bits in the used configuation(where 0 is Off and 1 is On) to obtain the value returned on the Input Status #0 register:

	case 0x3C2: //Read: Input Status #0 Register		DATA
//Switch sense: 0=Switch closed(value of the switch being 1)
switchval = ((getActiveVGA()->registers->switches)>>GETBITS(getActiveVGA()->registers->ExternalRegisters.MISCOUTPUTREGISTER,2,3)); //Switch value to set!
switchval = ~switchval; //Reverse the switch for EGA+!
SETBITS(getActiveVGA()->registers->ExternalRegisters.INPUTSTATUS0REGISTER,4,1,(switchval&1)); //Depends on the switches. This is the reverse of the actual switches used! Originally stuck to 1s, but reported as 0110!
*result = getActiveVGA()->registers->ExternalRegisters.INPUTSTATUS0REGISTER; //Give the register!
ok = 1;
break;

What the code does is:
- Take the current value from the Input Status 0 register that's globally emulated.
- Take the switch bit from the switches, whose bit number(0-3) is selected by the two bits(3) with the lowest bit at bit 2(2).
- Flip all bits to get the correct switch value to use(6 is in the switches atm, so 0110b becomes 1001b which is displayed on the Switch sense(bit 0 for misc output register clock 0, bit 1 for misc output register clock 1 etc.)
- Set bit 4 of the Input Status 0 register to the calculated switch bit value.
- Give the Input Status 0 register as a result, while counting the current register as responding(1). Other values for OK are 0(no response) and 2(response by submodule to ignore the result and give no result(used for SVGA and CGA/MDA emulation).

Last edited by superfury on 2017-02-21, 14:38. Edited 2 times in total.

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

Reply 27 of 37, by Gamecollector

User metadata
Rank Oldbie
Rank
Oldbie

@vladstamate: You can simultaneously use 2 display adapters in IBM XT. CGA and MDA. One is selected as the primary videocard.
EGA can replace any of them.
"EGA connected to Monochrome monitor" = the card replaces and emulates MDA. Uses the B000 segment, supports mode 7 only etc...

Asus P4P800 SE/Pentium4 3.2E/2 Gb DDR400B,
Radeon HD3850 Agp (Sapphire), Catalyst 14.4 (XpProSp3).
Voodoo2 12 MB SLI, Win2k drivers 1.02.00 (XpProSp3).

Reply 28 of 37, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

In the end I finally got EGA emulation working. Some screenshots: CheckIt, Sierra's Police Quest and SSI's Eye of the Beholder.

I had few issues like not correct timing, wrong hsync/vsync but once I fixed those the IBM EGA BIOS can properly pass its self test.

Attachments

  • pq.png
    Filename
    pq.png
    File size
    105.32 KiB
    Views
    913 views
    File comment
    Police Quest
    File license
    Fair use/fair dealing exception
  • eob.png
    Filename
    eob.png
    File size
    96.12 KiB
    Views
    913 views
    File comment
    Eye Of the Beholder
    File license
    Fair use/fair dealing exception
  • checkit.png
    Filename
    checkit.png
    File size
    141.45 KiB
    Views
    913 views
    File comment
    CheckIt !
    File license
    Fair use/fair dealing exception

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 29 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

Are there any differences in EGA VRAM vs VGA VRAM? It looks the same when I look at it. The EGA(which is emulated using large parts of the VGA) in UniPCemu fails the tests(With probably memory errors, according to the beep codes. One long, three short). VRAM is implemented according to freeVGA docs.

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

Reply 30 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

I see that the boot BIOS loads the correct value read from the switches(9) and continues on at PST_9(location 1D2). After that it executes a mode switch to mode 07h, finally to execute a mode switch to mode 03h, which leaves AH with value 03h? Logging while the entire POST of the EGA BIOS is executing, I see that it calls interrupt 42h, which seems to be mapped to segment F000(The Generic Super PC/Turbo XT BIOS handler)? Eventually it looks like it's writing into the RAM UMA memory hole(instead of VRAM, which doesn't seem to be enabled and at that location) at segment B800?

Filename
UniPCemu_EGAPost_20170225_1737.zip
File size
558.6 KiB
Downloads
51 downloads
File comment
Log of the EGA POST running, writing to RAM memory of the real RAM instead of the EGA.
File license
Fair use/fair dealing exception

The value at the INFO_3 containing the switches seems to be 09h, which is the inversed value of the switches (Off, On, On, Off). This is used, after multiplication and addition, to vector to PST_9. Is that happening in your case as well?

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

Reply 31 of 37, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

Eventually it looks like it's writing into the RAM UMA memory hole(instead of VRAM, which doesn't seem to be enabled and at that location) at segment B800?

I don't follow. It should write at B8000. That is where it expect the text mode memory to be throughout all the self checking. Where is yours set up to be?

superfury wrote:

The value at the INFO_3 containing the switches seems to be 09h, which is the inversed value of the switches (Off, On, On, Off). This is used, after multiplication and addition, to vector to PST_9. Is that happening in your case as well?

This is the order of INT 10h calls during boot time for me (useful since this is what PST_1,2,3,..9 do):

Int 10 AH 0x00 AL 0x30 BH 0x80 BL 0x00
Int 10 AH 0x00 AL 0x20 BH 0x80 BL 0x00
Int 10 AH 0x00 AL 0x03 BH 0x80 BL 0x00
Int 10 AH 0x00 AL 0x07 BH 0x00 BL 0x12
Int 10 AH 0x00 AL 0x03 BH 0x00 BL 0x12
Int 10 AH 0x00 AL 0x01 BH 0x00 BL 0x12

<- self testing starts here if you fail you do not see any more INT 10h calls after the one above.

Int 10 AH 0x00 AL 0x0e BH 0x00 BL 0x0f

<-self testing done

Int 10 AH 0x00 AL 0x07 BH 0x00 BL 0x12
Int 10 AH 0x00 AL 0x03 BH 0x00 BL 0x12

<-- now normal BIOS works and does POST and DOS booting.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 32 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

I remember PST_9 executing a mode switch using INT10 AX=0007, which redirects to INT10 AX=0003. Upon IRET, INT10 AX=0003 is executed, after which the beeps occur(Through Turbo XT BIOS or EGA BIOS. Which one I don't remember. I remember posting it domewhere(or planning to, but might haven't due to the "Always log" option not logging during skipping), but I'll make a new one later today(with the new, improved logging(logging when I use skip on the UniPCemu debugger as well. The old "Always log" option didn't log when skipping to the next instruction(e.g. the instruction after the CALL/INT etc. instruction that's skipped using PSP square/PC NUM4 key in the emulator debugger).

I don't remember seeing any AL=0x30/0x20 mode switches in that log. Just PST_9, of which the mode 7h mode switch uses STI, compares with 7 and executes INT10 AX=0003 a few instructions later.

Edit: Tried the latest(last version) IBM XT BIOS as well. The result is the same(not the fault of a BIOS incompatibility afaik).

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

Reply 33 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

This is the log of the emulator executing the EGA POST, which looks like it's reading the non-existant port 3DA(reading 0xFF bytes because the EGA doesn't respond to it: it's in monochrome mode, thus the status register is located at I/O port 3BA instead).

https://www.dropbox.com/s/jhk0fbjim8tow3f/deb … 5_2201.zip?dl=0

As can be seen, I've switched the CPU emulation to 80386 to make sure no unexistant opcodes are present(doesn't seem to be the case: the Turbo XT BIOS #UD handler creates an infinite loop, returning to the faulty opcode). Since this isn't seen, the CPU doesn't trigger any #UD instructions, thus only encountering valid instructions. Although it's at the cost of more logging space(longer and more registers to be logged).

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

Reply 34 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

After looking at your code again, I noticed a few things:
- The font RAM(plane 2) isn't used. UniPCemu does use it, thus no fonts without RAM(yours forces a Dosbox font?).
- The result of the input status register with the switches(#0) is missing all bits but the switch result itself.
- I see no MUX bits in the required register?
- UniPCemu still misses the lightpen trigger ports.

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

Reply 35 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just improved the CGA light pen emulation(after cross-referencing the chip documentation with reenigne's blog on the light pen) to make the CGA light pen probably a better version of what it always was. I've also improved the emulator's GPU to use the right mouse button when the mouse isn't mounted to enable the light pen input instead of normal input(not mounting the mouse when releasing the left button while the right mouse button is pressed).

Now the right mouse button enables the GPU(emulator video core) to see the mouse location as the light pen position when the virtual beam arrives at the light pen location, while taking the current position when manually probed(when accessing port 3DC). When the right button isn't pressed, the location is essentially location "-1,-1", so not being detected on the screen(by the video card renderer), because all CRTC coordinates are 0,0 and up. The left button when the right button is held triggers pressing/releasing the button of the light pen.

When the virtual CRT beam arrives draws anything on the screen, the current location is latched into the CGA/EGA light pen registers. The light pen button state is updated, for every rendered pixel, with the current light pen button state(1=Pressed, 0=Released? The documentation says that "0=Switch on"? But the EGA documentation of it's BIOS code says that the bit should be 1 to be pressed(only then will it read the light pen location and return pressed on the INT10 function call?)).

Although the light pen response doesn't require the pixel to light up, like on a real screen, it should improve the response of the light pen?

Is this behaviour correct? Reenigne?

Edit: I've managed to get the light pen emulation somewhat working:
Current CGA emulation lightpen support: https://bitbucket.org/superfury/unipcemu/src/ … mda.c?at=master

EGA variant is much the same, except for the bits in the special data register being shifted down to bits 0,1,2 instead of CGA's bits 1,2,3(bits 0 is reserved for the CGA/VGA enable compatibility mode switches combined with bit 7).

It now detects the coordinates correctly, trying to run reenigne's demo drawing software(Compiling this code from his repository: https://github.com/reenigne/reenigne/blob/mas … n/lightpen3.asm )

The offset CGA_checklightpen receives in it's currentlocation parameter is the raw column(including row) logic from the loading of the character planes(both graphics and text modes):

	//Column logic
vramlocation = Sequencer->memoryaddress; //Load the address to be loaded!
lightpen_currentvramlocation = vramlocation; //Save the new current location for light pen detection!

//Column/Row logic
vramlocation = patch_map1314(VGA, addresswrap(VGA, vramlocation)); //Apply address wrap and MAP13/14?

//Now calculate and give the planes to be used!
loadedplanes.loadedplanes = VGA_VRAMDIRECTPLANAR(VGA,vramlocation,0); //Load the 4 planes from VRAM, as an entire DWORD!

It's the lightpen_currentvramlocation variable that's passed. The Sequencer->memoryaddress variable contains the following data on the start of each row, which increments by one each character clock:

	charystart = VGA->precalcs.rowsize*row; //Calculate row start!
charystart += Sequencer->startmap; //Calculate the start of the map while we're at it: it's faster this way!
charystart += Sequencer->bytepanning; //Apply byte panning!
Sequencer->memoryaddress = Sequencer->charystart = charystart; //What row to start with our pixels! Apply the line and start map to retrieve(start at the new start of the scanline to draw)!

Is that behaviour correct? It seems to work without any problems. One thing I do notice is that, for some reason, the button on the lightpen is completely ignored? The strobe receiving a location the lightpen is pointing to is always used as an indicator to start drawing? Isn't this usually supposed to be saving the location only, then drawing once the button is pressed?

I assume the EGA version of the light pen works identically?

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

Reply 36 of 37, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

One thing I do notice is that, for some reason, the button on the lightpen is completely ignored? The strobe receiving a location the lightpen is pointing to is always used as an indicator to start drawing? Isn't this usually supposed to be saving the location only, then drawing once the button is pressed?

Yeah, probably - but that's a function of the program that interfaces with the light pen, not a function of the hardware/emulator. With that little program I was just trying to get the light pen to work at all, so I didn't bother implementing the code to read the button.

Reply 37 of 37, by superfury

User metadata
Rank l33t++
Rank
l33t++

I'm just wondering: has anyone ever tried to make a little module to put between the CGA/EGA and the monitor to implement a truly accurate 'lightpen' by measuring the location given by the video card(measuring horizontal and vertical timing outputs to deduce the beam, maybe patching the signal to fix the problem with black output(maybe making it a little bit lighter to make the lightpen detect it always)? Or simply use a LCD screen with virtual lightpen support build in for the CGA/EGA(and know the beam location through the video card inputs and using a touch screen to give a pulse every time the virtual beam(as virtualized by the monitor, I assume(it needs to virtualize anyway, due to the CGA/EGA timings being analog, using the pixels clock output signals(hretrace/vretrace etc.) to keep a virtual beam location)) crosses the point that's pressed on the screen? Maybe a seperate button on the monitor's side to implement the button on the lightpen(it's just a simple digital on/off afaik?)?

@reenigne: I assume you just wanted to make the lightpen function as a sort of brush? So it won't generate any input(nothing handled) when not close to the screen(in my emulation, it's coordinates are -1,-1 at that time, thus not triggering any 'pulses'/latching), but will generate input(like 'dipping' the brush into the palette or drawing with it on other parts of the screen) when held close enough to the screen?

Otherwise, the lightpen support on Windows/linux should be working without problems. Simply compile UniPCemu from the repository, configure it correctly(EGA isn't POSTing correctly yet) and boot it in CGA mode. You can now use the right mouse button to hold the lightpen at the cursor location, while holding the left mouse button when holding the right mouse button(the other way around, holding the left mouse button first and then the holding the right, does still trigger the Direct Input mode. This functionality is just disabled when holding the right mouse button first to allow for the Light Pen to be used without problems) will press/release the Light Pen button. Releasing the right mouse button will release the Light Pen button(mapped to the left mouse button) and take the virtual Light Pen away from the screen(returning it's coordinates effectively to -1,-1(thus making the CGA/EGA not see it latched anymore)).

I notice that pressing the CGA Light Pen button during text mode makes the cursor become a full block cursor instead of the normal cursor, while releasing the button makes it return to the normal MS-DOS prompt cursor(any cursor during the boot process, though)? Is that correct behaviour? Does this confirm my button support is working correctly?

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