rosco_m68k VS debugpy

Nice! I’d be interested to see how it handles https://github.com/rosco-m68k/rosco_m68k , it’s a mixed software / hardware repo, with a lot of code in assembler and C (for an old platform). Might be a challenge?

Probably not exactly what you’re looking for (since you mention “outdated”) but there are similar projects with 16 and 32 bit architectures, e.g. https://github.com/rosco-m68k/rosco_m68k

(Disclosure: I’m the designer and lead developer on that project).

Maybe the rosco-m68k computer kit would be up your alley. If you want to stay in z80 land, there's the omega MSX2 clone but I don't see any kits, so you'd have to get the boards and parts yourself.

Hi. The 68000 is an "old school CPU", like the 6502 and has no programmable memory inside the chip itself. To operate a 68000 system there generally needs to be some external ROM and RAM chips (and the type can vary). However, the same as with Ben Eater's 6502 and 8-bit kits, the TL866-II will likely be useful to program EPROMs and GALs on a 68000 setup also (it sure has been on the 68000 single board computer I have been tinkering with recently).

I am working on a similar project Xosera, aimed at adding video to a 68000 era home-brew system (the rosco_m68k). It is basically all working and there is a prototype PCB made. I am just finalizing "blitter" unit design and hopefully I'll have room for some "Amiga style" audio.

debugpy description from it's repository:

I'd love to see what it can do with https://github.com/microsoft/debugpy - and especially how it would handle vendored dependencies.

I read that nvim-dap-python uses debugpy which has all these configuration parameters of which one of them is `cwd` which represents the "absolute path to the working directory of the program being debugged".

Hey all, I'm not sure if this is normal or not but, when debugging with nvim-dap, nvim-dap-ui, and nvim-dap-python (which uses debugpy) over a remote session, dap runs exactly once and then closes the entire process. This even happens when I just call `require("dap").restart()`. It's pretty frustrating to deal with and is not something that I was used to when I used to debug with vimspector, which let me restart the debug remotely as many times as I wanted without killing the application that I was connected to. Is this happening for anyone else? How do I disable it? I didn't see anything in debugpy's configuration options. I'm rereading dap's vim :help but haven't found any mention of auto-close / terminate logic yet.

-- Debug adapter plug-in. Debug anything in Neovim { "mfussenegger/nvim-dap", config = function() vim.keymap.set("n", "d", ":DapContinue") vim.keymap.set("n", "dl", ":DapStepInto") vim.keymap.set("n", "dj", ":DapStepOver") vim.keymap.set("n", "dh", ":DapStepOut") vim.keymap.set("n", "dz", ":ZoomWinTabToggle") vim.keymap.set( "n", "dgt", -- dg as in debu[g] [t]race ":lua require('dap').set_log_level('TRACE')" ) vim.keymap.set( "n", "dge", -- dg as in debu[g] [e]dit function() vim.cmd(":edit " .. vim.fn.stdpath('cache') .. "/dap.log") end ) vim.keymap.set("n", "", ":DapStepOut") vim.keymap.set("n", "", ":DapStepOver") vim.keymap.set("n", "", ":DapStepInto") vim.keymap.set( "n", "d-", function() require("dap").restart() end ) vim.keymap.set( "n", "d_", function() require("dap").terminate() require("dapui").close() end ) end, lazy = true, }, -- A default "GUI" front-end for nvim-dap { "rcarriga/nvim-dap-ui", config = function() require("dapui").setup() -- Note: Added this dd duplicate of because somehow the -- mapping keeps getting reset each time I restart nvim-dap. Annoying but whatever. -- vim.keymap.set( "n", "dd", function() require("dapui").open() -- Requires nvim-dap-ui vim.cmd[[DapContinue]] -- Important: This will lazy-load nvim-dap end ) end, dependencies = { "mfussenegger/nvim-dap", "mfussenegger/nvim-dap-python", -- Optional adapter for Python }, }, -- TODO: Make sure that debugpy is installed. Otherwise, disable -- Reference: https://github.com/mfussenegger/nvim-dap-python#installation -- { "mfussenegger/nvim-dap-python", config = function() require("dap-python").setup("/path/to/python/here") -- XXX: Replace this with your preferred Python, if wanted -- An example configuration to launch any Python file, via Houdini -- table.insert( -- require("dap").configurations.python, -- { -- type = "python", -- request = "launch", -- name = "Launch Via hython", -- program = "${file}", -- python = "/opt/hfs19.5.569/bin/hython" -- -- ... more options, see https://github.com/microsoft/debugpy/wiki/Debug-configuration-settings -- } -- ) end, dependencies = { "mfussenegger/nvim-dap", "nvim-treesitter/nvim-treesitter", }, }, -- Remember nvim-dap breakpoints between sessions, ``:PBToggleBreakpoint`` { "Weissle/persistent-breakpoints.nvim", config = function() require("persistent-breakpoints").setup{ load_breakpoints_event = { "BufReadPost" } } vim.keymap.set("n", "db", ":PBToggleBreakpoint") end, }

After testing I have the same situation. I reported this issue on GitHub, you can follow up.

vim.fn.sign_define('DapBreakpoint', {text='🛑', texthl='', linehl='', numhl=''}) dap.configurations.python = { { -- The first three options are required by nvim-dap type = 'python'; -- the type here established the link to the adapter definition: `dap.adapters.python` request = 'launch'; name = "Launch file"; -- Options below are for debugpy, see https://github.com/microsoft/debugpy/wiki/Debug-configuration-settings for supported options program = "${file}"; -- This configuration will launch the current file if used. pythonPath = function() -- debugpy supports launching an application with a different interpreter then the one used to launch debugpy itself. -- The code below looks for a `venv` or `.venv` folder in the current directly and uses the python within. -- You could adapt this - to for example use the `VIRTUAL_ENV` environment variable. return os.getenv("VIRTUAL_ENV") .. "/bin/python" or '/usr/bin/env python' end; }, }

You should take a look at DAP (Debug Adapter Protocol). There exist a Python module implementing this protocol (debugpy) and you can probably find some client applications that can hook into it (like this neovim plugin).