LisaList2

Quote from: stepleton on August 13, 2026, 06:45:44 PMI'm guessing you can't rename the "Espressif USB JTAG/serial debug unit" that you find in an `lsusb` listing, but I wonder if there's a way to match the corresponding bus and device addresses in the listing to a /dev/ device without involving the hub.

There wasn't any way I could come up with to discriminate between the two ESP32s that didn't involve looking at the hub. They look indistinguishable from each other, and any method of changing the device's name (which I'm not even sure you can do on an ESP32) would require you to know which is which so that you know what device needs to be named what in the first place.

Quote from: stepleton on August 13, 2026, 07:13:51 PMI mention this because LisaFPGA rejects this form of Marxism by pitching an Error 75 when attempting to boot one of these Monitor drive images, or at least it does for me. I'm not sure why this would happen, and it's possible the problem is on my end, so I wonder: does it happen for anyone else?

Wow, that's not good! Come to think of it, I'm not sure that I ever tested the Monitor on it, which is a huge oversight on my part. I'll take a look once I'm done with ESFloppy and see if I can replicate those problems.

Okay, as part of my ESFloppy testing, I just booted several of the Twiggy Monitor images, both versions 11 and 12, and they all worked great. I was even able to start up Smalltalk. So whatever your problem is, it probably has something to do with the ProFile mod.

One other thing though: have you tried running with 1MB of RAM instead of 2MB? Smalltalk refused to load until I downgraded to 1MB, so perhaps you're having the same problem (just with more extreme symptoms) on your setup?

Quote from: AlexTheCat123 on August 13, 2026, 10:19:44 PMThere wasn't any way I could come up with to discriminate between the two ESP32s that didn't involve looking at the hub. They look indistinguishable from each other, and any method of changing the device's name (which I'm not even sure you can do on an ESP32) would require you to know which is which so that you know what device needs to be named what in the first place.

I wonder if you could change the ESProFile and ESFloppy firmware so that each device identifies itself on the serial port, perhaps in response to a challenge byte. The script could then connect to each /dev/ttyACM* device in order, trying to find one that says "how do you do I am an ESProFile on a LisaFPGA".

It would be a bit impolite if people had other serial port devices on their computer, but since the script is already somewhat brash, maybe it's okay. As a conservative choice of challenge byte, how about $11, the "XON" byte for serial port software flow control. It's one that literally means "go ahead and send data", and if I were writing a serial port program, I'd avoid giving the XON and XOFF bytes any other interpretation. So it seems more likely to be harmless if you send it to some bystander device.

One question: my YOLO assumption that it's not the end of the world if the ESProFile gets ESFloppy firmware or vice versa --- is this actually a safe assumption or could it break things? (Assume no real ProFile or floppy drives are connected to the LisaFPGA.)

QuoteOne other thing though: have you tried running with 1MB of RAM instead of 2MB? Smalltalk refused to load until I downgraded to 1MB, so perhaps you're having the same problem (just with more extreme symptoms) on your setup?

Good thought... I gave it a try (on both 01 and 10 RAM jumper settings) and no dice, unfortunately!

Quote from: stepleton on August 14, 2026, 04:02:18 AMI wonder if you could change the ESProFile and ESFloppy firmware so that each device identifies itself on the serial port, perhaps in response to a challenge byte. The script could then connect to each /dev/ttyACM* device in order, trying to find one that says "how do you do I am an ESProFile on a LisaFPGA".

That's an option, but it doesn't solve identification of the devices when they're still fresh from the factory and haven't been programmed with anything yet. In that situation you're still stuck with the hub, and while some people will be using the script to upgrade existing firmware, many others will be using it to install firmware for the first time. And in the event that you have to hold the BOOT button to get your ESP32 to program (which happens from time to time on ESP32s for inexplicable reasons), it wouldn't output that identity data anyway, even if it IS properly programmed.

Quote from: stepleton on August 14, 2026, 04:02:18 AMGood thought... I gave it a try (on both 01 and 10 RAM jumper settings) and no dice, unfortunately!

Darn! So clearly whatever it is, it's something to do with the ProFile version in particular. Can you attach or email me the exact image you're using so I can test with an identical config?

I guess one other thing you can try too if you haven't already: mess with the clock speed and see if it works at certain speeds and not others. Perhaps it's incompatible with the overclock for some reason but works fine at stock speed...

