Quote:

Would it be a standalone executable?. I doesn't know at all the RealBasic environment...

Yes, of course. It will be a standalone application that can be run independently on Windows, Mac OS X and Linux (All the needed libraries are already packed in the executable file)

Quote:

k7 as a phonetic joke only works in French! k 7 (ka-set)

Actually, that works in portuguese too
K7 = "ca" + "sete" = "cassete" (which is portuguese for tape heh)

As for a name suggestion, since we have DSK explorer, why not CAS explorer or Tape Explorer?

Hmm... although encoded BASIC program is just another type of binary I hope you could add BASIC into "Types".

... maybe also option to automatically add extensions (.BAS/.BIN/.TXT/<position>.RAW) to exported files would be nice...

Very nice idea!
I always thought, just a thought, more than a manager there might be a way to 'synchronize' the MSX and an external device (say, a PC or MAC) through the tape connector so that it behaves like some kind of "hard disk" for the MSX. This would mean the PC/MAC constantly monitoring its audio in and react to interpreted commands by outing some audio. (the motor on/off wire is nice but would require a less easy DIY wire, too complex for the general MSX user I guess).
DIR, COPY or whatever DOS-like commands will then be simulated, a quite useful and cheap "tape hardisk" for any MSX... With WAVer-like protocols it would be a usable transfer speed, not too sure about the 'disk access' time though.

But if nothing has been done so far in that direction (whatever the system as far as my googlings let me know), it certainly means there is something wrong in this theory and it's not possible at all... or useless. But your application is somehow quite close to this idea, except that yours is real and useful!

Sin

Quote:

Hmm... although encoded BASIC program is just another type of binary I hope you could add BASIC into "Types". ... maybe also option to automatically add extensions (.BAS/.BIN/.TXT/<position>.RAW) to exported files would be nice...

Hmm... I'm not really sure if I understand your question, but from what I undestand the name of each file on a tape can't be longer than six characters.

Quote:

As for a name suggestion, since we have DSK explorer, why not CAS explorer or Tape Explorer?

This is interesting... I'll think about this name

Quote:

As for a name suggestion, since we have DSK explorer, why not CAS explorer or Tape Explorer?

This is interesting... I'll think about that name

Ok. Exporting to WAV is finally working... it's still a bit slow but it seems that there aren't any major flaws in the code. Currently on my MacBook with a Core2Duo processor running at 1,8Ghz it takes about 20-30 seconds to convert a 15min tape. I'll see if I can optimize the code... but before that, I really need to clean the code and add some comments, because actually it's a mess.

I'd like to add the possibility of importing a .ROM file inside a tape. Does anybody of you knows how the .ROM format is made? Where I can find starting addresses, ending addresses and execution addresses?

Quote:

Quote: Hmm... although encoded BASIC program is just another type of binary I hope you could add BASIC into "Types". ... maybe also option to automatically add extensions (.BAS/.BIN/.TXT/<position>.RAW) to exported files would be nice... Hmm... I'm not really sure if I understand your question, but from what I undestand the name of each file on a tape can't be longer than six characters.

Yes, but I was talking about situation when you export files from tape. I mean copy files from tape to harddisk. If the program would automatically add extension to 6 character name while exporting you could easyly copy these files to MSX disk and see right away, how you should load the file from it.

Quote:

I'd like to add the possibility of importing a .ROM file inside a tape. Does anybody of you knows how the .ROM format is made? Where I can find starting addresses, ending addresses and execution addresses?

I don't think this is what you really want to do... .ROM files do not have start or end address. These files are dumps of ROM IC:s and the start and end address depends how it was originally wired to Z80 address bus. Today emulators use quite a well working guessing algorithms together with software database to get the ROM type and loading addresses correct. This is needed because there are many different memory mapper types that were used to make MSX game cartridges. The mappers worked as a kind of hardware copy protection as well.

How ever for small ROM files the situation is not that bad. 95% of the time if the ROM-size is 8KB, 16KB or 32KB the file should be loaded to address #4000. In case of 32KB ROM to be on safe side I would copy address range from #8000-#BFFF also to address #0. In case of 8KB I think it's good idea to copy the ROM to address 0,#2000,#6000,#8000 and #A000 as well. This is because usually the unused Z80 address lines are not connected to anywhere. If the ROM file is 48KB without mapper it should be loaded to address #0

Address #4000 should always contain "AB" and start address can be always read from #4002.

So if I had a 8Kb rom file called TEST.ROM I could create a BLOADable file this way ?

<SYNCHRONIZATION BLOCK ( 8 bytes ) > + < CHARACTER &hD0 REPEATED FOR 10 TIMES ( 10 Bytes) > + < FILE NAME ( 6 Bytes ) > + <SYNCHRONIZATION BLOCK ( 8 bytes ) > + < CHARACTER &hFE > + < STARTING ADDRESS ( 2 bytes ) > + < FILE LENGTH = 8192 ( 2 Bytes ) > + < EXECUTION ADDRESS ( 2 Bytes ) + < ALL THE CONTENT OF THE ROM FILE >

