The 10Mhz LED on my new Pocket 8086 seems to be opposite logic to what I would expect. It is lit when the CPU is running at 4.77Mhz and off when running at 10Mhz:

Anyone else have this?

On some other machines the turbo light switches orientation according to whether you've got turbo at boot slow or fast in setup.

BitWrangler wrote on 2024-11-24, 04:34:

On some other machines the turbo light switches orientation according to whether you've got turbo at boot slow or fast in setup.

Thank you. Not sure what was going on yesterday. But it seems to be working as I expect now. Either I was confused before, or it was!

Will bump this somewhat old topic with impressions from the pocket8086. Or, rather, warning.
As some might have noticed in the specs, this one comes with an 128K UMB memory at D...E address segments, and it's enabled by default. Stock DOS setup loads use!umbs, but ega3.cpi, mouse and ch375 driver pushed to conventional memory, which prevents from running a bundled DuneII game, so it's only natural to throw drivers and even dos via dosmax to UMB, effectively gaining high amount of free conventional memory. I've, hovewer, got unexpected system behavior after doing this. Drivers and dos itself are kept fine in the UMB, but launching ANY game gave me system halt, and win3 hangs after mouse enable. Even EDIT command was doing that. After some research it was clear that problem is in UMB itself. I've dropped all the drivers from UMB, leaving just use!umbs in config.sys, and Check!it 3 shows nothing instead of HiMem. Then i've checked product page thoroughly and found that UMB can be switched off. 060h keyboard port was mentioned, so i've tried to control it via simple C program (got bundled Turbo C compiler to use haha). Of course i've got nothing, and then checked the CPLD schematic, published on 8086cpu.com. In reality 061h was the control port for UMB using reserved bit 3, along with speaker and something named ENNMI, which seems like does not affect anything (only keeps it's value in register). This time i've been able to disable/enable the UMB section.

My guesses are the following: when some software wants to control speaker, it may write to port using an inverted mask or something, without paying attention to the reserved bit, and thus disabling the UMB. And yes, it may enable UMB when it's not should be - for example, when an external ISA card providing it's own memory block at mentioned segments is connected. There is no any lock bit was implemented, so...

now, coming the worst part. I've initially grabbed this neat thing because of CPLD usage, sooo it will be easy to fix the UMB, right? Right?.. So naive i've been. After offering an PLCC extractor and some epm7128s spare and rewriting almost 1/4 of the schematics in Verilog i've found that these old CPLDs should have JTAG disabled to function corresponding pins as i/o, and there's (still, counting researches at 3 different forums) no way re-enable JTAG without rare and costly parallel programmer. So unfortunately there are 2 options - somehow reach to the Shan Zhongyu and ask to fix schematics and sell (at least) CPLDs with updated design for those who already bought p8086, and make an adapter for tqfp100 MAX3000 series which will be quite costly as it will be required to make array of edge holes on all 4 sides of pcb. There is third one - make an plcc84 riser to any 5v-tolerant CPLD development board and debug the design before making an "OTP" programming of blank 7128s, but it's for real geeks who have spare time for this after work, and 7128s should be REALLY blank (chinese sellers often sending an used ones with JTAG disabled).

So, in short, UMB section is almost unusable, it also can influence your experience with external ISA cards, and there's no easy method to fix it.

Unfortunately i see no option to edit the post, so this is an quick update:
1. i've forgot white a bit about XT keyboard controller, it's readonly and you can't configure it via registry - no typematic setup, no numlock control, nothing. It may affect the software which relies on the 060h port setup;
2. even plain beep via dos functions causing UMB to disappear. There are chance that it can be fixed via BIOS update for some cases.

I am a bit surprised that era-software would clobber port 61h, as it is has always been used by various random things and likely lead to very weird behavior on real hardware. E.g. orig PC manual says bit 3 is cassette motor control, and disconnected starting PS/2. Yet RBIL says "NMI I/O channel check disable (W) / status (R)". With a bit of good luck, maybe it is really just the BIOS doing it?

I wonder if it's some problem with the CTC, timer 2 on i/o port 061. Since that handles the parity check on bit 7 and speaker out on bit 1 and gate control on bit 0... Also handles refresh. Anyway, electrical level trace bridge, electronic level part failure or incorrect pullups letting something backfeed, or software level bit masking failure, might disable some RAM through parity error when it is intended to use speaker. Or it interferes with refresh, knocking that RAM out.

I don't really have a deep understanding, just ended up having to check CTC operation when chasing a parity error on another machine and noted the large amount of functions that one thing did.

