Casio CZ/ VZ/ FZ - Pro Series

http://templarseries.atspace.com/cz.html
 
I mapped the CZ bytes going by Thong's map - as far as I can see the first few bytes use both nybbles - byte3,4,5 and thus the parameter is stretched across two nybbles - once those nybbles are collected as a byte it should be just a matter of masking the bits and dividing by an appropriate integer much as Charles suggested.
At least - this is what I think I did with the PSS programs - byte 15/16 are in a similar position. But then I am not totally sure the map is correct.
I cannot see any 16 bit structures from my map - but it is a rough draft to get the basic layout of the bytes for any given parameter.
Essentially the map indicates that the Sysx structure comprises common parameters first and then 2sets of 3 blocks for each DCO comprising the DCA,DCW and DCO envelope controls.


--- On Tue, 11/8/09, steve_the_composer <smw-mail@...> wrote:


From: steve_the_composer <smw-mail@...>
Subject: [CZsynth] Re: help cz101 bytes sysex breakdown
To: CZsynth@yahoogroups.com
Date: Tuesday, 11 August, 2009, 7:04 PM


  



Thanks for the clarification, Lee. This helps me to understand what you guys are trying to do.

I know what you mean about some CZ patch dump data needing to be handled on a bit-by-bit basis. However, unless I am missing something I don't see any where any parameters are split up. You have some 8-bit and 16-bit [not nybblized] structures where the different bits mean different things. 

See previous message with hex, binary, and decimal explanations of (1) nybblizing and (2) reassembling the nybbles.

Also, see the files section where I posted 2 sections of C-64 assembly code showing (1) and (2) with comments added today to correlate with http://launch. groups.yahoo. com/group/ CZsynth/message/ 4111.

Also, see comments below.

--- In CZsynth@yahoogroups .com, Lee Borrell <templarser@ ...> wrote:
>
> Regardless of the nybble arrangement of the CZ - once the data bytes are in place inside a PC/computer the problem is the whereabouts of the bits,which are sometimes placed across nybbles -

STEVE: For consistency, you might want to reassemble nyblized data first when receiving it.

> deriving the actual value of the parameter should be a matter of using Thong's table of values.

STEVE: Since Thong basically took Casio's Midi Guide book and added comments to try to explain what the graphics show in the original, I would really recommend the original. 
 
> Charlie and myself are trying to use GFA basic - but I am unfamiliar with this. 

STEVE: I have used basic, but I have no idea what GFA basic is.

> I have wrote programs to exploit the PSS series SYSx in Commodore basic - which worked admirably - Yamaha didn't make quite such a mess of the Sysx table and the parameters seem easier to derive.

STEVE: You should see Korg's EX-800/Poly- 800 packed patch data; it is all bit-wise sequential!! Does GFA Basic let you operate in hex or binary? Or is it all decimal? Did you ever work with Roland's midi data structures? It is complex, but at least they gave the address of individual parameters. I think that's what lot's of CZ/VZ users wish CAsio had done.

> I do not believe that we need formulae for time-wise versions of anything - only the actual decimal data from which to derive the parameters - to be edited - before sending them back to the CZ.

STEVE: This makes sense; I just couldn't figure out why Charlie was confused by the tables. I would think a look up simple array would do it. Get the two timing bytes as an offset from the start of the array based on the display value. 

> I already have a Commodore program which creates random data for the CZ - but this is not very effective.

> I think with the BYTE not over 15 - this is meaning the HALF bytes (nybbles) which of course never exceed 15 within the header and trailer bytes.

> Any given byte is therefore Nybble(1)=4 bits=15 + Nybble(2)=4 bits =15 - creating a byte of 8bits= 15+15*16 - getting them in the correct order is a must!

STEVE: YUP, if I understand what you mean here.
Reassembled Byte = Nybble(1) + Nybble(2) * 2^4

> Deriving the paramters is thence a matter of masking the bits as per Thongs table.

STEVE: YUP, just so long as (1) each 8-bit structure is split/nybblized or reassembled properly and (2) you realize that PVDLD is simply the display value and PVDLV is a set of 2 8-bit values. 

Sounds like an interesting project. Let me know if I can help.

--Steve

PS: In looking at my C-64 code, I do believe the nybbles are sent and received in lsb/msb order for each 8-bit structure. Thus for a 16-but structure you would the order would be MSBlsb MSBmsb LSBlsb LSBmsb. In other words, for a Delay Time represented on the screen by = 96 (dec), the nybblized PVDLV sequence would be 2 0 15 1 (dec).

2 + (0 *16) is the MSB 
15 + (1 * 16) is the LSB

In the table this appears as 60 02 1F (hex)

















      

[Non-text portions of this message have been removed]