Forums

(quickly retyped, as i wrote it two days ago. I didn't even make the effort to actually rethink about it yet)

Stub can either be Z80 or 68000 code. Unless 68000 starts using at some funky location, I don't think it is possible to use a stub with both.
Also, both stubs will have to be developed, and probably maintened/updated, so surely it is not the job of the logger (emulator) to add it, but a separate tool.
Thus, saving those empty space is useless.

Also why not considering that the actual DYM data could be after the 'dym ' magic string - that has to be searched by a player ? Allowing for one or no stub.
That would easily allow to pad several DYM files to make a multi DYM, containing all songs for the same game, for the exemple. And that, very easily (a COPY /B would work).
Of course, a smart player would start searching for a next 'dym ' magic after the end of the previous dym, to avoid the 1/4294967296th of case where random data would produce the magic. Damn us if the stub data contains the magic.

Also I would suggest adding a field in the DYM to say weither there's a stub, and for which CPU/system it is. Useful for players and tools.

Quote

> (quickly retyped, as i wrote it two days ago. I didn't even make the effort to actually rethink about it yet)

Somewhat bizarrely, this is my third attempt at replying. I'll try and keep to the point this time...

Quote

> Thus, saving those empty space is useless.

Yes. Either the offsets could be redefined in 1.06 to be relative to the 'dym ' marker, or a stub could be responsible for adding its size to the offsets, either at runtime or when prepended. It should compress extremely well though, even RLE squashes it to 2 bytes...

Quote

> Also why not considering that the actual DYM data could be after the 'dym ' magic string - that has to be searched by a player ? Allowing for one or no stub.

Erm... you mean after the 0x40 byte header? The optional gap there was to allow for the rest of the stub, while keeping the header at offset 0x200. I suppose if we're having free-floating data, we don't need it... or the SoundStart field.

Quote

> That would easily allow to pad several DYM files to make a multi DYM, containing all songs for the same game, for the exemple. And that, very easily (a COPY /B would work).

It'd be more hassle to play... with separate files you get to see all the titles at once, there is no need to search through files for 'dym ' markers, etc...

Quote

> Also I would suggest adding a field in the DYM to say whether there's a stub, and for which CPU/system it is. Useful for players and tools.

I'm not sure how useful it is, since to find the DYM header in a file with a stub, and no fixed location for the header, we'd have to search past the stub anyway :) I'd be more inclined to disallow stubs in .dym files, which would save on filesizes to download, would stop old stubs hanging around attached to files, would stop problems when a stub is added to a file which has one already, etc... because, after all, a DYM file with a stub is no longer a DYM file, it is a ROM (sort of).

Maxim

Quote

> Yes. Either the offsets could be redefined in 1.06 to be relative to the 'dym ' marker,

I think that's a good idea. Basically all of my 32-bit offsets will be changed in 1.06 to be relative to the current file point (signed 32-bit integer). Even if we don't do multi-file yet, it's a good idea for a lot of other reasons methinks.

Quote

> > Also I would suggest adding a field in the DYM to say whether there's a stub, and for which CPU/system it is. Useful for players and tools.

Why would that's be useful for players and tools?

Quote

> I'm not sure how useful it is, since to find the DYM header in a file with a stub, and no fixed location for the header, we'd have to search past the stub anyway :) I'd be more inclined to disallow stubs in .dym files, which would save on filesizes to download

Why would you like to not include z80 stubs in DYM files?

Quote

>would stop old stubs hanging around attached to files, would stop problems when a stub is added to a file which has one already, etc... because, after all, a DYM file with a stub is no longer a DYM file, it is a ROM (sort of).

My general idea would be to have something which functions both as a music file for winamp (a single track), and a simple rom which just plays the file. The z80 player won't be very elaborate: it'll be a blank screen in fact. It might even be possible to fit it into the 0x200 before the header: what do you think?

Regarding making z80 and 68000 players, how about starting the stub with:
00000028 f0
That would make the 68000 start at address 0x28, but the z80 at address 0xf5 I think (jr z,+0xf0). If that doesn't work, there's probably some other funky hacks to make a z80 and 68000 stub coexist.

The real music players however (like the gym think that Flavio did) can have a load of funky features like track selection, and (or blank out) the simple stub code on the DYM file.

