HYX file format

Yet another dumb custom hexadecimal file format, designed for the YASEP and my SPI flasher

Similar projects worth following
Standards are awesome, there are so many to choose from and none will ever match your exact needs !

So I made mine, with simplicity in mind, and adapted to my needs: a lean, gentle, safe and fast SPI Flash algorithm.

This "project" serves mainly as a repository and documentation hub, where I can also receive feedback.

This file format was created for my custom, fast, safe, web-centric #SPI Flasher.

Data can be translated to/from JSON and raw, with mixed support for block addresses. Other formats must be translated with other software.

The file format is best described by the self-documenting file example.hyx:

; the above line is the "magic signature" for the HYX data format.
; it must be placed at the very beginning of the file or stream.
; HYX1 is the same as HYX0 but with repeat enabled (with the dot character)

; comments start with a ';' and span the remaining characters of the line.
; you can put digits there : 0123456789ABCDEFabcdef

; empty lines are ok

; :0123   ; address specifiers are supported for non-binary outputs.
; The address is in hexa too.

01 23 45 67 89 Ab cD Ef ; data are represented in bytes,
 ; they must come as pairs of hexadecimal digits.
 ; the case is not meaningful.
 ; they can be separated by other characters,
 ; or even glued together, but a space is recommended and safest.


ABCDEF  ; note : this is NOT a big endian representation

00..... ; 0 is repeated 5 times (plus the first one)

; 20140907 : An optional end-of-file marker is possible with HYX1:

After the end of file we can write anything here.

The parser is very easy to write.

The C version is provided as an #include in input_hyx.c. You must provide some callbacks for the input and output of bytes. Look at hyx2bin.c for an example of .hyx import.

A VHDL version is also available.

One cool side effect is that .hyx files (hey David Duchovny) can be concatenated, which might make perfectly valid results if you you're careful with the offsets and the '@' end-of-file marker.

TODO: support .gz compression... see

TODO: import & export in JS and VHDL

TODO: support the "*" RLE encoding ?

Data integrity is not part of the format. Data alterations are rare and if you need to ensure integrity, other powerful tools exist, even GZIP has built-in CRC. And there is now #PEAC Pisano with End-Around Carry algorithm  :-)


1. Reboot_2023
2. .
3 .
4. .
5. .


The complete files for C, VHDL and some JSON.

x-compressed-tar - 7.05 kB - 11/12/2021 at 07:13



VHDL filter (output only so far)

x-vhdl - 2.58 kB - 11/12/2021 at 06:17



test file for hyx_filters.vhdl

x-vhdl - 682.00 bytes - 11/12/2021 at 06:17



A self-documenting file format example.

hyx - 954.00 bytes - 11/06/2016 at 13:12



The expected raw binary file generated from example.hyx

octet-stream - 19.00 bytes - 11/06/2016 at 13:12


View all 11 files

  • Reboot_2023

    Yann Guidon / YGDES10/19/2023 at 18:02 0 comments

    As things heat up on the #YGREC8  front, support of a binary format is essential. I have revived the archive and completed the revamp of the C ode, I must still work on the VHDL import, the JS code port as well...

    There is now a git as well at to follow the latest developments.

    There will be several versions of the Y8's assembler so it is important to make them speak in the same voice.

View project log

Enjoy this project?



Yann Guidon / YGDES wrote 10/14/2023 at 21:40 point

Development resumes !

The #YGREC8 is getting a boost and needs good tools so this archive is revived.

  Are you sure? yes | no

llo wrote 10/15/2023 at 06:47 point

Yeah ! That's a good news !  

I still hate the color theme of this website. It sucks.

  Are you sure? yes | no


[this comment has been deleted]

Yann Guidon / YGDES wrote 11/06/2016 at 17:48 point

Yeah, I meant to include a link to it but I couldn't find it, thanks :-D

And no, it's not human-oriented. It was actually meant to prevent complex situations when I flash the data. For example, addresses must be in increasing order only, they are not allowed to decrease, or it would make the flashing algorithm too complex. There is no way to enforce this in the major file formats.

That said, no, I don't want to make something universal. I guess that JSON is more suited but it is still too powerful and the parser must fit in a tiny space... (I aim to rewrite it in YASEP ASM...) JSON is itself a subset, and I'd have to create a subset of the subset... And all those comas waste room :-D

Just drop the syntax, dump the hex, add some delimiters and go.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates