Latest on C dev for the MTX SDCC etc,

Everything about programming, including VDP and Sound programming.
Potholepete
Posts: 42
Joined: 11 Aug 2012 22:13

Re: Latest on C dev for the MTX SDCC etc,

Post by Potholepete »

Hi Bill,

glad to know I am not the only one with way too many projects started (or still ongoing ;-) )

Re games running in which environment, I guess it would be good if it would be possible to have games that can run on an MTX500 with the right loader in place but I am guessing for anyone looking at developing and testing a good starting place is to get something up and running that can be tested in MEMU so a user basic option would be helpful. I am not skilled in these kinds of things though so have no real idea how easy or difficult getting some kind of MTX specific framework in place would be.

I did recall Paul taking about having some assembler libs he was getting in place to help with MTX game dev, I have searched on here and Dave's site and cannot find out if that happened or what stage they got to and I FB Paul a few weeks back but have not heard anything from him?

Jim
stephen_usher
Posts: 238
Joined: 27 Nov 2016 19:58

Re: Latest on C dev for the MTX SDCC etc,

Post by stephen_usher »

I guess that the most useful library would, like BASIC, abstract the hardware into simple function calls to control, for example the VDP or sound chip. Maybe also give access to the low-level function calls too in case people want to hit the hardware directly.

Another useful function could be the abstract memory bank paging etc.

With regards to running the process, I would suggest a standard BASIC loader which would then load the code and jump to the initialisation routine. Maybe always locate this within the MTX500 address space. Accessing other memory pages would be up to the library to work out. Maybe the initialisation routine would do a memory size check.
Potholepete
Posts: 42
Joined: 11 Aug 2012 22:13

Re: Latest on C dev for the MTX SDCC etc,

Post by Potholepete »

That sounds like a lot of good ideas to me, the main area I struggle with is anything that needs lots of old style dos or unix/cpm type of commands typed in to compile and so forth. making that process as simple as possible makes it more accessible to the less skilled of us :-)

I'm till waiting for a windowed scalable version of Memu ;-) though I have not checked out MAME in a long while and that is windowed and from a few posts on here seems to have better MTX emulation these days than when I last tried it (blue screen and curser and that was about it)
Bill B
Posts: 338
Joined: 26 Jan 2014 16:31

Re: Latest on C dev for the MTX SDCC etc,

Post by Bill B »

Potholepete wrote: 16 Jun 2022 15:48 I'm till waiting for a windowed scalable version of Memu ;-)
MEMU windows have always been scalable in integer steps (-vid-win-big or -mon-win-big repeated as many times as required). Fractional scaling creates the problem that emulated the emulated pixels are not all the same size.

My version of MEMU now supports the options -vid-win-max and -mon-win-max which attempt to find the largest integer scaling that will fit on the screen.
Bill B
Posts: 338
Joined: 26 Jan 2014 16:31

Re: Latest on C dev for the MTX SDCC etc,

Post by Bill B »

Potholepete wrote: 16 Jun 2022 15:48 That sounds like a lot of good ideas to me, the main area I struggle with is anything that needs lots of old style dos or unix/cpm type of commands typed in to compile and so forth. making that process as simple as possible makes it more accessible to the less skilled of us :-)
Then you are looking for an IDE that supports Memotech development. That is a completely different problem to a library providing SDCC callable routines. I suspect the only hope of that is an existing general purpose IDE that is sufficiently configurable. VS Code seems to be popular at the moment, but I know nothing about using it or how configurable it is. I am quite happy doing all my development using the command line.

Edit:

It looks like there are currently problems trying to use VS Code with SDCC:

https://github.com/microsoft/vscode-cpp ... ssues/7146
https://sourceforge.net/p/sdcc/discussi ... 049b17c55/
under4mhz
Posts: 26
Joined: 11 Apr 2021 05:12
Location: Brisbane, Australia
Contact:

Re: Latest on C dev for the MTX SDCC etc,

Post by under4mhz »

I like to port my code to other systems, and since Memotech is similar to an MSX, it was a fairly easy conversion, once I had all the information. I'd probably target programmers who are programming for similar platforms, it's requires a fair amount of dedication and programming ability to start programming and learn for any of these 8bit systems.

