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> is disney sound source a covox variant?
<andlabs> yes
<andlabs> it was made BY covox
<andlabs> they are NOT compatible, however
<cr1901_modern> That would be a good explanation
<Foone> yeah, I meant covox/sound source
<Foone> I think the only real difference between the two is the DSS has a fifo buffer so you can actually use the CPU for other things while using it
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 [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
ej5 has quit [Read error: Connection reset by peer]
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
Xyz_39808 is now known as TIMECUBEZ
TIMECUBEZ is now known as Xyz_39808
Xyz_39808 has quit [Ping timeout: 250 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
<andlabs> can someone explain YM2151 key fraction
<andlabs> every tool, be it vgm2txt or a MIDI dumper, tells me that all these notes are 2 semitones lower than they actually are, and yet the key fractions are set at 0
<Lord_Nightmare> i can try but i don't know the 2151 very well
<andlabs> does it have to do wth the clock rate?
<andlabs> YM2151 Clock: 4000000 Hz
<andlabs> in this case
<andlabs> I'll need to find a YM2151 VGM that has properly matching notes to compare it to though...
<superctr_> i believe the chip is in when clocked at 3.57mhz
<superctr_> the notes are in tune
<superctr_> the keycode is basically octave + semitone, and keyfraction is cents
andlabs has quit [Ping timeout: 272 seconds]
Xyz_39808 has quit [Ping timeout: 250 seconds]
andlabs has joined ##yamahasynths
<andlabs> superctr_: ah, ok
<andlabs> I wonder if there's a formula to produce the tuning difference
<cr1901_modern> 3.57 is the recommended clock speed, but I know x68k and at least one other arcade board clocks it at 4mhz
<andlabs> in this case it's sega x board
<andlabs> if x68k runs at 4mhz it'll mean a LOT of VGM files are detuned
<andlabs> so vgm2txt will need slight modifications
<andlabs> hence why I asked if there was a formula
<andlabs> I *could* say ~ 0.25mhz -> 1 semitone but
<cr1901_modern> I don't know the tuning formula I'm afraid
<cr1901_modern> if there is one
<superctr_> you can use a logarithm
<superctr_> Math.log(4.000 / 3.579545) / Math.log(Math.pow(2,1./12.))
<andlabs> ok
<superctr_> to get the key fraction essentially just multiply the decimal part by 64
<andlabs> log(4.000 / 3.579545) / log(2^(1/12))
<andlabs> 1.9226854013928027
<andlabs> so ~2 semitones higher
<andlabs> ok
<andlabs> "multiply the decimal part"?
<superctr_> the fractional part, so to say :p
<andlabs> of what
<andlabs> that number I just got?
<superctr_> yeah
<andlabs> I'm not quite sure how I'm supposed to use that new "key fraction"
<andlabs> but I take it log(4.000 / 3.579545) / log(64) will give me the conversion rate for the key fraction values for pitch bends?
<superctr_> not just pitch bends, you make sure it is always adjusted if you want to be in tune
<andlabs> no I mean
<andlabs> I was going to use that log value rounded "normally" to decide how to add to the note names printed by vgm2txt
<superctr_> you can see the keycode and keyfraction as one big value
<andlabs> but I'd also like to print the number of semitones for the Key fraction values it prints
<andlabs> or are you saying I only need to add 0.9226854013928027*64 to the key fraction values
<superctr_> it's not needed when with the 3.579545 clock, since the chip will be in tune with the keyfraction at 0
<andlabs> or that I shouldn't treat them as separately
<andlabs> since I have some pitch slides I also want to translate =P
<superctr_> if you add a displacement you have to account for wrapping
<superctr_> for example during pitch slides or vibrato
<andlabs> ohhh
<andlabs> so wait, does a delta key fraction of 1 mean the same delta hz regardless of clock speed?
<superctr_> cents, not hz
<superctr_> ym2151 does everything in the log domain already, it converts it to F-num internally
<andlabs> hz as in note frequency
<andlabs> not as in clock speed
<superctr_> just like there's always 100 cents between each semitone, there's always 64 key fraction values
<andlabs> ok, so yes, they are the same regardless of clock speed
<andlabs> I guess?
<andlabs> oh
<andlabs> hz are exponential
<andlabs> this completely fucks with my understanding of music thanks :D
<andlabs> but in terms of pitch slides, if there's always 64 KFs in a semitone, then the amount of bend doesn't change
<superctr_> if you want to convert 4mhz music down to 3.579545 you should always decrease 2 from keycode and add 5 to keyfraction, make sure you handle wrapping keyfraction by changing keycode
<superctr_> actually, it fucks with me too :P That is if you change it the other way, 3.58 => 4 mhz
<superctr_> 4 => 3.58 you add 1 to keycode / 59 to keyfraction
<superctr_> but it's a fixed displacement, since it's in log-domain
<superctr_> so even a Z80 can do it without any issues
<andlabs> well I'm doing this inv gm2txt
<andlabs> just so I get correct note names
<cr1901_modern> I admire your persistence andlabs, I would've ragequit months ago :P
<cr1901_modern> Are cents linearly or log distributed across two notes?
<cr1901_modern> It does tick me off a bit that Yamaha can't make up it's mind about what internal register val maps to a particular (fundamental) frequency
<superctr_> they should be log distributed but i don't really think it's exactly accurate on the 2151 (or any OPN/OPL sound drivers that simulate the way the OPM works)
<superctr_> i think they made the OPM like this just to make it a little easier to program from a user perspective
<cr1901_modern> https://twitter.com/BlueSpaceCanary/status/1163891242679197696 I should read this at some point. Vaguely aware that there isn't actually a "single universal mapping" between frequencies to music notes
<cr1901_modern> but it's based on ratios that "almost sound the same"
<superctr_> apart from the weird gap after every three notes, it's pretty simple on the 2151. a simple lookup table and it's pretty much equal to MIDI notes
<superctr_> i think equal temperament is by far most common though
<superctr_> since it's pretty much the default used by digital instruments
<andlabs> it makes sense from a keyboard design standpoint as well
<andlabs> it'd be pretty weird to have a logarithmic pitch wheel
<andlabs> we have to remember htat Yamaha is a keyboar dcompany first and foremost and that their chips were originally created for htose keyboards
<andlabs> especially the OPM/OPP, which were not only used in Yamaha keyboards, but also a few Korg ones as well
<cr1901_modern> https://twitter.com/whitequark/status/1163890471518687235 wq: Very good q w/ very cool answers. In my experience, I only remember A4 = 440Hz by convention. And all other notes are derived from A4 by ratios.
<superctr_> the YM2151 was created specifically for the Yamaha CX5M and SFG-01 though
<superctr_> those are MSX deriative and MSX expansion respectively
<cr1901_modern> Ultrasauce: Noted, thanks :P. I took music theory eons ago and was one of those dweebs who played an instrument in high school
<superctr_> so the 2151 was designed specifically to be easy to program
<cr1901_modern> ^Then why isn't it?
<superctr_> all other yamaha FM chips just used the direct F-num values, and when writing a keyboard/synth firmware, really it is not hard to calculate the frequency in software anyway
<superctr_> the 2151 is easy to program though. You can do linear pitch slides without any multiplications
<cr1901_modern> If your YM2151 stuff is at 4MHz, and you want it at 3.58MHz, why not resample it after it exits the chip to get to the clock speed you want?
<cr1901_modern> it's not like programming new reg values is going to be accurate anyway
<superctr_> what, in the analog output?
<cr1901_modern> yes
<cr1901_modern> since the music was never made w/ 3.58MHz (and the 2151's quirks when calculating when to increment samples) in mind
<superctr_> well, then you pretty much have to add the circuitry of an entire radio to the audio frontend lol
<cr1901_modern> It's a resampler, not an AM demodulator
<superctr_> you don't resample analog audio
<superctr_> it's not sampled
<cr1901_modern> oh, sorry I thought you were using analog to mean "everything after it exits the chip"
<whitequark> if it runs at 4 MHz and you want it at 3.58 MHz you need an unbounded buffer
<superctr_> you have to use a downconverter
<superctr_> if you want to convert the clock frequency of music, on the YM2151 all you have to do is add a fixed offset
<superctr_> ask grauw what he had to do to convert the clock frequency of OPN music :P
<cr1901_modern> >You need an unbounded buffer <-- oh, you do? I didn't know that
<whitequark> i mean
<superctr_> he had to use a log table + some interpolation logic because real time multiplication isn't viable on Z80
<whitequark> it's exiting the chip faster than it's entering the speaker
<superctr_> if you want to resample the serial output of the FM chip, it also requires extra logic, normally the serial output goes directly to the DAC
<cr1901_modern> Sure, but aren't we talking about software emulators here?
<cr1901_modern> I guess I don't understand what andlabs is trying to do
<cr1901_modern> If all of you were thinking actual physical chips or FPGA impls, then nevermind :P.
<superctr_> he wants to make vgm2txt display the correct note numbers if the chip is clocked at something else than 3.57mhz
<andlabs> correct note names
<andlabs> because both it and some mids produced by someone else's tool were two semitones too low
<cr1901_modern> There's a note-name-to-F-num chart in the app manual IIRC
<andlabs> vgm2txt handles that
<superctr_> the YM2151 does not use F-num
<andlabs> [15:35:13] <superctr_>the YM2151 was created specifically for the Yamaha CX5M and SFG-01 though
<andlabs> oh?
<cr1901_modern> screw it :P
<andlabs> also your booksdl link 404s
<superctr_> you just enter the key code, which is the octave + semitone (though it's weird)
<superctr_> and then key fraction, or detune or pitch bend or whatever you want to call it
<superctr_> the chip internally converts all that to F-num
<cr1901_modern> There should be a wiki page on this. Who wants to create it ;)?
<superctr_> it could just as well been done in software, but you save quite a few cycles on a poor Z80
* cr1901_modern will when he feels better
<andlabs> of course arcade games dedicated their Z80s to sound processing
<andlabs> and almost universally abandoned the 8-bit CPU by 1987
<andlabs> for everything except sound
<cr1901_modern> Is F-num the "internal value the chip uses to figure out how many clocks times in the future to increment to the next sample in the sine LUT (absent all other effects)"?
<cr1901_modern> s/times/ticks/
<andlabs> and for the Genesis they just hard-coded 12 F-nums and used them for all octaves
<andlabs> frnakly the stupidest thing about the Genesis is the fact that they didn't hook the timer to the interrupt lines
<cr1901_modern> ^this
<superctr_> F-num is the base value the PG counter is incremented with every channel cycle
<andlabs> F-num is manageable
<superctr_> it's affected for each operator by the multiply/detune setting
<andlabs> especially since the PSG frequency table is a LOT larger
<superctr_> actually, i've had requests from musicians to add more values to the F-num
<cr1901_modern> It has to be fixed point, correct? B/c it's feasible the PG _doesn't_ incremeent for a given channel cycle
<cr1901_modern> i.e. if the freq is low enough
<superctr_> since you can get a wider frequency range compared with if you only use the block / octave
<superctr_> the PG has a lot of bits
<superctr_> some of them are not significant for the lookup table, yeah
<andlabs> and keep in mind that the Genesis only allocates 8KB of RAM to the Z80, and most sound drivers copy the frequency tables to that RAM
<superctr_> i'm not an expert in the lowest level internals of the FM chip, you have to look at the source code or consult with OG or nukey or someone for that :P
<cr1901_modern> OG has been on vacation
<cr1901_modern> nukey I could email
<superctr_> but i think you could figure it out easily from just the source code though
<cr1901_modern> Sure, but more fun to chat :P
<cr1901_modern> And tbh, sometimes the source/datasheet doesn't answer my questions
<cr1901_modern> B/c they are so well-written and definitely not full of errors
<cr1901_modern> that end up being passed onto the software writers
<superctr_> andlabs, if you want to do a linear frequency slide or apply a proper detune you will likely need to interpolate between the lookup table values though
<superctr_> requiring a multiplication
<superctr_> if you don't want to be dirty like SMPS and just have nonlinear slides (or "pseudo linear" if it does account for octave wrapping)
<cr1901_modern> andlabs: I guess re: the timer int lines, the Genesis designers thought vblank was sufficient. I still would've preferred a dedicated int line tho.
<superctr_> cr1901_modern, yamaha datasheets are lovely :P
<superctr_> especially when you run out of toilet paper
<cr1901_modern> Bahahaha
<cr1901_modern> Use Sega2.doc as your cat's new kitty litter
<andlabs> the Genesis is such a crazily designed system
<andlabs> a system designed in 1988 *for* 1988
<superctr_> isn't that the case with almost every console
<andlabs> and allegedly it was going to be even more ambitious, so whyr eplace it with zero ambition?
<cr1901_modern> My "favorite" part of the Genesis design is that it has a 204 pin bus arbiter IC that basically does the absolute bare minimum arbitration
<andlabs> the SNES
<superctr_> when you start thinking about the future, you end up over-engineering it instead, like the saturn
<cr1901_modern> but it's so damn big solely b/c it needs to route all those pins
<superctr_> the SNES was designed with the idea "let's just put half the console in the cartridge instead, that worked so well with the NES anyway"
<cr1901_modern> What about the Jaguar
<andlabs> if hte SNES had a real CPU — or even just a 3x faster version of the same CPU — ther ewould ahve been no console war
<cr1901_modern> 5 different CPUs
<superctr_> on the other hand, i like the PS1 architecture. it's the console equivalent of the "KISS" principle really
<superctr_> even though it had all kinds of weird quirks and technical limitations
<cr1901_modern> I've been told that PS1 is actually a decent "baby's first emulator" target
<andlabs> it is?!
<cr1901_modern> it's still 3d, which is tricky, but it's regular
<andlabs> so why are there ... no PS1 emulators anymore?
<andlabs> just a bunch of long-abandoned ones
* cr1901_modern shrugs
<andlabs> none of which are OSS
<cr1901_modern> There's some Russian guys doing PS1 RE
<superctr_> the PS1 was one of the first consoles to have viable emulators released within its lifespan
<superctr_> what about mednafen, it's OSS afaik, it's still maintained
<cr1901_modern> andlabs: I think the idea is that it's the first generation of console where you don't actually have to care all that much about timing between components to get something that works
<andlabs> heh
<cr1901_modern> Although I would emulate branching in a delay slot just for authenticity
<cr1901_modern> (something bad happens)
<andlabs> "branching in a dleay slot"
<andlabs> if your CPU isintelligently designed it would make this an exception
<superctr_> i forgot, does the PSX CPU have a cache?
<andlabs> the SuperH used by the Saturn did
<superctr_> if so, then that would add to the complexity
<andlabs> let's see... the PS1 used ... a MIPS
<andlabs> which is designed by... the authors of Computer Organization and Design: The Hardware-Software Interface
<andlabs> aka The De Facto Only Computer Architecture Textbook
<cr1901_modern> SuperH also has delay slots
<andlabs> and also likely responsible for making RISC the Next Big Thing
<cr1901_modern> fwiw
<andlabs> so not making branching in a delay slot an exception was a massive oversight
<superctr_> according to wikipedia, the PS1 has a 5kb L1 cache
<andlabs> no, I meant SuperH doesn't let you branch in a delay slot
<cr1901_modern> andlabs: Uhh, let me rephrase
<whitequark> MIPS ... intelligently designed... yeah no
<superctr_> if you like mips, then you will surely love risc-v
<andlabs> SuperH actually only lets you do certain instructions in a delay slot
<cr1901_modern> risc-v doesn't have delay slots :P
<superctr_> at least they removed the delay slot
<andlabs> risc-v doesn't have delay slots because risc-v doesn't exist yet therefore there is no way it can have delay slots
<andlabs> :U
<whitequark> what
<whitequark> you can buy risc-v silicon just fine
<cr1901_modern> there's some gotchas, but they're cool
<andlabs> give MIPS this: you can actually buy MIPS processors
<cr1901_modern> makes risc-v silicon
<superctr_> delay slot is what you get when you design the microarchitecture before the ISA specification :P
<andlabs> really?
<andlabs> since when?
<whitequark> like a year or two?
<whitequark> sure
<cr1901_modern> andlabs: Si-Five
<andlabs> huh
<cr1901_modern> for instance, Si-Five doesn't have access to flash IP
<superctr_> there's a chinese company making risc-v microcontrollers too
<cr1901_modern> so you have to run your risc-v code from spi flash
<cr1901_modern> which can be slow
<andlabs> ok
<superctr_> there might be a few other companies too, i know western digital released a silicon proved IP core not that long ago
<andlabs> see I always thought RISC-V was the hardware equivalent of GNU HURD
<cr1901_modern> But it does work: https://www.sifive.com/boards/hifive-unleashed
<andlabs> it's been around for 20 years and yet they're NOT DONE SOMEHOW
<cr1901_modern> oooh wait
<cr1901_modern> wrong board
<superctr_> nah, that would be the Mill, andlabs
<cr1901_modern> andlabs: Here's a risc-v dev platform: https://www.sifive.com/boards/hifive1
<andlabs> also whitequark what character is that in your twitter avatar
<whitequark> the manga is called "catulus syndrome"
<andlabs> and I take it that syndrome turns people into catboys/girls?
<andlabs> that's hwat that ttile sounds like
<andlabs> o.o
<whitequark> the latter yes
<andlabs> either way, sure
<andlabs> change cat to dog and I'd be down for some infection o.o
<andlabs> =P
<andlabs> superctr_: "The designers claim that the power and cost improvements come by adapting a DSP-like deeply-pipelined processor to general-purpose code."
<andlabs> why am I getting Cray flashbacks
<whitequark> risc-v has a lot of softcores anyway
<whitequark> i can't get openrisc silicon but it's nevertheless been quite useful
<cr1901_modern> andlabs: Where's your avatar from again? I know I've seen booru artwork of it
<andlabs> touhou
<cr1901_modern> oh right
<cr1901_modern> There's always room for more softcores IMO. Or at least, I'd like to think so.
<superctr_> i think risc-v in general is nice, it's just a shame that the assembly language is absolutely terrible
<andlabs> it's momiji inubashiri, the wolf-girl (but really she's just a dog =p ) character with absolutely no identity because unlike the other characters she onlye ver appeared as an enemy sprite
<superctr_> it's an architecture designed for compilers and not humans
<andlabs> which led to pretty much every artist giving her different ideas
<cr1901_modern> superctr_: You've described ba- ya know what I'm not taking this bait today
<andlabs> and then some people in a nsfw channel found some to tie to me
<cr1901_modern> lmao
<andlabs> and well
<andlabs> here we are
<andlabs> "The claimed improvements in power and area are said to come from eliminating dynamic optimizing hardware: register-renaming, out-of-order execution hazard management, and dynamic cache optimizing. To replace that hardware, each Mill processor is designed to have timing and memory-access behavior predictable to single cycles, so that all the scheduling is subject to a highly-optimizing compiler."
<andlabs> .....why am I getting flashbacks to every pre-RISC CPU
<whitequark> superctr_: i mean optimizing ISAs for compilers makes sense
<whitequark> given that the vast majority of code is not written in assembly
<superctr_> it does make sense, but i think it's just unfortunate
<whitequark> although some blame for it is taken by our modern assemblers being godawful.
<whitequark> for example, an assembler can and should do register allocation
<whitequark> and calling convention handling
<andlabs> "Mill uses a very long instruction word (VLIW)-style encoding to store up to 33 simple operations in wide instruction words, termed opcodes. Mill uses two program counters, and every wide instruction is split into two parts. One of the program counters counts backward.[7] So, the code of every linear instruction block is executed from its middle to outside by two almost independent decoders.[clarification needed] Unused
<andlabs> operations are deleted by a small fixed-format data item in the center of each instruction. This helps maintain code density by reducing the incidence of no-operation codes in Mill code. It also allows each functional unit to start speculatively executing its instruction field, and then discard its result if it has no instruction. "
* whitequark gets on her horse
<andlabs> help
<andlabs> why do I feel like I'm stoned just by reading this
<whitequark> it's the timecube isa
<andlabs> ha
<andlabs> and apparnetlyt hese people worked at Philips
<andlabs> what are you doing
<superctr_> i like using assembly-level debuggers and disassemblers, so i end up staring at a lot of (compiler-generated) assembly code
<cr1901_modern> I've been told you watch Mill presentations if you want to watch Gandalf discuss CPU architecture
<andlabs> [16:19:16] <whitequark>and calling convention handling
<andlabs> <Plan 9/Go Assemblers> hey we do that already!
<superctr_> but MIPS, RISC-V and similar is like staring at a brick wall, sometimes
<cr1901_modern> andlabs: Don't mention Plan 9 here
<andlabs> <Plan 9/Go Assemblers> but we also try to be Everything!
<whitequark> superctr_: oh yeah that makes sense
<andlabs> <Plan 9/Go Assemblers> why doesn't anyone want to use us?...
<whitequark> have you looked at binary ninja?
<superctr_> especially when they play with the 'ra' register and not always use the stack
<whitequark> it uses several IRs to lift assembly into so you can read it more easily
<andlabs> hi I use acme
<andlabs> fight me
* whitequark fights andlabs
<cr1901_modern> _I_ personally don't care
<whitequark> well not really
<superctr_> nah, i use my old cracked IDA pro and NSA botnet disassembler
<cr1901_modern> :P
<whitequark> superctr_: right so i've never used ida but people tell me it stilld oesn't have a true IR
<whitequark> which really sucks
<andlabs> whitequark: I want to make an assembly language with an actual lexer and parser
<superctr_> i think ghidra is quite nice though
<whitequark> binja is the only disassembler i know of which is designed by compiler people
<whitequark> i'm not sure about ghidra, that might be good
<andlabs> and not the ad hoc nonsense of ... every other assembler
<superctr_> ida is nice since its fairly easy to make code that can be reassembled again, which is great for romhacks
<andlabs> my only complaint about ghidra is java
<superctr_> apparently that is not possible at all with ghidra, right now
<cr1901_modern> ghidra is promising as long as you're not doing something really stupid
<cr1901_modern> like trying to RE a dual DPMI and real mode DOS binary
<cr1901_modern> don't ask
<andlabs> superctr_: as long as your CPU module doesn't make mistakes like omitting (pc) for pc-relative addresses or something
<andlabs> [16:22:38] <cr1901_modern>ghidra is promising as long as you're not doing something really stupid
<andlabs> there's a politics joke here somewhere
<andlabs> [16:22:50] <cr1901_modern>like trying to RE a dual DPMI and real mode DOS binary
<andlabs> ah, so you are raymond chen
<superctr_> ghidra's decompiler is quite nice since it actually works very well even if the original assembly code was hand written
<andlabs> circa 1995
<cr1901_modern> I wanted to extract the horrible OPN2OPL emulation from Genecyst :P
<cr1901_modern> b/c I thought it would be funny
<cr1901_modern> But Ghidra choked on it and I didn't want it that badly
<superctr_> architectures with segmented memory is always a pain to disassemble
<superctr_> even with IDA...
<cr1901_modern> indeed. It's really to the point that it's prob just worth it to create my own one-off for that type of work
<whitequark> i wrote binja support for DOS executables
<whitequark> it should support segments reasonably well
<whitequark> the main thing is it doesn't support NE executables
<cr1901_modern> Oh, I didn't know you got the segment stuff working. That's cool
<whitequark> i think i tried to add it but couldn't find a coherent explanation of the format?
<cr1901_modern> Oh NE is Win16. Uhhh yea I wouldn't be surprised. IME, information on Win16 internals is pretty abysmally archived.
<whitequark> i would really prefer to not spend my time reverse engineering NE
<whitequark> like. yo know. just a preference
<cr1901_modern> Idk, I can't think of any past time more relaxing :3
<whitequark> ok then pls do it
<whitequark> and i'll add it to binja
* cr1901_modern grabs his copy of Peter Norton's Windows 3.1 Power Programming Techniques off the shelg
<Foone> I tried ghidra on a 16bit dos program recently. it definitely... tried.
<Foone> it ended up defining tons of segments, like hundreds. I'm pretty sure that's not how the program worked, but apparently static analysis for segmented architectures is not great
ej5 has joined ##yamahasynths
<cr1901_modern> There's a COM file I should try it on... I have an 8-bit/16-bit Ethernet ISA card that decided to go out to lunch; the packet driver claims the card doesn't exist. I should at least try to debug the card (no datasheet)
<cr1901_modern> and maybe I could get hints from the packet driver initializer
_whitelogger has joined ##yamahasynths
_whitelogger_ has joined ##yamahasynths
_whitelogger_ has joined ##yamahasynths
_whitelogger__ has joined ##yamahasynths
_whitelogger__ has joined ##yamahasynths
_whitelogger__ has joined ##yamahasynths
_whitelogger___ has joined ##yamahasynths
_whitelogger___ has joined ##yamahasynths
_whitelogger___ has joined ##yamahasynths
_whitelogger___ has joined ##yamahasynths
<cr1901_modern> It appears _whitelogger is reproducing
<cr1901_modern> It appears _whitelogger is reproducing
<cr1901_modern> It appears _whitelogger is reproducing
<cr1901_modern> It appears _whitelogger is reproducing
<whitequark> sigh
<whitequark> sigh
<whitequark> sigh
<whitequark> sigh
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger has joined ##yamahasynths
<TD-Linux> reminds me of how bdb copies glibc condvars directly into its database
<TD-Linux> this went really well for fedora when glibc updated the data structure
_whitelogger has joined ##yamahasynths