Author	Message
Bock Site Admin Joined: 08 Jul 2001 Posts: 8661 Location: Paris, France	DYM: Quick thoughts about Stub (retyped version) Posted: Mon Aug 13, 2001 9:01 pm
	(quickly retyped, as i wrote it two days ago. I didn't even make the effort to actually rethink about it yet) Stub can either be Z80 or 68000 code. Unless 68000 starts using at some funky location, I don't think it is possible to use a stub with both. Also, both stubs will have to be developed, and probably maintened/updated, so surely it is not the job of the logger (emulator) to add it, but a separate tool. Thus, saving those empty space is useless. Also why not considering that the actual DYM data could be after the 'dym ' magic string - that has to be searched by a player ? Allowing for one or no stub. That would easily allow to pad several DYM files to make a multi DYM, containing all songs for the same game, for the exemple. And that, very easily (a COPY /B would work). Of course, a smart player would start searching for a next 'dym ' magic after the end of the previous dym, to avoid the 1/4294967296th of case where random data would produce the magic. Damn us if the stub data contains the magic. Also I would suggest adding a field in the DYM to say weither there's a stub, and for which CPU/system it is. Useful for players and tools.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14750 Location: London	Posted: Mon Aug 13, 2001 11:01 pm
	Quote > (quickly retyped, as i wrote it two days ago. I didn't even make the effort to actually rethink about it yet) Somewhat bizarrely, this is my third attempt at replying. I'll try and keep to the point this time... Quote > Thus, saving those empty space is useless. Yes. Either the offsets could be redefined in 1.06 to be relative to the 'dym ' marker, or a stub could be responsible for adding its size to the offsets, either at runtime or when prepended. It should compress extremely well though, even RLE squashes it to 2 bytes... Quote > Also why not considering that the actual DYM data could be after the 'dym ' magic string - that has to be searched by a player ? Allowing for one or no stub. Erm... you mean after the 0x40 byte header? The optional gap there was to allow for the rest of the stub, while keeping the header at offset 0x200. I suppose if we're having free-floating data, we don't need it... or the SoundStart field. Quote > That would easily allow to pad several DYM files to make a multi DYM, containing all songs for the same game, for the exemple. And that, very easily (a COPY /B would work). It'd be more hassle to play... with separate files you get to see all the titles at once, there is no need to search through files for 'dym ' markers, etc... Quote > Also I would suggest adding a field in the DYM to say whether there's a stub, and for which CPU/system it is. Useful for players and tools. I'm not sure how useful it is, since to find the DYM header in a file with a stub, and no fixed location for the header, we'd have to search past the stub anyway :) I'd be more inclined to disallow stubs in .dym files, which would save on filesizes to download, would stop old stubs hanging around attached to files, would stop problems when a stub is added to a file which has one already, etc... because, after all, a DYM file with a stub is no longer a DYM file, it is a ROM (sort of). Maxim

Dave Guest	DYM Posted: Tue Aug 14, 2001 7:20 pm
Dave Guest	Quote > Yes. Either the offsets could be redefined in 1.06 to be relative to the 'dym ' marker, I think that's a good idea. Basically all of my 32-bit offsets will be changed in 1.06 to be relative to the current file point (signed 32-bit integer). Even if we don't do multi-file yet, it's a good idea for a lot of other reasons methinks. Quote > > Also I would suggest adding a field in the DYM to say whether there's a stub, and for which CPU/system it is. Useful for players and tools. Why would that's be useful for players and tools? Quote > I'm not sure how useful it is, since to find the DYM header in a file with a stub, and no fixed location for the header, we'd have to search past the stub anyway :) I'd be more inclined to disallow stubs in .dym files, which would save on filesizes to download Why would you like to not include z80 stubs in DYM files? Quote >would stop old stubs hanging around attached to files, would stop problems when a stub is added to a file which has one already, etc... because, after all, a DYM file with a stub is no longer a DYM file, it is a ROM (sort of). My general idea would be to have something which functions both as a music file for winamp (a single track), and a simple rom which just plays the file. The z80 player won't be very elaborate: it'll be a blank screen in fact. It might even be possible to fit it into the 0x200 before the header: what do you think? Regarding making z80 and 68000 players, how about starting the stub with: 00000028 f0 That would make the 68000 start at address 0x28, but the z80 at address 0xf5 I think (jr z,+0xf0). If that doesn't work, there's probably some other funky hacks to make a z80 and 68000 stub coexist. The real music players however (like the gym think that Flavio did) can have a load of funky features like track selection, and (or blank out) the simple stub code on the DYM file.

Forums

View topic - DYM: Quick thoughts about Stub (retyped version)