MiSTer PCXT

[MicroCoreLabs]

Also as a curiosity, I have tried other ROMs, such as the original IBM ROMs like ibmjr, ibm5150/5160 and they don't work.

The PCjr ROM will not work in an IBM 5150/5160. The IBM 5150 and 5160 ROMs do a check of the timer and IRQ early in the POST which will result in the BIOS just halting if it fails. This code executes before anything is displayed to the CRT, so maybe this is where you are getting stuck on these ROMs...

My suggestion would be to use the IBM BIOS versions and sticking with it until you can boot to DOS. I think this is a good place to fail because the BIOS is published in the technical reference and you can trace the code where the POST is getting stuck which is much easier than when games get stuck as they are nearly impossible to trace at that point. This is how I did initial debug on the MCL86.. with multiple versions of IBM BIOS, and even the fixed disk controller's BIOS!

The MCL86 core and BIU are fairly well debugged and work with every version of IBM and third party BIOSes I have tried, so I suspect there is an issue with the emulated peripherals like your 8288 and he 8259. The real 8288 (and my BIU) use the rising edge of the CLK at the beginning of the cycle and negative edge in other places, so if your core does not support this the bus cycle could be corrupted. For interrupt cycles, the BIU will perform a double-read, so maybe your 8259 core is not supporting this correctly, or is providing the incorrect vector to the CPU. Or maybe the interrupt priority scheme is not emulated correctly.. Just a few thoughts on where to look...

The MiSTer FPGA is a big/fast device, but is there a chance your FPGA timing is not constrained enough and you are getting timing violations?

[spark2k06]

Thank you! It's a good idea to debug with the original IBM 5150/5160 BIOS. Next I'll intercept port 80h to identify the POSTs and as you say, we'll see where it stops.

Regarding the rest of the ideas, maybe they can be useful to @kitune-san regarding his KFPC-XT project that this core uses.

For the last question, I can't tell you, I don't have an answer

[MicroCoreLabs]

You could also try the SuperSoft Diagnostic ROM which also performs a few interrupt/NMI tests.

Actually, I also experienced some IRQ and keyboard errors when I ran my other 8086 core, the MCL86+, in a very accelerated mode...

Here's a video of it: https://www.youtube.com/watch?v=xXVImaMU7Hw

When I run cycle accurate there are no errors.

[spark2k06]

Very useful this ROM from SuperSoft!... here we can see some problems with the TIMER @kitune-san and also when reaching the MDA memory check, from which it does not pass... I will be able to check it myself:

SuperSoft Tests 01.png (460.59 KiB) Viewed 5172 times

[kitune-san]

Thank you for the information.
I will send you some kind of reply within 48 hours.

[spark2k06]

I have already managed to avoid the problem in MDA:

SuperSoft Tests 02.png (587.34 KiB) Viewed 5125 times

but it would be better if the system switch settings provide the correct information, such as CGA 80x25, as in the video from @MicroCoreLabs:

IBM PCXT Switches.png (853.2 KiB) Viewed 5125 times

Any ideas on how to do this? This information is provided directly by the PPI 8255?

[kitune-san]

Any ideas on how to do this? This information is provided directly by the PPI 8255?

for example:

Code: Select all

logic [7:0] sw = 8'b00000000;
port_c_in[3:0] = port_b_out[3] ? sw[7:4] : sw[3:0];

[MicroCoreLabs]

The motherboard DIP Switch-1 is for IBM's continuous POST self-test which will run forever if the switch is on. Maybe this is why the IBM BIOS locks up for you?

[spark2k06]

The motherboard DIP Switch-1 is for IBM's continuous POST self-test which will run forever if the switch is on. Maybe this is why the IBM BIOS locks up for you?

I have already configured the DIP Switches with kitune-san's suggestion, now they look good:

SuperSoft Tests 03.jpg (149.35 KiB) Viewed 4938 times

However, that's not the problem with 5150 and 5160 ROMs hanging, it still happens, and with no beeps. I've also tried Ruud's diagnostic ROM, this time it doesn't detect timer failures... however it's clear that there must be as the other test shows, because games like AlleyCat hang with a constant beeping sound:

Ruud Tests 01.jpg (139.17 KiB) Viewed 4938 times

Let's wait for kitune-san to check this issue. The keyboard glitch problem is common to both tests.

[jordi]

The motherboard DIP Switch-1 is for IBM's continuous POST self-test which will run forever if the switch is on. Maybe this is why the IBM BIOS locks up for you?

I have already configured the DIP Switches with kitune-san's suggestion, now they look good:

SuperSoft Tests 03.jpg

