MSX cross development on OS X

Page 1/2
| 2

By Maggoo

Paragon (1217)

Maggoo's picture

30-08-2015, 17:48

I recently moved from a WIN7 PC to a Macbook and I'm looking for pointers regarding cross development for the MSX.

For cross development on PC I used to work with Context (Text editor with Z80 Syntax highlighter), SJASM 0.42c (which was handy to generate Megaroms files) and BlueMSX (mostly for the debugger feature with the step by step trace function).

Is there an OS X version of those tools? I could not find a version of SJASM for OS X and the BlueMSX port I tried (CocoaMSX) seems to be lacking the debugger function.

I know I can install a Windows VM to use those tools in OS X but I was wondering if there is any better alternative?

Login or register to post comments

By Sylvester

Hero (589)

Sylvester's picture

30-08-2015, 17:57

You can use https://atom.io/ with the z80 syntax highlighter for editing. For compiling I would say https://bitbucket.org/grauw/glass Never used it, but i guess Grauw can tell you how to generate megaroms with it :) And http://openmsx.org/ as emulator with the debugger plugin.

By Grauw

Ascended (10768)

Grauw's picture

25-02-2020, 09:24

I use Eclipse for editing (the CDT includes a decent generic asm editor) [Edit: Switched to VSCode nowadays.]. Assembling, Glass of course, having a good cross platform assembler was part of the reason for creating it. For pixel art drawing, check out Aseprite (avoid Pixen its colour handling is completely broken). As emulator, I use openMSX!

As for project setup, I use nodejs for tools (e.g. generating frequency tables), and have a makefile to build it, run it and copy to SD card. I also have an openMSX tcl script to set up various things handy for debugging and development. I include the Glass jar so that people can compile without needing to download dependencies first. For examples of those see here and here.

An additional note, if you want to use BMP2MSX, it works with wine (best to install wine via homebrew).

Edit: bumped because I updated the links (sorry about that, nothing to see here).

By uberjack

Champion (328)

uberjack's picture

25-02-2020, 05:26

Somewhat tangentially related, a mystery contributor recently added a very basic debugger to CocoaMSX and issued a pull request https://github.com/CocoaMSX/CocoaMSX/pull/48 . There were several issues with the pull request that I asked him/her to address before I could accept it, but they never amended the request or issued another PR, so I had to close it.

If anyone else is interested in adding a basic debugger, I'm happy to merge it into CM, just so long as those issues are ironed out. Doesn't have to look particularly pretty, those aspects can be ironed out eventually.

By gdx

Enlighted (6219)

gdx's picture

25-02-2020, 09:18

I use Zasm and TextWrangler with the following language Module that I modified a little to edit generic asm programs.

https://derekbolli.wordpress.com/2012/11/16/editing-z80-asse...

I debug with BlueMSX using VirtualBox. CocoaMSX has a lot of gaps. Adding the debugger would be good news.

By sd_snatcher

Prophet (3659)

sd_snatcher's picture

25-02-2020, 13:22

Grauw wrote:

An additional note, if you want to use BMP2MSX, it works with wine (best to install wine via homebrew).

This means you're also chained to macOS 10.14 (Mojave), or have you found a way to run wine on Catalina?

BTW, Louthrax's excellent MIFui also works fine with wine.

I use the good old vim to edit the files, sjmasmplus to cross-compile, plus a bunch of bash and tcl scripts.

For the emulator and debugger, I use openMSX + openMSX_debugger. I'm alternating between the old SDL1 version of openMSX and the newer SDL2, given that the newer version doesn't work on the 2nd display and handle joysticks differently.

What I really miss is a good remote debugger on the real MSX. One that would allow me to connect via RS-232 and debug from the PC/Mac. Because there are still situations where the emulator doesn't behave like the real hardware. And there are things that openMSX still doesn't emulate, like the light-pen or light-gun.

Does anyone have a good solution for remote debugging on the real MSX?

By Grauw

Ascended (10768)

Grauw's picture

25-02-2020, 14:28

That post I wrote in 2015, just the date stamp got updated and the thread got bumped because I updated the links in it to their new location.

I’m on Catalina now. I haven’t installed Wine in quite a while, I don’t like it much, it installs a ton of dependencies and then when you try to run Windows stuff with it it often doesn’t look and work well.

As for SDL2 on a 2nd display, did you file a bug about that?

A remote debugging cart would be neat. Perhaps also one with MMU-like features where your program can set memory access boundaries and such, that would be really cool to detect stack overflows and null pointer accesses.

By sd_snatcher

Prophet (3659)

sd_snatcher's picture

25-02-2020, 19:02

Grauw wrote:

I’m on Catalina now. I haven’t installed Wine in quite a while, I don’t like it much, it installs a ton of dependencies and then when you try to run Windows stuff with it it often doesn’t look and work well.

Maybe it depends on the wine flavour that was used? I use this flavour, and it works pretty fine. Nothing spectacular, but gets the job done.

Quote:

As for SDL2 on a 2nd display, did you file a bug about that?

Yep! It's here.

Quote:

A remote debugging cart would be neat. Perhaps also one with MMU-like features where your program can set memory access boundaries and such, that would be really cool to detect stack overflows and null pointer accesses.

Not sure if MMU-like features would be doable on a cartridge, since the NMI of the Z80 isn't available on the MSX slot. Maybe with some tricky code injection similar to what the Playsoniqs cartridge does for SMS games.

But a humble traditional debugger would suffice to me. As long as I can do step-by-step debugging, analyse registers, contents of the RAM/VRAM, etc.

But I've fallen in contradiction here, since dealing with the VRAM would change the VRAM pointer. And there's this design flaw inherited from the TMS9918, where you can't read the VRAM pointer value to be able to restore it later. Same deal with the palette values. Only on the V9978/V9990 they noticed that this had to be fixed.

So, to be able to allow VDP debugging, such cartridge would have keep a readable copy of the VRAM pointer and palette registers. A humble software debugger on cartridge wouldn't be able to accomplish that.

By zPasi

Champion (499)

zPasi's picture

26-02-2020, 08:40

sd_snatcher wrote:
Grauw wrote:

An additional note, if you want to use BMP2MSX, it works with wine (best to install wine via homebrew).

This means you're also chained to macOS 10.14 (Mojave), or have you found a way to run wine on Catalina?

What I've read, Wine does run on Catalina, it just doesn't run anything 32-bits. Because Catalina is 64-bits only.

I'm still on Mojave, and will not upgrade to Catalina before I'm forced to.

By gdx

Enlighted (6219)

gdx's picture

26-02-2020, 09:00

zPasi wrote:

I'm still on Mojave, and will not upgrade to Catalina before I'm forced to.

It is a wise decision. Especially as Catalina seems to be very buggy.

By uberjack

Champion (328)

uberjack's picture

26-02-2020, 09:07

gdx wrote:
zPasi wrote:

I'm still on Mojave, and will not upgrade to Catalina before I'm forced to.

It is a wise decision. Especially as Catalina seems to be very buggy.

FWIW, I've been running Catalina for a few months now, and except for the 64-bit restriction, there aren't any issues that I've come across. The hardware that I'm using (a mini and a macbook pro) is 2012, so it's not like it's brand new.

Overwhelming majority of the apps are compatible, and those that aren't (can't attest to Wine, but I know that Boxer/DOSbox already runs on it) are being worked on as we speak.

Page 1/2
| 2