SEQ format export

[Viza74]

I work with a bbs and they would like to receive petscii in seq format, so would be nice to add.

Actually I can't even find information on what is exactly seq, but seems to be a simple binary version list of screen codes?...

[nurpax]

Should be easy to add but would be nice to have format details. I was asked about SEQ earlier but I didn't at the time find a clear spec on what to exactly implement.

[gnacu]

Following up on Twitter conversation.

I would like a SEQ binary format, so that I can write an Application for C64 OS that provides the user interface that lets the user select the file to load in and view. My application will load the bytes one at a time, and put them into memory where they should be, and set the VIC's registers accordingly. As well as provide a way for the user to exit the viewing mode to carry on and load in the next file.

My proposed format is (first in prose) several magic bytes, so programs can recognize the data format, and its version number. Then the PETSCII control byte to select the character set. Followed immediately by 1000 screen codes, followed by 1000 color codes, followed by 1 byte for background color and finally 1 byte for border color. Technically then:

.text "PETIMG" ;Magic bytes to identify format .byte $01 ;Version number .byte $0e ;For Uppercase/Lowercase, or $8e for Uppercase/Graphics character set. .buf 1000 ; 1000 bytes of "SCREEN CODES" aka, $00 == "@", $01 == "A", etc. .buf 1000 ; 1000 bytes of color codes, range from $00 to $0F, aka, color memory format. .byte $01 ; Background Color byte, range from $00 to $0F, for the VIC background color register. .byte $01 ; Border Color byte, range from $00 to $0F, for the VIC border color register.

On a C64, or in a .D64 image, it should be in SEQ format, because it makes no sense for this format of data to have an additional 2-byte load header. It's sequential binary data, it's not a loadable program.

[nurpax]

Should check what output Marq's PETSCII editor outputs. I wonder if that'd be what @Viza74 originally asked for.

[nurpax]

petscii.krissz.hu SEQ export exports only screencodes, it seems.

[gnacu]

Oh neat, I'd never heard of petscii.krissz.hu before. It's pretty featureful! You're right though, the only SEQ output is just the screencodes. Weird.

I'm a bit surprised that no one seems to see the value of outputting just the binary data, without also wrapping it up in a self-displaying program. I guess on the C64 people are not used to the model of having a program that lets you load and render data files. Still, if it's easy enough for you to add, I think it would be very useful. I'll write a C64 program (and a C64 OS app) to read in and display the data in this format!

[nurpax]

I've been wondering about the same thing.. why there doesn't seem to be a standard format for this.

However I'm somewhat wary of adding a new made up format into Petmate. For non-c64 use, there's already Marq's PETSCII .c format, krissz PE format, my .petmate format, etc. These are easy to convert into any binary format that's suitable for consumption on the C64. Or if you want a binary format that comes out of Petmate or Marq's PETSCII, the .prg files produced by these editors contain only a few tens of bytes of extra stuff (the display code) but the template is fixed so the screen & color RAM always start from a fixed position in the file.. If you want, I can make you a python script that converts a .petmate file into a binary format that you detail above.

I thought that SEQ is a common format, but it seems like noone really knows what those files are and how PETSCII data should be converted into it. I'd like to know if SEQ can support PETSCII and color information.. if so, then just use that instead of a new format.

[gnacu]

The reason I've been thinking about it, is that I'm adding a screen capture feature to C64 OS. A global keyboard shortcut will trigger a routine that writes a file to disk of the current appearance of the text-based screen. Whatever format I write this screen capture in, I'll have a viewer that can load those screen captures back in so you can look at them. I was surprised to find that there doesn't seem to be a standard data file format.

"SEQ" is not a format. It's a sequence of bytes on disk, which are not executable. So, a text file is SEQ, but so is a .wav audio file, and so is a .jpg, when its on a Commodore file system. The PRG format is like setting executable bit in a modern file system. It tells the computer to interpret the first two bytes not as data to put into memory but as the address where the following data should go.

