Home

Maluva is a DAAD extension which can be loaded so DAAD has new features not included in the original interpreters. Maluva supports different features, and most of them are supported by all the 8 bit targets DAAD supports. In some cases, a specific feature is not suported by Maluva for a given target, cause that target already supported that feature natively.

Which functions are provided by Maluva?

Maluva can load raster graphics directly from floppy or hard drive, so you can make better pictures than those vectorial graphics used in the 80s, and also save the RAM those vectorial graphics were using, so you can develope larger adventures. This function is named XPICTURE.
Maluva can load and save the game status to floppy or hard disk. These functions are named XSAVE and XLOAD.
Maluva can load messages (text) directly from disk, what would allow you to create large games with more text, and not be limited to the amount of text fitting in memory. This function is called XMES and/or XMESSAGE (like the normal messages are called via MES or MESSAGE condacts).
Maluva can be told, in case the game have several parts, which part it is running. That helps having both parts in the same disk, using each one different file names. At the moment it's only used byt the XMESSAGEs function, so two different sets of files can hold the messages for each part.
Maluva has a replacement for BEEP for some machines where BEEP condact was not supported. That also helps using XPLAY feature if you use the DRC compiler for DAAD, althoug XPLAY is not a Maluva function.
Maluva can make split screen (one video mode in the upper half of screen, one video mode in the lower half) in CPC and C64, which have modes that are very intersting for this feature. XSPLITSCR does that.
Maluva can revert the "done" status set by the execution of an action condact. XUNDONE is used for that.
Maluva has function specific for ZX Spectrum Next and ZX-Uno: XSPEED, which is explained below.
Maluva has also two specific Spectrum Next functions XNEXTCLS y XNEXTRST, which are explained below.

Which functions are implemented for each platform?

	ZX ESXDOS	ZX +3	CPC	C64	Plus/4	MSX	ZX Next	ZX Uno	PCW
XPICTURE	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Native
XSAVE	Yes	Yes	Native	Native	Native	Yes	Yes	Yes	Native
XLOAD	Yes	Yes	Native	Native	Native	Yes	Yes	Yes	Native
XMESSAGE	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
XPART	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
XBEEP	Native	Native	Yes	Native	Native	Yes	Native	Native	No
XSPLITSCR	No	No	Yes	Yes	No	No	No	Yes	No
XUNDONE	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
XNEXTCLS	No	No	No	No	No	No	Yes	No	No
XNEXTRST	No	No	No	No	No	No	Yes	No	No
XSPEED	No	No	No	No	No	No	Yes	Yes	No

ZX stands for ZX Spectrum, CPC for Amstrad CPC, C64 for Commodore 64, Plus/4 for Commodore Plus/4, ZX Next refers to ZX Spectrum Next and PCW means Amstrad PCW.

Please notice "Native" means the original interpreter already supports a similar feature, so Maluva does not support it. In most cases, DRC compiler will replace the Xcondacts with normal ones when the target is one machine supporting features natively.

Using Maluva Functions with DRC

Although it's possible to use Maluva - at least partially - with old DC compiler, it's much better if you use it with the new compiler: DRC. Using Maluva with DC it's more complicated and it's not covered in this documentation, as I do myself consider DC obsolete.

To let DRC know you will use Maluva you have to define it as an extern just before the /CTL section:

#extern "MALUVA"
/CTL

Please notice DRC accepts only a BIN file as parameter for #extern, but if the parameter is "MALUVA" then it will determine which BIN file is used depending on target and subtarget chosen. So for instance, if your target is CPC, then DRC will replace that "MALUVA" with "MLC_CPC.BIN", and if target/subtarget is ZX/PLUS3 then it will replace "MALUVA" with "MLV_P3.BIN". Make sure you have downloaded all BIN files from latest release. You can also get the binary files directly from Github release folder, but take in mind there may be development builds there.

Function 0 : XPICTURE

DRC directly supports condact :

XPICTURE <picno>

You can of course use indirection in that parameter, for instance use this call to load the picture whose number is the current location number:

XPICTURE @38

You can also use it directly to load a specific picture:

XPICTURE 112

The picture files should be available in the disk where the game is, and their file name should be in the following format:

nnn.ext

Where nnn is the picture number with three digits (i.e. 001, 067 or 212) and ext depends on target:

