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 [Ping timeout: 240 seconds]
cr1901_ has joined ##yamahasynths
cr1901_ has quit [Ping timeout: 240 seconds]
cr1901 has joined ##yamahasynths
Degi_ has joined ##yamahasynths
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
cr1901_ has joined ##yamahasynths
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ is now known as cr1901
cr1901_ has joined ##yamahasynths
cr1901__ has joined ##yamahasynths
cr1901 has quit [Ping timeout: 240 seconds]
cr1901_ has quit [Ping timeout: 240 seconds]
cr1901 has joined ##yamahasynths
cr1901__ has quit [Ping timeout: 240 seconds]
cr1901_ has joined ##yamahasynths
cr1901 has quit [Killed (NickServ (GHOST command used by cr1901_))]
cr1901_ is now known as cr1901
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined ##yamahasynths
Lord_Nightmare2 has joined ##yamahasynths
Lord_Nightmare has quit [Ping timeout: 250 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
Lord_Nightmare has quit [Remote host closed the connection]
Lord_Nightmare has joined ##yamahasynths
<andlabs>
I've now also bought a copy of x68000 bosconian
<alexisvl>
heh, was just wondering if it'd be reasonable to ask a 68k instruction set question in here. seems the sort of place someone might know
<andlabs>
there's a sizeable overlap of 68k nerds here so yes
<alexisvl>
i'm flipping through the reference manual and finding this surprisingly elusive, maybe I'm just not looking for the right terms
<alexisvl>
movew 18(%sp), -(%sp) <--- does the 18(%sp) get evaluated before or after the predecrement? or is that undefined?
andlabs has quit [Read error: Connection reset by peer]
<alexisvl>
I'd have expected the section on addressing modes to call out whether predecrement and postdecrement happen inside or outside the evaluation order of other operands, but I don't see it :p
<alexisvl>
er, postincrement*
andlabs has joined ##yamahasynths
<qu1j0t3>
alexisvl: sec 3.12.2 "user stacks"
<qu1j0t3>
alexisvl: predecrement - register decremented before contents are used as pointer
<qu1j0t3>
hm, but maybe that's still a bit ambiguous since it's used twice :)
* qu1j0t3
continues to check
<alexisvl>
interesting, I don't have that section, what manual are you working off? this is the programmer's reference manual (M68000PM)
<qu1j0t3>
"User's Manual"
<alexisvl>
huh, I don't have that section in there either lmao
<alexisvl>
must be more manuals
<alexisvl>
that does still sound ambiguous to me though
<qu1j0t3>
yes
<alexisvl>
I can of course just avoid doing that, but I was really curious
<qu1j0t3>
it is still a little ambiguous, i am checking the addressing modes section, but i'm not sure there will be an obivous statement about htis.
<qu1j0t3>
you might have to check a simulator
<alexisvl>
I wouldn't trust a simulator, could also be UB and vary between specific variants
<qu1j0t3>
yes
<alexisvl>
I figured they'd call this out explicitly, if I can't find it I'll just move through a register. But it was itching at me :)
<alexisvl>
(or decrement separately, whatever)
<alexisvl>
<alexisvl> I wouldn't trust a simulator, could also be UB and vary between specific variants <--- or even just plain wrong in the simulator if it's an uncommon use of operands
<alexisvl>
yeah i just gave up and did it in two steps lol
<alexisvl>
I need two steps anyway as I'm copying a 16-bit value off the stack and pushing it back on extended to 32, so it's either read-and-push in a single move and then stack on a zero, or push a long zero and then copy the value as a word... all the same to me I guess :)
* qu1j0t3
nods
<qu1j0t3>
now i really want to know too lol
<alexisvl>
yeah I can't let it go lol
<qu1j0t3>
how's the scope going? i've actually reached a point where i'm ready to make a pcb for my vector generator
<qu1j0t3>
4.5 years fter i started (many life events in between)
<andlabs>
that shouldn't be undefined but
<alexisvl>
it's still meandering towards completion. been working on the third (and seeming like final..._finally_) rev of the HVPS lately
<alexisvl>
(and this 68k stuff is related too)
<andlabs>
there should be something elsewhere in either the UM or the PRM about order oe valuation of operands
<alexisvl>
I'd have thought so! can't find it tho
<andlabs>
it shouldn't be specific to the stack section like qu1j0t3 said because the stack pointer is just a7
<alexisvl>
clearly there's another manual since I'm missing that section. I've got the M68000 User's Manual (which also covered 68010) and the MC68000 Family Programmer's Reference Manual
<cr1901>
There doesn't seem to be any 68k-specific chat rooms on Libera that are active. Might as well explicitly make 68k on topic here
<alexisvl>
if only the stack pointer _were_ just a7, that'd be nice and consistent but no, there is some special casing :P
<cr1901>
Is "a6" special in any way too? Does the LINK insn use it?
<alexisvl>
only by convention AFAIK.
<alexisvl>
otherwise a6 behaves just like the others
<alexisvl>
but a7 is special case wrt predec/postinc
<alexisvl>
(byte-size moves by two)
<cr1901>
ahhh :(
<alexisvl>
why tf they didn't just apply that to all the address regs is beyond me lol
<alexisvl>
weird sloppy choice
<alexisvl>
(there's also the usp/ssp special case but that one seems more reasonable to me)
<andlabs>
wait what
<andlabs>
how is that different?
<andlabs>
oh you're saying move.b x,-(sp) is different?
<alexisvl>
yes
<andlabs>
okay yeah that's super weird and I did not know that
<alexisvl>
tbh I haven't tested that, I'm not sure I've actually used predec on any non-sp regs
<qu1j0t3>
it has the whiff of something implementation dependent
<alexisvl>
but the PRM says
<andlabs>
I guess they really don't like a misaligned stack
<qu1j0t3>
to be sure
<alexisvl>
yes, it's to avoid misaligned stack
<alexisvl>
push a byte and it moves by two
<qu1j0t3>
yes, there is a documented exception for byte stack moves.
<alexisvl>
but do the same on a0-a6 and it moves by one
<andlabs>
and yeah a6 is only the link register by convention
<alexisvl>
they should have just done the 1->2 upgrade on all of them IMO
<qu1j0t3>
(sorry i mean your original question definitely has the whiff of implementation dependence)
<alexisvl>
changing the stride is too weird
<andlabs>
you could theoretically link a7 if you really wanted to hate yourself I guess
<alexisvl>
haha
<cr1901>
Do longs have to be 4-byte aligned or 2-byte laigned?
<alexisvl>
2
<cr1901>
ahhh TI (re) L
<andlabs>
x86 does have a dedicated link register but x86 registers are all dedicated except for the new 64-bit ones
<andlabs>
(they call it the frame base pointer)
<alexisvl>
<alexisvl> 2 <-- this is possibly not the case on >=68020 where I have no experience. That one is more consistently 32-bit, so I can imagine it wanting things aligned to 4, but it also knows how to "fix" some unaligned accesses so idfk
<alexisvl>
but on 68010 and back 2 is the biggest alignment stride anything requires
<alexisvl>
move16 requires cache line alignment
<alexisvl>
but 68010 doesn't have that
<andlabs>
oh man 68020-specific programming
<andlabs>
entering the wild world now
<alexisvl>
:)
<cr1901>
Ahhh I thought the entire 68k family was "No unaligned accesses at all. Ever. Bad programmer. Bad."
<andlabs>
remember to always be 32-bit clean
<alexisvl>
everyone seems to prefer the straight 68000, but I'm using 68010 here so I figure I may as well try to bear in mind there are MORE 68ks too, who knows, I might use one in the future :D
<andlabs>
cr1901: it is, it's just the amount is different
<qu1j0t3>
cr1901: nah ... it's still in cisc era :)
<alexisvl>
lol 32-bit clean, stuffing things into the upper byte of a pointer just feels so...80s, I can't imagine even considering that now :P
<andlabs>
alexisvl: most do because most machines used one at some point, and some only ever used it
* alexisvl
nods
<andlabs>
I do have some Macs and a nextstep color for my 030 fix though
<cr1901>
I wish 68008 got more love
<alexisvl>
68010 feels a little "nicer" in a few areas, and they're still cheap and cheerful
<andlabs>
oh yeah I also have a QL
<alexisvl>
and I'm working on boards I made myself :)
<andlabs>
that used the 008
<andlabs>
clive sinclair's unfortunate business computer
<alexisvl>
is 68008 just a 68000 that can do 8-bit bus?
<cr1901>
Yes. It's cute :3
<andlabs>
probably also possibly the first consumer-price-grade computer to use a 68000
<alexisvl>
EC000 can do that too, I've got a few on hand for smaller projects :)
<alexisvl>
though it's not physically smaller since it can do _both_ bus sizes, but you're free to not use the extra pins :)
<cr1901>
oooh nice... .oO (68k attached to ISA bus)
<andlabs>
you laugh, but
<alexisvl>
it's been done, lol
<cr1901>
Teradrive
<andlabs>
no, not even that
<cr1901>
Well, maybe I'll save up for one of those cards you're talking about :3
<andlabs>
no I missed out on the auction for this datasheet I hope someone has a PDF of it
<alexisvl>
huh, 2MB, that feels like kind of a lot
<alexisvl>
who used this?
<andlabs>
I don't know! I'm not even sure it was releaed
<cr1901>
Interesting... 68000 w/ an MMU (but presumably no demand paging)
<alexisvl>
it's probably that Motorola MMU that slowed down every access by an entire cycle, lol
<alexisvl>
i have an M*P*U on this board I designed....it is definitely nice to have SOME form of memory protection/control on something running some form of "operating system"
<cr1901>
MPUs are cool
<alexisvl>
much easier to implement, too :) mine's just an extra SRAM running in parallel with the system bus that delivers a permission code to the bus control logic, who then sends out either AS or BERR based on that and the FC bits. it's fast enough to fit inside the bus cycle :)
<cr1901>
AS==Address Strobe?
<alexisvl>
yeah
<alexisvl>
passes through the bus control logic so nobody sees the CPU wants anything until it's been confirmed a permissible access
* cr1901
nods
SceneCAT has joined ##yamahasynths
<qu1j0t3>
alexisvl: i put the question 'out there', got this back: > uae says source is evaluated, then destination. So 18(%sp) is the unmodified value.
<qu1j0t3>
alexisvl: but no idea about documentation for this :<
<qu1j0t3>
the more i think about it the more weird that this isn't documented, because it's just not an obscure pattern
<alexisvl>
huh
<alexisvl>
i mean the isa is from the 70s it's not like caring about UB had been invented yet ;)
<qu1j0t3>
this issue also affects its sibling archs, pdp-11, vax-11, etc. i didn't find anything specific in pdp-11 handbooks. haven't checked VAX-11, but DEC are usually pretty rigorous.
<andlabs>
I use these PDFs now because fuck NXP's shitty watermark
<alexisvl>
ooh
* alexisvl
grabs non-NXPified versions of all the docs they're using
<alexisvl>
thx
<andlabs>
a few people have archives of the 68000 PDFs from the old renesas site but I don't think the internet archive was one of them, alas
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, CD theory of operation, and the 68k CPU are also on-topic. Channel logs: https://libera.irclog.whitequark.org/~h~yamahasynths
<alexisvl>
haha woo specifically 68k :P
<cr1901>
Not that I've EVER enforced on-topic, just now officially 68k is on topic :D
<andlabs>
and also renesas had other products too
<alexisvl>
lol
<cr1901>
Actually... one last addition
<qu1j0t3>
that's fine with me
<qu1j0t3>
i'm a fan
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, CD/floppy disk theory of operation, and the 68k CPU are also on-topic. Channel logs: https://libera.irclog.whitequark.org/~h~yamahasynths
<qu1j0t3>
andlabs: i snarfed NXP and other pdfs
<cr1901>
Now it's perfect/encompasses most topics discussed here
<qu1j0t3>
oh nm already mentioned
<qu1j0t3>
cr1901: analog electronics is implied, i guess :D
<cr1901>
Yes- analog is usually brought up here in terms of sound synthesis devices
<cr1901>
But I think teaching electronics should be for #electronics if they moved free from Fleenode
<cr1901>
B/c I'm not sure I could do a good job at teaching e.g. op amps via IRC
<cr1901>
I need a pen and pad for that sort of stuff
* qu1j0t3
nods
<andlabs>
okay I don't think motorola ever documented what happens if you do that
<andlabs>
or anything about the order of evaluation
<andlabs>
I can only *guess* it's source then destination because that's how it's stored in the instruction stream and that's how the prefetch sywill see them but
<cr1901>
Sarayan might know (and if he doesn't, eventually he WILL know)
<alexisvl>
aw i don't want a bunch of people to spend a lot of time on my silly question :p
<andlabs>
now I kinda want to try move.* (aX)+,-(aX) and -(aX),(aX)+ just to see what gets corrupted
<andlabs>
or one of the bcd/x operands with -(aX),-(aX)
<cr1901>
It's a 68k Fan Club... we help ppl out w/ their 68k problems :D
<alexisvl>
heh, i just made it movel #0, -(%sp); movew 22(%sp), 1(%sp)
<alexisvl>
no problems here :P
<andlabs>
lol
<qu1j0t3>
andlabs: yes. | it's sort of the 'common sense' way, but ... nothing adheres to common sense [all the time; often;
<qu1j0t3>
| depending on your jadedness]
<qu1j0t3>
is there a 68k godbolt-like online/ didn't goldbolt used to have coldfire at least?
<cr1901>
Maybe prod Godbolt to add a 68k compiler?
<qu1j0t3>
hehe
<qu1j0t3>
we need an EmbedBolt maybe, though they do do a lot of embedded targets