[Exophase]

As a lot of you probably already know, I'm interested in porting MZX. As per my style, I decided not to post anything officially until I actually had something done. I'll get to the later though. Here's the idea of the project:

Goals:

Make MZX easily compilable on other platforms, while retaining full compatability. Source should be as maintainable as possible. After porting is mature, integral changes to MZX itself may be made.

Procedure:

These are the first steps necessary, later more will follow...

* Translate all non-hardware dependant ASM code to C. Keep within DOS MZX for testing.

* Modify all source files to comfortably compile in GCC. Possibly convert to full ANSI C. Replace hardware dependant portions with stubs.

* Add emulations for hardware functionality should be written, using a cross-platform library (SDL is planned). Try to make as translucent as possible to MZX as it is now.

* Further unnecessary code should be taken out of MZX (like all EMS stuff)

* Write new robot editor (incorporating RASM)

Anyway, I'll post progress on this thread and ask for beta testers when I need them (if anyone has a Mac of some sort you might be useful in the distant future).

So far, I've translated game2.asm to C. game2.asm is the single largest ASM file in MZX's source, weighing in at over 3800 lines. It's quite possibly the most daunting thing to deal with in doing a port... There are still some bugs that need to be fixed, but at this point it's fairly mature.

Oh, and some people might be asking why I'm bothering, when BFeely has a port out. While BFeely's port is functional, it's very Windows/MSVC specific and that's no good for my goals. He's also rarely around here and that makes it difficult to properly report bugs or keep up to date with his progress. I intend to at the very least be here constantly.

I'll post more here as I have it. Right now I need to keep fixing game2.cpp bugs.

- Exo

[Exophase]

With Quasar's bugtesting, game2.cpp has reached a point where it seems fairly bug-free. At the very least, Caverns can be played through entirely without any problems.

I realized that not only has idput.asm already been ported, but we've been using it since MZX 2.51s3. In fact, it's because of it it that many of the new features have made their way to MZX, and sprites have been possible (because it allowed for ways to get the current char from the board). Some of the code is rather messy, though. I might try to work with it to make it friendlier.

I ported idarray.asm. This didn't take long at all, and seems to be working without any problems.

I ported string.asm well over a year ago, but never tested it. I'll get to work on incorporating it next. Besides that, most of the non-hardware dependant ASM in MZX has been converted to C.

- Exo

[T-Bone]

That means there's going to be new bugs allow with anything new.

[lipid]

When JZig was working on MZX, I seem to remember him converting
MZX's ASM to portable C. Which files did he do?

[Exophase]

lipid, on May 28 2004, 07:21 PM, said:

When JZig was working on MZX, I seem to remember him converting
MZX's ASM to portable C. Which files did he do?

Actually it was MenTaLguY that did idput.cpp, not JZig. JZig merely modified it so that it'd compile in BCC. JZig said that he converted game2.asm, but lost the source.

- Exo

[Exophase]

Okay, I made the first real push to moving out of DOS. I got all of MZX's C++ files to compile in G++, stubbing out everything that linked to something that needs to be totally rewritten. Here are the new modules that need to be made:

* Graphics code: This should include all of graphics.asm, egacode.asm, and some new encapsulation functions for accessing characters and the charset. SDL will be used to render the characters. Will emulate SMZX.

* Keyboard code: Part of an event loop. A translation function will have to be used to convert between the codes MZX uses (PC XT keyboard and DOS ASCII codes) and what I'll be using (SDL).

* Mouse code: Part of the same event loop as above. This comes later, since MZX doesn't need it to run.

* Module code (music): Will use libdmodplug for this one, and wizdom offered to let me use his GDM->S3M code. An actual GDM loader for libmodplug would be nice. May use MikWin instead initially, depending. SDL will be used for audio output, with a rudimentary mixer.

