I want to learn MSX-C, where do I start?

Page 10/12
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12

By AxelStone

Prophet (3020)

AxelStone's picture

26-08-2015, 18:43

JaviLM wrote:

No need to complicate things that much. The MSX-C manuals explains very well how to pass data to/from assembler routines (pages 54-59). It shouldn't be too much work to just wrap the MSX-DOS2 system calls in MSX-C functions.

I'll explain the process on my blog when we need that part. :-)

It seems a good aproach, wrap MSX-DOS2 functions in order to make bank switching. We'll be looiking forward for that chapter Smile

However a little thought about wrslt and rdslt. Can't you read an entire array? This is, using pointers to array perhaps we could read a complete array of data as Grauw suggest.

By Grauw

Ascended (10005)

Grauw's picture

26-08-2015, 19:45

The BIOS functions don’t support block read and write, if you want to do that you need to select the slot into an address range, copy the data, and switch it back. So indeed you could make a library function which selects the slot, memcpy it to or from another array outside the switched page, and then switch back to the original slot.

What I meant with byte array access though is, select a different mapper bank at address 8000H-BFFFH and have an array pointing to 8000H, I think something like:

TINY * memoryData = (TINY *)0x8000

Then you can access the data with memoryData[0x0], 1, 2, etc. up to 3FFFH. Could also be an array of structs as long as it doesn’t exceed 16K. But in general array-based access seems most convenient, because you don’t want to pack the values yourself. Alternatively, a single big struct containing all the substructures.

For something like loading graphics data into VRAM, or reading MML or tracker music data a byte array should work fine. For writing SCC sound data a struct may also be convenient, so you can access the registers in a structured way.

Actually, what do you need all that memory for? Smile 64K ought to be enough for everyone…

By AxelStone

Prophet (3020)

AxelStone's picture

26-08-2015, 20:24

Grauw wrote:

Actually, what do you need all that memory for? Smile 64K ought to be enough for everyone…

Only curiosity! Smile I'm starting so there is a long way before I could use more than 64kb. By the way I agree with you: 64Kb is a good amount of RAM to develop Wink

By Grauw

Ascended (10005)

Grauw's picture

26-08-2015, 21:23

Why I ask is, which is a good way to address the other slots and extra memory depends also on what you want to use it for. Smile

By hit9918

Prophet (2904)

hit9918's picture

26-08-2015, 22:30

To for example flip page 2
all the mallocs and global variables must not be above 0x8000.
because they will be the target of the transfer function.
or you have page 3 as target. the stackpointer must never be below 0xc000 + transfer area.
the question is not whether DOS can flip the page, the question is whether the application can survive it.

That is the thing I am working on with p3bios. With multibyte transfer from any subslot and mapping. And enaslt page 0. What the MSX always badly needed.

The user simply calls it and it works, no matter where is his code, his data, his stack.
It doesnt matter whether it's C, it works.
It is multitasking. Without that, one could end up with an experience like the player stuttering like one was loading from floppy.

To make this work for the user, without requiring him to know a dozen hack details, is complexity 42 times beyond otir() Big smile

The enaslot needs to be on a temporary stack.
The multibyte transfer needs another temporary stack.
Whenever one needs a temporary stack, it would need to have 256 bytes (always of SCARE page 3 area) to hold the double interrupt without crash.
Therefore is needed an interrupt stack.

With DOS I can't install it in HIMEM, is there a way to get a reliable page 3 allocation under DOS2?

By hit9918

Prophet (2904)

hit9918's picture

26-08-2015, 22:35

@Axelstone, rdslt works, except that it can't flip the mapper. It could read when you plug a vintage 16k RAM cartridge Smile
If you flip the mapper before the call to rdslt, one again got the same problems as mentioned above.
the p3bios slotread is with full address, slotid + mapper.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

27-08-2015, 10:30

Grauw wrote:

DOS2 memory mapper support routines only deal with the mapper and don't do slot selection

That's disappointing, because the slots management is the hard part, and the mapper selection is the trivial part, so DOS2 does little about memory management. I always thought that DOS2 will use all the RAM installed in the system slots, mapping them in a transparent way to the programmer.
The RAM mapper can be managed by your own simply writing a value in RAM, so I see no need to use DOS2 functions at all.

I'd like to ask for MSX-C basic types: un/signed 8/16/32 bit, and if float is available. If float is available can it be converted to int?.
Also, there is a way to read CPU flags, like carry?, or ASM is needed for that?.
Needed for implementing fixed-point arithmetic, in some and different ways.

By Grauw

Ascended (10005)

Grauw's picture

27-08-2015, 11:39

DarkSchneider wrote:

That's disappointing, because the slots management is the hard part, and the mapper selection is the trivial part, so DOS2 does little about memory management. I always thought that DOS2 will use all the RAM installed in the system slots, mapping them in a transparent way to the programmer.

The DOS2 mapper support routines do provide slot IDs if you opt to allocate a segment in a nonprimary mapper, you just need to do the actual slot selection via the standard BIOS *SLT routines. One of the important goals of DOS2 mapper support routines is to be high-performance (so people won’t hesitate to use them), as well as not consume too much memory from the top of the TPA, those are good reasons why it doesn’t deal with slots.

But of course you can make your own little wrapper which compares the mapper slot ID to the currently selected slot ID (non-trivial to determine unfortunately), and first switches the slot if necessary.

DarkSchneider wrote:

The RAM mapper can be managed by your own simply writing a value in RAM, so I see no need to use DOS2 functions at all.

You mean writing to an I/O port... But there’s two problems about this (and the reason mapper support routines were introduced in DOS2):

1. If multiple programs are using memory, e.g. ram disks or TSR software or whichever, without mapper support routines a program has no way of knowing what memory is in use and they will start to overwrite each other.

2. The mapper bank selection registers can’t be read reliably, so to properly support temporary mapper switches which need to restore the original bank afterwards (again, consider ram disks, TSRs, etc.), a mirror needs to be maintained, which is why you should not directly use the I/O ports.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

27-08-2015, 12:42

Grauw wrote:
DarkSchneider wrote:

The RAM mapper can be managed by your own simply writing a value in RAM, so I see no need to use DOS2 functions at all.

You mean writing to an I/O port... But there’s two problems about this (and the reason mapper support routines were introduced in DOS2):

I mean writing a number on RAM memory mappers.
http://www.msx.org/wiki/RAM_and_Memory_Mappers
Tested and works. Simply write a 4 on F343H and you have the 5th 16KB block mapped on page 2.

I am talking about your software is running alone. If multiple are wanted, you need a MSX-DOS2 environment, and software for DOS2, in that case.

By Grauw

Ascended (10005)

Grauw's picture

27-08-2015, 14:04

Writing to that address does nothing except mess up the internal state of DOS. Those are RAM slot IDs mirrors of the memory selected in each page of the addressable space (= the default slot configuration when starting a DOS program). They’re not mapper bank selection registers nor mapper bank numbers. You shouldn’t change them, and writing to them has no effect. When you say "tested and works", your test must be broken...

Page 10/12
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12