Hi, it's perhaps not really practical to some, but.. I remember there's a patch utility that disables PC speaker output in DOS games.
It's a public domain utility, I believe. It uses NOPs, I think.
Loosing PC speaker music is no real loss, maybe.
Both AdLib Music Synthesizer and Creative Music System were period-correct sound cards for PC/XTs, as well.
And the Book 8088 has AdLib, hasn't it? 🙂

BitWrangler wrote on 2025-03-23, 13:49:

I wonder if it's some problem with the CTC, timer 2 on i/o port 061. Since that handles the parity check on bit 7 and speaker out on bit 1 and gate control on bit 0... Also handles refresh. Anyway, electrical level trace bridge, electronic level part failure or incorrect pullups letting something backfeed, or software level bit masking failure, might disable some RAM through parity error when it is intended to use speaker. Or it interferes with refresh, knocking that RAM out.

Note the issue is not about "physical" RAM at all -- you can see on the schematics what the pocket8086 does with writes to port 061 and it's not controlling anything about the memory chips at all (and likely no PC does, for a long time) .

The problem described is that on the pocket8086 this port 61h 's bit 3 is controlling whether certain high addresses are mapped to RAM (thereby allowing their usage as UMBs). However some software is "accidentally" clobbering/writing to that port (when using related functionality such as pcspkr, also on port 61h) and thereby accidentally disabling the UMBs. My question is whether this can really be caused by DOS-era software: I presume such software would cause real era PCs to crash or at least misbehave since there port 61h seems to have really controlled something physical back then. Maybe owners/emulator writers know.

The other option proposed would be to just move this control to some port other than 61h, but that cannot be changed without reprogramming the pocket8086's CPLD, which is locked because reasons. ( as someone who'd like to hack the keyboard µc in the pocket386, I'd say "welcome to the pocket*86 owners club").

I don't know much about the pocket8086 either way, in fact I thought that like the book8086 it had exactly 512+128=640KB of RAM, but apparently this extra 128K for UMB-exclusive usage is new to the pocket8086 😀

javispedro1 is right, it's only about address mapping 🙂
As for BIOS patch, i'll try to do something when PLCC extractor will arrive, maybe even flash S. Kiselev's 8088 one. Do not want break another PLCC socket with needles. Making proper bios patch will be complicated though, since you can write the UMB bit to port, but it will be always 0 when reading. Additional variable should be kept somewhere in the RAM. I'm unsure about the real software, but seems like nobody made UMB mapping control through keyboard port before, i doubt that it really should be there.

BitWrangler wrote on 2025-03-23, 13:49:

I wonder if it's some problem with the CTC, timer 2 on i/o port 061. Since that handles the parity check on bit 7 and speaker out on bit 1 and gate control on bit 0... Also handles refresh. Anyway, electrical level trace bridge, electronic level part failure or incorrect pullups letting something backfeed, or software level bit masking failure, might disable some RAM through parity error when it is intended to use speaker. Or it interferes with refresh, knocking that RAM out.

I don't really have a deep understanding, just ended up having to check CTC operation when chasing a parity error on another machine and noted the large amount of functions that one thing did.

Chipset implementation in p8086 is very simplified, there's no ram parity checking and machine using SRAM chips, so it does not require "refresh" operations. Only 5 bits of 061h register actually controls something, including the non-readable UMB and value-only ENNMI. Even no reset circuit through the CPLD.

mIV wrote on 2025-03-23, 11:58:

My guesses are the following: when some software wants to control speaker, it may write to port using an inverted mask or something, without paying attention to the reserved bit, and thus disabling the UMB.

Much of what you said was beyond my current level of knowledge. But I will make a comment anyway 😀.

Just wondering if you could trace what's happening by disassembling a program that crashes straight away, and find out what it is actually doing? Could it perhaps be a bug in the BIOS routines? Issues there presumably are fixable?

mIV wrote on 2025-03-26, 09:17:

since you can write the UMB bit to port, but it will be always 0 when reading.

WTF, I didn't realize that . It is obvious in retrospect from the sch =) . Then it explains everything, since even software that is correctly written will destroy the contents of that reg. Sorry for my observation.

Minor situation update with p8086.
Good thing: S. Kiselev's 8088 bios (book 8088 build) can be flashed to p8086 directly (but it will provide an floppy drives init/letters). Using build with v20 cf-ide oROM, i've achieved about 1M/sec at CF read operation 😀.
Bad thing: the UMB control issue can't be fixed via bios patch. DOS controls speaker by itself, and handling the umb state in bios routines is useless. And it also worth to mention, that with changed bios and installed clean 6.22 MS-DOS UMB is not active after boot. I'm planning to fully port the CPLD code to Verilog and try to flash an clean IC, but not in the near future.
BTW: Many owners mentioned that p8086 screen is better than b8088 one, but it still sucks in terms of color rendering. Maybe it have an compatible IPS model...