* PC speaker code: Will emulate the PC speaker (it's a simple sine wave) and through it on the list of things to be mixed.

* Sample playing: Seperate from the module code. Will convert them straight to the mixer list.

* Directory listing: This has to be redone since it's very DOS specific. Will use POSIX dirent code (may not work on MSVC, but that's okay, I'm using mingw and you should too!)

* Timer code: No real timer code is necessary; MZX has its own timer handler but that's both unnecessary and impossible in a modern OS. Merely using SDL_Delay() and SDL_GetTicks() should suffice. Will probably encapsulate these to simplify. On OS's with low resolution timers some spinlocking may be necessary to compensate lack of granularity (on Windows 98/2k+ this shouldn't be a problem; older Linuces might have problems though)

I'm going to need the display code, keyboard code, and timer replacements to really run anything. I'll code all of the first two with independant testbeds to make sure I can get them working. Display code is the first thing I'll be working on.

- Exo

[Mr. Apol]

I'm eagerly awaiting this. I'm so glad you're working on it.

[weasel]

This may very well get me back into MZX. If you're taking requests (which I doubt), can you include a gamma slider? PowerStrip doesn't seem to like SDL stuff on my computer, so I can't adjust gamma mid-game...

[Exophase]

I'm pinning this. Because I can. ^_- I'll resume work on it once I get my MZXO entry out of the way (grrgh)

- Exo

[ZzCrook]

Exophase, on May 29 2004, 09:09 PM, said:

I'm pinning this. Because I can. ^_- I'll resume work on it once I get my MZXO entry out of the way (grrgh)

- Exo

CURSE THE MAN WHO THOUGHT UP THE MZXO!

[Tokugawa]

Yeah... can you avoid EMS? LOL! My computers BOTH suck...

[Exophase]

Tokugawa, on Jun 1 2004, 08:47 AM, said:

Yeah... can you avoid EMS? LOL! My computers BOTH suck...

There won't be EMS issues.

I've pretty much finished the graphics stuff (I think?). graphics.cpp should handle all of the functionality of graphics.asm, egacode.cpp, palette.cpp, cursor.asm, and some others. I've done some keyboard handling code; since SDL both gives keycodes similar to ASCII and the actual hardware scancodes it may fit into MZX okay (we'll see).

- Exo

[paulguy]

Yes he can if it is in Windows. Windows doesn't rely on EMS. But for compatibities sake he should keep a few of the memory limitations for people's computers that won't run a windows MZX well.

[Revvy]

Exophase, on Jun 1 2004, 10:26 AM, said:

I've pretty much finished the graphics stuff (I think?). graphics.cpp should handle all of the functionality of graphics.asm, egacode.cpp, palette.cpp, cursor.asm, and some others. I've done some keyboard handling code; since SDL both gives keycodes similar to ASCII and the actual hardware scancodes it may fit into MZX okay (we'll see).

Rox0rz. Since progress seems to be zooming along so well, what's taken so long for this to actually be started before now?

[asgromo]

Revvy, on Jun 1 2004, 05:49 PM, said:

Exophase, on Jun 1 2004, 10:26 AM, said:

I've pretty much finished the graphics stuff (I think?). graphics.cpp should handle all of the functionality of graphics.asm, egacode.cpp, palette.cpp, cursor.asm, and some others. I've done some keyboard handling code; since SDL both gives keycodes similar to ASCII and the actual hardware scancodes it may fit into MZX okay (we'll see).

Rox0rz. Since progress seems to be zooming along so well, what's taken so long for this to actually be started before now?

Prior lazyness, a pox suffered by all MZXers.

[djtiesto]

Sounds excellent... I've been waiting since I first got Windows 98 for something like this. Will the music quality improve with the port, since you mentioned you were using new libraries? Something that will allow you to directly use .S3M (and now, .XM or .IT) would be a lot better methinks than something that only allows you to directly use .MOD and .GDM... So basically, now that you say it's platform independent.. will it work on Linux or Mac?

[Dr Lancer-X]

djtiesto: There's an almost 100% chance that Exo will be using Libmodplug for MZX, which allows for pretty much everything module-related, specifically .669, .amf, .ams, .dbm, .dmf, .dsm, .far, .it, .j2b, .mdl, .med, .mod, .mt2, .mtm, .okt, .psm, .ptm, .s3m, .stm, .ult, .umx, .xm. Support for high-bitrate .WAVs should also be possible. Support for .SAMs (raw 8-bit .SAMs) would be easily possible for backwards compatibility, but not necessary. GDM support could be done, but it may not be.

EDIT: And yeah, should work fine on Linux and Mac providing Exo sticks with cross-platform compatible libraries. LibModPlug uses portable C++ without requiring OS subroutines (thusly, inherently compatible) afaik, and SDL is compatible with many platforms too.

This post has been edited by Lancer-X: 02 June 2004 - 03:08 AM

[Revvy]

There's even a port of SDL for PS2, I think. If you removed the sound library then that might be interesting =D

[Exophase]

The port will indeed be using libmodplug. Native support for GDM won't be present; instead a convertor (by wizdom) will be available that will convert all GDM instances in an MZX file and convert all the GDM's it refers to, to S3M (or whatever else they were originally)

Directory listing is working, preliminarily. Keyboard input was put to the test and works, and I added my own auto-repeat (for some reason it doesn't work so well in SDL..)

For Mac compatability I'm going to have to be careful to make it Endian-safe. FWIW, modplug should be reasonably portable, since it's memory only (works on modules given in memory, and outputs to memory)

- Exo

[T-Bone]

This is incredible! The IT and XM music formats playable through MZX would pretty cool! With good graphics (SMZX mode) and good music that works on both MAC and PC this will be the biggest improvement for Megazeux ever! I'll wait as long as it takes to make it happen...no rush.

Exo, you are the heart of MZX right now and we are your blood.

[weasel]

Lancer-X, on Jun 1 2004, 08:04 PM, said:

Support for .SAMs (raw 8-bit .SAMs) would be easily possible for backwards compatibility, but not necessary.

Well, you know, a SAM is, in essence, an 8-bit signed WAV file. With no limits, we can pump this up to 16-bits, 44100 Hz audio files...I can exercise my ear for quality.

[Frobozz]

T-bone6, on Jun 2 2004, 10:50 AM, said:

With good graphics (SMZX mode)

Since SMzx would work on every computer that the Windows port worked on I could imagine seeing a lot of games using it appear.

This post has been edited by Frobozz: 02 June 2004 - 06:08 PM

[Revvy]

WildWeasel, on Jun 2 2004, 12:08 PM, said:

Lancer-X, on Jun 1 2004, 08:04 PM, said:

Support for .SAMs (raw 8-bit .SAMs) would be easily possible for backwards compatibility, but not necessary.

Well, you know, a SAM is, in essence, an 8-bit signed WAV file. With no limits, we can pump this up to 16-bits, 44100 Hz audio files...I can exercise my ear for quality.

The only problem with removal of limits is that game sizes will probably skyrocket. I don't want to download 5-10mb zips with all the latest XMs and professional quality sound effects.

[weasel]

Revvy, on Jun 2 2004, 01:16 PM, said:

The only problem with removal of limits is that game sizes will probably skyrocket. I don't want to download 5-10mb zips with all the latest XMs and professional quality sound effects.

Well, just because I can use such high-quality sounds doesn't mean I'll abuse them...why bother with a high-quality stereo sound for a pistol, when it sounds exactly the same at a lower quality?

[Dr Lancer-X]

Weasel: Well, having WAV files would be best. SDL has inherent support for loading WAV files of a couple different formats. SAMs, or at least the kind MZX uses are just raw sound data, so they could be simply loaded into memory. We wouldn't be able to really be able to have SAMs of different bitrates and bit amount(8, 16, 24 etc) because there is no way of specifying what these values are in the SAM file (as there is no header). Therefore, if you want higher quality, use WAVs; nearly every sound modification prog supports them, so..

[Exophase]

Like Lancer said, SAMs are raw. So MZX will load them at 8bit 11kHz and upsample them to 16bit/44KHz, which is what audio streams will be at internally in MZX (including PC speaker). Modplug supports WAV, so that will be used to support it.

So, I haven't been around much (as can be seen) because my connection hasn't been working save for a few hours a day. I've still been working on MZX, of course. Right now I'm essentially running through every file and modifying them, cleaning out unnecessary things and converting other bits. Also making the formatting less offensive to the eyes (so if you don't like my formatting style, sorry. You can change it when it's your turn.) Unfortunately I haven't been able to test anything yet because there are still too many missing things. At this rate it's almost turning into an all or nothing kind of deal.

- Exo

[MadBrain]

Well, dunno, the default sample rate for SAMs - the rate it used when you tested them with Alt-L, was something like 8363hz (default sample rate for middle C in MODs), but obviously some games played samples at stuff like 22khz or more. The SAM command used sample_rate=3579364/period (period is the number you specify when you use the sam command). The music engine resampled everything, and the final rate was probably 44khz (on the sb16 setting). It would probably be interesting to be able to be able to change the volume or the panning used by sound effects in addition to the sample rate which you can allready modify.

As for the PC speaker, technically the speaker outputs a square wave, but it's pretty muffled inside the PC case so you have to filter it to come close of it's metallic sound.

[weasel]

MadBrain, on Jun 3 2004, 06:53 AM, said:

As for the PC speaker, technically the speaker outputs a square wave, but it's pretty muffled inside the PC case so you have to filter it to come close of it's metallic sound.

Removing the bass from the output of the sample, leaving it with mostly treble, would help in that kind of effect. At the very least it'll make it sound like it's coming over the phone.

[Dr Lancer-X]

MadBrain:

Ah yes, I forgot you could include a sample frequency when you played SAMs; haven't used the command in who knows how long.

As for the PC speaker, you could either emulate it with raw sound, or some kind of wave. Better still, you could drop it out altogether, though a rare few games (like Gemini's old sidescroller) actually use PC speaker effects well. Even so, I have PC speaker fx permanently on OFF so it won't bother me no matter what you do.

~ Lancy-Rexxy

[paulguy]

I say use a sine wave because nobody likes how it ACTUALLY sounds. Too scratchy and a sine wave is smoother and easier on the ears.