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
SceneCAT has quit [Read error: Connection reset by peer]
<cr1901_modern>
Sarayan: What does delta compression mean in the context of on-die ROMs (feel free to link me to an article so I can RTFM)
<cr1901_modern>
I never actually gave it much thought
* ej5
just ordered more Plaid Bib boards. these have a CPLD on them instead of the chips chip.
<cr1901_modern>
Excellent. Looking forward to a MicroChannel Rennaisance
<cr1901_modern>
Renaissance*
<ej5>
never got that model 95 working though. a ps/2 with a broken floppy interface is basically hamstrung.
<cr1901_modern>
They never made MCA floppy controller cards?
<ej5>
well sure but i think there were huge caveats
<ej5>
you'd need an ADF file to install it, and that required the reference disk with the main floppy drive :P
<cr1901_modern>
yea, the lightbulb in my head started to go off but you beat me to it
<ej5>
classic chicken and egg problem.
<cr1901_modern>
err turn on*
<cr1901_modern>
I wonder if ADF files were the reason that even ISA-based PS/2 machines required you to boot a floppy to change BIOS settings
<cr1901_modern>
Oh, I know a good project to do... a Dallas Co- err, Clock Module replacement
<ej5>
more or less. i think they cheaped out and didn't want to have a huge ROM
<cr1901_modern>
since the one in my PS/2 is prob dead
<ej5>
the PS/2 would have been amazing if they had a nice big battery backed SRAM and a larger ROM
<ej5>
you'd still need a setup disk to configure any new card, but you wouldn't need a reference disk
<ej5>
the industry just went ISA PnP and PCI which offloaded most of the configuration to the operating system
<cr1901_modern>
I can certainly appreciate your affection for MCA
<ej5>
hmm, in theory you could have built the ADF files into the cards themselves, then no floppies would have been erquired.
<ej5>
it's a neat idea with a nasty achilles heel
<cr1901_modern>
oh really? Does MCA mandate the contents of ADF files be stored at specific offsets in memory
<cr1901_modern>
(like PCI conf space?)
<ej5>
ADF files are just like an INI file. they just specify which bits in the POS bytes correspond with which jumper configurations
<cr1901_modern>
POS?
<ej5>
could be IO addresses, IRQs, memory address, DMA, etc
<ej5>
programmable option select
<ej5>
you get a couple of 8-bit registers that the BIOS can control, and they directly replace the function of the card jumpers
<cr1901_modern>
ahhh
<ej5>
for example, instead of an IRQ3/5/7 jumper, you'd have two POS bits that would encode that. and it was entirely up to the mfg.
<ej5>
the ADF file told the bios which bits encoded to which interrupt settings
<cr1901_modern>
and presumably those bits get fed to some I/O decoder chip that can at runtime change what addresses it accepts
<ej5>
correct
<ej5>
so the reference disk looked at all the ADFs required by the system and ran a little algorithm which figured out which combinations of IRQ would work
<ej5>
then it wrote the raw binary values of the POS registers into the battery backed SRAM
<ej5>
when you switched on the system, the BIOS would just copy all those over to each card, then turn on the enable bit for the cards
<ej5>
(one bit of a POS register was reserved for a card enable bit)
<cr1901_modern>
so you think PS/2s needed beefier SRAMs?
<cr1901_modern>
to allow more card configs to be saved?
<ej5>
first off, they'd need a larger BIOS ROM to incorporate the setup program
<ej5>
second, each card should have had a binary equivalent to the ADF file located in an on-board memory
<ej5>
thinking about it more, a larger SRAM is not strictly necessary
<ej5>
then the experience of installing a card goes like 1) put in the card 2) power up 3) BIOS says 'oh hai i see the new card! configured! done!'
<ej5>
no floppy swapping, no reference disk to keep around.
<Lord_Nightmare>
this is where openfirmware was a massive improvement over the old BIOS system
<cr1901_modern>
Lord_Nightmare: Chunks of openfirmware made it into devicetree
<Lord_Nightmare>
openfirmware allowed cards to provide little Forth code snippets, platform-agnostic, to allow the "bios" to initialize the cards and test them
<cr1901_modern>
(just not the Forth interpreter :(...)
<Lord_Nightmare>
and the os could technically use the forth drivers to drive the cards too though its probably incredibly slow
<ej5>
interesting
<Lord_Nightmare>
UEFI on the other hand seems to be a step backwards, its basically "a 32 bit os whose sole purpose is to boot the rest of the system and to implement various DRM"
<cr1901_modern>
I didn't know that re: openfirmware. That's pretty cool to have platform-agnostic bytecode for initialization
<ej5>
yeah UEFI is also an interesting idea but terrifying in implementation
<Lord_Nightmare>
and even the spec had some really bad bugs in it
<ej5>
i struggled hard to get a dual boot windows/linux on a UEFI system
<Lord_Nightmare>
as did the reference implementation
<Lord_Nightmare>
for instance, every time the boot on uefi fails, the system reserves another 256k(?) of ram
<Lord_Nightmare>
incorrectly assuming that the uefi crashed/failed to boot due to not enough ram
<ej5>
there's a windows utility that you use to work with UEFI disk partitions. what microsoft doesn't tell you is that the command to "view" the contents of that partition *silently modifies it*
<Lord_Nightmare>
and this is FOREVER
<Lord_Nightmare>
unless you use a uefi utility from os-space to force-clear the reserved ram variable
<ej5>
iirc that UEFI partition is formatted as FAT32.
<cr1901_modern>
>for instance, every time the boot on uefi fails, the system reserves another 256k(?) of ram
<cr1901_modern>
Yikes...
<Lord_Nightmare>
the whole mess with EFI booting and windows BCDedit and crap
<Lord_Nightmare>
cr1901_modern: as soon as intel was told about that bug they fixed it in the uefi spec as an errata and in the reference uefi implementation i think
<cr1901_modern>
ahhh well then nevermind
<Lord_Nightmare>
so now its required that if the uefi resets to default settings in the "bios-alike" uefi setup menu
<Lord_Nightmare>
i think its required to reset the reserved ram too
<Lord_Nightmare>
but it used to not be required
<ej5>
yeah it's coming back to me. using bcdedit /enum actually silently changes the BCD!
<Lord_Nightmare>
i have a win10 system which won't boot due to corrupted BCD table, and a very nonstandard disk arrangement
<ej5>
ugh
<Lord_Nightmare>
i remember it taking a number of hours to set up last time
<Lord_Nightmare>
and i don't have a saved copy of the config
<Lord_Nightmare>
i can acces the files on the two partitions one on an ssd and one on an hdd
<Lord_Nightmare>
but i can't make the system boot
<Lord_Nightmare>
the disk is set up using an old mbr partition, not uefi
<Lord_Nightmare>
and not one of those weird 'mixed mbr-uefi' things where you have a duplicate partition table both in mbr and gpt format
<Lord_Nightmare>
in adjacent sectors
<cr1901_modern>
Last time I tried using an mbr disk in a uefi system, uefi immediately rejected it
<Lord_Nightmare>
this is in an old dell optiplex 990
<cr1901_modern>
and I really couldn't be arsed to debug
<Lord_Nightmare>
the uefi is... spotty
<Lord_Nightmare>
its an earlier uefi system
<Lord_Nightmare>
it works ok in mbr mode though
<Lord_Nightmare>
as much as i dislike uefi, openfirmware was not all unicorns and rainbows either, there were some design stupidities in the way you had to pass around forth variables, and there were holes in the spec about whether the forth 'data stacks' are preserved between openfirmware calls or not
<Lord_Nightmare>
apple's implementation relies on the stacks being preserved, while the sun implementation doesn't preserve them, which means attempting to run the forth code from a g4 mac on sun's openfirmware implementation usually results in crashes and tears
<Lord_Nightmare>
unless you wrap all the commands which affect the data stack so the stack gets preserved manually and restored afterward
<cr1901_modern>
hrm :/
<Lord_Nightmare>
i think segher worked on a project to do this
<Lord_Nightmare>
openfirmware i think was the right idea, but needed a design iteration, a sort of 'openfirmware 2.0' to fix many of the warts and tighten up the spec
<Lord_Nightmare>
instead, efi/uefi happened, and then the ieee spec for openfirmware got withdrawn
<TD-Linux>
cr1901_modern, I dunno, I appreciate that devicetree and dt overlays are declarative only. otherwise it's kind of weird to have half the driver as proprietary bytecode
<ej5>
it's a bit of a security hole though, imagine malicious forth on a doctored card.
<Lord_Nightmare>
ej5: the olpc laptop project bolted on security/signatures on top of/as part of openfirmware
<Lord_Nightmare>
i don't see why this wouldn't have been part of an openfirmware 2.0 spec
<cr1901_modern>
TD-Linux: Tbh, I have no real opinion on the Forth interpreter's utility. I just thought it was sad it got cut :P.
<Lord_Nightmare>
to prevent malicious bytecode like that
<cr1901_modern>
the devicetree spec says openfirmware is heavy inspiration
<TD-Linux>
yeah devicetree is basically openfirmware 2.0
<TD-Linux>
rpi hats have devicetree overlays on an eeprom
<ej5>
true
<cr1901_modern>
I don't remember how overlays like that work... are they appended to an existing tree at a compatible node?
<cr1901_modern>
(existing tree == the .dtb the kernel sees)
<Lord_Nightmare>
nukeykt: can i send that pic to digshadow to see if he's willing to re-image that chip?
<nukeykt>
of course, that would be great
<andlabs>
oops I gave in and bought a Yamaha CX-5M
<andlabs>
now I just need to figure out what monitor cable to use
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
ej5 has quit [Read error: Connection reset by peer]
ej5 has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
SceneCAT has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 260 seconds]
Xyz_39808 has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 268 seconds]
Xyz_39808 has quit [Read error: Connection reset by peer]
Xyz_39808 has joined ##yamahasynths
andlabs has joined ##yamahasynths
nukeykt has quit [Remote host closed the connection]
andlabs has quit [Ping timeout: 240 seconds]
andlabs has joined ##yamahasynths
<Lord_Nightmare>
nukeykt: the fhb018 (ym2413b?) die probably does NOT use implant rom, or if it does, its affecting the color of the silicon enough to not need delayering
<Lord_Nightmare>
i'm hoping whitequark can get the ym2413 non-b chip i sent decapped soon, since that will tell us what changed between the nmos and cmos versions
andlabs has quit [Read error: Connection reset by peer]
andlabs has joined ##yamahasynths
<whitequark>
fwiw i noticed these conversations
<whitequark>
unfortunately i've been too fatigued the last two weeks to do... well, pretty much anything at all of use
<Sarayan>
Hey, hi wq
<Sarayan>
the ym2413b has instruments?
<Sarayan>
ah yeah, the fhb018 has instruments, but there's not at all readable without delayering, and I suspect no even with
<Lord_Nightmare>
and you can't see it for many of the bits
<Lord_Nightmare>
a higher res dieshot might show them better, but it may be tough to find the exact microscope angle/focus/illumination to make them visible like that again
<Lord_Nightmare>
much easier to stain them, if they're implant
<Sarayan>
you realize the top part is probably ram, right?
<Lord_Nightmare>
though knowing more in the last 6 years, that image could very well be wrong
<Sarayan>
I find the red/non red dubious because the same stuff is in the oscillator roms and it doesn't see to match what they know of their contents
<Sarayan>
but icbw
<Sarayan>
ohhh, you'd say the instrument select is vertical, and the bits horizontal
<Sarayan>
ok, that makes a lot of sense, and yeah, the ram on the side works well that way
<Sarayan>
are there 21 instruments?
<Sarayan>
yeah, 16+5
* Sarayan
bows
<Lord_Nightmare>
each vertical column is one instrument, and the horizontal rows are for bits within each parameter
<cr1901_modern>
wonder how long it took nuke to type out all the instrument rom values. I'm not able to (easily) extract ROM contents without doing vectorization first, but he doesn't vectorize unless he has to
<cr1901_modern>
whitequark: Take all the time you need :). I totally get fatigue
<Lord_Nightmare>
its barely visible at all
<Lord_Nightmare>
i think we need better images or staining before making any determinations about accuracy from the decap