| *** tpb has joined #yosys | 00:00 | |
| *** lutsabound has quit IRC | 00:09 | |
| *** emeb has quit IRC | 00:48 | |
| *** emeb_mac has joined #yosys | 00:50 | |
| *** AlexDaniel has joined #yosys | 00:53 | |
| *** gsi__ has joined #yosys | 01:48 | |
| *** gsi_ has quit IRC | 01:51 | |
| *** leviathanch has joined #yosys | 01:57 | |
| *** lutsabound has joined #yosys | 02:08 | |
| *** leviathanch has quit IRC | 02:38 | |
| *** somlo has joined #yosys | 02:45 | |
| emeb_mac | up5k w/ USB for futzing w/ TinyFPGA USB bootloader sent to OSHpark | 03:01 |
|---|---|---|
| *** rohitksingh has joined #yosys | 03:29 | |
| *** s_frit has quit IRC | 03:37 | |
| *** citypw has joined #yosys | 03:38 | |
| *** rohitksingh has quit IRC | 03:43 | |
| *** rohitksingh_work has joined #yosys | 03:55 | |
| *** rohitksingh has joined #yosys | 04:02 | |
| *** rohitksingh_work has quit IRC | 04:08 | |
| *** rohitksingh has quit IRC | 04:08 | |
| *** rohitksingh has joined #yosys | 04:08 | |
| promach | corecode : so, I guess it is a better idea to stop the sby ? | 04:12 |
| promach | still had not finished yet :( | 04:12 |
| *** lutsabound has quit IRC | 04:19 | |
| *** rohitksingh_work has joined #yosys | 04:30 | |
| *** proteusguy has quit IRC | 04:30 | |
| *** rohitksingh has quit IRC | 04:33 | |
| *** rohitksingh has joined #yosys | 04:33 | |
| *** proteusguy has joined #yosys | 04:50 | |
| *** blunaxela has quit IRC | 04:59 | |
| *** blunaxela has joined #yosys | 04:59 | |
| *** pie__ has joined #yosys | 04:59 | |
| *** pie___ has quit IRC | 05:03 | |
| *** rohitksingh_work has quit IRC | 05:12 | |
| *** rohitksingh_work has joined #yosys | 05:13 | |
| *** _whitelogger has quit IRC | 06:22 | |
| *** _whitelogger has joined #yosys | 06:24 | |
| *** citypw has quit IRC | 07:21 | |
| *** citypw has joined #yosys | 07:33 | |
| *** emeb_mac has quit IRC | 07:34 | |
| *** leviathanch has joined #yosys | 07:40 | |
| *** m4ssi has joined #yosys | 08:13 | |
| *** m4ssi has quit IRC | 08:43 | |
| *** m4ssi has joined #yosys | 08:46 | |
| *** citypw has quit IRC | 10:09 | |
| MoeIcenowy | emeb_mac: for the TinyFPGA USB BL, is any IO suitable for USB or a differiental pair specified by the pinout table is needed? | 10:39 |
| daveshah | Any IO works | 10:39 |
| daveshah | you can't use a FPGA diff receiver on its own for USB <3.0 in any case, as it has some single ended signalling modes | 10:40 |
| promach | can't use a FPGA diff receiver on its own for USB 2.0 ? | 10:43 |
| promach | daveshah : why ? | 10:43 |
| daveshah | promach: because USB has some single ended modes (where both pairs are at the same value) | 10:44 |
| tnt | Can yosys infer dual clock RAM with different read/write width ? | 10:44 |
| daveshah | tnt: yes, hopefully | 10:44 |
| promach | I see | 10:45 |
| daveshah | *both lines of the pair, not both pairs | 10:45 |
| tnt | daveshah: I tried this, but ... https://pastebin.com/TvbRjLAA | 10:45 |
| tpb | Title: module usb_ep_buf #( parameter TARGET = "ICE40", parameter integer RWI - Pastebin.com (at pastebin.com) | 10:45 |
| promach | daveshah: but wait, what about tinyFPGA BX ? | 10:45 |
| daveshah | promach: that is USB 1.1 | 10:45 |
| daveshah | and uses just two single ended pins | 10:46 |
| promach | what about the upcoming EX version ? | 10:46 |
| daveshah | USB 1.1 doesn't need any kind of diff receiver | 10:46 |
| tnt | well technically you can have a 2.0 compliant device that does FS only ... | 10:46 |
| daveshah | that supports 1.1 on IO pins or 3.0 on the transceivers but not 2.0 | 10:46 |
| promach | so, https://github.com/davidthings/tinyfpga_bx_usbserial is USB 1.1 , and not USB 2.0 ? | 10:47 |
| tpb | Title: GitHub - davidthings/tinyfpga_bx_usbserial: USB Serial on the TinyFPGA BX (at github.com) | 10:47 |
| tnt | promach: It's usb full-speed. | 10:47 |
| promach | so, it is USB 2.0 | 10:47 |
| promach | tnt | 10:47 |
| tnt | It's USB 2.0 compliant (well ... maybe, didn't check if they passed the compliance tests), but it doesn't use the 'High-Speed' mode that was introduced in USB 2.0. | 10:48 |
| tnt | LS = Low Speed = 1.5Mbps FS = Full Speed = 12 MBps HS = High Speed = 480 MBps. | 10:49 |
| tnt | you can do LS and FS using normal IO pins/CMOS drivers. | 10:49 |
| tnt | for HS you need a dedicated PHY chip. | 10:49 |
| promach | ok | 10:50 |
| corecode | hi | 11:09 |
| corecode | i wonder whether a HS USB SIE done using a softcore would be smaller and easier to maintain than a monolithic design | 11:12 |
| promach | SIE ? | 11:16 |
| corecode | serial interface engine | 11:16 |
| MoeIcenowy | I heard that Lattice claims USB on Lattice FPGAs w/o ext PHY is not possible | 11:19 |
| corecode | because they didn't certify it for usb | 11:20 |
| tnt | corecode: what do you mean monolithic ? | 11:22 |
| corecode | non-microprogrammed | 11:22 |
| tnt | Oh. Well it's not HS (only FS), but ATM I'm doing a USB core that implements the 'usb stack' in a CPU. Much like you would find an common microcontroller. Packet level stuff is done in hardcoded logic. Transaction stuff is done in a microprogrammed state machine, and then the higher "transfer" layer is left to the CPU to do. | 11:24 |
| corecode | the SIE | 11:24 |
| corecode | are you doing a HS SIE? | 11:25 |
| corecode | i don't know too much about HS frames | 11:25 |
| tnt | no, FS only. I don't want an external PHY. | 11:25 |
| corecode | okay | 11:25 |
| corecode | is there much to do even? | 11:26 |
| MoeIcenowy | I think USBASP is some USB LS implemented in software with 8-bit AVR... | 11:26 |
| MoeIcenowy | it astonished me | 11:26 |
| corecode | receive packet id, address, buffer out, checksum, ack? | 11:26 |
| tnt | corecode: for HS you mean ? | 11:27 |
| corecode | generally | 11:27 |
| corecode | that needs to be in the fast loop | 11:27 |
| corecode | i think you only have so many bit times to answer ack/nak | 11:27 |
| tnt | The transaction layer needs to be fast, you only have 6.5 bit time to respond in FS. | 11:27 |
| tnt | So when you get a IN or OUT token, you have to decide fast what to answer. | 11:28 |
| corecode | right, so that needs to be in a register already | 11:28 |
| MoeIcenowy | maybe implementing LS will be more loose? | 11:28 |
| corecode | LS will be the same, just slower | 11:28 |
| corecode | 1/10 | 11:28 |
| MoeIcenowy | USB is too strict! | 11:29 |
| MoeIcenowy | (escape | 11:29 |
| corecode | what | 11:29 |
| *** proteusguy has quit IRC | 11:29 | |
| tnt | corecode: yeah, I have basically just enough time to fetch from RAM the endpoint status and start the reply. That's why the transaction layer is still done in 'logic' (ok, microprogrammed, but still not quite a generic CPU) and not by just the soft core. | 11:30 |
| corecode | ah you don't keep the EP in registers? | 11:30 |
| tnt | No, I keep buffer rings in a RAM. | 11:31 |
| tnt | And fetch/writeback when starting/finishing the transaction. | 11:31 |
| corecode | ok | 11:31 |
| tnt | I wanted to be able to handle many endpoints without too much overhead. | 11:31 |
| corecode | yea i understand | 11:32 |
| tnt | Although technically you can only have 16 endpoints :/ | 11:33 |
| corecode | technically? | 11:34 |
| corecode | also, bidirectional | 11:34 |
| corecode | plus multiple buffers | 11:34 |
| tnt | The EP field is 4 bits | 11:34 |
| corecode | yes | 11:34 |
| tnt | Oh yeah, endp numbers can be re-used for IN/OUT. | 11:35 |
| *** leviathanch has quit IRC | 11:39 | |
| tnt | daveshah: any idea where I could find a example for that dual clock / different width ? Pretty much everything I tried resulted in ... no RAM :p | 11:47 |
| tnt | mm, actually from what I read, I don't see that yosys can infer READ_MODE != WRITE_MODE | 11:55 |
| *** rohitksingh_work has quit IRC | 11:56 | |
| daveshah | no, although some quick tests and it's happy to fake it with logic and the mask input | 11:56 |
| daveshah | https://www.irccloud.com/pastebin/UbzqG8pj/ | 11:58 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 11:58 |
| MoeIcenowy | BTW is it possible to implement ADC with iCE40? | 11:58 |
| daveshah | MoeIcenowy: yes, probably | 11:58 |
| daveshah | either doing something like charge time measurement of a capacitor, or sigma-delta with a diff input as a comparator | 11:59 |
| MoeIcenowy | I think some AN of Lattice mentioned it on ECP and XO series | 11:59 |
| MoeIcenowy | it should apply to iCE | 11:59 |
| tnt | google "Common Analog Functions Using an iCE40 FPGA", first result. | 12:00 |
| *** rohitksingh has quit IRC | 12:00 | |
| tnt | (couldn't ... ungooglify the link ...) | 12:00 |
| *** AlexDaniel has quit IRC | 12:02 | |
| tnt | https://www.latticesemi.com/-/media/LatticeSemi/Documents/ProductBrochures/AM/CommonAnalogFunctionsUsinganiCE40FPGA.ashx?document_id=45822 | 12:02 |
| tnt | Ah well, I managed :p | 12:02 |
| *** proteusguy has joined #yosys | 12:03 | |
| *** rohitksingh has joined #yosys | 12:18 | |
| corecode | doesn't this take quite some space on the fpga? | 12:23 |
| tnt | DAC ? not so much. ADC a bit more since you need the CIC but depends what kind of rate / precision you want. | 12:43 |
| *** rohitksingh has quit IRC | 13:36 | |
| *** rohitksingh has joined #yosys | 14:01 | |
| *** emeb has joined #yosys | 14:33 | |
| *** promach2 has joined #yosys | 14:35 | |
| promach2 | corecode : is it difficult to write a USB softcore from scratch ? | 14:35 |
| *** ZipCPU has quit IRC | 14:37 | |
| corecode | i don't know | 14:37 |
| corecode | i've only written the protocol part, not the bit part | 14:38 |
| promach2 | bit part ? | 14:40 |
| promach2 | corecode | 14:41 |
| corecode | layer 0 and 1 stuff | 14:44 |
| *** citypw has joined #yosys | 14:44 | |
| promach2 | corecode : you don't need to do the physical layer part | 14:46 |
| promach2 | why would you ? | 14:46 |
| corecode | you don't need anything, you can buy everything completed | 14:47 |
| promach2 | no offense. I mean the physical layer involves IO analog circuitry, that requires tapeout | 14:50 |
| promach2 | corecode | 14:50 |
| corecode | no | 14:50 |
| corecode | usb LS and FS can be done with gpios | 14:50 |
| promach2 | and what exactly do you mean by "layer 0 and 1" ? | 14:51 |
| daveshah | the tinyfpga does it with a grand total of three resistors, the rest being done with FPGA pins | 14:51 |
| promach2 | two series resistors and one pull-up | 14:51 |
| promach2 | what exactly is "layer 0 and 1" ? | 14:56 |
| promach2 | I have been reading the official USB 2.0 spec , but there is no mention of that so far | 14:57 |
| promach2 | corecode | 14:57 |
| MoeIcenowy | daveshah: is the resistor value critical? | 14:57 |
| promach2 | MoeIcenowy : see https://github.com/avakar/usbcorev/issues/1 | 14:57 |
| tpb | Title: Extra resistor on FPGA transmitter pin · Issue #1 · avakar/usbcorev · GitHub (at github.com) | 14:57 |
| daveshah | The 1.5k should be reasonably accurate, iirc, but I don't know about the 68r one | 14:57 |
| corecode | promach2: sorry, i mean layer 1 and layer 2 (osi model) | 14:59 |
| promach2 | corecode : so, you are working on layer 2 (data link layer) now ? | 15:01 |
| corecode | promach2: i.e. physical layer (electrical) and data link | 15:01 |
| corecode | i am not working on anything | 15:01 |
| promach2 | so, you had done implementing chapter 8 of USB 2.0 spec | 15:01 |
| promach2 | now only left with chapter 5 | 15:02 |
| MoeIcenowy | I mean the 68r ;-) | 15:02 |
| MoeIcenowy | the SMT service where I use (JLC SMT) doesn't offer 0402 68R | 15:02 |
| corecode | promach2: what are you talking about | 15:03 |
| corecode | which 68R | 15:03 |
| corecode | jlc offers pcba? | 15:03 |
| MoeIcenowy | corecode: not full PCBA | 15:04 |
| MoeIcenowy | only the SMT of specified components | 15:04 |
| promach2 | corecode : chapter 8 is protocol layer , chapter 5 is data flow model | 15:04 |
| MoeIcenowy | and only available in Chinese | 15:05 |
| promach2 | corecode : USB 2.0 spec | 15:05 |
| MoeIcenowy | but with it I can use 0402 components... | 15:05 |
| MoeIcenowy | I don't dare to solder them by myself... | 15:05 |
| promach2 | corecode : see https://www.beyondlogic.org/usbnutshell/usb1.shtml | 15:05 |
| tpb | Title: USB in a NutShell - Chapter 1 - Introduction (at www.beyondlogic.org) | 15:05 |
| corecode | i know usb | 15:05 |
| promach2 | MoeIcenowy : no worry, with few weeks of practice, you could do 0201 with only soldering gun under few seconds | 15:06 |
| corecode | promach2: what are you working on? | 15:06 |
| promach2 | corecode : huh ? | 15:06 |
| MoeIcenowy | promach2: I have no soldering gun | 15:06 |
| MoeIcenowy | only soldering iron | 15:07 |
| emeb | heh | 15:07 |
| promach2 | same thing | 15:07 |
| corecode | promach2: what project are you working on? | 15:08 |
| corecode | you seem to be doing usb, network on chip, etc. | 15:08 |
| MoeIcenowy | oh I thought you meant heating gun | 15:08 |
| promach2 | no, you do not need hot-air gun | 15:08 |
| corecode | hot air station is important | 15:08 |
| corecode | and cheap | 15:08 |
| promach2 | soldering iron is way cheaper | 15:09 |
| promach2 | and precise | 15:09 |
| corecode | good one not | 15:09 |
| promach2 | corecode : going to start on usb once I am done with NoC | 15:10 |
| *** Thorn has joined #yosys | 15:12 | |
| corecode | is this for work or a hobby? | 15:14 |
| MoeIcenowy | I'm thinking whether I will be able to solder iCE40UP5K-SG48I with soldering iron | 15:16 |
| daveshah | The exposed pad will be tricky, and can't be skipped because it's the only grounding | 15:16 |
| MoeIcenowy | daveshah: I reserved a through hole for it | 15:17 |
| emeb | that's what kevin hubbard does - great big hole in middle of the exposed pad | 15:18 |
| emeb | fill in w/ solder from the back | 15:18 |
| emeb | I just use paste + hot air to solder those QFNs | 15:18 |
| corecode | MoeIcenowy: no, use hot air | 15:19 |
| MoeIcenowy | I remember once I got a free unsoldered GD32F150G8U6 board from JLC | 15:19 |
| MoeIcenowy | and finally I disposed it | 15:19 |
| corecode | you don't need paste, but you need hot air | 15:19 |
| MoeIcenowy | as I found I'm not able to solder the exposed pad of GD32F150G8U6 | 15:19 |
| MoeIcenowy | my table is too small to keep a hot air gun... | 15:20 |
| corecode | ok | 15:21 |
| corecode | i guess you can find some solder ninja just around the corner | 15:21 |
| emeb | corecode: so all your u4k work got accepted into mainline? | 15:23 |
| corecode | yes | 15:24 |
| emeb | \o/ | 15:24 |
| * emeb goes to pull & rebuild | 15:25 | |
| promach2 | u4k ? | 15:28 |
| emeb | older lattice ice40 ultra stuffs | 15:29 |
| cr1901_modern | Ahhh someone was gonna offer me hardware to do ultra RE, but I got too busy. Nice work | 15:53 |
| cr1901_modern | is ultralight still up for grabs? | 15:53 |
| daveshah | cr1901_modern: yeah ultralite still available | 15:54 |
| daveshah | happy to pay for hw too | 15:54 |
| cr1901_modern | hmmm tempting. (for the record, someone _else_ was gonna offer me h/w, but they're on social media break atm) | 15:55 |
| cr1901_modern | I've been trying to coordinate w/ Andres, but the times we are awake/active don't seem to coincide | 15:55 |
| cr1901_modern | corecode: You did just the 4k family of ultra? | 15:56 |
| daveshah | there is only the ultra 4k | 15:56 |
| daveshah | the other parts are pseudo-devices | 15:57 |
| daveshah | ditto there is only one ultralite | 15:57 |
| cr1901_modern | ahhh, well ultralite is about machxo2-1200 level of complexity | 15:57 |
| daveshah | yeah, although probably less fuzzer hacking needed as I think it is closer to the ice40up than the xo2 is to the ecp5 | 15:58 |
| cr1901_modern | let me touch base w/ andres. | 16:00 |
| cr1901_modern | corecode: MachXO2 is probably going to reach a point of usability soon. Would be happy to help w/ ultralite if you want to do it (or start it myself when machxo2 reaches minimum viable product). | 16:00 |
| emeb | daveshah: is u4k also in yosys & nextpnr? | 16:02 |
| daveshah | yes | 16:02 |
| emeb | nice | 16:03 |
| *** emeb_mac has joined #yosys | 16:14 | |
| *** emeb_mac has quit IRC | 16:16 | |
| MoeIcenowy | is someone doing MXO2 RE? | 16:21 |
| cr1901_modern | MoeIcenowy: Me, technically but it's stalled due to chronic "I can't multitask"-itis | 16:26 |
| *** lutsabound has joined #yosys | 16:29 | |
| *** rohitksingh has quit IRC | 16:42 | |
| *** rohitksingh has joined #yosys | 16:52 | |
| *** keesj has joined #yosys | 16:57 | |
| corecode | if you're going to put in dozens of hours for reversing, $30 for an eval board is negligible | 17:02 |
| MoeIcenowy | I think I have seen some LCMXO2-4000HC-4MG132 board for CNY ￥169 | 17:07 |
| MoeIcenowy | ~$25.15 | 17:08 |
| *** AlexDaniel has joined #yosys | 17:09 | |
| *** citypw has quit IRC | 17:31 | |
| *** rohitksingh has quit IRC | 17:53 | |
| emeb | always fun when building yosys to get to the 95% point where ABC takes the other 95% of the time. :) | 17:53 |
| shapr | I can build yosys so fast on my new laptop... now if I only had some clue about verilog | 18:10 |
| shapr | even the most powerful hardware does not increase my skills all by itself | 18:11 |
| *** m4ssi has quit IRC | 18:12 | |
| *** rohitksingh has joined #yosys | 18:18 | |
| emeb | lots to learn | 18:32 |
| emeb | corecode: daveshah: trying to build a simple blinky for u4k. yosys seems to work but nextpnr gives Fatal error: file not found --u4k | 18:33 |
| emeb | when i do --help for nextpnr it lists --u4k as a device option though. what am I doing wrong? | 18:34 |
| daveshah | emeb: what is your full command line? | 18:34 |
| emeb | nextpnr-ice40 --pcf-allow-unconstrained --pre-pack --u4k --json bob_blinky.json --pcf ../src/bob_blinky.pcf --asc bob_blinky.asc | 18:35 |
| daveshah | --u4k shouldn't be after --pre-pack | 18:35 |
| emeb | ok | 18:35 |
| daveshah | --pre-pack file runs a Python file before packing | 18:35 |
| daveshah | Usually for constraints | 18:35 |
| daveshah | So it's interpreting --u4k as a file | 18:36 |
| emeb | daveshah: ok - I see what's wrong. missing the constraint file define in my makefile. derp. | 18:37 |
| emeb | daveshah: is there a place I can look which tells me what cells a particular target FPGA family supports? | 18:39 |
| emeb | eg - what's the name of the RGB driver in u4k | 18:39 |
| emeb | since it's not the same as in up5k | 18:40 |
| emeb | and doesn't match up with what icecube2 uses. | 18:40 |
| daveshah | No, I made that for ECP5 but nothing like that exists for ice40 other than vendor documentation | 18:40 |
| daveshah | Ask corecode but I don't think the u4k rgb is supported in nextpnr yet | 18:40 |
| emeb | kk | 18:41 |
| emeb | corecode: do you implement the RGB driver in u4k? | 18:41 |
| emeb | if so, what's it called? | 18:41 |
| *** lutsabound has quit IRC | 18:59 | |
| tnt | Does anyone see anything wrong with that functions : | 19:01 |
| tnt | https://pastebin.com/jMEWFGht | 19:01 |
| tpb | Title: function [15:0] ram_wr_map2 (wire [1:0] wdata); ram_wr_map2 = { - Pastebin.com (at pastebin.com) | 19:01 |
| *** promach2 has quit IRC | 19:12 | |
| emeb | nothing obvious to me | 19:19 |
| tnt | arf, you need 'input wire' and not just 'wire' .... | 19:22 |
| ylamarre | ... VHDL has a nice "feature for this kind of assignement where you can assign parts of a signal then give a "default value" to others.... | 19:29 |
| * ylamarre wonders if nMigen and/or MyHDL have this feature... | 19:30 | |
| tnt | ylamarre: oh yeah right. tbh I mostly used that to assign 0 to the whole verctor :p x <= (others => '0'); :p | 19:41 |
| ylamarre | Yes, but you can also do weird slices that way too. | 19:42 |
| ylamarre | Most missed feature when I had to transfer to verilog. | 19:43 |
| tnt | Damnit, iverilog doesn't like my function either ... syntax error :/ | 19:44 |
| tnt | 'input wire' -> 'input' | 19:47 |
| *** gsi__ is now known as gsi_ | 19:52 | |
| tnt | Mmm, yosys doesn't seem to like the 'new style' of having the reset at the end of the process when using a 'case' and an async reset : https://pastebin.com/NWwTrNmz | 20:10 |
| tpb | Title: always @(posedge clk or posedge rst) begin case (d) - Pastebin.com (at pastebin.com) | 20:10 |
| tnt | ERROR: Multiple edge sensitive events found for this signal! | 20:10 |
| emeb | I remember Clifford advocating for the "reset at end" style. Interesting that yosys doesn't like it sometimes. | 20:20 |
| ylamarre | Looks like it's more about the always block then the reset location... | 20:25 |
| ylamarre | Coded this way it looks like you have two clocks. | 20:25 |
| tnt | ylamarre: https://pastebin.com/bbMW7JzN | 20:29 |
| tpb | Title: module test( input wire d, output reg q, input wire clk, input wire rst - Pastebin.com (at pastebin.com) | 20:29 |
| tnt | this is the other variant that works fine. | 20:29 |
| ylamarre | Wow... | 20:30 |
| daveshah | tnt: I don't think the first code is legal Verilog for synthesis | 20:31 |
| daveshah | see p9 of http://www.iuma.ulpgc.es/~nunez/clases-FdC/verilog/Verilog-IEEE-1364.pdf | 20:31 |
| tnt | daveshah: Ok, indeed, so it's not yosys specific. It's just that in verilog with async reset you don't have a choice you _must_ use the legacy style resets. Good to know. | 20:37 |
| tnt | TIL :) | 20:38 |
| daveshah | However, aiui, async reset blocks don't have the "not putting a signal in the reset block makes reset a clock enable instead of just ignoring reset" problem as with sync resets | 20:43 |
| daveshah | so the only problem is inconsistency, the actual advantage of the reset at end style isn't present | 20:43 |
| tnt | Yeah, I was going for consistency :) But I never do process that have mixed reset/non-reset signals anyway, so the 'end style' is really just a 'style' for me ... no actual benefit. | 20:46 |
| *** lutsabound has joined #yosys | 22:23 | |
| corecode | can you explain? | 23:52 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!