SebRmv

Just uploaded a new improved version of the sound engine. Removers'lib 1.3.2 available right now!

Hello,

just fixed the way balance is computed and released the new version.

I think it is now what should be expected.

I also updated the cof file corresponding to example15, if you wish to retry.

By the way, I didn't mention that compared to my previous sound manager, volume scale is now logarithmic, not linear as it was before.

The same also applies now for balance. A balance of 8 corresponds to a centered voice, 16 means right only, 0 means left only.

Enjoy!

Wow, that is strange. Are you talking about the cof file I linked?

Have you tried to raise the volume of your TV?

 

I have the same problem, no sfx at start, but mod plays fine & sounds great.

 

EDIT: It's there, just very quiet.

Ok. That's what I expected. Try to change the balance of the voice with the joypad.

Maybe the way I handle balance of voice is not right.

Wow, that is strange. Are you talking about the cof file I linked?

Have you tried to raise the volume of your TV?

Here it is: http://removers.free.fr/softs/archives/example15.cof (this the COF corresponding to the C code)

By the way, I realized I didn't even changed the text of example15 (which is simply example4 recompiled with the new sound manager!): so just fixed that also! Oh, and oops, the display is not centered... sorry too lazy to fix that

edit: the red bar corresponds to the mod replay routine (which is still 68k code), not the Paula emulator resampling time! You probably guessed that 46 kHz is almost the limit of the new sound manager. (for 4 voices, I tested up to 52 kHz, but it can clearly still go higher... unfortunately DSP RAM is too small!)

As a matter of fact, I just released my own hacked version of JCP.

Used conjointly with the Removers library, you can open, read, write files from the Jaguar side very easily.

I used this hacked version of jcp to develop alpha version of Another World.

I'll try to release an example of use from the Jaguar side very soon, so stay tuned!

Hi everybody,

it is my pleasure to announce the immediate release of the Removers library 1.3.0 (as well as Jaguar C library 1.2.7).

The new version of the Removers library includes a freshly remade sound manager (a.k.a. Paula emulator), which is able to play 8 stereo voices at a replay frequency of 46 kHz.

I am particularly proud of the new design of this Paula emulator, and I hope it will solve the major issues (I think especially to bus contention) you may have encountered with the previous sound manager I did a long time ago now.

The only bad news about the new sound manager is that it fills (almost) entirely the DSP RAM so that the DSP is now devoted to sound generation.

I also added a new example (example15) which shows usage of the new sound manager. The good news is that its API is the same as the previous sound manager, so that you only need to change the linked object file: use now paula.o instead of sound.o.

This example includes a piece of assembly code which illustrates how to replay an Amiga module.

I hope you will enjoy this new release.

I would like to thank LinkoVitch who, with his work, gave me the motivation to rewrite entirely my sound engine ! I am very happy to have finally achieved this project I wanted to do since more than 2 years !

Do not hesitate to ask me questions, if you have any. On this thread, by PM or by email.

C U at http://removers.free.fr/softs/download.php !

Seb

edit: I also released binary distribs...

Great! I'll have a look at it tonight!

Great! Will definitely have a look at it!

Where can I download it? Is it open source?

The only way to recover from the 'network crash' is to reset the Jaguars.

If I remember rightly, ggn and sh3 were trying to play some of the hacked

Doom II levels that I did. Some of them are larger and more complex than

the original levels, but I doubt this would have had any ill effect on the

already bugged network code.. extra data due to the larger more complex

levels.

Thanks for the info

But is Doom crashed? Or is it possible to play again (alone and/or over the nerwork) without resetting the Jag?

Well, I think I am still quite far from getting a "light" workaround (if such a thing is possible).

By the way, what happens in Doom when network crashes?

I also observed that the duration of the liveness depends on the length of the message transmitted. (for the message "0123456789abcdef", it lasts only a few seconds)

No, this actually seems to be the message content!

If I send "aa", this works a long time.

If I send "01", the receiver dies quickly.

I think I found something!!!!!!!!!

It does not work yet, but I think I am on the way to get a workaround. So maybe someone here can experiment on his own.

While taking my shower, I had the crazy idea to write back the ASICLK value every time I get in the UART receiver interrupt (just before leaving interrupt handler).

Here are the details of the experiments.

On the PC side, I set my serial port to 57600 bauds, even parity control.

On the Jaguar side, same thing.

On the PC side, I launch the simple script:

while true; do echo -n "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" > /dev/ttyS0; done

With my patch, the UART receiver is alive during more than 10 seconds (I got more than 1 minute several times, my record is maybe 3 minutes)

Without my patch, the UART receiver dies very quickly (a few seconds in the best case)

I also observed that the duration of the liveness depends on the length of the message transmitted. (for the message "0123456789abcdef", it lasts only a few seconds)

Why not, if it works fine ?

