TheLivingBlooper 2021-06-16 02:39 (Edited)
Hi! I can't seem to comprehend why
MCELL isn't working for me. I've been trying to set cells in a background source map using
MCELL, but LowRes NX is always giving me an "Illegal Memory Access" error. The manual said this happens when the background source isn't in working RAM, but neither of the below ways I know how to get it there worked for me. To copy background ROM data to working RAM and set cell 0,0 to character 1 in the source map, I've tried:
BG SOURCE ROM(3) MCELL 0,0,1
and the less conventional
COPY ROM(3),SIZE(3) TO $A000 MCELL 0,0,1
Neither of them worked. Does anyone know how to copy this data properly or why this is happening?
was8bit 2021-06-16 02:52
Works like the CELL command, but sets a cell in the source map (BG SOURCE) instead of the current background. The source must be in working RAM, otherwise you will get an "Illegal Memory Access" error.
was8bit 2021-06-16 03:02 (Edited)
MCELL is a tricky thing... it takes time to get used to it...
MCELL was created to fix a problem... now lets say your background is the exact size of the screen, then any changes made to the screen stays... BUT if your background is BIGGER then the screen, then you have to use BG COPY to see different parts of the screen, and any changes you make to the screen gets lost...
NOW, i must add here that NO program is allowed to edit its own ROM files... only a secondary program set up as a tool is allowed to do that...
SO, before you can use MCELL, you have to do this one important step... after your COPY ROM(3),SIZE(3) TO$A000
You then have to add
BG SOURCE $A000
... this sets up a VIRTUAL full sized background into editable memory...
The additional tricky part is that as you change individual parts of the visual background, you must also change the same changes to the virtual background..
THEN as you use BG COPY command, it no longer is using the ROM memory, is using $A000 memory
was8bit 2021-06-16 03:04
Study this for a great example....
TheLivingBlooper 2021-06-16 04:20
Ooooooh. Thank you! I don't know why I didn't think of that :0
TheLivingBlooper 2021-06-16 04:22
I would want BG COPY and MCELL to refer to the same data anyways, so I guess that works out
was8bit 2021-06-16 10:34
:) no worries, it is always abit confusing at first....
Now, it "IS" kinda possible to make a program that can edit its own ROM files... however it is abit of a mind twister, as it requires using it both as a program AND a tool.... but if u r curious you can check it out...
TheLivingBlooper 2021-06-16 12:29 (Edited)
That's awesome! I might want to do a project like that
It'd be cool if LowRes had an if __name__ == "__main__" kind of thing so you could give the editor version different functionality
Do you know if there's a way you could do that?
(by that I mean detect wether the program is being used as a tool or not)
was8bit 2021-06-16 16:17
Yes, i built that into my program..... you have to use a bit of cleverness to do that though as it isn't built in to know...
A tool is supposed to be called via the menu from the program that you want the tool to edit... so if you are making a game, you use the menu to run the GFX editor, and the GFX editor knows to edit your game roms..
However (if you have tried this before you, you will know) it you try to simply run GFX editor like it was a game, you will see a message "using DISK.NX as a virtual disk" this is because GFX is trying to use tool only commands, and so it creates a file to edit since you didnt open it via an existing program...
Now, the created DISK progam will be blank.... so check out my code here that detects whether it is being used as a tool or ran as a program... see if you can figure it out ;)
IF F$="ARTOFNOISE" THEN
PRINT "ART OF NOISE"
PRINT "IS PROGRAMED"
PRINT "ART OF NOISE"
was8bit 2021-06-16 16:19
Also, carefully read thru the instructions i posted with it... remembering the code i just posted..... ;)
was8bit 2021-06-16 16:22 (Edited)
I created this approach for the possibility of having a map file that the game could edit... however so few people ever bothered with my test game, which tells me no one cared for the complicated steps needed to work it...
TheLivingBlooper 2021-06-16 18:01
That's a cool concept
People probably just didn't understand how it worked, if I had to guess.
I think I understand the excerpt you wrote, though. It checks to see if file 15 is named "ARTOFNOISE" and uses that information to either let the user play (IPLAY=1) or program (IPROG=1) it, with some fancy PRINT commands to let the user know what's going on.
So ig you could go:
IF NAME$="EDITME" THEN
To only use the editor if file 0 is named "EDITME"
was8bit 2021-06-17 05:24 (Edited)
The only issue with using ROM file#0 is that NX secretly uses it to secretly store and secretly uploads a default font set to page 4 of the character sets... you "CAN" use rom(0) but it will prevent the default fonts from loading... but if you dont use any text or you load your own font set, this wont be an issue... otherwise, you will be wondering why PRINT and TEXT dont work... it would not be an issue that they dont work, rather your font set is empty or blank ;)
was8bit 2021-06-17 05:26 (Edited)
But you have the right idea, unless you actually use DISK program, it should be blank, and ALL of its ROM files should be nameless.... so finding any file with a name should let you know the code is running as a program and not as a tool ;)
was8bit 2021-06-17 05:38
This is a safety feature... executable code and databases should NOT be editable by code.... it is quick way to crash your program if you are not carefull... early APPLE2e used the same memory for code or variables or other stuff... so it was actually common place for a novice programming at machine code level to crash their program when it started storing data over top of code... remember that data wasnt kept in a named variable, rather you stored your data ANYWHERE you wanted in the memory... so if made an error of WHERE you stored your data, you created 3 issues... 1) it aint where u think it is, so if the code READS at the location it is supposed to be, it aint there... 2) if the data is stored overtop another data, well you just corrupted that data...and 3) if your data was accidentally stored over top code... who KNOWS what will happen... if the computer reads it as junk, your program crashes...if it read the data as an instruction, it executes that instruction... and execution code isnt written in even blocks, so you MAY get lucky that your data doesnt upset the flow, but if it does the computer will go haywire before it crashes in a giant ball of flames! ;)
was8bit 2021-06-17 05:39
For NX, the problems my not be as severe, but it does help keep your code and databases from being accidentally messed up or even wiped out :)
TheLivingBlooper 2021-06-17 17:54
For sure. I just like to pretend that a new program is a completely blank slate when I start a project, like LowRes doesn't copy anything to anywhere on program startup (of course, there's the built-in interpreter, but that's outside the virtual console). In fact, it's a big reason why I like LowRes; it feels minimalistic and clean, in some weird way. That tendency has definitely gotten me into trouble in the past, though.
TheLivingBlooper 2021-06-17 17:59 (Edited)
Also, using the same memory for code/functions and variables sounds like a nightmare, but I guess could be kind of interesting. Imagine storing data for a function in the heap, for example, and completely altering its functionality with a variable pointing to an address the function occupies. It'd be some really complicated, low-level stuff, but could be really cool if you pulled it off. Then again, you COULD just act like a normal human and use arguments/parameters instead :)
TheLivingBlooper 2021-06-17 18:03
It couldn't be that much more complex than some of the 3D renderers people are making here. I've never seen so many peaks and pokes...
was8bit 2021-06-18 04:17
I happen to enjoy peeks and pokes... reminds me of machine language days :)