<digshadow>
balrog: fyi sent guy request about xilinx 9500 software will let you know
<cr1901_modern>
Now seeing the 9500 series RE'd would be something that would _really_ fascinate me. Not to synthesize new designs but to RE existing vintage.
digshadow has quit [Read error: Connection reset by peer]
<cr1901_modern>
balrog: Is that your intent?
<cr1901_modern>
(Well maybe to synthesize my own designs too)
digshadow has joined ##openfpga
<rqou>
are we asking about xc9500 _again_?
<rqou>
somebody please just do it and get it over with
<digshadow>
rqou: this has come up before? whats special about 9500?
<rqou>
nothing
<rqou>
i keep telling other people to go RE it
<digshadow>
why?
<digshadow>
there are many parts, why that one
<rqou>
because it keeps coming up as something people seem to want
<rqou>
for RE purposes
<digshadow>
well the problem in this case is I think we don't have any software that supports 9500
<cr1901_modern>
Excuse me for not being as attentive/informed as you
<digshadow>
which is what balrogs request was about
<rqou>
well, we don't have particularly good control over internal placement
<rqou>
for 9500
<digshadow>
placement?
<rqou>
e.g. there's no tcl nor xdl
<digshadow>
eh
<digshadow>
I did xc2000 stuff a while back, the device is so simple its not hard to figure things out
<rqou>
so we can't control e.g. "use this specific product term"
<digshadow>
easily just do a brute force method
<rqou>
yeah, it's still possible
<cr1901_modern>
digshadow: I think the xc2000 actually has the bitstream format on the datasheet
<digshadow>
for xc2000 you actually wrote in some sort of assembly like lang
<digshadow>
oh does it?
<cr1901_modern>
I _think_
<cr1901_modern>
They were the first xilinx FPGAs, right?
<cr1901_modern>
3-LUTs
<digshadow>
yes
<digshadow>
cr1901_modern: if you find a ref I'd be interested. I promised someone a while back I would release the docs I made for it and haven't gotten around to it
<digshadow>
they have some old apple hardwware they'd like to recover the netlist for
<cr1901_modern>
I'm looking for the relevant datasheet now
<digshadow>
if its flat out publically documented, that makes things a lot easier,
<digshadow>
no hurry
<digshadow>
be back in abit
<rqou>
wait did somebody say there's no software for 9500? that's definitely not right
<rqou>
ise still supports it
<cr1901_modern>
digshadow: Okay I was misremembering. The datasheet has the general structure of the bitstream but doesn't actually describe what data bits do
digshadow has quit [Ping timeout: 264 seconds]
<cr1901_modern>
(Which is still more information that you'd get about programming them compared to PALs of the era)
<rqou>
er, PALs have every bit explained?
<cr1901_modern>
I have never seen a PAL where the programming algorithm was specified on the datasheet. Just some usenet posts and a random angelfire/tripod site.
<rqou>
oh that
<rqou>
yeah, somehow that seems super secret for some reason
<rqou>
but the actual bits are explained i believe
<cr1901_modern>
That's prob true now that I think about it
<pie__>
oh shit i was looking at that a while ago out of curiosity :D
m_t has joined ##openfpga
<pie__>
(just superficially though)
<pie__>
cool
<pie__>
pointfree, i dont remember how much stuff they have on a chip?
<pointfree>
pie__: "Every CAB contains two op-amps, a comparator, banks of programmable capacitors, and a collection of configurable routing and clock resources."
<pointfree>
the chips can be chained together and they are dynamically reconfigurable.
<pointfree>
Lattice has an FPAA too (not as flexible, don't bother).
<pointfree>
Cypress has the Analog Coprocessor
<pie__>
really dumb question, whats this good for? (dont get me wrong i think fpaa is pretty cool in and of itself)
<pie__>
could this be good for like sdr or something
<pointfree>
Right now I'm trying to decide between Anadigm's FPAA and Cypress's Analog Coprocessor.
<pie__>
clock seems kind of low though? (as if i had a clue); 16-40 mhz
<pie__>
i suppose if you want higher youre generally supposed to go to dedicated hardware
<pointfree>
pie__: afaik that's more than the Cypress analog coprocessor
<pointfree>
pie__: I want to use the FPAA's to automatically detect pin types (input/output/bidirectional/tristate/gnd/vcc/etc/etc) based on the ESD protection.
<rqou>
downsides of scrounging up shit pc boxes: sometimes they stop working
<rqou>
this time my dad bought some refurbished hp sff thing and now it doesn't boot
<rqou>
"it was really cheap"
<rqou>
offtopic: does anybody know how exactly linux printing works?
<rqou>
what is Foomatic? CUPS? and how does this interact with proprietary print drivers?
<rqou>
what does a "printer driver" do?
<rqou>
how come the CUPS web gui understands that i have a printer even if it doesn't know how to print to it?
<pie__>
<rqou> how come the CUPS web gui understands that i have a printer even if it doesn't know how to print to it?
<pie__>
THIS
<rqou>
arrgh and after all this it doesn't work properly cause this printer is shitty and busted
<mtp>
oh god
<mtp>
rqou, so, basically, you're fucked
<rqou>
no, i got it to print
<rqou>
but this printer is garbage and has white lines across it
<rqou>
i still don't get _how_ this works though
<mtp>
CUPS knows how to connect to printers, foomatic knows how to shim inside cups's guts and translate jobs to whatever proprietary backend the printer uses
<mtp>
foomatic is a cups filter iirc
<rqou>
so why is there translating involved?
<rqou>
i always thought that printing worked by just shoving a giant bitmap into the printer
<mtp>
because cups assumes you're feeding stuff a printer understands
<mtp>
lolno
<mtp>
it CAN work like that
<mtp>
or you can send any of 10 different printer control languages
<mtp>
or just a plain ascii job
<mtp>
printing is easiest with postscript printers because all you need to do is tell the postscript engine about the features of the printer (ppd file)
<mtp>
but a lot of those cheap printers designed to work with Windows need the foomatic whatever
<rqou>
so what is a ppd?
<mtp>
postscript printer description
<rqou>
and what does it describe?
<mtp>
the postscript level of the printer, any patches to send before the job, the options and paper trays etc
<mtp>
but that's all for postscript printers
<rqou>
level?
<mtp>
"major release"
<mtp>
anyway printing is hell
<rqou>
wait, so what exactly does cups assume?
<mtp>
cups assumes, absent any driver, that it can just pass the content to your printer without processing
<rqou>
"the content?"
<mtp>
whatever you sent as print jobs
<rqou>
so if i go in evince and hit "print", what goes into the print job?
<rqou>
is it the same stuff as if i go in firefox and hit "print"? or in gedit?
<mtp>
i don't actually know :)
<rqou>
wtf
<rqou>
so how come i can just tell cups to print to "ipp://<redacted>.eecs.berkeley.edu" and it "just works" and it even bypasses print quotas (cc awygle :P _)
<mtp>
the only way i ever did unix printing was to export shit as postscript an LPR it
<rqou>
lol we used to have to do that
<rqou>
there would always be tons of wasted paper from people who managed to lpr a pdf as plain text by accident
<rqou>
they eventually "fixed" this problem by removing all the shitty sun thin clients and configuring all the lab machines to just automatically print to the correct printer in the correct way by default
<mtp>
anyway ipp://whatever probably works because the printer knows how to eat postscript
<mtp>
or the ipp queue you're printing to
<mtp>
(it's been forever since iv'e done this and it's always hell)
<rqou>
which is directly on the printer for sure (which is how it bypasses quotas :P )
<mtp>
lol
<rqou>
ah, so all of the "good" printers at the university just accept postscript then?
<rqou>
(btw this is also how weev can print on the printers too)
<mtp>
yeah good printers tend to
<mtp>
well yes
<mtp>
which is why you firewall off the jetdirect/cups ports at your network boundary
<rqou>
lol nope :P
<mtp>
anyway i've also connected with ncat to printer's port 9100 and typed raw postscript at it
<mtp>
feels good
<rqou>
wait is that how it works?
<mtp>
yes
<rqou>
wtf
<rqou>
that feels like a major layering violation somehow
<mtp>
IPP is just, effectively, formalization around that
<mtp>
with some job-control features attached
<mtp>
running over HTTP for some godawful reason
<rqou>
what happens if i send a postscript infinite loop to the printer?
<rqou>
does everybody else in the office/lab/etc. just get sad?
<mtp>
probably
<rqou>
that's dumb
<rqou>
isn't this an easy source of RCEs?
<mtp>
"who cares about printers?" -- vast majority of infosec