Where from what I can understand the starting, execution and length are expressed in hexadecimal

Example: Starting Address = &h4000 => 16384 => The first byte is Character 64 (Because 16384 / 256 = 64) and the second byte is 0 (because 16384 MOD 256 = 0)


Is it right?

So if I had a 8Kb rom file called TEST.ROM I could create a BLOADable file this way ?

<SYNCHRONIZATION BLOCK ( 8 bytes ) > + < CHARACTER &hD0 REPEATED FOR 10 TIMES ( 10 Bytes) > + < FILE NAME ( 6 Bytes ) > + <SYNCHRONIZATION BLOCK ( 8 bytes ) > + < CHARACTER &hFE > + < STARTING ADDRESS ( 2 bytes ) > + < FILE LENGTH = 8192 ( 2 Bytes ) > + < EXECUTION ADDRESS ( 2 Bytes ) + < ALL THE CONTENT OF THE ROM FILE >

Where from what I can understand the starting, execution and length are expressed in hexadecimal

Example: Starting Address = &h4000 => 16384 => The first byte is the ASCII Character 64 (Because 16384 / 256 = 64) and the second byte is the ASCII Character 0 (because 16384 MOD 256 = 0)


Is it right?

Quote:

So if I had a 8Kb rom file called TEST.ROM I could create a BLOADable file this way ?

Yes and no... If you do that you can BLOAD the file for example like this:

BLOAD"CAS:",&H5000
(If start address is #4000 this loads the data to area #9000-#AFFF)

... unfortunately you still can't execute it. In BASIC you can load data only abowe address #8000 because MSX-BIOS is located in area #0000-#3FFF and MSX-BASIC is located in area #4000-#7FFF

To make the program to execute you need to add loader. Here is a simple loader for 8KB ROM that works only if all of the RAM is on same slot. You should get the idea anyway:

	DI
	LD A,(#FFFF)
	CPL
	PUSH AF
	AND #F0
	LD B,A
	RLCA
	RLCA
	RLCA
	RLCA
	OR B
	LD (#FFFF),A	;Select sub-slot

	IN A,(#A8)
	PUSH AF
	AND #F0
	LD B,A
	RLCA
	RLCA
	RLCA
	RLCA
	OR B
	OUT (#A8),A	;Select main slot

	LD HL,#A000
	LD DE,0
	LD BC,#2000
	LDIR

	LD HL,0
	LD DE,#2000
	LD BC,#A000
	LDIR

	POP AF
	OUT (#A8),A	;Restore slot configuration
	POP AF
	LD (#FFFF),A

	RST #0		;Reboot the computer in order to start the ROM.

Then put this to cassette like this:

<SYNCHRONIZATION BLOCK ( 8 bytes ) > + < CHARACTER &hD0 REPEATED FOR 10 TIMES ( 10 Bytes) > + < FILE NAME ( 6 Bytes ) > + <SYNCHRONIZATION BLOCK ( 8 bytes ) > + < CHARACTER &hFE > + < STARTING ADDRESS = #A000 > + < FILE LENGTH = 8192 + loader lenght > + < EXECUTION ADDRESS = #C000> + < ALL THE CONTENT OF THE 8K ROM FILE > + <LOADER>

Quote:

Example: Starting Address = &h4000 => 16384 => The first byte is the ASCII Character 64 (Because 16384 / 256 = 64) and the second byte is the ASCII Character 0 (because 16384 MOD 256 = 0) Is it right?

No, you need to swap hi and lo-byte. So now you write &H4000 = &h40, &h00 = 64, 0 What you should write is 0,64

I really appreciate this growing project, well done cesco.

About ROMs BLOADing: as said previously, it's a bit tricky;
requires changing the file to add start/end/exec addresses
and some ROM-type-specific "loader" code.

I feel that general ROM managing would require big effort;
if you think it's a valuable feature, I'd suggest to limit to the
easier cases: 8K, 16K and eventually 32K (I think that
bloading a 32K ROM requires splitting the file in two sections,
am I right?).

Also, I know that a few 8/16K ROMs may start
at address 0x8000h, that's an easier case: you
just add load addresses without loader
code (example of such a ROM: the new MSXDev
entry "Night Driver" ).

My best regards and my encouragement,

Andrea

Cesco: could you check that keyboard thread on the openMSX forum, please? (Sorry for off topic.)

Quote:

Cesco: could you check that keyboard thread on the openMSX forum, please? (Sorry for off topic.)

Sorry Manuel, I completely forgot about that... yes I'm taking a look at the thread now...