LOAD to use non-BASIC parts doesn't seem to work
fade0ff opened this issue · 13 comments
When trying to compile a C64 basic program that loads a binary part using something like
10 IFA>0THENGOTO190
180 A=1:LOADNA$,8,1
I get all kind of problems. My understanding is that using LOAD in a BASIC program for binary parts (located above basic memory) will reset the executing program to its first line (thus the skip mechanism using variable A). In the actual BASIC program this works fine, but in the compiled program it somehow doesn't.
E.g. I get IO errors even though the program was loaded and screen corruption.
Admittedly, this is a borderline case and didn't really work with AustroComp either, but is there any chance to get this running without some dedicated load routine?
I see. The IO error was caused by an oversight on my side when playing around with the IO messages in general.
The LOAD behaviour was to load the requested file and just continue. I've changed this, so that it will now do the same thing as BASIC (reset the stack and start at line 0). With this change, this test case
10 IFA>0THENGOTO190
20 PRINT A
180 A=1:PRINT"LOAD",A:LOAD"RTS.PRG",8,1:PRINT"AFTER",A
190 PRINT "DONE!",A:SYS24576
worked fine. Please give it a try to see if that helps somehow.
I fail to see a reason for screen corruption though!? Maybe this was just caused by the IO-error message?
No, sorry, still doesn't really work.
It's for something I hacked together in the 80s and just wanted to get running. Actually, I managed to do this in the meantime with Austrocomp somehow by using RAM in the 0xc000 area directly instead of variables. There seems to be something else going on with MoSpeed though, but it's difficult to investigate since the program uses multicolor character mode and moves the screen RAM to 0xCC00.
If you're still interested to have a look, I posted the stuff here (sorry, German, but it's mainly about the disk image):
https://www.forum64.de/index.php?thread/50196-interesse-unvollendete-fr%C3%BChwerke-remastered-sammeln/&postID=1465627#post1465627
Again, this specific project is not really important but I somehow like the idea to use a cross compiler instead of messing around with Austrocomp.
I'll have a look at it...
It gave it a try and it actually worked fine for me, except that MOSpeed didn't support the "arrow left" control code (only "left arrow"). I've added that and now it works fine. I'm not sure if that's your issue as well, because the "arrow left" was introduced by CBM prg studio after importing the PRG file from the disk image and I don't know if your source looks the same (I've included the one that I used in the attached zip). If it still doesn't work for you, can you provide me with the actual source code that you are using?
Thanks for looking into this and yes, your version works fine. But on my side there is no change after updating the JAR. One thing that I noticed is that my source code looks different than yours. Mine is uppercase and with special characters, yours is lowercase with replacement for the CBM characters.
I zipped the source and the compiler output:
PiratesViewer.zip
Upper- or lowercase doesn't matter. MOSpeed will work with both. But the special characters don't work this way. I assume you've created the txt-version by exporting it from something like DirMaster? In that case, these characters are all mangled and look like this:
230 PRINT""
The compiler will take those as they are, but the outcome won't be what one expects (obviously). The proper way to do this is to import the prg file into something like CBM prg studio, which will handle these special characters by replacing them with the placeholders that you can find in my source code.
Another option is actually to compile the PRg file directly. MOSpeed supports tokenized files since a few checkins, but there's an issue remaining with spaces, which affects the outcome in this particular case. I'll try to fix that as well.
Ok, the spaces problem is now fixed as well. That means, that you can compile the BASIC prg-file directly (it detects this by simply looking at the extension, which means that such a file has to end on .prg). When doing so with -generatesrc=true, it will now write the untokenized txt version to disk as well in addition to the other source files.
So in summary: Either compile the prg file directly or use a converted one with replaced control characters. Files exported directly from DirMaster or similar tools won't work.
The basic program was saved exactly like this by C64Studio. It's the actual version used by and edited in C64Studio. I just didn't switch on the special character translation to macros. I always used "/generatesrc=true" btw. but can't find any new file created now (still only prg, il, nl).
And are you really sure that uppercase/lowercase isn't exactly the problem? When I compile the program with "my" source, I get a binary (prg) that's completely identical with yours apart from strings. So in your version it's "TREE.WIN" while in mine it's "tree.win".
To me it looks like MOSpeed expects the sourcecode to be in lowercase mode, and that it translates lowercase characters to uppercase characters (from a PC point of view). My source code has uppercase characters as they would be displayed in the C64's normal uppercase character mode. These are then translated to lowercase characters from a PC point of view, but in the normal C64 uppercase mode, these are special characters. E.g. "TREE.WIN" from my source code is translated to "tree.win" (0x74,0x72,0x65,0x65) in the compiled version. Now these are graphical characters in normal C64 mode and this probably explains why the file is not found.
I tried to work around this by using " /tolower=true" but it works only for the text, not some other characters. And turning on/off lowercase mode in C64Studio doesn't influence the source code: it's always stores uppercase. And when I switch from "symbol" to "macro", C64Studio stores things like {17DOWN} which MOSpeed doesn't support.
So I guess in the end, it looks like MOSpeed and C64Studio just don't work together because of some formatting issues (lowercaser vs. uppercase and different macros used for C64 symbols).
I sure hope you can work this out with Georg Rottensteiner at some point, He seems a nice enough guy.
No, lower or upper case for source code doesn't matter. For strings, it might of course, which is why there is this tolower-switch. It doesn't affect special characters, of course. But these are already mangled in your source code anyway.
Have you tried to compile the prg file directly with the new version? It should work and create a runnable executable as well as an additional .asc file.
The problem with the {17down} is, that I wasn't aware of this option. I got my understanding of these things from looking at source code only, because there are several variants of this and I couldn't find a comprehensive documention has lists them all. I'll add support for this variant as well.
Ok, MOSpeed now supports stuff like {17down} in addition to the already supported {17*down}. I've updated the JAR file.
Great. That works for me when I turn on macro mode in C64Studio and use "/tolowercase=true".
Thanks a lot for your support!
Great to hear. You were of course right about the lower-/uppercase mismatch between the C64 and the PC. With MOSpeed being a cross compiler, I decided to stick to a scheme where you can edit the files on the PC properly in some text editor and then compile them for the C64 with the same outcome. Of course, that includes writing text in lowercase even if it's displayed in uppercase on the C64 depending on the mode.
But it also means that I can write something like "Hello" on the PC and get it displayed properly on the C64 in lower-/uppercase mode. The alternative would have been to write "hELLO" on the PC instead, which is just awful.
Bascially, you can copy the source files that MOSpeed takes into VICE and the get the same results. That said, if you are using the X16 emulator https://www.c64-wiki.com/wiki/Commander_X16 (MOSpeed supports the X16 as a target platform), you get the exact opposite. So it's all kind of difficult to find a way that pleases everybody. That's why there are the tolower and even flipcase switches in newer versions (still not documented in the wiki).