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
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<andlabs>
also I may try cowgol
<andlabs>
and maybe also the zmac assembler
<andlabs>
asxxxx is proving to be a bit too quirky for my tastes
<andlabs>
but doing this thing in assembler is starting to seem like a mistake
<Foone>
andlabs: I'm indirectly mentioned in at least two LGR videos, but I can't remember which one I'm actually mentioned in
<Foone>
there's a weird connection, though: I'm actually from the town LGR lives in
<whitequark>
is that a 'technology connection'?
<TD-Linux>
ｂｒｏｗｎ
<TD-Linux>
I finally got a yamaha mu2000ex so my midi excursions can be technically on topic
<andlabs>
brezza_dsa: hi yes I'm the one that was looking at old versions of emu2413 =P I didn't realize it was the same emu2413 that was part of libkss, but I eventually gave up when I realized it was the hoot source code archive that was too old to be of much use
brezza_dsa has quit [Remote host closed the connection]
<cr1901_modern>
andlabs: You can reach brezza_dsa at @ym2413 on hellsite
<andlabs>
lol
sorear has joined ##yamahasynths
<cr1901_modern>
Sarayan: When you're around, we started discussing 68000 in another room I idle in #j-core. The state the 68k saves on the stack inevitably came up. What do you know about the state saved from studying the die?
<cr1901_modern>
state the 68k saves on the stack on exception*
<cr1901_modern>
Since kevtris created that Genesis FPGA core for Analogue, I'm guessing that the state is at least _partially_ known
<TD-Linux>
the 68000 exception frame is in the 68000 reference manual
<cr1901_modern>
Including the processor-specific state saved that allows the 68k to continue mid-insn?
<superctr>
the 68010 yeah
<superctr>
all is in the M68000PRM
<TD-Linux>
iirc that is 68010+
<cr1901_modern>
I thought the 68k allowed this too, it just didn't save enough state to _restart_ an insn
<superctr>
68k couldn't interrupt in the middle of an instruction, apparently some computers did virtual memory on regular 68000 by having two of them running in parallel though with a small
<superctr>
if one interrupted, the second one could be halted in time to set up the memory map
<cr1901_modern>
Yes, that's the "standard" way to do it. But I thought the 68000, specifically, _could_ interrupt in the middle of an instruction, and most exceptions would work fine after returning.
<cr1901_modern>
But page fault didn't.
<superctr>
they solved it on the 68010 by making the address error and bus error exception dump more state to the stack
<superctr>
that is documented in the M68000PRM as i mentioned
<cr1901_modern>
>all is in the M68000PRM
<cr1901_modern>
Oh, I somehow substitured M680*1*0PRM
<cr1901_modern>
it appears I can't reafd
<cr1901_modern>
or type
<superctr>
the format of this stack frame is slightly different on later versions
<superctr>
there is only one PRM and it covers the whole family
<cr1901_modern>
Then I guess I'm confusing with something else... I vaguely recall that for a long time there was something about exception processing that nobody working on emulators knew.
<cr1901_modern>
And it was only via REing the die and bus signals that ppl started learning.
<cr1901_modern>
If the exception info is completely documented in the manual (which I didn't know), I must be thinking of something else
<superctr>
well, maybe i'm pushing it a bit
<superctr>
in fact it isn't fully documented
<superctr>
just says "internal information, 16 words"
<superctr>
:P
<cr1901_modern>
16 words... 1 word = 32 bits?
<superctr>
16 bits
<cr1901_modern>
ahh right... dword == 32 bits
<sorear>
this is 68k, not mips
<superctr>
so 32 bytes or 256 bits
<sorear>
ADD.W
<sorear>
32 bits = long
<cr1901_modern>
Yes, I forgot lmao
<cr1901_modern>
From what I've been told, saving this much state was notoriously slow. I can see why ._.
<cr1901_modern>
Most CPUs finish the curr insn (interrupts and most exceptions) or just completely discard it's state and try again (some exceptions)
<superctr>
i'd say the 68k is notoriously slow in general
<sorear>
the 68000 is a fully pre-RISC design with multiple levels of microcode that I do not understand at all
<cr1901_modern>
superctr: But the ISA is beautiful (read as: I actually like reading and writing it) :o
<superctr>
beautiful to an assembly programmer
<cr1901_modern>
opcode encoding is utterly horrific tho
<superctr>
not so fun when you count cycles though, because there's a million different way to optimize your code
<superctr>
it's better on RISC architectures when all instructions just complete in one or two cycles :)
<cr1901_modern>
I have a book on compilers (Appel)... in one section it goes out of its way to say "68k's autoincr insns are too f***ed to be worth generating code for"
<cr1901_modern>
not in that language of course
<cr1901_modern>
Made me sad :(
<sorear>
must be really old book because that's one of the few features that has largely survived
<superctr>
at least the 68k isn't that terrible for high level programming languages
<cr1901_modern>
sorear: 1998 I think?
<superctr>
unlike, say, the Z80 which was invented in a time when nobody knew what a compiler was
<sorear>
A64 and ppc both have postinc addressing modes
<superctr>
you could probably write and get accepted a PhD paper on Z80 register allocation for C
<superctr>
that is how fucked it is
* sorear
has the opposite problem with a Z80 and doesn't really know how you're supposed to use one without a million spills
<cr1901_modern>
My own experience is that "you concede register pressure is too high and be thankful the memory/cpu bandwidth isn't too horrible on systems where you'd use a z80"
<cr1901_modern>
bandwidth ratio*
<superctr>
of course
<superctr>
but z80 also doesn't have a convenient way to access ram like the 6502 zeropage
<cr1901_modern>
Which is also probably why it's not an accident that z80 and 65xx emulate stack machines well
<superctr>
you have to go in with a 16-bit memory address or use the 16-bit registers or the slow index registers
<cr1901_modern>
hmmm
<cr1901_modern>
sorear: Oh it's A64 only? TIL
<sorear>
A32 has it as wel
<cr1901_modern>
ahhh
<sorear>
but A32 isn't something you can point to when arguing that something is modern good practice
<superctr>
oh, there is _one_ convenient memory access method
<superctr>
the stack :P
<sorear>
if A64 has a feature, people thought that feature was a good idea as recently as 2014
<sorear>
and it looks like clang can generate ldr x1, [x2], #8
<cr1901_modern>
Well, I'm happy postincr survived, b/c I think it's a cool type of insn :).
<sorear>
at a high level, I'd just like to understand the design principles of the 68000 as well as I do more modern chips…
<cr1901_modern>
I would bet it was probably the most complex CPU design (in terms of number of transistors) existing at the time, until iapx 432 came out.
<sorear>
do you mean the 4320[1-5] individually or in combination
<cr1901_modern>
in combination
<whitequark>
superctr: i thought sdcc had a few such papers
brezza_dsa has joined ##yamahasynths
* cr1901_modern
adds to the todo list to check those out
<brezza_dsa>
andlabs: hi i thought hoot's emu2413 was primary copy from MSXplug around 2002. I have never tried to build hoot - it seems hard to get proper dependencies...
<l_oliveira>
on a side comment, plenty of interesting stuff disappeared from the internet when geocities.jp went offline a few years ago and a lot of of it is lost forever D:
<l_oliveira>
a lot of it (sorry about the poor edit of the text line)