cr1901 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://libera.irclog.whitequark.org/~h~yamahasynths
cr1901_ is now known as cr1901
cr1901 has quit [Remote host closed the connection]
<andlabs_>
"porting the greaseweazle / fluxengine firmware to Arduino so that it is less tied to specific hardware. this is important as, during 2021 we learned that silicon shortages can make specific chips extremely difficult to find - having a cross-platform firmware alleviates dependancies on specific chips."
<andlabs_>
I mean they have a point
<andlabs_>
"adding hardware support for reading apple ii disks. many flux readers focus on 34-pin disk drives but do not have interfacing for apple disk ii drives. the drives are available and could be used for archiving a vast number of floppies out there! this will require adding an index sensor so we can image disks into 'woz' formats. currently, applesauce hardware and software can do this for apple ii disks - applesauce is amazing and an excellent
<andlabs_>
tool and we recommend it to folks! at this time, it appears to be closed source hardware, firmware and software, so we are not able to integrate their design into an open source design."
<andlabs_>
so wait can normal drives not be used for this already
<andlabs_>
I figured I could stick any 5.25" disk into anything connected to a greaseweazle and get a flux dump; don't all drives for some reason use the same low level flux format?
<andlabs_>
the curse of shugart
<andlabs_>
(this does not actually do flux yet, btw)
<Sarayan>
it's interesting that the pico can communicate with the floppy and not have anything blow up with voltages. I guess they power separately, but that's normal
<Sarayan>
flux is not a format btw, it's just that the drive communicates when the magnetic flux changes. There are two protocols, the standard one (~1us pulse on each change, shorter with HD/ED floppies probably) and apple (invert the line on each change)
<andlabs_>
right
<andlabs_>
I was just imagining some sort o funiversal format-agnostic physical layer type thing here
<andlabs_>
how is the change encoded over area
<andlabs_>
I'm still surprised that it seems every disk drive does it the same way
<Sarayan>
oh, it is format-agnostic, because there are two formats: before ED the magnetic flux goes either in the direction of rotation or backwards, and for ED it's towards the platter or to the outside (so-called perpendicular recording)
<Sarayan>
but that's defined by the floppy itself more than the drive, and floppies are supposed to work in any drive (and drives to work with any floppy)
<Sarayan>
and then on top of the flux you have the encodings (mfm/fm/gcr/m2fm/other insane things), on top of that you have the formats (headers, sectors, etc) and on top the filesystems
<Sarayan>
layered layers :-)
<Sarayan>
formats and encodings go hand-in-hand, but you have multiple formats for the same encoding (f.i. amiga and pc are both mfm with totally different formats)
<Sarayan>
ibm's fm and mfm-based standard formats as implemented with the upd765 and wd chips are most of what was actually used though
<andlabs_>
yeah
<andlabs_>
so I wonder what makes apple disks hard to rip at a low format-agnostic level
<andlabs_>
but good to know, thanks
<Sarayan>
andlabs: apple disks are no harder that any other, but the truth is that they are all hard
<Sarayan>
the trick is, the signal you get is not directly what's on the floppy. There are rotational speed varations (high and low frequency), there are parasite flux transitions that don't exist, there are transitions that are filtered out... so you can't just do one floppy rotation and say it's good, and when you do multiple you have to align them and that's nontrivial
<Sarayan>
some protections rely on the fact that for in some (well-known by now) cases you'll get different results on multiple passes
<Sarayan>
so "resolving" the flux read into what's really on the disk (which is what does applesauce and others) is not at all trivial and uses knowledge at multiple levels (hence why they tend to be format-specific)
cr1901 has quit [Remote host closed the connection]
cr1901 has joined ##yamahasynths
<andlabs_>
ah
<andlabs_>
ok
<andlabs_>
I guess I have too much to learn then =P
<tunixman>
oh yeah it's pretty wild. There's an article somewhere with traces from a modern hard drive head compared with the idealized waveform, and they're definitely not the same.
<tunixman>
well, not visually anyway, obviously.
<Lord_Nightmare>
the code i wrote for handling .dfi images in MAME (which are roughly equivalent to applesauce .a2r flux images) is a massive gross hack and I really should remove it
<qu1j0t3>
just add some self deprecating comments
<qu1j0t3>
/** GROSS HACK.. DO NOT USE THIS.. DO NOT EVEN READ THIS **/
<qu1j0t3>
/** Sorry sorry ,I am trying; to delet it*/
<tunixman>
/** There used to be dragons here but now there's just this. */
<qu1j0t3>
/* At least it scared the dragons off. */
<tunixman>
/** Durin's bane? This code defeated it with this one weird trick. */
<Sarayan>
/* It was failure that or 10k lines or code, I chose failure */
<tunixman>
I'm slowly introducing the interns to things like "five star programmer".
<Sarayan>
s/that//
<NiGHTS>
Correction: <Sarayan> /* It was failure or 10k lines or code, I chose failure */
<Sarayan>
s/ / /
<NiGHTS>
Correction: <Sarayan> the trick is, the signal you get is not directly what's on the floppy. There are rotational speed varations (high and low frequency), there are parasite flux transitions that don't exist, there are transitions that are filtered out... so you can't just do one floppy rotation and say it's good, and when you do multiple you have to align them and that's nontrivial
<Sarayan>
mwahahhaa
<tunixman>
/** you can't have success without lots of failures. I'm now successful. Thank you. */
<Sarayan>
you can't correct the correction
<tunixman>
hahaha!
<tunixman>
oh I bet it matches the username too.
<tunixman>
hm. let's see.
<tunixman>
correction: hello
<tunixman>
s/hello/no/
<NiGHTS>
Correction: <tunixman> correction: no
<tunixman>
well not that way.
<Sarayan>
s/not/yes/
<NiGHTS>
Correction: <Sarayan> so "resolving" the flux read into what's really on the disk (which is what does applesauce and others) is yes at all trivial and uses knowledge at multiple levels (hence why they tend to be format-specific)
<Sarayan>
yep, matches username
<Sarayan>
I wonder
<Sarayan>
s/that //
<tunixman>
how many synth dudes does it take to reverse engineer some open source bot we probably have code for.
<NiGHTS>
Correction: <Sarayan> /* It was failure or 10k lines or code, I chose failure */
<Sarayan>
well, first line that matches the pattern from the name user
<Sarayan>
s/name/same/\
<Sarayan>
s/name/same/
<NiGHTS>
Correction: <Sarayan> s/same/same/\
<Sarayan>
MWAHAHAHAHAHA
<tunixman>
nailed it dot jif
<Sarayan>
indeed
<andlabs_>
I like the comment that used to be in the code for the GTK+ combobox control
<andlabs_>
/* WELCOME, to THE house of evil code */
<tunixman>
hahaha
<tunixman>
I once had to explain to some random ISO 9k dude how it was "f*ck me gently with a chainsaw" wound up in a commit to our kernel fork.
<andlabs_>
nice
<tunixman>
I think it's now part of traffic light controllers everywhere in the US and maybe parts of Oz and the EU.
<tunixman>
well, obviously the comments are skipped by the preprocessor, but if you download the source archives you'll likely find it. I'm sure they haven't upgraded out of the 2.6 range.
<andlabs_>
sweet
<andlabs_>
also: open source traffic infrastructure =p
<tunixman>
well, let's not go too far with this.
<tunixman>
the os is, but the rest of the software, well, it's... well it has issues.
<andlabs_>
also in re MAME dfi handling
<andlabs_>
I keep forgetting MAME actually has code for all the weirdo floppy disk file formats
<andlabs_>
or at least many of them
<andlabs_>
not sure about some of the other bizarre japanese ones
<andlabs_>
ideally we shouldn't have to tether ourselves to the Two Very Specific Closed-Source Programs that I don't even know if they still are available on japanese file sharing sites anymore
<tunixman>
with the right disassembler everything is open source.
<tunixman>
speaking of I just stumbled into an article titled "Reverse Disassembly". Isn't that just an assembler?
<qu1j0t3>
idk you tell us :)
<tunixman>
hahah fair...
<Lord_Nightmare>
.dfi ironically is not closed source at all
<Lord_Nightmare>
its fully open source, from the discferret project, fully open including pcb gerbers etc
<Lord_Nightmare>
.a2r the applesauce project IS closed source but the spec is open, and the author is willing to share code/definitions/etc if asked nicely and for good reason
<Lord_Nightmare>
(not the whole source code obviously, but if there's specific things you'd need you can ask him)
<tunixman>
oooh, discferret looks super cool!
<Lord_Nightmare>
if you want to build one, iirc it uses an EOL fpga, so it will require some modification to use a more available part unless you want to find a used fpga for it
<Lord_Nightmare>
you want to talk to philpem, see #discferret ... except he isn't in there right now. he is on discord though
<Sarayan>
honestly, the hardware part is the easy one, you can do it with anything fast enough
<Sarayan>
I mean, highest signal frequency is 2MHz, and that's with a ED drive nobody has :-)
<qu1j0t3>
/b 7
<tunixman>
2MHz, hm, you could almost do that bitbanging on a 65xx.
<cr1901>
Need at least twice the highest signal frequency. On the IBM PC floppy controller, a 4MHz clock is used for a 512kHz write clock
<cr1901>
Sarayan: cr1901cc -pedantic, but... isn't the highest signal frequency 1MHz for ED, because a 2MHz write clock and a maximum of one transition per bit cell, and two write clocks per bit cell?
<tunixman>
oh yeah, that's right.
<tunixman>
hahaha cr1901cc -pedantic made me think I had the wrong term up.
<Sarayan>
cr1901: only if you have an edge detector with timing handy, otherwise you need to observe both the 1 and the 0
<Sarayan>
in any case it's nowhere near what is considered high frequency nowadays
<cr1901>
Indeed, tho the repo I linked runs the micros at 180MHz and 200MHz
* cr1901
remembers when 150MHz was considered very high for microcontrollers
<tunixman>
you mean it isn't now?
<cr1901>
STM32H7 goes up to 400MHz I think
<cr1901>
But yes, I think 150MHz is a very high clock speed personally
<tunixman>
oh yeah cortex, of course.
<tunixman>
if I can't whistle it into a pots line I get uncomfortable.
<Sarayan>
the integrated dual-core arm in the cyclonev is 800Mhz
<qu1j0t3>
cr1901: unethically fast
<qu1j0t3>
cr1901: unseemingly fast
<tunixman>
embarrassingly speedy
<qu1j0t3>
unsafely
<qu1j0t3>
unnaturally
<tunixman>
I remember my first pxa270 project...
<qu1j0t3>
cr1901: I'm in your world, but now i have a couple of unpleasantly fast ARMs
<qu1j0t3>
actually the one i am using now is only about 16 or 20MHz, which is acceptable
<tpw_rules>
Sarayan: at least that's a cortex-a
<tunixman>
it was kind of a cool one where the SoC was on a DIMM.
* tpw_rules
agrees that >100MHz is too much for cortex-a
<tpw_rules>
cortex-m* >_>
<tunixman>
so we just put a dimm socket on a board and never did anything more.
<tunixman>
there was also an FPGA with a lot of weird automotive IO controllers that were only nominally standard register models, and we put a soft 68k on it to emulate our old system.
<cr1901>
Sarayan: >otherwise you need to observe both the 1 and the 0. So 2MHz _sample rate_ to observe the 1MHz read signal?
<cr1901>
I'm not being pedantic for the sake of being an ass, I swear. I just get hung up on terminology.
<tunixman>
I think that's right, also because of the nyquist limit...
<cr1901>
The write clock is 2MHz for ED drives, so you would need a bare minimum of 4MHz sample rate to see the write clock 1/2
<cr1901>
But observing the raw write clock signal isn't useful.
<cr1901>
?*
<cr1901>
I hate trying to visualize waveforms in my head
<qu1j0t3>
cr1901: i think you're violently agreeing with each other.
<qu1j0t3>
cr1901: if you have a 2mhz sample rate, you can observe the 1's and 0's on the signal.
<tunixman>
hahah you poms have a funny idea of violence said the yank.
<qu1j0t3>
but actually i'll shut up because i'm only procrastinating and i need a coffee
<qu1j0t3>
anyway i solved a longstanding problem driving the YM3014B DAC and my conspiracy theory is that the datasheet omits a tiny piece of information.
<tunixman>
qu1j0t3: good on you mate!
<qu1j0t3>
but this theory does not have peer reproduced review
<tunixman>
you know what that means...
<Sarayan>
well, ED has the cell size at 500ns, but you can have a flux change only in every other cell, and I have no idea what the flux change pulse lenght is
<Sarayan>
otoh, wd-class chips need a 16MHz frequency for reliable HD (to have a working pll), so that's a saner minimum (still not that much)
<Sarayan>
if you have a fpga latching on edge a 50MHz clock (like you'd do easily on a sx120f) is kinda trivial
<tunixman>
as long as the amplitude of the pulse is strong enough to modulate the detector it shouldn't matter too much...
<tunixman>
it's going to smack the field coil anyway and it'll ring.
<Sarayan>
you're talking read or write there?
<tunixman>
(That's a very very qualitative analysis.)
<cr1901>
>and I have no idea what the flux change pulse lenght is
<tunixman>
oh, good point. write you'll need to worry about it, probably smear it out a bit.
<cr1901>
(everything retro is so much easier with a latch, damnit T_T)
<tunixman>
but reading yeah, just listen for the ringing.
<Sarayan>
what field coil?
<tunixman>
hahahah yeah...
<tunixman>
the head is basically a field coil, isn't it?
<tunixman>
or whatever the GMR equivalent is...
<Sarayan>
when you read you're very far from the head
<tunixman>
wait, who's far from the head?
<Sarayan>
there's an agc or something that behaves like one and a bounce filter and a pulse rectifier before you see seomthing
<Sarayan>
the read signal out of the floppy connector
<tunixman>
right, yeah, all that stuff is what's "listening" for the signal straight out of the coil.
<Sarayan>
and then your fpga or mcu or greaseweasel or whatever
<cr1901>
qu1j0t3: Yes, we are probably violently agreeing w/ each other. Terminology wise, I consider a "2 MHz signal" different from a "2 MHz sample rate"
<tunixman>
oh yeah, we are.
<Sarayan>
yeah, but we're talking characteristics of the hardware after the connector, not between the connector and the head
<tunixman>
Yeah, that's true too. but the inductance of the read coil is going to smear all that out, even if you're on a smaller time scale than 2MHz to the extent retro electronics can manage.
<tunixman>
now I'm rambling and not quite following myself.
<Sarayan>
one on the things on the path supposedly recreates nice clear pulses for you
<tunixman>
yeah, that's right. it's listening for the field changes, then when it detects one it tells you.
<tunixman>
god I'm so not rigorous here it's embarrassing.
<Sarayan>
it happens :-)
<tunixman>
we're definitely saying the same thing. you're actually saying it though, I'm sort of metaphoring myself into a dark corner.
<Sarayan>
but that's why the pulse width is dependent of that circuit and not at all on what's on the disk
<tunixman>
oh yeah, we're definitely saying the same thing.
<Sarayan>
then we're good :-)
<tunixman>
or, really, you're saying what I wanted to say but could only sort of gesture at.
<cr1901>
raw floppy read signal is Gaussian-shaped pulses of both polarities, with typically a spurious zero crossing between pulses of different polarities
<cr1901>
the spurious crossing is called a "snake", according to some internal memo from Shugart at least. The analog front end uses a timer to gate out these snakes
<cr1901>
>spurious zero crossing (I MIGHT mean "signal derivative changes sign twice for a short period of time")
<qu1j0t3>
i knew it was going to get dark and occult in there.
<qu1j0t3>
anything involving magnets
<qu1j0t3>
and magnetics
<qu1j0t3>
Aliens did it
<tunixman>
"...heads featuring integrated microscopic heater coils to control the shape of the transducer region..."
<tunixman>
black magic
<tunixman>
all the way down the turtles
<tunixman>
smacking the head from both sides now. what's next...
<qu1j0t3>
i've been reading about transformers a lot in the past year
<tunixman>
oh yeah...
<tunixman>
I'd say quantum tunneling is next but that was 2004.
<Sarayan>
the 82077AA (which handles ED) expects a pulse width of at least 50ns... that's not a lot if you're not hw-assisted to see that there's a pulse
<Sarayan>
anyway, it's midnight here, and work week, so good night
<cr1901>
night
<cr1901>
(Also, that's good info to know... 50ns == 20MHz, so sample at least 40MHz. 48 should be enough, right?)
<cr1901>
gatecat: In any floppy controller design I want to do for FPGA, I want there to be a single clock domain. 1/?
<cr1901>
This isn't a problem for ice40hx parts, but for the up5k parts, 48MHz is likely to fail. Does nextpnr recognize when part of a design is held under a clock enable signal to "emulate" a separate clock domain?
<cr1901>
So I can run the bare minimum of the design in the 48MHz domain and run the rest at, say, every 3 cycles of the 48MHz clock?