Quote from: AlexTheCat123 on August 14, 2026, 04:18:59 PMThat's an option, but it doesn't solve identification of the devices when they're still fresh from the factory and haven't been programmed with anything yet.

I'll live with just YOLOing port assignments as described provided you think it's low-risk. If I accidentally put ESFloppy firmware on the ESProFile or vice versa, is there any chance of bricking the board or causing hardware damage?

Quote from: AlexTheCat123 on August 14, 2026, 04:18:59 PMI guess one other thing you can try too if you haven't already: mess with the clock speed and see if it works at certain speeds and not others. Perhaps it's incompatible with the overclock for some reason but works fine at stock speed...

My experiments were all at stock speed, unfortunately! I wanted to remove acceleration as a factor.

Quote from: stepleton on August 14, 2026, 04:33:09 PMI'll live with just YOLOing port assignments as described provided you think it's low-risk. If I accidentally put ESFloppy firmware on the ESProFile or vice versa, is there any chance of bricking the board or causing hardware damage?

Yeah, you should be fine. I've accidentally uploaded the wrong one to the wrong chip several times and nothing bad has happened. Although there is a trick you can use to identify which is which. Just press and hold the RESET button of one of the ESP32s and check to see which port disappears on your computer. The one that vanished is the one whose button you're holding down.

Quote from: stepleton on August 14, 2026, 04:33:09 PMMy experiments were all at stock speed, unfortunately! I wanted to remove acceleration as a factor.

That's a shame! Send me the image and I'll take a look as soon as I have time.

Quote from: AlexTheCat123 on Yesterday at 04:49:14 AMThat's a shame! Send me the image and I'll take a look as soon as I have time.

No need --- it looks like it might be an issue with the "raw" images that pablo_marx included in zip files on that thread. (I was getting Error 75 on my real Lisa 2/10 as well.) I found working images sitting on one of my Cameo/Aphids, and they are attached here. They work on the LisaFPGA and on a real Lisa from an ESProFile without a problem, even in accelerated mode. I think I may have made them by dumping pablo_marx's .dc42 files to raw images by myself. At last, Smalltalk on a Lisa feels snappy.

One thing I have found since upgrading my firmware is that the Selector doesn't recognise the LisaFPGA's ESProFile as being Selector-compatible on first boot. It gives the option to go ahead and use the ESProFile anyway, and everything works fine; sometimes on reboots, the recognition also works as normal.

I looked at the $FFFFFF block in NeoWidEx and the magic bytes marking Selector compatibility were indeed present, so I'm not certain what the issue could be.

Nice, that's good news!

Strange about the Selector issue. I can't replicate it on my end; it catches it as Selector-compatible on the first and all subsequent boots.

I'm having trouble loading new firmware on my board. I tried with Mac OS 10.10 on my Mac Mini 2012 and with my 2 year old MacBook Pro running the latest Mac OS and I get the same error:
Scotts-Mac-mini:LisaFPGA-main mainuser$ ./program_board.sh
[INFO]  Platform: macos

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.24.3 (Apple Git-128)
[INFO]  Installing pyusb...

Usage:   
  pip3 install [options] <requirement specifier> [package-index-options] ...
  pip3 install [options] -r <requirements file> [package-index-options] ...
  pip3 install [options] [-e] <vcs project url> ...
  pip3 install [options] [-e] <local project path> ...
  pip3 install [options] <archive url/path> ...

no such option: --break-system-packages
Scotts-Mac-mini:LisaFPGA-main mainuser$

I then tried on Debian and get the following error:
scott@debian:~/Documents/LisaFPGA-main$ sudo ./program_board.sh
[INFO]  Platform: linux

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.39.5
[ OK ]  pyusb: 1.2.1-2
[ OK ]  ftdi_eeprom: v0.17
[INFO]  Installing arduino-cli...
./program_board.sh: line 151: curl: command not found
scott@debian:~/Documents/LisaFPGA-main$

I'm going to have to research what each of these errors mean unless someone has a quick fix. On all three systems I downloaded the zip file and unzipped into my downloads or documents folders.

I figured out I had to update pip. After the update I ran it again on my MacBook Pro and now I get this:
scottlewis@Scotts-MacBook-Pro LisaFPGA-main % ./program_board.sh     
[INFO]  Platform: macos

