_catircservices has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #prjcombine
h_ro has joined #prjcombine
Wanda[cis] has joined #prjcombine
<Wanda[cis]>
hi
<Wanda[cis]>
time for a status update
<Wanda[cis]>
so a week or two ago I started looking into setting up some JTAG stack to interface with the FPGAs for the in-hardware testing phase of this project
<Wanda[cis]>
unfortunately, this resulted in getting highly pissed off at FTDI's entire existence and deciding to ascend and kill libftd2xx.
<Wanda[cis]>
since we decided to do it properly, me and Maja have been busy reversing FTDI hardware for the last week or so and intend to write a proper driver as a rust library.
<Wanda[cis]>
thus, I'd like to announce prjspeedbump.
<Wanda[cis]>
I hope the name conveys the level of disdain I feel for this vendor in particular.
<Wanda[cis]>
... at some point I'll also need to look at Xilinx Platform Cable and announce prjyakshave, but that's not today
whitequark[cis]1 has joined #prjcombine
<whitequark[cis]1>
nice
<whitequark[cis]1>
i have also once got highly pissed off at FTDI's entire existence
<mupuf>
Wanda[cis]: ROFL
<vup>
re hating FTDI, does anybody know of a instruction reference for their FT32 arch?
<Wanda[cis]>
I'm considering making one
<Wanda[cis]>
is the FT900 series like, actually used much?
<Wanda[cis]>
also. this instruction set is... I can only call it "cute"
<Wanda[cis]>
has the funniest compressed instruction format I have ever seen
<Wanda[cis]>
the FT32B I mean
<Wanda[cis]>
as far as I can tell, they ran some statistics on their codebases and then just picked the most common 768 instructions and stuffed them into a ROM lookup table
<Wanda[cis]>
and by "most common 768 instructions" I mean "for ALU opcodes, including the R2 source register"
<Wanda[cis]>
* source register and immediate field"
<Wanda[cis]>
so you can look into binutils libopcodes and get a list of their most commonly used (opcode, R2) and (opcode, immediate) pairs.
<Wanda[cis]>
like. I'm still not sure if I like or hate this approach.
<Wanda[cis]>
also. FTDI really has a thing for making fucked-up instruction sets.
<Wanda[cis]>
the VNC2 architecture is some weird custom harvard 0-registers zero-page 8/16/32-bit ISA
<Wanda[cis]>
the VNC1 is... I can't really find proper information on it, but they took some 8-bit MCU (8051?) and gave it a fucking 32-bit integer math coprocessor, advertised in the datasheet as being for "complex 32-bit integer math such as required for FAT filesystem handling"
<Wanda[cis]>
this is so laughable that I just have to RE this weirdass thing.
<vup>
i dont know about FT900, but FT60x also uses it, and thats one of the few FIFO USB3 chips, which seems to be used quite a bit.
<Wanda[cis]>
wait, FT600 has programmable firmware?
<Wanda[cis]>
that's a part that I missed
<Wanda[cis]>
I haven't looked in detail at D3xx yet
<Wanda[cis]>
there aren't really many instructions
<Wanda[cis]>
but the ones that exist sure are interesting
<Wanda[cis]>
you have a fairly normal RISC architecture. add. xor. some jumps. mul. div even.
<Wanda[cis]>
has a hardware stack pointer and push/pop instructions which is slightly weird for a RISC, but eh whatever
<Wanda[cis]>
and then right next to mul you have a fucking strcmp instruction.
<Wanda[cis]>
and a bunch of other shit from string.h, as an opcode.
<Wanda[cis]>
and then well
<Wanda[cis]>
you have memcpy of course
<Wanda[cis]>
and you have "stream this buffer into/from USB endpoint" instructions
<Wanda[cis]>
also, as an aside
<Wanda[cis]>
I find the FT930 architecture hilarious.
<Wanda[cis]>
see, on FT900, you have a USB peripherial block, and the toolchain has a library you can link into your code that implements the D2xx protocol in software
<Wanda[cis]>
but on FT930, they claim they have a "D2xx engine" in hardware that does the D2xx protocol handling for you
<Wanda[cis]>
I have looked at it
<Wanda[cis]>
guess fucking what. the "D2xx engine" is a second MCU core, likely FT32 too, which communicates with the main core via some mailboxes and uses the same software D2xx implementation.
<vup>
wtf
<Wanda[cis]>
I love this
<Wanda[cis]>
this is excellent entertainment
<Wanda[cis]>
FTDI has made so much ridiculous hardware
<ari>
xD
<Wanda[cis]>
btw I just installed the VNC2 toolchain on my windows VM
<Wanda[cis]>
it is a work of art
<Wanda[cis]>
I have never seen such a completely fucked toolchain
<Wanda[cis]>
and the early-2000s ribbon UI makes it even better
<Wanda[cis]>
they have made a completely custom in-house C compiler, assembler, and linker
<Wanda[cis]>
or. actually more like C-fanfic compiler
<Wanda[cis]>
because this shit is definitely not C
<Wanda[cis]>
VNC2 involves another custom architecture they made. a "8/16/32-bit Harvard MCU"
<Wanda[cis]>
there are no registers, you just use zero-page of memory for that like a 6502
<Wanda[cis]>
I think VNC1 is also going to be hilarious, but unfortunately they don't seem to publish the toolchain for that, only premade firmware images? I have no idea wtf is going on
<Wanda[cis]>
worst case I'll reverse it by disassembling their firmware
<Wanda[cis]>
that said. while the FTDI MCUs and custom ISAs are... mesmerizing, our main target here is the actual fixed-function D2xx devices that tend to be used as JTAG controllers on FPGA boards
<Wanda[cis]>
all the FT32 stuff is going to be done in "I got bored" mode
<Wanda[cis]>
our main target is FT2232/FT2232H/FT4232H/FT232H because these can do MPSSE. secondary target is FT232[ABR], FT245[ABR] and FT-X, because it's so easy to just throw them in too when you support the other ones.
<Wanda[cis]>
anything else is going to be supported on "maybe when someone gets bored" basis
<cr1901>
I didn't know FTDI made bespoke MCUs
<cr1901>
I just thought they made "USB to low speed serial protocol" bridges
<whitequark[cis]1>
also high speed parallel
<Wanda[cis]>
they make... a lot of weird stuff
<Wanda[cis]>
mostly USB related
<Wanda[cis]>
though apparently they have spun off the MCU stuff as Bridgetek, and it is not clear how much it is the same company or not