(FreeMint) port of dMagnetic v0.30

[cb]

Here is a port of dMagnetic v0.30 to FreeMint. The sources are located at https://www.ifarchive.org/indexes/if-ar ... dmagnetic/ and much to my suprise, they compiled on first try.

What is dMagnetic? It is an interpreter for Magnetic Scrolls text adventures, with ASCII graphics.
This version requires FreeMint, TosWin2, and a rather high resolution in order to get ASCII art that actually ressembles the graphics from the original games. There is a text-only mode as well. Just have a look at the ini file

I won't however provide any support to this port, as I actually don't know anything about C.
This has only been tested on Aranym, but I don't see why it wouldn't work on a real machine. Also, the save/load system works. Not the command history with Up arrow though.

[cb]

-- nevermind --

[Eero Tamminen]

What is dMagnetic? It is an interpreter for Magnetic Scrolls text adventures, with ASCII graphics.
This version requires FreeMint, TosWin2, and a rather high resolution in order to get ASCII art that actually ressembles the graphics from the original games. There is a text-only mode as well. Just have a look at the ini file

I won't however provide any support to this port, as I actually don't know anything about C.
This has only been tested on Aranym, but I don't see why it wouldn't work on a real machine.

This seems to work fine without FreeMiNT, e.g. in Hatari emulated TT high res mode with EmuTOS and at least 10MB of RAM, when using these "dmagnetic.ini" settings:

Code: Select all

rows=42
columns=160
...
mode=monochrome

It looks like this:

grab0001.png

Also, the save/load system works. Not the command history with Up arrow though.

Missing command history is a bit of a bummer. Are you sure it's not just an issue of missing something like libreadline or libedit devel files while configuring / building this?

[cb]

Wow, it doesn't look too bad in monochrome!
About the command history, it might be indeed worth investigating. I'll have a look at it.

[cb]

After checking, dMagnetic doesn't use readline at all.
Also, the sources at ifarchive.org are outdated: latest version is v0.34! It compiles just as fine as v 0.30, but still no command history.

[Eero Tamminen]

Sources are a bit hard to follow, but it seems just to use C-library fgets() function to read input string. Can it really be true that dMagnetic has no line editing support for any platform?

[cb]

My thoughts exactly. I think it has not been implemented yet. No big deal, that interpreter is already really nice as it is.

[DarkLord]

Has anyone tried this on real hardware yet?

What files are required to do so? I didn't see an Atari ST release on the
Magnetic site.

Thanks.

[cb]

https://magneticscrolls.info/magnetic.php

[DarkLord]

Thank you for the link but it appears to be the same as the one listed above?

I apologize for being dense but I still don't see an entry for "Atari ST".

Is it listed in some other fashion?

Thanks.

[EDIT] Never mind, thanks...

[Eero Tamminen]

Smallest setup I got the supplied binary to work was (emulated) 8Mhz 020 Atari ST with 10MB of RAM, and ST monochrome monitor:

grab0001.png

If cb would build it with some other compiler options, I'm sure with would works also on 68000, but whose Atari ST has 10MB or more RAM? It was also very slow with 8Mhz, so I think only some accelerator board, TT or Falcon, with enough RAM, would be OK for this.

PS. I used Gulam shell with following "gulam.g" startup script to get 50 lines on screen:

Code: Select all

msoff
set nrows 50
dmagneti.ttp fish

And following dMagnetic.ini file GFX settings for ST-high mode:

Code: Select all

[DEFAULTGUI]
; ST-high
rows=30
columns=79
mode=monochrome

[cb]

To be honest I have no idea how to reduce the memory footprint, or if it is even possible. I guess the whole bitmap to ASCII conversion alone, must eat up a lot of it, and it would also explain why it is so slow...

[Eero Tamminen]

I don't know of any good memory usage analysis tools for Atari. Best would probably to build same dMagnetic version for Linux, install Valgrind and use "valgrind --tool=massif" to analyze where the memory goes: https://valgrind.org/docs/manual/ms-manual.html

