TADPCM

GO TO ADMIN PANEL > ADD-ONS AND INSTALL VERTIFORO SIDEBAR TO SEE FORUMS AND SIDEBAR

slobu

New Member
Joined
Jun 27, 2011
Messages
23
Points
1
I've already asked the person involved in the BasiEgaXorz example but I thought I'd go to the source as well (for help).

This is the post covering TADPCM use in BEX:

http://devster.proboards.com/index.cgi?board=basiegaxorz&action=display&thread=768

One of the steps is to use a file called pcm_player.asm but I see it nowhere. I've tried to find Chilly Willys original TADPCM driver but the posts don't seem to be necessarily for TADPCM. Some refer to a x32 driver and another to a compression method called "CVSD"

Why am I not following the BasiEgaXorz example properly? I've got a bad feeling I'm missing something obvious.
 

slobu

New Member
Joined
Jun 27, 2011
Messages
23
Points
1
Chilly Willy said:
The thread on CVSD compression has the TADPCM demo as well. It was demo number 4. You can download it directly from here:

musicdemo4.7z
Thank for the clarification! I did a check for the code and labels given in Step 4 for the TADPCM example in BEX and they are not present in any of the files in musicdemo4.7z

Unless I'm really, REALLY missing the point Sega16 failed to include his specific driver a.k.a. pcm_player.asm
 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
54
Website
groups.google.com
slobu said:
Thank for the clarification! I did a check for the code and labels given in Step 4 for the TADPCM example in BEX and they are not present in any of the files in musicdemo4.7z

Unless I'm really, REALLY missing the point Sega16 failed to include his specific driver a.k.a. pcm_player.asm
It's probably just z80_tadpcm.o80 converted into assembly dc.b statements. My original musicdemo4 is C code with z80 assembly; sega-16 used that to make a BEX example. The only thing in common is the driver... which appears he forgot in the archive. From the SpritesMind thread, you seem to have z80_tadpcm.o80, so you can either do the BEX version of incbin, or run it through bin2s to get an assembly file of the driver data.
 

vexatious

Ban Hammered
Joined
Jun 23, 2013
Messages
19
Points
3
Hey Chilly, you think this driver would fit into a small enough size of cache if ported to SH2? Think it would be great to see this used on your Wolfenstein 3D port on 32X, or Sega Saturn stuff. Even if it did fit, could you avoid BUS stalls when RAM or ROM (cartridge) data is accessed from second SH2 (so both SH2's execute simultaneously without waiting)?

Maybe this would run good on the 68000 (more specifically the Saturn's, or Genesis with 32X and/or Sega CD).

It'd be great to drive higher quality audio given the limited ram space on the Sega consoles, and at least match the equivalent of playstation or other hardware ADPCM decoding.

Regards
 

Chilly Willy

New Member
Joined
Jan 21, 2006
Messages
256
Points
16
Age
54
Website
groups.google.com
Yes, the decoding of TADPCM would easily fit in the SH2 cache. While it could be written in assembly, the SH2 would be plenty fast enough to use the C code found in the tadpcm2pcm.c decoder file included in the demo. The SH2 can handle any form of ADPCM in real-time for any reasonable sample rate (say 22kHz). In fact, you may have seen my other 32X sound demos, like the ones doing ogg playing with the SH2. That uses the lowmem branch of Tremor to decode low bitrate streams, and could use a bit more optimization, but the SH2 in the 32X (or Saturn by extension) is quick enough to handle ogg-vorbis decoding in real-time.
 

vexatious

Ban Hammered
Joined
Jun 23, 2013
Messages
19
Points
3
Chilly Willy said:
Yes, the decoding of TADPCM would easily fit in the SH2 cache. While it could be written in assembly, the SH2 would be plenty fast enough to use the C code found in the tadpcm2pcm.c decoder file included in the demo.
Sorry but I forgot that this would actually be troublesome to run on a SH2, since sound would be accessed from RAM or ROM; this would stall the bus if both SH2's were heavily used simultaneously (does this even happen on 32x?).

Can bus contention be avoided if the 68000 accesses RAM or ROM with SH2's running?

Think it'd be feasible to make a library for special effect algorithms to run on the second SH2 (reverb, etc); something that doesn't access ROM or RAM but uses its own data from cache to avoid bus contention (preferably something graphical like custom masks where mesh transparency would normally be used, but real 3D transparency applied instead; other stuff too).
 
Top