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
ej5 has joined ##yamahasynths
<cr1901_modern>
The hell is an xcf file?
<cr1901_modern>
Oh, it's GIMP format. I'll wait for LN to be here tomorrow
grauw has quit []
<KillaMaaki2>
"Oh I'll just whip up a quick M68K -> YM2151 sound driver in C" I said. "It'll be fun" I said. A week later and I'm still trying to debug an absolutely bewildering memory corruption issue. s i g h
<cr1901_modern>
hopefully 68k rust comes out at some point soon. For the time being, wrap bounds checks around your array accesses and take the perf penalty?
<KillaMaaki2>
The bewildering part is that even an OOB shouldn't be biting me here. I'm copying from an array into a local struct variable, which under the hood emits a memcpy call, but right now that struct is totally unused. So it should just be a plain old memcpy into the struct's address, even if the data was garbage that shouldn't be affecting anything. And yet here I am.
<cr1901_modern>
I would have to see the code
<KillaMaaki2>
The line that seems to break everything is about as plain as it gets - "instrument = songData->instruments[ cmd->Val1 ];" where "instrument" is a local struct. Somehow including this line causes it to read garbage values out of the command array, which is located in ROM-space FWIW, starting at index 2. Without that line, it reads correct values all the way to the end of the array (which is 13 elements long).
<KillaMaaki2>
Starting to wonder if I'm encountering more interrupt tomfoolery. I had a problem where my vertical sync interrupt blew things up but that's because it was messing with my registers and not restoring them. Should be fixed now, unless I've misunderstood the movem instruction...
<cr1901_modern>
And the assembly looks reasonable too?
<cr1901_modern>
(Could be optimization, that's why I ask)
<KillaMaaki2>
Last I checked it looked OK. Should probably re-check it for sanity.
<KillaMaaki2>
I do remember when I was messing with Sega homebrew some people were having issues with weird 68k specific bugs in GCC at certain optimization levels...
<cr1901_modern>
You're using Stef's devkit I assume?
<cr1901_modern>
I've tried compiling recent gcc for 68k, but at the time I couldn't get the build to succeed. I ought to try again (or the llvm version).
<KillaMaaki2>
In this case, no. Custom barebones GCC 4.9.0 & binutils build for a custom system
<cr1901_modern>
Mind pasting your ./configure command line and linking it here for posterity so I have a starting point?
<KillaMaaki2>
GCC itself didn't give me a whole lot of trouble, but binutils was a bit of a pain. Ended up having to tack on a whole heap of disable-warning directives in the makefile before it finally compiled.
nukeykt has quit [Ping timeout: 260 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined ##yamahasynths
andlabs has joined ##yamahasynths
emily has quit [Remote host closed the connection]
emily has joined ##yamahasynths
Xyz_39809 has joined ##yamahasynths
Xyz39808 has quit [Ping timeout: 260 seconds]
<Sarayan>
so whitequark, using a soldering iron as a lamp now?
<KillaMaaki2>
Just had the realization that I think this thing is blowing up BEFORE it even runs that struct copy line. Starting to seriously think it's a timing issue, which probably means an interrupt-related bug. I really need to sort out some sort of serial debugging >.>
<andlabs>
what language?
<KillaMaaki2>
C compiled to 68000 running on an M68000 Verilog clone.
<andlabs>
you are doing the equivalent of move #$2700,sr, right?
<KillaMaaki2>
In this case, GCC emits a call to memcpy for any struct copy.
<andlabs>
ys, and when I did OS dev with gcc that fact annoyed me
<andlabs>
the standard defines a freestanding environment's requirements fs
<andlabs>
fs
<andlabs>
ffs
<andlabs>
I'll have to look it up
<andlabs>
anyway that sounds like you're being interrupted, ye
<andlabs>
s
<andlabs>
is this code running as supervisor mode?
<KillaMaaki2>
Yep.
<andlabs>
so yeah, see if sr is set correctly
<andlabs>
#$2700 disables all interrupts except IRQ7 (which should really be called NMI)
<andlabs>
(really #$27xx but still)
<andlabs>
also is your memcpy written in C by any chance?
<KillaMaaki2>
I have all interrupts enabled right now. The only interrupt which does anything besides immediately return is the vertical sync interrupt, which is tied to a VGA generator. That interrupt moves d0 - d7 and a0 - a6 onto the stack, jumps into a C handler, then restores d0 - d7 and a0 - a6 off of the stack before returning.
<KillaMaaki2>
Yes. It's a naive byte copy at the moment.
<KillaMaaki2>
No optimizations yet.
<andlabs>
hmm
<andlabs>
that wouldn't cause it btw, was just curious
<andlabs>
also what VGA generator?
<andlabs>
and are you able to hook this up to a debugger?
<KillaMaaki2>
Wrote my own in Verilog. Generates a 60Hz 640x480 signal which is fed to an HDMI transmitter on this board.
<KillaMaaki2>
I'm currently working on getting some form of serial output up and running
<andlabs>
does your CPU core not expose a TRACE or TRAPV line?
<andlabs>
er not TRAPV that's for oveflow lol
<KillaMaaki2>
There's no explicit trace line, but trace can be enabled in the status register.
grauw has quit []
natarii has joined ##yamahasynths
<Lord_Nightmare>
cr1901_modern: yes, its a gimp file, since its one of the free formats which supports layers
<cr1901_modern>
SVG isn't free?
<Lord_Nightmare>
i can't easily run inkscape with this stuff right now