══ Checking / Installing Dependencies ══
[ OK ]  git: git version 2.50.1 (Apple Git-155)
[ OK ]  pyusb: 1.3.1
[ OK ]  ftdi_eeprom: v0.17
[ OK ]  arduino-cli: arduino-cli  Version: 1.5.1 Commit: Homebrew Date: 2026-06-05T09:39:33Z
[ OK ]  ESP32 Arduino core: esp32:esp32 3.3.11    3.3.11 esp32
[INFO]  Installing SDFat Arduino library...
Already installed SdFat@2.3.0
[ OK ]  SDFat:
[ OK ]  Adafruit SH110X: Adafruit SH110X
[ OK ]  openFPGALoader: openFPGALoader v1.1.1
[ OK ]  cp210x-cfg: /tmp/cp210x-cfg-n/cp210x-cfg

══ Program FT323H USB-to-JTAG Interface EEPROM ══
Current FT232H: manufacturer='Xilinx'  board_description='LisaFPGA JTAG Interface'  serial='000000'
[ OK ]  FT232H already programmed correctly, skipping!

══ Program CP2102N Serial Interface Name Descriptor ══
[INFO]  CP2102N current product: 'LisaFPGA Serial B'
[ OK ]  CP2102N already programmed correctly, skipping!

══ Discover ESP32 Serial Ports ══
[FAIL]  Failed to find serial port for ESProFile (hub port 2)!
scottlewis@Scotts-MacBook-Pro LisaFPGA-main %

Any ideas?

I have turned the board off and on several times as the instructions say and run the script again but it always fails with the same error. This is what my system is reporting for the USB:
USB 3.1 Bus:

  Location ID:   0x00000000
  Connection Type:   Built-in
  Driver:   AppleT8132USBXHCI

USB HUB:

  Location ID:   0x00100000
  Connection Type:   Removable
  Serial Number:   Not Provided
  Link Speed:   480 Mb/s
  USB Vendor ID:   0x1a86
  USB Product ID:   0x8091
  USB Product Version:   0x1320

LisaFPGA JTAG Interface:

  Location ID:   0x00110000
  Connection Type:   Removable
  Manufacturer:   Xilinx
  Serial Number:   000000
  Link Speed:   480 Mb/s
  USB Vendor ID:   0x0403
  USB Product ID:   0x6014
  USB Product Version:   0x0900

USB JTAG/serial debug unit:

  Location ID:   0x00130000
  Connection Type:   Removable
  Manufacturer:   Espressif
  Serial Number:   AC:A7:04:04:78:68
  Link Speed:   12 Mb/s
  USB Vendor ID:   0x303a
  USB Product ID:   0x1001
  USB Product Version:   0x0101
  Power Allocated:   2.5 W (500 mA)

USB JTAG/serial debug unit:

  Location ID:   0x00120000
  Connection Type:   Removable
  Manufacturer:   Espressif
  Serial Number:   AC:A7:04:04:78:70
  Link Speed:   12 Mb/s
  USB Vendor ID:   0x303a
  USB Product ID:   0x1001
  USB Product Version:   0x0101
  Power Allocated:   2.5 W (500 mA)

LisaFPGA Serial B:

  Location ID:   0x00140000
  Connection Type:   Removable
  Manufacturer:   Silicon Labs
  Serial Number:   9621c27ad41bf111899dafc40f0f12f8
  Link Speed:   12 Mb/s
  USB Vendor ID:   0x10c4
  USB Product ID:   0xea60
  USB Product Version:   0x0100

Quote from: slewis1962 on Yesterday at 11:10:53 PMon Debian and get the following error:
...
./program_board.sh: line 151: curl: command not found

Going through this now on a fresh install of ubuntu jammy jellyfish (this variant selected for Vivado compatibility) -- not to the finish line yet, but so far I found the need to
sudo apt install curl
and a bit later I found I needed to
sudo apt install libftdi1-devHaving done those, program_board.sh gets to the point of looking for the board

I had already installed Vivado 2026-1 on this system, so some other dependencies might have been covered. Alex reported development was done on Vivado 2025-2, but it seems to me that 2026-1 is looking workable. Note that the Vivado 'free' node-locked license available at the moment does not support versions prior to 2026-1, which suggests that some future license may not work on 2026-1, so you might get a license now if you think you may want to modify the FPGA design someday.