Educational question about z80 and 68k

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Educational question about z80 and 68k

Post by Count SymphoniC » Thu Jul 16, 2015 10:24 pm

Let's say you have a music sequencer running on the genesis. It's using all sound channels available to it for playback being processed by the z80, with PCM sampling and let's say that the 68k is processing routines for GUI and animation, gamepad input, possibly even a MIDI device, and memory transfers. Would on the fly lossless data compression/decompression in RAM be feasible without disrupting the speed and accuracy of everything else??

I found a decent way to store notes, note off, and octave information in less than one byte. Even better is that I figured out a way to store FOUR times this much information still fitting it all in just under a byte. This is a dream come true for me, but is it too good to be true? I'm not at a stage where I could test as I lost all of my tracker source code, but I'm trying to plan to reduce RAM usage so that I can make it Deflemask compatible.

Can it be done?

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Jul 20, 2015 7:21 pm

I guess that real time decompression can be done as you will have very few data to unpack at each frame, at max i guess you can send 500 bytes to the YM2612 and that is already a lot. Of course i don't consider the PCM data.
Still i'm wondering if you are not too optimist with your compression schem..
(note / octave / note off) x4 in less than 1 byte sound really really low !
Last edited by Stef on Tue Jul 21, 2015 8:16 am, edited 1 time in total.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Tue Jul 21, 2015 5:37 am

Stef wrote:I guess that real decompression can be done as you will have very few data to unpack at each frame, at max i guess you can send 500 bytes to the YM2612 and that is already a lot. Of course i don't consider the PCM data.
Still i'm wondering if you are not too optimist with your compression schem..
(note / octave / note off) x4 in less than 1 byte sound really really low !
You're right Stef, my math was off as I was using figures in my head roughly based on memory. But I got to thinking about it some more. I believe I can stuff notes, octaves, and note off into two bytes of data... 697 times. But it will require a bit of cpu work. Last time I wrote this tracker I used an inefficient 2 bytes to store all of that information once.

The new scheme works like this ... it takes 0x5E to express notes, octave and note off.
0x00 would be D 0 all the way up to 0x5D being B 7 which are the note and octave limits used in deflemask. 0x5E itself being note off. Now we start over with 0x5F-0xBC being D 0 all the way to B 7 and note off for the second note, then 0xBD-0x11A for the third note... this pattern can repeat all the way until 0xFFEE. It fits into 2 bytes in decimal 697 times.

But this would be CPU INTENSIVE. I'd have to convert that information to usable information for the vdp display and both sound chips. I wonder if it's practical...

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Tue Jul 21, 2015 8:22 am

Count SymphoniC wrote: The new scheme works like this ... it takes 0x5E to express notes, octave and note off.
0x00 would be D 0 all the way up to 0x5D being B 7 which are the note and octave limits used in deflemask. 0x5E itself being note off. Now we start over with 0x5F-0xBC being D 0 all the way to B 7 and note off for the second note, then 0xBD-0x11A for the third note... this pattern can repeat all the way until 0xFFEE. It fits into 2 bytes in decimal 697 times.
You actually cannot do this... If your information take 0x5E to be expressed then it requires 7 bits of information. Each note information should be independent and so if you want to encode 2 notes you require 7+7 bits, so almost 2 bytes. You cannot consider about packing 2 notes informations inside a single 0x00-0xBC range ! Imagine you have the value 0x80, you have no way to know if 0x80 means 0x40+0x40 or 0x50+0x30.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Tue Jul 21, 2015 6:26 pm

Haha it would still only be able to express one and only one note then, but at 697 different locations. Wishful thinking got the best of me. Well. I suppose one note per byte is the best it will be, which is still better than the original 2 bytes. Thanks for setting me straight on that one, I don't really know what I was thinking :P

Post Reply