mkarcher wrote on 2022-04-18, 19:10:

maestro wrote on 2022-04-18, 18:21:

I'm using a PS/2 keyboard with an adapter, not ideal since they weren't 100% backwards compatible but unfortunately that's all I have to test with. I remember that switch now that you mention it. 😀

To put things straight: PS/2 keyboards and AT keyboards with a DIN connector are 100% compatible. You can use the cheap passive cable adapter without any restrictions. On the other hand, AT and XT keyboards are 0% compatible. XT keyboards use a unidirectional protocol without parity, and AT keyboards use a bidirectional keyboard with parity and the possibility to resend bytes if the receiver encounters a parity error.

Your problem is only that much related to the keyboard having a PS/2 plug as keyboards with PS/2 plugs are less likely to implement the XT protocol than keyboards with DIN plugs. An AT keyboard with DIN plug without XT protocol support would work just as bad as the PS/2 keyboard you are currently using.

Wow that's actually interesting, and quite an improvement to the keyboard protocol, kind of analogous to heat seeker missiles verses radar guided missiles. The controller must have been beefed up to handle the extra data, and I wonder if the poling clock was increased as well to keep up the response time.

I also did an experiment, this time I pressed the F2 key instead of the F1 key. It shrieked like a banshee, so it looks like you're 100% correct. 😉

maestro wrote on 2022-04-18, 23:19:

mkarcher wrote on 2022-04-18, 19:10:

maestro wrote on 2022-04-18, 18:21:

I'm using a PS/2 keyboard with an adapter, not ideal since they weren't 100% backwards compatible but unfortunately that's all I have to test with. I remember that switch now that you mention it. 😀

To put things straight: PS/2 keyboards and AT keyboards with a DIN connector are 100% compatible. You can use the cheap passive cable adapter without any restrictions. On the other hand, AT and XT keyboards are 0% compatible. XT keyboards use a unidirectional protocol without parity, and AT keyboards use a bidirectional keyboard with parity and the possibility to resend bytes if the receiver encounters a parity error.

Your problem is only that much related to the keyboard having a PS/2 plug as keyboards with PS/2 plugs are less likely to implement the XT protocol than keyboards with DIN plugs. An AT keyboard with DIN plug without XT protocol support would work just as bad as the PS/2 keyboard you are currently using.

Wow that's actually interesting, and quite an improvement to the keyboard protocol, kind of analogous to heat seeker missiles verses radar guided missiles. The controller must have been beefed up to handle the extra data, and I wonder if the poling clock was increased as well to keep up the response time.

I also did an experiment, this time I pressed the F2 key instead of the F1 key. It shrieked like a banshee, so it looks like you're 100% correct. 😉

Yeah, those heat seeking air to air missiles really were a pain in everyday use. And don't get me started on the old wire guided ones, those gave me carpal tunnel's!

maestro wrote on 2022-04-18, 23:19:

mkarcher wrote on 2022-04-18, 19:10:

XT keyboards use a unidirectional protocol without parity, and AT keyboards use a bidirectional keyboard with parity and the possibility to resend bytes if the receiver encounters a parity error.

Wow that's actually interesting, and quite an improvement to the keyboard protocol, kind of analogous to heat seeker missiles verses radar guided missiles. The controller must have been beefed up to handle the extra data, and I wonder if the poling clock was increased as well to keep up the response time.

The complexity in the keyboard only increased slightly, even the XT keyboard included an 8042 controller with scanning logic. The main practical advantage of the AT keyboard is that it provides software control over the keyboard LEDs. The original XT keyboards didn't have any lock LED indicators at all (that's why MS Works for DOS for example has NumLock and ScrollLock indicators on screen in the status line), and extended XT keyboards had keyboard controlled Caps/Num LEDs that toggled everytime you pushed the lock key, independent of whether the computer really processed it as a lock key. If a game replaced the keyboard interrupt with a custom handler that didn't chain to the original and didn't toggle the lock key flags in the BIOS data area, pushing the lock key an odd number of times while the game was running made the keyboard LED go out of sync with the BIOS status bits.

The complexity on the mainboard increased significantly, though. On the XT, the keyboard interface is handled by (guessed, approximately) three off-the-shelf TTL chips, the central component being 8-bit shift register with a "carry out" signal as nineth bit. As soon as the start bit reached the carry out, the logic latched up waiting for the processor to read the current byte and issue a reset signal to the receiver logic. On the AT, the keyboard interface (shifting bits and arbitrating for the communication direction) is handled by an 8042 microcontroller that also handles miscelaneous other things like providing some GPIO pins, one of them being used for the A20 gate, and another one to reset the 80286 to make it leave the protected mode. The 8042 doesn't handle resends, though. The resend logic is to be implemented in a proper IRQ0 handler (the BIOS did it, I assume DOS did it, I'm quite confident nearly no game did it). The LEDs are also driven from the IRQ0 handler: As soon as a lock key down event is handled by a standard IRQ0 handler, the BIOS data bit is toggled and an "update LED status" command with the new LED bits is sent to the keyboard.