(in embedded electronics, it's not rare to emulate features in software when the hardware is buggy -- or too expensive to afford)

Yes, I know that, since I work in a company that does embedded platforms.

But I feel it is a waste of DSP power until I got the proof it is impossible to do an other way on the Jag.

Do you think other people that did a workaround for the UART bug uses a method similar to yours?

The stop bit level and the idle level (when you're not transmitting anything) are the same. Which means (for example) that sending a byte with 1 stop bit, then waitng for the duration of 2 bits before sending the next byte, is the same as sending the first byte with 3 stop bits.

 

What they mean is that the delay between incoming bytes should be an integral multiple of the bit duration. If that's true, that means that if you send a continuous stream of bytes, you should never run into the problem ; that would be interesting to try.

If it works, it would be easy to work around the problem : when you don't have anything to transmit, just send "filler" bytes to keep the UART busy.

(note that it's problematic for network with more than 2 consoles for collision reasons)

I have not understood.

Indeded, that's the problem I had too, and I couldn't find a way to reset it either. So I decided to forgot about the broken UART receiver completely and do it in software

Ok. I finally understood what you did (or maybe I understood before but forgot since that time ).

But Software UART, nobody wants to do that in real life, doesn't it? (especially when a hardware chip is supposed to do it!)

And did you notice this thing regarding the parity?

I can't make sense of the remark in the "known bugs" sections about UART where they describe a possible workaround.

In particular, I don't understand the following:

"Subsequent bytes should be exactly aligned (i.e. 2, 3 or 4 stop bits exactly, before the next start bit)"

Can you make sense of that? I suspect the key is there.

How is it possible to transmit several stop bits?

I played a bit this night and unfortunately, it is not that easy!

The receiver seems to become deaf if we stress it too much and I have not found the way to reset it until now.

By the way, it is quite cumbersome to set the UART interrupt handler.

Actually, it is the GPU that processes the request coming from Jerry.

(IT handler at GPU_RAM+$10)

Hello,

these days, I have powered up my Jaguar and played a bit with the UART controller.

On my PC, I used putty to communicate on the serial link with the Jag. (I have a RS232 cable plugged in the Jaglink2 on the Jaguar side)

I observed that the parity bit in ASICTRL has the opposite meaning of what is said in Jag_v8. Am I the first one to observe this?

(i.e. when bit #0 of ASICTRL is set to 1, and parity control is enabled, even parity is active)

I also observed the problem of corrupted characters (left shifted by 1 bit).

However, the error bits of the ASISTAT register seems to be set correctly.

So by just clearing the errors and dropping the received character, I guess it is easy to recover from this error.

(this seems to work in practice)

This means that a simple protocol to transmit packets over UART would work.

(I mean transmitting packets on an unreliable channel is doable, if not everything is lost of course!)

Are there any other bugs I should be aware in the UART? If yes, how can I trigger them?

For the moment, I programmed the UART just by polling the ASISTAT register on the 68k side.

I intend to experiment a bit with the DSP interrupt and try to see if I can get something working using these few observations.

Has somebody already tried these ideas? (I guess yes, but we never know)

Forget the Removers bomberman clone, there is very little chance that it will be finished this year (or even in the future). My programming activity on the Jaguar is almost zero since several months.

However, I promise that Another World will be distributed as soon as possible.

I voted Laddybugged but I would also love to play Robinson Requiem on my Jag.

Happy new year!

Ok, so I'll have a look at the Windows port (if I am courageous enough)

Here are the converted image (in ASM format)

NEBULA.zip

Here is the code I used to test the four images... Just change the way VMODE is initialised depending on the image format.

#include <jagdefs.h>
#include <jagtypes.h>
#include <stdlib.h>

#include <interrupt.h>
#include <display.h>
#include <sprite.h>

#include <sound.h>

#include <joypad.h>

#include <console.h>

extern phrase image;

int main(int argc, char *argv[]) {
  SET_SHORT_INT(CRY16|CSYNC|BGEN|PWIDTH4|VIDEN,VMODE);     // for CRY16
//  SET_SHORT_INT(RGB16|CSYNC|BGEN|PWIDTH4|VIDEN,VMODE);     // for RGB16
//  SET_SHORT_INT(CSYNC|BGEN|PWIDTH4|VIDEN|VARMOD,VMODE);     // for CRY15/RGB15
  init_interrupts();
  init_display_driver();

  display *d = new_display(0);
  d->x = 16;
  d->y = 8;

  show_display(d);

  sprite *s = new_sprite(320,240,0,0,DEPTH16,&image);
  attach_sprite_to_display_at_layer(s,d,1);

  while(1) {
    vsync();
  }

  return 0;
}

Would love to learn the final word of the story. Cyrano, could you please post the piece of code you are using? I can post mine if you wish (but it uses my library).

Anyway, I fixed a bug in my converter. The 15 bits mode were flawed, thanks for having spotted that (even if it seems it might be by accident )

The bad news is that I have to recompile a Windows compatible version if I want to make a binary distrib...

I tried all 4 in my app and they all looked like random data...

 

however your header in the .s says 320x200

 

the image i uploaded was 340x255.... so that might explain that

yes, these are 320x200 images (this should correspond to the bmp you posted above)