01:23 <fridtjof[m]> esden: how about a bgm_net module for sled to receive data from out_net? :D (It could just output to SDL2 to show what's going on then)

01:26 <d1b2> <esden> @Fridtjof it did cross my mind! 🙂

01:27 <d1b2> <esden> It might be the most useful thing to do, then it will be usable for bigger installations

01:34 <d1b2> <Attie> https://cdn.discordapp.com/attachments/613461005392936961/786405443928850442/unknown.png

01:34 <d1b2> <Attie> HUB75 applet is still WIP, but made good progress

01:35 <d1b2> <Attie> two issues remain, which I'll try to address (but feel free to comment)

01:35 <d1b2> <Attie> 1. the rows are rolled down by one (the top row should appear at the bottom... i couldn't get the fix straight in my mind)

01:36 <d1b2> <Attie> 2. there is some upward bleed (e.g: red into black)... IIRC this is to do with oe -> latch timings, and a ~30us delay helps

01:36 <d1b2> <Attie> https://github.com/attie/glasgow/tree/hub75

02:30 <d1b2> <bob_twinkles> if you're generating the pattern algorithmicly, I suspect the issue is that you're generating the "current" row when you should be generating the "next" row

02:32 <d1b2> <bob_twinkles> the solution I have to this (which I inherited from icebreaker-candy) is to use a register for the "address" output, so I latch the address internally when I ask the panel to latch the pixel data

02:33 <d1b2> <Attie> re point 1: it is exactly that, yeah... i had a play on stream to try to resolve it, but couldn't quite get my head around it at the time

02:33 <d1b2> <bob_twinkles> it is quite the mind bender

02:39 <d1b2> <esden> ohh right... @Attie here is another repo with a bunch of generative LED panel demos, this one is from @kbob https://github.com/kbob/icebreaker-candy

02:41 <d1b2> <bob_twinkles> (https://github.com/bobtwinkles/ledpanel-nmigen/blob/86203ec8788d5e0aeafb9d00badef2bf1eb9f6a1/ledpanel.py#L131-L256 is my port of that to nmigen, it seems to work =))

09:33 <_whitenotifier> [glasgow] blazra opened issue #244: bits[key] for negative key seems to not behave correctly - https://git.io/JIaEa

09:52 <_whitenotifier> [glasgow] blazra opened pull request #245: support.bits: fix __getitem__ for negative keys - https://git.io/JIaaR

10:32 <_whitenotifier> [glasgow] Success. The Travis CI build passed - https://travis-ci.org/github/GlasgowEmbedded/glasgow/builds/748729291?utm_source=github_status&utm_medium=notification

13:37 <d1b2> <Attie> thanks both! i'll take a look

17:24 <_whitenotifier> [glasgow] whitequark closed issue #244: bits[key] for negative key seems to not behave correctly - https://git.io/JIaEa

17:24 <_whitenotifier> [GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JIVji

17:24 <_whitenotifier> [GlasgowEmbedded/glasgow] blazra 047ed15 - support.bits: fix __getitem__ for negative keys

17:24 <_whitenotifier> [glasgow] whitequark closed pull request #245: support.bits: fix __getitem__ for negative keys - https://git.io/JIaaR

19:04 <_whitenotifier> [glasgow] Success. The Travis CI build passed - https://travis-ci.org/github/GlasgowEmbedded/glasgow/builds/748812809?utm_source=github_status&utm_medium=notification

19:45 <d1b2> <vifino> @esden I finally took the time to review your PR. Now I'm just eagerly waiting for my chance to buy a glasgow. 🙂