ZXS: for ZX Spectrum +3 or ESXDOS (001.ZXS, 067.ZXS, 212.ZXS)
NXT: for ZX Spectrum Next (001.NXT, 067.NXT, 212.NXT)
MS2: for MSX (001.MS2, 067.MS2, 212.MS2)
CPC: for CPC (001.CPC, 067.CPC, 212.CPC)
64: for Commodore 64. Important note: Commodore 64 files should not have the dot to separate number and extension (00164, 06764 and 212).
UNO: for ZX-Uno (001.UNO, 067.UNO, 212.UNO)

To create the files required you should use SC2DAAD utility, avaliable in the Maluva package.

Please notice DRC would convert XPICTURE calls into PICTURE calls when the target platform does support raster graphics natively.

Function 1: XSAVE

DRC supports the XSAVE condact, which will be replaced by SAVE condact automatically when the target platform does natively support saving to disk.

XSAVE opt

In case the target directly natively supports saving to disk, DRC will replace XSAVE with a standar SAVE call automatically. Although XSAVE has opt parameter as the original SAVE condact, the value will be ignored, but will be used in case XSAVE becomes eventually a standard SAVE.

Function 2: LOAD

DRC supports the XLOAD condact, which will be replaced by LOAD condact automatically when the target platform does natively support loading from disk.

XLOAD opt

In case the target directly natively supports loading from disk, DRC will replace XLOAD with a standar LOAD call automatically. Although XLOAD has opt parameter as the original LOAD condact, the value will be ignored, but will be used in case XLOAD becomes eventually a standard LOAD.

Functión 3: XMESSAGE

DRC supports the XMESSAGE and XMES condacts, which will be replaced my MESSAGE and MES if the target platform does not support loading messages from files.

XMESSAGE "Hello world!"
XMES "This is a message without carriage return"

To make XMESSAGES work you have to make sure you include in the game floppy disk the file 0.XMB generated by DRC, apart from the .DDB file.

Please notice for CPC and C64 there could be several XMB files, in the nn.XBM format, make sure you copy them all. See C64 build notes below for a special detail on how to copy these XMB files.

Functión 4: XPART

If you a two-parts game, and want to hold the files in the same disk, you may run into a problem when you have to store two different XMB (xmessage) files. As Maluva expect them to be named the same for both parts writing them on same disk would make one overwrite the other. XPART may be run before any XMESSAGE/XMES is executed, so Maluva knows it's running some other part.

For Spectrum and MSX, the parameter will be added to the '0' at'0.XMB'. So for instance if value is 1, then Maluva will load 1.XMB instead of 0.XMB, if value is 7 then 7.XMB would be loaded, etc. Don't try to use values above 9, it won't work as you expect.
For C64 and CPC, if value is not zero, then 50 will be added to file names. That means instead of loading 00.XMB, 01.XMB, etc. the files 50.XMB, 51.XMB will be loaded. On C64 instead, of file "00" Maluva will read "50", instead of "01", it will take "51", etc.

Function 5: XBEEP

Duration is in 1/50 for second, so duration 50 equals one second.
Tone is a value from 48 to 238, which allow playing notes for 8 different octaves. Values above or below will be taken as silence.

Only even values are valid, that is C is 48, C# is 50, D is 52, D# is 64, E is 66, F is 68, etc. If you use an odd value, you will probably just get noise.

For each octave this are the ranges:

Octave	Range
1	48-70
2	72-96
3	98-118
4	120-142
5	144-166
6	168-190
7	192-214
8	216-238

For machines not supporting XBEEP, DRC compiler will replace XBEEP with BEEP.

Function 6: XSPLITSCR

For machines supporting split screen (currently Amstrad CPC and Commodore 64), this condact allows defining which mode will be used. Please notice the value has nothing to do with specific video modes in the target machine, but for a given configuration of modes. This is what mode means for each machine:

target		upper half video mode	lower half video mode
CPC	0	CPC Mode 1	CPC Mode 1
CPC	1	CPC Mode 0	CPC Mode 1
CPC	2	CPC Mode 2	CPC Mode 1
C64	0	C64 HiRes	C64 HiRes
C64	1	C64 Multicolor	C64 Hires
ZXUno	0	Standard	Standard
ZXUno	1	Timex HiColor	Standard

Please notice to used this condact in CPc, apart of the extern file, you should include the interrupt handler binary (MLV_CPC_INT.BIN). Your source code should include MALUVA (first) and the interrupt handler, like this:

