October the 1st: Debug in C (just one image) Tagged on: "C", Debug By Malban | October 1, 2017 | Uncategorized | 7 Comments | ← 23rd of September doing nonsense… 8th of November – 19″ Monitor! → 7 thoughts on “October the 1st: Debug in C (just one image)” Kokovec October 3, 2017 at 4:12 am Really cool! How well optimized are the binaries? Reply ↓ Malban Post authorOctober 3, 2017 at 4:45 pm Well – the default setting is with framepointer and no optimiziation. This leaves a lot to be desired – but it nearly always works out of the box that way.. If you know what you are doing and are prepared to do a little manual “work”, you “might” switch off the framepointer and compile with -O3. IMHO the generated code is often not bad at all – see my last posting in the proboard forum, I posted two examples there… Reply ↓ Martin October 22, 2017 at 9:45 pm What machine are you using. I would love to try VIDE for my vectrex dev but on my i7 Haswell MacBook Air it absolutely thrashes it. The fan goes like crazy and it gets super hot. Reply ↓ Malban Post authorOctober 22, 2017 at 10:42 pm For the normal releases I usually keep the settings so that they should “work” always. But one CAN configure VIDE to be barely usable. Perhaps something screwed up the configuration. I use an iMac mid 2011. 3.4GHz Core 7, 16GB RAM Unless you start a couple of emulators at once, there are only a couple of things I can think of that really can freak out a good computer a) the settings regarding “ringbuffer”. Depending on the version of Vide this settings can be found either under “emulator”- or “debug”- TAB (within the configuration). Ringbuffer (unless you need it) should NOT be active (checkbox unchecked) – the values for “frame” and “single step” should be farely low (frame 100 and single step 3000 or so) b) Emulator settings “Ray Gun” should be off c) if you have a large assembler file in an old Vide version (larger 100KB) that will also slow things down d) on really old Vide versions a cache might be active that caches all images – if active and you started a “starter”, than all images are in the cache – that will use quite a bit of memory (to switch that off go to Menu System->Extra->Application Configuration TAB Cache & Co, and make sure the “cache active” checkbox is not checked (if changed – you must “Save Configuration” in order to accept the changes) I can’t think of much more – which version of Vide are you using? Reply ↓ Martin November 12, 2017 at 9:31 pm I’m sorry for appearing rude, I didn’t see the reply to this! I have only had a relatively brief look at VIDE so it was v1.20 in an “out of the box” setup. There are so many things in there that I need to sit down one evening and read through all of the documentation. I was previously using Xcode (always the latest) with an external build script, gcc-6809 C compiler for my code with a 6809 assembler for BIOS function boxing / unboxing code. I forget which assembler off hand. I have to confess that an upgrade for the 4.5 year old MBAir had been in the pipeline for some time and last week I bit the bullet and now have a 2017 i7 MacBook Pro. The problem appears to have gone away however I’m the curious kind and I will go back to the air to see if any of the settings you mention made the difference. I’m also very keen to learn more about the C work you are doing. My environment works fine but I’m always happy to look at new things and new ways 🙂 Reply ↓ Martin November 12, 2017 at 10:51 pm I just checked and it looks like it was the ‘frame’ and ‘single step rollback buffer’ settings. By default they are set at 1,000 and 30,000 (10x the values you gave above). When I reduced these to 100 & 3,000 CPU use went way down considerably and the fans did not kick in. I’m just watching your video on the C work. All of my work is based on the work by the author of Bloxorz so it looks like it uses all the same tools which is fortunate. Reply ↓ Malban Post authorNovember 12, 2017 at 11:18 pm Yeah – nearly the same. Although the BIOS bindings are a bit different… If you haven’t looked there yet – I started a very new (and quite empty) page about Vectrex C: vectrexc.malban.de Leave a Reply Cancel replyYour email address will not be published. Required fields are marked *Comment * Name * Email * Website Δ This site uses Akismet to reduce spam. Learn how your comment data is processed.