"handheld" several years back, and after I bricked it (it seems it didn't like to run pascal program piped in over serial port 😁) I've put it aside until now, when I was able to desolder flash chips from it.
The chipset is 186 ISA with vendor specific upgrades (for example it has presumably 24-bit segment registers with which it should be possible to directly address well over 1 MiB, it also has improved virtualisation with which it probably can emulate devices and newer opcodes).
and a few unofficial (a magazine from 90., board manuals even some sonic buoy handbook😁 ), but these are not enough to fully understand the architecture. The upgraded ISA (called superstate R) and the SoC config registers are not described there. However it is referenced to be in documents called (maybe one with the different names):
F8680 PC/CHIP Programmer's Reference Manual, UG75
CHIPS Superstate R Interface Guide
F8680 PC/Chip Programmers Data Pack
I was able to deduce a few possible instructions from the firmware images, but not all of them (especially the important ones). IMO there isn't any chance to reverse engineer the config registers fully.
Does anybody have more info about this interesting SoC or even these missing datasheets? It seems even dosbox-x is interested in those.
The C&T was later sold to the Intel (mostly GPU division) and later sold to somebody else (maybe Asiliant Technologies?). I don't suppose contacting Intel would help (I would be happy to be proven wrong 😁)
Also any firmware dump would be appreciated if anybody still has a surviving device. The vintage devices, where this SoC was used seems to be (often industrial computers):
OT, but I have known the CTO of Chips & Technologies, and he claimed that he designed most of F8680 chip by himself.
I know that this person was a quite a hardcore IC design engineer back in his heyday, so I believe his story.
OT, but I have known the CTO of Chips & Technologies, and he claimed that he designed most of F8680 chip by himself.
I know that this person was a quite a hardcore IC design engineer back in his heyday, so I believe his story.
This was weird, I was talking with somebody on reddit about F8680 based handheld device and I wrote a summary how to try to fix it and the reddit deleted my messages and shadowbanned me 😁. In case he will find this thread, I post the copy of the summary here too (it may be useful for another handbook 286 users too).
The discussion was about dumping BIOS and about cloning the software onto a healthy hdd. It seems the handbook expects a special area/partition with an updated shadow BIOS. I've got original files from the device and analyzed the program:
Awesome, thank you very much! […] Show full quote
Awesome, thank you very much!
I was poking in the image and it seems it contains int 13h extender. So I assume it was one of the testing images from the replacement drive(s)? I'm not sure if I extracted it correctly on linux, but it doesn't seem to have any io.sys nor msdos.sys (nor bootmgr of the int 13h extender) in the root directory, so this image would never boot anyway.
The file update.exe looks like it contains a shadow copy of the newer bios (there are two different update.exe versions 😮) and from the code it seems it will try to write 1+64+64 kilobytes (also last 1+64+64 kB of the update.exe) sequentially somewhere to a harddrive. This will be your special HDD data. Unfortunatelly the base sector value is obtained from the superstate code, which is located in the bios and it is using mechanisms without public documentation. Maybe I will try to analyze this 1+64+64 bios update, but I wasn't successful with the bios of my devices. It is also impossible if there is an additional code only in the ROM. BTW that's why I wanted a photo and ROM dump, to get idea how big is the firmware.
Anyway if the update is the entire BIOS image it should be stored probably in the last 64+64 kB (E000 and F000). The first 1kB is probably some loader/updater (didn't have a time to disassemble that). Also I would be suprised if the handbook ignored any drive without this structure (any device without floppy could be easily "bricked" if the drive was erased). If there is no special superIO HDD controller, the interface should be ATA IDE compatible (possibly emulated), the update.exe just writes IDE ports.
edit: BTW did you try to image the original drive in msdos/windows or in linux? If the 1kB block is written from the start of the drive it will make the drive inaccessible in msdos (until it is repartitioned by `fdisk /mbr`). However in linux something like `dd if=/dev/sdX` should always work (and it could point in a way of incompatible interface).
Discussion about my findings is welcomed here too 😁 (well only here as my reddit account doesn't work 😁 )
By doing an extensive research I think I've managed to find probably all special instructions. As stated in already public documents. It seems the F8680 ISA can have 24bit segments registers (CS/DS/ES/SS) which can be actively used for linear addressing. Basically instead of:
11234:5678 = 12340 + 5678 = 179b8
You can get:
1123456:789a = 1234560 + 789a = 123bdfa
This upgrade probably works only in "superstate" mode (or maybe in a normal one too until a segment register is overwritten - flat mode?). In the superstate mode you have a specialised instructions to fill these segment registers.
It seems the superstate ISA is using unused opcode starting with 0xFE byte, which puts it next to INC/DEC (funny, ghidra decodes these F8680 opcodes as this INC something something 😁 ). But instead of the standard INC/DEC R/M opcode 0/1 the superstate opcodes are using the higher values. The rest of R/M fields seems to have the same register/memory/offset encoding purpose as the vanilla 8086 ISA (it would be impractical to have a custom register decoder). The instructions which were deduced from the code behavior looks like this (I took the liberty to name them by myself 😜 ):
Shortened R/M field structure:
176 543 210 2Aa Bbb Ccc
(I hope I get that right)
"Aa" is the group type of operands (offset by register, offset by register and 8bit value, offset by register and 16bit value, directly register)
"Bbb" is the additional opcode field (INC vs DEC vs superstate ISA) .
"Ccc" is the subvariant in the "Aa" group ... [BX+SI], [BX+DI] etc
1LOAD_EDS Mem ... Encoded as 0xFE + mem ... The r/m opcode field is 2 2LOAD_EES Mem ... Encoded as 0xFE + mem ... The r/m opcode field is 3 3LOAD_ESS Mem ... Encoded as 0xFE + mem ... The r/m opcode field is 4
For example:
1LOAD_EDS CS:[SI+0x1234]
will load 24bit into EDS from a 32bit dword (MSB was always 0) located at the offset SI+0x1234
ESS may be incorrect, there was too little examples in the BIOS image.
It seems there is no ECS load (POP CS 😁). But there is a similar opcode:
1SSRET ... encoded 0xFE 0x28 ... no operands, opcode field is 5
It seems to be located at the end of the superstate functions in similar ways as IRET. But the occurence is minimal (usually like 2 per BIOS). There is mention of something like SSRET in some the 3rd party documents. So I guess this is it, most likely return from the superstate.
Wikipedia and buoy document describe encoding of two normal opcodes LFEAT and STFEAT (not sure if the naming is official, I would name them like CREG_WRITE, STATE_READ, but OK 😁 ). These seem to also follow the standard R/M encoding so finding variants other than AH/AX was easy:
ST FEAT loads the content of STATUS (SDATA?) F8680 registers specified by imm8 into the specified register (AL/CL/DL/BL/AH/CH/DH/BH).
1STFEAT reg, imm8 ... encoded 0xFE r/m imm8 ... opcode field is 6, subvariant field is 0
LFEAT will write a value stored in half of a 16bit register into CREG specified by second half of the 16bit register:
1LFEAT AX ... encoded 0xFE 0xF8 ... opcode field is 7, group field is always 3 2LFEAT CX ... encoded 0xFE 0xF9 ... opcode field is 7, group field is always 3 3LFEAT DX ... encoded 0xFE 0xFa ... opcode field is 7, group field is always 3 4LFEAT BX ... encoded 0xFE 0xFb ... opcode field is 7, group field is always 3
Variants with the pointer and index registers were not observed (probably impractical to fill them).
Also there are R/M bitfields combinations which could lead to another opcode(s) and there are other unused opcodes in 8080/80186 ISA. None of these we observed.
It seems these opcodes can work only in the superstate (unless they can trigger it). So the OS needs to enter the superstate if it needs to change something (EMS driver switching banks). All it needs to do is to call
1int 0x1f
I'm not sure if the interrupt actually call something, but it is most likely intercepted (IBM PC uses it as a pointer to a font table !!!) and the superstate handler is executed. It can be executed by many different reasons (reset, I/O port access, unused segment, probably invalid opcode, etc). After the handler realise it was triggered by int 0x1f it will act as a normal int handler but with superstate ISA opcodes, so it can reconfigure the SoC. Different vendors are obviously using different int 0x1f functionality 😜.
That's probably all. But even with all this info, it will be really difficult to write any F8680 software without knowing which CREG controls what, so still the programming manual would be nice to have.