mkarcher wrote on 2022-04-19, 21:21:

maestro wrote on 2022-04-18, 23:19:

mkarcher wrote on 2022-04-18, 19:10:

XT keyboards use a unidirectional protocol without parity, and AT keyboards use a bidirectional keyboard with parity and the possibility to resend bytes if the receiver encounters a parity error.

Wow that's actually interesting, and quite an improvement to the keyboard protocol, kind of analogous to heat seeker missiles verses radar guided missiles. The controller must have been beefed up to handle the extra data, and I wonder if the poling clock was increased as well to keep up the response time.

The complexity in the keyboard only increased slightly, even the XT keyboard included an 8042 controller with scanning logic. The main practical advantage of the AT keyboard is that it provides software control over the keyboard LEDs. The original XT keyboards didn't have any lock LED indicators at all (that's why MS Works for DOS for example has NumLock and ScrollLock indicators on screen in the status line), and extended XT keyboards had keyboard controlled Caps/Num LEDs that toggled everytime you pushed the lock key, independent of whether the computer really processed it as a lock key. If a game replaced the keyboard interrupt with a custom handler that didn't chain to the original and didn't toggle the lock key flags in the BIOS data area, pushing the lock key an odd number of times while the game was running made the keyboard LED go out of sync with the BIOS status bits.

The complexity on the mainboard increased significantly, though. On the XT, the keyboard interface is handled by (guessed, approximately) three off-the-shelf TTL chips, the central component being 8-bit shift register with a "carry out" signal as nineth bit. As soon as the start bit reached the carry out, the logic latched up waiting for the processor to read the current byte and issue a reset signal to the receiver logic. On the AT, the keyboard interface (shifting bits and arbitrating for the communication direction) is handled by an 8042 microcontroller that also handles miscelaneous other things like providing some GPIO pins, one of them being used for the A20 gate, and another one to reset the 80286 to make it leave the protected mode. The 8042 doesn't handle resends, though. The resend logic is to be implemented in a proper IRQ0 handler (the BIOS did it, I assume DOS did it, I'm quite confident nearly no game did it). The LEDs are also driven from the IRQ0 handler: As soon as a lock key down event is handled by a standard IRQ0 handler, the BIOS data bit is toggled and an "update LED status" command with the new LED bits is sent to the keyboard.

Thanks for the detailed info! Since we're on a keyboard tangent at the moment and you seem quite knowledgeable on XT keyboard stuff, I have a question I haven't found the answer to yet - maybe you can shed some light on the subject if that's not too much to ask 😀

Some keyboards seem to be "auto-sensing" if they're connected to an XT or an AT, and adjust their protocol accordingly. I have 3 of these: two early IBM model M (one without LEDs and one with LEDs) and a Commodore PC keyboard (that came with a PC30-III, so an AT-class machine). They work on any AT machine and also seem to work fine when I use them with my IBM 5160 (64-256KB system board). Now what I've been wondering is - why do they work with a 5160 but won't work with other XT clones? I have tried them unsuccessfuly with 3 different clone (non-IBM) XT mainboards. Only a "proper" XT keyboard will work with those. What does the 5160 mainboard have that the other clone mainboards lack?

MMaximus wrote on 2022-04-19, 21:51:

Some keyboards seem to be "auto-sensing" if they're connected to an XT or an AT, and adjust their protocol accordingly. I have 3 of these: two early IBM model M (one without LEDs and one with LEDs) and a Commodore PC keyboard (that came with a PC30-III, so an AT-class machine). They work on any AT machine and also seem to work fine when I use them with my IBM 5160 (64-256KB system board). Now what I've been wondering is - why do they work with a 5160 but won't work with other XT clones? I have tried them unsuccessfuly with 3 different clone (non-IBM) XT mainboards. Only a "proper" XT keyboard will work with those. What does the 5160 mainboard have that the other clone mainboards lack?

I can only guess. It might be BIOS dependent or HW dependent. The original PC/XT keyboard interface used pin 3 as reset pin for the keyboard, but that pin wasn't used by a lot of keyboard and is generally no longer used on AT-class machines. The auto-sense mechanism in your keyboards might identify an XT system by receiving a reset pulse, which needs support by the board to drive the reset line and the BIOS to generate a reset pulse during the POST.

weedeewee wrote on 2022-04-16, 20:27:

another week, another haul... help. 😐

posting in the wrong place! we'll just encourage you 😀

Sinclair QL
powerpc mac mini
2 normal floppy drives, new in box.

you found these or buying them?

great finds, that rare(ish) QL. I like that there are 2 new floppy drives too

the cards are looking handy too

gerry wrote on 2022-04-20, 07:37:

posting in the wrong place! we'll just encourage you :) […]
Show full quote

weedeewee wrote on 2022-04-16, 20:27:

