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
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [*.net *.split]
doppler has quit [*.net *.split]
natarii has quit [*.net *.split]
doppler has joined ##yamahasynths
natarii has joined ##yamahasynths
andlabs has joined ##yamahasynths
<alva> Have some ROMpler/FM Castlevania tunes https://cloud.beach.city/s/dpWFxDrAG6meJQR
Xyz_39808 has quit [Ping timeout: 258 seconds]
Xyz_39808 has joined ##yamahasynths
<whitequark> hey, i know this channel is full of retro enthusiasts
<whitequark> i have a micropc rev3, aka octagon 5081
<whitequark> here's the manual
<whitequark> the problem i'm facing is that it doesn't boot
<whitequark> i know there is power. i know the address pins are toggling, and on the internal data bus (not the ISA connector) the data pins are toggling
<whitequark> it doesn't print a prompt on the UART and it doesn't respond to ESC
<whitequark> i verified that the uC side of the level translator gets an ESC, and that there is no transmission
<whitequark> i tried running it with autoboot on, with various W2 and W3 jumper settings, no change
<whitequark> seems to have arrived to me in the factory configuration, memories wise
<whitequark> i've extracted and reseated all the memories, no change
<whitequark> there are no electrolytics on board and no oxidation anywhere i see, looks pristine, not even dusty (it was in a sealed case)
<whitequark> even though it's like 23 years old
<whitequark> not really sure what to do next
<TD-Linux> if you have a way to dump the eprom, you don't need a very wide la for the address lines, as it's very likely looping over a small bit of code waiting for something to happen. might be informative on what's happening (this is how I fixed my pc-9821)
<whitequark> oh
<whitequark> well i could use glasgow :p
<TD-Linux> glasgow even has enough lines to do all of them
<whitequark> hrm
<whitequark> it's a 8 bit EPROM
<whitequark> so 8 bit data + uh
<TD-Linux> oh, dumping the rom with glasgow
<whitequark> needs a counter
<whitequark> 15 address lines + 8 data lines = sadness
<whitequark> oh, i got what you meant
<whitequark> the ROM is CAMBASIC IV V5.03
<TD-Linux> cursed idea: lift the eeprom data pins and ground them, then the cpu will count up from 0 on reset due to executing nops
<whitequark> :/
<whitequark> it's a ceramic EEPROM
<whitequark> EPROM*
<TD-Linux> (actually though if you can find a 5v arduino or something it'd make more sense)
<whitequark> oh i would just use a glasgow as a counter
<whitequark> and then some dumb logic analyzer to capture the data
<whitequark> then pulseview to convert it to a ROM dump
<whitequark> so, A0..A9 are toggling
<whitequark> ... wait
<whitequark> the other address pins aren't even connected on the ISA lol
<TD-Linux> one other quick check is sometimes I've seen eprom data lines become "weak", where they don't drive voltages high enough. something you could quickly check with a rigol
<whitequark> i actually did see something weird
<whitequark> a bus driven like... halfway
<whitequark> i wasn't certain which memory chip it is
<whitequark> lemme desocket everything except for EPROM (again, sigh) and try it
<whitequark> horrifyingly i think i am getting better at DIP extraction
<whitequark> yep i am definitely observing this
<whitequark> hmmmm
<whitequark> i also see an obvious period
<whitequark> though this is without RAM so that's expected
<whitequark> wait, i should be looking only at parts where EPROM CE is active
<whitequark> or i guess OE
<whitequark> no, CE
<whitequark> TD-Linux: this is really weird
<whitequark> i.. think the pullups might not be working?
<TD-Linux> pullups where?
<whitequark> TD-Linux: https://imgur.com/a/ER7bo8j
<whitequark> top = CE, bottom = IO5
<whitequark> well, O5 or w/e
<TD-Linux> the CE voltages look preetty weird?
<whitequark> yes
<whitequark> i have no idea why
<TD-Linux> sometimes shorts in other chips will drag down signals. this CE is ROM specific though I think :/
<TD-Linux> does it even have a pullup, or does it go through a PAL decoder or something
<whitequark> lemme trace it
<whitequark> there are two PALs
<TD-Linux> (hopefully it's not a bad PAL, as that's going to be hard to fix)
<whitequark> so the address and data lines all look sane
<whitequark> but CE and OE are like that
<whitequark> it has two PALCE16V8Q
<TD-Linux> yeah continuity test them backwards
<TD-Linux> (there's also a chance that it's the eprom dragging it down though, might also be worth testing it without the eprom installed)
<TD-Linux> *continuity test to find the source of OE and CE
<whitequark> yep its a PAL
<whitequark> hm wait
<whitequark> yep they only go to a PAL
<whitequark> TD-Linux: bad PAL
<whitequark> EPROM is fine
<TD-Linux> unfortunately sort of common :/ the next step is to try to dump the PAL
<whitequark> how do i do that
<whitequark> it does seem vaguely functional
<TD-Linux> two approaches, one is via the official programming interface with a rom programmer that supports it
<whitequark> the other is just enumerating state
<whitequark> ?
<cr1901_modern> PAL algorithms are proprietary, but I _have_ seen them posted online before. I don't remember where tho :(.
<whitequark> TD-Linux: fun fact: this specific PAL ended up owned by Lattice
<whitequark> AMD, Vantis, Lattice