{"id":16162524,"url":"https://github.com/sunsided/c64-debugger","last_synced_at":"2025-03-18T22:31:12.598Z","repository":{"id":141992873,"uuid":"136446970","full_name":"sunsided/c64-debugger","owner":"sunsided","description":"Mirror of the awesome C64 Debugger project hosted on SourceForge","archived":false,"fork":false,"pushed_at":"2021-09-07T20:38:22.000Z","size":16084,"stargazers_count":29,"open_issues_count":0,"forks_count":6,"subscribers_count":4,"default_branch":"github","last_synced_at":"2025-02-28T12:33:02.422Z","etag":null,"topics":["c64","debugger","mirror","visual-debugging"],"latest_commit_sha":null,"homepage":"https://sourceforge.net/projects/c64-debugger/","language":"C","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sunsided.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-06-07T08:32:00.000Z","updated_at":"2024-10-23T14:26:10.000Z","dependencies_parsed_at":null,"dependency_job_id":"78c7224c-80e8-4369-88ff-29a9342e5d2c","html_url":"https://github.com/sunsided/c64-debugger","commit_stats":null,"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sunsided%2Fc64-debugger","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sunsided%2Fc64-debugger/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sunsided%2Fc64-debugger/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sunsided%2Fc64-debugger/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sunsided","download_url":"https://codeload.github.com/sunsided/c64-debugger/tar.gz/refs/heads/github","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243950927,"owners_count":20373664,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c64","debugger","mirror","visual-debugging"],"created_at":"2024-10-10T02:30:38.127Z","updated_at":"2025-03-18T22:31:10.301Z","avatar_url":"https://github.com/sunsided.png","language":"C","readme":"# C64 Debugger by SLAJEREK/SAMAR\n\nC64 Debugger (C) 2016-2017 Marcin Skoczylas\n\nVice (C) 1993-2016 The VICE Team\n\nThis is Commodore 64 code and memory debugger that works in real time.\nIt is quick prototyping tool where you can play with Commodore 64 machine\nand its internals.\n\nC64 Debugger embeds VICE v3.1 C64 emulation engine created by The VICE Team.\n\n#### Note to C64 Debugger source files\n\nSo, you would like to step into this entertainment coding mystery of C64\nDebugger source code? Beware that it is not going to be that easy as you\nthink!\n\nFirst of all I wrote this code just for entertainment. That means what it\nmeans, most of code has been developed around 4:30am, on Saturday night\njust after I came back from a party, being completely drunk. Oh yes,\nthat's what I call entertainment... and that's why some ideas in the code\nare... strange :) Some people like to play games on their PS4s, I like to\nplay a game called C++. Ahh, and I do big files, huge files that have 10k\nlines of code and store functionality are my drawback. I do not like\nmouse clicking, simple paging down or searching method name is quicker\nthan using mouse to select other files. It is bad, I KNOW. Plus lot of\ncopy pasting. It is bad, I KNOW.\n\nCode is based on my very old game engine called MTEngine. Origins are\ndated back to year 2002 when I developed first lines of code for Nokia\nSymbian and created MobiTracker (a mobile XM tracker). The engine was\nextended and aimed for mobile apps around 2008 where MobiTracker X for\niPad/Android was born. It has never been released anyway due to lack of\ninterest from potential users.\n\nEngine is heavy weight, huge and even when I removed most of code for the\nC64 Debugger code release it still has drawbacks and limitations due to\nquite old mobile technology we had in the year 2009. The engine has been\nported to desktop operating systems many years ago and it is now a base\nfor the C64 Debugger.\n\nWhy I hadn't selected SDL or other engines? Simply speaking, I know my\nengine quite well and did not have time to sit and re-implement things in\nSDL from scratch. But you're welcome and can do this yourself.\n\n## How to compile sources\n\nWhat's the biggest pain in the ass is a fact that this project does not\nhave Makefiles. Simply speaking, because in year 2009 I was not able to\nfind any Makefile delivery system that was fully multi platform - that\nis, that could generate Makefile for Xcode iOS, Android Eclipse, Xcode\nMacOS, Linux and Windows VS 2008 C++, and in the year 2009. Thus, the\nproject files are very related to selected IDEs and I'm compiling this\ndirectly from IDEs. Yes, I'm aware that nowadays we have nice Makefile\ngenerators, but I did not have time to focus and rewrite that part.\nWhat's more, all project files are stored in one source-tree, they are\nnot organised into libraries as they normally should be. This is due to\nthe same as above - I wasn't able to properly generate libs in some of\nOSes to which I targeted back in '09 so I simply put all files into one\nproject. It is bad, I KNOW. Besides that, it works for me as-is now, it's\nvery clumsy, but it works. There are hundreds of files and they compile\nquite long time on some of my build machines, but my MBP, a main\ndevelopment machine, compiles whole project from clean to run in just few\nseconds, so this is not an issue for me. And I like that rule you know,\nif it works and is quick then why bother. Remember that IS entertainment\ncoding at sunrise after Saturday's crazy parties :)\n\nI really look forward to get help and create proper Makefiles for the C64\nDebugger. I tried this once with CMake but I was stuck with problems how\nto handle `*.mm` files as C++ source code.\n\nOkay, let's go through platforms first.\n\n### MacOS\n\nThis is my main development machine. Just start Xcode, compile and run.\nShould work as-is without troubles. Just put files into\n`~/develop/MTEngine` folder.\n\n### Linux\n\nThere's a Makefile in root folder you can use to compile. Just type make.\nYou need to install these libs: gcc, g++, libgtk-3-dev, libasound2-dev,\nmesa-common-dev, libglu1-mesa-dev, libglib2.0-dev, libxcb-util\n\nNote this ticket related to libxcb-util library:\nhttps://sourceforge.net/p/c64-debugger/tickets/34/\n\nTo compile code for development purposes in Eclipse IDE:\nI use a tool from hell to compile the project that is called Eclipse CDT.\nIt is crap and you can find my stupid posts on Eclipse support forums\nshowing why I think so. Devs of Eclipse have never released a stable\nversion even though it is more than 10 years old. I selected Eclipse\nbecause I wasn't able to find any other IDE for Linux that had proper\nwrapper to GDB back in '07. My bad. Should have selected Vi, Emacs or\nsomething. I was able to compile the project on Ubuntu 12.04 recently.\n\nThen go to Eclipse settings and make `*.mm` files compile as C++ source\ncode: Window/Properties/File types: `*.mm` as C++ source.\n\nSome of includes can point to ~/develop/MTEngine folder directly, so it's\nbetter that you put the source files there. Note, that project adds\nincludes to all folders with code.\n\n### Windows\n\nCode is compatible only with Visual Studio 2008 C++. I was not able to\nport the code to newest VS due to bugs and issues in VS itself. Maybe you\nknow the solution and can help here... the problem is that new VS is not\nable to compile *.mm files as C++ code. You can find people that are\nmoaning about this on StackOverflow, discussing some workarounds, but all\nworkarounds described there did not work for me. So we are stuck with\nVisual Studio 2008 for now due to this. One of solutions is to rename all\n`*.mm` files to `*.cpp` and remove ObjC dependencies in MacOS part of code.\n\nRemember to have glext.h handy and OpenGL libs. The engine uses also\nPthreads lib that can be got from here: https://www.sourceware.org/pthreads-win32/\nA static version of library is being used, so you will need to compile\nthis lib from source code because they provide only dynamic versions.\nNote that you need to compile Pthreads lib from command line, not VS IDE.\n\nIn VS2008 C++ you need to set in settings that `*.mm` files are treated as\nC++ code (see MTEngine/Win32/config for screenshots how to do that). Note\nthat some paths may point directly to `C:\\develop\\MTEngine`, so just\nremember to put files in that folder.\n\nOf course you can contact me if you have questions how to compile this\nproject. It is doable, just a bit clumsy.\n\n## Source code files\n\nThe project itself is divided into Engine, platforms-related and Game\nfolders. It is a bit messy, but this is due to the fact that some IDEs\nmade by devils from hell can't organise files as they should, so often\nsome strange things are just there as-is workarounds. The same implies to\nthe code itself, you'll definitely find places in code that look strange,\nlike variables that are set to themselves - these are workarounds for\nWin32 compiler mostly, which (politely speaking) is stupid and has\nerrors... Oh yes, sleepless nights, entertainment coding to find that in\nassembly code generated by Win32 compiler some important C++ lines were\n\"forgotten\"... normal thing, believe me:) it is called \"optimisations\ndone by Microsoft\" :D remove some lines here and there, we have faster\ncode, less binary size and it does not matter that it does not work, hehe\n:D\n\nThe Engine folder contains things related to generic UI, resource\nmanager, tools, etc.\n\nThe C64 Debugger code itself is located in Game/c64 folder. Connection to\nemulator is achieved via interface, in Game/c64/DebugInterface you will\nfind an abstract interface with empty methods. This is your starting\npoint if you would like to add another emulator.\n\nIn Game/c64/Emulators you will find Vice. It is a version quite modified\nby me that supports features delivered by the debugger. I started from\nVice 2.4 SDL Linux version and removed most of SDL code that was replaced\nby hooks to the C64 Debugger - however as you will see, the SDL port from\nVice is still there, just mostly commented out. I left the original SDL\ncode for now temporarily to not jump between projects too much when I do\nresearch how things are done in Vice. If you'd like to learn yourself, a\nGame/c64/Emulators/vice/ViceInterface/ folder is a good starting point.\n\nOkay. Happy fighting with the code. Feel free to contact me if you need\nassistance.\n\nSLAJEREK/SAMAR\nslajerek@gmail.com\n\nBialystok, Poland, 2016/06/04\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsunsided%2Fc64-debugger","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsunsided%2Fc64-debugger","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsunsided%2Fc64-debugger/lists"}