I'd suggest creating a sample project and page with all the relevant hardware information in one page. I wrote a similar document for the Microbee https://under4mhz.github.io/microbee/index.html

I like to know the VDP data/in ports and the PSG data port, also that the PSG is SN76489 (vs AY-3-8910). The amount of memory available is important as well (32/48k?). A memory map is useful as well, (ie that CPM is above 0xD000)

Code: Select all

#define VDP_DATA_OUT   0x01
#define VDP_DATA_IN    0x01
#define VDP_COMMAND    0x02
#define VDP_COMMAND_IN 0x02
#define PSG_DATA       0x06
and any other ports I may be missing.

Also important is some code on how to read the keyboard. I think I reverse engineered that from mame (I can't remember if I did or not, but I've had to for many other platforms).

A default crt0.s, with the correct org etc is important. I had to write my own, and that's a fair bit of messing around in assembler to get right.

Also highlight somewhere that since the z80 is running slightly faster than other systems at the time (3.6MHz vs 4.0MHz?) more wait states in the vdp code is needed.

Perhaps pick a format and hardware model for programmers to use and specify that in your documentation/examples. I'd probably suggest the MTX512, since it has the most memory (depends on the user base, though). Output as COM files, since those are fairly well known.

I'd suggest making a simple demo project, with everything included: ie type "make" and the whole thing is built and Memu is run automatically at the end (if it's in the path). I've done something like this for the Microbee https://github.com/under4mhz/microbee, since they have no documentation at all on the thing. But my example project is targeted for someone like me, who knows these systems well and simple needs information on what the ports and how to run it on an emulator. You'd probably want to make a simple game with sprites and sounds for general use.

There are two TMS vdu projects I know of. Probably leveraging off these libraries is a good idea. I don't know how popular these are. From what I can tell, most programmers are like me and wrote their own libraries, we have to get pretty close to the metal to get the performance needed for most games.

An advantage to adding support to these is MTX is added to the list of support platforms, and that may generate some interest if they start to ask "MTX, what is that?" It also means programmers can recompile their code and expect it to work on the MTX (hopefully,mostly).

https://github.com/sehugg/cvlibc
https://github.com/sverx/devkitSMS

cvlib (for the ColecoVision) has the same hardware at the MTX. I'd probably suggest forking this and adding MTX support. I'm sure he'd be amenable to adding an other platforms. As I mentioned, make sure the demos make a COM file, and the needed crt0.s.

devkitSMS is for the Sega Master System, but also supports it's predecessor the SG-1000 (the system of my childhood), which is pretty much identical to the MTX as well. Though I'm not sure sverx would be open to adding MTX support (Sega forever), there are certainly tools to leverage in there and a maintained fork may be worthwhile.

It's also important to be able to create and show assets such as background images, sprites and text from png/bmps files. I would like to be able to create, load and show tiles in 8x8 and 16x16 (or larger for more advanced games).

Can I suggest making the default options enabled with Memu to be -vid-win -snd-portaudio -diag-vid-time-check (at least on Linux) I found it confusing to run Memu and have it do nothing. I think I gave up, and tried Mame at that point. Without the vid-time-check I was releasing code that wouldn't work a on real MTX machine, and it's a pain to have to go back and find out where that's occurring. It's easier the first time.

The Mame roms package on the Memotech website has the finnish.rom missing (one of them, anyway), at that point I think I gave up on MTX for a while. Eventually I figured out that the finnish rom was in Memu, and somehow figured out the Memu command line switches needed to get the sound and video going.

I think most people targeting this machine are probably going to technical people like me (I'm an embedded C++ programmer by trade), so I doubt many are going to writing code in basic. From what I can see, those who do BASIC did so as a kid and are picking it up again as an adult, not starting on a new system.

I use sdcc, and from what I can tell most of us hardcore Z80/TMS9918 programmers do, but z88dk also supports MTX as pointed out on the Memotech website. http://primrosebank.net/computers/mtx/t ... _z88dk.htm. Maybe some specific instructions on how to build and run the demo projects maybe worthwhile. From what I can see, it's not immediately clear (ie easy) how to do that from the z88dk documentation.

I think it's important to have a demo project programmers can download, build and run. As a starter, I usually want to take someone's demo project and go from there. I just want to write games, not figure out all the bits before I can start (that can come later).

I know I'm lecturing on what others should do, rather than doing it myself. MTX isn't my main platform of choice, it's more of a side project.
Support me on Patreon: https://www.patreon.com/Under4Mhz
Potholepete
Posts: 42
Joined: 11 Aug 2012 22:13

Re: Latest on C dev for the MTX SDCC etc,

Post by Potholepete »

thats a lot of useful information and I appreciate you taking the time to write it all. I Think at the moment it sounds like there is too much for me to do before I can get back upto speed again with programming on the Memotech, especially with all the other projects I have on going. One day I hope to be able to actually complete one game in assembler on the MTX though ;-)

