<rqou>
someone now needs to make a TAS that starts with super mario world and ends with an admin calc.exe
<cr1901_modern>
Nobody would ever use ZSNES for TASing :P.
<cr1901_modern>
I don't think there's a way to escape bsnes/higan's "sandbox". Tho a cool "party trick" is to write a ROM that can tell whether it's being run on a real console or higan.
<rqou>
idk about snes emulators, but years ago detecting gba emulators was pretty trivial
<rqou>
apparently the real hw has a bug where overwriting an instruction that is already in the cpu pipeline won't cause the pipeline to flush
<rqou>
so the real hw will continue running the old opcode
<rqou>
no emulators emulated this
<rqou>
note that i never tested this, just heard that it worked
<cr1901_modern>
That's a hardware bug :P? (I would've thought that's by design. You're kinda screwed if the inst is in the pipeline)
<rqou>
afaik intel will flush the pipeline if it detects that
<whitequark>
well that's intel
<whitequark>
almost any other arch doesn't
<whitequark>
you have to explicitly invoke `imb` on ARM
<rqou>
ok, s/bug/quirk then
<cr1901_modern>
Something seems impractical about sniffing the bus for a memory write and then comparing against every instruction and its associated PC already in the pipeline.
<cr1901_modern>
I'm guessing that's NOT how it's actually done tho
<whitequark>
no, not a quirk
<whitequark>
this is normal behavior
<whitequark>
cr1901_modern: I think it's done through cache coherency
<whitequark>
icache is sniffing dcache transactions
<rqou>
i mean, i understand why it happens, but it kinda breaks the very simplified model of "cpu executes instructions one after another"
<whitequark>
rqou: sure. but it's wrong. just like the simplified memory model of "reads and writes happen in the order they're present in the program" is wrong
<cr1901_modern>
Ahhh, that would make sense, and then cache controller prob sends a "oh God everything's f***ed" signal back to CPU to tell it to stop the pipeline.
<cr1901_modern>
But we'll never know w/ Intel :P
<whitequark>
sorta. it just acts as a barrier
<rqou>
in that case would you also call architecturally-visible delay slots normal behavior rather than a quirk?
azonenberg_work has quit [Ping timeout: 245 seconds]
<whitequark>
it's not a quirk per se, just shortsightedness
<whitequark>
if your design is even a little complex you don't gain any benefit from having delay slots
<whitequark>
and of course there's a drawback
<cr1901_modern>
I mean even MIPS has Interlocked Pipeline Stages now
<rqou>
you didn't like the ps1's bugs? :P
<cr1901_modern>
I've never looked at the PS1 (or N64) in much detail.
<rqou>
n64 iirc is much saner
<rqou>
ps1 has load delays
<rqou>
so after a read from memory the very next opcode uses the old register value
<cr1901_modern>
Virtual Boy on the other hand is essentially a "6 stage MIPS clone with interlocks and bit-granularity memcpy"
<rqou>
it also has amazing gimmicks like putting a branch in a branch delay slot
<cr1901_modern>
Ummm...
maaku has quit [Quit: No Ping reply in 180 seconds.]
<rqou>
it'll execute one opcode from the target of the first branch
<rqou>
then start executing from the target of the second
<rqou>
i don't know what happens if that one special opcode is also a branch
<cr1901_modern>
My brain just melted a bit
<rqou>
the ps1 also had a geometry transformation engine that was hooked up as a coprocessor
<rqou>
putting one of its opcodes in a delay slot was also exciting
maaku has joined ##openfpga
<whitequark>
gross
<cr1901_modern>
Jet Moto 3 is an interesting PS1 game. The developer (just one) had full control and so replaced Sony's coprocessor microcode with his own to create cool weather effects
<rqou>
so the sony counterpart to rare? :P
<cr1901_modern>
Might very well be. But it was only one game, and I haven't heard much from him after that one game (correction: he was lead dev. There were multiple devs)
<rqou>
the jwz one doesn't really count does it? it's not very complete i thought?
<rqou>
but yeah, i'm aware of that particular one
<rqou>
anyways, byuu made bsnes/higan, supposedly the most accurate snes emulator
<rqou>
and somehow managed to attract a huge amount of drama along the way
<whitequark>
ah
<cr1901_modern>
Some of that is byuu's fault (his NIH syndrome, reinvent the wheel tendencies), others are just downright assholes to him. He is very polarizing.
<cr1901_modern>
emulation is very srs bsns. *rolls eyes*
<rqou>
at least it's not neo geo :P
<rqou>
or mame for that matter
<cr1901_modern>
MAME is filed under emulation. The reason I'm interested in decap at all is thanks to MAME and bsnes/higan
<rqou>
how does mame manage to get so much drama though?
<cr1901_modern>
It's an interesting coincidence that azonenberg, whitequark, et al are part of the same community as well.
<cr1901_modern>
Lord_Nightmare: A penny for your thoughts :)?
<cr1901_modern>
balrog: ^^
<rqou>
re "same community": only very very few people are insane enough to set up decap labs in the first place
<whitequark>
insane enough??
<Lord_Nightmare>
cr1901_modern: which version of the oman archive do you have? iirc theres two versions
<whitequark>
I literally did it because I was really bored
<whitequark>
what's hard about it
<Lord_Nightmare>
one is much smaller than the other and is missing all the sdk stuff
<Lord_Nightmare>
i have the small one
<Lord_Nightmare>
the larger one contains a bunch of n64 sdks and libraries
<cr1901_modern>
Well, it's more like: azonenberg and Dr. Decap/CT worked for the same company lol, and MAME ppl know Dr. Decap
<cr1901_modern>
and everyone else knew azonenberg :P
<Lord_Nightmare>
i think dr decap worked there and left before azonenberg was hired
<cr1901_modern>
Lord_Nightmare: Probably the smaller one. I was asking you why is MAME filled with drama tho
<Lord_Nightmare>
i don't think there was any overlap
<Lord_Nightmare>
drama has been part of the emulation scene since its earliest days
<cr1901_modern>
B/c I certainly have an answer. But I wanted you to give your answer first
<Lord_Nightmare>
MAME is no exception
<cr1901_modern>
My thoughts is that emu devs want to reach a broader audience to gain respect for a hobby that by and large is incredibly niche, and will step over each other for a moment of glory.
<cr1901_modern>
"hobby" being "preservation"
<cr1901_modern>
Preserving a piece of hardware exactly is important and gives me a lot of satisfaction. Other than being a curiosity for most other people, it's utility is limited :/.
<rqou>
who else even has decap labs? whitequark, nevstiki, ???
<rqou>
i don't do emu dev
<rqou>
Lord_Nightmare: want to send me your oman archive? just for personal interest
<rqou>
does your copy have the partial verilog?
<cr1901_modern>
A cycle accurate PPU is not gonna cure cancer
<whitequark>
I mean, a beautiful painting also won't
<cr1901_modern>
Hmmm... good point. Maybe I'm still dealing with my own insecurities about how (relatively) niche are the things that fascinate me.
<cr1901_modern>
Lord_Nightmare: If you dl this link, you can tell me which version you have. I asked someone in #higan for it months ago. And I'm prob gonna delete the link after this.
<cr1901_modern>
AFAIK, "Oman" actually did go to jail a bit for leaking these
<whitequark>
wow, 1997
<Lord_Nightmare>
suspect same version as you
<rqou>
i've dl'ed it
<whitequark>
"Use of a copyright notice is precautionary only" lol
<rqou>
btw what exactly is the legal status of gbatek? all i know is that somehow leaked sdks are involved
<cr1901_modern>
whitequark: Please use these documents responsibly. By no means should you make a torrent or otherwise share with your "IP is harmful" friends who can find a good host for these definitely-not-secret docs :)
<whitequark>
lol
<whitequark>
the fuck is a &&& operator in verilog
<cr1901_modern>
which file :o?
<rqou>
wtf
<rqou>
also, which parts of the verilog are missing?
<rqou>
i don't see anything obviously missing
<whitequark>
cdbuf.v
<whitequark>
yeah
<whitequark>
but you could probably spend months just figuring out how this worked
<rqou>
even the pad ring is present
<whitequark>
yup
<cr1901_modern>
pad ring?
<rqou>
hw/chip/lib/verilog/pads
<whitequark>
and various READMEs
<rqou>
essentially some verilog that is a placeholder for "actual analog transistor stuff needed to make I/O pins work"
<cr1901_modern>
Ahhh, somehow don't think that matters if someone just wanted an FPGA version (b/c that would be akin to Hard IP?)
<cr1901_modern>
I've briefly looked into compiling the code, but it wants an old Verilog toolchain from $LONG_GONE_COMPILER_PROVIDER
<rqou>
it doesn't matter if you want an FPGA version
<rqou>
hmm i wonder if my father has some floppies :P
<whitequark>
'm pretty sure the point of Verilog is that you dont' need the old toolchain
<rqou>
the bugs were different :P
<whitequark>
lol
<whitequark>
even has test vectors
<rqou>
thinking about it my father might have been using AHDL around this time (1997)
<whitequark>
has full schematics too
<cr1901_modern>
there were some verilog files called cells. I thought they were vendor-specific placeholders. So I'm guessing say, yosys could compile most of the Verilog but Idk if it would be sufficient to get a working simulation as-is.
<whitequark>
yes absolutely
<whitequark>
this has the entire design package
<whitequark>
you couldn't *produce masks* from this, although you are not very far from doing so
<whitequark>
not that there are any fabs left with that process, I think :D
<rqou>
ultra64.bom is neat
<rqou>
" 1 | 1 | CAP NPO SMD 0.001UF 50V 5% 0805"
<rqou>
etc.
<whitequark>
cr1901_modern: what's the name of that verilog toolchain?
<cr1901_modern>
It's been a while since I looked at the archive. It also provides the cells as they should be laid out on the die itself?
<whitequark>
so far I only see behavioral info
<whitequark>
like the complete simulation package
<whitequark>
and it looks like the simulator itself is also fully present
<rqou>
there's definitely no GDS
<cr1901_modern>
whitequark: I don't remember offhand. I'll see if I can find it.
<cr1901_modern>
GDS?
<rqou>
i don't know too much about asic flows to know what other file formats are involved
<rqou>
GSD is basically a digital representation of the chip physical layout
<whitequark>
theres' an incredible amount of docs
<cr1901_modern>
I'd love to see this chip work. I'm too paranoid to do it myself.
<rqou>
yeah, i see nothing missing on first glance
<whitequark>
ah yes I see what's "missing"
<whitequark>
the Irix C/C++ toolchain
<rqou>
that's not really necessary
<whitequark>
doc/readme.6.2
<whitequark>
exactly
<rqou>
i get the feeling the emu devs who had this back in the 90s had no idea what they were looking at
<whitequark>
lol possible
<cr1901_modern>
It's called a "dirty little secret" for a reason. No one in N64 dev community wants to admit that this exists
<cr1901_modern>
It's like how ppl would keep leaked SNES technical manuals to themselves in the 90's
<cr1901_modern>
whitequark: The toolchain I was thinking of is called Chronologic. But AFAICT, that's only the simulator portion
<whitequark>
I'm pretty sure the entire simulator is included
<rqou>
heh, someone on the internet claimed that the NES didn't even have any technical manuals
<whitequark>
they appear to have modified it to suit their peripherals
<whitequark>
LOL
<rqou>
maybe some notes in japanese or something
<whitequark>
doc/rsp/ps/rspprogguide.ps
<whitequark>
331-page manual
<whitequark>
this is astoundingly well documented
<cr1901_modern>
I'd totally believe someone went to jail for leaking this
<rqou>
wow evince can just open that file. standards ftw!
<whitequark>
pity most of the docs are in FrameMaker
<whitequark>
too lazy to figure out how to convert from that
<cr1901_modern>
Some of the software definitely runs on SGI systems, others old versions of Windows? Haven't checked the header
<whitequark>
rqou: wow, that even has the cell timing info
<whitequark>
*.ss
<rqou>
oh wow
<cr1901_modern>
Not gonna lie- I haven't even read the docs. I've just been sitting on these since March, since I sent it to a MIPS/SGI Enthusiast to be put into a torrent.
<cr1901_modern>
Should prob ask her how that's coming along
<rqou>
also lol framemaker
<rqou>
when i was interning at broadcom, they "used framemaker" for their docs
<cr1901_modern>
Hrm... maybe I could get away with creating a Makefile/file hierarchy to compile the code into a simulator and just have people who "want to run it" provide their own Oman archive.
<cr1901_modern>
That way I couldn't get hit for distributing illegal content
<cr1901_modern>
"It's just a bunch of makefiles!!!11"
<rqou>
just ask whitequark to help you host it in RU :P
<whitequark>
I wouldn't touch it at all if I was in the US
<whitequark>
or google "abuse-resistant hosting"
<whitequark>
which is a very hilarious figure of speech
<cr1901_modern>
I have no intention of distributing it. It was a bad idea to even link to it in this chat (consider it's logged) in retrospect. But risk of me getting in trouble sharing it among friends is low.
<cr1901_modern>
However, if I or someone else interested, ever got this running, I'd like them to have to opportunity to experience it as well, if only just to study.
<cr1901_modern>
I'd like others*
<cr1901_modern>
Lord_Nightmare: Does CEN64 or the other cycle-accurate N64 projects use the archive at all, or do they steer away for legal reasons?
<Lord_Nightmare>
there have been fixes to the rdp/rsp emulation based on stuff in the archive but nothing directly copied afaik
<cr1901_modern>
Did you dl my link, check against your copy?
<cr1901_modern>
(And additionally, Idk if N64 CPU has on die peripherals like Nintendo loves to do, but I don't think the CPU is included in my copy?)
<whitequark>
I think that's just the sources for the ASIC?
<whitequark>
it's using VR4300 apparently
<whitequark>
right, the dump only has sources for Reality
<cr1901_modern>
Up to at least Virtual Boy, Nintendo would put DMA, Timers, and other goodies directly on the CPU die. W/ N64, I believe at least the DMA was moved to Reality coprocessors. I'm just wondering if a stock MIPS (VR4300) with the appropriate bus signals is enough.
<cr1901_modern>
N64 also uses RAMBUS. I'm not sure which chip has the controller for that
<rqou>
it's in the dump
<cr1901_modern>
All in all, even if you're not an emu fan, this seems like a fun system to study :)
<qu1j0t3>
I mean emus are _all right_ but a bit large of a pet for an apartment.
<cr1901_modern>
Those kind of emus creep me out a bit
<whitequark>
cr1901_modern: the wiki says the CPU has to go through RCP for all access
<cr1901_modern>
Oh! That's cool! Nintendo did something analogous with SNES coprocessors... all CPU accesses to memory (but not I/O) went through the coprocessor, which decided what the CPU could/could not do.
<whitequark>
you basically need something to arbiter the RAM
<whitequark>
could as well be the GPU
<rqou>
yeah, and arbiter/cycle stealing from the CPU is very common
<cr1901_modern>
Maybe it could even be transparent DMA as long as the CPU sticks to its caches
<rqou>
hmm the verilog is modern enough to have // synopsys translate_off
<cr1901_modern>
Something mildly curious: PCB traces on N64 curve smoothly. I guess that's partially b/c two layer board
<whitequark>
that's probably just a really old thing
<rqou>
btw what's up with the 2009 datestamps?
<rqou>
did someone reorganize and repack the archive at that time?
<cr1901_modern>
Most likely if I had to guess
<whitequark>
The translate off stuff is all pain caused by Synopsys being too lazy back in 1990 to add a
<whitequark>
hundred lines of code to implement the Verilog preprocessor.
<rqou>
we're totally not talking about fpgas right now
<pie_>
thats fine
<qu1j0t3>
rqou: I wrote a Photoshop plugin for that
<qu1j0t3>
rqou: to try and ensure longevity
<qu1j0t3>
rqou: (it's GPL)
<rqou>
we're actually discussing an illegal data dump right now
<whitequark>
lol
<pie_>
rqou, im actually trying to prepare my lab notebooks for tomorrow :P
<qu1j0t3>
pie_: DOn't accidentally log this chat in your books
<pie_>
distractions abound
<pie_>
qu1j0t3, in my books?
<qu1j0t3>
pie_: notes
<pie_>
OH, my comprehension just exploded.
<pie_>
:P
<pie_>
whelp...back to work...
<pie_>
on a sightly related note, anyone here familiar with ltspice?
<whitequark>
yeah
<rqou>
it works... barely
<rqou>
better than hspice
<whitequark>
it's great imo
<rqou>
ok, fine
<rqou>
it's about as shit as all EDA tools
<whitequark>
slightly less shit
<pie_>
i guess ill look around the market sometime, i just happened to pick this one up
<whitequark>
I haven't found a FOSS SPICE tool that I will tolerate at all
<pie_>
whitequark, mind if i ask for help if i get stuck?
<whitequark>
and that's a slightly worse situation than usual
<whitequark>
sure
<rqou>
i mean, aren't they all clones of the original UCB code?
<whitequark>
sorta?
<whitequark>
some of them have lots of modifications
<rqou>
btw UCB installed a commemorative plaque a few years ago for SPICE
<pie_>
neat
<rqou>
it's in the entrance to the EE building
<pie_>
whitequark, just for fun; http://imgur.com/a/QWZ4m the lab was measuring the voltage in a RLC circuit as a function of capacitance...or something like that. i did the measurement, trying to figure out what the lab is actually aboot right now 0.o
<pie_>
well, that was the lab, this is just me trying to replicate it in simulation xD i think i got it, thats what the curves look like, i just dont know the specs of the RLC we used so numbers dont match
<qu1j0t3>
pie_: I think you're rambling.
<pie_>
qu1j0t3, yeah i am...damn lack of sleep
<qu1j0t3>
I can tell :)
<cr1901_modern>
I don't find SPICE all that useful in my experience. I mean, it's great for confirming results, but I'm likely to just do pen and paper or use a symbolic math toolbox.
<cr1901_modern>
It should've been highlighted, but: "i get the feeling the emu devs who had this back in the 90s had no idea what they were looking at"
<cr1901_modern>
I have a feeling that's at least partially true today. :P
<Lord_Nightmare>
yeah, probably
<Lord_Nightmare>
the problem is the code is not complete
<Lord_Nightmare>
they have no code for the rambus stuff except stub libraries which would be replaced at the fab by rambus ip blocks
<whitequark>
oh
<Lord_Nightmare>
so you can't just compile an rsp or rdp asic from this
<Lord_Nightmare>
also missing the mips cpu core
<Lord_Nightmare>
for the rsp
<cr1901_modern>
If it's a completely generic MIPS core, I don't see that being a problem, tbh
<Lord_Nightmare>
its mostly generic; it implements the VICE co processor opcodes from the SGI O2
<cr1901_modern>
I mean, *I'm* not going to make a MIPS core to connect to it, but... ;)
<Lord_Nightmare>
including a few which nintendo themselves didn't document
<Lord_Nightmare>
DCT related stuff
<Lord_Nightmare>
so MPEG-LA wouldn't sue them
<cr1901_modern>
lmao
<Lord_Nightmare>
but the opcodes are there and do work
<whitequark>
lol
<Lord_Nightmare>
iirc someone was trying to do some homebrew which used them for FMV
<Lord_Nightmare>
not sure if it got anywhere
<cr1901_modern>
B/c we totally need Time Gal for the N64
<cr1901_modern>
as for RAMBUS, I guess RAMBUS never released a datasheet to the public documenting their PHY interface?
<cr1901_modern>
or "whatever connections/protocol are required to successfully talk to RDRAM"
* azonenberg
gets home from work
<cr1901_modern>
In any case, N64 is that weird "grey area" where some ppl think cycle-accurate emulation is possible/feasible on commodity hardware, and others don't. I'm cautiously optimistic, but I would be curious about an FPGA impl if it can't be done.
<cr1901_modern>
azonenberg: You may want to scroll up and find some "definitely not at all illegally obtained" technical docs on the N64 Reality Coprocessor
<azonenberg>
Lol
<azonenberg>
I'd rather not, i dont really have any interest in vintage games
<cr1901_modern>
Well, hey, N64 is kinda too new for me to be interested ;). I just find the verilog code interesting to study.
<azonenberg>
Lol new?
<azonenberg>
my interest is mostly 21st century programmable logic
<cr1901_modern>
That's the joke. I'm interested in old systems, you like systems ppl actually use. N64 occupies that gray area where it's too new for me/too old for you.
<cr1901_modern>
I hope that university RISC-V ASIC project succeeds in producing more chips though. That would really be my "gateway" (back) into modern fabrication. I didn't really pay attention that much during the class I took lmao (T_T).
kuldeep has quit [Ping timeout: 248 seconds]
kuldeep has joined ##openfpga
kuldeep has quit [Max SendQ exceeded]
kuldeep has joined ##openfpga
<azonenberg>
o/ pie_
<azonenberg>
welcome to the community
kuldeep has quit [Max SendQ exceeded]
kuldeep has joined ##openfpga
<whitequark>
ｗｅｌｃｏｍｅｔｏｔｈｅｃｏｍｍｕｎｉｔｙ
<azonenberg>
whitequark: ?
<azonenberg>
what charset is that
<azonenberg>
this vm must not have that font installed
<whitequark>
azonenberg: dang
<whitequark>
that's "welcome to the community" using the fullwidth english
<azonenberg>
lol
DocScrutinizer05 has quit [Disconnected by services]
* cr1901_modern
can't imagine why you're on a hiatus. Twitter is an exciting place filled with rational discourse where emotions nev- ahh, fuck it. I don't blame you.
<whitequark>
holy shit there are *fifteen pages* there now
<pie_>
anime really like their powerlines
<cr1901_modern>
I miss when anime was done with cels. It just looked prettier.
<azonenberg>
lol
kuldeep has joined ##openfpga
<rqou>
(un?)fortunately i don't watch enough anime to recognize any of those
<whitequark>
rqou: lol the joke is that i don't watch anime much either
<azonenberg>
rqou: lol
<whitequark>
especially as of late
<whitequark>
been months since i watched anything at all. the tumblr is mostly refreshed by other people
<azonenberg>
rqou: $WIFE is very much not closet :p
<cr1901_modern>
Last anime I watched was... Macross Plus?
<cr1901_modern>
Oh no, it was Galaxy Express 999
<azonenberg>
there's a hand painted shiny mudkip, life sized, leaning up against the wall here
<whitequark>
cr1901_modern: i don't. it was extremely labor intensive, and looked badly on all but the highest budget titles anyway
<azonenberg>
just within arms length
<rqou>
at least you can't as bluntly call me a weeb because i'm chinese :P
<whitequark>
it's still labor intensive mind you, but at least the result is passable even when shaft is behind schedule
<whitequark>
though, i feel like the ambitions of producers basically expand to fill all available tech advances anyway
<whitequark>
eroom's law for anime
<cr1901_modern>
whitequark: Of course I meant the highest budget titles :P. And my stock response to "result is passable" is that "anime has saturated the market"
<pie_>
rqou, hehe
<cr1901_modern>
Aforementioned Galaxy Express 999 movie, or DYRL
<whitequark>
you would never see something like "Attack on Titan", graphics-wise, hand-drawn
<whitequark>
it *has* to be done in 3D
<whitequark>
as for saturated market, well, yeah, anime is all garbage anyway. I'm with Miyazaki
<whitequark>
not that this prevents me from stuffing myself full of garbage mind you
<cr1901_modern>
I'm not against digitally drawn anime at all, btw :).
<cr1901_modern>
I have my guilty pleasure titles as well, like School Days
<whitequark>
>School Days
<whitequark>
is that why you're... like that?
<cr1901_modern>
like what? :)... completely screwed up? Probably...
<cr1901_modern>
Or more likely, I go into bad anime knowing it's bad and enjoying it anyway
<whitequark>
I think I gave up on about 8th minute of that and managed to completely erase all traces of it from my mind, before this moment
<cr1901_modern>
I apologize for reminding you it exists :(
<whitequark>
I don't know if it's bad, I just know it's far more disturbing than even Elfen Lied
<whitequark>
which is a remarkable achievement in and of itself, BUT
<cr1901_modern>
Have managed to never see Elfen Lied
kuldeep has quit [Max SendQ exceeded]
<whitequark>
watch it. you will never forget the blood
* cr1901_modern
adds it to the list
kuldeep has joined ##openfpga
<cr1901_modern>
Most gory anime I remember watching was Freezing (and that gets offset with the... fanservice).
<whitequark>
I mean, after School Days, I think there's only [REDACTED] that is gonna disturb you and I'm not even going to admit I'm aware of its exustence
<whitequark>
blame @alt_kia for telling me about that... thing
<whitequark>
no, I haven't watched [REDACTED]. the first paragraph of the summary was more than enough
* cr1901_modern
is trying to think what it is...
<whitequark>
I'm going to answer "I can neither confirm nor deny this" to any guess you have
<rqou>
great, ##openfpga is now #anime, #anime has always been basically #linux, where does FPGA talk go? :P
<cr1901_modern>
Please understand, by no means do I think "School Days" is good XD. Bad anime is just a guilty pleasure. And there's enough to last a lifetime.
<whitequark>
I mean, there is bad, and there is trashy
<whitequark>
rqou: oh dang, I just recalled that 4nsGH... misses EN subs
digshadow has joined ##openfpga
<whitequark>
the one above has proper EN subs by the author\
<whitequark>
it's a pity. 4nsGH... is one of their best ones
<rqou>
are they using a text to speech though?
<whitequark>
yes
<cr1901_modern>
I have seen exactly one moderately good shot so far
<cr1901_modern>
and that's only b/c of excessive use of sun flare effect
<rqou>
i hate lens flare effects
<rqou>
oot3ds has a stereoscopic 3d lens flare
m_w has joined ##openfpga
<rqou>
imho very excessive and silly
<cr1901_modern>
I LOVE how his cigarette floats in midair as he talks
<rqou>
anyways, are these animations done in flash?
<whitequark>
yup
<cr1901_modern>
whitequark: Re: my "anime has saturated" complaint, that is mainly based off my bitterness that Sailor Moon and Dragon Ball reboots weren't treated w/ respect when they first aired. Which is apparently a side effect of animators not being paid the money the deserve.
<cr1901_modern>
also no English subs on that video, but I'm 5 minutes in and entertained, so I guess it's a win XD?
<whitequark>
you're going to miss like 80% of meaning
<rqou>
why is it that automated RU->EN translation seems to always leave random untranslated nouns?
<whitequark>
rqou: there's a shit ton of nouns and they're all weird
<cr1901_modern>
Are... are the robbers wearing books with eyeholes as masks?!
<whitequark>
cr1901_modern: yes. the book says "THE LAW"
<whitequark>
they are literally hiding behind the law
<cr1901_modern>
oh sweet Jesus XD T_T
<cr1901_modern>
"a lethal dose of unemployment... and he became a hobo" Oh God, if this isn't supposed to be funny, I'm sorry
<cr1901_modern>
Is Russian a language where the adjective comes after the noun in a sentence?
<whitequark>
no?
<rqou>
idk, but russian has declension, and a totally insane amount too
<cr1901_modern>
https://youtu.be/K3aTpytFqFI?t=5m46s Apparently this is "fucking PARKING", and I'm guessing "PARKING" is the big text, and fucking is the small one?
<whitequark>
oh
<whitequark>
that's just untranslateable
<cr1901_modern>
Ahhh
<whitequark>
english simply doesn't have the necessary inflections
<whitequark>
in fact most of russian obscenity is untranslateable for this reason
<rqou>
wait, the big text does say parking?
<whitequark>
yes
<rqou>
ah so only the small text that isn't just an english word written in cyrillic is the one that is untranslatable
<cr1901_modern>
It probably modifies parking in a manner to express irritation :P?
<whitequark>
indeed
<cr1901_modern>
Insulating Tape-Man... help T_T! What rabbit hole have I peered down
amclain has quit [Quit: Leaving]
<whitequark>
it's as if someone looked at "beavis and butt-head" and thought "far too civil"
<rqou>
so i just looked up russian declension on wikipedia, and i see "Nominal declension is subject to six cases – nominative, genitive, dative, accusative, instrumental, and prepositional – in two numbers (singular and plural), and absolutely obeying grammatical gender (masculine, feminine, and neuter). Up to ten additional cases are identified in linguistics textbooks,[1][2][3] although all of...
<rqou>
...them are either incomplete (do not apply to all nouns) or degenerate (appear identical to one of the six simple cases)."
<rqou>
and you said that cantonese is weird :P
<cr1901_modern>
Gender: neuter.
<whitequark>
russian is weird as hell
<whitequark>
i don't like it fwiw
<whitequark>
it's very good for purple prose and obscenity, and very bad for everything else
<whitequark>
when you're talking about tech you could as well just switch to english entirely, not much will change
<rqou>
but you have to change the alphabet to cyrillic just because :P
<whitequark>
eh
<whitequark>
there's "translit", which is russian written with latin letters
<whitequark>
caused entirely by the fact that computers in 90s and early 2000s haven't supported encodings for shit
<whitequark>
also you get 2x cheaper SMS messages
<whitequark>
hilariously, tech terms are rather commonly written in translit *phonetically*
<whitequark>
then some people will take en->ru->translit and convert it back to ru
<whitequark>
the result is hideous
<rqou>
wtf
<rqou>
at least chinese tends to be reasonably consistent how they use tech terms
<whitequark>
I mean the last step isn't very common
<whitequark>
but writing tech terms phonetically with latin letters? sure, most russians don't know how to spell them properly in english, because english is so non-phonetic
kuldeep has quit [Read error: Connection reset by peer]
<whitequark>
this actually caused me serious annoyance when learning english
<whitequark>
not the fact that it's non-phonetic *per se* but rather that i first knew some words in translit
<whitequark>
that said i learned written english, so i never *tried* to write it phonetically. rather i'm trying to pronounce it as it's written, with hilarious/shameful results
<whitequark>
I bet I could learn enough chinese to be dangerous and never figure out how to actually pronounce it
<rqou>
that's totally possible
<whitequark>
especially if I do something like browsing with a pinyin transform and an input method
<rqou>
there are actually stroke/structure-based input methods
<whitequark>
right, I know, but why bother learning ideograms if I can... not?
kuldeep has joined ##openfpga
<whitequark>
I mean it might be interesting on its own regard but for communciation it seems excessive
<rqou>
hmm chinese probably has too many homophones/near-homophones to rely on just pinyin
<whitequark>
I mean people do speak it, right
<whitequark>
that implies it could be grasped from context :p
<rqou>
hmm this probably only works for modern chinese
<whitequark>
that works for me :p
kuldeep has quit [Read error: Connection reset by peer]
digshadow has quit [Quit: Leaving.]
<rqou>
hmm i really should work on learning a foreign language "for real" at some point
<whitequark>
if you teach me cantonese i suppose i could teach you russian
<rqou>
the problem is that despite cantonese being my first language my cantonese skill is not that great
<rqou>
and i essentially "cheated" learning mandarin
<whitequark>
not really a problem imo; I'm not exactly aiming to become the JK Rowling of PRC
<rqou>
because my parents forced me to have enough exposure to mandarin to pick up some of it at the tail end of the early childhood language acquisition phase
<whitequark>
anything that's more intelligible than "please speak into google translate on my phone" is enough
<rqou>
i also have no idea how to actually teach cantonese
<whitequark>
... which reminds me that I should get one of those stroke-based IMs onto my phone
<rqou>
i never experienced any chinese-language instruction at all
<whitequark>
mhm
<rqou>
i have taken mandarin classes that weren't full immersion
<rqou>
it turns out that most basic mandarin classes also can't help me too much because they don't emphasize the parts i'm bad at
dingbat has joined ##openfpga
kuldeep has joined ##openfpga
<rqou>
anyways, interestingly enough my father actually studied russian a very long time ago
<rqou>
he now remembers none of it at all
<rqou>
:P
<whitequark>
common
<rqou>
he mentioned that he never understood what the deal was with the "hard sign" and "soft sign" :P
<whitequark>
oh god
<whitequark>
so like you have "сесть" and "cъесть". the 1st is read like "sest" and means "to sit", the 2nd is like "sjest" and means "to eat"
<whitequark>
yes, that's one letter difference and the letter itself is not pronunciable
<whitequark>
ъ means that the next letter should be in its "standalone" form
<whitequark>
it's basically like a zwnj for phonetics. breaks a "ligature", if this makes sense
<whitequark>
that was the hard sign. now the soft sign
<rqou>
so you have a palatalized consonant and then /j/ as well?
<whitequark>
yeah. the consonant doesn't actually change much
<whitequark>
the /j/ is the important part
<rqou>
so ipa for russian gets decorated with ʲ everywhere even though that doesn't do much?
<whitequark>
I don't know ipa
<rqou>
oh, i thought you did
<whitequark>
I have a lot of trouble with phonetics in general
<rqou>
ʲ indicates that the previous sound is palatalized
<whitequark>
because I use written language so much and spoken language so little
<whitequark>
oh
<whitequark>
yeah I suppose
digshadow has joined ##openfpga
digshadow has left ##openfpga [##openfpga]
<rqou>
i know ipa in theory, but i have very little practice with actually speaking foreign sounds
<rqou>
berkeley has a really great and accessible intro linguistics course
<whitequark>
as for the soft sign, most of the time it's there just to indicate phonetics in a word that's already unambiguous
<whitequark>
but there is one major exception, тся/ться
<whitequark>
i bet you 80% of russians don't get that one correctly
<whitequark>
it actually is also unambiguous
<whitequark>
so ь is basically entirely pointless except for making the writing system match the phonetics
<whitequark>
of course it's not actually *fully* phonetic, that would be too easy. loads of exceptions with silent letters and shit
<rqou>
not as insane as english?
<whitequark>
not quite as bad
* rvense
went through all 90 lessons of pimsleur's russian a few years ago
<rvense>
it's really interesting to 'study' a language with no writing
digshadow has joined ##openfpga
<rqou>
i mean, i speak cantonese/mandarin but have basically no reading/writing ability
<rqou>
ideographs are hard
<rvense>
mhm, but i think if you took a course somewhere they'd still teach you using transliteration
<rqou>
oh yeah, i rely on pinyin a lot
<rqou>
er... for mandarin
<rqou>
for cantonese i just shrug
<rqou>
i don't know cantonese romanization schemes
digshadow1 has joined ##openfpga
digshadow1 has quit [Read error: Connection reset by peer]
digshadow1 has joined ##openfpga
<rqou>
this also leads to fun situations of "i have this word that I know how to say in mandarin, i can look up how to write it" but "i have this word i know how to say in cantonese, i can't look up how to write it"
<rqou>
this then gets enhanced to "i have this word i know how to say in cantonese, try to guess what the pronunciation would be in mandarin and then look it up"
<rqou>
if it's colloquial cantonese you just give up :P
digshadow has quit [Ping timeout: 265 seconds]
<azonenberg>
ideographs...
* azonenberg
shudders
<azonenberg>
I didnt have too much trouble with the little bit of German I studied a ways back
<azonenberg>
since that was the roman charset
<azonenberg>
I know the Greek charset from math, and a bit of Cyrillic (but don't know the phonetic pronunciations for all of them yet)
<rqou>
lol similar here
<azonenberg>
But at least those are still a std::map<character, phoneme> with some special casing
<azonenberg>
with size() as being reasonably small
<azonenberg>
:p
<azonenberg>
but chinese/japanese? nooooo thanks
<azonenberg>
i cant rule out being able to speak them one day, but i dont think i could ever write them
<rqou>
heh, when my housemate (white guy who speaks some japanese, a weeb :P) and i were playing with google translate EN->JP, half the words just came up in katakana
<rqou>
even though there were usually other native japanese words that also had the same meaning
<azonenberg>
$WIFE openly refers to herself as a weeb, but doesnt speak much/any jpn
<azonenberg>
mostly just anime fan
<azonenberg>
Although some of those little snack kits are adorable lol
<rqou>
lol i love japanese snacks
<azonenberg>
i just ordered a bunch of her on amazon
<azonenberg>
for*
<rqou>
this housemate also speaks some mandarin
<rqou>
so i've joked with my housemates that we should all speak mandarin to each other for practice
<rqou>
nobody is willing to invest the effort :P
<rqou>
(we have 3 ABCs (american-born chinese) and the white guy)
<azonenberg>
I see
<rqou>
the most frustrating part of our collective mandarin ability is our lack of "more advanced" nouns/verbs
<rqou>
you would think that that's what benefits most from practice
<rqou>
the problem is that it's hard to hit the activation energy so that this isn't super frustrating
<pointfree>
code needs to be cleaned up and (re)factored but it works.
<pointfree>
I can also do DSI and PLD PI tiles but that's not in there.
<pointfree>
formulas for hv tiles are next!
<pointfree>
HS tiles are also clear to me, they work just like VS tiles.
<pointfree>
HC tiles connect to PI tiles
<pointfree>
although, I still need to look into formulas for how HC tiles connect on the other end to HV tiles...
<pointfree>
Also, the code I posted should be using knowledge whether an upper or lower block is the target of configuration and consequently use & mirror the corresponding nyble accordingly.
<pointfree>
The code posted doesn't do that because I would need to integrate older gelFORTH code for PLD synthesis. The the udb pair number as given by the B*_P*_ROUTE_* registers are naturally not enough information by themselves.
<pointfree>
I found some papers and pdf slides on parallel logic minimization using a generalization of karnaugh maps. I hope to complete that and arbitrary routing fabric support before my gelFORTH/PSoC talk on Forth Day.
<azonenberg>
Awesome
<azonenberg>
have you considered just using yosys or abc for that though?
<azonenberg>
the minimization i mean
<pointfree>
I do fully intend to help with adding yosys support for the PSoC. gelFORTH is another project to do full dynamic partial live reconfiguration from a Forth-based RTOS residing on the PSoC's ARM core.
<azonenberg>
i meant more like, reusing code from them for logic minimization
<azonenberg>
thats a solved problem
<azonenberg>
dont waste your time on it
<azonenberg>
focus on the unsolved problem, the RE
<azonenberg>
doesnt matter where the input netlist comes from - verilog, forth, or rubylith + machine vision for all i care :p
<pointfree>
The purpose is for interactive hardware design, and by running the Forth code on the UDB array I get some fine-grained parallelism for existing high-level Forth code.
<azonenberg>
innnteresting
<pointfree>
I'm thinking the parallel synth tool could run in parallel from the UDB array itself to make use of its parallelism.
<azonenberg>
so you are trying to do something along the lines of opencl for psoc?
<pointfree>
I don't think anyone else intends to work on this, so I'll spill the beans and say I indend to make something like an (open source/open hardware) PSoC based Bus Pirate with the possibility of writing new "hardware" modules for it.
<azonenberg>
ooh nice
<azonenberg>
I had a tangentially related idea, but very different
<azonenberg>
I wanted something based on a small fpga, probably a spartan-7 when they come out
<azonenberg>
I'd likely do initial prototyping on a small artix then switch to a spartan to cut costs if they're cheaper
<azonenberg>
Ethernet interface so several users can share it
<azonenberg>
I hate moving usb cables back and forth between laptops
<azonenberg>
easier to bridge to the lan
massi has joined ##openfpga
<pointfree>
interesting!
digshadow has joined ##openfpga
<azonenberg>
then have a crossbar fabric and a bunch of digital IP cores
<azonenberg>
like i2c, spi, uart, gpio, etc
<azonenberg>
and an integrated LA
<azonenberg>
so you can make any of the I/Os on the expansion header usable as any of those protocols as you see fit
<azonenberg>
Pins would be ESD protected and buffered, tolerant to a fairly high voltage (i'd aim for 12V tolerant for brief periods and 5 sustained)
digshadow1 has quit [Ping timeout: 268 seconds]
<azonenberg>
also provide say 2 fully variable output voltages suitable for driving external circuitry
<azonenberg>
Have support software for common tasks like dumping i2c eeproms, writing spi flash
<azonenberg>
bonus points if there's an interactive view-and-patch tool
<azonenberg>
that will show you a live view of the flash in a hex editor, as you scroll it'll pull more content
<azonenberg>
allow you to patch and write back
<azonenberg>
And make it multi-client capable
<azonenberg>
So for example the uarts would be exposed as telnet consoles
<azonenberg>
just bridged to a TCP socket, with a separate management socket for setting baud rate etc
<azonenberg>
you could have one dev talking to the LA while another talked to uart
<pointfree>
my tool is also intended for RE.
<azonenberg>
I have most of the FPGA IP for this already written, just have to do the glue to put them all together
<azonenberg>
I do embedded pentesting at $DAYJOB
<azonenberg>
We have an assortment of random stuff like the bus pirate, a total phase i2c/spi tool, flashrom, etc
<azonenberg>
half of them only work at a smal lrange of voltages
<azonenberg>
most of them have buggy closed source software
<azonenberg>
Plus when you clip onto say a soic for flashing, you lose LA access to those pins
<azonenberg>
i'd rather be able to use the same probe clips as both LA and SPI etc
<azonenberg>
I already have a TCP offload engine, UART, I2C, SPI, and logic analyzer core written for my past FPGA projects
<azonenberg>
It's just a matter of gluing them together and writing the UI software
<azonenberg>
most of the work will likely be in the UI
<azonenberg>
As well as the board-level hardware design for things like input ESD / overvoltage protection
<azonenberg>
there also has to be a very easy way to set a voltage threshold on everything
<azonenberg>
This week alone both me and another consultant @ $WORK killed 1.8V flash chips because the tool we have in the lab for it makes it very easy to accidentally apply 3.3 or 5V
<azonenberg>
thankfully this was while burning a modified image, we already had the original content so we could just replace the chip
<azonenberg>
But that was just dumb luck
<pointfree>
Well, you just listed a lot of unsatisfied features for a product!
<azonenberg>
Lol well i really dont care if somebody else builds it before i get around to it
<azonenberg>
If they do, $WORK will buy me one :p
<pointfree>
If you have the time and want to collaborate on something like this let me know! We could put it on crowdsupply or the similar.
<azonenberg>
My tool will probably be a bit higher end than you want as far as budget/ feature set
<pointfree>
or similar*
<azonenberg>
I want a LA good to at least 100 MHz, preferably more
<azonenberg>
gigabit ethernet
<azonenberg>
the FPGA in the prototype will probably be an xc7a50t or larger
<pointfree>
Yes, my tool is targeting the same price-point as the Bus Pirate.
<azonenberg>
Yeah, different market then
<azonenberg>
Today at work I had to sniff 40 MHz SPI
<azonenberg>
using a saleae
<azonenberg>
then program the chip using a bus pirate, which took forever due to the low clock speed
<azonenberg>
then sniff some traffic on a uart
<azonenberg>
etc
<azonenberg>
i want to combine all of those into different features on one tool
<azonenberg>
Just run a bunch of probes from one expansion header to every signal of interest on the board
<azonenberg>
and let the FPGA figure out the rest
<azonenberg>
Have options for using an externally provided voltage reference or synthesizing a voltage internally
<azonenberg>
at least 3 or 4 I/O banks, all separately level shifted
<azonenberg>
Switchable pullup/down for every pin
<azonenberg>
oh, and JTAG as well
<azonenberg>
Typical scenario: Hook probes up to every pin on a debug header near a flash chip
<azonenberg>
sniff, figure out which ones are what for the SPI
<azonenberg>
(bonus points if there's also a DMM mode so you can figure out voltage levels... I don't need a DSO, just Hz to kHz range voltages)
<azonenberg>
Then immediately convert those same pins from LA to SPI without moving any wires around on the DUT
<azonenberg>
auto-detect the flash chip in use and dump its contents
<azonenberg>
modify the contents, write back
<azonenberg>
then look at the uart console to see if i pwned it
<azonenberg>
This is not a contrived scenario, i did all of that in the last week at work on one project
<azonenberg>
I would have LOVED to replace all of those separate tools with one
<azonenberg>
The bus pirate is a nice idea but too slow
<azonenberg>
like, the LA tops out at 1 MHz
<azonenberg>
with any xilinx part you could *easily* make a LA good to 200+
<pointfree>
So, I'm not sure how much a user would want to do from within the PSoC from flash and SRAM and how much they would want tethered from their laptop (Linux/radare2/etc)
<azonenberg>
Yeah i'm up in the air on how much to offload too
<azonenberg>
i cant reject the possibility of doing PR for user accelerators at some point
<azonenberg>
but short term i'll be writing firmware then interfacing to it via TCP sockets
* azonenberg
mentally calculates if he could do all of this in a FTG256 FPGA
<azonenberg>
artix7 ftg256 is 170 IOs
<azonenberg>
RGMII is ~15
<azonenberg>
Say 32 going to the expansion header
<azonenberg>
6 to boot flash
<azonenberg>
again, the big challenge will be the input stage
<azonenberg>
it has to be able to handle bidir protocols like i2c, input, and output
<azonenberg>
with voltages ranging from like 1.5 to 5
<azonenberg>
runtime adjustable
<pointfree>
I wrote a 9P server for another microcontroller so that I can mount the address spaces of a target onto my laptop as a file tree. I suppose that could be something of a compromise with the Linux side...it would allow using unix tools with the microcontroller.
<pointfree>
such as radare2 etc...
<azonenberg>
nice
<whitequark>
huh
<azonenberg>
whitequark: any idea how fast a greenpak with Vdd=5V can switch signals from one voltage domain to another?
<azonenberg>
peak toggle rate i mean
<azonenberg>
latency is less of a concern
<azonenberg>
Probably too slow for what i'm doing
<whitequark>
azonenberg: I never looked at dual supply GPs
<azonenberg>
I think the data rates i want are way too high anyway
<azonenberg>
Do you know of any level shifter ICs that have say 8 bits, with explicit per-bit direction control?
<azonenberg>
the only ones i can find are either auto-sensing or all-way ganged direction control
nmz787_ has quit [Remote host closed the connection]
scrts has joined ##openfpga
azonenberg has quit [Ping timeout: 258 seconds]
openfpga-bb has quit [Ping timeout: 244 seconds]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
azonenberg has joined ##openfpga
openfpga-bb has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 244 seconds]
tecepe has quit [Remote host closed the connection]
<felix_>
problem with the logic analyzer input stages is that you can only have either 5v compatibility or high bandwidth
<nats`>
LA are way more complicated than it seems :)
<nats`>
we have a tektronix here (can be found for less than 500$) and the frontend are able to get from 0.3v to 12V input
<felix_>
didn't have much time to work on my logic analyzer this year, but that is still the main problem
<nats`>
with custom threshold
<nats`>
I guess those are discret FET AFE
<felix_>
selectable threshold is quite easy
<nats`>
not at 500MHz+
<nats`>
ah and they have 1Mohm impedance input too
<nats`>
with long cable
<felix_>
to get 5v compatibility you have to use either a voltage divider (with some frequency compensation) or some 5v compatible buffer, which won't support e.g. 1.2v io
<nats`>
or make a "like" RF front end
<felix_>
well, the fpga has differential input buffers
<felix_>
i was aiming for maybe 400mhz bandwidth
<nats`>
in some way you could change the bank voltage
<felix_>
no, set the bank voltage to 3,3v and connect the reference voltage to the inverting input
<cr1901_modern>
felix_: Aren't 5V compatability and high bandwith kinda mutually excluse in practice :)/
<felix_>
it's input-only, but works rather well
<felix_>
cr1901_modern: yep/ i meant that the same input stage can be used for 5v singnals or for fast lower voltage signals
<felix_>
5v and fast at the same time won't work
<cr1901_modern>
Do you have a circuit with the input stage? I'm mildly curious. I mean even discrete transistors you get from Radio Smack should be able to do 300 MHz
<cr1901_modern>
Granted cutoff at 300 MHz, but you can still amplify w/ that
<felix_>
cr1901_modern: i can link you the circuit from the input stage later
<cr1901_modern>
felix_: This might be a stupid q, but a voltage divider is purely resistive. Why is the freq compensation needed for a purely resistive input? (Or are we talking about voltage divider parasitics?)
<felix_>
well, the fpga has some input capacitance
<cr1901_modern>
... oh. Yea, I'm gonna stop all q's until I see the circuit
<felix_>
so you slightly boost the higher frequencies of the input signals
<cr1901_modern>
In my experience, I haven't needed an input stage. Sending current through the FPGA pins directly (or a logic shifter) has worked fine for me thus far
<felix_>
connecting external probes to the fpga pins directly increases the chance of a fried or esd damaged fpga
<cr1901_modern>
Interesting lol
<cr1901_modern>
I just attached some wires I got from adafruit to a bunch of old clips from a set of agilent probes
<felix_>
that should work, but that's not something you want to sell; the average user will probably kill at least one of the fpga inputs during the warrenty time...
<cr1901_modern>
why will it likely kill the FPGA pin? B/c someone is gonna accidentally put a 5 or 12V input to the pin?
<cr1901_modern>
Or does this apply even if the user knows not to do that?
<felix_>
e.g. applying 5v directly or esd
<nats`>
again if you want a real LA input you don't have choice than making a front end like for RF
<nats`>
sadly I didn't take picture of tektronix input when we disassembled it
<nats`>
I'll try to do that next time
<felix_>
nats`: i'm aiming for maybe 200 euros per device
<cr1901_modern>
My question isn't "can I avoid it"? It's "what are all the things can go wrong w/o one and how is a front end designed to mitigate all the things that can go wrong"?
<cr1901_modern>
out of curiosity, not b/c I want to do this myself :P
<felix_>
ah, ok
<cr1901_modern>
One thing I do know about FPGA outputs (well in this case they were current sinks): If you exceed the current rating for the pin, the output will be start tending toward the opposite voltage of what you want for the pin.
<cr1901_modern>
I have a FPGA floppy disk interface (for fun) and I figured out the hard way that NO FPGA by itself can sink the required current to drive the output interface of a floppy drive low. I have to put an 74F-series IC between them.
<cr1901_modern>
Ironically enough, most 74-discrete logic made today *also* can't sink the required current :P
<felix_>
i can try to answer the question about the inputs later or maybe tomorrow; have a bad cold at the moment and my brain feels a bit sludgy (not sure if thats the right word; "matschig" in german) at the moment
<cr1901_modern>
no worries, no rush
<balrog>
cr1901_modern: yeah that's something philpem ran into with the discferret
<balrog>
what chip did he select...
talsit has left ##openfpga [##openfpga]
<balrog>
SN74LVC14ADB for inputs from the pdrive, SN74LVC07AD for outputs
<balrog>
drive*
tecepe has joined ##openfpga
Bike has joined ##openfpga
<azonenberg>
felix_: yeah what i might do is have two sets of inputs and have 5V tolerance on one half of them or something
<azonenberg>
I rarely have to use 5V logic anymore
<azonenberg>
but compatibility with 3.3 and 1.8 is mandatory
<felix_>
i was also thinking about having a small pcb that can be plugged between the probe connector on the la and the probes, which adds the 5v compatibility
<digshadow>
azonenberg, rqou, cyrozap: making plans to meet tonight
<digshadow>
azonenberg: palo alto area sounds like?
<digshadow>
looking for suggestion
<digshadow>
around 6 pm
<nats`>
anyone with few knowledge about SATA protocol ?
<digshadow>
nats`: yeah whats up
<digshadow>
diamondman: above
<nats`>
digshadow I'm thinking implementing a minimum subset of it so I was wondering if the spec (I got it online) is full mandatory or if you can only implement what needed to write data and read data without optimisation
<nats`>
sort of implementing only some profil of usb
<cr1901_modern>
nats`: Ask _florent_ in #m-labs about SATA. He has experience w/ it
<digshadow>
what sort of optimization do you want to do?
<digshadow>
as an example
<digshadow>
you don't need power management
<digshadow>
just don't advertise it as a capability
<digshadow>
nats`: is this for open source project?
<nats`>
digshadow I guess in the end it'll be published yes
<nats`>
I saw 2 stack
<digshadow>
its worth mentioning there is an opencore
<nats`>
one in verilog but pretty heavy
<digshadow>
but its pretty hacky
<digshadow>
I did get it to work, but it would require a lot of work
<digshadow>
to be used in production
<nats`>
and one made with litex library which seems to be migen based
<digshadow>
hmm? I haven't seen that one
<cr1901_modern>
litex is _florent's_ fork of migen
<nats`>
cr1901_modern that sentence makes not much sense
<nats`>
TMDS doesn't use a code set like 8b10b
<nats`>
8b10b is based on a LUT
<nats`>
TMDS is based on a set of logic operation and conditionnal operation
<cr1901_modern>
It takes 8 data bytes, and represents them in 10 bytes in a way that minimizes transitions :D
<cr1901_modern>
8b10b :P
<nats`>
but in the end the goal is to extend the original 8bit to 10bit
<nats`>
digshadow one of my goal in the process is to learn how to implement it too :)
<nats`>
I mean I made the HDMI2 core mainly for fun
<nats`>
despite I can't release it
<cr1901_modern>
In any case, I still disagree that it's really easy. I would not use that as a beginner's project
<digshadow>
nats`: whats your target chip?
<digshadow>
ie fpga
<nats`>
artix or kintex
<nats`>
cr1901_modern I really say it is
<nats`>
it's easier than VGA for example
<nats`>
just implement the tiny diagramm for transceiver
<nats`>
(RX is way more complicated)
<nats`>
I'll see if I can remove all the HDMI2 specific part from my design to put onine a highly pipelined TMDS code
<cr1901_modern>
Uhhh WHAT?! o.0; Totally disagree w/ the VGA remark (VGA I *would* use as a final project for a Digital I course) but to each their own.
<nats`>
I'm able to output 18gbps from the 3 gtp of an artix7
<azonenberg>
cr1901_modern: with modern kicad length matching is pretty much trivial if you arent routing in a high density board
<nats`>
using that I connected wire with part of an ethernet cable to my fpga
<nats`>
was my first proto for a 1080p60Hz tx
<azonenberg>
its only hard if you are trying to do stuff like QDR-II+
<cr1901_modern>
That's cute... what is it?
<cr1901_modern>
oh nevermind you just said lol
<nats`>
in this configuration it's afake screen
<nats`>
but before I used it as a source
<nats`>
digshadow I'll take a try at writing my own minimalist sata core
<nats`>
maybe in system verilog I would like to try it
<nats`>
and it'll be certainly OS if clean enough
<digshadow>
nats`: if you implement for a standard SATA board
<nats`>
I have no constraint on that one
<digshadow>
like KCU105 etc
<cr1901_modern>
azonenberg: What's tough about QDR-II+? Is that at a speed where data signals could potentially bypass serpentines b/c it's the lowest impedance path?
<digshadow>
and run into issues
<digshadow>
I may be able to run a SATA analyzer to help you debug
<digshadow>
if you get stuck
<cr1901_modern>
(I.e. the serpentine effectively is "seen" as a wide trace?)
<nats`>
ah interesting :)
<digshadow>
although you should be able to do a lot
<digshadow>
with chipscope
<nats`>
yep
<nats`>
I have a genesys2 with kintex and will put a fmc sata board on it
<cr1901_modern>
what's wrong w/ litesata?
<nats`>
but I should be able to relocated output for an other edvkit
<digshadow>
do you have an FMC sata board?
<digshadow>
or will you make one
<nats`>
nop I'll make one
<digshadow>
if you make one
<digshadow>
please use the standard sata port locations
<digshadow>
there are several sata boards
<digshadow>
and they all use the same ports
<nats`>
standard ?
<nats`>
I thought you could put them on any GTX/H
<digshadow>
you can
<digshadow>
but it will make your design a lot more portable
<digshadow>
if someone else wants to use it
<azonenberg>
cr1901_modern: no the problem for me on the ethernet board was
<digshadow>
out of box
<nats`>
do you have more information about which one is the "standard" one ?
<azonenberg>
trying to cram two 36-bit data buses plus address
<digshadow>
i can e-mail you later
<nats`>
would be cool :)
<azonenberg>
fanned out from one bga
<azonenberg>
with only 8 layers
<digshadow>
actually
<digshadow>
eh nmv
digshadow has quit [Quit: Leaving.]
<nats`>
what means nmv
<nats`>
?
<qu1j0t3>
never mind
* qu1j0t3
thinks digshadow meant 'nvm'
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 268 seconds]
pie_ has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
<nats`>
digshadow you have my email ?
<digshadow>
yes
<digshadow>
somewhere
<digshadow>
or i'll irc you
<rqou>
going to listen to clifford giving a talk here at UCB in... 15 min
digshadow has quit [Ping timeout: 252 seconds]
massi has quit [Quit: Leaving]
azonenberg_work has quit [Ping timeout: 260 seconds]
m_w has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 248 seconds]
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
digshadow has left ##openfpga [##openfpga]
azonenberg_work has quit [Ping timeout: 268 seconds]
tecepe has quit [Remote host closed the connection]
tecepe has joined ##openfpga
<DocScrutinizer05>
azonenberg: [2016-11-15 Tue 23:40:00] <cyborgar_> DocScrutinizer05, i got an answer from chuck "The 537 has improved I2C performance. Basically, it was not functioning 100% when a 1.8V signal was used (the “low voltage digital input” mode). That was fixed as well as increased security options for the I2C port. Yes, we will continue to support the 531 regardless, but we recommend the 537 as that will be the volume part going