The serial ports can be configured as either RS-232, 422 or 485, using these daughter boards and DIP switches. I had naively assumed both ports are 232 and somehow fried one of my 232 to USB converters. Better RTFM first.
🔥1
Anyhow, I had trouble getting anything out of the 232 port, it gets stuck in a boot loop and never makes any sign of life on serial. This needs hardware handshake and I even probed RTS and CTS with the scope to make sure my USB converter does support hardware handshakes
The debug console features a disassembler, an assembler, can load binary data from the network using TFTP, and even dump the contents of memory to a TFTP server
Now, I do have a box full of VME goodies I never did anything with because I lacked a backplane and power supply. Now that I do have those... In that box is a pile of OS9 reference manuals and a couple of GPUs for the VME bus. Are you thinking what I am thinking? 🐧
Wow, it's surprisingly difficult to find a TFTP server that actually works.
atftpd seems to be completely broken under current *buntu, as is tftpd-hpa. I tried https://pypi.org/project/ptftpd/, which does not handle write requests properly. Reading the code, it does not keep track if the client is currently writing to a file and assumes the client wants to overwrite the just created file after the first packet. Seems like the author never even tested write requests.
This one https://github.com/sirMackk/py3tftp works, but only for a limited number of packets, after which it just gives up. I did not read the source here. Limiting myself to 512k chunks at a time did the trick.
atftpd seems to be completely broken under current *buntu, as is tftpd-hpa. I tried https://pypi.org/project/ptftpd/, which does not handle write requests properly. Reading the code, it does not keep track if the client is currently writing to a file and assumes the client wants to overwrite the just created file after the first packet. Seems like the author never even tested write requests.
This one https://github.com/sirMackk/py3tftp works, but only for a limited number of packets, after which it just gives up. I did not read the source here. Limiting myself to 512k chunks at a time did the trick.
❤2
If anyone wants to have a look, here are the dumps. Including the floppy image and the single file on the floppy.
Now, what to do with this thing now? I wasn't able to find any software or development files for it by the manufacturer of this board, Force Computers GmbH. There is some stuff on bitsavers, namely the reference manual, and some PDOS images, probably for older hardware. No OS9, no Linux port, no *BSD port.
The hardware /is/ quite capable, having Ethernet, SCSI and 32Mb of RAM. So this would make for an interesting system. There are ports of Linux and NetBSD to other VME 68k boards of course, and there are drivers for all the off the shelf chips used on this in the Linux kernel, albeit for other platforms. There is even documentation for those. So, it might be possible to port Linux to it with a reasonable amount of effort.
However, one crucial piece is missing. I wasn't able to find the reference manual for the "FGA-002" VME bridge developed in house by this company, implemented in FPGA. The manual is called "UM SYS68K/FGA-002". Nobody seems to have archived it :(
The hardware /is/ quite capable, having Ethernet, SCSI and 32Mb of RAM. So this would make for an interesting system. There are ports of Linux and NetBSD to other VME 68k boards of course, and there are drivers for all the off the shelf chips used on this in the Linux kernel, albeit for other platforms. There is even documentation for those. So, it might be possible to port Linux to it with a reasonable amount of effort.
However, one crucial piece is missing. I wasn't able to find the reference manual for the "FGA-002" VME bridge developed in house by this company, implemented in FPGA. The manual is called "UM SYS68K/FGA-002". Nobody seems to have archived it :(
😢5