Let's Play "Mac Plus Mystery Port"

[Bunsen]

Pardon my necromancy, but:

The thing is based on a Xilinx FPGA and Lapis touted that they could update and modify the functionality of the card by issuing a bit of software to put on the computer, which would be consistent with changing the configuration file for the FPGA.

Does this not suggest they left a programming port accessible? Does that in turn suggest to anyone that it may be possible to retrieve the FPGA data?

 

[Anonymous Freak]

Does this not suggest they left a programming port accessible? Does that in turn suggest to anyone that it may be possible to retrieve the FPGA data?

Absolutely. I used Xilinx reprogrammers during my last stint at Intel to both read and write from FPGA chips. (Ah, the joy of dealing with early pre-production hardware when there is no method to update a BIOS or the like.)

 

[trag]

Pardon my necromancy, but:

The thing is based on a Xilinx FPGA and Lapis touted that they could update and modify the functionality of the card by issuing a bit of software to put on the computer' date=' which would be consistent with changing the configuration file for the FPGA. [/quote']
Does this not suggest they left a programming port accessible? Does that in turn suggest to anyone that it may be possible to retrieve the FPGA data?

Xilinx FPGAs power up blank. They can be programmed externally, and they also have a mode where they'll output an incrementing address from some pins and receive the resulting data on other (or same?) pins. In other words a method to automatically load their programming from a storage chips such as a ROM of Flash.

I can't remember if the Lapis card has an EEPROM or similar on board, but it is entirely possible that the FPGA code was loaded by the computer through the interface to the expansion card, in which case the FPGA code would be a component of the Lapis Driver.

This would be consistent with Lapis's statement that the hardware functionality was updateable.

The computer boots up, the FPGA is blank, after the Lapis driver loads, the Lapis driver causes teh FPGA data to be driven on the bus to the Lapis card where it is addressed to the FPGA. After programming the FPGA the Lapis card begins functioning.

Alternatively, there may have been a memory chip on the Lapis card itself so that the Lapis card could operated before the Lapis driver loaded. I'd have to look at the card to be certain which way they did it.

 

[Bunsen]

If I lay my hands on one, I'll try to make sure you get a chance to poke at it.

it is entirely possible that the FPGA code was loaded by the computer / in which case the FPGA code would be a component of the Lapis Driver. /

The computer boots up, the FPGA is blank, after the Lapis driver loads, the Lapis driver causes teh FPGA data to be driven on the bus to the Lapis card where it is addressed to the FPGA. After programming the FPGA the Lapis card begins functioning

Intriguing - a possible method for new FPGA-based expansion devices which saves a little board space and component expense?

How does one avoid collisions with CPU activity while flashing the FPGA? (On the PDS bus)

 

[H3NRY]

The CPU writes to the FPGA to configure it thru the same buss it sends video after the FPGA is running, so there is no buss conflict. I think Lapis embedded the config within the driver, instead of using an EPROM, so the FPGA data is easily extracted and hacked by editing the driver file. Xilinx chips are wonderful toys. Beck-Tech made video output adapters that snapped into the security slot of 128 / 512 / Plusses, and I believe Steve Beck continued that after he started Lapis.

 

[Bunsen]

There are a few Lapis drivers in the 'museum.