Search options (Page 23 of 41)

Yeah, I think SID is here to stay Port contention will be there in 48k mode, though it can probably be disabled with a setting.
I'm curious how good the beeper sound will be. I expect it to be at least on par with what garvalf recorded from his MiST.

Thanks for the info. Seems that either way the Next will be totally overpowered in terms of sound capabilities It's basically a chip orchestra-in-a-box at this point. Especially pleased to hear that SAA support is on the list. Now we just need a decent tracker for all of this...

Made by one of the most talented chip artists on the planet

Not sure if Shiru has developed this idea any further yet. He's done a few ports of ZX beeper engines though, as you've probably seen. I've mostly been busy working on MDAL myself, though I've also done a Z80 emulation core in the meantime (not for AVR though, just a C++ experiment to see if I could pull it off in general). I'm sure we'll come back to this at a later point though.

Holy moly, over 720,000 GBP! Don't think anybody saw that coming. Well deserved though, imo this really is the Speccy of the future.

Z80 is sometimes used in the Sega Genesis/Megadrive as a sound co-processor. It's also used for sound generation in a number of other home computers without dedicated sound hardware.

You don't really need an in-depth understanding of the ULA. I suppose my wording was a bit confusing: As far as sound goes, the ULA only converts the digital output from the Z80 into an analogue signal. The actual sound synthesis is done by the Z80.

Basically, you mostly interact with the ULA either by writing to VRAM (0x4000 - 0x5bff) in order to change graphics, or by writing to port 0xfe in order to change the border color, and the state of the 1-bit signal. Bit 4 is the relevant bit for controlling the beeper state.

The tricky part of running graphics and audio at the same time is this: the Z80 shares the data bus with the ULA in the lower 16 KB of the Spectrum's RAM (0x4000 - 0x7fff), and the ULA gets precedence over the CPU. So when the CPU is executing a read or write operation that concerns the first 16K of RAM, it may have to wait a variable amount of cycles. This is called "memory contention". Now here's the catch: When synthesizing 1-bit music, you usually need to use cycle-exact timing. However, the amount of delay caused by the memory contention is very difficult to predict, so cycle-exact code becomes nearly impossible when generating graphics at the same time. There are some tricks to make it appear as if graphics and music are running at the same time, but actual synchronous gfx+msx generation is considered very challenging (though not impossible).

Cheers! Another thing you'll want to do is setting up a toolchain. Books usually don't explain how to do this in a modern way. There are many different ways of going about this, ultimately it all depends on your personal preferences. Are you a bit familiar with using the shell on your Mac and compiling simple C/C++ programs?

Hey Mark, welcome aboard! I realize we don't actually have a sticky about getting started on Speccy 1-bit music And we're always happy to help, so please feel free to ask any beginner's questions you may have.

Hello HT2 friends, I've uploaded a new beta version (2.24) to the github repo. Fixed a major bug in the keyhandler which was probably responsible for a whole range of stability issues, and added a "loop pattern" playback function (accessible with [ALPHA][(-)]. Provided there are no bugs, this will become the next stable release. Please do test and report any bugs you find.

Also note that the html documentation is no longer updated. For HT2.3, there'll be a new fancy pdf manual. The current draft is attached below.

Hehe, better late then never eh?
Dunno why, but 0.23 also overall feels faster/less jerky for me. And still super happy about the added sequence navigation.

Thanks! I had initially planned on implementing this, but ultimately abandoned the idea, mostly because of my lack of experience in coding such a system. At the current stage, it would be quite tricky to add, because there's just a few hundred bytes of memory left. And there's actually a few other features that I still want to implement (advanced live mode, better copy/paste/clone support), so I'd rather spend the remaining bytes on this. I might consider it again at some point, but at the moment I'd rather try to convince the TiLP guys to try and add Android support, which would probably solve the problem for many people as well.

Btw, a call for action to everyone: Please do test the latest beta versions from github. There are a couple of nasty issues which I need to sort out before I can progress further. So far I've had no luck with these, so any input on them is highly appreciated.

The first example can be done faster with 12-bit counters, at the cost of loosing variable duty:

   add hl,de
   ld a,h
   out (#fe),a
   rrca
   out (#fe),a
   rrca
   out (#fe),a

Second example is very powerful. One can create all sorts of waveforms with this, especially if you also play with the distances between the OUT commands. If I understood fourier transformations, I'd have some great fun with this...

My idea was to use a free-running counter. Original idea of an 8-bit counter didn't work, so here is a pretty clumsy version with a 16-bit counter:

    ld de,#80
    xor a
    ld h,a
    ld l,a
    ld b,a
    ld c,a
    
loop
    out (#fe),a    ;11__36
    add hl,de      ;11
    inc bc         ;6
    ld a,h         ;4
    nop            ;4
    out (#fe),a    ;11__36
    add a,b        ;4
    ld r,a         ;9
    jr loop        ;12

Suprisingly it actually works, but wasting a whole 16-bit reg on this seems rather wasteful. Though on the other hand, one free-running counter can serve multiple channels, so maybe not so bad after all.

Edit: On second thought, that register is maybe not wasted at all... because it might be possible to use the frame length counter for this :D
Edit2: Trying out the idea in BeepModular. The effect is less pronounced here because of the volume difference (48 vs 64t), but generally abusing the timer for this seems like a good idea.