vgmrips

The forum about vgm files
It is currently 2018-11-14, 20:06:56

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
 Post subject:
PostPosted: 2018-10-24, 9:58:54 

Contributors Contributors
Staff Staff
Reverse engineers Reverse engineers
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 339
The zlib compression should do a good job at reducing the file size caused by repetitive wait / chip commands.

Dividing the sample rate (if the CPU clock is used) is already assumed, I think. Consider that the 68K and Z80 (for example) have fixed memory cycles and can't hammer memory (and thus sound chips) every cycle anyway.


Top
 Profile  
 
 Post subject:
PostPosted: 2018-10-24, 18:13:52 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 628
The reason why I mentioned inserting a marker is because you can then use that marker to optimize files. For example, some sound drivers are interrupt-based, so they only write to the chip when a timer interrupt occurs, so that would help to find loops and to close the sample gaps between chip writes.

With the current format, I guess one can insert a zero-sample wait 0x61 0x00 0x00 as a marker. Perhaps emulators can be modified to insert such a marker if the CPU receives an interrupt, such as the vsync interrupt in a ZX Spectrum? And then that would help find loops and optimize perhaps.

_________________
Support me on patreon!.
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.


Top
 Profile  
 
 Post subject:
PostPosted: 2018-10-24, 21:03:15 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 125
ctr wrote:
The zlib compression should do a good job at reducing the file size caused by repetitive wait / chip commands.

Mmyeah, as usual I’m thinking about my MSX player… ;) Currently I decompress the entire file in memory so the unzipped size still matters to me. And also more bytes to process means less performance, a second 2-byte command would simply be caught by the jump table at no extra cost, while an extra port byte will require an extra buffer read, compare and branch to process. It’s not the end of the world but it’s still something that I think about.

(As for decompressing the entire file to memory, for a long time I have on my wishlist to decompress on the fly to a small buffer (and snapshot the decompressor at the loop point), but as you can imagine this is not trivial to implement.)

ctr wrote:
Dividing the sample rate (if the CPU clock is used) is already assumed, I think. Consider that the 68K and Z80 (for example) have fixed memory cycles and can't hammer memory (and thus sound chips) every cycle anyway.

What do you mean by assumed?

The Z80 has a variable number of cycles per instruction, indeed never less than 4 cycles, but usually not a multiple of 4, so it’s not quantisable.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group