626 Reply by utz

(135 replies, posted in Sinclair)

@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?

Go to forum: Sinclair

627 Reply by utz

(43 replies, posted in Atari)

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

Go to forum: Atari

628 Reply by utz

(135 replies, posted in Sinclair)

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.

Go to forum: Sinclair

629 Reply by utz

(43 replies, posted in Atari)

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

Go to forum: Atari

630 Reply by utz

(3 replies, posted in Atari)

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

Go to forum: Atari

631 Reply by utz

(130 replies, posted in Calculators & Pocket Computers)

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 wink

Go to forum: Calculators & Pocket Computers

632 Topic by utz

(3 replies, posted in Atari)

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?

Go to forum: Atari

633 Reply by utz

(20 replies, posted in Sinclair)

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

Go to forum: Sinclair

634 Reply by utz

(21 replies, posted in Sinclair)

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.

Go to forum: Sinclair

635 Reply by utz

(21 replies, posted in Sinclair)

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.

Go to forum: Sinclair

636 Reply by utz

(21 replies, posted in Sinclair)

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.

Go to forum: Sinclair

637 Reply by utz

(43 replies, posted in Atari)

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.

Go to forum: Atari

638 Reply by utz

(130 replies, posted in Calculators & Pocket Computers)

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

Go to forum: Calculators & Pocket Computers

639 Reply by utz

(49 replies, posted in General Discussion)

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

Go to forum: General Discussion

640 Reply by utz

(20 replies, posted in Sinclair)

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.

Go to forum: Sinclair

641 Reply by utz

(5 replies, posted in Sinclair)

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

Go to forum: Sinclair

642 Reply by utz

(130 replies, posted in Calculators & Pocket Computers)

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.

Go to forum: Calculators & Pocket Computers

643 Reply by utz

(20 replies, posted in Sinclair)

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.

Go to forum: Sinclair

644 Reply by utz

(20 replies, posted in Sinclair)

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)

Go to forum: Sinclair

645 Reply by utz

(20 replies, posted in Sinclair)

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 wink

Go to forum: Sinclair

646 Reply by utz

(20 replies, posted in Sinclair)

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 // wink
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 wink 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 wink

Go to forum: Sinclair

647 Reply by utz

(20 replies, posted in Sinclair)

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

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 yikes

Go to forum: Sinclair

648 Reply by utz

(20 replies, posted in Sinclair)

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.

Go to forum: Sinclair

649 Reply by utz

(20 replies, posted in Sinclair)

Ah, yes, I made a last minute change and probably forgot to update main.asm in the repo. Thanks for reporting, will fix asap. Edit: done.

The "-is" suffix is indeed for sharps, forgot to mention that as well. (German notation, hehe) Using an actual # char would break pasmo, so we'll have to live with "-is" I guess. Originally I had "h" instead of "b" as well yikes

Anyway, thanks for the cheers wink

Btw fancy website for MDAL: https://utz82.github.io/MDAL
Not much content in the wiki yet, will be filling that in in the coming days.

Go to forum: Sinclair

650 Reply by utz

(20 replies, posted in Sinclair)

Good news everyone, BetaPhase is the first engine to get Music Data Abstraction Language (MDAL) support! (If you missed the discussion about MDAL, read up on it here.

I haven't written much documentation yet, but usage should be pretty straightforward. Check out docs/betaphase.txt and examples/betaphase-demo.mdal. Some general notes:

- Unlike standard music markup languages like MML or ABC, the notation in MDAL is row-based, just like you would do it in a tracker.
- If you don't want to change anything in a given row, you can use the dot command (.) to specify just that.
- Pattern names must be lowercase.
- Specifying a loop point in the sequence is optional (will be set to sequence start if not specified).

MDAL is still in very early beta stage, I'm expecting it'll have tons of bugs at this stage. Let me know if you find any.
Most notably, there are two problems at the moment:
1) Mixing of strings and bit flags is not yet supported. In case of BetaPhase, that means that upward slides cannot be used in conjunction with note names, so you'd have to supply a note divider instead (see pattern1b in betaphase-demo.mdal)
2) There's no support for global constants yet, so MDAL will fall back to internal defaults in some cases (for example, speed is reset at the beginning of every pattern)

source: 

git clone https://github.com/utz82/MDAL.git

win32 build


In the meantime, I've found a way to generate noise in BetaPhase, but I haven't updated the engine yet. Stay tuned. Meanwhile, a new, crappy demo tune, produced by the MDAL converter:

Go to forum: Sinclair