Great questions.
Would it be feasible with an bluepill STM32F103C8T6 (128 KB flash, 20 KB RAM) for a 2$ usd board
My prototype used a bluepill. It was a heck of a lot of manual wiring, and the bluepill comes misconfigured with the wrong USB pull-up resistor value, and not much ESD protection. Once taking time to do a PCB, one might as well put the micro on the PCB in the first case. So, yep, it would be slightly cheaper to use a blue pill since I can't get parts as cheaply here as in China, but not easier design-wise. Also note that I'm using a STM32F0 which seems to be newer than the STM32F1 series (I don't understand the numbering scheme...)
That looks pretty through and complete.
Still, could we lose that pig of a chip, 8243?
It doesn't seem that difficult to make a modern processor just interface with the 4 bit interface directly.
The USB isolator is pretty fancy, by why not just optoisolate UART data out of the uP and use an FTDI232 on the cold side?
You'd reduce the bandwidth requirement of the isolator a few decades!
Can we get rid of the 8243? Yes, I had assumed not easily with a microcontroller. The slave needs to respond to the bus signal within about 650ns of a falling edge. Assuming 20ns clocks, that's 30 cycles total. With very careful programming (nested interrupts, etc), it may be possible even though I had initially dismissed it. I had imagined implementing it with a FPGA. Another factor is that the bus is 5V logic, so one would need to add a set of transceivers (5 inputs and four tri-state outputs, so 10 MCU IO pins).
On a bus read, the MCU would need to quickly latch the data on a the falling edge of nPROG (60ns hold time), decode the instruction, read the appropriate data from RAM, and write the data back to the bus. Perhaps DMA would work to latch the bus data? Oh, and bus reads can happen every 5 or 10us, so the MCU would spend nearly all of its time handling bus I/O.
My proposed FPGA solution would have used UART isolators (2 IO and 2 flow control lines), but wouldn't support USBTMC if I ever wanted to implement that. The USB solution has more flexibility (even DFU modes) and the user doesn't have to pay attention to the baud rate or flow control settings. I'd probably use a purpose-built isolation IC (like from Silicon Labs). In terms of board space, the USB isolator is about equal to the UART isolation, and the USB isolator isn't that much more expensive than the digital isolator+FT230X.
I was looking at QFP package FPGAs, which would require a bunch of board area and decoupling capacitors.... In particular, I like the MachXO2. A TinyFPGA would be great, but it looks like they are mostly out of stock. However if I do accept QFN soldering, the LCMXO2-256HC-4SG32I may actually work out well. Maybe I'll look back at that solution. A note is that the FPGA needs its own external oscillator, as its internal RC isn't precise enough for use in a UART, so an oscillator needs to be added to drive the FPGA (unless I pass the FT230X's clock output through the digital isolator.).