Search options (Page 25 of 40)

2016-11-16 21:55:38

Ok, gotcha. Interesting point indeed. Well, it can always be faked via digi method (as can any other waveform at a minor cost), but the real nice thing would be to exploit this via an actual algorithm. So in abstract terms, the question would be how to translate the amplitude levels in H into the time domain. Pity that it doesn't work with pin pulses, that would've been my first try, too. Hmm, what about phase inversion? As you may remember volume can be controlled like this:

add hl,de
ld a,h
cp #80
sbc a,a
out (#fe),a
exx
add hl,de
ld a,h
cp #80
sbc a,a
out (#fe),a

where the offset between HL and HL' will determine the volume (HL=0, HL'=#8000 is most quiet; perceived volume change is logarithmic). Perhaps it's possible to modulate HL' by H somehow (HL' += (256 - H) or something like that)?

2016-11-16 12:51:14

Ok, understood. It's essentially the same method I'm using in my digi-core engines, except that my sound output and calculations are fully interlaced (eg. during a loop iteration, I calculate the volume level for the next iteration, then jump at the end of the loop). That way, you can squeeze some more levels out (in theory, 224/8=28 levels would be possible, but there are some issues with that, so ~20 levels is more realistic).

Shiru, is this what you were trying to get at? Or did you have something else in mind?

2016-11-15 22:12:49

@Hikaru: I don't quite understand your sample code. Is the .lvNN part executed every time, and then it will jump to .lv00-.lvXY, from where it'll loop back to .lvNN? Is beeper turned off before executing .lvNN? Wouldn't that give an overall very low volume?

Another thing that I was wondering about. In BetaPhase, phase channels are calculated as

   add hl,bc
   ex de,hl
   add hl,bc
   ld a,h
   xor d            ;or|and|xor
   out (#fe),a

which saves at least one register pair compared to a full Phaser implementation. During testing, I realized that actually 8-bit frequency dividers are enough in conjunction with scalers. So the above could be rewritten as

   ld hl,0
loop:
   ld a,b
   add a,nn
   ld b,a
   sbc a,a
   add a,h
   ld h,a
   ld a,c
   add a,nn
   ld c,a
   sbc a,a
   add a,l
   ld l,a
   xor h
   ds 2             ;2x scaler (rrca/rlca)
   out (#fe),a

freeing up another register pair in the process.
So here's the question: Can't we get rid of one of the counters somehow (H,L in the above example)? In other words, is it possible to generate similar bitstreams as above (or at least something that offers timbre variation), but with a combined upper counter byte for both of the operators?

2016-11-15 21:37:00

Yes, I knew about this one, but it contains only 2/4 entries.

2016-11-15 10:40:23

Not sure I understand correctly what you mean, could you provide a pseudo-code or asm example?

The only thing I could think of right now would be to implement it via a digi core (like in fluidcore, zbmod, etc). But that would be pretty inefficient, as you'd need 4 shifts to derive a suitable volume value from H. So pointing to a predefined table of wave data would be much faster (but at the cost of using up an extra register, of course).

Speaking of digi core, there is a phenomenon that I haven't quite understood yet. When the overall calculated volume is >50% for longer periods, the actual output volume starts to ramp up, producing a saw-wave like timbre (check octode2k16, it is very noticable in the demo tune, when bass kicks in). My assumption was that this happens because the speaker cone does not have enough time to retract in "off" periods, and thus will start to ramp up volume. However, I made some code to specifically trigger that behaviour (by keeping calculated volume continually above certain thresholds), and it wouldn't produce any conclusive/consistent results.

2016-11-15 10:06:01

Alright, I can live with that
Are the works available for download somewhere?

2016-11-11 10:14:02

Hmm, interesting. As far as I understand the schematics (read: not very far), it might only affect RF out, though?

2016-11-10 10:45:46

Good suggestion, that might indeed be useful. I think I had thought about it at some point, but completely forgot along the way. I'll put it on my to-do list for 2.30

2016-11-05 19:27:11

So I was wondering, would it be possible to apply the GTIA method from Atari 8-bit to the 16-bitters somehow? Ie. produce sound without using YM or DMA sound? Any ideas?

2016-10-31 14:52:01

I'm also still very much intending to add XM import at some point, though there are more, uh, pressing problems at the moment

2016-10-31 14:42:53

Alright, we've got a working PhaseSqueek config! It's pretty complete, except that MDAL doesn't support tables that aren't linked from a pattern yet.
For example something like this doesn't work yet:

:SEQUENCE
    pattern1
:pattern1
    A=c1, FX=fx1
    .
:fx1
   A=c1
   A=d1
   A=e1
   FXJUMP=fx2
:fx2
   A=f1
   A=g1
   FXJUMP=fx2

I have to say, MDAL makes things easier, but the engine is still a major p.i.t.a. to use. You have to be very careful especially when constructing tables, because of the data format quirks. For example, if you have A and B set in your pattern, and want to use a table that modifies A, then you should set B again at the start of the table. This is because the player expects a value for B when A is set, but mdalc has no means of knowing what that value should be, and thus will fall back to the default value if you don't tell it to do otherwise. (Setting the value once is enough, mdalc will use the value that was last set from this point on). Likewise, SIDA requires SIDB, ESA, and ESB and vice versa. Also, when in doubt, use PAB/PCD=0 to reset the phase.

2016-10-28 21:55:49

Not 100% there yet with PhaseSqueek, some details are still missing. For example, I've recently added label prefixes, to minimize the change of name collisions (eg. if you name a pattern "pattern1", it'll be named "mdp_pattern1" in the asm output. However, I still need to implement this for commands that set a pointer (which the PhaseSqueek config uses). Once these things are taken care of though, MDAL should be able to support almost all existing beeper engines, except those that use multi-track sequences and/or samples.

2016-10-28 15:51:33

I've got some very good news: The core table parser is implemented and working. In other words, MDAL just generated the first complete and (more or less) working music.asm for PhaseSqueek. There's a number of things that still need tweaking, but we're definately getting there.

2016-10-28 15:47:46

I want to make an entry, but I don't know if I will have the time. Especially considering deadline is 1 week before the party, aka next Friday.

2016-10-28 15:45:10

Ahahaha, yes! Me <3 Speedcore. Also, this is a whole new level of "Mario on a rave"

2016-10-26 14:58:09

Cheers 0r4, welcome aboard! Of course we talk about 1-bit here most of the time, but we like 8-bit, too

2016-10-26 14:45:26

Made quite some progress on the back end today. There's also a couple of front end changes:

- The [loop] command is now [LOOP], for consistency since all commands are uppercase in MDAL.
- // comments should now work everywhere.
- Block comments (/* ... */) are now available.

2016-10-25 16:23:52

MDAL config available now in the MDAL repo Redownload the engine, too, if you want to use "b" instead of "h" as a note name.

2016-10-25 15:59:32

Oh, that turned out really nice! Too bad Soundcloud made such a mess of the render. I'm still trying to figure out how that happens, sometimes their rendering is fine and sometimes they botch the tracks completely.

2016-10-25 12:03:11

Updated BetaPhase on github, and also updated the MDAL config accordingly.
If you want to keep using the old version, just rename the old BetaPhase.cfg to something like BetaPhaseOld.cfg, and use that name for the CONFIG= command. Generally speaking though, MDAL modules made for BetaPhase 0.1 should be mostly compatible with the new 0.2, except for the following:
- DMOD is now called DMOD1 (because there's also a DMOD2 command now)
- PSCA2/PSCB2 are now pre-scalers

A special note about the new NOISE command - the current implementation is a bit awkward. Basically, when you enable NOISE, you must also set PSCA1=0 and PSCA2=0. Likewise, when disabling noise, you should set PSCA1/2 to a value of your choice. You might as well ignore the noise command and just set PSCA1=$cb and PSCA2=2. The problem exists because I didn't forsee this particular use case where an internal masking command (SET_IF) should overwrite an existing value rather than ORing to it. I'll need to implement another config flag to avoid this mess but this might take a while.

2016-10-24 17:25:39

Little sneak preview of the next version on BetaPhase attached below.

Changes:
+ Ch1/2 post-scalers are now pre-scalers
- Old (slow) Ch1 duty mod removed
+ New Ch1 duty mod, can be heard in the intro (using osc sync method - runs a bit too fast for my taste, so it's not terribly useful in any case)
+ Ch1 noise support
+ Ch2 duty mod w/ custom sweep speed, can be heard in the interlude (using Shiru's implementation, but with a variable counter increase every 256 loops instead of constant increase every loop)

2016-10-23 11:12:30

Ok, noted the problem with the comments in sequence. The current pattern parser needs some reworking anyway, so I'll fix this problem when I get around to that. I'll think about the comma thing too, it'll require some extra code but can't hurt to make the parser more robust in this respect.

Since you were wondering, I'll try to give a better explanation of what the effect settings do.

The basic thing you have to understand is that the first two channels each use two semi-independant oscillators. Semi-independant because they share the same frequency divider ("A" resp. "B"). The output of the two oscillators is combined using the MIXA resp. MIXB method. This works the same way as in Shiru's Phaser engines (namely Phaser2/3, Phaser1 has only XOR mixing).

Before the mixing, a pre-scaler is applied to the first oscillator (PSCA1/PSCB1). This prescaler will shift output from the first osc up or down by one octave. After mixing, a post-scaler is applied to the combined output (PSCA2/PSCB2), which again shifts one octave up or down. This feature will probably be removed in favour of a second pre-scaler in the next version, because it's not really necessary (I was originally afraid that tone range would be insufficient, but that seems to be not the case).

On channel 1, there's also the duty modulator (DMOD), which should theoretically do what the "Duty Sweep" effect in HT2 ch2 does. However, the implementation is so slow that the effect is barely noticable - I'll probably replace it with something better in the next version as well.

Last but not least, there's the phase offset (PHA/PHB). The value you enter here is used to initialize the second oscillator before the sound loop (the first osc is always initialized to 0). If you don't use the pre-scaler and set MIXx=xor, this will essentially act as a duty setting (4xx/5xx/6xx in HT2). Setting PHx to $1000 will give a 50:50 square wave, $800 would give 25:75. There's no point in using values >$1000 unless you have PSCx2 set to "down" - in this case, $2000 will give 50:50 duty. Likewise, if PSCx2 is set to "up", $800 will be the max.

Channel 3 on the other hand has only one oscillator. PSCC is a post-scaler. Here, post-scaling makes sense because it has an effect on slide speed.

Hope that makes sense

2016-10-22 12:19:30

Thanks for your input mate, always appreciated!

garvalf wrote:

A little feedback.
First,
I think the parser could be less strict, for example you can't write:
A=a3, C=d2,
the last comma prevents to compile the song.
As long as there is no data except space, tab or line break, it could consider the comma doesn't exist.

I'll have to think about that. It would require some rather big changes to the compiler atm.

garvalf wrote:

I'd like to see a comment mark (for example to comment a part so it won't play during the rendering)

Single line comment is //
I'll put block comments on the to-do list.

garvalf wrote:

I like the idea of columns for entering notes. I has an interesting effect, you don't have to enter the value of some notes, like that:

You can totally do that, mdalc doesn't care about formatting except for line breaks.

garvalf wrote:

I think in addition to the current behaviour, it might worth adding, if possible, independent patterns, it means a pattern could contain only one voice, then you would mix the patterns together for different variations. The current behaviour is like on milkytracker, beepola or vortex tracker, I was thinking to something like on sidwizard or goattracker.

I definately plan to implement this, as there are some beeper engines that actually require data in this format (zx16, for example). However, it'll be a while before I get around to this. First, I want to finish preliminary documentation, clean up the code, and implement tables.

garvalf wrote:

(edit) thanks for the brackets addition, I'll have a look at it. Also for the value, what is correct, PHA=$800 or PHA=800, or is it the same?

With $ prefix, it's a hex number so PHA=$800 == PHA=2048

garvalf wrote:

I don't understand all the pattern commands effects, but I'll have a try.
In the betaphase.txt it's written
MIXB Set mixing mode channel 1
I guess it's:
MIXB Set mixing mode channel 2

Ah yes, of course. Well spotted

2016-10-22 11:24:44

Nice little tune And glad to see that MDAL doesn't break immediately when other people use it

In other news, structuring with brackets in patterns is now possible. Just don't skip any of the commas, like I wrote above.
Also I believe I know where that glitch is coming from. Slides in BetaPhase don't stop when they reach the limit. So since the speed is falling back to $10 at the beginning of ptn1, the slide wraps to $ffxx and that's what's causing the glitch. Can't do much about that

2016-10-21 21:31:13

garvalf wrote:

ah yes, German notation... I was wondering.
Is it possible to use flat as well?

Yes. It's a matter of adjusting the equates.h file, MDAL itself doesn't care what you feed it (for now, at least).

garvalf wrote:

Just saying, in abc flat is _ before the note, ^ is for sharp and = for natural (but not applicable in mdal). So ^f2 would be f2 sharp and _g2 would be g2 flat.

Any special characters are likely to cause trouble with assemblers, unfortunately. For pasmo, ^ would be interpreted as XOR, and _xxx is a local label. For this reason, MDAL doesn't accept special chars in strings atm (it shouldn't, at least, not sure if I actually implemented that check already). On the long run, I could possibly work out a standardized pitch notation in MDAL, but for the time being it's not really feasible.

garvalf wrote:

I think you made something great with MDAL. It's perfectly suitable for this kind of music. The only criticism I could say is I find it less readable to get all the info on the same level for example:
A=a1, MIXA=xor, PHA=$800, PSCA1=down, C=c4, PSCC=down, SLIDESPD=$30, SPD=6
It might be more readable like this, with options between parenthesis:
A=a1 (MIXA=xor, PHA=$800, PSCA1=down), C=c4 (PSCC=down, SLIDESPD=$30, SPD=6)
(but maybe it's just me)

Good idea, and it should be fairly simple to add. Perhaps I'll do
A=a1, (MIXA=xor, PHA=$800, PSCA1=down), C=c4, (PSCC=down, SLIDESPD=$30, SPD=6)
though, then I can just simply strip out the brackets when parsing (and usage of the brackets would be optional).

garvalf wrote:

is the speed persistent across the patterns? For ptn1 if I remove SPD=12 then I get a little glitch (high pitch tone). If I set SPD=10 (default?), it's even different.
ok I understand, SPD=16 is default (and I get the sound glitch as well)
SPD=16 is 0x10

Probably a bug in the compiler. I'll have a look in the coming days. In theory, all values should fall back to their defaults at the beginning of a pattern ($10 for speed in this case). Btw I pushed a new commit a couple of hours ago where I changed some things related to this mechanism, do you have that already? (Simple check: if /config/BetaPhase.cfg has an INIT_DEFAULTS command in the CFG_PATTERNS block, you've got the latest version.

Search options (Page 25 of 40)

Posts found: 601 to 625 of 989

601 Reply by utz 2016-11-16 21:55:38

Re: next gen engine ideas (135 replies, posted in Sinclair)

602 Reply by utz 2016-11-16 12:51:14

Re: next gen engine ideas (135 replies, posted in Sinclair)

603 Reply by utz 2016-11-15 22:12:49

Re: next gen engine ideas (135 replies, posted in Sinclair)

604 Reply by utz 2016-11-15 21:37:00

Re: SillyVenture 1-bit Compo (43 replies, posted in Atari)

605 Reply by utz 2016-11-15 10:40:23

Re: next gen engine ideas (135 replies, posted in Sinclair)

606 Reply by utz 2016-11-15 10:06:01

Re: SillyVenture 1-bit Compo (43 replies, posted in Atari)

607 Reply by utz 2016-11-11 10:14:02

Re: GTIA trick on Atari ST? (3 replies, posted in Atari)

608 Reply by utz 2016-11-10 10:45:46

Re: HoustonTracker 2 (TI-82/83/83+/84+) (130 replies, posted in Calculators & Pocket Computers)

609 Topic by utz 2016-11-05 19:27:11

Topic: GTIA trick on Atari ST? (3 replies, posted in Atari)

610 Reply by utz 2016-10-31 14:52:01

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

611 Reply by utz 2016-10-31 14:42:53

Re: new engine: Phase Squeek (21 replies, posted in Sinclair)

612 Reply by utz 2016-10-28 21:55:49

Re: new engine: Phase Squeek (21 replies, posted in Sinclair)

613 Reply by utz 2016-10-28 15:51:33

Re: new engine: Phase Squeek (21 replies, posted in Sinclair)

614 Reply by utz 2016-10-28 15:47:46

Re: SillyVenture 1-bit Compo (43 replies, posted in Atari)

615 Reply by utz 2016-10-28 15:45:10

Re: HoustonTracker 2 (TI-82/83/83+/84+) (130 replies, posted in Calculators & Pocket Computers)

616 Reply by utz 2016-10-26 14:58:09

Re: Welcome to the 1-Bit Forum (aka The Introduction Thread) (49 replies, posted in General Discussion)

617 Reply by utz 2016-10-26 14:45:26

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

618 Reply by utz 2016-10-25 16:23:52

Re: new engine: PhaserX (5 replies, posted in Sinclair)

619 Reply by utz 2016-10-25 15:59:32

Re: HoustonTracker 2 (TI-82/83/83+/84+) (130 replies, posted in Calculators & Pocket Computers)

620 Reply by utz 2016-10-25 12:03:11

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

621 Reply by utz 2016-10-24 17:25:39

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

622 Reply by utz 2016-10-23 11:12:30

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

623 Reply by utz 2016-10-22 12:19:30

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

624 Reply by utz 2016-10-22 11:24:44

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

625 Reply by utz 2016-10-21 21:31:13

Re: new engine: BetaPhase (20 replies, posted in Sinclair)

Posts found: 601 to 625 of 989