<nf6x[m]>
Are there any known issues with the software under macOS? I followed the instructions except for installing Homebrew, since I use MacPorts. The `glasgow` utility aborts without seeing the attached hardware for me. If it's currently dodgy under macOS, I can try testing out my new shiny hardware on a Linux box.
<Darius>
I've used glasgow under macos and also use macports
<Darius>
I don't have it here right now to test though..
<whitequark[cis]1>
it's not tested with macports
<whitequark[cis]1>
try ioreg -p IOUSB -l -w 0 to see if the kernel sees it
<whitequark[cis]1>
also try sudo port install usbutils; lsusb
<nf6x[m]>
The glasgow utility aborts every time, even when just printing the version number. So I suspect I may have some other dependency problem, not necessarily related to talking to the hardware.
<nf6x[m]>
If I don't make progress debugging the software on my Mac today, I'll try out my new hardware on a Debian laptop at work tomorrow.
<tpw_rules>
i've used it fine on macos with nix
<nf6x[m]>
Cool. It should be fixable on my Mac, then.
<nf6x[m]>
That aluminum case is nice.
<nf6x[m]>
I wish the Glasgow had a lot more pins. I dream of using a Glasgow descendent for silly tasks like interfacing to the Omnibus backplane in my PDP-8/M. 🤪
<nf6x[m]>
Previous errors were with one (or even zero) plugged in. I don't see a correlation between number of Glasgows plugged in vs. whether the utility aborts.
<whitequark[cis]1>
can you get a backtrace?
whitequark[cis]1 has quit [Quit: Reconnecting]
whitequark[cis]1 has joined #glasgow
whitequark[cis]1 is now known as whitequark[cis]
redstarcomrade has joined #glasgow
<nf6x[m]>
I don't know how; it crashes without printing one. Do you have any hints for me?
<nf6x[m]>
Each invocation of glasgow appears to exit with code 134.
<nf6x[m]>
I think that is SIGABRT?
<nf6x[m]>
If I try to run the uart example applet, it segfaults.
<whitequark[cis]>
the cause of the crash is probably heap corruption; the cause of the heap corruption is ???
<nf6x[m]>
Let's see, whatever python I'm invoking doesn't know about glasgow. I'm not familiar with pipx yet, so it may take me a moment to figure out how to try that with the right python
<whitequark[cis]>
oh, sorry
<whitequark[cis]>
PYTHONFAULTHANDLER=1 glasgow list -v
<nf6x[m]>
Let's see, I normally use python 3.9 currently, but IIRC pipx referred to python 3.12 when I installed glasgow. I need to figure out how to check what dependencies it pulled in, I think?
<nf6x[m]>
less which glasgow
<whitequark[cis]>
this looks painful to debug tbqh
<nf6x[m]>
Derp! Wrong window. 🤣
<whitequark[cis]>
I know this part of python-libusb1 and because of some design issues with interop of GC and non-GC languages it's an endless source of bugs
<nf6x[m]>
Neat. /sarcasm
<nf6x[m]>
🙂
<nf6x[m]>
My bedtime approaches, so if you don't mind, I'll put debugging my mac installation of glasgow on the back burner, and try playing with my new hardware on a linux box at work tomorrow.
<whitequark[cis]>
why is dlfree getting called?..
<nf6x[m]>
I must assume that was a rhetorical question; I'm staring at you like a dog hoping you just said 'cookie'.
<nf6x[m]>
So maybe this is related to the libffi closure thingy mentioned above, after all?
<nf6x[m]>
Also, I kind of want a cookie now.
<whitequark[cis]>
oh.
<whitequark[cis]>
sorry, I mixed up dlfree and dlclose
<whitequark[cis]>
they're both FFI-related but completely unrelated to each other
<whitequark[cis]>
okay, it's clear why dlfree is getting called, and also this is a double free or heap corruption
<nf6x[m]>
That sounds to me like the actual bug is inconveniently hiding under a different rock.
<whitequark[cis]>
yes
<whitequark[cis]>
basically unless someone becomes a champion of this particular issue it's probably not getting fixed
<nf6x[m]>
That debian laptop at work is starting to look a lot more attractive.
<whitequark[cis]>
like I have the skills to do it but I cannot possibly justify sinking 5-10 hours into it
<nf6x[m]>
Understood and agreed.
<nf6x[m]>
Stuff being somewhat broken on my mac is not unfamiliar territory. 🙂
<whitequark[cis]>
there's at least five different places I can name offhand where the issue could be, not to mention the interactions
<whitequark[cis]>
and because libffi embeds its own allocator instead of using the system one, valgrind and friends won't work on it
<whitequark[cis]>
so you kind of just suffer.
<nf6x[m]>
I got my first computer in 1981. I've been suffering ever since. 😁
<nf6x[m]>
Well, thank you very much for trying. I suspect it'll all work just fine on a different computer without broken dependencies, and then I can begin learning how to Do Stuff with the Glasgow.
<ewenmcneill[m]>
Reading the scrollback, especially the backtrace, it seems libusb is aborting somewhere in its unload handler. I've seen that happen in other MacPorts contexts where, eg, the dylib dragged in something else via init dependency and then the other thing was no longer there at unload time.
<ewenmcneill[m]>
In those cases MacPorts worked around the crashes by telling the dylib loader not to unload libraries again (which avoided the whole exit path confusion). I don't know how easy it would be to persuade Python's dylib handling to do that.
<whitequark[cis]>
<ewenmcneill[m]> "Reading the scrollback, especial..." <- nope
<whitequark[cis]>
dlfree, not dlclose
<whitequark[cis]>
dlclose unloads a shared library
<whitequark[cis]>
dlfree is free from dlmalloc
<ewenmcneill[m]>
Ah, okay, thanks for the clarification
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
oh right
<whitequark[cis]>
thanks!
GNUmoon2 has quit [Ping timeout: 260 seconds]
GNUmoon2 has joined #glasgow
redstarcomrade has joined #glasgow
trh has joined #glasgow
ali_as has quit [Quit: Ping timeout (120 seconds)]
ali_as has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
bvernoux has joined #glasgow
balrog has quit [Quit: Bye]
balrog has joined #glasgow
tec has joined #glasgow
maki0728[m] has joined #glasgow
<maki0728[m]>
my glasgow arrived last week, and I'm really excited to try it out on a vintage/retro keyboard project. Thank you everyone here for the hard work to make this product. I'm looking forward to the next part of this journey.
<whitequark[cis]>
good luck
<nf6x[m]>
Is there a preferred name for Glasgow revC hat/cape/adapter boards? Poking through the scrollback, I get the impression that “addon” might be it.
<whitequark[cis]>
we don't have a formalized one at the moment
<whitequark[cis]>
historically this has been "addon" but I'm wondering if "hat" is maybe not so bad
<benny2366[m]>
hat is already in use by the pi folks ...
nekrondev[m] has quit [Quit: Idle timeout reached: 172800s]
<benny2366[m]>
so that might cause confusion
galibert[m] has joined #glasgow
<galibert[m]>
Someone draw a hat of a Glasgow box :-)
<galibert[m]>
On
<galibert[m]>
With the box it’s more like dentures though
<whitequark[cis]>
HAT is "Hardware Attached on Top"
WilfriedKlaebe[m has joined #glasgow
<WilfriedKlaebe[m>
well, then there'll be Pi hats, Glasgow hats, ... - people will adapt.
<whitequark[cis]>
this accurately describes plugging something into the main glasgow connectors
<whitequark[cis]>
in fact it is probably a better descriptor than most of what we've discussed
<nf6x[m]>
Oh, I never thought of hat as an acronym. Neat.
<whitequark[cis]>
there's also pHAT which stands for something but I refuse to consider it because of how silly it sounds
<nf6x[m]>
I will call the ones that I expect to design whatever is preferred, but it pleases me that I won’t have to call them pHATs.
omnitechnomancer has joined #glasgow
<omnitechnomancer>
chapeau
<whitequark[cis]>
it's possible we'll reserve "addon" for things like RAM-Pak, but I'm thinking RAM-Pak should just be unique
<whitequark[cis]>
the part where you fiddle with a completely unprotected FPGA IO bank is not confidence inspiring
<nf6x[m]>
I don’t know what this RAM-Pak is. From context, I presume it is a RAM expansion that plugs into the LVDS header, for applications needing more local buffer space?
<whitequark[cis]>
correct. and I expect most people will want it for logic analyzer capabilities
<nf6x[m]>
Sounds useful.
<whitequark[cis]>
I plan to design a "hyper-FIFO" which looks like a normal FIFO but uses HyperRAM to spool if you store too much into it
<nf6x[m]>
Do you expect that the orientation, spacing, and pinout of the two shrouded connectors will be maintained in future revisions? I.e., do you think a HAT/chapeau/thingy designed for revC will likely also work on the envisioned revD?
<whitequark[cis]>
unsure
<whitequark[cis]>
there is a desire to do that but the form factor of revC is really tiny and we're already stretching it
<whitequark[cis]>
we will definitely try
<nf6x[m]>
I hope to influence you to stretch it a lot, because I play with a lot of vintage minicomputers using interfaces with crazy pin counts by today’s standards.
<nf6x[m]>
I would consider contributing to such silliness on the hardware design side if it does not step on toes.
<whitequark[cis]>
so revD is 32... and I think that's still not enough
<whitequark[cis]>
however, have you seen my work on ATF15xx?
<whitequark[cis]>
it's a CPLD i reverse-engineered to the point where it could be dynamically reprogrammed as a pin extender for high pin count projects
<nf6x[m]>
I have not seen that. Just for context, one of the sorts of things I’d like to apply something Glasgow-like to is the Pertec magnetic tape interface. That has about 51 signals IIRC.
<whitequark[cis]>
so in principle each individual ATF1502 chip (32 MC) could do 32 inputs or outputs, fixed but reconfigurable on the fly
<whitequark[cis]>
you'd use a few terms as a latch and the register as a scan chain
<whitequark[cis]>
the CPLD can be reprogrammed (reflashed) via JTAG
<whitequark[cis]>
it's also native 5V
<whitequark[cis]>
theoretically i can see e.g. each of the 8-pin banks being extended to 64 pins, with corresponding loss of frequency
<nf6x[m]>
Interesting! I will look at that. I’ve considered using ATF15xx stuff for 5V applications before, and the thought of using an old WinCUPL tool did not excite me.
<whitequark[cis]>
well to avoid WinCUPL you'd have to implement a toolchain first
<whitequark[cis]>
since i only provide the chip database
<whitequark[cis]>
but yeah ATF1502AS is completey RE'd
<whitequark[cis]>
ATF1504AS, almost completely
<Attie[m]>
wasn't there some discussion around "kilt" a while ago?
<Attie[m]>
and addon for the LVDS header(??)
<whitequark[cis]>
Attie[m]: Absolutely Not
<whitequark[cis]>
(that was my answer to the discussion)
<Attie[m]>
ha, ok
<Attie[m]>
ahh cool
<whitequark[cis]>
Attie[m]: well the thing is that we probably don't want to have many of those
<nf6x[m]>
Kilt would imply that a Glasgow without one is nude. That is not my preferred vibe.
<whitequark[cis]>
i don't like documentation that's too full of cute names
<whitequark[cis]>
it stops being cute after like one or two
<whitequark[cis]>
and starts to be just confusing and annoying
<whitequark[cis]>
eventually (see Phabricator) it becomes an art form in itself, but even Phabricator kind of got done with it
<whitequark[cis]>
* if you take it far enough (see Phabricator) it becomes an art form in itself, but even Phabricator kind of got done with it
<whitequark[cis]>
nf6x[m]: also this, yes
<nf6x[m]>
Whatever term is selected, it seems to me that it might be a good convention to include the Glasgow revision, since it is unclear how much compatibility will be maintained. For example “Foo project is a Glasgow revC (thingy)”.
<whitequark[cis]>
yeah. revAB are mechanically compatible with revC but the FXMAs were so unreliable it's not really electrically compatible even if the pinout and functions are the same
<nf6x[m]>
How many revAB boards are out there? Is compatibility with them something that I should consider when I design a revC (thingy)?
<whitequark[cis]>
not many
<whitequark[cis]>
and no new ones should appear
<whitequark[cis]>
and no
<nf6x[m]>
Do you think that a hypothetical future high IO count Glasgow should keep 0.1” headers for all of the IO? Or might it just have 0.1” headers for a limited number of pins and expect to have a HAT installed on high density headers where high IO count is needed?
<whitequark[cis]>
nf6x[m]: revE will use mechanical/electrical SYZYGY connector (not the plug'n'play spec though)
notgull has joined #glasgow
notgull has quit [Ping timeout: 268 seconds]
<nf6x[m]>
Cool.
<nf6x[m]>
128 IO via SYZYGY connectors sounds like a good start. 🙂
<whitequark[cis]>
yep
bvernoux has quit [Quit: Leaving]
<nf6x[m]>
But seriously, how many IO do you envision for revE? Even just 64 would cover most of my weird use cases.
<whitequark[cis]>
at least 128?
ari has quit [Ping timeout: 256 seconds]
Wanda[cis] has joined #glasgow
<Wanda[cis]>
128? holy shit
<Wanda[cis]>
nice
<whitequark[cis]>
i'm not promising that you could mechanically populate them all to the revC-style headers, but as a bare IO count? yeah that seems reasonable. about half the IO of a nice chonky ECP5
<whitequark[cis]>
we really do need to sort out USB though...
<theorbtwo[m]>
My two cents, for what it is worth (which is probably less than two cents), are that it'd be nice if, as long as there are 0.1inch connectors for glasgow, they stayed as compatable as possible with rev c in terms of pin definitions, spacing, etc. That is, if you've got an addon that will fit on top of a bare glasgow revc on either port A, port B, or port AB, it will fit on port A, port B, or port AB of the glasgow d. I'd be far less
<theorbtwo[m]>
concerned about fitting in the case, though, because that'd constrain the design of future glasgow revisions too much.
<theorbtwo[m]>
I also think that there's a lot of use in retaining 0.1 inch headers, because they are so friendly. A future lots-of-pins glasgow could have a mix of connector types?
<whitequark[cis]>
it is obvious that keeping compatibility is desirable... keeping the case is impossible because the case only has two holes
<theorbtwo[m]>
For case read form factor? Is there a reason to keep the form factor other than case compatability?
<theorbtwo[m]>
I'd like to see "addon" used, with "lvds addon" and "port ab addon" used to distinguish where necessary. The only terminology I don't like is "revision".
<theorbtwo[m]>
I'd like just calling the current one a Glasgow C, or a Glasgow C revision 3.
<whitequark[cis]>
too late, it's everywhere and entrenched
<whitequark[cis]>
theorbtwo[m]: it's not possible to keep the form factor. you cannot physically fit revD onto the same board size...
<theorbtwo[m]>
<whitequark[cis]> "it's not possible to keep the..." <- Yes, I agree. But it's possible to keep the 0.1 inch headers the same distance apart and rotation, right?
<whitequark[cis]>
it's unclear
<whitequark[cis]>
until the layout is done I'm not going to say that it's possible
<theorbtwo[m]>
Fair.
<nf6x[m]>
It would not bother me if most of the newly-added IO came out on connectors with higher density than 0.1”. Any of the high-pin-count applications I have in mind would involve me making an adapter PCB anyway for mechanical and/or electrical interface reasons. The SYZYGY connector seems like a good choice to me. I’ve designed for FMC in a previous day job, and that connector is not DIY-friendly.
<whitequark[cis]>
FMC is a no-go
<whitequark[cis]>
the idea for revE is to replace all of the IO with high density SYZYGY-like connectors
<whitequark[cis]>
then you could put an adapter that gives you back revC/revD style IO
<nf6x[m]>
That sounds fine to me.
<nf6x[m]>
Is the idea for revD to just add two more revC-style headers?
<whitequark[cis]>
and change the FPGA
<whitequark[cis]>
* the FPGA to ECP5
<nf6x[m]>
Oh, nice.
<nf6x[m]>
ECP5 packs more punch.
<whitequark[cis]>
and make HyperRAM a permanent addition
<whitequark[cis]>
(these are all related)
<whitequark[cis]>
USB will probably stay on the FX2 though
<nf6x[m]>
Another crowdfunded project I’m still waiting for is Luna/Cynthion. I wonder if that project might help Glasgow achieve more USB throughput in some future revision?
<whitequark[cis]>
theoretically yes
<whitequark[cis]>
practically I do not believe that right now LUNA is production-ready or close to being production-ready
<whitequark[cis]>
last time I looked it did not even pass timings on ECP5 in the default configuration
<whitequark[cis]>
the other major concern is that ECP5-5G is rather quite expensive
<whitequark[cis]>
putting one ECP5 on a board is costly; putting two seems almost excessive
<whitequark[cis]>
I think for revD we'll go with the FX2; it's tried and true and very reliable, if a little slow
<whitequark[cis]>
revE is very uncertain
<whitequark[cis]>
it's going to be at least gigabit, ideally 3 gigabit
<nf6x[m]>
Cool.
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
ari has joined #glasgow
nekrondev[m] has joined #glasgow
<nekrondev[m]>
I followed Cynthion dev along the way and the analyzer gateware seems quite production ready (as devices will ship by the end of the month to CS backers).
<nekrondev[m]>
The thing that's missing I think is currently HyperRAM buffering when capturing USB packets so at HS it might overflow
<nekrondev[m]>
(depending on the targets device)
<nekrondev[m]>
One of the latest PRs added AUX PHY test device so you can loop the AUX device via USB cable to TARGET-C port and use that internal device for testing purposes... so the USB (LUNA Amarath) stack seems quite complete to me.
<nekrondev[m]>
* to me if you can do this kind of configuration.
<nf6x[m]>
The glasgow initial setup instructions worked fine on a Debian laptop I have at work. Yay! I’ll see if I can use my new glasgows at home under a Debian VM on my mac. If that doesn’t work, then I’ll just use a Debian laptop that I didn’t care to dig out over the weekend. In any case, I have a path forward to learn how to use my new glasgows.
smkz has quit [Quit: smkz]
smkz has joined #glasgow
<nf6x[m]>
I think my biggest hurdle will be learning Amaranth. I’ve previously only used VHDL, Verilog, and CUPL-like things for HDL stuff.
<nekrondev[m]>
Anyway revD/E needs high output so USB3/NIC are eventually needed which is out of scope for Cynthion.
<nekrondev[m]>
Yea... I'm still learning Amarath, too as I'm a toital newbie on this even with 15+ years of Python experience
<nekrondev[m]>
s/toital/total/
<nf6x[m]>
I use Python all the time, but Amaranth looked kind of arcane to me based on my first glances at it. Now that I have my glasgow, I finally have a reason to dig in to Amaranth.
<nekrondev[m]>
yep same for me once I get Cynthion or Glasgow 😉
<nf6x[m]>
I am hoping that Cynthion/Luna will help me incorporate more USB goodness into both work and hobby projects. In my day job, I’m currently leveling up in motor drive and power electronics. I specifically told them not to hire me for that role, but did they listen? 😁
tomkeddie[m] has joined #glasgow
<tomkeddie[m]>
You'll want to name it zmod or something else. Avnet recently hit that and had to drop the syzygy name because of the lack of dynamic voltage support. (Greg did dynanic voltage with ecp5 on butterstick, you could copy his technique).
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
Shiz has quit [Ping timeout: 272 seconds]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
grazianom[m] has joined #glasgow
<grazianom[m]>
is there a list of available applets somewhere?