[dettus]

Hello.
So, I found your thread via a vanity search

To answer your question: There is actually a PRETTY EASY way to reduce the memory footprint... In Release 0.34, it is in the file src/toplevel/dMagnetic.c in the lines 39-42.
Hmmm.. And for some reason, you would have to edit src/engine/linea/linea.c lines 104 and 105 as well.
Aaaaaand src/toplevel/picture.h Line 50.

(Damnit... I thought I could write cleaner code than that! )

What I did there as to define the maximum amount of memory that would be needed for ALL THE GRAPHICS in one of the games, and that is WONDERLAND. And, to be better safe than sorry, I added A LOT OF HEADROOM.

You can experiment with those defines a bit, and see it it helps you.


BTW: It would be AWESOME to see my little project running on a real Atari ST. Please, please, PLEASE PLEASE tell me if I could help you in any way.

[dettus]

You know... Your threat inspired me. I am currently working on verson 0.35, which involves A LOT of code cleanup...

I already found 4 Megabytes, for example. Plus: The code is better structured now, so that people more enthusiastic than me can attach their own frontend.

[cb]

You know... Your threat inspired me. I am currently working on verson 0.35, which involves A LOT of code cleanup...

I already found 4 Megabytes, for example. Plus: The code is better structured now, so that people more enthusiastic than me can attach their own frontend.

Nice
I tried tweaking those cache settings you mentioned but only spared a few kilobytes. So I would say you need at least a Falcon030 with 14mb of RAM, which is a standard configuration nowadays, to enjoy the program. The best configuration is Aranym + Freemint + a rather high resolution.

Also, talking about frontends, did you consider adding glklib support as an option? I did compile that lib and a few interactive fiction interpreters and I was pleasantly surprised that it added command history and an info/score bar on top of the screen. And I guess with a very high resolution and a small font you could have the graphics on screen + info bar on screen at all times. However it would probably break ST compatibility as TOS builtin terminal is not advanced enough.

[Eero Tamminen]

What I did there as to define the maximum amount of memory that would be needed for ALL THE GRAPHICS in one of the games, and that is WONDERLAND.
...
BTW: It would be AWESOME to see my little project running on a real Atari ST. Please, please, PLEASE PLEASE tell me if I could help you in any way.

It should already run in real TT with TT mono monitor, and in Falcon on color one, as those support large resolutions and large enough memory amounts (and many people have nowadays installed enough), and dMagnetic worked fine under Hatari emulation of those.

However, real ST / STE machines have only max 4MB in them. After TOS starts, and dMagnetic binary is loaded to memory, there's about 3.5MB left.

If dMagnetic loads all gfx into RAM at the same time, do any of the Magnetic Scrolls games fit into 3.5 MB?

[dettus]

If dMagnetic loads all gfx into RAM at the same time, do any of the Magnetic Scrolls games fit into 3.5 MB?

To be honest, I have never bothered checking how much memory I REALLY need, since my goal was to run it on modern computers...

Thus far, the biggest collection of graphics I encountered where from WONDERLAND, and that one had ~2.5MB... Add ~200kByte for the game code and the text, and this is less than 3MByte.
However, I need a little bit for stack and the frontend.

Speaking of frontend...

Also, talking about frontends, did you consider adding glklib support as an option?

Yes, in fact, I did. However, I found the interface to be rather restrictive; i felt like it has been designed with ZORK in mind, rather than FISH, since it was not able to handle pictures properly. (Which are a HUGE PART of the Magnetic Scrolls Legacy...)
However, a large portion of my effort between 0.34 and 0.35 went into cleaning up the interface between frontend and engine though.
With any luck, there will be a release this week! (Great, now I am spamming...)


My goal for 0.36 is to create at least a GTK-Frontend, and use that as a vehicle to document the API for developers... It will be somebody else's problem by that point.



