Open nekochan777 opened 2 years ago
we all had the same problem. in my case there were interrupt controllers. this project is pretty sensitive on them. I also though that this is a keyboard controller. but it's not. so, try different PICs. i got a good result with AMD P8259A. the index "A" is important.
@nekochan777 display select switch must be checked before display initialization. Especially for MDA/CGA displays. So KBC needs to be initialized earlier. It does make sense not to halt in this case, but mark an error in a variable, maybe in BIOS data area, and print that later. With that being said, most AT BIOSes will fail to boot or show anything at all with failed keyboard controller or even if a not supported KCB type is installed. The BIOS outputs POST codes to port 0x80, and they can be used to figure out where exactly in the POST process the BIOS gets stuck. I do understand that not everyone has a backplane with a POST display or a POST card. An alternative could be using serial port to output debug information (and perhaps a BIOS option to enable/disable this).
@maxgvz PICs and PIT are essential to system operation, at least for timer interrupt. Moreover, the BIOS doesn't really test PICs, so if they faulty the system might fail to power on, boot, behave erratically, etc. All this is not really a software bug. Unless, one can write a code to actually test PICs during the POST, the BIOS will not report any errors
@skiselev "With that being said, most AT BIOSes will fail to boot or show anything at all with failed keyboard controller or even if a not supported KCB type is installed" Indeed some does and i even know few cases of black screen freeze because of dead CMOS battery, but question is it good practice? "An alternative could be using serial port to output debug information (and perhaps a BIOS option to enable/disable this)." that would be nice indeed! maybe if we couldnt find videocard switch console to serial. probaly we could be even able to boot to dos and got dos console at serial this way. @maxgvz in my case it was caused by kbc only and indeed without functioning PIC and timer it probably dont make sense to continue to boot, but things like kbc or dma is kinda optional imo. speaking of dma - recently i found some new motherboard which dont have dma enabled in chipset and it seems it doent cause any issues with dos and dos software other than no sound but it wouldnt be there anyway since there is no isa bus.
I wonder if it can be "faster"? in old 0.9.4 it inits display very fast, while latest version added ~20 seconds of delay without any display with Post Code 08.
EDIT:
kbc_ctr_timeout
can be in lower value.
for 86Box uses, kbc_ctr_timeout
can be lower to 1/10, i.e. 2000
.
I wonder if it can be "faster"? in old 0.9.4 it inits display very fast, while latest version added ~20 seconds of delay without any display with Post Code 08.
EDIT:
kbc_ctr_timeout
can be in lower value. for 86Box uses,kbc_ctr_timeout
can be lower to 1/10, i.e.2000
.
@roytam1, thank you for reporting this issue! I was able to reproduce it on my Xi 8088 system, created a separate bug, and resolved it already: https://github.com/skiselev/8088_bios/issues/63
Can you please download the latest BIOS image or the source code and test it?
Can you please download the latest BIOS image or the source code and test it?
it is much more faster, but still takes 5 seconds in Post Code 08 state.
hi! i was slowly collecting all necessary parts to solder and recently was able to do first power up attempt. it was playing tune but then nothing no image no nothing. it make me think something very wrong ! but after some time (couple month tbh) i found the only issue was keyboard controller. cheap chinese post card behave very unstable and didnt help much. so at some point i start mess around with bios code and find out that for some reason keyboard controller is considered some vital part and if it fail to initialize everything just halts ! from my experiments it seems very wrong. for example im able to boot to dos without working keyboard controller at all. so suggestion is: 1)move kbc_init to later stages AFTER video init. this will allow simple visual indication of "keyboard error" instead just freezing with blank screen. 2)i see kbc_init should get "display select" switch BEFORE video init. so other alternative to moving kbc_init is maybe do this: if that disp_select is really usefull for someone leave kbc_init where it is now, but in case of error not freeze but proceed to go further setting some "kbc_init_result" flag and after video init if there was a keyboard init error print message about it and continue to boot (sort of behave same as with CMOS clock). but we still need disp_sel to do video init? right. in case we was unable to init kbc properly we can just assume it is "color" set it to color mode and proceed with video init. result: instead of just black screen freeze we will get image and clear text indication of what went wrong with kbc and continue to boot this will give option to even autorun some custom tests from disk if someone want to do so.