ulx3s/Lobby

Dolu1990

@Dolu1990

hooo right

emard

@emard

BTW on FB textmode and colors, do vt100 color numbers 100-108 work, they are "bright" versions of normal text bg colors 40-49. Visually it colors appear identical as non-bright... Well it's just for tetris, and generally completely unimportant :)

Dolu1990

@Dolu1990

hmm, i have no idea about it, maybe it is some packages to enable in linux / buildroot ?

emard

@emard

ok, if you or lawrie can for some of next rebuilds enable 256-color mode, original tetris "needs" yellow and orange blocks which currently both look orange so I changed yellow to white, thus departing from official "standard" :) eheheheee

Erik Piehl

@Speccery

@kost ok good to know you have the same issue, even if this is bad news. For me 3.0.3 fails too.

kost

@kost

@Speccery Identified problem. caused by this pull request: https://github.com/kost/fujprog/pull/1/files

if you open the device with NULL: hmp->cable_path, NULL, port_index);

it works.

if passed serial to the same function call, it does not recognize the device.

currently it is only manifested on Mac

kost

@kost

Right fix is to actually initialize value early in main() with serial=NULL;

and it looks like it works

mara

@vmedea

@emard

BTW on FB textmode and colors, do vt100 color numbers 100-108 work, they are "bright" versions of normal text bg colors 40-49. Visually it colors appear identical as non-bright... Well it's just for tetris, and generally completely unimportant :)

that's correct, due to IBM PC legacy, linux console doesn't support the bright background colors as separate color, the trick was always to use blink (SGR parameter 5), this sets the attribute bit in question

mara

@vmedea

that said, for tetris with full-sized blocks, one could use a block character with the foreground color yellow instead maybe? or, fwiw, linux fb also allows changing the palette

kost

@kost

@Speccery fixed in kost/fujprog@720e92b , that means you can pull latest version, compile it and it should work. I'll check for openfpgaloader, probably he have similar problem ;)

Erik Piehl

@Speccery

Thanks @kost that was very fast!

kost

@kost

As suspected, sudo openFPGALoader --board ulx3s blink/blink_85f.bit works

directly calling does not work: sudo openFPGALoader blink/blink_85f.bit

@Speccery does it work for you now?

emard

@emard

@vmedea thanx for blink bit trick I will try!! :)

emard

@emard

@vmedea Yes blink bit makes linux FB show orange as yellow, and it actually blinks in linux terminal, incrasing colorfulness of the board, thenx :)

pushed new tetris :)

Erik Piehl

@Speccery

@kost no change for me with the new version. I wonder if my FTDI drivers are somehow broken

kost

@kost

stupid question. have you connected it to the USB (US1)? USB (US2) will not work. Also, do you get the micropython terminal screen when run screen /dev/tty.usbserial-XXXX

Erik Piehl

@Speccery

Yes I am using US1. Again, the old ujprog works (with adding 3.0.8). Micropython I haven't tried

kost

@kost

how about openfpgaloader with --board specified?

Erik Piehl

@Speccery

micropython does respond (I needed to provide bitrate of 115200).

Eriks-MacBook-Pro:icy99 perik$ sudo openFPGALoader --board ulx3s ti994a_ulx3s.bit
unable to open ftdi device: -5 (unable to claim usb device. Make sure the default FTDI driver is not in use)
Error: Failed to claim cable

kost

@kost

will try on my colleagues macbook with Catalina if I can reproduce.

Have you tried installing these? https://www.ftdichip.com/Drivers/VCP.htm

Erik Piehl

@Speccery

I think so, but let me do that again. Installing 2.4.4.

I did run it again, no change. This actually makes me wonder if the drivers were properly installed, since when I did run this in the past, I needed to use System Preferences/Security to allow access for the kext.

kost

@kost

but you see ftdi loaded with kextstat or ?

Erik Piehl

@Speccery

195 0 0xffffff7f85521000 0x7000 0x7000 com.FTDI.driver.FTDIUSBSerialDriver (2.4.4) B137605C-32D8-3E81-89B6-E1F8039FC427 <100 60 6 5 3 1>

That's the output of kextstat

kost

@kost

~/code/mygithub> sudo kextstat | grep -i ftdi
  222    0 0xffffff7f83aa5000 0x3000     0x3000     com.apple.driver.AppleUSBFTDI (6.0.0) E35C349C-8115-37BA-B4C9-8034D1ED8B8B <221 63 23 6 5 3 1>
~/code/mygithub> fujprog blink/blink_12f.bit
ULX2S / ULX3S JTAG programmer v4.6 (git 720e92b built Oct  7 2020 10:53:42)
Copyright (C) Marko Zec, EMARD, gojimmypi, kost and contributors
no root permissions, not handling kexts
Using USB cable: ULX3S FPGA 12K v3.0.8
Programming: 100%
Completed in 8.32 seconds.

I see difference here in kexts

Erik Piehl

@Speccery

Thanks, good catch. Yes you have 6.0.0. I wonder if this is coming from Apple directly.

kost

@kost

maybe running manually: /sbin/kextunload -bundle-id com.FTDI.driver.FTDIUSBSerialDriver and/or /sbin/kextunload -bundle-id com.apple.driver.AppleUSBFTDI

Erik Piehl

@Speccery

Magic! That worked! Thank you so much. I ran sudo /sbin/kextunload -bundle-id com.FTDI.driver.FTDIUSBSerialDriver and then openFPGAloader worked!

kost

@kost

I guess fujprog will work as well

Erik Piehl

@Speccery

Yes it does. No root needed. Interestingly sudo kextstat | grep -i ftdi returns nothing, but things work. Thank you so much @kost

Erik Piehl

@Speccery

I think it was the driver issue all along. I also prepared a Xcode project to debug easier (using the older source code, without serial=NULL on line 525). I just got the project together, and it works too.

kost

@kost

@Speccery you're welcome. glad we managed to troubleshoot it.

Erik Piehl

@Speccery

Yes, thanks for your real-time help. I also learned a few useful commands as well :)

sxpert

@sxpert

this may be related with the new "we don't like kext anymore" policy from apple

Paul Ruiz

@pnru_gitlab

From memory, I think Apple included native FTDI drivers from High Sierra (10.13 - maybe even Sierra 10.12) onwards and in my old private ujprog builds I had the kext lines commented out.

Probably if you had the FTDI written drivers installed before that, the automatic upgrades grandfathered them in. There is a lot of outdated information on MacOS and FTDI on the web. Maybe it makes sense to have a few lines about this in a Getting Started page for fujprog

kost

@kost

currently, kext are handled if you provide root perms. if you run as user those lines are not executed anyway.

kost

@kost

but thanks @pnru_gitlab on suggestion. definitively is needed to document. including that if you have this line:

Where communities thrive

People

Repo info

Activity