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
<TD-Linux>
the interface I'd expect would be to be to use a PGM pin if specified, otherwise CE
<TD-Linux>
I don't know how much you want pin specifications to influence behavior but it's already a pattern in the current interface
<whitequark>
that's fine if they do
<whitequark>
PGM is the same thing as WE, right?
<whitequark>
more or less?
<whitequark>
i might have to assign CE as logical OR of OE and WE
<TD-Linux>
seems so. looks like for the flash you can assert ce and we in whatever order you want
<whitequark>
alrighty
<TD-Linux>
also looks like all of these require data to be valid for the entire time that we/pgm/e is low
<whitequark>
yeah, that seems like something i should definitely assume
<whitequark>
TD-Linux: the best part about your cursed EPROM is that GVpp=Vih doesn't do anything
<whitequark>
they could have actually make it work with just E and three levels
<whitequark>
TD-Linux: okay, please check if what i'm saying sounds sane
<whitequark>
- i should have three pins (all optional), CE, WE, and OE. CE=WE|OE (logical levels used here, as usual)
<whitequark>
- i should have an "access" timing, which is the delay between any control or address pin change to data out
<whitequark>
actually, not quite
<whitequark>
argh
<TD-Linux>
"access" (for writes) should probably be the delay between address and data change to change of a control line
<TD-Linux>
(including when deasserted, though looks like chips like at29c010a have no hold time so technically you could go faster by specifying that as well)
<whitequark>
i feel like my brain needs to operate at 200% to understand this
<whitequark>
suddenly, the cost of a tl866 seems much more reasonable
<TD-Linux>
me reading any timing diagram ever
<TD-Linux>
yeah also just in hardware, the tl866 can put vpp on a variety of pins so there's a lot of discrete parts jammed in
<whitequark>
yep, seen that
<TD-Linux>
most "classic" eprom programmers align the chip on the bottom, which is I think primarily to reduce the vpp possibilities
<whitequark>
if i ever do the glasgow cpld adapter thing, i'll just ask the user to put vpp on the right pin manually
<whitequark>
among other things i think this would reduce opportunity for human error
<TD-Linux>
I don't know what safety checks commercial programmers do but one might be to raise vpp slowly and make sure that vcc doesn't rise with it
<whitequark>
so
<whitequark>
i could theoretically do it
<whitequark>
but the massive high voltage analog mux is really not one of the parts i want to design or debug or be responsible for in any way
<TD-Linux>
I think if you align parts to the bottom it might be only one or very few pins
<whitequark>
it's definitely not one
<whitequark>
as i think they are usually in upper left corner?
<cr1901_modern>
TD-Linux: Re: safety checjs... on TL-866, there's a forward-biased diode on every Vcc line. The Vdd line is open-collector. The Vpp line has nothing special. With this setup, if you enable multiple voltage drivers, the highest voltage wins without damaging the circuit.
<whitequark>
the concern here is about damaging the flash, right?
<whitequark>
these days i don't care so much about the programmer (which is replaceable) but about the flash (which is often not)
<cr1901_modern>
On TL866, there are definitely pins with both Vcc and Vpp drivers. I don't recall any circuitry that can protect against feeding an I/O pin with incorrect voltage.
<cr1901_modern>
And Vpp doesn't go low enough to do what TD-Linux described on TL866
<cr1901_modern>
Oh right: the output drivers can be disabled at rail granularity.
<TD-Linux>
damaging flash during read is definitely bad
<TD-Linux>
damaging flash during write isn't quite as bad but best avoided of course
<TD-Linux>
as another protection I'd assume the vpp boost converter was under software control and would be off unless writing specifically an eprom
<cr1901_modern>
There's 8 voltage levels for the boost converter on tl866. It's software controllable, but I think the rail disable is the only way to disable its output; there's no turning the converter off
<TD-Linux>
I'm describing what I'd want, not what the tl866 does
<cr1901_modern>
oh sorry
<TD-Linux>
(deciding these tradeoffs is a bit far away, I'm just Opinionating)
<cr1901_modern>
digshadow, davidc__, and I had discussed using greenpaks as analog muxes plus FPGA to implement an open EPROM programmer- and to avoid the PIC firmware. But we concluded it's not worth it.
<cr1901_modern>
... oh, you're already in #proghq :P
<TD-Linux>
do greenpaks go high enough voltage for that?
<cr1901_modern>
I _think_ I'm misremembering their role, tbh. It was davidc__'s idea.
<whitequark>
TD-Linux: no
<whitequark>
TD-Linux: okay, lemme try to make sense of these waveforms again
* whitequark
stares more at the datasheet
<whitequark>
TD-Linux: maybe three basic timings?
<whitequark>
"read setup", which is the time between CE/OE negedge and address change, whichever is greatest, to stable output
<whitequark>
"write setup", which is the time between CE/WE negedge and address/data change, whichever is greatest, to WE posedge
<whitequark>
and "write hold", which is the time between WE posedge to the next write or, more likely, busy polling
Xyz_39808 has quit [Quit: Leaving]
Xyz_39808 has joined ##yamahasynths
<Lord_Nightmare>
whitequark: the eprom applet should really use the /CE pin since some oddball mask roms at least latch the address on the falling edge of /CE
<Lord_Nightmare>
the mask roms on the ibm 5150, 5160, and maybe the MDA and CGA cards are like this
<Lord_Nightmare>
so if you don't pulse /ce high-low after updating the address, the ROM dump is just byte 0 repeated over and over
<whitequark>
Lord_Nightmare: yes, that's the idea
<whitequark>
make /CE=/OE&/WE
<whitequark>
just in the case it matters
<TD-Linux>
that sounds ok
<TD-Linux>
defaulting write hold to read setup looks like it would work in most stuff too
<whitequark>
TD-Linux: i got writes!
<whitequark>
no polling yet, hmm
<TD-Linux>
excellent
<TD-Linux>
well for eprom there is no polling :)
<whitequark>
oh, really?
<TD-Linux>
my tl866 does do a verify after each byte is written but it stops if it detects an error
<TD-Linux>
(even on flash I thought the polling was only for erases?)
<whitequark>
hm
<whitequark>
this flash doesn't have separate erase
<whitequark>
it works like an i2c eeprom
<whitequark>
except instead of start/stop you just have a 150 us timer
<TD-Linux>
ah ok I see
<whitequark>
i actually have no idea what algorithms look like
<whitequark>
can you link me several separate flashes and EEPROMs you think are good?
<whitequark>
from different vendors
<TD-Linux>
sure (though flash in small dip packages is sort of uncommon)
<TD-Linux>
also maybe not "good" but at least "common"
<whitequark>
oh i was memeing off "here are some tweets i think are good. do you like this"
<whitequark>
CFI is easy, i'm interested in pre-CFI
<TD-Linux>
so apparently a bunch of the eeproms I have on hand *do* actually have "express programming", which requires "polling" of a sort (more like retrying the program a bunch)
<TD-Linux>
sorry I'm bouncing around a bit, looking through my stuff
<whitequark>
right ok thats fine
<TD-Linux>
ok I guess my 2732 stash was really the odd ones out. every single eprom I've found other than that has had some variety of the write-10-times algorithm
<TD-Linux>
with a different name every time
<whitequark>
hm
<TD-Linux>
personally I like amd's "flashrite"
<TD-Linux>
especially because it's not flash
<TD-Linux>
also I have yet to find any flashes without cfi-style writes
<TD-Linux>
(although some of them are pre cfi technically)
<TD-Linux>
yeah I saw that and have been looking for similar flashes, but haven't found any
<whitequark>
right ok
<TD-Linux>
in particular all the ones I found have separate erase commands and byte/word granularity write
<whitequark>
oh
<TD-Linux>
aha I found one. well it's still separate but it uses non-CFI commands. a CSI CAT28F020P
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 260 seconds]
Xyz_39808 has joined ##yamahasynths
Xyz39808 has quit [Ping timeout: 256 seconds]
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 256 seconds]
<whitequark>
oh
<whitequark>
oh that one is hvp only
<whitequark>
oh god damn it this is horrible
<cr1901_modern>
HVP? Like 18-21V?
<whitequark>
no, >5V
<whitequark>
anything >5V is HVP to me lol
<cr1901_modern>
That's perfectly fair.
_whitelogger has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Read error: Connection reset by peer]
andlabs has joined ##yamahasynths
andlabs has quit [Read error: Connection reset by peer]
andlabs has joined ##yamahasynths
<whitequark>
hey!!!!
<whitequark>
i found the BIOS image of the chip i was reading
<whitequark>
with `health sweep` yesterday
<whitequark>
it matches bit for bit
Xyz_39809 has joined ##yamahasynths
Xyz39808 has quit [Ping timeout: 240 seconds]
<Lofty>
Congrats
<whitequark>
thanks :)
<cr1901_modern>
Excellent work :D
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##yamahasynths
<whitequark>
hmmm
<whitequark>
Lord_Nightmare: i don't think the oscillations contribute to the way bits are recognizd
<whitequark>
or at least
<whitequark>
hmmmmmm
<whitequark>
so the thing is
<whitequark>
i figured out under which conditions it oscillates
<whitequark>
and those are *super weird*
<whitequark>
what you have to do is to excite the output buffers by using the shift registers i have at the right frequency (!)
Xyz39808 has joined ##yamahasynths
Xyz_39809 has quit [Ping timeout: 244 seconds]
<whitequark>
wait, no
<whitequark>
that's wrong
<whitequark>
i just got confused by a slightly different reading algorithm that didn't read bytes in the same order
<whitequark>
frequency doesn't matter much
<whitequark>
okay, i found out something fascinating
<whitequark>
the likelihood of getting unstable words when reading is increased by two things
<whitequark>
- keeping OE low between bytes
<whitequark>
- reading bytes in random order, not just some stable
<whitequark>
*stable one
<whitequark>
however, no matter whether i get 1000 unstable words or 100, the voltage at which they stop oscillating is basically the same
<whitequark>
to me, this implies that the unstable words i get is the number of intrinsically unstable words * the probability of metastability turning into oscillation
<andlabs>
"health swee"?
<andlabs>
*sweep
<whitequark>
andlabs: "keep undervolting by 50 mV until all words read stable"
<andlabs>
oh I thought you meant you found an image that someone else made on the internet
<andlabs>
heh
<andlabs>
to verify yours
<whitequark>
andlabs: i did that first
<whitequark>
it was a BIOS flash
<andlabs>
ok
<whitequark>
after i sweep, what i read matches what ASUS distributes bit for bit
<whitequark>
but i have to sweep first
<andlabs>
ah
<andlabs>
heh
<andlabs>
anyway I might as well post this here given the nature of recent discussions
<andlabs>
Pietro Gagliardi, [26.07.20 14:11] I need to investigate retro PC compatibles of some sort
<andlabs>
Pietro Gagliardi, [26.07.20 14:11] I would like a NuXT but they had something ugly on their site that made not want to do business with the maker
<andlabs>
Pietro Gagliardi, [26.07.20 14:12] and of course they changed everyhting so it' snot there anymore
<andlabs>
Pietro Gagliardi, [26.07.20 14:12] there has to be some alternative
<andlabs>
Pietro Gagliardi, [26.07.20 14:12] and yes, specifically to run Windows 3.x, because I have several old Win16 music programs to run
<whitequark>
regarding my earlier statement that there are "bitrotten EPROMs", that was incorrect
<whitequark>
it was just a signal integrity issue i did not investigate well enough
<whitequark>
so i only have "bitrotten Flash"
<whitequark>
at the moment anyhow
<cr1901_modern>
The hell is a Z8018008? ._.
<fseidel>
well, when a Z80 and an 8008 love each other very much...
<cr1901_modern>
Ahhh so once 151683 is reached the whole EPROM was read correctly?
<whitequark>
basically yes
<whitequark>
for this specific flash i do not have the gold image
<whitequark>
but that's generally how `health sweep` works
<Lord_Nightmare>
whitequark so read the bytes in an NLFSR order
<Lord_Nightmare>
so you can get 2^n bytes
<Lord_Nightmare>
you'll need to store a little table of the taps for various length NLFSRs and the 'extra sticky state'
<Lord_Nightmare>
since an lfsr hits (2^n)-1 states
<Lord_Nightmare>
an nlfsr hits all 2^n
<Lord_Nightmare>
by explicitly checking for the 'almost all zeroes' state and forcing an all zero in, then detecing the all zero state and forcing a 1 in
<Lord_Nightmare>
the tms1000 uses this for its program counter so it hits all 64 bytes on a page
<whitequark>
Lord_Nightmare: wait what
<Lord_Nightmare>
instead of 63 like the sharp mcus do
<whitequark>
i'm confused
<Lord_Nightmare>
an optimal length linear feedback shift register produces a pseudorandom series of values proportional to its length using shifts, XORs and inverts only
<Lord_Nightmare>
but because of math reasons, it can never actually hold a value of all zeroes or it gets stuck at that state
<whitequark>
right, sure
<whitequark>
i don't understand how it's related to this issue
<Lord_Nightmare>
oh, you said reading addresses in order can make bad bytes more common
<Lord_Nightmare>
so read them in a pseudorandom order instead
<whitequark>
oh, nlfsr won't work for that
<Lord_Nightmare>
i guess you can just explicitly read address 0 first, then start the lfsr at 1
<whitequark>
i need to randomize *transitions* from reading byte x to reading byte y
<Lord_Nightmare>
so, maximal number of addres bit flips?
<whitequark>
no
<Lord_Nightmare>
like a sort of grey code?
<whitequark>
i'm kinda going for maximal number of *data* bit flip
<whitequark>
since that seems to excite the oscillators and make metastability clear
<whitequark>
except i don't actually know what the data is
<whitequark>
so i just randomize the entire order in a few different ways
<Lord_Nightmare>
i know for roms with dirty legs, sometimes when you pass the 0x7ff->0x800 transition on address, the first byte or two after that reads bad due to sharp voltage swing because of all the pins suddenly being pulled low
<whitequark>
ahh
<Lord_Nightmare>
usually this happens if VCC is making a poor connection