azonenberg_work has quit [Ping timeout: 240 seconds]
Miyu has quit [Ping timeout: 272 seconds]
unixb0y has joined ##openfpga
unixb0y_ has joined ##openfpga
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y_ has quit [Quit: ZNC 1.6.5+deb1 - http://znc.in]
<awygle>
tfw YouTube recommends TinyFPGA
<tinyfpga>
woohoo!
<tinyfpga>
XD
<awygle>
congrats :-)
digshadow has quit [Ping timeout: 244 seconds]
unixb0y has joined ##openfpga
s1dev has joined ##openfpga
s1dev has quit [Ping timeout: 244 seconds]
ym has quit [Quit: Leaving]
Bike has quit [Quit: Lost terminal]
m_w has quit [Quit: Leaving]
s1dev has joined ##openfpga
digshadow has joined ##openfpga
<cr1901_modern>
> azonenberg_work: see my blog
<cr1901_modern>
Could you point me to a link :)? Also, what's TDR?
azonenberg_work has joined ##openfpga
<lain>
time-domain reflectometer
<cr1901_modern>
Oh, that "find the fault" game you play if you have an oscilloscope, a T-connector, and a square wave generator?
<cr1901_modern>
oh and coaxial cable*
<rqou>
lol cr1901_modern is oldschool
<rqou>
my father was telling me about how he used to do that
<shapr>
but you can't find the fault if you ran your coax over the top of the fluorescent bulbs
<rqou>
lol
<cr1901_modern>
I mean, that's what we did in a lab once. We were given coaxial that deliberately had a fault, look at the oscilloscope to see when the square wave/pulse was reflected. Use telegrapher's equations to predict where it actually is
<awygle>
that's a cool lab
<awygle>
wish we did stuff like that
* cr1901_modern
forgets how to actually find the speed of e-field prop using telegrapher's equations tho
<cr1901_modern>
all that stuff I lost T_T
<azonenberg_work>
seee, i look at the cable datasheet to get a propagation velocity
<azonenberg_work>
Or estimate 2/3 * C in the absence of any information
<azonenberg_work>
then hope for the best :p
<lain>
^
<azonenberg_work>
Since realistically you probably do not know the Er or spacing *that* precisely
<azonenberg_work>
there is going to be some tolerance anyway
<cr1901_modern>
Er?
<azonenberg_work>
dielectric constant
<cr1901_modern>
Oh that
<sorear>
what kinds of cable have a prop speed significantly different from 2/3c?
<cr1901_modern>
azonenberg_work: I think we were given the characteristic impedance (incl. the imaginary part that lossy- aka real- cables have) for rg-58 as an assumption. Or maybe L and C per unit length
<cr1901_modern>
But it's going on 8 years now that I did that lab lmao
<azonenberg_work>
sorear: random data points from googling datasheets
<cr1901_modern>
Being able to calculate it was kinda a requirement to pass that lab. I could use 2/3*C and prob be fine. It's the principle that I let myself forget how to do it, and reteaching myself has been... well, not going well
<sorear>
I mean, "2/3 c" is the number I've always heard for copper-based technology
<azonenberg_work>
RG-316 from various vendors 69.5%, 69%, 70%
<azonenberg_work>
(times C)
<cr1901_modern>
10BASE5 mandates above 70%
<cr1901_modern>
I think that's important to know in 2018
<sorear>
is there anything I could plausibly encounter in my life that's <10%?
<azonenberg_work>
RG174 66%, 66%
<cr1901_modern>
analog delay lines as cables :P
<azonenberg_work>
According to a chart on rfcafe it varies mostly by dielectric
<florolf>
gonna try the readout-protection thing with those later
rohitksingh has joined ##openfpga
p0nziph0ne has quit [Ping timeout: 272 seconds]
X-Scale has quit [Ping timeout: 260 seconds]
<q3k>
heh, gd32
<daveshah>
I thought they just have an SPI flash in the package?
X-Scale has joined ##openfpga
X-Scale has quit [Excess Flood]
X-Scale has joined ##openfpga
Miyu has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<florolf>
rqou: FWIW, same behavior: flash lockout only disengages on POR
<q3k>
fseidel: hm
<q3k>
fseidel: REing the bitstream format for 4000ZE was on my backlog
<q3k>
fseidel: I don't think anyone else looked at lattice CPLDs at all
s1dev has joined ##openfpga
<fseidel>
q3k: woah, cool
<fseidel>
let me know if you manage to get to it
<q3k>
fseidel: but yeah, i have so many stupid personal non-money-making projects on that list that it's gonna take a looong time :/
<q3k>
but i'll certainly bump it up
<fseidel>
don't sweat it, I'm not in any critical need
<q3k>
i at least managed to get isplever to run on docker so I can start running fuzzing at some point or another
<fseidel>
this only helps me avoid designing something myself :-P
<fseidel>
(although maybe learning how to interface a 68060 to a 68000 bus and writing the verilog from scratch is a better use of time than trying to port to a modern CPLD)
<q3k>
huh, yeah
<q3k>
probably easier :)
<q3k>
you could use a ice40 for that, too - low power and cheap enough
<fseidel>
yeah, that's what I had in mind
<q3k>
lp1k would probably do just fine, and they come in large enough packages
<fseidel>
just need to figure out how the bus protocols actually differ. the 68060 docs have a lot of shit in them I don't care about (like multiprocessor snooping). need to figure out what's really necessary
<fseidel>
anyway, thanks!
<gruetzkopf>
where're you getting the 68060s :D
<cr1901_modern>
Is this for some amiga accelerator?
<cr1901_modern>
Only use case that comes to mind attaching a 680x0, x > 2 to a 68000 bus
<fseidel>
my university's computer club has a few
<fseidel>
close, sharp X68000
<cr1901_modern>
I really want one of those (b/c 68k + YM2151 = <3), but I'm not prepared to shell out $700-$1000 for one
<fseidel>
best option is to buy a dead one and attempt to refurb, you can get them broken for ~$200
<fseidel>
shipping from japan is a pain though
<cr1901_modern>
Historically if I take something apart that's already broken it doesn't end up working when I put it back together, so I guess I'll just save up the money
<fseidel>
the issues tend to be bad caps and PSUs (I think the PSU may be made of tissue paper, it's the most fragile POS I've ever seen)
<fseidel>
but yeah, given the cost, it's a risk if you aren't sure you can get it working
<cr1901_modern>
So someone already made a 68060=>68k converter, and you want the equations/schematic?
<fseidel>
yeah, some dude in Japan did a while ago, and someone I know has the card + the JEDEC file used to program the CPLD on the card
<fseidel>
they're super rare and hard to find, so people want reproductions, but the CPLD is EOL. There's an easy to find replacement for it, but I think a new design would be a good thing to have
<fseidel>
and it seems like a fun project, anyway
<cr1901_modern>
https://github.com/fseidel/PCE-HD This is cool; I've seen a number of these "class projects" fail thinking that "because it's 8/16-bit it's going to be easy"
<q3k>
you could just grab a ECP5 and implement the 68060 on there as well
gnufan has quit [Ping timeout: 268 seconds]
<q3k>
so you don't have to use super rare vintage chips
<sorear>
How compatible are 68060 open cores
<fseidel>
cr1901_modern: thanks! how did you find that?
<cr1901_modern>
I _love_ 68k assembly, but the features I love about it come at a cost; the insn encoding is horrifying and there's stuff about internal state that we still don't know about it (i.e. it saves stuff on the stack on exception and last I checked we don't know exactly what that state is)
<cr1901_modern>
68060 sounds like even less fun
<fseidel>
yeah, 68010 and up save A LOT of internal state for resuming after a fault
<fseidel>
could be dual issue of two fusable instructions?
<sorear>
when you dig down to cpu_{superscalar,fuse,bond} that's exactly what they're claiming
<sorear>
"we fuse, also we have 2 pipelines, so it's 4 instructions"
<Prf_Jakob>
Ah okay
<fseidel>
ah, yeah 2 int, 2 address
<fseidel>
so you can probably fuse a load and an add, or a lea and an add, etc.
<fseidel>
interesting that it has its own 3-operand instructions
<fseidel>
at a certain point, these accelerators seem a little silly. tacking an 010-060 on a 68000-based machine is one thing
<fseidel>
but sticking a higher performance core than would have been even remotely possible during the lifetime of the machine sort of feels like running a super gameboy type addon
<fseidel>
where the original machine isn't really doing any of the work
<gruetzkopf>
heh, i once had a accelerator for a600 planned
<sorear>
reminds me of a certain company that used to make 68040 computers and then switched to selling ppc boxes with a rom emulator
<gruetzkopf>
plugged ontop of the PLCC 68000
<sorear>
because, you have a software base
<Prf_Jakob>
fseidel: Well just amiga you got a desktop, so with the new core you can actually do more on the desktop now.
<fseidel>
so this is intended for the "still use an Amiga as a daily driver PC" market?
<Prf_Jakob>
I guess, and funding developement for the core so they can sell it.
<Prf_Jakob>
I think is the long term goal.
<gruetzkopf>
mine was for the fun of it, basically
<cr1901_modern>
2 int, 2 address <-- I'm not sure how these can be used to convert 4 insns into 2, considering most 68k insns are going to have address calculation happening?
<fseidel>
register->register math + memory should fit that
<Prf_Jakob>
gruetzkopf: I have been "planning" one as well.
<gruetzkopf>
had hardware issues, never did a respin
<cr1901_modern>
yea, that sounds logical/fair. Though I'd expect a compiler to do that opt for you :P
<fseidel>
rule #1: never trust the compiler to do anything for you :-P
<Prf_Jakob>
fseidel: I think they mean four 16bit ins. Maybe, because sometimes they are bad at communicating.
<sorear>
slightly tempted to hack a 68k frontend onto BOOM or something
<gruetzkopf>
please do
<Prf_Jakob>
^ ditto
<gruetzkopf>
what worked with my hardware was "boot off of sd card"
<Prf_Jakob>
gruetzkopf: You think all that will fit on a Zynq?
<fseidel>
sorear: funny, that was one of the ideas I had in mind before deciding to do an X68k accelerator
<fseidel>
please do that, sounds fantastic
<gruetzkopf>
why zynq
<gruetzkopf>
and zynq is a fairly broad field
<Prf_Jakob>
Mostly because the Z-turn board with a Zynq has enough IO to replace a MC68k
<Prf_Jakob>
And is cheap enough
<cr1901_modern>
>I think they mean four 16bit ins <-- Are there 16-bit insns that addr memory in 68k (otherwise how do you keep the addr units filled?)
<cr1901_modern>
In any case, 68k decoding is not my idea of a fun time. It's a beautiful ISA with a horrific encoding :(.
<Prf_Jakob>
Data 'op' *(Addr++)
<Prf_Jakob>
Instructions I think excists.
<fseidel>
seems easy enough to make a state machine to parse it
<fseidel>
at least it's not x86...
<cr1901_modern>
Early x86 is easier tha 68k IMO
<sorear>
"state machine" is not an approach that scales to 4-wide decode
<fseidel>
oh shit, right
<Prf_Jakob>
sorear: Four state machines?
<sorear>
that'd work OK with 4 threads
<fseidel>
if you can extract the length in a pre-decode stage, you can use state machines to decode the actual ops
<sorear>
not that much of a gap between "extract the length" and "decode"
<Prf_Jakob>
Well you could have 2 or 3 different types of decoder blocks. So one set which would only work on say 16bit ones and only active when there are 4 16bit ops. Or something.
<fseidel>
that's getting dangerously close to modern x86 decoding
<fseidel>
3 simple decoders and a complex one
<sorear>
well yes
<sorear>
the design space is pretty constrained, modern large processors all look kind of alike
<Prf_Jakob>
They guy doing the apollo core is a former PPC designer, so I not suprpised if it is something like that.
<pie__>
(hey peeps, whats ths topic?)
<Prf_Jakob>
pie__: mc68k cores
<Prf_Jakob>
And amiga stuff
<pie__>
ah ok \o/
<sorear>
mmh
<sorear>
freescale or ibm?
<Prf_Jakob>
Dunno maybe IBM
<sorear>
so when do we get decimal fp
<Prf_Jakob>
Haha :p
<cr1901_modern>
what is insn bonding vs insn fusing?
<gruetzkopf>
i'd love a s390x box
<cr1901_modern>
I'd love a new arch that wasn't painful to write (read: more than load/store touches memory). It'll never happen of course.
<cr1901_modern>
Maybe someone will make riscv extensions to play around w/ a so-called "orthogonal insn set", but I'm not holding my breath.
<whitequark>
cr1901_modern: just use a macroassembler
<cr1901_modern>
Like what :P? NASM is okay, but I find it's too easy to make mistakes w/ it's macro system. I've def batted around making my own before.
<whitequark>
sure, write your own
<whitequark>
add a register allocator while you're at it
<cr1901_modern>
Yup, also have thought about that too :), in fact I have a crappy prototype somewhere.
<cr1901_modern>
Something akin to an "optimizing assembler" lol
<whitequark>
optimizing assembler is harder because if you want to do anything interesting you get UB
<whitequark>
you could probably do a peephole optimizing assembler
<whitequark>
and actually sdcc has it
<whitequark>
it can optimize inline assembly in C code, even
<cr1901_modern>
peephole was what I had in mind. Like "let the peephole optimizer correct goofy insn combos I used when there was clearly a better choice".