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> oh
<andlabs> this fucking ISA
<andlabs> the 6502 is basically a 6800 but the B register is replaced with the Y register
<andlabs> by the way, thanks for this, I was looking for something like this because the datasheet has some... holes
<andlabs> mostly due to language issues
<andlabs> to be precise, the DX100 uses an HD63B03XP
<l_oliveira> found that by accident while using my google-fu
<l_oliveira> seems like it's the complete book
<andlabs> which is a 64-pin DIP
<andlabs> the 6809 and 6801 are still 6800s at their heart
<l_oliveira> that's the same mcu used as protection on the double dragon game
<l_oliveira> 63701
<l_oliveira> is the 6809 compatible with 6801 instruction wise?
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 250 seconds]
andlabs has joined ##yamahasynths
<Lord_Nightmare> andlabs: whoa, an actual user of the HD630[1,3]X architecture
<Lord_Nightmare> I'm more used to stuff using the HD637B01Y0 which is the HD630[1,3]Y architecture, which is an extended/enhanced version of the X
<Lord_Nightmare> the sprite handler "protection" mcu in double dragon is an HD63A01Y0 (lower speed grade, same chip) and the protection chip in super dodge ball is an HD63B01Y0 which has about 256 bytes of its 4k(?) romspace full
<Lord_Nightmare> and also the adpcm decoder chip on the realvoice is an hd637B01Y0
<Lord_Nightmare> actually the double dragon mcu and the sdb mcus are both also hd637 eprom parts
<Lord_Nightmare> double dragon also had a version using a mask mcu, on a daughterboard with external roms, wired to run from external romspace
<Lord_Nightmare> after technos probably ran out of blank eprom mcus, and no longer cared about bootlegging
<Lord_Nightmare> the mask mcu internal ROM isn't used
<Lord_Nightmare> god knows what's on it
<Lord_Nightmare> probably cheap scrap mcu from god knows what
<Lord_Nightmare> andlabs: so adding an hd63[7][,A,B]0[1,3]X core to MAME would be nice since the hd63[7][,A,B]0[1,3]Y would be a subclass of it with more features and more ROM
<Lord_Nightmare> currently iirc the double dragon mcu is using some gross hacks for the extra io ports that the Y series parts have beyond the 40 pin V series parts
<andlabs> I have no idea what any of this means, sorry
<Lord_Nightmare> and realvoice (as well as the yamaha PSS-170 which uses an hd63A01Y0 with mask rom, which whitequark has from me) would probably need the extra features
<andlabs> realvoice?
<Lord_Nightmare> andlabs: the DX100 uses a romless HD63B03XP
<Lord_Nightmare> this is an hd6301X series mcu, 64 pin sdip with a lot of peripherals
<Lord_Nightmare> double dragon, super dodgeball, the yamaha pss-170, and the realvoice speech module all use an HD6301Y series mcu, which is a strict superset of the hd6301X series but with more rom, ram and more peripherals
<Lord_Nightmare> the pinout is identical to the X series too
<cr1901_modern> >I have no idea what any of this means, sorry
<cr1901_modern> I think LN wants a MAME port of various HD63xx implementations, which don't exist yet b/c the parts are rather obscure
<Lord_Nightmare> realvoice is a speech module; originally it was an add-on module to the epson hx-20 portable computer, but later there was a "realvoice pc" version released which had TWO HD6301Y parts in it, and took rs232 input
<Lord_Nightmare> its actually a very cool device, i have two of them, both need batteries replaced in the hx-20s since the nicads go bad
<Lord_Nightmare> the current "hd6301" core in mame, as far as i know, is emulating the basic 40 pin Hd6301 chip, correctly called the "HD6301V0" or "HD6301V1"
<Lord_Nightmare> i actually don't know what changed in the V1 stepping, i suspect it was a bug fix to do with serial but i don't know
<Lord_Nightmare> the datasheets of course don't say anything
<andlabs> ah
<andlabs> yeah IDK, sorry
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
linkmauve has quit [Ping timeout: 264 seconds]
linkmauve has joined ##yamahasynths
Nicole_Express has quit [Quit: ZNC - http://znc.in]
Nerionaya has joined ##yamahasynths
<Sarayan> hey whitequark, rewriting the nmigen sim as a C++ codegen?
<ZirconiumX> Yeah, she talked a bit about it in #m-labs
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
ej5 has quit [Quit: Leaving]
<whitequark> Drewriting?
<whitequark> er
<whitequark> my terminal barfed, nevermind
<whitequark> yes, there is interest in doing that, mostly so that you can e.g. replace the Ethernet PHY with a tap interface
andlabs has quit [Ping timeout: 250 seconds]
<Sarayan> huh, wrong channel wq?
<whitequark> where? you asked a question a while ago
<whitequark> so I replied
<Sarayan> I... did? I've forgetten it I guess
<Sarayan> No worry in any case :-)
<whitequark> 16:56 < Sarayan> hey whitequark, rewriting the nmigen sim as a C++ codegen?
<Sarayan> ok, I fail to see how it links with "replace the Ethernet PHY with a tap interface
<Sarayan> 18:12 *** Signoff: andlabs (Ping timeout: 250 seconds)
<Sarayan> gah
<Sarayan> or it's just that it was just way too slow to test otherwise?
<whitequark> first, the python simulator is quite slow, yes
<whitequark> second, it doesn't let you link external verilog code
<whitequark> third, most integrations with the system are naturally written in c/c++
<whitequark> you don't want to build python bindings for every weird linux API first
<Sarayan> indeed
<whitequark> litex already had a simulator like that, it was fairly ad-hoc though
<Sarayan> it feels like nmigen has properties that make a c++ sim both wasy and damn efficient, at least comparatively
<Sarayan> because an event edge can be a method call
<Sarayan> and there won't be a loop, everything can be ordered
<whitequark> that's actually not the case
<Sarayan> what makes nmigen easier to understand makes it easier to sim too
<Sarayan> it's not?
<whitequark> pysim iterates combinatorial logic to fixpoint
<Sarayan> can't you depth-sort it?
<Sarayan> well, topo-sort it I meant to say
<whitequark> it's not a netlist
<whitequark> it's expressed as nested, sequential priority selectors
<whitequark> so I'd have to synthesize it first
<whitequark> well, do some first steps
<Sarayan> unrelated, has a look at the votrax?
<Sarayan> and whatever else I had put in there
<whitequark> not yet :( did not even unpack it...
<whitequark> think I'll have time closer to NY
<whitequark> lots of work + lots of RL obligations I can hardly do
<Sarayan> new year, not new york :-)
<Sarayan> bad brain bad
<Sarayan> heh well, no problem, at least it's safe
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
superctr__ has quit [Ping timeout: 245 seconds]
superctr has joined ##yamahasynths
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths