Raven. A homemade Atari-like computer

[luciodra]

Since last night I noticed that the audio on the Yamaha chip no longer works: neither in Castway, Sndplay, the click of the keys and not even Test ym...
This is both in Emutos and Magic. What could have happened?

[luciodra]

I tried running selftest from terminal:

Code: Select all

Raven selftest
 YM2149...
  Byte writes (you should hear a bell sound)
  Long writes (you should hear a bell sound)
  OK
 MFP1:R/W...
  OK
 MFP2:R/W...
  OK

instead of the bell you hear a muffled noise.

I tried changing the Yamaha chip, removing ideswap and ckbd but nothing.
@agranlund
What could I have damaged by removing and adding ideswap?

The Picogus audio work.

[luciodra]

@agranlund

I ran these tests that you suggested some time ago...

Code: Select all

> 
> pb $a1000800 $0b
> 
> pb $a1000802 $55
> 
> pb $a1000800
$ff
> 
> pb $a1000a27
$55
> 
> pb $a1000a27 $55
> 
> pb $a1000a27
$55
> 
> pb $a0000a27
$55
> pb $a0000a27 $55
> 
> pb $a0000a27
$55
> 
> 

It seems to me that the Yamaha chip responds incorrectly.
MFP1 and MFP2 are correct, right?

[luciodra]

Actually, some distorted noises come out of the Raven's audio output that sound like the playback.

[agranlund]

@agranlund
I ran these tests that you suggested some time ago...

It seems to me that the Yamaha chip responds incorrectly.
MFP1 and MFP2 are correct, right?

Yes that looks like it's either not responding at all or incorrectly :/
Perhaps removing the YM2149, check that pins are nice and clean, and re-seat it in the socket?

The Iksi ATF22V10 also plays a part in controlling the YM chip so maybe that too.
But then again this one's less likely since it helps other things too, including IDE which I suppose is working.

It's hard to come up with recommendation on what to test without putting a scope on the machine and checking that pins behave as expected.

You could try removing other removable things. I suppose IDE + ISA cards. And run the test again in the monitor.
In the off chance that one had a slightly dodgy connection, causing it to think it was being addressed, and thus defiling the data bus.
But then again $FF usually indicates nothing responded so that's really a long shot.

I don't suppose you have another spare YM2149 just laying around to check?

[luciodra]

Yes that looks like it's either not responding at all or incorrectly :/
Perhaps removing the YM2149, check that pins are nice and clean, and re-seat it in the socket?

The Iksi ATF22V10 also plays a part in controlling the YM chip so maybe that too.
But then again this one's less likely since it helps other things too, including IDE which I suppose is working.

It's hard to come up with recommendation on what to test without putting a scope on the machine and checking that pins behave as expected.

You could try removing other removable things. I suppose IDE + ISA cards. And run the test again in the monitor.
In the off chance that one had a slightly dodgy connection, causing it to think it was being addressed, and thus defiling the data bus.
But then again $FF usually indicates nothing responded so that's really a long shot.

I don't suppose you have another spare YM2149 just laying around to check?

Raven everything works, apart from the distorted audio output. I tried 4 YM2149 chips (!) but the result is the same.
When you refer to ATF22V10, are you thinking of replacement or reprogramming?

Thank you so much !

[luciodra]

I tried reprogramming iksi

IMG_2767.jpg (702.76 KiB) Viewed 200 times

and everything seems fine.
Even removing all the cards no results.

Last little clue: when I turn it on for the first time, after the computer has been off for a few hours, some artifacts appear on the screen in Xboot. Then nothing more...

[agranlund]

Fueled by inspiration from finally trying out my new ESS+GUS soundcard I re-started working on some kind of centralized soundsystem thing.
It's just a start, perhaps no more than a proof of concept, and a long way off still

Drivers themselves are external plugins and these can publish one or several of the following devices to the system:
midi-out, midi-in, audio-out, audio-in, mixer, chip

- mixer is something that has a bunch of named controls. what they do is up to the driver but usually these are volume controls.
User should be able to freely re-bind individual controls to their xbios counterpart and this becomes especially interesting when you have multiple soundcard. (In my setup I may want to use "GUS:master" as the xbios master volume but "SB:fm" for the xbios fm volume)

- chip is a named "raw" device which can only expose functions for reading/writing its registers.
Not very exciting for the end user but quite nice for developers.

Taking OPL as an example. Assuming a driver has publishing something it calls "OPL3", a game could do something like this:

Code: Select all

dev = rvsnd->Find(RVSND_DEVTYPE_CHIP, 0, "OPL3");
dev->write(reg, data);

And now the game doesn't need to know where that chip is, it just needs to talk to the driver which more or less has as its only purpose to abstract the bus-layer.

The new Midi-out OPL softsynth driver is using this. Unlike the old one, it has no idea what an ISA bus is and just asks rvsnd if there is a chip driver registered for something called "OPL3" or "OPL2".
So if someone puts an OPL on a cartridge, makes an rvsnd driver, then the above should automatically just work with that thing too.


