tokumaru: you don't need to use those custom tape I/O routines, really. You can put up a loading screen without them just fine. This just happens like this (most common scenario):
- the user types RUN"CAS:"
- an ASCII file is loaded from tape, which contains a small loader in basic
- (these previous 2 steps can also be changed by: BLOAD"CAS:",R, then an assembly loader will be loaded and executed. This is a bit better, because ASCII basic files load very slowly)
- the loader loads a loading screen and puts it on the screen for display
- the loader loads a program part and puts it in the proper place in memory, often this is done by executing the part, which puts itself on the right location in RAM and then returns to basic
- iterate the previous step until the whole program is loaded. The last part jumps to the right address to start te program, after it moved itself to the proper location in RAM, if necessary.

This loading and stuff can all work via the normal BASIC/BIOS routines.

More advanced loaders use indeed custom routines and after loading each byte from tape change the background colour of the screen so that the user has some visual feedback of the loading process. Personally, I like the laoder of Jet Set Willy II better: it shows a progress bar

All in all: this is all a slow and cumbersome process. Using disks on MSX is really quite easy and as i already said it has a lot of advantages.

I don't know aobut Brazil, but in Europe you can buy an MSX2 with diskdrive for like 10 euros.

Quote:

Try to download the file at

I got it! Thanks!

Manuel, thanks for the overview of the process, that's exactly what I needed to get on the right track.

I'd like to stick with assembly and forget that BASIC even exists.

Quote:

I like the laoder of Jet Set Willy II better: it shows a progress bar

Progress bars can be cool AND useful. I suppose it is not possible to make one while still using the standard BIOS routines then? At least not with the same precision?

Quote:

I don't know aobut Brazil, but in Europe you can buy an MSX2 with diskdrive for like 10 euros.

I think MSX's are quite rare to find here. There are always a few at www.mercadolivre.com (auction site) but they're always MSX1, I've never seen an MSX2. And even if there was any, buying old things like the MSX is a complicated process. You have to see the thing personally before buying it, to make sure it's worth the money, since in many cases these machines will not work properly, and not all sellers are honest.

I wish I could buy an MSX2 with a disk drive for 10 euros. But if I ever find such an item around here it will surelly be treated as "rarity", and it will be overpriced.

Well, back to development: How much of the BIOS routines will a serious assembly program actually be using? Graphically, I mean... I'm guessing I'll probably be using the standard functions to change modes and such, but the actual drawing will be all custom, is that right?

It much depends from your experience as MSX programmer and the specific needs of your program. Initially is better to stick with the BIOS graphic routines only to be sure that your program will run over ALL the MSX models (that's the main obstacle a noob could front in their first programs). Try first with some simple demos/games and once you become a more advanced programmer, you'll be free to use custom routines, usually faster, and tight your code a bit.
Talking about differences between models and being Brazilian I believe you'll find very tricky the setup of the screen refresh. Take a look at this recent thread! :

The 50/60Hz controversy

You'll find a lot of useful documents in the Pitpan's homepage :

www.robsy.net/

...and tons of interesting info in the MSX Assembly Page :

map.tni.nl/

I can't help you wtih details of loading routines, I don't know those details. I'm sure that the author of WAVer knows about it, though Or others.

Using directly the BIOS routines you can load from tape easily. There are simple BIOS routines:

Entry point...00E1H
Address... 1A63H
Name...... TAPION
Entry..... None
Exit...... Flag C if CTRL-STOP termination
Modifies.. AF, BC, DE, HL, DI
Function: START the cassette, adjust loading speed and load whole header (no data)

Entry point... 00E4H
Address... 1ABCH
Name...... TAPIN
Entry..... None
Exit...... A=Byte read, Flag C if CTRL-STOP or I/O error
Modifies.. AF, BC, DE, L
Function: read a single byte from tape

Entry point: 00E7H
Address... 19E9H
Name...... TAPIOF
Entry..... None
Exit...... None
Modifies.. EI
Function: STOP cassette loading

Very easy. There is also another set to WRITE to tape: TAPOON, TAPOUT, TAPOOF.

Of course, direct handling of hardware can improve speed, but it could prove both difficult and uncompatible. At the moment, I have reached sustained and reliable loading speeds of about 8,500 bauds.

If you have any further question, do not hesitate to ask!

I nearly forgot: the information was excerpted from the digital (TXT) edition of THE MSX RED BOOK, written by Avalon Software and published by KUMA. A useful book indeed!

Thanks a lot pitpan.

There is something I still don't understand. After you type "BLOAD "CAS:", R" what exactly happens? I mean, at what point control is transfered to my program? Is that information by any chance contained in the header (size of the first block, destination address, etc)?

I mean, something has to be copied from the tape before my program starts to execute. Does that make sense?

Anyway, after my program is in control, it is up to me to load byte by byte from the cassette, is that it? How would I make sure to stay synchronized to the incomming data? If I take too long between byte reads would I miss information?

One more thing: is the tool that comes with asMSX the best way to produce MSX compliant WAV's?

Thanks for all the help!

if you use BLOAD"CAS:",R, the MSX-BASIC loads the entire ML program for you and after that runs it. So, you'll use this for your loader. After that, you get control and you can load the rest by using these BIOS calls.

That makes a lot of sense! Cool!

"Bloadable" files has a small header: FEh (indentifier byte, always FEh), then 2 bytes for start address, 2 for end address and 2 for execution address.

that's for disk only. for cassette the bin header is split up into 2 parts... the first part is the signature stream in the file header which also contains the file name. the second part is the other 6 bytes which are the first bytes of the actual data stream... and the signature string is 10 times 1 byte, which isn't FEh by the way.

MSXwav makes such conversion automatically.