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
<balrog>
andlabs, sorear: they got rid of the less frequently used instructions and provided a software emulation package under a permissive license, the source code of which can be found in the linux kernel tree
<balrog>
cr1901_modern: that software emulation package is called the FPSP
<balrog>
I've been digging through this for a different reason: we don't have a good emulation-friendly floating point abstraction layer or software library
<cr1901_modern>
Floating Point Software Package... ahhh
<balrog>
(softfloat2 is under a problematic license)
<cr1901_modern>
I have batted around doing a floating point library before for old machines.
<cr1901_modern>
I'm sure they weren't _good_, but there were a few 286 FP emu libraries
<andlabs>
netlib is an archive of mathematical code specifically
<balrog>
> Further testing yielded a "cursed WAV" that consistently prevents perfect rips on different brands of optical drive, ripping software, and operating system.
<andlabs>
hm, motorola's fpsp isn't in netlib
<andlabs>
that's something that can be fixed
<andlabs>
sigh at that page
<andlabs>
can we just make our own CD readers please
<andlabs>
already
<andlabs>
hackaday project
<andlabs>
it shouldn't be impossible
<andlabs>
you'd need a motor and a laser
<balrog>
andlabs: yes, domesday86 can already read CDs
<andlabs>
is domesday86 a person or a community or a piece fo hardware
<andlabs>
I thought it was the former two
<balrog>
the duplicator specifically
<balrog>
it's a community/project that devised hardware for RF level ripping and software decoding of laserdiscs
<balrog>
some of which have EFM modulated digital data on them
<balrog>
it would be easier to tap the output of an existing CD reader anyway
<balrog>
no need to reproduce the mechanical crap and the tracking feedback loop
<andlabs>
I'm not convinced that can be done though
<balrog>
which part?
<balrog>
I mean, domesday duplicator does it with LD players (some of which can play audio CDs)
<andlabs>
tapping the output so early in the chain of events leading to you getting a 2358-byte sector that you can read the raw bitstream
<balrog>
I'm afraid some players use an integrated amplifier + partial processing IC
<andlabs>
especially for CDDA where you've got that pesky reed solomon to worry about
<andlabs>
I also now wonder what the sheep score of my drives are
<andlabs>
because I have ripped some CDs multiple times and did confirm identical output
<andlabs>
meh
<andlabs>
I still need to look into domesday at some point
<andlabs>
I've got ISOs to rip of software that I have
<andlabs>
so I can shove them into virtual machines
<balrog>
I'm particularly interested in analog video tape, would be nice if more people were working on that
<andlabs>
I'll try using cdrparanoia on them I guess
<balrog>
software? I'd try Aaru of DiscImageCreator
<balrog>
OR*
<andlabs>
are either of those FOSS
<andlabs>
also I need to find a good compact cassette deck that I can use to archive software that's on tape, but preferably one with a direct drive quartz lock or whatever it is that reduces wow and flutter to zero and also has the advantage of requiring virtually zero maintenance from me in any regard (azimuth, belt relacmeent, etc.)
<andlabs>
analog video doesn't have this problem because it turns out analog video required all those fancy things to work properly
<balrog>
unlikely you'll find one like that, that's also zero maintenance
<balrog>
I'd probably look for ones with little wear in decent condition, but felt replacement will probably be mandatory
<balrog>
belt replacement*
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<andlabs>
right now I'm looking at a WM-DD9
<andlabs>
yes, the expensive one
<Nerionaya>
fancy
futarisIRCcloud has joined ##yamahasynths
Xyz39808 has joined ##yamahasynths
Xyz_39809 has quit [Ping timeout: 240 seconds]
<andlabs>
hmm
<andlabs>
apparently innodisk still makes the right kinds of compactflash cards
<andlabs>
>at least $200 for 16GB
<andlabs>
fuck that
<andlabs>
and 16GB is absolutely not going to be enough for what I wanted it for lol
<andlabs>
or maybe it will but I have no idea
<sorear>
balrog, andlabs: i didn't ask *what* they did, it's obvious from the manuals that they left out a bunch of instructions. i asked *why*: the 68xxx line is critically dependent on microcoding for stuff like UNLK, did they run out of microcode space for FSIN?
<sorear>
andlabs: why "infamous" line 1111 emulator?
<cr1901_modern>
Apparently if you press the "C" button after Sonic 1 crashes, you can cause program execution to continue
<cr1901_modern>
(it'll almost certainly crash again, but interesting thing I learned yesterday)
<cr1901_modern>
>did they run out of microcode space for FSIN
<cr1901_modern>
Also, interesting q. One I don't know the answer to
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<andlabs>
it's also likely the answer
<sorear>
it's just a bit strange because rom constraints relaxed quite a bit in the '000 - '060 timeframe, and a crappy sin isn't that big
futarisIRCcloud has joined ##yamahasynths
<andlabs>
sure, but it's mroe than just a number ROM
<andlabs>
it's also all the logic
<andlabs>
and it's not just sin, it's literally like 80% of the instructions lol
<andlabs>
and yes, you need some sort of logic, because even now a ROM will not be enough to store a complete lookup table for an entire double-precision floating point domain of [0..1)
<sorear>
I know how math libraries work.
<cr1901_modern>
I believe those assumptions were coded into sorear's question
<andlabs>
then I missed them
<andlabs>
I don't know how chip manufacturing works but they probably ran into a size constraint
<andlabs>
eithe require a physically larger chip which is incompatible with existing systems or drop something because there's literally not enough room with current manufacturing processes
<andlabs>
remember that the 68040 also included a 68850 (MMU)
<andlabs>
and its own set of new instructions to handle more things the previous generations didn't offer
<andlabs>
and didn't do well
<Sarayan>
the mmu was simplified too iirc
<Sarayan>
and the cache was less insane
<andlabs>
I'm trying to remember exactly what those new instructions were
<sorear>
hmm, cache is a bit smaller than I thought
<Sarayan>
68030 cache iirc was 27 lines full-associative
<andlabs>
MOVE16
<Sarayan>
68040 64 lines 4-way associative
<Sarayan>
PIPT, also iirc
<sorear>
too used to thinking about the 32K+32K modern norm
<andlabs>
all cache control instructions
<cr1901_modern>
>full-associative
<cr1901_modern>
What. The. Actual. F***.
<Sarayan>
cr1901: Yep
<andlabs>
"ATC" manipulation
<Sarayan>
atc = tlb
<sorear>
but 16K total cache would have similar area to 96K of ROM (SRAM = 6T/bit), and more than 10% of that is probably unreasonable for ucode, so fitting the FPSP logic in 9.6K is not impossible but a squeeze
<andlabs>
additional MMU instructions (!)
<andlabs>
like PTEST
<cr1901_modern>
Also, PIPT sounds like a severe perf loss. But I guess they had their reasons
<Sarayan>
VIVT is atrocious for the OS
<cr1901_modern>
Well VIPT is what I was thinking
<cr1901_modern>
like 90% of everything out there
<Sarayan>
hmmm
<Sarayan>
well, I'm sure of the PT, need to check the PI
<cr1901_modern>
or at least every me-too RISC I've ever seen
<Sarayan>
mips was/is VIVT, and PITA
<Sarayan>
alpha too
<andlabs>
hm
<cr1901_modern>
ewww
<andlabs>
the FPSP even had its own exclusive instructions
<andlabs>
mostly dealing with single/double precision differences
<andlabs>
and oh yeah I'll need to get some Alpha machine at some point lol
<andlabs>
maybe
<andlabs>
I still wonder what a port of libui to OpenVMS would entail