ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
Xyz_39809 has joined ##yamahasynths
Xyz39808 has quit [Ping timeout: 244 seconds]
<Foone>
Lord_Nightmare: no, I believe there's just some sticker on the window.
<Lord_Nightmare>
oh
_whitelogger has joined ##yamahasynths
<cr1901_modern>
whitequark: Where'd you get that perfboard that electrically connects adjacent rows to each other?
<whitequark>
cr1901_modern: locally
<cr1901_modern>
ahh
<cr1901_modern>
I used to be better at it, but in general I'm not good at point-to-point soldering. Doesn't help that I don't have thin enough solder
<cr1901_modern>
whitequark: http://gopher.wdj-consulting.com:70/store/AWARD.ROM This is the dump I made of the DIP EPROM of that PC I mentioned earlier. I don't remember if I still have the board. It's from 1999-ish.
<whitequark>
Lord_Nightmare: so.. about octagon board
<whitequark>
it has a EEPROM and a UV erasable EPROM
<whitequark>
both have bitrotten
<whitequark>
for the UV EPROM, there is a voltage sweet spot where it gives consistent reads
<whitequark>
below and it just returns FF
<whitequark>
above and it starts to return inconsistent values
<whitequark>
do you think there is value in a glasgow applet that tries to find the sweet spot and then does some bit statistics to recover the rotten bits?
<Lord_Nightmare>
yes
<Lord_Nightmare>
and digshadow i'm sure would think so too
<whitequark>
ok
<whitequark>
can do
<whitequark>
i have a question
<Lord_Nightmare>
the fact that lowering the voltage helps read bad roms is well known, but the graphs you posted are the first really detailed showing of exactly why that is
<whitequark>
it's about naming things :)
<Lord_Nightmare>
you should publish a paper on this
<whitequark>
wait. what
<whitequark>
are you telling me my twitter shitposting has like actual value
<Lord_Nightmare>
yes
<Lord_Nightmare>
it has to do with floating gate charges and threshholds
<Lord_Nightmare>
or that's what it was thought
<Lord_Nightmare>
but your graphs show that there's also an oscillation component in there as well
<Lord_Nightmare>
which in retrospect makes sense, bad bits tend to randomly read as 0 and 1 on subsequent reads
<Lord_Nightmare>
a ROM reading device which automatically, possibly on a per-byte basis, tries to find the optimal read threshold for bitrotten roms would be HUGE
<whitequark>
wait really
<whitequark>
this is like
<whitequark>
i mean i more or less already have that code, it's just crappy poc quality
<whitequark>
and yes i was thinking per-byte
<Lord_Nightmare>
i.e if the floating gate charges are between like, say... whatever floating gates are at, which i think is much less than 5v
<Lord_Nightmare>
lets just imagine a floating gate at 0v represents a 1 bit (hence erased eproms are all 1s)
<Lord_Nightmare>
and a floating gate at 3v is a 0
<Lord_Nightmare>
if the floating gate goes below 2.1v or so it reads as random oscillating garbage, or perhaps just 1
<Lord_Nightmare>
if you lower vcc, the threshold comparator used to determine the 0 vs 1 state gets offset lower
<whitequark>
yeah i understand the idea
<whitequark>
that's why i lowered it :)
<Lord_Nightmare>
your device can do better th
<Lord_Nightmare>
your device can do better tho:
<Lord_Nightmare>
you can detect when roms are ABOUT to fail
<Lord_Nightmare>
by raising vcc to ~5.1v
<Lord_Nightmare>
and seeing if bits start to crap out
<whitequark>
oh huh
<Lord_Nightmare>
that means its time to re-burn the ROM
<whitequark>
so i had this idea for a few modes
<Lord_Nightmare>
to refresh the gate charges
<whitequark>
mode 1: just read the damn thing
<whitequark>
mode 2: read the damn thing twice and collate changed bytes
<whitequark>
"quick scan"
<whitequark>
mode 3: read every byte n times (say 10), then if all 10 do not agree, build a distribution for every bit
<whitequark>
"full scan"
<Lord_Nightmare>
theres people with one-of-a-kind prototypes with rotten roms who would love a device to do exhaustive analysis on the eproms
<TD-Linux>
whitequark, interesting, didn't realize it affected the eprom as well
<Lord_Nightmare>
mode 3 would need a 3d graph
<whitequark>
Lord_Nightmare: are you seriously telling me no one built this yet
<Lord_Nightmare>
since the z axis is read voltage
<whitequark>
i was *literally* playing with garbage my raccoon roommate brought me
<Lord_Nightmare>
nobody has done this!
<Lord_Nightmare>
or if they have, i've never heard of it
<whitequark>
i
<whitequark>
okay
<Lord_Nightmare>
wouldnt surprise me if some crazy expensive device exists from a military contractor maybe
<TD-Linux>
if it's related to decay somehow, eprom is interesting because you can easily partially degrade it
<whitequark>
TD-Linux: worse yet, optimal thresholds for uv eprom appear to be per byte
<Lord_Nightmare>
but nothing that a typical consumer or even corprorate customer would have heard of
<whitequark>
oh yeah
<whitequark>
TD-Linux: one problem: i lack EPROMs :P
<whitequark>
i think i threw out a lot of parallel *PROMs i encountered before cuz i thought they were too boring
<whitequark>
well, not that many, maybe a dozen
<Lord_Nightmare>
kevtris was playing around with a one-off device to do it, that crazy eprom reader thing of his using a hacked up allpro88
<Lord_Nightmare>
but it was only ever a one-off
<Lord_Nightmare>
and there was no deep analysis utility attached to it afaik
<TD-Linux>
I'm pretty sure raccoon roommate can solve that quick, but I can also ask around for a stash of failed eproms
<sorear>
if this is caused by transition speed, then it should be strongly afffected by _temperature_ as well as voltage
<Lord_Nightmare>
YES temperature IS a factor
<Lord_Nightmare>
kevtris messed with that too
<Lord_Nightmare>
using ice and a heatgun
<Lord_Nightmare>
iirc heating the chip up DOES help, sometimes a LOT
<TD-Linux>
btw many arcade enthusiasts know about voltage sensitivity on boards, and a lot of arcade power supplies have adjustable +5V
<Lord_Nightmare>
since it presumably boosts the random fluctuations within the read of the gate-cell
<Lord_Nightmare>
due to thermal effects
<Lord_Nightmare>
its a temporary effect
<TD-Linux>
however I kind of assumed the adjustment was more useful because the psus are group regulated designs without kelvin sense, so droop caused most of the issues
<Lord_Nightmare>
but it could make a cell which always reads as 1 otherwise sometimes read as 0
<sorear>
I don't suppose the artiq stuff includes home use of a LHe cryostat
<Lord_Nightmare>
so you'd take 1000 reads of your rotten ROM and binary AND all of them together
<whitequark>
sorear: not at m-labs anymore (do not work for narcissists)
<Lord_Nightmare>
while varying voltage and temperature
<Lord_Nightmare>
statistical analysis may help, but a plain old binary AND also probably works much of the time
<Lord_Nightmare>
since erased cells read as 1
<Lord_Nightmare>
(on MOST chips. on 8049 and i think upd77P2x i think erased cells are 0?)
<Lord_Nightmare>
not 100% sure about 8049
<Lord_Nightmare>
it might be only some mcs-48 variants, not all
<Lord_Nightmare>
maybe the 8048 is erase-0 and 8048H is erase-1, who knows
<whitequark>
Lord_Nightmare: okay so i have a critical question
<whitequark>
upon which depends the success of the project
<whitequark>
what should i call the applet
<whitequark>
right now it's called "memory-27x" but it's just a lie, it works on... most parallel memory
<whitequark>
"memory-prom"? in "eeprom" the "p" doesn't stand for "parallel" but in the applet name it could
<whitequark>
and it nicely rhymes with (e)eprom
<Lord_Nightmare>
memory-prom? like memor-eprom ?
<Lord_Nightmare>
memory-prom is fne
<Lord_Nightmare>
memory-prom is fine
<sorear>
memory-async-rom?
<Lord_Nightmare>
iirc brizzo ran into a very nasty issue with a really unreliable type of 3v3 mask ROM used on certain n64 stuff
<whitequark>
sorear: - is supposed to separate hierarchy levels
<whitequark>
i guess memory-prom it is
<Lord_Nightmare>
these mask roms are part-serial with an internal address counter
<Lord_Nightmare>
so you'd load an address in, then read X bytes starting at said address
<whitequark>
oh i've seen those
<whitequark>
weird things
<TD-Linux>
are eprom output buffers usually CMOS?
<Lord_Nightmare>
the problem is the eprom output was returning garbage
<Lord_Nightmare>
not sure
<TD-Linux>
because if so, adjusting vcc will adjust the midpoint, so it might just be compensating for a weaker reading from the cell
<Lord_Nightmare>
the only way to get a semi reliable read was multiple reads in like 16 word chunks
<Lord_Nightmare>
then offset by 1 word and repeat
<TD-Linux>
this is done quite extensively in nand flash
<Lord_Nightmare>
so you'd get words 0 thru f, then 1 thru 10, 2 thru 11, etc
<whitequark>
TD-Linux: that's what i assume happens
<Lord_Nightmare>
then do statistical analysis of the multiple copies and vote on the stable one
<TD-Linux>
if you go too low does it start reading all 0's?
<Lord_Nightmare>
i'd love to see what glasgow would do with those chips
<Lord_Nightmare>
my guess is whatever brizzo used to read them wasn't sensitive enough or there was clock or other noise leaking hrough and corrupting the PC value
<Lord_Nightmare>
but who knows
<TD-Linux>
so I do have a friend with a whole ton of failed rom/eprom/etc chips
<TD-Linux>
as well as known good dumps for some of them
<whitequark>
okay excellent
<whitequark>
i'll just ... implement this now i guess
<TD-Linux>
I might be able to mail some of them, otherwise I could implement a replica of your device
<whitequark>
TD-Linux: it's literally three 74hc164n
<Lord_Nightmare>
what about re-prom
<whitequark>
connected to all the address lines in sequence
<Lord_Nightmare>
or reap-rom
<whitequark>
i made the dumbest possiblething i could come up with
<TD-Linux>
great
<whitequark>
Lord_Nightmare: oh no, if memory-prom sounds fine to you, i'm fine with it too
<whitequark>
it fits into the existing naming scheme
<whitequark>
nicely
<Lord_Nightmare>
ok
<Lord_Nightmare>
memor-e-prom :P
<TD-Linux>
whitequark, do you have an idea how to decide what the "best" read for a byte is, as you mentioned that the voltage level can vary on a per byte basis?
<Lord_Nightmare>
or just one word: memoryprom
<whitequark>
TD-Linux: not yet
<whitequark>
let's just try a few things and see what works
<whitequark>
well
<whitequark>
this is mildly complicated by me not having golden images for any of this crap
<whitequark>
TD-Linux: wild idea: i could intentionally violate programming timings on a fresh eprom
<whitequark>
eeprom*
<whitequark>
or undervolt it or w/e
<TD-Linux>
I was just thinking leave it in an eraser not long enough (or leave it under the sun or something)
<whitequark>
.. i'm gonna have to get an EPROM eraser in TYOL 2020
<TD-Linux>
I still have to bring my eproms to a friend for that, much like how normal people would ask for a cup of sugar
<whitequark>
lol
<Lord_Nightmare>
you can create a bitrotten eprom by programming it with vpp and vcc set too low, i'd think
<whitequark>
look, i can do advanced data recovery, but if you ask me to implement programming algorithms, i'll pass :p
<whitequark>
(is joke, they're not that bad)
<whitequark>
(i just don't know what format to specify the timings in)
<sorear>
how fast do they erase if you just leave them in an open window
<Sarayan>
sorear: randomly, from what I hear
<Sarayan>
(hi everyone)
<whitequark>
i've heard even ambient fluorescent light will erase them
<whitequark>
over weeks
<whitequark>
or months
<sorear>
iow how much higher is the intensity of a typical eprom eraser vis a vis direct noon sunlight
<Sarayan>
yeah, it's good enough to fuck the contents so that they're corrupted, but not good enough to make the eprom reusable
<Sarayan>
"The UV wavelength of 253.7nm at initial exposure levels of 4000uW/sq cm ensures complete erasure in typically 15 minutes or less"
<Sarayan>
let's see how bad the sun is
<sorear>
at 253nm, I think negligible, that's beyond the ozone passband
<Sarayan>
that's "UVC"
<Sarayan>
"Short-wavelength UVC is the most damaging type of UV radiation. However, it is completely filtered by the atmosphere and does not reach the earth's surface."
<Sarayan>
confirms what you're saying
<Sarayan>
so it's intensity at the frequency the eprom likes
<Sarayan>
now how long before wq whips up an eraser with a lamp, some tubes and aluminum foil? ;-)
<whitequark>
Sarayan: the thing here is that i actually really suck at analog design
* sorear
imagining a big curved mirror to intensify sunlight and some kind of water cooling setup
<whitequark>
like, "would not pass ee 101" suck
<whitequark>
ok maybe that is a bit too self critical
<whitequark>
but you get the idea
<Sarayan>
sorear: frequency multiplier crystals?
<sorear>
those only work at _very_ high per-mode intensities that I don't think can be achieved from sunlight
<Sarayan>
wq: well, I'm essentially a software guy, so you're way ahead of me :-)
<Sarayan>
sorear: You mean "ask the racoon roommate to find one" is easier?
<whitequark>
Sarayan: consider that i actually *love* abstractions. i just want to sit all day and write nice simple code that shuffles data between nice simple interfaces
<whitequark>
unfortunately, as you may have noticed, i also ... break abstractions a lot
<whitequark>
i was not going to research eeproms
<Sarayan>
wq: and then the abstraction leaks all over the place and it's time to get out the mop again
<whitequark>
i was trying to play with e-junk to relax
<sorear>
actually, no, if frequency multiplier crystals worked at all on blackbody radiation it would violate the 2nd law, because blackbody radiation has the highest entropy for any energy density
<whitequark>
and then i got distracted
<Sarayan>
"and then I got distracted" -- our motto
* Sarayan
is installing ghidra to look at nv-kernel.o just because
<sorear>
(this assumes that the frequency multiplication process does not involve phonons and so the low temperature of the crystal relative to the radiation field does not provide a source of free energy)
<Sarayan>
sorear: couldn't it just emit the higher frequency at lower intensity?
<Sarayan>
the optical version of a charge pump
<sorear>
it's competing with an inverse process where UV photons are split into two visible photons
<sorear>
for a given amount of optical energy, the planckian distribution has the most microstates
<Sarayan>
so you'd need maxwell's daemon?
<sorear>
basically
<sorear>
maxwelld(8)
<ValleyBell>
cr1901_modern: Sorry, I completely forgot about the chat due to working on the vgmrips site.
<ValleyBell>
I was playing back Tales of Phantasia MIDIs (converted from SPC files) on my Yamaha MIDI module.
<Sarayan>
meh, I just don't understand ghidra
<Sarayan>
it doesn't seem to propagate function signatues
<Sarayan>
errr, you have to commit the signature before it uses it? weird
<whitequark>
TD-Linux: poke
SceneCAT has quit [Quit: *Mreow*]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##yamahasynths
cr1901_modern1 has joined ##yamahasynths
cr1901_modern1 has quit [Client Quit]
cr1901_modern1 has joined ##yamahasynths
cr1901_modern has quit [Disconnected by services]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##yamahasynths
SceneCAT has joined ##yamahasynths
* whitequark
pokes TD-Linux harder
<TD-Linux>
whitequark, what's up
<whitequark>
TD-Linux: o hi
<whitequark>
i just pushed something for glasgow
<whitequark>
completely rewritten prom applet and it can now check the health of proms
<whitequark>
can you repro my results?
<TD-Linux>
verify needs to note that -f is required
<whitequark>
done
<TD-Linux>
so scan just does multiple check passes?
<whitequark>
basically yes
<whitequark>
check is fixed time, scan is potentially indefinite
<whitequark>
well i mean the eeprom is finite
<whitequark>
the idea is that check quickly shows you whether the prom has gone to shit
<whitequark>
and scan shows the degree
<TD-Linux>
on my "bad" eeprom it detects bytes as decayed though it doesn't detect the same ones on every pass
<whitequark>
Lord_Nightmare: so... is there anythign else you'd actually like to have in the applet?
<whitequark>
hm
<whitequark>
should i implement EEPROM write support y/n
<cr1901_modern>
Does it require high voltages?
<whitequark>
well the one i have is 5V only
<Lord_Nightmare>
massive nintendo source leak on 4chan btw
<Lord_Nightmare>
including source code to many 1st party snes games like SMAS, ALTTP, Star fox 1 and 2, and f-zero
<cr1901_modern>
Yea I got the links
<Lord_Nightmare>
and source to LADX for gbc, as well as the gbc bootrom and gba bootrom
<Lord_Nightmare>
the latter have multiple ROM revs and also have the subversion tree
<Lord_Nightmare>
... why link those here? this channel is logged
<cr1901_modern>
Because sharing is caring
<whitequark>
Lord_Nightmare: anything you can say about the applet?
<Lord_Nightmare>
looking
<Lord_Nightmare>
wow, that is VERY comprehensive
<whitequark>
it seems to be able to deal with all 3 of my bad (E)EPROMs easily
<whitequark>
i just put in the number that `health sweep` gives me
<Lord_Nightmare>
about the only other thing i could think of adding is support for 93cxx serial eeproms which have a very different interface, but that may be unnecessary or a job for a different tool
<whitequark>
ugh i actually have a bunch of those
<whitequark>
microwire, right?
<Lord_Nightmare>
i'm not sure what its officially called
<whitequark>
93lc46 for example is a microwire part
<Foone>
cr1901_modern: I'm not sure which channel you mean.
<cr1901_modern>
This one
<Foone>
oh I see now
<whitequark>
Lord_Nightmare: ok yeah i actually planned to do it some time ago
<Lord_Nightmare>
there's also the rare 24xx jedec serial roms but i don't know much about those
<whitequark>
they have a bizarre and obnoxious bit level protocol
<Lord_Nightmare>
they never caught on
<whitequark>
i worked out a plan to support it nicely
<Lord_Nightmare>
i think they're a different protocol from microwire
<whitequark>
isn't that just i2c?
<whitequark>
should be supported by memory-24x
<Lord_Nightmare>
ah! does memory-24x have support for undervolting/sweep?
<whitequark>
nope... would not be hard to add though
<whitequark>
do you really have i2c eeproms so old they bitrotted?
<whitequark>
i mean i guess why not
<whitequark>
i'm just more used to seeing those brand new
<whitequark>
like
<whitequark>
you call them "weird eeproms" but glasgow itself has two
<whitequark>
for me those are the single most boring kind of eeprom imaginable :)
<Foone>
I've got some old bitrotted EPROMs from a weird Soviet soundcard that I've been meaning to try to recover. It'd be interesting to try this method on those
<whitequark>
Foone: do it!! :D
<whitequark>
happy to help if the existing algos are not enough
<Foone>
as soon as I get a glasgow, will do!
<whitequark>
this was really easy to implement and test
Patater has quit [Quit: Explodes into a thousand pieces]
Patater has joined ##yamahasynths
<cr1901_modern>
Apparently there's also a SMW prototype