dredds 2019-05-05 20:40 (Edited)
At the moment, when I save to a ROM entry in the Character Editor or Background Editor (and maybe sound editor, I’ve not checked), all ROM entries get reformatted.
This is really inconvenient for ROM entries that I’m editing by hand, because I format them to help me understand and edit their structure, not as a block of 16 byte lines.
Could the file save routine only format the ROM entry being saved?
Also, could the BASIC interpreter allow comments within ROM entries?
was8bit 2019-05-06 07:36
My thinking is that ROM represent FILES, not code.. they are simply put at the bottom as Lowres uses one text file to store everything...
As such, ROM “can” technically be manually edited and copied etc. but are designed to be edited via TOOLS..
Lowres NX is attempting to simulate “old school” gaming hardware...
TIMO can give the best answer to your questions... this is his project :)
was8bit 2019-05-06 07:39
And, actually the ROM for characters is simple, each line is a character...
You might look into the actual code for Character Designer and Background Designer, as they will show you HOW the ROM data is being read, edited, and saved :)
dredds 2019-05-06 15:51 (Edited)
I think they are more like data declarations in assembly language. The numeric values are human readable. In assembler you can add comments, lay out the declarations to help you manage the data etc.
It’s a lot of work to write an editor tool for every custom data format my apps need. The format isn’t something generic like characters or sounds. It’s map data for a game or a bytecode interpreted by my app to script enemy behaviours. So I want to just edit the bytes directly.
was8bit 2019-05-06 16:12 (Edited)
I have a tool which lets you edit, store and retrieve bulk data using a ROM FILE
If it would be of any use to you....
was8bit 2019-05-06 16:16
Also, you can use DATA and READ commands to load up arrays
was8bit 2019-05-06 16:20
Or you can create digital blocks of data like I did with Atari Running Man
dredds 2019-05-06 16:25 (Edited)
Saving and loading data is not the hard part. The drag is writing each GUI editor tool. Which is why I want to avoid that for data formats that are app specific
The limitation of DATA and READ is that it doesn’t allow random access to the data. (In the thread on that subject, the recommendation was to use ROM instead of DATA statements)
was8bit 2019-05-06 17:37
That’s what my Message File Pro tool is for...
It holds something over 1000 entry lines of text 16 digits long... it lets you edit ANY entry, and my demo shows you how you can read ANY entry...
What you get is a text string 16 characters long... you can use the text characters as BASE 64 which means each text character can represent a number from 0 to 63, or you can format the data as 4 digits each up to 4 numbers big, so entry would be “0101010201030104” would yield numbers 101-104...
.... but, actually, you CAN read any small random portion of a ROM... I just leaned how to do that with my “Use multiple font sets”
Where i only retrieve what portion of the ROM file i want, and put it directly into character memory...
You could use trick, just reserve a block of character memory, say page 3, for your data retrieval, then read your character data on page 3 for use in your game... if you want I can later on make a demo of that specific idea :)
was8bit 2019-05-06 17:40 (Edited)
Also, see this
Where I use multiple ROM files as a test in controlling and combining 2 different speeds of 2 different animations :)
One is the EDGE animation, and the other is the AXIS animation.... and either speed of either animation can be adjusted with code, AND I’m only using one BG layer and no sprites...
Timo 2019-05-06 17:43
The code and the ROM parts of a program are handled completely separated. At first the parser reads and tokenizes all BASIC lines. When it reaches the first ROM part it switches to the ROM parser, so you cannot mix code and ROM data. Also the text format of the ROM is lost when editing as virtual disk. It's converted to binary, edited and in the end encoded as text again. Changing this would be quite complicated.
Maybe for data you want to edit by hand the classic DATA command is better. You can read it to arrays (or even working RAM) to have random access.
dredds 2019-05-06 18:50
@was8bit I have no difficulty reading data from ROM
files. My issue is the effort of writing programs to edit all the custom data formats my apps use.
was8bit 2019-05-07 04:49
Ok, so one data format you mentioned was map data... why not use the background designer to create the map data... so... say one is a terrain map, another can be political map (who controls what) another can be a resource map (what the land can yield)
TIMO created BASIC commands that allow you to randomly access, read, and write to background ROM, so this would be a very convent way to use the existing Background Designer to create your different map data layers and use them at game time.