|
|
Post by minsoft on Jan 16, 2021 11:55:00 GMT -5
Is the END statement required at the end of code?
eg in the programming tutorial with Vide, the hello1.asm example has this at the end:
;***************************************************************************
; DATA SECTION
;***************************************************************************
hello_world_string:
DB "HELLO WORLD" ; only capital letters
DB $80 ; $80 is end of string
;***************************************************************************
END main
;***************************************************************************
However, if you use Vide to create a project, and generate the main loop, the code generated does not have the END statement:
;***************************************************************************
; DATA SECTION
;***************************************************************************
hello_world_string:
DB "HELLO WORLD" ; only capital letters
DB $80 ; $80 is end of string
;***************************************************************************
It does seem to make some difference to the .cnt file, but I don't really understand what it's doing. I've looked at some example projects and some seem to have it, and some not, so I'm not sure.
|
|
|
|
Post by gauze on Jan 16, 2021 19:44:27 GMT -5
end isn't required.
|
|
|
|
Post by minsoft on Jan 17, 2021 10:53:48 GMT -5
Cool, many thanks.
What is odd is that the game I'm working on doesn't work properly on flash carts, has random issues/crashes etc. My latest build crashes consistently after the game ends, when it should return ot the title screen. However, I added 'END main' to see if it made any difference, and it did, it seems to fix the issue.
I don't know what difference adding 'END main' has made, and I'm sure it's not a proper 'fix', but it has done something. The only difference in the .cnt file is the addition of this line:
LABEL $00CD *xfer
Any idea why this made a difference?
|
|
|
|
Post by Peer on Jan 17, 2021 11:25:33 GMT -5
The two generated binaries (with and without END) must differ in some way. Load each of them into VIDE and do a text dump of each disassembled asm. Then do a diff in a text editor to find the difference. Just a suggestion.
Cheers, Peer
|
|
|
|
Post by minsoft on Jan 17, 2021 12:25:39 GMT -5
The two generated binaries (with and without END) must differ in some way. Load each of them into VIDE and do a text dump of each disassembled asm. Then do a diff in a text editor to find the difference. Just a suggestion.
Cheers, Peer
Thanks for the tip, hadn't thought of doing that. They are exactly the same. So adding 'END' can't have fixed the issue, just a coincidence.
What's odd is that the 'bad' binary would consistently go wrong every time yesterday. Since posting earlier I tried it today...it went wrong the first time (but didn't crash), and has been fine ever since.
I keep having weird issues with VecFlash. If I program it in 'dev mode' without the menu, my game works 100%. If I program it normally with the menu (& patched binary) then I get random problems, as if the memory contents are being corrupted at some as the game is running. I can't think of an explanation for it, the game also works 100% when programmed onto an eprom.
|
|
|
|
Post by gtoal on Feb 10, 2021 15:49:30 GMT -5
I keep having weird issues with VecFlash. If I program it in 'dev mode' without the menu, my game works 100%. If I program it normally with the menu (& patched binary) then I get random problems, as if the memory contents are being corrupted at some as the game is running. I can't think of an explanation for it, the game also works 100% when programmed onto an eprom.
well, there's your answer. You must be writing to rom space which I presume with that cart is writable. Try modifying an emulator to catch writes to rom areas and report where they happened from... G |
|
|
|
Post by minsoft on Feb 16, 2021 8:10:17 GMT -5
well, there's your answer. You must be writing to rom space which I presume with that cart is writable. Try modifying an emulator to catch writes to rom areas and report where they happened from... G Yes that was it. At time of writing I had no idea it was possible to write into ROM space...being 'read only'. I since learned that it is possible on some flash devices, which seems wrong to me that this is possible but there you go!
I was able to use Vide 'allow ROM write' config setting, and the Debug Window to work out what was happening. I had a line of (I think copy/pasted) code which was modifying a value at the address in the X register...without the X register being set correctly first.
|
|
|
|
Post by Malban on Feb 16, 2021 18:42:09 GMT -5
Hehe...
if that "flash device" is a VecFever - I think you can enable/disable that behaviour with some setting/or header type :-).
|
|
|
|
Post by minsoft on Feb 17, 2021 5:07:55 GMT -5
Hehe... if that "flash device" is a VecFever - I think you can enable/disable that behaviour with some setting/or header type :-). I don't have a VecFever but it does happen with that device...as you say I think there is an option to disable it. It also applies to VecFlash (normal mode with menu, doesn't seem to be the case in dev mode without menu), and I'm told also the Matteos programmable cart. |
|
|
|
Post by D-Type on Feb 17, 2021 7:44:05 GMT -5
Older VecMulti you can write to the address space (at least bottom 32k, haven't tried upper 32k), but not newer ones, Richard H changed the hardware. This means you can't run Animaction on it now, or other programs that need extra RAM e.g. my programs :-(
|
|
|
|
Post by minsoft on Feb 18, 2021 5:32:37 GMT -5
Older VecMulti you can write to the address space (at least bottom 32k, haven't tried upper 32k), but not newer ones, Richard H changed the hardware. This means you can't run Animaction on it now, or other programs that need extra RAM e.g. my programs :-( I guess that explains why it is useful for it to be possible. I didn't realise you could have extra RAM. |
|