#extern "MALUVA"
#int "MLV_CPC_INT.BIN"

To use this split mode please have this in mind:

A split screen is a quite hacked mode that requires a lot of control from DAAD to keep, specially if you used different modes in the upper and lower zones.
The split mode is built so the upper zone (picture) is 96 pixels high and the lower zone 104 pixels high, but is quite complicated to control the split zone exactly, so it's not recommended having the text area going too close to the picture area, or text can be affected. A window starting at ROW 14 is recommended (WINAT 14 0).
If you paint text in the upper area, and that area it's not using the same mode the lower area is, text will not look well (as it will be painted as if it was in the lower area mode, but it is not)
You can change modes during the game, if that is required, but if you don't want too much flickering or strange palette effects you better clear the window completele before changing. Please notice CLS condact clears only text window, so to clear the whole screen you need to enlarge text window, clear screen, and bring back original size.
If you are going to use standard DAAD mode just don't use XSPLITSCR. Take in mind using the condact in CPC without loading the interrupt handler may freeze your game.
You can still use full screen pictures, but it's recommended, unless you know what to do very well, that you have both upper and lower screen modes the same when you want to paint a picture like that (nevermind the mode, but the same for both areas).
Command using the disk (i.e. XLOAD, XSAVE, XMESSAGE) may produce some glitches in screen when upper and lower mode are different, that is normal and cannot be avoided. In C64, as the disk is quite slow, the effect is very clear, so we decided that Maluva would hide the screen completely while showing XMESSAGE.

Hiding the screen cannot be done while saving/loading cause save/load are native to the C64 interpreter, so there is nothing you can do to avoid the way it looks, except clearing the picture or loading a blank picture when saving.

In C64, the loading/saving time is sometimes too long, and the split screen code gets desychronized. So it's highly recommended to use XSPLITSCR just after save/load to ensure the synchronization works fine.

Function 7: XUNDONE

XUNDONE changes the "done" status to not done. Every time DAAD executes an action, the internal interpreter status of "done" is set. That means if ISDONE or ISNDONE conditions are executed, they will succeed or not accordingly.

Please notice unlike NOTDONE, XUNDONE just clears the done status, but doesn't go to the end of the current process.

There are cases where even when an action is executed in a process, we don't want to consider the process "done". An clear example is the SYNONYM action. If you write an entry like this, so TURN ON LIGHT it's synonym to SWITCH ON, as soon as SYNONYM is executed, the internal status is already "done".

> TURN LIGHT
    SYNONYM SWITCH _

If later you write this entry, it may happen if the user forgot to type "ON", as PREP will fail, the entry won't be succesful:

 SWITCH _
 PREP ON
 MESSAGE "You turn on the lights."
 DONE

But as SYNONYM was executed and DAAD considers something has been done, when the response table ends, as status is "done", there won't be a "I don't understand" or "You can't do that message", just nothing, so the game will look like this:

> TURN LIGHT
> (next prompt)

For this case and others were, despite something having been done, you don't want the "done" status to remain set, you can use XUNDONE, which will clear the "done" flag.

Pleas notice there is no XDONE or similar to activate he DONE flag, cause you can activate it by running any action condact. If you want a condact which does nothing, you can use "GOTO @38".

Function 8: XNEXTCLS

This is a Spectrum Next exclusive function, which clears and disables layer 2. As in Spectrum Next games the pictures are painted in layer 2, DAAD cannot delete them with CLS. To allow the author to remove the pictures you can call this Maluva function.

Function 9: XNEXTRST

This Spectrum Next exclusive function, just makes a soft reset. The reason behind this function is if you use END condact to finish a Next game, it makes a reset without clearing and disabling the layer2, so you may find the game resets but the picture is still there beside your Next menu. To avoid that, it's recommended to avoid using END, and replace it with a combination of INKEY and this function. This code replaces END

;#define yesScancode 115 ; Spanish "s"
#define yesScancode 121 ; English "y"
#define noScancode 110  ; "n"

> _     _       SYSMESS 13 ; Another try?
                NEWLINE
                NEWLINE

> _     _       INKEY 
                SKIP 1  ; Something pressed

> _     _       SKIP -2 ; Nothing pressed, wait for keypress


> _     _       EQ 60 yesScancode
                GOTO 0
                RESTART    

> _     _       EQ 60 noScancode
                XNEXTCLS
                XNEXTRST          ; Next cleanup and machine reset
                
