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
<ej5>
nope, just checking in
<cr1901_modern>
Regardless of how long it takes, I promise not to look at the firmware blob or disassembly
<andlabs>
balrog: well it can
<andlabs>
but as written my program only natively supprots AES-128-ECB
<andlabs>
there are other possible schemes
<andlabs>
AES-{128,256}-{ECB,CBC,XCB}
<andlabs>
to identify which one is being used requires either trial and error OR vendor-specific ATA requests
<andlabs>
(and if you're on macOS that means you only have trial and error as an option, because on macOS the kernel prevents you from making any vendor-specific ATA requests other than SMART requests unless you're a kernel extension)
<andlabs>
(and no, that's not a recent restriction)
<andlabs>
(on windows and most other unix systems it's just an ioctl() (DeviceIoControl() on Windows); on plan 9 you can do this by writing directly to a /dev file!)
<cr1901_modern>
We do not discuss plan 9 here :P
<cr1901_modern>
(Actually, feel free to discuss Plan 9 here.)
<andlabs>
so remember that site that was selling the YM2608s a few months ago?
<andlabs>
they're now selling a bunch of ... these
<andlabs>
whatever they are
<andlabs>
or more precisely, YSS205B-F
<cr1901_modern>
I've never heard of this one until now ._.
<cr1901_modern>
I'll have to read the datasheet, why would you need an ASIC dedicated to Karaoke (as opposed to "use an MCU")?
<andlabs>
I'm still not entirely sure what this does or how it's intended to be used
<superctr>
it's a DSP with a few effects appropriate for karaoke
<superctr>
possibly it could be decapped and the mask ROM dumped and emulated
<superctr>
but the DSP architecture might either be some funny custom thing or based on an existing yamaha architecture that has already been reverse engineered
SceneCAT has quit [Quit: *Mreow*]
SceneCAT has joined ##yamahasynths
<andlabs>
ah
<andlabs>
well I started looking into getting the parts needed for either a glasgow or a fluxengine for dumping dfloppies
<andlabs>
that is, the drives themselves
<andlabs>
and according to vogons, double density 80-track 5.25" drives like the TEAC FD-55GFR do not support single-density disks very well?????
<andlabs>
*vogons wiki
<andlabs>
although it isn't very clear (and also has some redlinked articles which is always useful)
<andlabs>
also I can't tell if the same ribbon cable can be used with both 5.35 and 3.5 dirves
<andlabs>
currently looking at a 3.5 drive that will come wiht its own cable
<andlabs>
and I'm also wondering how compatibility will work with these in mind
<andlabs>
will newer 1.44mb drives from like 1987 or so not read the earliest 3.5" diskettes?
<andlabs>
and how is it that a PC floppy drive can read GCR-encoded disks anyway
<andlabs>
also the fluxengine build page says I'm going ton eed a PC power supply and I wonder if any modern ones even come with the necessary power connections or not
<andlabs>
with USB having too high of a current for a 3.5" drive I bet a resistor will suffice instead
<Lord_Nightmare>
andlabs: the teac fd55gfr has issues with 40 track disks only because its head is narrow enough that some 40 track disks (since they were recorded with a wider head) will have issues reading on the two 'half tracks' since it doesn't necessarily have a clean signal the whole width of the track
<Lord_Nightmare>
also writing 40 track disks in an 80 track drive might not be very reliable due to the narrower head
<Lord_Nightmare>
or at least, I BELIEVE that's the cause of the issues
<Lord_Nightmare>
teac did make 40 track drives (the fd55A and B?) and also made 80 track double density drives (a format that the pc didn't officially support?)
<whitequark>
andlabs: ribbon cable: the connector for 5.25" and 3.5" floppy is different, but there are cables compatible with both
<whitequark>
PC floppy drive: the floppy drive cares very little about the actual data. all it needs is for magnetic domain size to stay within certain bounds. as long as that is true, the rest depends solely on the controller
<whitequark>
and since glasgow records magnetic domain boundaries rather than decoding the data in any way, it doesn't really care for the format either
<whitequark>
re power: I'm confused by your statement. did you swap "USB" and "3.5" drive" there?
<whitequark>
modern power supplies do still come with the connector since other devices piggyback on it, but it might be starting to disappear slowly. that is not to despair, most 3.5" floppy drives use only 5V (never seen one that used 12V) and the connector accepts normal jumper cables of the kind you'd use on a breadboard
<Lord_Nightmare>
cr1901_modern: so the original 765 it works, but the intel 765 clones it doesn't?
<Lord_Nightmare>
what about wd1771 and wd1772?
<cr1901_modern>
It better work on the original 765 ._.
<cr1901_modern>
ditto on wd177*
<cr1901_modern>
(Is sarayan on vacation?)
<andlabs>
Lord_Nightmare: yeah that makes sense
<andlabs>
whitequark: ah, ok, and the controller is on the motherboard of the computer itself
<andlabs>
(or an expansion card, but still, not part of the drive)
<whitequark>
yes
<andlabs>
ad for power:
<andlabs>
http://cowlark.com/fluxengine/doc/building.html "A suitable power supply. 3.5” floppy drives use 5V at about an amp (usually less) — sadly, too much to power from USB. 5.25” floppy drives also require 12V. An old but decent quality PC power supply is ideal, as it’ll frequently come with the right connectors."
<andlabs>
well yes I did swap those and a resistor isn't going to work
<andlabs>
oops
<andlabs>
I still haven't read the equivalent document for glasgow
<andlabs>
and this document implies that all you need is "a" ribbon cable "with a twist", so I don't know what 5.25 cables actually lok like
<andlabs>
should probably find the glasgow-specific documentt hough
<whitequark>
glasgow unfortunately doesn't have such a straightforward document since it's not so single purpose
<whitequark>
here's the description of the required cable
<whitequark>
it doesn't matter whether the cable has a twist or which way your drives are jumpered for
Xyz_39808 has joined ##yamahasynths
<whitequark>
really you don't even need a cable, you can connect individual pins with jumper wires, that works just fine. the cable is mostly for convenience with 3.5" drives
Xyz39808 has quit [Ping timeout: 260 seconds]
<cr1901_modern>
Why doesn't the twist mat- *checks code*- ohhh, I see.
<cr1901_modern>
That's certainly one way to do it :)
<andlabs>
the fluxengine page links to a (sigh) nostalgia nerd article explaining the twist
<andlabs>
(despite enjoying the cyrix video I don't know if I can trust nostaliga nerd yet)
<andlabs>
I ask about this because that amiga thing Lord_Nightmare linked the other day requires you to un-twist the cable
<Lord_Nightmare>
i assume that means it wants drive B instead of A
<andlabs>
whitequark: and that's fine; I'm mainly just trying to figure out what I need to buy before I take either opiton =P
<Lord_Nightmare>
that's what the cable twist on the floppy drive does
<Lord_Nightmare>
it switches drivesel1/motoron0 with drivesel0/motoron1
<andlabs>
I did already sign up to your waiting list for glasgow boards though
<cr1901_modern>
>Okay, so you can put 2 drives on a single cable, but can you add a third drive to the cable? Yes, you can. You'll note that pins 4 and 6 aren't used on the PC side, so they can be re-assigned to the "motor on" and "drive select" signal for a third drive.
<cr1901_modern>
I wonder how this works for the external floppies on the original IBM PC floppy controller
<cr1901_modern>
(TODO: Check the schematic)
<andlabs>
well the PC BIOS calls for drive access use "nth floppy drive" instead of "nth overall drive"
<andlabs>
one DOS virus made this mistake so it ineffectually tries to wipe your third floppy drive instead of your hard drive
<cr1901_modern>
hard drives start at 0x80
<cr1901_modern>
so indeed drive 0x02 would be the third floppy
<andlabs>
[14:43:57] <whitequark>glasgow unfortunately doesn't have such a straightforward document since it's not so single purpose
<andlabs>
and yeah that makes sense, but I can imagine a series of tutorial pages where one of them would be along these lines
<andlabs>
the modern day ultra-nerd equivalent of those elctronics hobby ideas but with your microcomputer books from the 80s
<whitequark>
andlabs: true but you're the first person besides me to even plan to use this applet...
<whitequark>
a few have expressed interest but in theoretical ways
balrog has quit [Quit: Bye]
balrog has joined ##yamahasynths
<andlabs>
ah heh
<andlabs>
well I've got some sealed PC software that I want to dump
<andlabs>
and already have started compiling Amiga software to dump
<andlabs>
mostly music programs
<andlabs>
and also in the event that even .nib files aren't enough, C64 disks
<andlabs>
I do intend on dumping the Amiga programs
<andlabs>
also a rarity — a sealed MSX disk game!
<andlabs>
Ys III specifically
<andlabs>
and even rarer, a sealed NEC PC-88 game — Tecnosoft's Kyuugyokuden
<andlabs>
I imagine this'll be the first dump of a sealed PC-88 game... ever
<andlabs>
even including those elusive japanese ROM trading compilations
<whitequark>
'sealed'?
<andlabs>
and yes dumping a never opened floppy disk before running it for the first time is a big deal to me, especially after I confirmed that yes, there is at least one game (Electronic Arts's Starflight) that does indeed make heavy use of self-modifying code on the disc itself (not for protection, but as a cost-cutting measure)
<whitequark>
oh
<whitequark>
fascinating
<whitequark>
so, some more things you should know about glasgow
<andlabs>
that being said I am not that picky about what I'm dumping — I can't be, given how rare some ofthese disks are
<andlabs>
I have a complete set of the elusive Sequential MusicMate utility disks
<whitequark>
the hardware/gateware itself for the floppy applet is something i have a lot of confidence in. it's very simple, i've used it a lot and the only issue you might encounter is your PC somehow being too slow to drain the buffers (the hardware only has a few KB of buffers) in which case you run it again
<andlabs>
I will be dumping and releasing those with the zoomfloppy, but first, I have to do two things: 1) scan the accompanying materials, 2) write up both a C64 and a [redacted to avoid being sniped] program that can actually use the peripheral
<andlabs>
everything will be done simultaneously
<whitequark>
the dumps you get are essentially bitstreams from a 48 MHz logic analyzer for each head and cylinder
<andlabs>
ah, neat
<andlabs>
that shouldn't be too much of a problem on this thing
<andlabs>
System Information: Model: MacBook Pro (15-inch, Mid-2012) • CPU: Intel Core i7-3615QM (8 Threads, 4 Cores) @ 2.30 GHz • Memory: 16.00 GB • Uptime: 13 days • Disk Space: 2.00 TB • Graphics: Intel HD Graphics 4000, NVIDIA GeForce GT 650M • Display Resolution: 1440 x 900 • OS: macOS Sierra (Version 10.12.6, Build 16G2136)
<andlabs>
hopefully
<whitequark>
should be more than enough
<andlabs>
if not I could probably get a second prottotyping board dedicated to the task
<andlabs>
(the disk is an SSD too)
<whitequark>
the software that analyzes the dumps was written with research in mind: easy to tweak and adjust for e.g. different formats, rotation speed issues, and so on. it works pretty well on PC floppies although i think mature demodulators can beat it in some cases. it doesn't do non-PC floppies currently at all.
<whitequark>
one thing it is not is fast. think ten minutes to turn a bitstream into an image file. i was kinda thinking i could redo it to be faster but ... no interest, never happened sofar
<Lord_Nightmare>
so it reads the whole disk first, then converts to an image file afterward?
<Lord_Nightmare>
can it make a list of tracks to re-read during the image file conversion if it finds anomalies/errors, then automatically seek to and re-read just those tracks?
<whitequark>
it does let you do nifty things like realign the heads using nothing but an ordinary floppy, or debug physical media issues like messed up rotation speed or wrong density or see which parts of a track are physically corrupted and how
<whitequark>
Lord_Nightmare: not currently, no. if people are actually going to use it i'm going to rewrite it so that it decodes the data on the fly on the FPGA using the same algorithms and streams *both* the bitstream *and* the sector data to the PC
<whitequark>
which makes it possible for the PC to make whatever decisions you want in realtime in response to the actual decoded sector data coming from the disk