One thing that's odd is this: even though the Generic Turbo XT BIOS shows it exists, it doesn't supply anything for it. It just detects it, displays it's there and continues doing other things. Couldn't the maker have added full BIOS support for that RTC chip if he already planned on displaying it (seemingly 'supporting' it by the BIOS)? He could just as easily implement an interrupt 1Ah BIOS interrupt for that chip(actually all three chips seem upwards compatible at least)?

All it has is this simple routine:

1;---------------------------------------------------------------------------------------------------
2; Interrupt 1Ah - Time Of Day Clock
3;---------------------------------------------------------------------------------------------------
4	entry	0FE6Eh				; IBM entry, time_of_day clock
5proc	int_1A	far
6
7	sti					; User time_of_day BIOS service
8	push	ds
9	push	ax
10	mov	ax, 40h
11	mov	ds, ax
12	pop	ax				; Get request type
13	cli					;   pause clock
14	or	ah, ah
15	jz	@@read				; Read time, ah=0
16	dec	ah
17	jnz	@@end				;   invalid request
18
19@@set:
20	mov	[ds:6Ch], dx			; Set time, ah=1
21	mov	[ds:6Eh], cx			;   set time high
22	mov	[byte ds:70h], 0		;   not a new day
23	jmp	short @@end
24
25@@read:
26	mov	cx, [ds:6Eh]			; Read low order time
27	mov	dx, [ds:6Ch]			;   high order time
28	call	@@reset				; Read resets overflow
29
30@@end:	sti					; Resume clock
31	pop	ds
32	iret
33
34@@reset:
35	mov	al, [ds:70h]			; Zero the overflow and return
36	xor	[ds:70h], al			;   previous status in flags
37	retn
38
39endp	int_1A

superfury wrote:

One thing that's odd is this: even though the Generic Turbo XT BIOS shows it exists, it doesn't supply anything for it. It just detects it, displays it's there and continues doing other things.

The RTC doesn't 'do' anything. It's just that the version of DOS released with the AT knows that the AT has an RTC, and if it detects this, it will set the DOS time to the RTC's time on startup.
If there's no RTC, it will prompt the user to enter date/time.
For other RTCs, a driver was usually included, which did the same from config.sys or autoexec.bat.

superfury wrote:

He could just as easily implement an interrupt 1Ah BIOS interrupt for that chip(actually all three chips seem upwards compatible at least)?

But the XT didn't have that in BIOS, so why would a clone XT BIOS have it?

It could be implemented to provide a simple replacement of the TIMER.COM v1.2 that has to be loaded by MS-DOS on boot? Why put something that's not XT on a clone XT motherboard (That Samsung clone's XT BIOS) and not even provide support for it in the BIOS in some way?

The Samtron 88S apparently has it integrated into their motherboard, but it isn't used by the BIOS? Why even put something in there when you don't even use it? Nor provide any standard way for the software to access it (using BIOS calls)?

superfury wrote:

It could be implemented to provide a simple replacement of the TIMER.COM v1.2 that has to be loaded by MS-DOS on boot? Why put something that's not XT on a clone XT motherboard (That Samsung clone's XT BIOS) and not even provide support for it in the BIOS in some way?

The Samtron 88S apparently has it integrated into their motherboard, but it isn't used by the BIOS? Why even put something in there when you don't even use it? Nor provide any standard way for the software to access it (using BIOS calls)?

Probably because clones had to be as cheap and simple as possible, and almost nobody wrote their own BIOS. They just bought it from companies like Phoenix, AMI or Award. Getting every BIOS customized for every motherboard would probably be a lot more expensive than just having some DOS utilities. Besides, software didn't use those BIOS APIs anyway, so nobody cared.

PCs weren't these nice feats of engineering. They were more like Frankenstein machines. Whoever built them the cheapest, won.

OK. So most XTs didn't have a normal RTC(or at least not in the BIOS), but TIMER.COM v1.2 is a seperate program using those chips to load and store time from that RTC chip, so it's only supported in software, but not in the BIOS(Interrupt 1Ah).

But we were originally talking about the AT emulation, not XT emulation. Why did the BIOS error out on the floppy disk controller? The RTC chips seems to be working without any problems, so why does it error out on the Recalibrate/Seek operations? Both simply cannot succeed, seeing as there's no media in the drive to synchronize to: without any media in the drive, it can't find the start (track identifier) of a track. So if there's no identifier, those seek (both normal seek and recalibrate) can't synchronize to anything at all(there's no track id or anything to synchronize to), so they must fail, right? Why should they succeed if they theoretically cannot succeed ever, without a media in the drive?

It's like the floppy drive telling me(taking a box of banana's as an example): "Here, i am now standing on top of this banana at this location in the box, even though it's an empty box". It shouldn't be theoretically (and practically) possible?

Edit: Just tried running Day of the Tentacle demo on the 80286 XT emulation. It starts, but then I get some ridiculously large copyright text which prints directly after it each time I hit a key?

