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
<Xyz_39808>
loggers are people too ;_;
<cr1901_modern>
well the logger isn't capable of discource I'm afraid :P
Xyz_39808 has quit [Ping timeout: 246 seconds]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 265 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 276 seconds]
andlabs has joined ##yamahasynths
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
ej5 has quit [Read error: Connection reset by peer]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<andlabs>
the commodore 1571 is larger than I thought it would be for some reason lol
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Lord_Nightmare>
re: the former tweet: are those the same weird 'minicassette' format used for dictation machines, and also for the save/load tapes on the fluke 9010? those drives are absolute shit, if so.
<Lord_Nightmare>
iirc its originally an hp format
<Lord_Nightmare>
and the players are absolutely terrible and break super easily and are apparently a massive pain in the ass to fix
<Lord_Nightmare>
the later microcassete format was a major improvement
<Lord_Nightmare>
re: the latter tweet: see #discferret or other channels regarding floppy imaging; i believe you're WAY better off using a means of imaging the diskette flux directly rather than using a 1541 or 1571
<Lord_Nightmare>
since that way you get index-aligned data
<Lord_Nightmare>
also has anyone ever done a comprehensive disassembly of the 154x/157x firmware and FINALLY tracked down and fixed that nasty bug with REL files which makes saving them after seeking backwards very broken?
<Lord_Nightmare>
it makes REL files pretty useless on c64, and people who needed actual relative file access ended up rolling their own formats and implementing them in software
<Lord_Nightmare>
i think commodore mostly but not completely fixed it in the 1581 but the fix was never backported
<Lord_Nightmare>
and isnt a complete fix either
<Lord_Nightmare>
i think a register is getting stomped somewhere unexpected due to the weird 'threading' stuff they're doing on the drive
<Lord_Nightmare>
and i think the REL bug has existed possibly since the dual-6502 PET IEEE GPIB drives' DOS versions
<Lord_Nightmare>
its a really old bug
andlabs has joined ##yamahasynths
<cr1901_modern>
andlabs: May wish to read the backlog of the last 30 mins :P
<Lord_Nightmare>
andlabs: i'll pm the logs if you want
Xyz_39808 has joined ##yamahasynths
<andlabs>
oh
<andlabs>
whitequark: please fix your ipv6
andlabs has quit [Ping timeout: 252 seconds]
andlabs has joined ##yamahasynths
<andlabs>
actually _whitelogger
<andlabs>
er
<andlabs>
whitequark: since your domain does not resolve in ipv6
<andlabs>
you could probably help me figure out why SO MANY domains don't
<whitequark>
uhh
<whitequark>
i actually don't have v6
<whitequark>
like the only native v6 i have is on that server
<andlabs>
ok
<andlabs>
do you at least know who is responsible for the DNS?
<andlabs>
you or someone else?
Xyz_39808 has quit [Ping timeout: 245 seconds]
<whitequark>
me
<andlabs>
ok
<andlabs>
I'll try again another day
<andlabs>
Lord_Nightmare: huh, I thought flux had nothing to do with GCR disks?
<andlabs>
also I'm still not familiar with the different file formats on a C64 disk
<andlabs>
will join discferret later
<andlabs>
I'll need the 1571 in any event since I intend on running the programs I'm dumping after I dump them
<Lord_Nightmare>
flux is the raw magnetic waves (usually but not always stored as discretized transitions with a time between when the wave is in one orientation vs the other)
<Lord_Nightmare>
figuring out when the transition has actually reversed is a complicated problem: see al kossow (@bitsavers)'s twitter, and his discussion with whitequark and cr1901_modern on twitter
<Lord_Nightmare>
there's several ways to convert analog flux to digital transitions, with a few different circuit methods used by various drives
<Lord_Nightmare>
some have advantages over others
<Lord_Nightmare>
and for really marginal disks, you may be better off actually ADC-sampling the flux from two of the drive test pins and doing the analog voodoo to get transitions out in software
<Lord_Nightmare>
that's what al is stuck doing, on some really valuable and damaged/decayed disks
<Lord_Nightmare>
i think whitequark's glasgow hardware is in theory capable of doing the same
<Lord_Nightmare>
though may require an external ADC chip
<whitequark>
yeah
<Lord_Nightmare>
those same two test pins i believe are used for getting the 'cats eye' graph on an oscilloscope when calibrating a drive
<whitequark>
have i ever told a story of how i misaligned a head on one of my drive?
<whitequark>
and then aligned it back without any cats eye disk or anything
<Lord_Nightmare>
i believe the cats eye pattern is created by a special drive which 'wobbles' the track at the correct offset point for a certain track number at a certain speed/mhz which is visible on an oscilloscope
<Lord_Nightmare>
not unlike the wobble tracks CDs use, but that's an entirely different story
<Lord_Nightmare>
whitequark: i know philpem managed to align a later FDS drive which doesn't have the alignment stud on it, doing some shenanigans
<Lord_Nightmare>
without a catseye mitsumi quick disk
<Lord_Nightmare>
the early FDS drives (and quick disk drives, we think) have a special stud on them for aligning the beginning of the spiral track
<Lord_Nightmare>
while the later ones don't have that and must have used a special disk or mechanical jig for doing the alignment
<Lord_Nightmare>
the drive must be realigned after replacing the belt (which always, ALWAYS fails eventually)
<whitequark>
Lord_Nightmare: i basically just bumped it and repeatedly read a normal floppy until i was happy with the error rate
<Lord_Nightmare>
i think that's exactly what philpem eventually did
<whitequark>
well, gross misalignment you can fix by looking at sectors
<Lord_Nightmare>
he had two drives, one of the older type and one newer
<Lord_Nightmare>
he aligned the older drive using the stud
<Lord_Nightmare>
then read a disk
<whitequark>
but if you look at a histogram of domain sizes, it is very obvious when it's centered and when not
<Lord_Nightmare>
then used that as a basis for what the newer drive should read and brute-force aligned it
<Lord_Nightmare>
quick disk drives are weird: I think they get away with having just one motor for both the spindle and the head armature: when it spins forward the disk head automatically travels inward at a certain rate, when it spins backward the head is reset to the beginning of the disk. I think that's how it works, at least.
<Lord_Nightmare>
i think you can also briefly spin it backward to 'seek back' a limited distance? I really need to recheck how quick disks work
<Lord_Nightmare>
you can't use a rubber band to fix a QD drive
<Lord_Nightmare>
and if the drive isn't realigned (his was NOT) he only read parts of 1 out of like 21 disks
<Lord_Nightmare>
the fds drive and the smith corona's quick disk drive use the SAME BELT
<Lord_Nightmare>
there are companies making repros for FDS drives, get one of those, they work
<Lord_Nightmare>
then you have to align the drive, which if your drive has an alignment stud, is not too hard
<Lord_Nightmare>
rubber band will make the head go way unstable and wobble all over the place and the disk will spin at a wildly inconsistent speed, i'm surprised he could read anything at all
<andlabs>
okay
<andlabs>
so the sense I'm getting is that I will always be way in over my head
<andlabs>
=P
<Lord_Nightmare>
please don't think that :(
<Lord_Nightmare>
this stuff seems complicated at first, but once you sort of 'get it' it all clicks together
<Lord_Nightmare>
it all boils down to you have an electromagnet on a stick with amplifiers on both ends of that coil
<Lord_Nightmare>
normally when reading flux, when one end of the coil gets a positive voltage the othr gets a negative voltage, they should be exactly 180 degrees out of phase
<Lord_Nightmare>
in reality, this isn't always the case, especially with decayed components in the amplifier circuits, and lowpass stuff to reject noise, etc
<Lord_Nightmare>
for bit transitions, the waves should be nearly a sine wave, smoothly changing from one state to the other, and you can use a threshhold with hysteresis approach (if the wave goes above 0.7 and we're 0, swithc to 1; if the wave goes below -0.7 and we're 1, switch to 0) or use a number of other approaches
<Lord_Nightmare>
as al kossow ran into, sometimes there's a 'knee' in the wave when descending or ascending, and if your detector is based on the derivative of the signal (i.e. how it slopes) you will get a pair of false transitions at the 'knee'
<Lord_Nightmare>
al is working on some software means of rejecting those to get the correct data out
<Lord_Nightmare>
andlabs: you're familiar with what the derivative and integral of a signal are, right?
<andlabs>
oh oops I should have clarified
<andlabs>
the *hardware requirements to make these dumps*
<andlabs>
will be something I likely mihg tnot be able to do
<andlabs>
but we'll see
<andlabs>
quit efrankly I am very interested in knowing how the actual physical representation of data on a magnetic disk is done
<Lord_Nightmare>
oh. i think al kossow is using a plain old saleae logic analyzer connected to the alignment test pins on two channels (4 wires)
<Lord_Nightmare>
that's really all you need, the rest is just software signal processing
<andlabs>
ok
<Lord_Nightmare>
whitequark uses an fpga based device she made called the 'glasgow' which allows some processing to be done inside the fpga itself
<andlabs>
and then there's the question of how I would take the decoded flux data and turn it back into something usable but that can wait =P
<andlabs>
as for the derivative and integral, I know what they are mathematically, not in a DSP sense
<Lord_Nightmare>
ah, now that gets into the fun bits of writing your own MFM or GCR decoder, and the joys of software PLLs and stuff
<andlabs>
my goal is I have several C64 disks i want to preserve
<andlabs>
some are previously undumped software, like Passport Master Tracks
<andlabs>
others are sealed copies of software and I want to make pristine copies
<Lord_Nightmare>
karsten schiebler's CWTOOL doesn't even use a pll at all, it uses buckets of how many samples since the last flux transition, which is an extremely naive system and very error prone, but is likely the simplest way
<andlabs>
because who knows what kind of self-modifying code exists in software
<Lord_Nightmare>
these buckets are set to different sizes/positions on a per-track basis
<Lord_Nightmare>
imho its a gigantic hack
<Lord_Nightmare>
but it (often) works
<andlabs>
not sure what a PLL is in this case
<Lord_Nightmare>
pll is a phase-locked loop
<andlabs>
oh yeah also I have a sealed NEC PC-8801 game too I want to dump for the same reason
<Lord_Nightmare>
its meant for aligning where the bit cells are supposed to be on the imaged track
<andlabs>
I have ZERO clue how that disk dat ais stored lol
<andlabs>
if I were to guess from the fact it's by NEC it's likely MFM but
<Lord_Nightmare>
pc-8801? if its on a 5.25 disk i think it may be FM on track 0, mfm on all other tracks
<Lord_Nightmare>
but maybe not
<Lord_Nightmare>
some of the nec stuff used 8" disks
<andlabs>
multiple formats? even better
<andlabs>
this is Kyuugyokuden by Tecnosoft
<Lord_Nightmare>
and iirc their 5.25 disks followed the same restriction where they would seek to a max of track 35 instead of maxing at track 40
<andlabs>
an early RPG
<andlabs>
the only thing known about it in English is that one of the songs from its sequel has a remix version hidden in Devil Crash MD/Dragon's Fury (Genesis)
<TD-Linux>
PC-8801 is the same as PC-98 afaik
<Lord_Nightmare>
the whole 'fm on track 0' thing was an idea started by IBM where their computers expected the boot track on the disk to be FM format but the rest didn't matter
<Lord_Nightmare>
that idea dates to 8" disks in the 70s
<Lord_Nightmare>
so the oldest ibm drives were FM on all tracks
<Lord_Nightmare>
and the newer ones could do MFM but the software was stupid and still expected FM on the first track
<Lord_Nightmare>
so they just left the first track that way rather than fixing the software
<andlabs>
oh that makes snese I guess
<andlabs>
why is IBM boot code always so weird lol
<andlabs>
anyway sorry for coming off as pessimistic, I'm just completely unprepared
<andlabs>
the misconception I had about flux being FM specific was from the fact Flux Engine doesn't yet support any GCR-based formats
<cr1901_modern>
GCR lets you do more horrific things by offloading reading part of disks to software. In IBM PC world, your options for doing horrific copy protection is limited
<cr1901_modern>
But yes, flux is universal to floppies :P
<andlabs>
hmm
<andlabs>
CWTOOL refers to the Catweasel controller
<andlabs>
I keep hearing about it
<andlabs>
why would I NOT want to us eit?
<Lord_Nightmare>
because the catweasel is no longer made, nor was the hardware very good
<Lord_Nightmare>
it has a critical flaw in it
<cr1901_modern>
discferret is the way to go IMO if you don't want to deal w/ Kyroflux
<Lord_Nightmare>
the 7 bit flux timing counter can overflow, and if it does it does so SILENTLY with NO WAY TO DETECT IT
<cr1901_modern>
and you don't want to deal w/ Kyroflux
<cr1901_modern>
they are... not nice ppl
<Lord_Nightmare>
i.e. RAMPANT DATA LOSS
<andlabs>
lol
<Lord_Nightmare>
and jens schoenfield, who made the catweasel, REFUSED to acknowledge that this was an issue
<andlabs>
yes, Kryoflux is SPS
<andlabs>
they are Not Good
<Lord_Nightmare>
and made fun of the people who reported it
<cr1901_modern>
SPS?
<andlabs>
oh even better
<Lord_Nightmare>
those people, from the CAPS project, renamed themselves to SPS and made a competing device called the kryoflux
<andlabs>
so Individual Computing as a whole is also bad
<Lord_Nightmare>
after jens shat on them
<andlabs>
oh so they're all bad!
<andlabs>
yay!
<Lord_Nightmare>
the SPS guys however are MALICIOUS
<Lord_Nightmare>
ask philpem about what they did to him
<cr1901_modern>
Floppy Disk Preservation Disk-Horse
<Lord_Nightmare>
also their license is insane
<Lord_Nightmare>
or was
<Lord_Nightmare>
it has a non-compete in it
<superctr>
sounds like they don't really care about preservation then
<Lord_Nightmare>
they care about making money
<Lord_Nightmare>
and locking museums into a $3000+-a-year license to use their DTC analyzer software, which is dongle-locked
<Lord_Nightmare>
and preventing said museums from using competing, open hardware
<Lord_Nightmare>
they've been incredibly successful
<Lord_Nightmare>
with dozens of museums 'locked in'
<andlabs>
they are the ROM equivalent of encasing your game cartridge in plexiglass
<Lord_Nightmare>
pretty much
<andlabs>
the Amiga community has only been driven to flat out open and blatant piracy as a result
<cr1901_modern>
And even then you need a lot of money to get involved in Amiga land
<Lord_Nightmare>
well, Sarayan reverse engineered SPS's IPF format after they dragged their feet for literal YEARS claiming they'd release an open spec
<andlabs>
retro was a mistake
<Lord_Nightmare>
and lo and behold, a week after he did so, the spec suddenly appeared! what a coincidence!
<andlabs>
there's a spec?
<Lord_Nightmare>
yes, there is a spec for the ipf format now
<andlabs>
I went ont heir website two weeks ago and there's nothing there now
<andlabs>
in fact I think they started a new format?
<andlabs>
which is exactlyt he kind of petty crap I expected
<andlabs>
sigh
balrog has quit [Ping timeout: 250 seconds]
<andlabs>
individual Computing and that jens guy likes to say that jani "never delivered" on the stuff for the C-One
<andlabs>
now I'm more inclined to believe that he didn't want to do the DTV
<Lord_Nightmare>
jeri and jens did not get along with the c-one
<Lord_Nightmare>
i think jens was the problem
<Lord_Nightmare>
also the c-one's fpga was a piece of shit
<andlabs>
well so much for me potentially buying anything from Individual
<Lord_Nightmare>
it needed an addon-board with a more powerful fpga just to do what it was originally specced to
<andlabs>
are there any good people
<Lord_Nightmare>
lft wrote a demo called 'parallelogram' for the fpga addon board ALONE
<Lord_Nightmare>
:P
<Lord_Nightmare>
yes there are: philpem, whitequark, most of the people in this channel
<Lord_Nightmare>
kevtris does commerical stuff now but he's a good person too
<Lord_Nightmare>
he can't share verilog/vhdl code but will happily answer questions if he has time
<Lord_Nightmare>
he also can't share certain 'trade secrets' like how the clock sync plls in the super NT work (which is sort of annoying for the TASBot guys)
<Lord_Nightmare>
(but its possible, with some effort, to reverse engineer that information)
balrog has joined ##yamahasynths
<andlabs>
sure but kevtris is also in the exclusive commercial games thing which I'm not 100% cool with either
<superctr>
normally i wouldn't really care about analogue products
<andlabs>
what is this about translate_off lol
<superctr>
but i don't like that they try to claim that FPGAs are not emulation
<cr1901_modern>
>but i don't like that they try to claim that FPGAs are not emulation
<cr1901_modern>
Let us PLEASE not open this can of worms.
<superctr>
so they're selling emulators to people who are sold thinking it is "accurate reproduction of real hardware"
<cr1901_modern>
I'm begging you
<cr1901_modern>
this convo never ends up going well and nobody agrees on it
* andlabs
traps cr1901_modern in a gust of mist...er
<andlabs>
>=P
<superctr>
hey, i love my DE10-nano board
<superctr>
and the mister project
<whitequark>
andlabs: some noise from the toolchain
<whitequark>
no longer present in master, even
<whitequark>
and was never relevant
<whitequark>
anyway, just in case someone doesn't know it yet, glasgow can interface a floppy drive directly, using only a crimped cable and two IDC connectors
<andlabs>
neat
<andlabs>
I'll ahve to figure out what I'll do in any event
<andlabs>
I do have a 1571 now
<andlabs>
and I will be using it *after* I make the dumps of these software to use these software, because why not
<andlabs>
if worst comes to worse I could use it *as* the drive mechanism
<whitequark>
whats 1571
<andlabs>
commodore 1571
<cr1901_modern>
Commodore disk drive
<andlabs>
disk drive released alongside the commodore 128
<andlabs>
dual-sided 5 1/4" that can read both GCR and MFM formats (because commodore 128 cp/m lol)
<andlabs>
hell it might support FM I'm not sure
<andlabs>
I know it supports commodore, osbourne, kaypro II, and kaypro IV formats at the least
<cr1901_modern>
The same physical disk can prob be used for all those formats, tbh
<cr1901_modern>
(not at the same time of course)
<whitequark>
does GCR use CAV or ZCAV?
<whitequark>
in this context
* cr1901_modern
doesn't know
<Lord_Nightmare>
ok: commodore 1541 uses ZCAV GCR by varying the data bit rate to 4 different rates depending on the track (and side, on the 1571? not sure)
<Lord_Nightmare>
the victor 9000 uses ZCAV GCR to approximate CLV by varying to one of (in theory) 16 different drive spindle speeds, controlled by a microcontroller
<Lord_Nightmare>
apple's 3.5 sony drive (and the 5.25 twiggy) approximate CLV using ZCAV by track as well, different numbers of sectors per track, and different data rates(spindle speeds?) by track/side. on the twiggy drive its very weird because the side A and B heads are aligned to the opposite disk edges from each other (an incredibly unreliable mechanism) which means one head is always the fast rate, and the other the slow one! this means if
<Lord_Nightmare>
you switch sides, you have to also change the motor speed?
<Lord_Nightmare>
i think the special apple upd765-derived custom drive controller used on the quadra 620av/840av only, used the drive spinning at a constant speed and did data rate magic instead? I'm not sure.
<Lord_Nightmare>
apple gcr shit is weird, they did it many different ways
<Lord_Nightmare>
on the apple diskII they use CAV, all tracks have the same number of sectors
<Lord_Nightmare>
on the twiggy 5.25 disk, they have a nonstandard track pitch (72(?) TPI instead of the usual 48 or 96tpi?) and the two heads on opposite tracks (so when one head is on track ?67? the other is on track 0), and the motor spindle speed can vary using the TACH pin
<Lord_Nightmare>
on the sony and mitsubishi apple 3.5" drive, the heads are on the same tracks, but they used zoned CAV (approximating CLV) based on the track number, different numbers of sectors and spindle speeds
<Lord_Nightmare>
i don't know of any floppy drives that used true CLV
<Lord_Nightmare>
but they may exist (the durango f85 uses a really weird gcr scheme that chuck guzis of sydex/teledisk fame himself designed)
<Lord_Nightmare>
as for disk controllers:
<Lord_Nightmare>
the apple2 used a prom-based state machine on the diskII card; later cards used the IWM which put an enhanced state machine in an ASIC, gcr-only
<Lord_Nightmare>
apple2c and IIgs used the IWM
<Lord_Nightmare>
the lisa used an i/o co-processor 6502 driving the IWM to handle the twiggy (and later, sony drive) stuff
<Lord_Nightmare>
the mac used an IWM for sony drive stuff
<Lord_Nightmare>
the mac SE FDHD and mac II FDHD and onward used an even more enhanced chip called the SWIM which could do both IWM/GCR stuff as well as MFM decoding; it would work with special 'superdrives' and there's a way to send some 'commands' to the drives via the motor phase bus to switch it into CAV-only mode so it no longer varies the spindle speed, for reading MFM disks
<andlabs>
now I'm starting to think merely reading flux is going to be insufficient to handle all disks ever
<Lord_Nightmare>
later macs used a chip called the SWIM2, which got rid of the IWM/GCR mode, since the devs at apple discovered that you can actually read GCR using the 'MFM' mode of the SWIM chip
<andlabs>
especially when we get to CLV vs CAV
<Lord_Nightmare>
as long as your PLL correctly locks to the bit-cells regardless of what speed the drive was supposed to be spinning at, you will be able to decode the data correctly
<Lord_Nightmare>
flux doesn't give a shit, if the drive was supposed to spin faster, then the spacing between the fluxes will be fewer samples long
<Lord_Nightmare>
flux doesn't care
<Lord_Nightmare>
the CAV vs ZCAV stuff can be dealt with in your decoder
ej5 has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
Xyz_39808 has quit [Read error: Connection reset by peer]