A lot of this is still theory and the biggest part is still missing which is audio out and the xbios Falcon dma-sound wrapper.
Right now there is only an OPL chip driver for ISA bus + a couple of Midi drivers. And a very basic control/test cmdline application.
Next up would be to start on the soundblaster driver, which should lead to starting to work on getting audio and mixer device stuff in place.

Having a central soundsystem let's you do unnecessary stuff like swapping at runtime which device you want xbios midi to go to:



(and also, individual driver binaries become hilariously tiny as they only need to do what is specific for it.. Raven midiport driver is ~400 bytes and the MPU401 driver is ~800 bytes large)

While I'm doing this for Raven I do intend on possibly using this on the V4SA and Atari ST too.

On AtariST it could be useful for sound devices such as Covox, MV16 etc.. I remember writing multiple codepaths in ScummST for supporting a couple of cartridges, Covox, and samples through YM2149 -- then I more or less copy/pasted that code into BasiliskII.
Having those as drivers for something like this might make more sense.

[LarryL]

WIP Nessi firmware for the adventurous to test.
NESSI_WIP_251029.jed.zip

Thanks to @PhilC I got back to looking at bus timing in the Nessi firmware.
Something I've felt has been needed for a while but I haven't done because it stopped being fun last time I went there.
This time I am enjoying it again.

This version has been tested to work on my computer with 50,48,40,32,25 and 4(!) mhz oscillator. And with both 2x and 1x cpu speed.
Something that wasn't possible before due to slightly dodgy and timing sensitive cpu<->mainbus and cpu<->68150 communication.
This version will become the next release assuming it works fine on not just my computer.

And a word of caution, even though I am notoriously bad at doing so myself, I'll have to do the usual recommendation of backing up your disk in case there are bugs that cause IDE access errrors or something like that. In fact, it's probably always good to have backups.. or so they say

Hi @agranlund

Like to come back to his topic with the WIP firmware for Nessi.
This made my boards working with x1 and lower clocks than 48MHz
But now I have found out, that there seems to be no difference at all between x1 and x2 anymore…
I thought this was a problem in board with S/N #17 (which I am checking right now).
But my board with S/N #15 behaves exactly the same.

With Gembench and with Coremark68k I am getting exact same results, regardless of jumpers being in x1 or x2 position (switching J102,104,105 from 1-2 to 2-3)

Can this be?
…maybe I am doing something wrong…

I see performance differences between 32, 40 and 48MHz, but not between x1 and x2

BTW: none of my boards will even start with 25MHz and one is completely unstable with 32MHz (I suspect the 68150FN33 here, the others have FN40 equipped).
Interestingly the one with a FN33 works with 40, but not with 48 (expected) and not with 32MHz (unexpected)

Cheers
Michael

[Atarian Computing]

Fueled by inspiration from finally trying out my new ESS+GUS soundcard I re-started working on some kind of centralized soundsystem thing.
It's just a start, perhaps no more than a proof of concept, and a long way off still

Drivers themselves are external plugins and these can publish one or several of the following devices to the system:
midi-out, midi-in, audio-out, audio-in, mixer, chip

- mixer is something that has a bunch of named controls. what they do is up to the driver but usually these are volume controls.
User should be able to freely re-bind individual controls to their xbios counterpart and this becomes especially interesting when you have multiple soundcard. (In my setup I may want to use "GUS:master" as the xbios master volume but "SB:fm" for the xbios fm volume)

- chip is a named "raw" device which can only expose functions for reading/writing its registers.
Not very exciting for the end user but quite nice for developers.

Taking OPL as an example. Assuming a driver has publishing something it calls "OPL3", a game could do something like this:

Code: Select all

dev = rvsnd->Find(RVSND_DEVTYPE_CHIP, 0, "OPL3");
dev->write(reg, data);

And now the game doesn't need to know where that chip is, it just needs to talk to the driver which more or less has as its only purpose to abstract the bus-layer.

The new Midi-out OPL softsynth driver is using this. Unlike the old one, it has no idea what an ISA bus is and just asks rvsnd if there is a chip driver registered for something called "OPL3" or "OPL2".
So if someone puts an OPL on a cartridge, makes an rvsnd driver, then the above should automatically just work with that thing too.


A lot of this is still theory and the biggest part is still missing which is audio out and the xbios Falcon dma-sound wrapper.
Right now there is only an OPL chip driver for ISA bus + a couple of Midi drivers. And a very basic control/test cmdline application.
Next up would be to start on the soundblaster driver, which should lead to starting to work on getting audio and mixer device stuff in place.

Having a central soundsystem let's you do unnecessary stuff like swapping at runtime which device you want xbios midi to go to:



(and also, individual driver binaries become hilariously tiny as they only need to do what is specific for it.. Raven midiport driver is ~400 bytes and the MPU401 driver is ~800 bytes large)

While I'm doing this for Raven I do intend on possibly using this on the V4SA and Atari ST too.

On AtariST it could be useful for sound devices such as Covox, MV16 etc.. I remember writing multiple codepaths in ScummST for supporting a couple of cartridges, Covox, and samples through YM2149 -- then I more or less copy/pasted that code into BasiliskII.
Having those as drivers for something like this might make more sense.

Amazing. Thanks. Looking forward to updates on this.