Search results

@MIST , @Mu0n : I can now build and run NanoMacTracker. https://68kmla.org/bb/index.php?threads/retro68-build-issues.50537/post-569396

I've been reading some of the documentation on building and running apps for Retro68 (ToughDev, Henlin's simplified guide), but again it seems to be a case of people not specifying critical information a newbie to CMake or Retro68 might not be aware of. The bit I didn't understand is where I'm...

We can take this a bit further. Lots of EVs provide V2L these days (Vehicle to Load), which means you can power mains appliances from an EV (e.g. if you're camping). A Mac Plus takes 60W. A typical modern EV has at least 50kWh of battery, so you could power your Mac Plus from a charged EV for...

@bribri , @Mu0n , @8bitbubsy , @MIST, @noglin. OK! It looks like I'm there: Done building Retro68. The toolchain has been installed to: /Users/julianskidmore/Development/Retro68Dev/Retro68-build/toolchain/ I think I can try building the MOD player next!

The reason why there are two different directories is because homebrew can't (or couldn't) build universal binaries. So, the Intel ones stay in /usr/local/[include], but the arm64 ones go in opt/homebrew/[include]. If you need both (or think you do), then the Intel directories ought to stay...

@bribri , @Mu0n , @8bitbubsy , @MIST, @noglin. OK, I've made a bit more progress, I now know where the wrong prototype is coming from and why, but I don't yet know the best way to solve it. To recap, the compilation fails, because libResourceFiles.a contains the x86_64 signature for...

I would normally use THINK C 5 for development. The nice thing is that it will run happily on a Mac Plus emulator in 4MB. However, it uses Motorola syntax for assembly rather than gas. For example, %d0 instead of d0. Also, it only supports inline assembly and doesn't support .rept. I haven't...

@joevt , thanks for the informative reply! @bribri , @Mu0n , @8bitbubsy , @MIST, @noglin. OK, I've made a bit more progress now in analysing the problem if not solving it. Going back to the error message I realised the problem isn't with ResInfo.cc.o , the newly compiled file that's being...

Thanks, it looks like the signature for your /opt/homebrew/lib/libboost_filesystem.dylib is the same as mine. Did you check that: cat pathTo/Retro68-build/build-host/ResourceFiles/CMakeFiles/ResInfo.dir/link.txt Says: /usr/bin/c++ -Wall -Werror=return-type -Wno-multichar -g -arch arm64...

OK. I've made a bit more progress. You can list the symbols in a dylib using nm -gU libraryName.dylib . Because I knew I had an x64 and arm64 version of libboost_filesystem.dylib , I figured I could list the symbols for each architecture; pipe them to grep "append" , because it was an append...

A minor improvement. I deleted the entire build tree in case it was trying to use a library it thought it had already built. I then re-ran the build for Retro68. It fell over just like before. This time though I've found the link command that caused the failure. /usr/bin/c++ -Wall...

Well, it didn't blow up, however, I still have the same problem when building Retro68: -- Found Boost: /opt/homebrew/lib/cmake/Boost-1.88.0/BoostConfig.cmake (found version "1.88.0") found components: filesystem program_options -- Configuring done (0.2s) -- Generating done (0.1s) -- Build files...

@bribri , @Mu0n . OK, so I think I'm making progress. $ lipo -info /usr/local/lib/libboost_filesystem.dylib Non-fat file: /usr/local/lib/libboost_filesystem.dylib is architecture: x86_64 $lipo -info /opt/homebrew/Cellar/boost/1.88.0/lib/libboost_filesystem.dylib Non-fat file...

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