EDIT: If you do not wish to load ALL games from ALL different formats, it is possible to fit them into 3.5 Mbytes.
The .mag/.gfx files from the Magnetic Scrolls Memorial are smaller than that:

Code: Select all

% ls -l *.mag *.gfx
-rwxr-xr-x  1 dettus  dettus   199160 Jul  1  2022 fish.gfx
-rwxr-xr-x  1 dettus  dettus   162858 Jul  1  2022 fish.mag

-rwxr-xr-x  1 dettus  dettus   212224 Jul  1  2022 guild.gfx
-rwxr-xr-x  1 dettus  dettus   130858 Jul  1  2022 guild.mag

-rwxr-xr-x  1 dettus  dettus   271104 Jul  1  2022 jinxter.gfx
-rwxr-xr-x  1 dettus  dettus   156458 Jul  1  2022 jinxter.mag

-rwxr-xr-x  1 dettus  dettus    32540 Jul  1  2022 myth.gfx
-rwxr-xr-x  1 dettus  dettus    99370 Jul  1  2022 myth.mag

-rwxr-xr-x  1 dettus  dettus   276612 Jul  1  2022 pawn.gfx
-rwxr-xr-x  1 dettus  dettus   103466 Jul  1  2022 pawn.mag

-rwxr-xr-x  1 dettus  dettus   200297 Jul  1  2022 corrupt.gfx
-rwxr-xr-x  1 dettus  dettus   167466 Jul  1  2022 corrupt.mag

-rwxr-xr-x  1 dettus  dettus   951497 Jul  1  2022 ccorrupt.gfx
-rwxr-xr-x  1 dettus  dettus   177185 Jul  1  2022 ccorrupt.mag

-rwxr-xr-x  1 dettus  dettus   669633 Jul  1  2022 cguild2.gfx
-rwxr-xr-x  1 dettus  dettus   141766 Jul  1  2022 cguild2.mag

-rwxr-xr-x  1 dettus  dettus  2534113 Jul  1  2022 wonder.gfx
-rwxr-xr-x  1 dettus  dettus   183916 Jul  1  2022 wonder.mag

If you wish to run the releases from other platforms (such as the C64, Atari XL, for example) I recommend converting them on a PC first, using the -dumpmag and -dumpgfx commandline arguments:

Code: Select all

% ./dMagnetic -d64 guild1.d64,guild2.d64 -dumpmag guildc64.mag -dumpgfx guildc64.gfx
% ls -l guild*
-rwxr-xr-x  1 dettus  dettus  174848 Jan 23 22:27 guild1.d64
-rwxr-xr-x  1 dettus  dettus  174848 Jan 23 22:27 guild2.d64
-rw-r--r--  1 dettus  dettus  141701 Jan 23 22:27 guildc64.gfx
-rw-r--r--  1 dettus  dettus  130858 Jan 23 22:27 guildc64.mag

[dettus]

Btw: Release 0.35 is out NOW.

https://dettus.net/dMagnetic/dMagnetic_0.35.tar.bz2


I moved the defines we discussed to src/frontends/default/main.c Lines 46 and 47 (and only there)

Code: Select all

#define MAXMAGSIZE      (1<<20)
#define MAXGFXSIZE      (1<<22)

Changing this to smaller values, for example

Code: Select all

#define MAXMAGSIZE      200000
#define MAXGFXSIZE      500000

might restrict the amount of games playable, but it might also reduce the memory consumption to make them run on an Atari. *giddy*

[dettus]

Okay, now there is release 0.36.
I decided against the GTK frontend, but instead included a HelloWorld example.

https://dettus.net/dMagnetic/dMagnetic_0.36.tar.bz2

[Eero Tamminen]

You know... Your threat inspired me. I am currently working on version 0.35, which involves A LOT of code cleanup...

Nice

I tried tweaking those cache settings you mentioned but only spared a few kilobytes.

Have you had time to build / try the new 0.35 or 0.36 version?