Is there some kind of 80286 testsuite, like the 80186 one I used earlier to fix my emulator (also used for fake86 apparently) to fully test the 80286 emulation, and to test whether or not it's got errors?

superfury wrote:

OK. So most XTs didn't have a normal RTC(or at least not in the BIOS)

There is only one XT, the IBM model 5160 PC/XT.
Everything else is an XT clone.
Since there was no RTC, there was no BIOS API for it in the XT, and also not in most clones. The BIOS API wasn't introduced until the AT.

superfury wrote:

But we were originally talking about the AT emulation, not XT emulation. Why did the BIOS error out on the floppy disk controller?

As I say, you need to configure the drive parameters in the CMOS with the SETUP program. Is it possible that the BIOS calibrate/seek operations fail because the CMOS configuration is wrong?

Well, the problem with the AT is that it cannot boot, because it's refusing to properly initialize the AT "PS/2" keyboard. Since the keyboard initialization aborts halfway due to the keyboard error, F1 cannot be pressed to make it continue booting from the harddrive.

So the problem is currently that I have to fix the 8042&PS/2 keyboard combination in order to even boot and enter that SETUP program, which is on a floppy disk (which I don't have btw, nor can I find it anywhere on the internet).

Trying the other BIOSes, like that AMI BIOS etc. from the minuszerodegrees page, simply results in a black screen not doing anything at all, so those are pretty much unusable as well.

You guys keep saying that the problem is in the delay expected before the incoming result bytes, but even when that delay is implemented (5 milliseconds atm, also tried with 100ms) it refuses to initialize using the 0xFF reset command properly.

Running Day of the Tentacle on the 80286 with the Turbo XT BIOS(and XT-IDE BIOS) I end up with this(the emulator is in XT 286 mode):

Pressing any key makes the text add after the upward arrow(like it's simply printf()'ed/echoed after it). This repeats infinitely while the key is pressed(key presses are received).

superfury wrote:

So the problem is currently that I have to fix the 8042&PS/2 keyboard combination in order to even boot and enter that SETUP program, which is on a floppy disk (which I don't have btw, nor can I find it anywhere on the internet).

You can use a generic setup program, see here: http://classic-computers.org.nz/blog/2009-08- … disk-setup.html
Can be downloaded here: https://web.archive.org/web/20120126194038/ht … ware/GSETUP.ZIP
This should be an image for the original IBM AT diagnostics disk, which should contain the real setup program: http://www.minuszerodegrees.net/software/5170 … ostics_2.07.zip

The problem is that I can't boot on the AT: The CMOS supported on the AT isn't supported on the XT(Although the I/O ports exist on both emulations, since it needs part of that for the XT timer chip mirroring). Stuff like 80286+ instructions and protected mode won't work on the actual IBM XT emulation(80186 CPU).

This is the current result I'm getting trying to get the 80286 AT BIOS to work (keyboard is unresponsive due to invalid scancode set(scancode set 2 is currently being used, translation is disabled)):

Well yes, obviously you need to fix your keyboard first. But when you do, you should run the diagnostics disk and perform proper configuration.

I'm not surprised if an XT BIOS doesn't work on an 286 to be honest. It's a wild goose chase to try and make it work.

This is the current 8042 emulation:
https://bitbucket.org/superfury/unipcemu/src/ … 042.c?at=master

And this is the PS/2 keyboard connected to the first PS/2 port(the PS/2 mouse is only connected to the second PS/2 port when the architecture is set to PS/2. AT uses a serial mouse instead):
https://bitbucket.org/superfury/unipcemu/src/ … ard.c?at=master

It's associated lookup tables:
https://bitbucket.org/superfury/unipcemu/src/ … ata.c?at=master

Can you see what's going wrong?

I've modified the 8042 and PS/2 keyboard to apply improved timings. The 8042 now sends at 16.7kHz, with 12 cycles to send and 11 cycles to receive, according to http://www.computer-engineering.org/ps2protocol/ .
8042: https://bitbucket.org/superfury/unipcemu/src/ … 042.c?at=master
PS/2 keyboard: https://bitbucket.org/superfury/unipcemu/src/ … ard.c?at=master

The update8042 and updatePS2Keyboard take care of any timings required, based on the CPU time (in nanoseconds), like the VGA and other hardware that have their own clocks (Which are not based on the 14MHz clock crystal).

For some reason, the AT BIOS still errors out with the same error? Anyone can see what's going wrong here?

Btw what about the XT 286? There was a XT build of the 80286 just before the AT, apparently? The IBM PC XT 286 (5162), which is a rare IBM AT fit in a XT case or something similar? So essentially an IBM XT 286 still existed?

Edit: Apparently it was just an AT within an XT case with a few modifications, according to http://www.vcfed.org/forum/archive/index.php/t-26434.html

I've just fixed some bugs in the 8042 and PS/2 keyboard (8042 translation based on Bochs' translation method and https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html for the table). The F1 key and other keys now work properly now. I've also fixed the results of the 0xF0 0x00 command, which now properly result in 0x01, 0x02 and 0x03 (which, when translated, give the strange values that were returned earlier). Thus that part of the PS/2 keyboard is now working correctly as well.

The keyboard and Floppy drive errors still remain, however:(

After pressing F1, the IBM AT BIOS now properly starts the XT-IDE BIOS, which loads the OS from the sfdimg harddisk. Although after running MS-DOS, when starting Day of the Tentacle, it still gives me that strange screen with text repeating on every keypress. But at least it's basically 'booting' now, although with errors:)

Now to fix those ennoying floppy disk and PS/2(AT) keyboard errors. Anyone can see what's going wrong here?
8042 emulation: https://bitbucket.org/superfury/unipcemu/src/ … 042.c?at=master
PS/2 keyboard emulation: https://bitbucket.org/superfury/unipcemu/src/ … ard.c?at=master
Floppy disk emulation: https://bitbucket.org/superfury/unipcemu/src/ … ppy.c?at=master

Using the GSETUP program hangs when terminating and saving changes. It seems that after trying to use the AT BIOS again, it hangs before getting to the press F1 part. Just cleared the CMOS by using the settings menu (you can also just delete or corrupt(using any editor) the SETTINGS.DAT to make the emulator invalidate and load it's default values into the Settings). Since editing anything in the SETTINGS.DAT without properly updating the checksum and make sure the file size is compatible with UniPCemu, when trying to load it either the Checksum or the file size makes it fail loading and UniPCemu will simply load it's current version default settings and clear the emulated CMOS memory.

Edit: It appears the XT-IDE BIOS fails booting using the XT ROM with an AT BIOS (wrong jumpers, which aren't existant the same way on the AT). It refuses to detect the IDE harddisk in UniPCemu for some reason? Or it simply crashes detecting it? It simply says "Master at 1F0h:" with the cursor at the M position?

It says:

1Master at 1F0h: not found
2Slave at 1F0h: not found

It eventually crashes with an undefined GRP5 /7 opcode?

So what is the error code?

Any logs on 8042 port accesses, read/write to 60h and 64h?

Strangely enough, http://wiki.osdev.org/PS/2_Keyboard says that 0xFF should only give a response of 0xAA, but not 0xFA?

Although I've now gotten the AT BIOS up to the point It tries to execute the XT-IDE BIOS, I'm left with this:

1Master at 1F0h: not found
2Slave at 1F0h: not found
3Booting C>C
4<Cursorhere>

Although the > is actually a >> mark, which I can't simply type with the keyboard.

For some reason it doesn't detect the harddisk?

IDE ATA-1(and ATAPI partially) harddisk/cdrom emulation: https://bitbucket.org/superfury/unipcemu/src/ … ide.c?at=master

I've made a little log of the 8042 port 0x60 and 0x64 reads and writes:

8042 source code: https://bitbucket.org/superfury/unipcemu/src/ … 042.c?at=master
PS/2 keyboard source code: https://bitbucket.org/superfury/unipcemu/src/ … ard.c?at=master
PS/2 keyboard lookup tables: https://bitbucket.org/superfury/unipcemu/src/ … ata.c?at=master

Can you see what's going wrong?

I've been working on the ATAPI commands supported (ATA/ATAPI 4). Currently in the specification up to the Read CD command (e.g. all Music CD-ROM SCSI commands aren't implemented yet) is implemented.

So up to 10.8.15 of http://www.bswd.com/sff8020i.pdf is implemented (Mandatory commands only). Also some normal Mandatory commands for ATA-4 commands still need to be implemented (Currently it's ATA-1 for all hard disks, and ATA-4/ATAPI for CD-ROM drives).

I've finished implementing the IDE CD-ROM emulation.

The BIOS now crashes after detecting harddisks at address F000:1CBA? It's trying to execute opcode 0xFF Modr/m 0xFF?

The last instruction executed was 0xC3 (RET).

Edit: Looking at information generated by my debug build it reveals the RET was at C600:0000? Thus it might be an error in the VGA BIOS? Strangely enough, when I set the emulator to breakpoint at C600:0000, it doesn't trigger?

Strange enough, after working on it and trying to find the error by terminating emulation when it's executing an #UD(undefined) opcode exception, it never seems to reach this now and just resets the emulator?

I've started the emulator normally (breakpoint at checkpoint 43 #2, which is the start of the boot sequence INT 19 executed by the BIOS). Then I simply changed the debugger mode to "Enabled, RTRIGGER to step" and set the debugger log mode to "Always log". That way, it should log everything executed by the CPU between the INT 19 call, which starts the XT-IDE BIOS itself up to the point it reaches the #UD instruction, which should terminate the emulator. That way I would end up with a (rather huge) log file containing all instructions executed up to the #UD, which is done by the XT-IDE and AT BIOS combined. That way I should be able to find the cause of this.

Edit: Eventually ended up with a 1.5GB logfile. It now, for some reason, completely resets the CPU during the XT-IDE booting process for some reason?

https://www.dropbox.com/s/plbf5v98aexccvm/deb … 6_1243.zip?dl=0