October the 1st: Debug in C (just one image)
7 thoughts on “October the 1st: Debug in C (just one image)”
Leave a Reply to Kokovec Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Really cool!
How well optimized are the binaries?
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…
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.
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?
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 🙂
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.
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