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
<whitequark> TD-Linux: okay so, it doesn't use the registers because the clock input is always low
<whitequark> so i *think* i can read it like a ROM
<whitequark> i just need some comparators
<TD-Linux> whitequark, cool, that's not surprising as it sounds like it's an address decoder
<whitequark> btw i just added a glasgow applet for reading 27x/28x
<TD-Linux> very nice
<whitequark> can you test it on smth?
<whitequark> i bet you have some of those
<TD-Linux> yeah I do, let me look in my parts bin
<TD-Linux> I expect the pal inputs to be the high address lines and there to be an output for the OE of various chips
<TD-Linux> you might be able to just reconstruct it based on the memory map in the board's documentation
<whitequark> TD-Linux: hrm
<whitequark> okei i can try that
<TD-Linux> (there's a chance it handles IO space too which would make it a bit harder, but you can check just by seeing if it's attached to the enable of the gpio chip)
<TD-Linux> found some 2732's
<TD-Linux> interesting, I wrote a jpg to one of these a long time ago and it's no longer decodeable
<whitequark> huh
<whitequark> are you sure it's the ROM?
<whitequark> it could be glasgow!
<whitequark> like, that's why i asked you to test it :)
<TD-Linux> that was me testing it with my minipro
<whitequark> ha
<TD-Linux> (currently debugging nextpnr's new requirement of pytrellis)
<whitequark> oh, you have old nextpnr and can't use glasgow?
<TD-Linux> no I just didn't have ice40 support and decided to update it at the same time and am now going down the rabbit hole
<TD-Linux> (on this computer which is different than the one I normally use)
<whitequark> ah
<whitequark> use yowasp? :p
<whitequark> TD-Linux: ah yeah that's something i might have broken
<TD-Linux> also strangely pytrellis installs to /usr/local/lib64/trellis which is outside the normal PYTHONPATH
<whitequark> i think that's intended
<TD-Linux> til my distro just packages nextpnr
<whitequark> arch?
<TD-Linux> fedpra
<TD-Linux> *fedora
<TD-Linux> whitequark, does this require address and data to be on the same port?
<whitequark> TD-Linux: nope
<whitequark> well
<whitequark> you have to glue the ports, eg --port AB, and then use indexes throughout the glued port
<whitequark> so with --port AB, pin 8 is B0
<whitequark> makes sense?
<TD-Linux> whitequark, I get this error. I don't see a way to specify width? https://paste.debian.net/1157374/
<whitequark> TD-Linux: uh, old yosys i think
<TD-Linux> already updating
<whitequark> this isn't even related to the applet
<TD-Linux> yeah I probably should have used my laptop
<TD-Linux> whitequark, cool it works. (sorry for the brief glasgow troubleshooting)
<whitequark> TD-Linux: thanks! gonna take the preview mark off it then
<TD-Linux> whitequark, I might suggest cranking up the default read latency
<TD-Linux> with the eeprom I have here, 250ns is marginal
<TD-Linux> *eprom
<whitequark> huh really?
<whitequark> what's the p/n
<TD-Linux> NEC D2732D. I don't have a datasheet for it but a similar one says 200ns access time
<TD-Linux> but another says 450ns
<whitequark> wtf ok
<TD-Linux> (these are really old, I have them for a dot matrix printer...)
<whitequark> TD-Linux: done
<whitequark> lol and i thought 250 ns is conservative
<TD-Linux> I'm not sure if you'd consider this in scope but an applet that read 1 bit at a time and prompted you to move the wire, then assembled the bits together would be handy
<whitequark> TD-Linux: i feel like this should be solved by one of "revD", "revC GPIO expander", or "manually move the jumpers for high bits"
<whitequark> esp the last one seems much less error prone as you can easily verify that you are getting *some* valid data
<TD-Linux> yeah I think those are the best solution. (though setting high bits needs lots more reads then reading 1 data bit at a time)
<whitequark> another thing i was actually considering is having the memory-27x applet have a *step output*
<whitequark> so you'd hook up like a 74xx counter to it
<whitequark> i guess that sorta breaks the addressing logic
<TD-Linux> I think more people would have 74xx shift registers on hand
<whitequark> the problem with 74xx shift registers is that dumping a 16 bit EEPROM with that can't be done
<whitequark> as you need clock+data
<whitequark> mhhhh
<whitequark> i guess you could dump it twice as 8bit
<whitequark> TD-Linux: okei
<whitequark> i will add a shift register capability i think
<whitequark> seems easy enough
<whitequark> i have a metric fuckton of ROMs i can't easily dump, too
<TD-Linux> worst case you could use a shift register for data too
<whitequark> i guess
<whitequark> TD-Linux: wait, are there 16 bit ROMs?
<TD-Linux> yes definitely. though it's far more common to use 2 8 bit ROMs
<whitequark> any link?
<TD-Linux> whitequark, 27c160
<TD-Linux> a lot of them support reading in byte mode though
<whitequark> TD-Linux: so i'm planning to make an adapter with a ZIF socket
<whitequark> it seems like D0..7, CE, OE are in standard locations
<TD-Linux> there are some mask roms with that pinout that I don't think support the BYTE line
<whitequark> oh yeah talking about just the 8 bit ones for now
<whitequark> what worries me is ~WE
<whitequark> but it seems like if i tie ~OE low, then i don't need to care about ~WE?
<TD-Linux> which chip's WE are you concerned about
<whitequark> suppose I used a 32 pin socket aiming for 1 Mbit density
<whitequark> but smaller ICs would have WE in a different location
<whitequark> and an address pin driver would live there
<TD-Linux> if you select the right chip in software that shouldn't be a problem, should it?
<TD-Linux> but yeah both of those seem to say that OE low is a write inhibit
<TD-Linux> I've never tested this
<whitequark> TD-Linux: the problem is hardware
<whitequark> since the shift register thingy would not have e.g. OE support
<whitequark> (this is why i'm bothering with the CPLDs...
<TD-Linux> can you not just shift in WE like an address bit? the drivers are the same?
<whitequark> probably not? since then there would be glitches on it during shifting
<whitequark> unless i use buffered shift registers
<TD-Linux> oh yeah I was assuming buffers
<whitequark> mhhh
<TD-Linux> I guess you could make the pins in question just go directly to the glasgow
<whitequark> yes but then i couldn't use the same ZIF adapter for different densities
<TD-Linux> are there more than 6 possible locations for the WP pin on the chips you want to support?
<TD-Linux> *WE
<whitequark> :/
<whitequark> i don't want to have some random address pins go to glasgow and some through shift regs
<whitequark> this is a PITA
<TD-Linux> yeah I think we're rapidly sliding into revD territory (alternately - dedicated glasgow rev with the zif socket built in)
<whitequark> TD-Linux: generating ATF15xx bitstreams on the fly was my plan
<whitequark> then you can do just, literally, any pinout
<TD-Linux> sure
<whitequark> okei, so it looks like there are 24 pin, 28 pin and 32 pin packages and that would cover ?most? EPROMs
<whitequark> and EEPROMs
<TD-Linux> definitely the most common ones. the struggle in this area is of course the long tail of stranger and stranger ones
<whitequark> right
<TD-Linux> above 32 pins they generally become flash (and tsop)
<TD-Linux> the biggest eprom I've seen irl is a 27c322 (42 pins)
<whitequark> hrm
<TD-Linux> one of the biggest limitations of the tl866 is the 40 pin zif. jumping to 64 pin helps you especially with plcc, tssop adapters
<TD-Linux> (though with a huge jump in socket cost)
Xyz39808 has joined ##yamahasynths
Xyz_39809 has quit [Ping timeout: 260 seconds]
Lofty has quit [Quit: Love you all~]
ZirconiumX has joined ##yamahasynths
ZirconiumX is now known as Lofty
__sen has quit [*.net *.split]
emily has quit [Remote host closed the connection]
alva has quit [Remote host closed the connection]
__sen has joined ##yamahasynths
alva has joined ##yamahasynths
enick_401 has joined ##yamahasynths
ej5 has quit [Quit: Leaving]
Xyz_39809 has joined ##yamahasynths
Xyz39808 has quit [Ping timeout: 260 seconds]
<cr1901_modern> https://twitter.com/The_Episiarch/status/1285391436901265408 Why am I getting emu scene drama vibes from this?
<cr1901_modern> (rhetorical question)