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 [Ping timeout: 260 seconds]
<cr1901_modern>
I had the opportunity to buy a VAX in early 2011, but because I'm a moron I didn't take the offer.
<sorear>
i'd consider it if i had somewhere to put one
<sorear>
john paul adrian glaubitz, author of the bountysource page
<andlabs>
oh
<sorear>
someone I half expected to already be in here :D
<cr1901_modern>
I sent him a msg... we'll see if he gets back to me
<cr1901_modern>
His focus is 68k AFAIK, but he's pretty good w/ retro stuff in general. He helped look for byuu's package of European Super Famicom games when USPS lost them
_whitelogger has joined ##yamahasynths
cbmuser has joined ##yamahasynths
<cbmuser>
cr1901_modern: you asked me to come here?
<cr1901_modern>
Indeed, lemme pull up the history
<cr1901_modern>
Uhhh short context: This is ##yamahasynths, a channel where we discuss floppy disk theory of operation, 68k, VAX.
<cr1901_modern>
cbmuser: SInce you organized it, and the 68k bounty succeeded, I figured the AVR and VAX ones would succeed as well. But Microchip punted on doing the AVR work, and the VAX bounty hasn't had much activity
<racoon>
I think the two people who are capable of fixing vax gcc are too preoccupied right now
SceneCAT has joined ##yamahasynths
<andlabs>
did Microchip buy Atmel?
<andlabs>
yes, back in 2016
ej5 has quit [Read error: Connection reset by peer]
emeb has joined ##yamahasynths
<cr1901_modern>
racoon: Oh dear :(...
<sorear>
wait, is that a reference to a specific situation
<cr1901_modern>
sorear: The "two people who are capable"? I'm not sure... the 68k backend was fixed by a gcc developer once the bounty reached a specific amount
<cr1901_modern>
afaik, at that point (about the same amount of money as for VAX), even the gcc devs wanted 68k fixed
<sorear>
like I'm wondering if this is vagueposting about two specific people who are experiencing a specific personal crisis
<racoon>
vagueposting? kinda. one is busy with other stuff, the other has personal problems. re: 68k, VAX is an extremely convoluted architecture, 68k is much better understood at this point
<racoon>
we (netbsd) are the only real remaining user of the gcc vax port, most of our support is not upstreamed (e.g. shared libraries), we have it to the point where it kinda works cross-compiling with -O0, optimizations and native builds are out of the question
<racoon>
68k is in a much healtheir state
<cr1901_modern>
>we have it to the point where it kinda works cross-compiling with -O0
<cr1901_modern>
Wait what?!
<racoon>
which part are you "wait what"ing at
<cr1901_modern>
-O0
<racoon>
it ICEs at higher optimization levels
<racoon>
frequently
<racoon>
on very basic code
<cr1901_modern>
Well, that would explain why a native compilation of Perl takes multiple days
<racoon>
no, gcc is just slow
<racoon>
disabling optimizations makes gcc faster
<cr1901_modern>
But the compiler has opts disabled
<cr1901_modern>
So you're running an unoptimized gcc to compile Perl
<cr1901_modern>
(?)
<racoon>
likely it is only disabled for specific files that break
<racoon>
i can't remember the details
<racoon>
don't really give a shit about museum-tier architectures
<cr1901_modern>
What about 68k? :P
<racoon>
at least you have half a chance of finding an amiga on ebay
<cr1901_modern>
You seem to like that one just fine
ej5 has joined ##yamahasynths
<racoon>
vax, either you're unfortunate enough to have a fridge-sized machine eating at your power bill that you bought off some guy on a mailing list 10 years ago, or you're running it in simh
<cr1901_modern>
I don't have any particular attachment to VAX. Just think it's a shame that compilers worth their salt have moved on so extensively that they can't target VAX anymore.
<racoon>
i would like a c compiler that does not try to be as fancy and gcc and clang
<racoon>
just with fast build times
<racoon>
if you try pcc compared to gcc the difference is amazing
<racoon>
gcc and clang are both kinda pigs
<sorear>
hmm, there were no desktop vaxen? not even with the later single-chip implementations?
<cr1901_modern>
I've asked for a netbsd pcc build multiple times on the mailing list over the past 6 years
<racoon>
sorear: yeah, but they're very expensive now
<cr1901_modern>
no one cares enough to make it work
<racoon>
i presume they were all raided for use in industrial applications where they still have cobol vax binaries on openvms as mission critical
<cr1901_modern>
ej5: Excellent work :D... I have not
<cr1901_modern>
I don't read HN unless someone gives me a link, so thx for that :D
<sorear>
did openvms not do emulation when they migrated to ~alpha~ ~ia64~ x64?
<cr1901_modern>
I'm proud to have played a small part as moral support while you did the work :)
<racoon>
10 years or so ago every UK supermarket of some major chain had a vax running vms at the back
<racoon>
that kinda thing inflates the prices since those kind of industries can throw a few K on a machine
<cr1901_modern>
>before a restart point
<cr1901_modern>
sorear: Oh, so that's what VAX did... if any of those 40 mem accesses failed, the whole insn restarted?
<sorear>
for page faults, yes
<cr1901_modern>
68k has a mechanism where if a multiple mem-access insn fails, it will save it's internal state on the stack to pick up where it left off
<cr1901_modern>
I thought maybe VAX was similar since they are similar era archs
<cr1901_modern>
But saving internal state has it's own problems (interrupt latency), so 68k seems unique
<sorear>
well it's awful for doing anything interesting in software using page faults
<andlabs>
racoon: oh neat
<andlabs>
so I could potentially have libui/netbsd running on vax then? =P
<andlabs>
*right now
<cr1901_modern>
sorear: You mean saving state is awful :P?
<racoon>
andlabs: ye, at 1 frame a month
<andlabs>
oh boy!
<sorear>
saving state in an undocumented, uninspectable and unmodifiable format is awful
<andlabs>
for context (+ cbmuser) this discussion started because I said I just purchased a MicroVAX 3100/90
<cr1901_modern>
I... don't actually know if it's undocumented
<cr1901_modern>
According to Sarayan, it's documented in the patents
<sorear>
do you want to write a page fault handler which skips the offending instruction? too bad
<cr1901_modern>
But _I_ don't know the format
<andlabs>
ell just as in yesterday but still
<sorear>
i don't think patents qualify as programmer's documentation
<sorear>
at best it's OSINT
<cr1901_modern>
that is true
<andlabs>
[11:32:31] <cr1901_modern>I thought maybe VAX was similar since they are similar era archs
<andlabs>
similar era, vastly different philosophies
<cr1901_modern>
Yes, but both would've been laid out by hand/rubylith
<andlabs>
I'm pretty sure the philosophy at the time for vax was "programs should not cause those kinds of issues at all"
<sorear>
vax also has a bunch of interruptable instructions which can save state in R0-R5 (and for DIVP6, 16 bytes below the top of stack)
<cr1901_modern>
So saving state would've been within the realm of feasibility even for a manual design
<andlabs>
but I can only point to anecdotes about MVS
<andlabs>
which is not VMS
<sorear>
"those kinds of issues"?
<andlabs>
[11:32:15] <cr1901_modern>68k has a mechanism where if a multiple mem-access insn fails, it will save it's internal state on the stack to pick up where it left off
<cr1901_modern>
ej5: >Sadly extracted firmware was never published :(
<andlabs>
Let me tell you briefly (I promise!) A Tale of Two Systems, the UNIX and the Emveeous. ``There dwelt in the land of New Jersey the UNIX, a fair maid whom savants travelled far to admire.'' The Emveeous was envious of the UNIX for her natural grace; the UNIX however, spurned the Emveeous, thinking him a course, vulgar fellow. One day her suspicions were confirmed when she saw that he had more manuals listing his errors and sins
<andlabs>
than she had manuals describing her entire life. But as the UNIX grew into middle age and got busy, she became careless, and made many mistakes, and forgot to check these errors. And the scribes duly observed these errors, and duly recorded them. And the UNIX died old and unhappy, for she saw in her final hour that her error messages manual had grown malignantly to become large, larger than that of that old simpleton, the Emveeous.
<andlabs>
but MVS is IBM, not DEC
<cr1901_modern>
Is UNIX supposed to be shorthand for "68k and saving state"?
<Sarayan>
andlabs: And on the UNIX's tomb is written "It's not a bug, it's a feature"
<cr1901_modern>
(Not sure what my msg had to do with it)
<andlabs>
"saving state and being recoverable from error conditions"
<andlabs>
which I thought you were talking about
<andlabs>
but you seem to mean saving state *in general*
<cr1901_modern>
By saving state, I mean:
<cr1901_modern>
Most CPUs will abort the current insn if it runs into a problem
<cr1901_modern>
68k won't. It'll save it's current position in the insn
<sorear>
the term you are looking for is "precise and imprecise exceptions"
<sorear>
68020 is highly unusual in having restartable-but-imprecise page faults
<cr1901_modern>
It's still up to you to actually _handle_ the exception, but you can continue where you left off once you return
<sorear>
I believe 68040 joined the rest of the world with precise page faults
<andlabs>
and I'm pretty sure big mainframe systems like the VAX were designed to be extremely hardened to an absurd degree
<andlabs>
well yeah the 68040 also joined the x86 in having a built-in MMU
<Sarayan>
in which way are the 020 page faults imprecise?
<cr1901_modern>
andlabs: Tbh, I've kinda and resigned to the idea that, while 68k is probably the best arch to read/write for me, I don't actually like writing much assembly at all. I'd rather have a wrapper over assembly
<cr1901_modern>
even a small one like COMFY68K (which doesn't exist)
<andlabs>
that's fair
<cr1901_modern>
The actual language is called COMFY65
<andlabs>
so yeah is debian-akiko a CD32? =P
<cbmuser>
no
<andlabs>
heh
<cbmuser>
it's a QEMU virt machine
<andlabs>
ah
<cbmuser>
as explained in the talk by Laurent I linked
<andlabs>
I should try seeing how feasible it would be to add support for the Akiko chip to ShapeShifter
<cbmuser>
btw, there is also work being done for adding m68k support to Haiku ;)
<andlabs>
amazingly no one has done so in the past 25 years
<andlabs>
heh
<andlabs>
I am going to guess that will be for 68302?
<cbmuser>
hmm?
<cr1901_modern>
Does "monorepo" mean "LLVM changed their layout a few months ago, so we imported the history of prior commits into a new repo that reflects the new layout"?
<andlabs>
or I guess I can ask them directly since I'm also in #haiku
<cbmuser>
cr1901_modern: Yes
<andlabs>
what 68000 platforms they are going to support
<andlabs>
68302 seems to be the only 68000 thing NXP still sells
<cbmuser>
andlabs: the guy working on that is mmu_man
<cbmuser>
but if people have complaints, why don't they send patches?
<andlabs>
DBF == DBRA
<cbmuser>
I find it very frustrating when people who could help with their experience and knowledge are just complaining
<cr1901_modern>
B/c compilers, despite being well-documented, are hard
<cbmuser>
well, even a bug report helps
<cr1901_modern>
Well that's fair
<cr1901_modern>
Uhhh, I'll see what I can do about attending the next meeting
<Sarayan>
proving that a loop can be done with dbra is nowhere near trivial, and it's even worse when you need the index
<Sarayan>
plus the index is 16 bits
<andlabs>
but isn't that what dbra works with?
<Sarayan>
it is, I mean all that makes it nontrivial to correctly use a dbra in a compiler
<andlabs>
ah
<sorear>
it seems to have more features than the pulp/sh2 zero-overhead loop
<andlabs>
cr1901_modern: do you have info on COMFY65? I can only find ports to common lisp and the ACM paywall for some article
<cr1901_modern>
It was an article whitequark sent me last year, I'll see if I can find the link
<cr1901_modern>
andlabs: https://dl.acm.org/citation.cfm?id=270947 Here's a link. Indeed it's behind a paywall. And it would be very immoral to find a way around that paywall via SciHub or libgen. So don't do that.
<Sarayan>
sorear: DBcc is "if the test passes, don't branch. Otherwise decrement the indicated register asa 16-bits value by one, and if the result is not -1 then branch"
<Sarayan>
dbra is dbf, e.g. the test never passes
<ej5>
cr1901_modern, any progress on your cleanroom sb firmware? people are champing at the bit to get the original disassembly and i don't want to hold it back much longer.
<Sarayan>
sb = soundblaster?
<cr1901_modern>
ej5: It's not going to happen I'm afraid... I'm sorry :(
<ej5>
ok no worries, i'll just go release it then
<ej5>
Sarayan, yes
<Sarayan>
we don't have three versions in mame already?
<cr1901_modern>
I am going to add "skene" to my repertoire
<cr1901_modern>
as a shorthand for "ppl who take themselves too seriously in a very narrow focused community"
<Sarayan>
yeah
<Sarayan>
"quit da skene" was the full expression
<Sarayan>
not entirely sure where it came from, too long ago at that point
<Sarayan>
even google doesn't help
<cr1901_modern>
Reminds me of a few ppl who quit byuu's forum back in the day b/c they didn't get as warm and fuzzy a reception for their work as they'd like
<andlabs>
cr1901_modern: both are a bust :/
<cr1901_modern>
andlabs: I'll see what I can do in a few minsa
<andlabs>
also what are you talking about with ej5
<cr1901_modern>
I asked ej5 for some time to do a clean room RE of the sound blaster firmware, just so it exists for those who want a FOSS firmware that's not susceptible to copyright etc
<cr1901_modern>
This did not pan out for reasons
<m4t>
what kind of dsp is it?
<cr1901_modern>
DSP 2.02
<m4t>
oh, mcs-51?
<cr1901_modern>
yes
<m4t>
so not a dsp :)
<cr1901_modern>
yes
<m4t>
digital sound processor wikipedia says
<m4t>
i want my money back
<andlabs>
what use would a custom firmware have?
<cr1901_modern>
Bug fixes, not copyrighted material
<andlabs>
ah
<cr1901_modern>
... that's it?
<andlabs>
wha do clones do?
<cr1901_modern>
I think they do similar clean room. The clone firmware I know of barely fits- Creative's firmware fits more nicely