4 ms·

I wrote my own implementation, now called Uxn38. I had done a few writing uxn programs, and figured out some tricks with programming with this. I think that t

I wrote my own implementation, now called Uxn38. I had done a few writing uxn programs, and figured out some tricks with programming with this. I think that there are a few problems with it, one of which is the delete/append ports of the file device, which I had proposed a change, to allow seeking and a few other things. (Deleting files in a uxn code is probably not that important anyways. Uxn32 allows deleting directories too, although since there is no way to create directories using uxn, deleting directories seems worthless.) I also made some enhancements to the assembler. Some of these do not match what other people had done, so due to this sometimes there are two ways of doing the same thing. It was before the symbol file output, so instead it has its own symbol file format (although it might be possible to use the official assembler to convert the symbol file). If necessary, I might need to add switches to control some options, e.g. different versions of the uxn assembly language (since sometimes changes will break some old programs, even if the target instruction set has not changed), symbol file format, etc. I have not implemented any optimizations in the assembler, since I think that the writer can make the optimization by themself (or, possibly, can have a high-level programming language capable of uxn, but I do not have such a thing). I dislike the proposed metadata formats. For one thing, I think that it is unnecessary for a device port to be allocated for this purpose. Also, specifying capabilities would be useful, I think; at least to me, it seems more useful than including icons.

conaclos 4y ago
Where is the link to the source code? :)
- entaloneralie 4y ago
  http://zzo38computer.org/fossil/uxn.ui/dir?ci=tip http://zzo38computer.org/fossil/uxn.ui/dir?ci=tip
entaloneralie 4y ago
It's true that using a vector port for this is overkill, how would you instead tell the emulator that metadata is available?
- zzo38computer 4y ago
  There are a few ways I can think: 1. Make a header similar to Game Boy. The first four bytes are jump past the header (which might also be used to define the length of the header, in case of being extended in future), and then there is some sort of logo or code to identify the presence of the header, and then the data of the header. 2. Put metadata in a separate file, to avoid using up memory in the program file. 3. Put all of the files together in a Hamster archive file. Lump names starting with a underscore can be used for the special use, e.g. "_default.rom" for the program code and "_metadata" for the metadata. In this case an extra step is required to run the program if the emulator does not support it, but I wrote a program in uxn which is capable of doing this, therefore it can be used with any implementation of uxn. So, any of these should be able to work with any emulator, even existing implementations which do not implement metadata.
  - entaloneralie 4y ago
    I'd like for the metadata to exist in memory tho, in almost every app, I read that metadata within the rom itself, I don't want to be fetching that external file each time I need to display the about box. What we could do is just not expect the #xxxx #f0 DEO2 bytes as magic number, so you can just ";meta POP2" at the start. That wouldn't "use" anything, I mean, in its current state, it doesn't really occupy a port, vectors can always be overwritten, even if some day the #f0 device does become something, we could immediately write the same vector with another address in the reset vector.
    - zzo38computer 4y ago
      > I'd like for the metadata to exist in memory tho, in almost every app, I read that metadata within the rom itself, I don't want to be fetching that external file each time I need to display the about box. Then, you could use my first idea, of the first four bytes skipping past the header which starts with a code to identify the header (such as ASCII text "UXN!META", or whatever else might be agreed on); this is similar to the way that the Game Boy header is working. > so you can just ";meta POP2" at the start Yes, that would also work, if it is agreed that this convention is used for that purpose.

conaclos 4y ago

Where is the link to the source code? :)

entaloneralie 4y ago
http://zzo38computer.org/fossil/uxn.ui/dir?ci=tip http://zzo38computer.org/fossil/uxn.ui/dir?ci=tip

entaloneralie 4y ago

It's true that using a vector port for this is overkill, how would you instead tell the emulator that metadata is available?

zzo38computer 4y ago
There are a few ways I can think: 1. Make a header similar to Game Boy. The first four bytes are jump past the header (which might also be used to define the length of the header, in case of being extended in future), and then there is some sort of logo or code to identify the presence of the header, and then the data of the header. 2. Put metadata in a separate file, to avoid using up memory in the program file. 3. Put all of the files together in a Hamster archive file. Lump names starting with a underscore can be used for the special use, e.g. "_default.rom" for the program code and "_metadata" for the metadata. In this case an extra step is required to run the program if the emulator does not support it, but I wrote a program in uxn which is capable of doing this, therefore it can be used with any implementation of uxn. So, any of these should be able to work with any emulator, even existing implementations which do not implement metadata.
- entaloneralie 4y ago
  I'd like for the metadata to exist in memory tho, in almost every app, I read that metadata within the rom itself, I don't want to be fetching that external file each time I need to display the about box. What we could do is just not expect the #xxxx #f0 DEO2 bytes as magic number, so you can just ";meta POP2" at the start. That wouldn't "use" anything, I mean, in its current state, it doesn't really occupy a port, vectors can always be overwritten, even if some day the #f0 device does become something, we could immediately write the same vector with another address in the reset vector.
  - zzo38computer 4y ago
    > I'd like for the metadata to exist in memory tho, in almost every app, I read that metadata within the rom itself, I don't want to be fetching that external file each time I need to display the about box. Then, you could use my first idea, of the first four bytes skipping past the header which starts with a code to identify the header (such as ASCII text "UXN!META", or whatever else might be agreed on); this is similar to the way that the Game Boy header is working. > so you can just ";meta POP2" at the start Yes, that would also work, if it is agreed that this convention is used for that purpose.