MikeFair_ has quit [Ping timeout: 252 seconds]
_whitelogger has joined ##openfpga
<lain> tried looking at the gcc patches for avr32, but I'm pretty sure it just summons demons to do the actual patching
<azonenberg> no, i think it uses daemons
<azonenberg> :p
<lain> haha
<lain> one of the uc3 revisions was missing the multiply instructions
<lain> like, they were totally missing from impl
<lain> atmel are pros at testing
<lain> the errata is like "workaround: use software multiply"
<lain> it's unclear if that was ES silicon or if it was pre-silicon, but since it has an errata in the public datasheet, and a revision letter... I'm guessing that was silicon of some kind :/
<lain> anyway, sounds like I have my work cut out for me if I want to target avr32 with rust heh
<lain> or I could accept my C++ fate
<whitequark> lain: sure you don't want me to write the avr32 backend? :p
<lain> whitequark: I have $5, a stale taco, and some pocket lint. is that enough?
<whitequark> that's not a lot
<lain> I may be able to upgrade that to a fresh taco
<whitequark> lol
<whitequark> well... idk
<lain> does rust have bitfields?
<whitequark> if you write all the boilerplate i may write the instruction selector for you
<whitequark> aka the hard part
<whitequark> I just really hate writing twenty files of LLVM target where you hvae to replace its name in slightly different ways
<whitequark> bitfields: not in the core language
<whitequark> but I'm sure someone wrote a crate for it
<lain> "Unlike in C, the position of each bytes and bits in the underling bytes array is specifed. The bytes are in network order, and the bits are MSB first. No padding is added."
<lain> this person gets it.
<azonenberg> lain: whitequark has pretty much convinced me to write the next-gen antikernel userland in rus
<azonenberg> rust*
<lain> ok yeah, this is actually pretty similar to what I was doing with macros in C
<lain> azonenberg: yeah, rust seems interesting. I'm going to rewrite this code, regardless of target language... might be a good test case for rust
<azonenberg> lain: well my dream is
<azonenberg> memory-safe userland
<azonenberg> running on top of a formally verified cpu
<azonenberg> on an antikernel soc
<lain> I just know
<lain> if I have to interact with one more fucking header file
<lain> I'm going to throw my computers out the window and take up knitting or something
* lain pokes the C++ standards peeps, asks what's taking so long with the "module" stuff
<lain> not that it matters. atmel won't update avr32-gcc, so I can't take advantage of such space-age technology when it finally happens
<rqou> eh, I don't really get why modules are important
<rqou> i guess I haven't hit the footguns
<lain> rqou: mostly that header files are an annoying relic of the past, and totally unnecessary
<rqou> I'd rather have the ABI stuff fixed
<rqou> especially on Winblows
<qu1j0t3> lain | I'm going to throw my computers out the window and take up knitting or something || yeah, fighting systemd yesterday and today makes me feel the same
<lain> haha
* qu1j0t3 nods
<lain> I haven't had the (mis)fortune of encountering systemd yet
<qu1j0t3> it's waiting for you
<lain> as long as freebsd doesn't move to it, I probably never will :3
<cr1901_modern> lain: Rust has an alternate backend (MIR) so you don't have to go the LLVM route. It might be even more work tho. But LLVM is so intractible to me that it's tempting
<lain> hehe
<lain> llvm is neat, I've been meaning to poke it
<lain> they have some nice-looking tutorials on adding a new backend... I'll... try it...
<cr1901_modern> Look at the cpu0 backend
<clifford> felix_, it is completely unrelated to carry chains. The bits in question are related to interconnect tiles, not logic tiles. E.g. INT_R_X15Y135/INT_R.NR1END0->>NR1BEG0 and INT_R_X15Y135/INT_R.NE2END0->>NR1BEG0 seem to share the same bits.
<felix_> clifford: ah, ok. i'll try to look into that later
<azonenberg> clifford: which device are you looking at?
<clifford> azonenberg, xc7a50t
<azonenberg> oooh shiny :D
<azonenberg> color me very interested
<lain> :D
<azonenberg> like, VERY interested
<azonenberg> lol
<azonenberg> clifford: a f/oss flow for 7 series has been on my wishlist for a very long time, as you probably know
<clifford> azonenberg, all of us
TGILITO has quit [Quit: Saliendo]
* cr1901_modern would rather have a 6 series backend, but that's b/c of BGA lol
<cr1901_modern> Even the Spartan 7 is going to be BGA only now
<lain> mmmm
<lain> I heard s7 will have the tqfp
<cr1901_modern> I keep hearing conflicting reports, tbh. The 7-series datasheet mentions a QFP, but doesn't actually give dimensions for it
<lain> huh, it's not in ds180 though
<lain> yeah
<cr1901_modern> So it's an error. But which way?
<felix_> compared to a7 (or probably even s7), s6 is meh
* felix_ isn't afraid of bga parts though
<lain> at least one s7 is a nerfed a7
<lain> but there seem to be smaller s7's that are a different die
<lain> sadly no s7 will have transceivers
<lain> clifford: your 33c3 talk is making me want to consider verilog (instead of vhdl, which I use currently)
<felix_> lain: do i remember correctly that you're working on a usb3 core which uses the a7 transceivers and an external usb2 phy? if so, are you planning to open source the fpga design?
<felix_> clifford: hmm, does every bit correspond to exactly one pip or are there also pips which need two bits to be set?
<clifford> most of them require more than one bit
<felix_> i probably should try to dig out the patent on the xilinx switch bozes
<felix_> *bexes
<felix_> *boxes
<lain> felix_: yes, I am working on that. but no, it is not going to be open source.
<felix_> ok
<felix_> then it would probably the easiest way to take the existing usb3 fpga design for that really expensive ti transceiver and make it use the transceiver for the usb3 part
Ardeshir has joined ##openfpga
Ardeshir has quit [Quit: Leaving]
balrog has quit [Ping timeout: 258 seconds]
balrog has joined ##openfpga
pie_ has joined ##openfpga
kuldeep is now known as mmnip
mmnip has quit [Killed (mniip (no))]
mmnip has joined ##openfpga
mmnip is now known as kuldeep
kuldeep is now known as piinm
piinm is now known as Y0u
pie_ has quit [Ping timeout: 268 seconds]
Y0u is now known as k1ine
k1ine has quit [Killed (e (please stop))]
kuldeep has joined ##openfpga
<openfpga-bb> build #50 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/50 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMtgl
<openfpga-github> openfpga/master d7b680a Andrew Zonenberg: Added Luts HiL test
<lain> you BROKE IT
kuldeep is now known as dogs
dogs is now known as kuldeep
<azonenberg> also lol the buildbot was faster than the commit message
<openfpga-bb> build #51 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/51 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMtgR
<openfpga-github> openfpga/master e57b4b2 Andrew Zonenberg: Updated Luts test with more details
kuldeep is now known as dogs
dogs is now known as kuldeep
<openfpga-bb> build #52 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/52 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<azonenberg> huh i thought that was it...
<openfpga-github> openfpga/master cb0cc92 Andrew Zonenberg: BUGFIX: test passed input signals in the wrong order
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://github.com/azonenberg/openfpga/commit/cb0cc927df6056da070f382385a3cdba41d1df37
<openfpga-bb> build #53 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/53 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://github.com/azonenberg/openfpga/commit/784bf6ba05232eba304550d6387e7d5d7940115d
<openfpga-github> openfpga/master 784bf6b Andrew Zonenberg: tests: Fixed pin numbering to be more sane, corrected another numbering error
<azonenberg> Ok, less errors...
* azonenberg looks
<azonenberg> LOL
<azonenberg> ok, legitimate error
<azonenberg> i had an error in the gp4par example code
<azonenberg> that i copied into my test case
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMtgh
<openfpga-github> openfpga/master 691962d Andrew Zonenberg: tests: Fixed incorrect truth table in Luts HiL test. Fixed incorrect LUT truth table in GP_2LUT example code
<openfpga-bb> build #54 of openfpga is complete: Success [build successful] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/54
<azonenberg> that bug threw me off lookign for the typo'd pinout
<azonenberg> because nothing made sense lol
kuldeep is now known as sudo
sudo is now known as kuldeep
kuldeep is now known as i
i is now known as Guest56530
Guest56530 is now known as kuldeep
kuldeep is now known as softtek
softtek is now known as kuldeep
<openfpga-bb> build #55 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/55 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMt2g
<openfpga-github> openfpga/master 0f3473a Andrew Zonenberg: tests: Added HiL test for GP_LFOSC
<openfpga-bb> build #56 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/56 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://github.com/azonenberg/openfpga/commit/d56da5bcc5761626c73d45fae7aab4f28c0c6257
<openfpga-github> openfpga/master d56da5b Andrew Zonenberg: tests: Changed LFOsc test voltage to 3.3
<azonenberg> whitequark: can you look into this?
<azonenberg> i cant find any reason it shouldn't be working
<azonenberg> maybe integer overflow in the counter or something? maybe the freq counter can't run that slowly?
* lain stares into the llvm abyss
<lain> at least there's a walkthrough...
<lain> what kind of sick bastard uses spaces for indentation
<azonenberg> lain: the designers of yaml
<azonenberg> its one of the few things i dislike about it
<lain> azonenberg: the llvm devs also, apparently
<azonenberg> i think a lot of gnu code too
* lain adjusts editor settings, grunts.
<azonenberg> one \t makes a lot more sense, it's semantically "one indent"
<azonenberg> how you render that is up to you
<lain> yes
<lain> precisely
<lain> it is objectively the superior choice
<azonenberg> 4 vs 8 columns is a matter of personal preference
<lain> they use 2 column, using spaces
<azonenberg> but spaces bulk up the file and are make less semantic sense
<lain> it's maddening
<azonenberg> wut?
<azonenberg> not even 4?
<lain> not even 4.
<azonenberg> idk if thats better or worse than 8 spaces lol
<lain> 8 is pretty bad
<lain> lol
* azonenberg basically uses the visual studio indentation style for everything
<lain> yeah
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMt2d
<openfpga-github> openfpga/master b43cb6c Andrew Zonenberg: tests: Added HiL test for ring oscillator
<openfpga-bb> build #57 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/57 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<azonenberg> well we know the lfosc test was borked
<azonenberg> let's see if the ring osc worked
<azonenberg> um...
<azonenberg> clearly i'm doing something wrong
<azonenberg> now this is interesting
<azonenberg> if you ignore the 6* at the start
<azonenberg> the measured ring osc freq looks sane
<azonenberg> 13.5 ish MHz
<azonenberg> 13.56 interestingly enough, lol
<azonenberg> but i think that's coincidental as i got the same garbage measuring the LF oscillator
<azonenberg> rqou: also when you're around
<azonenberg> i wanted to discuss your progress on the coolrunner effort and figure out how we want to move forward
<lain> can't say I'm pleased by the llvm code style, but at least it's consistent
kuldeep is now known as y0u
y0u has quit [Disconnected by services]
kuldeep has joined ##openfpga
Ardeshir has joined ##openfpga
Ardeshir has quit [Quit: Leaving]
<lain> this cpu is a pain
<lain> why am I doing this to myself :|
* azonenberg would suggest drop it
<azonenberg> say there will be no future s/w releases
<lain> nah
<azonenberg> and do futrue dev on stm32 or so
<cr1901_modern> world needs less ARM IMO.
<lain> future dev will be arm
<lain> because avr32 needs to die
<lain> but I don't feel ok abandoning my existing customers
<lain> they are numerous.
<azonenberg> yes but how many of those customers need new code?
<lain> azonenberg: all.
<azonenberg> it seems like isostick is a pretty stable product, no?
<lain> no
<lain> lol
<lain> there's.. outstanding issues
<azonenberg> oh?
<lain> which I've been meaning to fix for uh
<lain> 4 years
<lain> give or take
<lain> burnout, etc
<balrog> Thoughts on atmel sam?
<lain> balrog: as a rule, I avoid atmel nowadays unless they have something unique I need (and it's arm). their sam series seems good, I have a sam3u devkit lying around somewhere and it's nice
<lain> the vendor libs are, predictably, godawful though
* felix_ doesn't like the sam3u very much
<lain> oh?
<felix_> sure, it's cheap
<felix_> but the gpio pins (including the external memory interface) are slow
<felix_> can't push data from an fpga to the usb interface on the sam3u at full usb2 speed
<felix_> so if you want to use the chip in a project using the external memory interface or any faster gpio stuff make sure to have a look at the timing stuff of the gpio and memory interface...
<lain> that's what cypress and ftdi are for
<lain> ;)
<balrog> How is SAMD21?
<azonenberg> no, that's what RGMII is for :P
<felix_> my go to chip for reasonably fast usb interfaces is the ft601; not too expensive either. but only a set of data pipes
<lain> whitequark: roughly how long would it take you to add support for a new arch in llvm? asking so I can 5x it and guesstimate how fucked I am :P
<felix_> never used the smaller sam microcontrollers
<lain> so far llvm is pretty straightforward, just lots of boilerplate and tables ahead of me...
<felix_> well, ethernet is more complex than just pushing some data into a usb3 fifo ;P
<balrog> I've been playing with it (LoRAHam project) and they're not bad
<lain> we'll see what's on the other side after that though
<lain> oooh LoRaWAN stuff?
<balrog> Also someone should upstream PIC24/32 ;)
<balrog> lain: no. #loraham
<balrog> Something @travisgoodspeed started
<cr1901_modern> PIC32 is a MIPS. Yamn.
<lain> balrog: is that like lorawan at all?
<cr1901_modern> Yawn* :P
<balrog> A lot simpler intended for ham use
<balrog> cr1901_modern: there's additions that have not been up streamed
<felix_> oh and what also bite us when were porting a usb2 stack to the sam3u was that its watchdog timer is enabled by default. took quite some time to find that out...
<lain> neat
<cr1901_modern> Oh I'm sure I'm oversimplifying
<lain> felix_: lool
<lain> the sam3u vendor usb lib is so baaaad
<lain> sobad.
<lain> it's like layers upon layers of needless indirection and complex nonsensical "object models"
<lain> I'm all for OOP, but that wasn't OOP, it was an abomination
<felix_> i think the person working on that only looked at some parts of the vendor lib to find out some stuff that wasn't clear from the datasheet
<cr1901_modern> like the iapx 432 (which also had built in OOP in the arch level... don't ask me how)?
<cr1901_modern> oh vendor LIBRARY, not h/w
<lain> heh. that reminds me of that time I was writing a usb stack for an older atmel chip (this was ca. 2005) and after months of banging head against desk to no avail, I finally checked some 3rd party code....
<lain> printed it out, printed mine out, had a nice sit down for a few days going over it line by line, comparing it all exactly
<lain> and finally I found the ONE DIFFERENCE
<lain> a PLL setting.
<lain> the datasheet was wrong.
<felix_> the layers on layers of indirections sounds quite uefi-like ;P
<lain> I notified atmel of this typo, a 1 instead of a 0 in the pll register settings. silence.
<azonenberg> lain: you make it sound like datasheet errors are a rare occurrence
<lain> several months later I notified them again. "thank you for bringing this to our attention..."
<lain> years went by
<lain> I don't think it was ever fixed
<cr1901_modern> I destroyed a number of LM2907's b/c the max voltage on the datasheet was wrong and I kept applying too much voltage to the rails (but not above datasheet max)
<lain> lol
<azonenberg> you *have* seen some of mine, right? :p
<qu1j0t3> lain: :(
<lain> azonenberg: yeah, but man... not fixing it... when it's a critical-to-function setting (you have to put the pll in "usb mode" to enable the usb clocks, and they gave the wrong bits for that)
<lain> iirc some of atmel's sample code also used this invalid setting
<azonenberg> lol
<lain> I mean ok, now I know to check the vendor libs first and foremost
<azonenberg> ouch
<lain> but I didn't back then :P
<azonenberg> Lol yeah
<azonenberg> i've now learned which parts of silego's docs are generally authoritative in case of a contradiction
<balrog> On the other hand microchip had those stack bugs
<lain> actually iirc I was avoiding the vendor libs because I discovered their usb implementation was against usb spec in a lot of ways
<azonenberg> (appendix A is normally pretty good, the chapter on each peripheral often has serious errors)
<openfpga-bb> build #58 of openfpga is complete: Failure [failed make_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/58 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<lain> rip
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://github.com/azonenberg/openfpga/commit/7030ab1a8d2066edec165dcf5393a9eb444ae03a
<azonenberg> huh it compiled fine on my box
<openfpga-github> openfpga/master 7030ab1 Andrew Zonenberg: tests: Added DCMP test
* azonenberg looks
<azonenberg> oh derp
<azonenberg> i built before i added that file to the build
* azonenberg facepalms
<lain> another datasheet bug that bit me was on a switching converter
<lain> that one was pretty magical
<lain> high current switching converter, has equations to calculate the appropriate compensation network for the feedback loop... except they're wrong
<lain> and it's REALLY NOT OBVIOUS
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMtr7
<openfpga-github> openfpga/master 4bcdb85 Andrew Zonenberg: tests: fixed typo in last commit
<lain> because ok, the datasheet starts with some equation, and then lists out step by step a sample solution if the equation
<openfpga-bb> build #59 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/59 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<lain> like, they fill in the variables, and then one step at a time they solve this equation, across several pages of the datasheet
<lain> they arrive at the correct answer for their inputs
<lain> but if you follow along at home, they get there by... making shit up
<lain> the equation they started with was wrong
<lain> and like, in one step they'd just fudge a number, then fudge another number in another step, etc, until they end up with the correct answer
<azonenberg> lol
<azonenberg> that reminds me of a TA i had in multivar calc
<azonenberg> guy multiplied two matrices in the wrong order, or did columns instead of rows, or something
<lain> turns out if you use their excel spreadsheet calculator thingy, that gives the correct answers...
<azonenberg> live in front of the class
<azonenberg> and fudged it to get the right answer in the end
<lain> lool
<azonenberg> but his magic math only worked if <1 1> dot <1 2> = 2
<azonenberg> or something equally absurd
<rqou> heh, in my OS class their example for signal handling called printf in the signal handler
<lain> ack
<mtp> UM.
<rqou> I pointed out that that isn't allowed
<rqou> but their example just spun in a loop in the main function
<rqou> so it works in that case
<azonenberg> yeah
<azonenberg> i've seen anti-debug code that sets up a handler for SIGTRAP or SIGSEGV
<azonenberg> puts the entire app in that handler
<lain> that's going to confuse a lot of people who don't understand why it's not allowed and break shit later :P
<azonenberg> then main just triggers the signal
<lain> lol
<lain> I still love the xilinx thing
<mtp> i've once thought of converting code to all live in C++ destructors
<azonenberg> mtp: eeew
<azonenberg> lol
<mtp> and so main is just delete new App()
<lain> where the entire fucking library is just obfuscated code setting up ROP chains
<lain> and then returning into them
<mtp> lol
<lain> it returns into calls to external libs, too
<lain> because fuck it
<mtp> that cornholes the average branch predictor iirc
<lain> IDA was /pretty fucking confused/
<lain> "ok there's about 10,000 function fragments and NONE OF THEM ARE EVER CALLED"
<mtp> lmao
<azonenberg> lol
<azonenberg> mtp: in case you wondered why vivado was slow
<azonenberg> :p
<lain> they used streaming simd instructions to fill the stack with rop gadgets and shuffle them around, too, just to make things more confusing
<lain> yeah
<lain> I mean, that's actually true as far as I can tell
<lain> this is the SecureIP code, but the same code is used even if you're processing non-encrypted HDL
<azonenberg> you should try and convert that rop junk back to native code
<mtp> a friend of mine (used to?) work for xilinx
<azonenberg> and see how much faster it runs
<lain> azonenberg: I would if I could automate it, but I don't feel like taking the time to deobfuscate their simd junk
<lain> the rop chains it sets up are many thousands of gadgets long
<lain> it's insane
<lain> it takes nontrivial amounts of time to do this :P
<lain> I meant to check if the linux code does this
<rqou> wait, it's no longer the old "just invoke libPortability" thing?
<lain> rqou: this is the SecureIP lib
<lain> which I was only stabbing because it was preventing me from debugging something else
<lain> I couldn't care less about their encrypted garbage
<rqou> that's not the "files that start with XlnX" thing?
<lain> it's used for all HDL, encrypted or not
<rqou> the old HDL could be decrypted by poking libPortability
<lain> ah
<lain> lol
<lain> not surprised
<rqou> on ISE, not Vivado
<lain> but this was the actual crypto lib, it prevented me from debugging vivado
<lain> has a million tricks, and the ida anti-anti-debugger plugin only works on 32bit, vivado is only 64bit
<rqou> I've never used ida as a debugger
<rqou> only ollydbg
<azonenberg> Sooo hmm
<azonenberg> DCMP block is (I think) implemented
<azonenberg> but not doing what i wanted
<lain> lul
<rqou> for a while I was using a "scene" patched Ollydbg that had debug hiding patches
<rqou> iirc it was called "SND"
<lain> if/when I finish this intel motherboard, I wonder if I'll be able to attach a hardware debugger and just bypass all that :P
<rqou> this was also the winxp era where there were all sorts of near-rootkit kernel patching bullshit to hide ollydbg
<lain> there's a game I'd like to RE the netcode for, to see why it's so awful... but it's protected by Themida, which is just... I don't have the time :P
<rqou> "scene" code is scary
<rqou> Themida still exists?
<lain> yeah
<rqou> that brings back memories
<balrog> What game?
<lain> I had never heard of it until I poked this game
<lain> balrog: Ghost in the Shell: First Assault
<rqou> nProtect GameGuard in my case
<balrog> Someone used it to "protect" an extremely sketchy fork of MAME that added PGM2 support
<lain> lol
<rqou> I actually factored their old RSA key
<azonenberg> i was asked by someone, i forget who, to crack some themida-encrypted anticheat thing a while ago
<azonenberg> said no
<azonenberg> so i never really had a chance to study it in detail
<azonenberg> but it still existed as of a few years back
<rqou> probably nProtect GameGuard :P
<lain> this is like... BlackCipher.aes?
<lain> which uses Themida
<lain> or something
<lain> it's such a departure from big-$$$$ commercial software, which is "protected" by the equivalent of a "please don't" sign
<rqou> lool
<azonenberg> lain: well it makes sense
<azonenberg> low-end stuff has to stand on its own
<lain> azonenberg: yeah, their revenue is tied to the game being not-hacked, for multiplayer anyway
<azonenberg> they dont have the budget to pursue infringers, plus there's a bazillion potential users
<lain> if people can cheat, that ruins the experience
<lain> and then people won't play
<azonenberg> But on the other hand
<cr1901_modern> balrog: How does one "protect" a fork?
<azonenberg> for high-end commercial stuff
<cr1901_modern> Besides stabbing someone with it
<azonenberg> there's only a few users and its usually not hard to tell that somebody used your app and didn't pay for it
<balrog> Add private crap to it and then encrypt the binary
<lain> yeah
<rqou> I've even seen Themida+Y0da
<azonenberg> at which point you can sue them because you have money, and they have money t otake
<lain> I don't even know what Y0da is
<lain> I'm totally unfamiliar with protection schemes outside of like flexlm
<lain> flexlm is just trivial to bypass :<
<rqou> some other random exe cryptor
<rqou> so it was nested :P
<lain> in PADS they just run all the flexlm codes through a single unsigned dll
<lain> I kept forgetting my usb dongle
<lain> so I just patched out the check :P
<rqou> I also recall hiding my exe that was false-positive-ing Norton AV by just throwing it into PECompact
<rqou> :P
<lain> haha
<balrog> lain: do they do any phoning home for antipiracy?
<rqou> it was a thing that I did to learn ASM
<balrog> Some companies do that and then you get a letter from their lawyer (or your ISP does)
<rqou> a "scene"-style no-import-table hello world
<lain> balrog: none that I could detect, but I wrote a script to apply the patches and then apply windows firewall rules to disallow any file within the PADS installation from ever reaching the internet :P
<rqou> also exes with no imports on Windows really is _weird_
<rqou> because Windows doesn't have consistent syscall numbers
<azonenberg> lol yeah no imports at all is a red flag for something beign heavily packed
<azonenberg> usually even packed stuff will have imports for like LoadLibrary() and GetProcAddress()
<cr1901_modern> imports in the DLL sense?
<cr1901_modern> Even tho I use Windoze, tbh I know rather little about how binaries run on it
<rqou> yeah, DLL imports
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/vMto7
<openfpga-github> openfpga/master b069ded Andrew Zonenberg: gp4par: DRC: Verify DCMPs all have same power-down setting
<openfpga-github> openfpga/master 0946306 Andrew Zonenberg: greenpak4: DCMP no longer writes power-down mux if unconnected
<rqou> the hack that I was using was that you would assume that the return address at your exe entry point was somewhere within kernel32.dll
<openfpga-bb> build #60 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/60 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<rqou> you take that return address, clamp it to the page boundary, and keep searching backwards until you see "MZ"
Ardeshir has joined ##openfpga
<azonenberg> lol
<openfpga-bb> build #61 of openfpga is complete: Failure [failed test_openfpga_normal] Build details are at https://openfpga-dashboard.antikernel.net/builders/openfpga/builds/61 blamelist: Andrew Zonenberg <azonenberg@drawersteak.com>
<azonenberg> Random trivia bit
<azonenberg> Who is MZ? ;)
<cr1901_modern> The guy who put his initials in the MZ file format
<rqou> Mark Zbi<mumble mumble can't spell>
<rqou> :P
<azonenberg> rqou: ;p;
<azonenberg> yep
<azonenberg> lol*
<cr1901_modern> My answer's not wrong either
<cr1901_modern> Just useless ;)
<azonenberg> welp, my HiL tests are moving along
<rqou> anyways, another "scene" way to avoid inputs was to look at the TIB at fs:[0], get the PIB, and look at the loaded module list
<rqou> *imports
<azonenberg> yes thats more what i'm used to
<azonenberg> i've seen malware doing that
<lain> found out something cute about SpinRite.exe, when you run that in windows you get a little window that lets you create a bootable flash drive or iso... that exe is the exact same one it puts in the iso/flash drive to run in FreeDOS
<azonenberg> And i can confirm I have the DCMP block working in comparator mode (not yet set up for PWM)
<azonenberg> next up is to implement DCMP inputs from counters
<cr1901_modern> The guy who wrote SpinRite is a bit of a conspiracy theory loon
<lain> since apparently when they extended the exe format to do windows stuff, they left an executable section for non-windows... that's what runs and prints out "This program requires Microsoft Windows" or whatever it says when you run a windows app in dos
<azonenberg> And then i can finally have a useful subset of the DAC working
<azonenberg> lain: yep
<lain> so he just
<lain> wrote spinrite in that bit
<lain> and put a gui app in the other bit
<lain> and it's all like 30kB or something because assembly :P
<cr1901_modern> lain: Many pieces of Windows software do that tho :P
<azonenberg> so in principle its totally possible to have a windows and dos app in the same PE/MZ executable
<cr1901_modern> there's a linker option to change the stub
<lain> azonenberg: exactly, that's what he did
<azonenberg> i think i've seen that in some windows system utility?
<rqou> so he's insane like nocash? :P
<azonenberg> cant recall which one
<azonenberg> but it's been done
<lain> cr1901_modern: I think he's mostly over that, but he is a bit alarmist still about certain things
<cr1901_modern> nocash isn't insane. He's just a luddite
<cr1901_modern> not without reason either
<rqou> apparently nocash lives in Hamburg
<rqou> I wonder if he attends/sneaks into CCC?
<lain> he does the Security Now podcast (Steve Gibson, the SpinRite author), which is a fun podcast. sometimes they get stuff wrong, but it's a convenient news source when I'm driving around :P
<balrog> NoCash dude is not a crank
<balrog> rqou: considering that he's always broke I doubt it
<rqou> sneaking in doesn't require money :P
<cr1901_modern> balrog: I was talking about the spinrite author
<cr1901_modern> he's a loon, not nocash
<cr1901_modern> nocash just likes to hold out against Wirth's Law
<lain> for any sufficiently complex software, you can't beat the compiler
<lain> I'll put money on that :P
<lain> at least, not for any modern cpu
<lain> for simple risc machines, sure.
<azonenberg> you dont have to beat the compiler
<azonenberg> you just have to not write your software in horribly bloated fashion
<lain> right, that too
<azonenberg> and expanding to fill all available cpu power and memory :p
<lain> you can write good high-level-language code
<lain> just most people don't
<cr1901_modern> Never once did I say we should write everything in assembly :P. What I *am* concerned about is our willingless to shove the complexity in regions such that only a few people know how to handle it
<lain> either because they don't know how, or they don't care
<cr1901_modern> as opposed to sharing the burden with users
* cr1901_modern thinks about systemd and cries a bit
<rqou> eh I don't really care about systemd one way or another
<lain> I have no strong opinions either
<lain> but I'm a windows and freebsd user, mostly, so systemd hasn't affected me :P
<felix_> lots of stuff is better than the pile of bash scripts called init system we had before ;P
<lain> that's the impression I get, yeah
<cr1901_modern> I can at least fix bash scripts
<cr1901_modern> systemd would take a week or more to figure out how to fix.
<lain> freebsd's init is pretty sane, I've found it easy to extend and configure... it's probably not as nice as systemd from a sysadmin perspective, but yeah
<cr1901_modern> rc.conf is pretty well-behaved
<lain> yeah
<cr1901_modern> it's able to figure out the order to do everything too
<lain> yep, and you just specify dependencies and such in the init script, and variables, and it provides you a toolkit of functions... and it's all documented in the handbook...
<lain> no complaints really
* felix_ had to debug some weird bug that was caused by some sort of race condition in the old sysv-init. might have been due to some debian-specific stuff though; i don't really remember that any more
<lain> debian's init was annoying :/
<rqou> in my experience Linux boot always had a fuckton of bugs and race conditions
<lain> yeah
<rqou> I just make it so that I win the race the majority of the time
<lain> what finally kicked me to freebsd was kernel devs putting religion above code
<rqou> :P
<lain> rqou: lol
<felix_> having some productive system which is only reboot-safe in about 70% of the time isn't fun :/
<rqou> "the thing that reads /etc/network/interfaces" (on Debian) loves to race both itself and other daemons
<lain> lol
<rqou> but if you lose the race the upstream link will usually come up still
<rqou> only the "internal" side will fail
<rqou> (this is on a router)
<rqou> on my system iirc I fixed it so I basically always won the race except with smbd/nmbd which are non-critical
<rqou> I don't get why this is such a difficult problem
<lain> in freebsd this is just a matter of adding a dependency to the file, it's part of the start of the script
<lain> then `rcorder' will order it appropriately
<rqou> the /etc/network/interfaces can't express dependencies within itself
<rqou> or with "something else" inserted in the middle
<lain> can you make the network script block until it's up? or did I misunderstand the problem
<rqou> e.g. a br0 that requires a tap0 that requires an OpenVPN to launch first
<lain> ahh
<lain> I think in freebsd that would be like... openvpn would have its own rc script, which could depend on the network interfaces. then other things could depend on openvpn.
<lain> or etc
<lain> I should sleep
<rqou> my favorite was iirc a br0 that depends on hostapd that depends on wlan0 in the config file
<lain> XD
<rqou> all this is also racing with dnsmasq in the meantime
<rqou> :P
* lain passes out
<lain> see you folks next year!
<lain> :P
<rqou> hmm only 22:34 here
<rqou> going to hopefully see some fireworks here in Amsterdam
<lain> 16:38 here
<cr1901_modern> I'm prob gonna watch speedrunners do a race while waiting for the Hell Year to die
<cr1901_modern> lain: Before you go to bed
<cr1901_modern> if you are building Clang on Windows, chances are you will need a patch unless you're targeting trunk
<cr1901_modern> erm, s/trunk/master/
<rqou> building on Windows? masochist :P
<cr1901_modern> I'm not about to move all my shit to a Linux system, and my NetBSD installation is borked currently
<cr1901_modern> and too lazy to post on mailing list on "unborking-procedures"
<cr1901_modern> other than "it can be done, so why don't I put it off and make it harder"
<rqou> I only really work on Linux nowadays
<rqou> too tired of dealing with driver bullshit on other operating systems
<cr1901_modern> I know :). You make a point to bring that up every time I complain about Windows
Bike has joined ##openfpga
<felix_> if just someone would pay some good ui designer to improve the ui situation on linux...
<cr1901_modern> FreeDesktop?
_whitelogger has joined ##openfpga
<rqou> happy leap second :P
Ardeshir has quit [Quit: Leaving]