A few commodore specific data formats, like Koala use PRG (even though a koala file is not executable) and set the load address to the area of ram where the VIC-II wants the image data to be. I wrote a blog post about this a little while back. Anatomy of a Koala Viewer (http://www.c64os.com/post?p=47). But every other kind of data file is SEQ, or USR, which is identical to SEQ.

I know that it's easy to get a format similar to what I want by writing a script to strip away and manipulate the .prg output of Petmate. I can write a script like that no problem. But then, I'm the only one who has that script. And a standard C64-friendly PETSCII image "data" format does not come into existence. I think that in the absence of a standard format, we should invent that standard format, and then implore the programmers of those other PETSCII programs to support this format as an output.

[nurpax]

Right.

Should this PETIMG format support also a width/height of something else than 40x25? Bigger than 40x25 so that someone can maybe use it for scrolling a larger petscii image?

What about custom charsets? Should it also support dumping an embedded charset ROM in case someone wants to bake in his charset tweaks into this file?

What about multi color charmode? Should this be supported too?

Personally, I don't have much interest in advocating the C64 scene to adopt a new file format. I'm just happy when graphic artists make stuff in Petmate, and that I can use the content exported from Petmate in my assembly programs. But if a format like this gains traction, I don't mind adding support for it in Petmate.

[gnacu]

Okay.

Yeah, those are good questions and good points. Regarding alternative sizes, custom character sets etc, I see that as the reason for putting a version number in the header. Future features and future headers can be added by changing the version number so that programs that only support version 1 can report an unsupported format when they encounter a hypothetical future version.

I respect your decline. But for me it's a practical matter. I'm hashing out the screen capture format right now. My goal was to use an existing format. And to my surprise, there just isn't one. In the absence of one, I'll have to create one. I thought it would be useful to get a PETSCII drawing app or two on board with that, so from the get go there'd be at least 2 or maybe 3 sources that generate the format.

I can easily write a script that modifies Petmate's .prg output. The problem is that some other PETSCII drawing app might also output a .prg format, but it could be structured differently. Because the nature of it is that the executable code merely has to be able to run, and to be able to handle its own structure of data following itself. You could, for instance, change Petmate's .prg output at any time. Old exports will continue to run, new exports will also run, even though they'd be internally structured differently. So, I can certainly write a conversion script, but it's not ideal.

[Esshahn]

+1 on the traction. I'm very keen on learning about the C64 OS and when it will be released. If it establishes a user base then I think putting some extra effort into supporting it would be interesting. As for now I would consider it low prio and value other issues of higher importance.

[gnacu]

Yeah, but creating a standard PETSCII image file format is not for the purpose of supporting C64 OS.

It's more, the other way around. Embedding data into a custom executable means it cannot be reliably parsed out and used by any other platform. Petmate exports to PNG, for example. Why? Because that's a pure data format that can be read in and rendered by any modern OS. Outputting in .prg for display on a C64 (which is cool as an option), is roughly equivalent to outputting a Windows .exe with the data packed inside. And to view it, you run it on Windows and it displays a window with the image inside. That might be cool, but you would never then advocate that that Windows .exe file is a suitable format for using on Linux or macOS or any other computer or OS.

If the .petmate format is stable (and it's small and tight) C64 OS could write its screen captures to that format, and support reading that format too. But then, that's problematic because that's not the format of other PETSCII drawing apps. A file format that is literally just the data, plus a simple header, seems like such an obvious interchange format to me. It's like .wav is PCM audio data with a header.

So I'm not advocating this, because I want people to support my OS project, but because a simple, small, standard, interchange format is win-win. And if that already exists, point me in the direction! I'd much rather use that than make my own.

[Kroc]

PNG uses named "chunks", so that the file may contain some or all of the chunks in any order and compatibility is better as unknown chunks can be ignored.

A table of contents provides offsets to the chunks in the file. Each chunk begins with a 4-byte id and then the data. E.g. a "SCRN" chunk could provide screen codes, "BRDR" the border colour, etc. This allows for each data-chunk to be defined and added independently without changing the whole file format.

[Kroc]

I've started working on a specification here: https://gist.github.com/Kroc/32fff4fdc1f4e90fdf5df36480128aa3 dump yo' ---comments--- demands there.

[nurpax]

I'm closing this issue as the original SEQ format details were missing. It's not too hard to write a python script to convert even directly from .petmate to something else.