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
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 256 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Read error: Connection reset by peer]
andlabs has joined ##yamahasynths
andlabs has quit [Read error: Connection reset by peer]
andlabs has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 260 seconds]
Ultrasauce_ has joined ##yamahasynths
TD--Linux has joined ##yamahasynths
Ultrasauce has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<andlabs>
and of course Wonder Library hardcodes the $016000 address
<andlabs>
it also doesn't help that the only emulator to support this type of environment is Kega Fusion and it only supports it with the game Flux (a music visualizer released in Europe near the end of the system's lifetime), and that appears to be hardcoded
<Foone>
ahh.
<andlabs>
also the Laseractive entry is worth pointing out
<andlabs>
because it's absolutely ridiculous
<Foone>
one of those fun cases where it'd be neat to find out the answer but you'd be fighting an uphill battle to get there. gotta find the discs, it's in another language, you gotta hack the emulators, etc
<andlabs>
in my case: Sega CDs are getting expensive again for no goddamn good reason (someone told me it was because many of them are dying but *still*) and I forgot to buy a power supply for the one I did get
<andlabs>
so now I'm waiting for that
<andlabs>
I did get a real disc though (I forget which) so there's that
<andlabs>
I would have used the demonstration ISO that comes with that software you hacked if not
<Stilett0>
started sending Foone info on some of the "weird shit" USB devices I've stumbled across over the years. This one's pretty mundane but also pretty bizarre. I think I may have one in storage. https://twitter.com/stilett0_/status/1259511435245293571
<balrog>
Stilett0: I probably asked you but you wouldn't have any USB to SCSI, right?
<Stilett0>
nope
<Stilett0>
this guy's by far one of the weirdest USB devices I've ever seen for sale (not counting novelty shit): USB 2.0 to Firewire 1394b ! Explicitly for use with DV devices tho, it doesn't support the full Firewire feature set. http://www.pixela.co.jp/en/products/tv_capture/pix_uvcd_u1w/
<Stilett0>
(he opened up the usage to other devices tho)
<Stilett0>
sorry, meant IEEE 1394, not 1394b. Force of habit...
ej5 has quit [Quit: Leaving]
ej5 has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<cr1901_modern>
This may be a silly q, but since this is a 68k fan club: What exactly is a 68k "bus error"? How does the 68k detect "non existent or faulty" hardware?
<cr1901_modern>
And why don't other CPUs of the era have something similar?
<ZirconiumX>
I bet they do, actually
<ZirconiumX>
But first I need to find a 68k pinout
<ZirconiumX>
Pin 22 is called BERR
<ZirconiumX>
And based on my experience with other chips, if it gets asserted you get a bus error exception
<ZirconiumX>
Or else if a transaction is made that doesn't get acknowledged after a given number of cycles
<ZirconiumX>
The faulty bit is that stuff is only meant to assert "bus error" in case something goes badly wrong
<ZirconiumX>
And if hardware doesn't exist, then there'll be no acknowledgement of the transaction after a given period
<ZirconiumX>
cr1901_modern: ^
<cr1901_modern>
>And if hardware doesn't exist, then there'll be no acknowledgement of the transaction after a given period
<cr1901_modern>
Yes, that is the crux of my question
<cr1901_modern>
68k was definitely interfaced to e.g. TTL chips that have no way to acknowledge that a write or read was received
<cr1901_modern>
I thought maybe it did some analog tricks to recognize that "there's nothing there"
<cr1901_modern>
But I didn't know about the BERR pin ;lol
<superctr_>
the BERR pin is funny though, i think it was specifically intended for use in MMUs (along with HALT)
<superctr_>
some old systems had two 68k running in lockstep, when one encountered a page fault (=bus error exception), the MMU could halt the second one since the 68000 had a bug where it didn't push enough internal state to the stack
<superctr_>
the manual mentions how the 68000 halt behaves differently depending on if BERR is (externally) asserted or not, so it's a bidirectional pin
<superctr_>
i think the megadrive only uses DTACK, but i might be incorrect yet again. It has no MMU so there really isn't any need to use the other signals
<natarii>
yes afaik BERR is not hooked up to anything
<cr1901_modern>
re-run termination == "retry the current insn"?
<superctr_>
not the whole instruction, just the memory access cycle, i think
<superctr_>
a 68000 can have up to multiple memory access cycles (for example 4 on instructions with two 32-bit operands, and even more for MOVEM) per instruction, so it makes sense just to rerun the one that caused the fault
<superctr_>
plus any memory access cycles to actually fetch the instruction, but i'd hope those would be mapped properly in the first place :P
<cr1901_modern>
>for example 4 on instructions with two 32-bit operands
<cr1901_modern>
Oh right, I forgot that 68k can do mem-to-mem move in one insn
<superctr_>
the 68000 also has a simple instruction prefetch, if that caused a fault after all, it would be hard to determine where to start over from, if it didn't just rerun the faulting access
<cr1901_modern>
8086/8 has a Queue Status output that allows you to track when an insn has exited prefetch. Maybe 68k designers decided that status info wasn't important
<cr1901_modern>
https://www.youtube.com/watch?v=bQ_qfd1hUNQ Actually... why does Sonic 1 recover enough after illegal instruction to try and execute more code (only to immediately print another error msg)?
<cr1901_modern>
I thought each exception handler went into infinite loop after printing the msg