> _     _       SKIP -5  ; neither "n" nor "y" pressed

Function 10: XSPEED value

This function allows you to set CPU Speed in ZX-Uno and ZX Spectrum Next targets. Value can be 0 or 1, so 0 is 3.5Mhz and 1 is 7Mhz. Although both machines support faster speeds, they do sometimes interfere with some Maluva features, so we've kept 7Mhz as safe speed. Please notice if value is not 0 or 1, XSPEED call will be just ignored.

Increasing the speed makes the game text be printed faster, and helps a lot with image loading. Sadly, original BEEP implementation in the ZX Spectrum interpreter is also speed up, so please make sure you restore standard speed before a BEEP or XPLAY, or it will sound at a higher frequency (sharper).

Error reporting

Some Maluva functions may fail cause of external reasons. For instance, reading a picture from disk by XPICTURE may fail cause the file is not there, cause he user extracted the disk, etc. Maluva does nothing in those cases, at least apparently, so if for instance a picture is not there, no picture will be loaded, and if the XMessage file is not there, the message won't be shown but nothing else.

But Maluva does something: when a call to Maluva fails, the 7th bit of flag 20 is set, when it suceeds, the 7th bit of flag 20 is cleared. In other words, if after a XPICTURE call you do "GT 20 127", that condition will suceeed if the picture failed to load. That way, you can check and display a message (i.e. Warning: image not found, please insert disk):

_ _ XPICTURE @38
    GT 20 127
    MESSAGE "Warning: image not found, please insert disk"

or even this if you want to wait until the disk is inserted

_ _ XPICTURE @38
    GT 20 127
    MESSAGE "Warning: image not found, please insert disk and press any key"
    ANYKEY
    SKIP -1

On the other hand, Maluva can also report errors via de "done" flag status. If you set bit 0 of flag 20 (LET 20 1), Maluva, apart of saving result to flag 20, will also update the internal "done" flag accordingly, so if the call succeeds, the done status will be set but if not the done status will remain as it was when the call was executed. That way you can use ISDONE or ISNDONE after Maluva call. For instance, if in the initizalition process you have done that LET 20 1, you can later:

> _ _ AT 200
      XPICTURE 120
      ISNDONE
      MESSAGE "Error: picture not found, please insert disk"

Building release disks

There are several methods to build your final disks using Maluva, please follow the links for detailed explanation. Please notice these notes and the disks linked consider you will use Maluva XPICTURE for graphics, but the disks and procedures can be used exactly the same if your game doesn't have graphics. In case you game has vector graphics, you should replace the graphics database in the disks.

What does Maluva mean?

Maluva is not a an acronym, nor has an special meaning, it's just a tribute to first adventure made with DAAD, which was a free version of "Adventure", named "La Aventura Original". One of the NPCs in that game was a dwarf named "Maluva", some kind of shortening of spanish expression "tener mala uva", which is somehow similar to being unkind, unpleasant, or in the end, to be a nasty piece of work. Unlike the dwarf, the current Maluva extension is not , of course, any of that.

Why all new condacts start with an X?

The leading X in the new condacts just mean eXtra, as they are additional or extra condacts. Also, there is no standard condact in DAAD starting with an X, so it was convenient.

Can I use Maluva with old DC compiler?

But... why use DC? DC requires dosbox to run, handling output is complicated, generates bigger DDB files and has less features than DRC.

Anyway, as there are some few advantages of DC over DRC, or maybe because you discovered Maluva when you have already typed most of your adventure in the old SCE format, here are some notes to use Maluva with DC:

Check DAAD Manual about how to include #extern and #int binaries
To call the Maluva functions, replace Xcondacts calls with EXTERN condact this way:

DRC	DC
XPICTURE x	EXTERN x 0
XLOAD	EXTERN 0 1
XSAVE	EXTERN 0 2
XMESSAGE	No way
XPART x	EXTERN x 4
XBEEP x y	EXTERN x 5 + #DB y
XSPLITSCR x	EXTERN x 6
XUNDONE	EXTERN x 7

Support me

Well, honestly I do this for fun, so I don't really need support. I enjoy every minute I work in these kind of tools, and when I don't enjoy it, I just don't do it. If anyway you want to support me somehow you can send me a copy of your games (either digital or physical), or as last option, just buy me a beer via paypal donation.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly