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

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

By AxelStone

Prophet (3020)

AxelStone's picture

27-08-2015, 14:03

This way of using bank switching is specially useful to store data in high zones of RAM. This is, you can compile your MSX-C program using the basic 64Kb, but all data and variables used can be stored in high 64Kb using bank switching. By this way you have available all 64kb only for logic, so you can make very complex games. However as I said, personally I'm still far of exceed 64kb, first I need to learn how to use them! LOL!

@hit9918 Good luck with your project, it sounds promising.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

27-08-2015, 15:26

Grauw wrote:

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...

Right, what I did was the OUT to port #FE is what I meant. You can do directly an the DOS2 is not needed for that. No need to read the ports if you manage your own program data.

By Grauw

Ascended (10005)

Grauw's picture

27-08-2015, 19:22

You could make such assumptions, and then when someone tries to run your program with a ramdisk, and the data will be corrupted.

Why do you not want to use the mapper support routines? It saves you the trouble of detecting the mapper sizes and slots, for one thing, and has better compatibility and less risk of issues like the example above.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

28-08-2015, 09:04

Grauw wrote:

You could make such assumptions, and then when someone tries to run your program with a ramdisk, and the data will be corrupted.

The most important is to work on a real machine, if some way of hack to load the program (like RAMDISK) fails then use the standard one. The only one that I couldn't pass is the MegaflashROM, if fails from it, I'd change it. Think that I am talking about running-alone programs, like old auto-boot games. No other software will be loaded in RAM.

Graw wrote:

Why do you not want to use the mapper support routines? It saves you the trouble of detecting the mapper sizes and slots, for one thing, and has better compatibility and less risk of issues like the example above.

The reason is because I see 2 cases:
1) Disk programs for 64KB or that don't need all the RAM: MSX-DOS2 uses 32KB so i.e. if you have 128KB maybe with 96KB you don't have enough. Having 256+KB or more I think is enough to use them, if you can't fit in 224KB then probably neither in 256KB.

2) ROM or programs that needs all the RAM for itself: maybe you need all the 128KB. Think about this programs like the 128KB games of others systems, like Amstrad CPC, which use the whole 128KB for themselves. In these cases total control about the code and data location is needed.

If the case is 1, there is no reason for avoid using them in fact.

By Grauw

Ascended (10005)

Grauw's picture

28-08-2015, 11:51

My personal preferred approach is to support DOS2 mapper routines by default (through a wrapper), and then add a compatibility layer to the wrapper which activates when DOS2 is not available. It is a bit of extra effort, but most of the effort actually lies in the DOS1 side of things. This is why VGMPlay currently only supports DOS2, I haven’t gotten around to writing the compatibility code yet.

Note MSX-DOS2 uses that 32K regardless of whether you use its mapper support routines or not... When you ignore it, you will overwrite MSX-DOS system code with unpredictable results. And often DOS2 is loaded by default, e.g. when you have a turboR, or a MegaFlashROM inserted... I don’t know, maybe it will work out, but it feels dangerous to me to ignore it Smile.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

28-08-2015, 12:54

Turbo-R has a minimal of 256KB so DOS2 would be used. About MegaflashROM, launching an auto-boot software is running DOS2?. If that is the case, then it would only work loading directly from physical disk, not an option. But I am not sure when you reset and load software from MegaflashROM there is a DOS2 behind. I'd have to ask.

If that's the case, then MSX with 128KB is something like a chimera, you have really 96KB because there is no way to use the 128KB really.

Also, I don't understand well how DOS2 would be involved.
http://faq.msxnet.org/dos2.html
If you don't have the cartridge (the usual), booting to DOS2 would take 96KB (64KB system + 32KB mappers), so you have even less than using DOS 64KB type for a 128KB computer.
So compiling the software for DOS2 for 128KB...?? When boot to DOS2 we have 32KB left! So when run the COM file it will crash. Is not there a way to run it without loading the system (64KB part)?
Ups, without the cartridge, it does not work? Then how there is software that uses DOS2 functions (like Nestor) without the cartridge?
When creating software for MSX2/2+ (no DOS2) for 128KB...how then?

By Grauw

Ascended (10005)

Grauw's picture

28-08-2015, 12:59

DarkSchneider wrote:

About MegaflashROM, launching an auto-boot software is running DOS2?

Yes, I think so, unless you press a key during boot.

DarkSchneider wrote:

If that's the case, then MSX with 128KB is something like a chimera, you have really 96KB because there is no way to use the 128KB really.

There is, when you don’t insert DOS2 Smile.

If you need 128K, the software can abort with a not-enough-memory error, and the user can then choose to remove the cartridge or hold the boot key. I think that’s better than just using the memory anyway and getting something unpredictable like random crashes or something like that. Also, being able to run in the DOS2 environment will make it easier to run the software from HD, which I think is a big benefit.

DarkSchneider wrote:

So compiling the software for DOS2 for 128KB...?? When boot to DOS2 we have 32KB left! So when run the COM file it will crash. Is not there a way to run it without loading the system (64KB part)?

DOS2 uses 32K for system purposes (for the msxdos2.sys code and storing data like file control blocks, buffers and mapper tables). When run from the DOS environment 64K is available to the program directly, with 32K more which can be allocated on a 128K system. When run from the Basic environment 32K is available to the program directly with 64K more on a 128K system.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

28-08-2015, 13:46

If you have the cartridge, but what about if not? like MSX2/2+ software targeting 128KB. Is there a way to "install" a lite version (that takes only 32KB) on a MSX2/2+ with no need of cartridge?.

Let's say, a MSX2 auto-boot disk game that want to use 128KB.

I see a terrible conflict between MSX-DOS2 and systems without it with more than 64KB (and MSX2+ has mappers as standard), DOS software oriented running under DOS2 environment.

By Grauw

Ascended (10005)

Grauw's picture

28-08-2015, 16:50

Yeah, that’s what I meant by "My personal preferred approach is to support DOS2 mapper routines by default (through a wrapper), and then add a compatibility layer to the wrapper which activates when DOS2 is not available."

Note that when a DOS2 cartridge is inserted, it is active even when not in the DOS command line environment. So use of the DOS2 mapper routines is not really "optional" when they are present, at least if you don’t want to risk crashes or other odd (possibly destructive) behaviours. If that means there’s not enough memory you should tell the user and he can decide whether to remove the DOS2 cartridge or plug in a memory mapper.

Most DOS1 software just sticks to the usual 64K address space and does not use a memory mapper so it’s safe to run, but yes there is risk (and you can’t really tell either). It’s the compatibility cost of new OS features, and the reason why many DOS2 cartridges offer boot keys to skip DOS2 and why the turboR does this confusing thing where it disables DOS2 based on the disk boot sector.

The best new software can do is to be well-behaved by using the DOS2 mapper support routines when available.

By DarkSchneider

Paladin (941)

DarkSchneider's picture

28-08-2015, 19:21

How DOS2 can be detected?

Thinking more about it, what we have is not a conflict, it is really an incompatibility. Like a 64-bit OS not running 16-bit software, or between some versions of OS for Mac.

Let's think about it. The DOS software using 64KB runs fine, no problem at all. But:
- DOS software using more than 64KB will not work on DOS2, it will fail when it wants to use mappers without DOS2 permission, unless you run MAP.COM that surely will unlock it (not desired behavior in a DOS2 environment).
- DOS2 software will not run on machines without DOS2. That can be the case of most MSX2/2+.

The "easy" solution is provide 2 executables, one for DOS and another one for DOS2. There is no much problem to include 2 executables in a 720KB disk I think.

The "hard" is like you say, detect when DOS2 is available and use them or not depending if available. But I have no idea how to do it at this moment Shocked!

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