another week, another haul... help. 😐

posting in the wrong place! we'll just encourage you 😀

Sinclair QL
powerpc mac mini
2 normal floppy drives, new in box.

you found these or buying them?

great finds, that rare(ish) QL. I like that there are 2 new floppy drives too

the cards are looking handy too

actually finding.
Today, I got a panasonic JB-3300. No idea if it's working. Has some plastic damage and seems complete for the rest.
also two AT psu's that were new in box, and 2 300W atx psus new in box.
a USB zip 100 with powersupply
a geforce 3
etc....
It's kinda crazy what people throw away. Lucky for me 😁

mkarcher wrote on 2022-04-19, 22:01:

I can only guess. It might be BIOS dependent or HW dependent. The original PC/XT keyboard interface used pin 3 as reset pin for the keyboard, but that pin wasn't used by a lot of keyboard and is generally no longer used on AT-class machines. The auto-sense mechanism in your keyboards might identify an XT system by receiving a reset pulse, which needs support by the board to drive the reset line and the BIOS to generate a reset pulse during the POST.

Thanks for this info. That sounds like a plausible explanation - I had no idea about this reset pin

weedeewee wrote on 2022-04-20, 15:33:

It's kinda crazy what people throw away. Lucky for me 😁

you're right! You seem to be good at intercepting this stuff!

Interesting to read though, now and then one of us will think "hey i found that too!"

It's ALIVE !

Is that a gas-plasma display? What's it like to use in person?

Kahenraz wrote on 2022-04-22, 19:54:

Is that a gas-plasma display? What's it like to use in person?

That's what the internet tells me it is. Also has a switch mentioning Plasma ON/OFF, so I guess it must be.

Considering the large screens we're used to these days... it's small :-p
also looks sluggish and feels like it came from a period where people had more time.

Shouldn't be sluggish, unless the graphics controller holds it back. They were faster than LCDs were until a few years into this century.

"Be Competitive" - ly disappointed...
PCChips with Celery 333 and SiS 6326 onboard

At least it's a dumpster find, since the GPU on it is actually a hot dumpster fire IMO.

Wonder if the Celery is one of those OC-able chips.

May be suited to a Voodoo II build, that and the fact that it's BabyAT board may be the only two redeeming features..

holdencars11 wrote on 2022-05-01, 06:29:

"Be Competitive" - ly disappointed...
PCChips with Celery 333 and SiS 6326 onboard

I agree with bashing a brand that had the nerve to install fake cache chips as much as the next person, but let's not forget that computers are in many ways "binary" - to some large extend, they either work or they don't. And some of PCCraps later revisions were normal, decent boards, apparently.
That being sad, the one at hand is probably not one of them:
PC100 M747 - The bane of my existence
Also, no one wanted AT boards back then who could afford Intel PIIs, apparently. So those boards are pretty rare?

I have a few S7 boards by PCChips and its underwhelming, but serviceable. M571 is very stable with the Cyrix M2 in my useage. The M571 also has quite a decent 'fan' made support page http://m571.com/m571/...
In this case with the M747... hmmm the Celery has some problems with not always booting, but seems to work fine with a P2... And the celery seems to work fine on another board... so its a mystery so far.
Unsure if i should bother troubleshooting further, or just stick with the P2. I think this system will be more of just a curious test build than anything else for the moment.

Cuttoon wrote on 2022-05-01, 11:18:

I agree with bashing a brand that had the nerve to install fake cache chips as much as the next person, but let's not forget tha […]
Show full quote

holdencars11 wrote on 2022-05-01, 06:29:

"Be Competitive" - ly disappointed...
PCChips with Celery 333 and SiS 6326 onboard

I agree with bashing a brand that had the nerve to install fake cache chips as much as the next person, but let's not forget that computers are in many ways "binary" - to some large extend, they either work or they don't. And some of PCCraps later revisions were normal, decent boards, apparently.
That being sad, the one at hand is probably not one of them:
PC100 M747 - The bane of my existence
Also, no one wanted AT boards back then who could afford Intel PIIs, apparently. So those boards are pretty rare?

They were really uncommon back in the day. I think in the wild (while dumpsterdiving) I only ever found one AT slot 1 board?
...and iirc it was this same PC Chips board 🤣

Makes a lot of sense to me that anyone who was on a budget in the late 90s-2000 would go with a SS7 and anyone able to afford a PII could get a ATX tower and PSU, as well.

I like the idea of having a real "mains" switch on a computer and assumed for some time that socket 7 was the last to provide AT. Which is why I bought that K6-III+.
But turns out, there is exactly one Socket A board out there in baby AT...

PCChips were utterly unknown to me contemporary, but they must have been rather widespread.
I couldn't help getting a M537 via some "parts unknown" ebay haul. The 3.1 revision with the linear voltage regulators with huge, golden heatsinks:

That too has at least one fanpage:
http://th2chips.freeservers.com/m537/index.html