Jim
Bill B
Posts: 338
Joined: 26 Jan 2014 16:31

Re: Latest on C dev for the MTX SDCC etc,

Post by Bill B »

I thought I was making some progress on this for Jim, but then I ran into a problem with SDCC.
  • The Code::Blocks IDE provides reasonable support for SDCC,
  • I made a small start on a library of C callable routines that reproduced a number of the BASIC commands. These are routines written in assembler mostly just call the corresponding code in ROM.
  • I wrote a small program to demonstrate the library.
  • I wrote a Python utility to convert the Intel Hex format file produced by the SDCC linker into an MTX "*.run" file.
  • I demonstrated that it was possible to just select "Build" from the Code::Blocks menu and have the C source files automatically compiled into a RUN file.
All this was on my laptop running Ubuntu Linux.

Just to check, before posting here I finally tried it out on Windows. It did not work :( The program was build successfully, but when trying to run it on MEMU, it just crashed.

It turns out that the problem is caused by different versions of the SDCC compiler. On Windows I was running the very latest version of SDCC downloaded from the SDCC website. On my Linux machine I was running an older version of SDCC installed by the package manager.

The new version of SDCC has changed the way parameters are passed to subroutines. This breaks all my library subroutines. There is a command line parameter that can be set to tell SDCC to use the old calling convention. Code::Blocks does not have this as a check-box option, although it is probably possible to set this as an additional option.

Forcing everything to the old convention does not seem like the right approach, but equally if I change all the routines to use the new calling convention this makes the library unusable by anyone with an older SDCC.

I think perhaps the best solution is to have two versions of each routine, one for each calling convention, with slightly different names. Then use some #define trickery in the header file to call one version or the other according to the compiler version. Rather similar to the way Windows has ANSI and Unicode versions of many of the routines in its API.

That is is going to take a bit more work.

As an aside, the SDCC change is at some time going to break rebuilding all the programs for the NFX as they also involve assembler routines called from SDCC :roll:
User avatar
gunrock
Posts: 124
Joined: 28 Oct 2020 21:17

Re: Latest on C dev for the MTX SDCC etc,

Post by gunrock »

Yes, the change to the calling conventions in SDCC 4.1.12 (on a minor version) was a pretty radical move. There is some interesting chat on the MSX forums about it and the rationale behind it and the developer who worked on it published a paper on it here:

https://arxiv.org/pdf/2112.01397v1.pdf

It looks like there are some clear advantages (using registers for parameter passing) and it's something that the Sony's fork of the GCC compiler did for the first four parameters of a function call on PS1 and as the Z80 has a fair few registers, the performance increase should be noticeable.

From the perspective of your library Bill, why support the old compiler? It's unlikely that the old calling convention will make a comeback and running more than one toolchain for retro computers is no biggie. If they need to have an older SDCC around for another platform the overhead is minimal.
Steve G
Danish-keyed Memotech MTX 512, CFX II and loving it
Bill B
Posts: 338
Joined: 26 Jan 2014 16:31

Re: Latest on C dev for the MTX SDCC etc,

Post by Bill B »

Based on my conversions so far, the new convention is clearly better in some cases, and not quite so good in others.

It is worth supporting the old convention for Linux users (like me) who just want to keep whatever version of SDCC is supplied with their distro, rather than upgrading to the latest version.

My plan A for supporting both conventions does not work. A few of the routines have to be called by the SDCC run-time (in order to support printf () and scanf ()), and so need fixed names.

Plan B is to write all the routines as inline assembler in C files. It is then possible to use #if macros against __SDCCCALL to select code appropriate to the different calling conventions. One additional advantage of this approach is that Code::Blocks should then be able to build the library (it does not support pure assembler files).
Post Reply