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
<cr1901_modern>
cc: Lord_Nightmare if you're around. You've done GAL/PAL RE, correct?
<whitequark>
the bitstream is actually public i believe
<whitequark>
but not the algos
<Lord_Nightmare>
i've done some gal/pal re but mostly from the non-registered device dumping and analysis standpoint
<Lord_Nightmare>
i think balrog knows more than i do
<cr1901_modern>
indeed. Re: the algos, if you go down that route, you'll prob find it w/ a careful Google search
<whitequark>
let me see if this is a registered one
<Lord_Nightmare>
if its a gal its possible the eeprom cells on it bitrotted away
<Lord_Nightmare>
that's going to be a bigger and bigger problem with old devices
<Lord_Nightmare>
gal and palce devices use eeprom cells on them, not fuses
<Lord_Nightmare>
and those do eventually rot
<whitequark>
so i think i might know the cause
<whitequark>
there are two PALs in it
<whitequark>
one with a factory laser marking
<whitequark>
the other, same p/n, but with a thermoprinter label on it
<whitequark>
same format
<whitequark>
3271A28B1 on the good one
<whitequark>
3272A2612 on the bad one
<whitequark>
so... i'm speculating the bad one was programmed in a different way
<Lord_Nightmare>
seems like one is part 3271A and one 3272A, the end is a datecode?
<whitequark>
why the long part numbers?
<whitequark>
is this some established format that PAL vendors accept?
<whitequark>
or just something the vendor here made up?
<Lord_Nightmare>
no
<Lord_Nightmare>
^
<Lord_Nightmare>
vendor made it up
<whitequark>
ok
<Lord_Nightmare>
its just a sticker they put on the pal after programming it
<Lord_Nightmare>
28B1 could be a checksum also
<whitequark>
thats on on one of the PALs
<Lord_Nightmare>
same with 2612
<whitequark>
the other PAL has a laser marking
<cr1901_modern>
2612... huh
<whitequark>
different color
<whitequark>
under the manufacturer marking
<whitequark>
wait
<Lord_Nightmare>
cr1901_modern: nothing to do with ym2612
<whitequark>
not laser
<cr1901_modern>
I know :P
<whitequark>
the 28B1 one is marked in silk
<whitequark>
the 2612 one is marked with a label
<whitequark>
so
<whitequark>
since the 2612 one is not clocked, i guess i could just brute force it?
<whitequark>
question
<whitequark>
which kinda PAL devices exist?
<whitequark>
i know 16V8 and 20V8
<whitequark>
presumably amount of IO and amount of O
<whitequark>
er
<whitequark>
amount of I and amount of IO
<whitequark>
not including CLK/OE
<cr1901_modern>
Those are the two I know, divided into registered and non-registered version (whose exact part names I don't know)
<whitequark>
mkay then i'll just support these two
<whitequark>
though i guess i could write my code to be generic for any kind of PAL/GAL
<whitequark>
it's not like it's harder
<cr1901_modern>
Going a Glasgow brute force RE or programmer applet?
<whitequark>
former, though it will be called `program-pal` in the Glasgow taxonomy
<whitequark>
hm
<whitequark>
actually
<cr1901_modern>
If I remembered where the algorithms are online, I would've linked them here (I found them once on Usenet, and another time on some old Tripod site) :P
<whitequark>
hey do you know how to bruteforce RE clocked PALs
<whitequark>
?
<whitequark>
does that even make sense?
<cr1901_modern>
Have two truth tables... outputs and inputs and outputs' (prime)
<cr1901_modern>
find the truth table for outputs prime given the inputs and the current outputs
<cr1901_modern>
Have two truth tables* <-- err, have two sections of inputs*
<cr1901_modern>
Oh right: outputs prime is "the value of the outputs after the active clock edge"
<whitequark>
i think that's not enough
<whitequark>
because there could be hidden state
<whitequark>
imagine a counter
<whitequark>
one input, 8 outputs, 256 states
<whitequark>
oh, wait
<whitequark>
PALs don't have buried macrocells do they?
<whitequark>
... but they could have macrocells where the OE is always low
<whitequark>
which is equivalent
<cr1901_modern>
Hrm, you're right. You could suss out whether there's extra state, but Idk where you go from there
<whitequark>
ok so i won't bother making an applet for PAL/GAL
<whitequark>
i'll make an applet for reading 29x memories
<whitequark>
which coincidentally can produce truth tables for fully combinatorial PAL/GALs
<cr1901_modern>
Brute forcing does indeed work (or at least create pretty accurate models) if you have some idea of what the internal state looks like. See: most Yamaha FM synth emulators. >>
<cr1901_modern>
But since a PAL is a blank slate, I think you would need some external context to do brute force. Idk how one would make that generic over e.g. a Glasgow applet.
<whitequark>
you don't
<cr1901_modern>
That works :)
<whitequark>
whats the slowest ROM you can imagine
<whitequark>
250 ns?
<whitequark>
500 ns?
<Lord_Nightmare>
how many pal types? a lot
<Lord_Nightmare>
probably over 100
<cr1901_modern>
150ns is the highest I've seen personally. 250ns should be safe I think
<whitequark>
cool ty
<cr1901_modern>
Yea I see 250ns parts online and not higher
<cr1901_modern>
(Looking for 2764 EPROM parts- and I don't think ROM would be slower than that... would it?)
<whitequark>
if a ROM slower than that exists, it is surely made by a company called something like "FastMemory
<whitequark>
and the product must be called "SuperROM"
<cr1901_modern>
but of course :P
<cr1901_modern>
FastMemory SuperROM is almost as reliable and functional as SoftRAM :)
<whitequark>
cr1901_modern: you know, going in the footsteps of Lattice UltraPlus (former slowest FPGA family on market) and QuickLogic EOS S3 (likely current slowest FPGA family on market)
<whitequark>
this will never stop being funny to me
<sorear>
250ns? isn't CROS/TROS faster than that?
<cr1901_modern>
Ahhh, I get it! Thought you came up with some random company that sounds like it would sell snake oil
samlittlewood has quit [Ping timeout: 265 seconds]
<whitequark>
TD-Linux: uh, that's uh
<whitequark>
some really low output voltages
<whitequark>
let me zoom in on those traces...
<whitequark>
also
<whitequark>
is it common that E?E?P?ROM output drivers are single sided?
<whitequark>
ie that it requires pulls to one direction
samlittlewood has joined ##yamahasynths
<cr1901_modern>
If /OE isn't asserted (but /CE is) the output drivers are disabled
<cr1901_modern>
but they are listening for input
<whitequark>
yes
<whitequark>
but i mean
<whitequark>
do any of ROMs have half of a totem pole output driver?
<whitequark>
eg TTL without an actual integrated pullup
<whitequark>
or NMOS (not CMOS)
<cr1901_modern>
I don't know :(
<whitequark>
i'm sure there is some godforsaken chip that needs this
<whitequark>
for example
<whitequark>
this PAL seems to only have the top half of the driver
<cr1901_modern>
This is the good PAL presumably?
<whitequark>
the bad one
<whitequark>
i haven't tried doing anything with the good one cuz it's clocked
<whitequark>
TD-Linux: we have a readout!
<cr1901_modern>
\o/
<whitequark>
... this seems like a really trivial PAL unless it's bitrotted so far it is almost completely nonfunctional
<whitequark>
hm, wait
<whitequark>
i think this is wrong, hang on
<whitequark>
TD-Linux: yikes
<whitequark>
it has Vhigh=670mV
<whitequark>
i... actually don't have anything that can read this
<whitequark>
cr1901_modern: so if we consider this PAL a memory, the read latency is uh,
<whitequark>
about 1000 ns?
<whitequark>
600 ns fall time
<cr1901_modern>
That sounds utterly horrible, and while the z80 has a 4-clock bus cycle (IIRC), I think it would be clocked above the maximum speed for waiting for the PAL
<whitequark>
i think it's just like
<whitequark>
weak pullup on glasgow side
<whitequark>
10k
<cr1901_modern>
Oh, hmmm
<cr1901_modern>
btw
<cr1901_modern>
>eg TTL without an actual integrated pullup
<cr1901_modern>
Just to clarify for my own sake... is it that the pullup _and_ transistor connected to GND in the totem-pole output are missing. Or just the pullup is missing?
<whitequark>
what seems to be missing is a *pulldown*
<whitequark>
ie
<whitequark>
PAL gives me a nice 70-ish nanoseconds rise time
<whitequark>
and then the glasgow 10k pulldown drags it back for 600 s
<whitequark>
*ns
<whitequark>
and without an explicit pulldown it just takes forever
<cr1901_modern>
Ahh so pullup was a typo in your initial msg
<whitequark>
it was more of an example
<cr1901_modern>
Anyways, clearly this behavior doesn't seem right, but since we know the PAL is bad... do you have any comparators in your parts drawer to do custom level shifting to something tools can use?
<cr1901_modern>
tools like LA*
<whitequark>
nope
<whitequark>
i don't have analog components :p
<whitequark>
i probably uh... should
<cr1901_modern>
It's the least complex solution (and takes up less space than discrete level shifters) I can think of.
<cr1901_modern>
Re: your tweet... Idk any chips. A typical CMOS circuit at any logic level isn't going to like 0.7V on the input- thresholds are pretty tight, like e.g. 4.95-5V for 5V CMOS.
<cr1901_modern>
err any voltage*
<whitequark>
cr1901_modern: glasgow *does* have an 1.8V iostandard
<whitequark>
but even that has too much of a high threshold
<TD-Linux>
whitequark, sorry I fell asleep, the other is reading it like a ROM and hoping it doesn't use the registers, and/or reading it like a ROM and then trying to figure out the registers
<TD-Linux>
I don't know of any (non-broken) ROM types that have open collector outputs
<TD-Linux>
the naming scheme started with 16L8 and 16R8 (unregistered and registered)
<TD-Linux>
note that the registered ones don't have hidden state in that you can't turn off the output drivers
<TD-Linux>
V8 added the ability to enable the registers from the bitstream, and also turn off the output drivers (enabling hidden state)