Search results

@bribri , @Mu0n . I can give an example of frustration with modern tools. I want to know how to compile a simple Boost example. So, I googled "C++ Boost example". Indeed, it leads to some example code: https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/examples.htm But when you click...

Note: When it comes to optimisation, every 1083 cycles we save on the VBL (including the Hardware buffer copying, the sample generation or replayer), leaves 1% more CPU for the application. OK, I found two bugs in my code. Firstly, tst.w %d0 near the end should be tst.w %d1, because we need to...

@MIST , @8bitbubsy. This is GenSamples in assembly code: GenFrameSamples: move.w gStepSamples(%pc),%d0 #d0.w=aStepSamples move.w #LEN,%d1 #d1.w=tickSamples=370; GenFrameSamples10: #can be do loop while(tickSamples>=0) { move.w %d1,%d2...

I'm not sure how to do that. What I could do is create a simple program that uses the line it fell over at: "boost::filesystem::path::append_v3(char const*, char const*)", referenced from: (See OP). I've never compiled anything with Boost before, not sure of the simplest example to do that...

@MIST , @8bitbubsy . In case you're not convinced the algorithm above works, we can write a simple 'C' program to test it: #include <stdio.h> #include <stdint.h> // Or whatever TicksPerMs*TicksPerRow*SamplesPerMsIs #define kSamplesPerVbl 444 void GenSamples(uint16_t aClipSamples) {...

We shouldn't lose any performance! It's OK, the code snippets I've written earlier can implement it at the output stage. It's a version of this algorithm, from this comment. uint16_t GenFrameSamples(uint16_t aStepSamples) { uint16_t tickSamples=370; while(tickSamples>=0) {...

You mean how many replayer ticks per pattern row? (where a song row is 64 pattern rows)? I didn't think you were trying to be arrogant, I was just trying to reconcile the fixed VBL tick rate with your description of the replayer tick rate. From my current reading then.. I've just had an a-ha...

It wouldn't affect the playback speed, it just means code doesn't get duplicated. One thing I was concerned about, and I think I still am, is the fact that the position: wizxpos is a 16-bit byte offset, so it looks like the sample code can't properly handle waveforms larger than 64kB (128kB is...

OK, I've finally had a look at the newer code and I can see how you're splitting it up [I've responded to your latest comment a bit below]. One of the upshots of splitting the "Sample" routine into 74 samples at a time (for 4 channels) is that looping is more finely grained. On the old code it...

@mihai , @joevt ! Amazing, I can now run Mac OS 8.0 on the PPC 6100 Dingus PPC emulator! That's a first for me. I ran it with 24MB RAM with VM off, then restarted with VM on OK! Don't know why it says "56MHz". I tried running it with 12MB of RAM, but it failed to boot. I've tried Mac OS 8.1...

@Melkhior - thanks for the great reply back on July 21, sorry I haven't read it until now!

Onto the data structures. Part info starts with: count: DC.W PARTS wiz1lc: DC.L sample1 #I think "lc" means "Location". wiz1len:DC.L 0 #Actually end address for wiz1. wiz1rpt:DC.W 0 wiz1pos:DC.W 0 wiz1frc:DC.W 0 #The same structure repeated for wiz2.. wiz4. aud1lc: DC.L dummy...

I thought it was from the Amiga which had 4 audio channels: "The Amiga has four audio channels. Channels 0 and 3 are connected to the left-side stereo output jack. Channels 1 and 2 are connected to the right-side output jack. Select a channel on the side from which the output is to appear."...

As @MIST says, it'd be really helpful to look at the published code and read the previous postings. Firstly, I think the 'tick' or 'ticking' terminology is a bit unhelpful, because it appears to refer to an interrupt period, but in fact there's only ever one interrupt and it's the VBL one, which...

The Mac's hardware audio buffer ticks at 60.15Hz, which means a VBL task at that frequency is certainly needed. If you wanted to 'tick' the replayed after N samples, you'd need to manage that within the VBL period as per my post here...

[ and @MIST ]. I've been looking at the assembler code a bit more, to turn this MOD player into a proper Mac app. This means I'll end up using things like NewPtr to allocate sample data and MOD data and being able to read in a MOD file properly. I tend to find there's ambiguity with the term...

I'm not sure yet which MOD file types are supported by @MIST 's player. I'm fairly familiar with MIDI files, but not MOD files. Since, ultimately they're derived from Amiga sound hardware, it seems like they're not that sophisticated. I found a concise description here...

Hi @bribri, Thanks for the response. I tried file /opt/homebrew/Cellar/boost/1.88.0/lib/*.dylib and got this: /opt/homebrew/Cellar/boost/1.88.0/lib/libboost_atomic.dylib: Mach-O 64-bit dynamically linked shared library arm64...