<ZirconiumX>
This is actually the exact same model as the one I have
<ZirconiumX>
Well, I figured you didn't want one of the combination boxes with games and controllers
<whitequark>
oh it's more that "fat unit" sounds like it's describing a raccoon
<ZirconiumX>
But if you skip along you'll see there's a picture of the model number: SCPH-39003
<ZirconiumX>
It's the second of the three fat PS2 models
<ZirconiumX>
But that gave me a laugh
<ZirconiumX>
So I can ship you my board/dead console, that gives you two sets of the same chips
<ZirconiumX>
Need more?
<whitequark>
two is enough to start
<ZirconiumX>
So, do you want me to buy it and have them ship it to you, or?
<whitequark>
yeah that works
<ZirconiumX>
Wonder how much shipping to Moscow is
<ZirconiumX>
Or Russia in general
<ZirconiumX>
(sorry, it's 2am and my brain is *fucked*)
<ZirconiumX>
Oh, and whitequark, would you mind putting the die shots under a creative commons license?
<whitequark>
it's usually around $20-$30
<whitequark>
creative commons, sure
<whitequark>
i normally do public domain equivalent
<whitequark>
but i have no horse in ps2 race so whatever you want
<ZirconiumX>
Public domain also works
<whitequark>
glasgow is under 0-clause BSD which is as close to public domain as you can get
<ZirconiumX>
CC0 is probably fine
<whitequark>
yeah, CC0 for imagery
<ZirconiumX>
Anyway, thanks for this, now I'm going to hit the hay.
<whitequark>
night
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #glasgow
<marcan>
PS2 sounds like a huge target
<marcan>
my "baby's first SEM netlist extraction" project is going to be the GBA, and that already looks pretty daunting
<marcan>
ZirconiumX: ^
<marcan>
CXP103049 is the mechacon, right? why is that so important for emulation? it's just the drive controller
<marcan>
I figure for making PCSX2 suck less you'd be interested in EE/GS
<marcan>
but those are going to be huge
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
ali-as has quit [Remote host closed the connection]
ali-as has joined #glasgow
<whitequark>
marcan: ok, i had another horrible night
<whitequark>
probably going to review stuff now
<whitequark>
marcan: hmmm, so i've read your JED parser
<whitequark>
have you looked at what i did for SVF?
<whitequark>
i'm not sure if i'm trying to have a standard that's high or that's *too* high
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+1/-0/±1] https://git.io/fhhS0
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark ab9dc16 - protocol.jesd3: new protocol.
<whitequark>
marcan: ok, so i ... i guess the word is "rewrote" your JED parser
<whitequark>
to be clear, there wasn't anything wrong with it per se. i could (and maybe should) have merged it as-is.
<whitequark>
i modified it for two reasons: a) i wanted to demonstrate, by example, the preferred way of writing parsers in Glasgow, and b) i had a horrible night and i find writing defensive parsers for awful formats fairly relaxing
<whitequark>
anyway, now i'm going to comment on my changes
<whitequark>
i added proper support for a bunch of features (all field formats, plus design spec with an explicit quirk flag) mostly because it was very easy.
<whitequark>
i separated the bare grammar, concerned with specifying exact character sets, repetition counts, field separators, etc, from the parser actions
<whitequark>
as a side effect, the grammar recognized by this parser is now very close to JESD3C spec. it's very slightly more permissive.
<whitequark>
i made parser errors report the exact line and column where the error was encountered.
<whitequark>
i made the parser explicitly error out on fields specified in wrong order (as per spec; the F field is the main offender here) as well as too many times (not in the spec, but the spec would be uselessly ambiguous if it implicitly permitted that)
<Jasjar>
Sounds good
<whitequark>
i specified explicit base in all numeric conversions, to make it easier to follow.
<whitequark>
also cleaned up a bit checksum handling code, it was a bit too stringy
<whitequark>
i added code to check for the case where F is not specified and not all fuse bits are set, as per the spec.
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+1/-0/±1] https://git.io/fhhSz
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark a573321 - protocol.jesd3: new protocol.
<whitequark>
i tidied up the public interface (i.e. fields) a bit, to make it less redundant and to not export features we don't explicitly support. this is just opinion land.
<whitequark>
oh and i renamed it to jesd3, since that's how the protocol is called. i think the standard doesn't mention .jed anywhere
<whitequark>
marcan: ok, so i made only three changes to the applet itself.
<whitequark>
first, i made some logging code easier to read. you can specify padding width explicitly with "{:0{}b}", which sounds dumb but is the correct way to do it, apparently.
<whitequark>
second, i made the jed-to-bit converter handle parser errors gracefully.
<whitequark>
third, i made identify() return the xc95xx_iface right away, so that the code above it doesn't have to care about private members of the interfaces.
<whitequark>
going to test it on real hardware now
<ZirconiumX>
marcan: the MECHACON is a SoC with embedded ROM and DSP; we know barely enough to HLE the MECHACON, because it's entirely undocumented. The EE and GS are documented, although not all of its secrets are given away.
<whitequark>
marcan: ohhhhh
<whitequark>
the USERCODE was reversed and that's why my PCI debug card has been showing USERCODE=_IPC
<whitequark>
er, _ICP
<whitequark>
which doesn't make sense
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fhhHZ
<_whitenotifier>
[Glasgow] whitequark commented on issue #108: Verify XC9572XL programming on revC - https://git.io/fhhHC
<whitequark>
marcan: the applet still works well on my XC9572XL, and bit files match my reference files from many months ago
<whitequark>
can you double check that JED conversion still works correctly? it should be fine, but still.
<whitequark>
oh and any comment on my changes are welcome of course.
<ZirconiumX>
Anyway, morning
<ZirconiumX>
Late, but whatever
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
<marcan>
whitequark: I saw what you did for SVF, but after looking at the JED spec I considered that to be overkill
<marcan>
clearly you considered otherwise :p
<marcan>
fwiw, if we're doing "real" parsers, have you considered PLY? it's what I've used for that in python, several times
<marcan>
I was wondering about that padding thing, thanks for finding the right way to do it
<marcan>
I looked and failed
<marcan>
I *figured* there had to be a better way but I must've overlooked it
<marcan>
ZirconiumX: yeah but does anything about the mechacon matter for games that isn't already HLE'd?
<marcan>
I imagine most of the PCSX2 emulation problems don't have to do with the mechacon, but I might be wrong
<marcan>
whitequark: re: review, busy for the rest of the day today but I can at least smoke test it, will comment later when I have some time
<ZirconiumX>
marcan: timings are quite important, though you are probably correct in that decapping the EE/GS/IOP will be more immediately useful
<marcan>
whitequark: btw, re: recycled CPLDs... one batch of XC9536XL we got from china had half of them popcorned
<marcan>
no idea if they were pulled, one guess I had was that they were improperly stored and soldered without baking and then they pulled them from that
<marcan>
like 30% didn't work
<marcan>
whitequark: validated jed-to-bit and xc9536xl programming again
<marcan>
whitequark: btw, should the default jtag freq for this applet be 1MHz? that's what impact seems to use for me