Search results

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...

My preferred one. @MIST , is this your bag too? That's the kind of problem I'm facing with Retro68 development. In the past, a dev environment needed stdlib, and a few, basic include files (e.g. stdio.h, string.h). These days even the simplest stuff needs every library under the sun. In my...

Hi folks, I've just been trying to install Retro68, but it fell over somewhere when trying to link. As per the instructions, the first thing I did was: brew install boost cmake gmp mpfr libmpc bison texinfo Then there were some more commands ending in: ../Retro68/build-toolchain.bash . There...

I've been trying to build Retro68 for ARM64 on my MBA M2, but after much effort I ended up with: esourceFiles.a[5](ResourceFile.cc.o) "boost::filesystem::path::find_parent_path_size() const", referenced from: boost::filesystem::path::parent_path() const in...

OK, I'm trying to turn your app into a proper classic Mac OS app, but the repo doesn't have a link to the: .include "../axel_f.mod.s" in wc_modMac.s . Of course, I could pick up a version of axel_f.mod, but if it's not the same one, I can't be sure if my code is correct. -cheers from Julz

OK, I've run it now. Sounds pretty good. It's quite instructive that using actual sampled sounds makes it sound a lot less chip-tune and far more like a multi-tracked piece. That is, it's harder to identify the individual tracks which means that it often sounds like there's more than 4 tracks...

It's more that the main purpose is to imagine a minimally hacky version of a Mac 512K era Mac that could do similar things to the Atari ST/Amiga type computers. I chose chunked pixels rather than planar pixels, for two main reasons. Firstly, an earlier conversation which I linked to at the start...

Brilliant, I'll check it out!