The Caslink3 project has been released!

Guardian (3571)

12-05-2016, 02:17

Dear MSX fans,

Some of you probably know the Caslink project already. It's being developed since 1999 and now, when it's quite easy to buy a floppy/IDE controller or even a flash cartridge for your MSX, my project's value has diminished. However I am still trying to develop this project for those people who are nerdy enough to load software into their MSXs from the mobile phones or MP3 players. So here we go...

New features in Caslink Version 3:

- It is now possible to load 49kb ROM images into MSX. Such ROMs are divided into 3 parts and are loaded from address 0000h. Some of these ROMs only work with /r option, some - only with /e option
- The /r option has been introduced - it allows to select the option to reset a computer after loading a ROM image. If some game does not work with /e option, it may work with /r option
- The ROM loading routines have been improved to handle files starting from various tricky addresses
- File format recognition routines have been improved, a simple check for mapper presence in ROM files larger that 32kb has been added
- Now it's possible to encode up to 20 files into a single WAV/MP3 file - this was done for games with large amount of files
- The single BIN file and multi-file loaders have been significantly improved. Now action is taken to avoid corruption during moving of the loaded binary code to its destination
- The 24kb BIN files are now loaded correctly. The BIN loaders' code has been moved from 9000h to 8200h to save space and allow a 24kb file to be fully loaded into available RAM
- The small ROMs starting from 0000h and above 8000h can now survive the reset - the "AB" signature and the ROM's start address are placed at 4000h

The Caslink3 project's page with the links to the sources, additional files and encoded samples is:

http://www.podrezov.com/caslink3.htm

Enjoy! B-)

By dhau

Paragon (1570)

12-05-2016, 05:35

Thank you very much, Alexey, for releasing the source in particular!

By NYYRIKKI

Enlighted (6033)

12-05-2016, 19:27

Alexey wrote:

- The 24kb BIN files are now loaded correctly. The BIN loaders' code has been moved from 9000h to 8200h to save space and allow a 24kb file to be fully loaded into available RAM

If you need a more complex BIN-file loader than simple ' 1BLOAD"CAS:",R ' it sounds like you are using a better method of saving to cassette than the standard FSK delivered on MSX ROM. Can you share some details or the speed and encoding method you use?

to load BIN-files I would suggest moving the loader to below #8000... Yes, this will make it suitable for 64K RAM machines only, but it will improve compatibility other ways... At least as an option it would be nice.

By Wierzbowsky

Guardian (3571)

12-05-2016, 23:51

NYYRIKKI wrote:

Alexey wrote:

- The 24kb BIN files are now loaded correctly. The BIN loaders' code has been moved from 9000h to 8200h to save space and allow a 24kb file to be fully loaded into available RAM

All the 24kb BIN files that I encountered so far were parts of 131kb ROMs with the special loaders. For example Penguin Adventure and King's Valley 2. As I am using the standard BIOS methods, I can only place my data above 8000h. There's no point of moving the loader below 8000h because it's small enough to fit itself and the file into RAM. What I do is just copying the file's data minus first 7 bytes to 8000h (my "move" code works from F560h) and pass the control to the entry point. Worked well so far.

I am using the standard FSK method for 3600 baud encoding. I create a waveform pattern (2 actually - one for normal and one for inverted encoding) and then scale it according to the specified speed. Seems that most of MSXs can load correctly at 3600 baud. Tried 4800 as well, but did not succeed.

By Louthrax

Prophet (2436)

12-05-2016, 23:55

Has anybody tried to load >3600 bauds tapes on turbo / 7Mhz MSXs ? Maybe it could work (I've also never been able to transfer anything over 3692 bauds on any MSX machine).

By Wierzbowsky

Guardian (3571)

13-05-2016, 00:05

There was an OTLA project with upload speeds up to 12000 baud. But it used a custom loader as far as I can remember.

By Grauw

Ascended (10713)

13-05-2016, 00:29

Isn’t it a physical limit imposed by a low pass filter on the cassette input line?

By Louthrax

Prophet (2436)

13-05-2016, 00:34

I don't think so, it's often on/off (always works at 3692 bauds and nothing above). My guess is that it's linked to the speed at which the Z80 loops to read bytes (the standard MSX BIOS routines are checking for CTRL+STOP keys). Having simpler and optimized access when reading the cassette input bit might improve things.

Thanks Alexey for pointing the OTLA project, found their homepage, will have to try that (12000bauds, OMG !!).

By NYYRIKKI

Enlighted (6033)

13-05-2016, 01:50

Grauw wrote:

Isn’t it a physical limit imposed by a low pass filter on the cassette input line?

It isn't only about speeding up communication rate, it is also much about algorithm...

Ie. standard MSX uses very simple algorithm. If we encode it to bits This means that :

2400bps:  (Time = 373 T-states or 104 micro-sec / bit )
bit 1 =     0101 or wave _|¨|_|¨ = 4800Hz
Bit 0 =     0011 or wave ___|¨¨¨ = 2400Hz
1200bps:
Bit 1 = 00110011 or wave ___|¨¨¨|___|¨¨¨ = 2400Hz
bit 0 = 00001111 or wave _______|¨¨¨¨¨¨¨ = 1200Hz

... so bit 1 is represented by double frequency compared to bit 0.

If we think alternative method where we don't change the speed we output these bits and ie. encode 2 bits at a time and add number 2 to those 2bits, the result will be 3 bit number, with 3 frequencies:

bits 00 = 010
bits 01 = 011
bits 10 = 100
bits 11 = 101

If you look the patterns that this generates when these values are put randomly after each other, there can be 1 bit long pulse (4800Hz), 2 bit long pulse (2400Hz) or 3 bit long pulse (1600Hz)... We know that 1600Hz is ok, because 1200bps encoding uses 1200Hz (4bit long pulse to represent 0) as well.

So, this very simple method already reduces time by 25% and doubles the data transfer capacity without need to play any higher notes. To load only thing to do is to record 3 samples, subtract 2 and save 2 bits... very easy yet effective.

By Louthrax

Prophet (2436)

13-05-2016, 12:13

Grauw wrote:

Isn’t it a physical limit imposed by a low pass filter on the cassette input line?

Louthrax wrote:

I don't think so...

Well, I stand corrected on this, there is indeed a filter applied on real MSXs. I was investigating why openMSX was not able to load the GP.WAV file (when a real MSX can), and discovered that applying a simple 14000Hz low pass filter fixed the issue (12000Hz is too low and does not work, values above 16000Hz might generate loading errors).

I'll try to have an accurate estimation of this frequency by reading & dumping in memory the cassette port super-fast while playing increasing frequencies from PC sound card (until memory dump does not reflect those high-frequencies anymore).

By NYYRIKKI

Enlighted (6033)

13-05-2016, 17:22

Louthrax wrote:

Thanks Alexey for pointing the OTLA project, found their homepage, will have to try that (12000bauds, OMG !!).

Actually in openMSX I tried the 25200 bps without trouble, but I have no idea would that really work with any real MSX configuration.