However, that's not the problem with 5150 and 5160 ROMs hanging, it still happens, and with no beeps. I've also tried Ruud's diagnostic ROM, this time it doesn't detect timer failures... however it's clear that there must be as the other test shows, because games like AlleyCat hang with a constant beeping sound:

Ruud Tests 01.jpg

Let's wait for kitune-san to check this issue. The keyboard glitch problem is common to both tests.

(discussed in private, I copy here)
Alleycat is one of the few first games that runs at perfect speed no matter of the CPU.

It uses a frame limiting technique, for sure, I guess developer had two alternatives:
1) CGA raster interrupts, explained very well here:
https://www.youtube.com/watch?v=FYj05Qw ... e=youtu.be
But they are not supported by mostly all VGA cards, and the game runs perfectly on them.

2) RTC.

or maybe both, by auto-detection

[kitune-san]

I found that using the latch function to read the counter causes KF8253 Timer to return 0.
The difference between an application that probably works and one that does not is whether or not it uses latches when reading.

[spark2k06]

2) RTC.

They don't have RTC, but maybe what you're referring to specifically is the use of the 8253 timer chip? which is one of the tests that is failing, in which case, it makes sense:

http://www.minuszerodegrees.net/5150_51 ... amples.htm

[kitune-san]

I have sent you a pull request.
I will report back to you if I find an enbug.

[spark2k06]

I have sent you a pull request.
I will report back to you if I find an enbug.

AlleyCat now works perfectly:



and also passes the SuperSoft test,although curiously, it now fails the "Interrupt Level 0" test, as did @MicroCoreLabs:

SuperSoft Tests 04.png (736.27 KiB) Viewed 4725 times

That's great! Thank you!

This weekend I will release a new beta version of the core

[kitune-san]

Awesome!

[spark2k06]

More good news, now the IBM 5160 BIOS is working... but only up to this point:

ibm_5160.jpg (58.26 KiB) Viewed 4671 times

Curiously the IBM 5150 version doesn't work... I must have dumped it wrong?

[breiztiger]

keyboard issus ...

[MicroCoreLabs]

The PC motherboard has a keyboard loopback path which the IBM POST is checking and needs to be present to pass. I don't think this path is ever used after this test though.

You may need to duplicate this and other logic paths on the motherboard to fully emulate the PC successfully.

[spark2k06]

In case it helps, I attach the keyboard test routine carried out in the ruud tests, where it also fails:

http://www.baltissen.org/zip/diagrom.zip

Code: Select all

;**  Check if a keyboard is present
CheckKeyboard:
	OutDebugB 78

	mov	si,TxtChkKeybCont
	call	TextToScreenA

	in	al,i8255A		; clear buffer

; Enable the keyboard
	mov	al,0Ch			; set keyboard CLK line low
	out	i8255B,al

; Delay
	xor	cx,cx
.L04:
	loop	.L04

	mov	al,0CCh			; set CLK, enable lines high
	out	i8255B,al

	nop
	nop

	mov	al,4Ch			; keyboard CLK high, enable low
	out	i8255B,al

; Now wait for an interrupt
	mov	al,0FDh
	out	PIC8259+1,al		; enable keyboard interrupt

	sti	

	call	CheckForINT		; has there been an interrupt?
	jne	.L20			; yes, -> OK
.L10:
	OutDebugB 9Ah

	mov	bx,ErrKeybCntr
	call	DisplayFailedA
	jmp	.L30

.L20:
	in	al,i8255A		; read value
	cmp	al,0AAh			; correct init code?
	jne	.L10			; no, -> error

	call	DisplayPassedA


; Disable all interrupts
.L30:
	mov	al,0FFh
	out	PIC8259+1,al

	cli


;**  Scan the keyboard for not expected output
CheckKeybScan:
	OutDebugB 80

	mov	si,TxtChkKeybScan
	call	TextToScreenA

; Disable the keyboard
	mov	al,0F8h
	out	i8255B,al

	nop
	nop

	mov	al,78h
	out	i8255B,al

	mov	al,0FDh
	out	PIC8259+1,al		; enable keyboard interrupt

; Now wait for an interrupt
	call	CheckForINT		; has there been an interrupt?
	jne	.L20			; yes, -> error

	call	DisplayPassedA
	jmp	.L30

