I'm working on a Tape manager... suggestions?

Page 3/5
1 | 2 | | 4 | 5

By cesco

Champion (453)

cesco's picture

19-01-2008, 12:08

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

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

By cesco

Champion (453)

cesco's picture

19-01-2008, 12:09

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?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

19-01-2008, 13:11

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.

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.

By cesco

Champion (453)

cesco's picture

19-01-2008, 19:57

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?

By cesco

Champion (453)

cesco's picture

19-01-2008, 19:57

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?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

19-01-2008, 22:02

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>


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

By andrear1979

Expert (97)

andrear1979's picture

20-01-2008, 18:47

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

Smile My best regards and my encouragement,

Andrea

By Manuel

Ascended (18876)

Manuel's picture

21-01-2008, 09:23

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

By cesco

Champion (453)

cesco's picture

21-01-2008, 10:28

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

By cesco

Champion (453)

cesco's picture

21-01-2008, 10:39

I have to thank you all for your encouragement and support, especially Vincent Van Dam for his very polished source codes that allowed me to learn many things about MSX data and NYYRIKKI that helped me a lot and he even provided a small loader for ROM cartridges. Rest assured that I'll add your names to the credit section.

Yesterday I had to stay awake until 3am before understanding what to do with NYYRIKKI source code and getting some proper results, but today I'm really happy to say that ROM conversion is working... only with 8Kb ROMs, but... hey... it's a start Wink

I think that I'll release my utility tonight or tomorrow... Today I'm going to check again the code because there are still some minor bugs, but nothing serious... yesterday I also had the opportunity to test the application under Linux, and it's working flawlessy (at least under Ubuntu 7.10)

Unfortunately, starting from the end of this week I'll have little time for making improvements to the code until February (I'm actually running a masks shop in Venice, and starting from next sunday the Carnival will starts here), but I'll try to do my best to fix any bug that may be discovered in reasonable time.

Page 3/5
1 | 2 | | 4 | 5