XML parser in Z80

m_dr_m · 19:17, 22 March 25

Would anyone have that in their drawers?
Arkos Tracker songs are in this bloated format. @Targhan, come on!

roudoudou · 20:04, 22 March 25

for simple XML, naive approach should be ok
new tag => new leaf
end of tag => go back to parent
each XML may be viewed as flat structure with the structure in the names

<body>
<pouet>
<instr>glop</instr>
</pouet>
</body>

will lead to

body>pouet>instr = glop

something like that

Targhan · 21:07, 22 March 25

Quote from: m_dr_m on 19:17, 22 March 25Arkos Tracker songs are in this bloated format. @Targhan, come on!

XML is a perfectly viable format on PC, which is the target of AT. It is not meant to be read on a CPC, and many people thanked me to use such format, because it's easy to read, parse, and transform (possibly via XSLT).
Do you blame ZIP because it's not the best suited compressor on CPC too?

abalore · 01:07, 23 March 25

I don't know how you think Arkos Tracker works, but the project file is not meant to be read on the target machine. You need to use the bespoke players and formats. If you want to edit songs in the CPC there are a number of other native trackers you can use, but AT it's definitely not your guy.

Prodatron · 14:52, 23 March 25

Quote from: m_dr_m on 19:17, 22 March 25Would anyone have that in their drawers?

I started an XML2DOX converter many years ago (for displaying websites in SymZilla), but I would have to dig this out again.
You probably don't want this for AKS files, but what is you usecase?
Otherwise you would need an Unzipper as well, I can recommend you a fast one

Targhan · 22:07, 23 March 25

Quote from: Prodatron on 14:52, 23 March 25but what is you usecase

Probably to load an AT song on Ayane. Bad news, AT1 is very bloated (a one-liner from C#, handy but terribly inefficient), and AT2 and AT3 have slightly different format (the latter not official yet, so you should wait for the official release). However, I honestly doubt people will load an AT song on a CPC software, but this is my opinion only.

Prodatron · 22:29, 23 March 25

What I always learned about the CPC is, that nothing is impossible haha

But yes, I love the AKS XML format a lot on PC side e.g. for merging multiple AKS songs into one including re-using instruments

https://github.com/Prodatron/symsys-sounddaemon/blob/main/convert/aks_merge.py
https://github.com/Prodatron/symbos-wiki/wiki/SoundD-%E2%80%90-creating-sound-files

Thanks so much for all this great stuff, the Sound Daemon (and much more) wouldn't be possible without it.

norecess464 · 23:52, 23 March 25

For the Amstrad CPC, I would recommend the IFF file format (Amiga). Yes, it's a binary format, but it's easy to parse and extendable, like XML.

However, if you really prefer a human-readable format, I would suggest JSON or YAML instead, as they both offer the same functionality as XML but in a more compact form.

m_dr_m · 01:09, 25 March 25

Glad to see my teasing worked! I know the advantages of XML, it's just ugly.

Last time I checked the CPC was turing-complete, there is nothing it cannot process.

Yes my goal is to import .AKS songs from the CPC.
Ideally with a callback based parser, something resembling to:

Code Select

xml_parser
In: HL = description table
    IX = input callback, a routine passed by the client, itself taking:
           ; BC = size (number of bytes to provide)
           ; DE = destination buffer (where to provide the bytes)

Like that, the feeding mechanism is input-agnostic, it can be Amsdos File, Symbos File, Ramdisk or zip uncrunched on the fly. It prevents to have to load the whole thing in memory in the first place.

Where the description would look like:

Code Select

root
; name of expected tag 
  db "song",0 
; callbacks when entering / closing the tag
  dw cb0_song, cb1_song
; list of subtags
  dw instruments 
  dw subsongs
; ...
;end of list
  dw 0

instruments
  db "instruments",0
  dw cb0_instruments,cb1_instruments
  dw instrument
;...
  dw 0

The closing callback should be invoked with:

Code Select

In: A = type of value
        ; 0 = no value
        ; 1 = 16 bits signed integer 
        ; ... To be defined
        ;16 = string
   HL = value or pointer to the value depending on the type.

The callbacks would return Carry in case of success, NC in case of error, which would stop the parsing.

The .aks doesn't use attributes. Youpi!
In the first instance, we can also assume the order of the tags in the XML match the order of the description.

It should be pretty fun to program, yet I'd rather use some existing code, especially if it's Prodatron's stellar Z80!

m_dr_m · 17:11, 26 March 25

Update of the description format to make it future proof!

Code Select

tag_description
; name of expected tag
 db "song",0
; callbacks when entering / closing the tag
 dw cb0_song, cb1_song
; list of attributes in the form
 ; db "attribute_name0",0
 ; db "attribute_name1",0
 ;...
; Unsupported for now, but put end of list marker for forward compatibility
 db 0 
; list of subtags
 dw instruments
 dw subsongs
; ...
;end of list
 dw 0

Also, xml_parser could be relying on an even simpler parser, useful in its own right to scan xml whose structure is not none.

Code Select

xml_parser_simple
; In:
 ; HL = callback when tag opened, invoked with:
          ; HL = pointer to tag name
          ; B = size of tag name (rationale: HL can point to the buffer, without having to copy the name into a null-terminated string)
          ; DE = pointer to tag info (ToBeDefined);
 ; DE = callback when tag closed, invoked with:
          ; A = type of value
              ; 0 = no value
              ; 1 = 16 bits signed integer 
              ; ... To be defined
              ;16 = string
          ; HL = value or pointer to the value depending on the type.
 ; IX = input callback, invoked with:
          ; BC = size (number of bytes to provide)
          ; DE = destination buffer (where to provide the bytes)

zhulien · 17:22, 07 April 25

I had 2 ways to do that fast in vb6 in the 90s. One was to parse the xml a character at a time and be as compliant as possible, this worked and was slow.

The faster way which wasn't fully compliant but compliant enough for certain simpler xml structures was...

- all tags were lowercase
-entire hml needed to be loaded in memory at once, in vb6 its not banked which could make it a bit more complicated if on cpc
-search for the closing tag ignoring nests
- no attribute usage or limited if you must

Of course it depends on the use of the xml too, like are you converting it to another format, are you preserving the structure in memory but want to keep parsing it.

If converting to xml to json or json into binary it is somewhat trivial if taking the faster route. Converting json to binary you can have a defined binary structure such as are all numbers 16bit or are all strings and arrays pointers (near or far) or in place.

News:

XML parser in Z80