.L20:
	in	al,i8255A		; read value
	push	ax

	mov	si,TxtStuckKey
	call	TextToScreen

	mov	si,TxtStuckKey2
	call	PlaceToScreen

	pop ax				; restore found key
	mov	ch,al			;  and move to CH

	mov	cl,4
	shr	al,cl			; get hi-nibble

	mov	bx,Tbl_ASCII
	xlatb				; transfer into ASCII

	mov	dx,SegmentMDA		; MDA screen
	mov	es,dx
	mov	ah,7			; attribute
	mov	[es:di],ax		; write to the MDA screen
	mov	[es:di+8000h],ax	; write to the CGA screen

	mov	al,ch			; get read byte again
	and	al,0Fh			; get lo-nibble

	mov	bx,Tbl_ASCII
	xlatb				; transfer into ASCII

	mov	ah,7			; attribute
	mov	[es:di+2],ax		; write to the MDA screen
	mov	[es:di+8002h],ax	; write to the CGA screen


	OutDebugB 9Ch

	mov	si,TxtChkKeybScan
	mov	bx,ErrKeybScan
	call	DisplayFailedA

; Disable all interrupts
.L30:
	mov	al,0FFh
	out	PIC8259+1,al

	cli				; disable interrupts

	mov	al,0FCh
	out	i8255A,al		; reset the keyboard

[MicroCoreLabs]

https://camo.githubusercontent.com/c258 ... 442e706e67

The two 7407's, sourced by the 8255, drive the keyboard clock and data for the loopback test.

[thorr]

Seeing this makes me want to hunt down my old GWBasic programs I wrote as a kid if I still have them somewhere.

[kitune-san]

Has anyone already tried to fix keybord issue?

[spark2k06]

Has anyone already tried to fix keybord issue?

I haven't tried it, right now I'm focused on adding the Graphics Gremlin MDA module, and being able to use it at the same time as a secondary display: HDMI and VGA.

On the other hand, can you think of any reason why it might not pass the "INTERRUPT LEVEL 0" test now, having solved the timer problem? The MicroCoreLabs tests also show that it doesn't pass this test... maybe it's not a big deal and does not affect the proper functioning of the system.

[kitune-san]

On the other hand, can you think of any reason why it might not pass the "INTERRUPT LEVEL 0" test now, having solved the timer problem?

Probably caused by the counter not being reset when writing the same data to the control word.
Could you try this patch?
https://github.com/kitune-san/PCXT_MiST ... f9bddd1464

[spark2k06]

On the other hand, can you think of any reason why it might not pass the "INTERRUPT LEVEL 0" test now, having solved the timer problem?

Could you try this patch?
https://github.com/kitune-san/PCXT_MiST ... f9bddd1464

Tested. Test still fails.

[kitune-san]

Thanks, I'll have a look at the BIOS code and give it some thought.

[spark2k06]

Thanks, I'll have a look at the BIOS code and give it some thought.

In case it helps, I attach the keyboard test routine carried out in the ruud tests, where it also fails:

http://www.baltissen.org/zip/diagrom.zip

Beware, Ruud's equivalent test (or at least I think it is the equivalent), does pass... both with and without this latest patch:

Code: Select all

;**  Check if INT0 is recognised = timer interrupt
CheckINT0:
	OutDebugB 66

	mov	si,TxtCheckINT0
	call	TextToScreenA

	mov	ax,00FEh		; clear counter and
	out	PIC8259+1,al		;  only ensable timer interrupt

	mov	al,10h			; select timer 0, LSB, mode 0, binary
	out	PIT8253Ctrl,al

	mov	ax,24
	out	PIT8253A,al

	mov	cx,ax

	sti	
.L10:
	or	ah,ah			; did an interrupt occur?
	jne	.L30			; yes, -> is good

	loop	.L10

; No interrupt occurred = error
.L20:
	OutDebugB 94h

	mov	bx,ErrINT0
	call	DisplayFailedA
	jmp	CheckNMI

The problem is the SuperSoft test, which used to pass, but since the timer solution, it no longer does. I don't know if this software has source code, otherwise it would have to be disassembled.

[kitune-san]

Has anyone already tried to fix keybord issue?

The keyboard controller does not fully reproduce the circuitry of the XT.
The current PCXT only has the circuitry to convert the received PS/2 scancode to XT.
Additional circuitry must be added to pass the test.

[MicroCoreLabs]

The MicroCoreLabs tests also show that it doesn't pass this test... maybe it's not a big deal and does not affect the proper functioning of the system.

Hmm... the MCL86+ failed because it was running greatly accelerated. When it is running cycle-accurate it passes all tests. My other core, the MCL86 which is the one you are using, also passes all of the SuperSoft tests when running cycle accurate.

When you ran MIPS.EXE your setup measured more than 10% faster than the stock IBM PC, right? Perhaps even this amount is too much for the SuperSoft test to pass.

I suggest looking at the SuperSoft manual for their explanation why Interrupt Level 0 fails. This test appears to cover the 8253, 8259, and the 8288.

[spark2k06]

This is the result of MIPS 1.10 and landmark speed 1.14 at the moment:

mips_110.jpg (134.86 KiB) Viewed 4247 times

landmark speed 1_14.jpg (117.39 KiB) Viewed 4247 times