Hi there, the screen show Basic 10.0 v0.9B.911001. It also has a yellow border. Just starting with Mega65 on Zemu. Just ordered the Mega65 last week.
The problem that you're using original C65 ROM. It does not know the hex number feature $1600 in line 250 (among many-many other things). This syntax is a MEGA65 BASIC (BASIC65) extension so you need that ROM to work.
When I run Mega Assembler with Xemu, I get the message "syntax error at 250" Listed: "250 DA=$1600: REM Default Address for Assembly. I have also copied the Megaasm.d81 files to the SD Xemu disk using DirMaster.
Just an idea, what is your ROM version you're using?
not so much people using LCD in form of emulation
Yeah, already a crowd 
Anyway, I would be interested even if I do it only for myself.
By the way, Commodore LCD is a very interesting machine. I feel sorry that I don't have time for everything I would be interested in otherwise. But it would worth a big effort to disassemble the whole KERNAL at least to begin with (maybe BASIC too) and even making some "DIY bug fix" releases (as CLCD was cancelled relatively early - only 4-5 units are estimated to be existed - I guess contains even more bugs than the famously buggy original Commodore 65 ROMs) and things like that in the process. Unfortunately the demand wouldn't be so great, as not so much people using LCD in form of emulation, and certainly not as a real machine ...
Ah, OK. I meant to test with the emulator's load/save to be sure it works. Not with the RAM disk, that's a whole another issue as its own and I have not so much control over that, but as mentioned I found many odd things with it already.
Not sure about the RAM drive, I did some test to create lots of files on it from BASIC and it seems ROM even crashes, it's very possible that it's not the exactly most polished part of the system ... Also it goes so slow after a while that IEC bus is pair with that, which is funny, since it's in memory ... Thus clearly, the ROM routines handling the RAM drive are kinda well hmm errr "interesting".
Btw, what you sent me program, I've loaded with the inject functionality then saved then loaded it, it still worked, and the same size. Even that it must be relinked. Now I see what caused the most problem before: I assumed that the load address is in pair with the next line pointers which is not the case with your program. So I've simply turned off that check and now it seems to work. To be able to run any BASIC program it must be relinked anyway (unless it's for the same load address as the target system and the pointers are 100% to be good). But as far as I see it's good now. Szoval - eddig legalabbis - minden okes, mondhatjuk
If someone has more time than me (that is, more than about almost zero), the new `dev` builds can be tested maybe about the "usual" CLCD load/save stuff. As usual, I only code and not so much testing, that would need time ;-P [ok that meant to be funny but as every joke, there is some truth in that as well].
So what is then the role of the zero byte just before the start of the basic program? Mega65 seems to ignore it, but when you change that byte on any Commodore Machine (PET, VIC20, C64) Basic programs don't work any more. E.g. on a C64, write a Basic program, then POKE 2048,1, then RUN leads to Syntax Error. Somehow on those machines, the zero must be present.
To be honest I have no idea. For example https://sta.c64.org/cbm64mem.html says:
Seeing all those zero bytes between basic lines,, it's hard to interpret how they where meant to be, line starts or line ends...
I always thought the zero byte at $2000 was part of the program, but just isn't saved to the file to save memory, since it's always zero anyway. But it seems my interpretation (that I had for the past 43 years) was wrong...
Well yes, hard to follow first time, but quite logical thinking about it this way: if you examine a PRG itself "on the disk" you can see the load address (first two bytes) is $2001 in our case. Thus, clearly $2000 is something else, not part of the program strictly speaking (since is one byte below the load address). For sure same applies to other configurations like in case of C64 saved BASIC programs would have $801 as load address (and not $800).
QuoteI'd like to add to this that - even if those two bytes are part of the PRG file - you don't have to put them into your assembler code, since the assembler will automatically write them to the PRG file. They're derived from your *=$2001 statement, so the first two bytes in the file will be $01 $20.
That is dependent though on the assembler, so indeed some must be very careful to check these things out first Some assemblers purely uses the *=.... construct to change the relative address it emits addresses to but does not cause anything to "output" at all into the target file! Some assemblers can use that to "skip" bytes in the middle of program as well (filling up zeroes), some assemblers though, no filler bytes will produced just the assumed address for labels, etc to be referenced for. Honestly, I should admit, my English here is not well enough to express what I want to say, sorry about that .........
Much appreciated and it made me understand the BASIC of it
I will see if I can find some reference for what all these header-bytes actually mean, but your example works just fine.
In Basic, every line starts with a zero byte. For the first line, this is already and always present at $2000, so not included in the bytes above.
Well, not exactly: every basic line ENDS with a zero byte.
In BASIC every line starts with the (two bytes long) pointer to the next line unless there is no more lines, thus being '00 00' for the pointer in that case (and no more bytes at all then). Then two bytes long basic line number. Then the tokenized line itself, end of the basic line is marked with a zero byte. Yes the info of end of line marked with a zero byte, and the next line ptr stuff is kinda redundant but some BASIC functionality tend to use different methods to "walk" on lines. Also loading a BASIC program usually relinks the pointer structure anyway, thus it's possible to load a BASIC program written for another CBM machine with different loading address (in fact, that is the reason that loading the "$" - directory - from 1541 can't be used with ,8,1 and only with ,8 .... but that's a long story).
So the reason the program ends with three zeros, is not because it marks the end of the program alone but: one zero just for the end of the current line, the two next would be the pointer for the next line, but there is no more, thus being two zeroes then. So in total you'll see, there are three zero bytes at the end of the program.
And also a PRG file is special having and extra two bytes at the very beginning, that's the load address, and not part of the BASIC program itself.
Seeing only the first message in this thread, I wanted to respond, but it seems there is some help here already
Oh, by the way, I forgot to mention that actually relinking does _nothing_ if links are OK already, since it would produce the very same "next line pointers" thus no modifications at all.
Display MoreHi, I have uploaded a zip file to my own site and wanted to send a link about it to you as a private message now... but I can't seem to find such an option here (maybe this forum engine doesn't have any...?) So then what's next...?
In this current form, it is just an empty shell for startup, which prompts for a simple greeting message and you have to type in an "x" (+ return) to exit. (As shown by the attached screenshot.)
But please delete it after trying out, because it is not yet public and not yet meant to be published in any form.
In my opinion, as generally speaking, the best way would be that whenever your algorithm fails to recognize or handle a valid Basic structure within the injected code perfectly, then rather simply leave it untouched in the memory, as is (just set the end of program pointer to the last byte +1 and ready) instead of dropping an error message about it (or making the mess yet worse). That can also be a data file or machine language code.
The user may also call the re-chaining method of the Kernal by himself if needed, e.g. just entering an empty line (10 + RETURN) or so.
As I've said, it's probably just the pointer handling etc must be "fine tuned" by me. I really don't like the idea that "leave it alone" you suggested, since that is not what real LOAD would do anyway. Also that makes it possible to load any basic program, even not written to the Commodore LCD BASIC, having different starting address and line-link pointers. I really would like to make this "in the proper way". Relinking itself should not mess up the "extra payload" after the end of BASIC program (what is used often to carry machine code and use SYS in the "basic part" to call it), it's just I don't set the pointers right. The error messages you can see is more from my checks which tries to be sure that BASIC is running at all, ie somebody not trying to use that without starting BASIC first. But again I'll check those a bit more than only few minutes I spent it for, so far. Also I'll try to dig out my "demo" (well not really ...) for Commodore LCD written by myself (to test graphics mode emulation also my ability to modify the ROM to include own programs in the SHELL) as well, that's in ROM form, but would be interesting to rewrite into the usual BASIC-stub form and trying to load + run it. You can see it in my first Javascript Commodore LCD emulator (by selecting the 'lgb' entry from the SHELL menu): http://commodore-lcd.lgb.hu/jsemu/?test=yoda
Btw string lgb repeated three times in total then 'at' then gmail .com is my email address for email kind of private messages 
Indeed, this is not a bug, or if it's, then it's a design bug of Commodore waaay before C65. But I guess there must be some reason for that, just I can't tell what
Well, to clean and sum it up: this code of mine is running on all 8-bit Commodore machines, ranging from the first PET with 4K memory, up to the newest and the most exotic ones (like the C65 and the MEGA65, or the different models of the CBM-II series). Recently, as a bonus, even the Commander X16 has been added to the support list (maybe I can drop it later if I change my mind).
I have already managed to run it on the LCD when I start it as a sigle PRG. That's no problem.
Yet it needs some additional data and code parts to be loaded later, which I first want to copy to the ramdrive, still before running the main program.
Well, then please send it to me, or present it in some other means, so I can check. Not so much time since my initial rush effort to check smooth the rough edges after implementing the initial idea (I guess it's more or less OK just needs to be "fine tuned").
Display MoreEspecially the save is not even tested by me!
I have just tested it.
LOAD a PRG (the 10 PRINT "HELLO") works, but SAVE doesn't work yet.
Yeah, as I've said I run out of time so I haven't tested that yet, even the LOAD was only tested with a single line basic program to load. So it clearly needs more polishing, that's also the reason I put only into the "dev" branch only.
... (lack of time) ...
Do you really need more than two hours of sleep?
No, 6 hours "trying to sleep" and 2 hours actual sleep
There is already some modifications in the "dev" branch. It's not all my changes (some of them wouldn't even compile - just a draft - thus I tried to commit something sane at least for now) and not really ready yet. On the download page, "Show all downloadable builds from various branches (for experienced users)" must be clicked to be able to see the "dev builds" (also the link above turns of version fetching and displaying, btw).
The main changes are: UI menu option for dumping all the RAM, load basic prg and save basic prg UI menu options. Especially the save is not even tested by me! Surely these should be used only if CLCD is in BASIC mode otherwise strange things can happen. Again, other than single line program, I haven't tested that yet (lack of time), and the save may not work at all. It re-links the loaded basic program, so in theory even a BASIC V2 program (eg from C64) can be loaded (surely, it's natural to work with the LOAD command, but in case of direct memory inject, I have to relink myself ...). I also tried to set some pointers of the BASIC interpreter to look like what it should after studying what a C64/C128/Plus4 does with those pointers exactly.
After having saved the injected program code to ramdrive and then loaded back, it seems the low byte of the ending address stays intact, but only the high byte is increased. That's strange. In spite of this size corruption, it remains runnable and working. That is just a problem due to much more free space loss, as the ramdrive is so very limited in capacity (it seems to stop at about 64K, so seemingly the second half of the 128K RAM is used for it).
Well, we must not forget that we can't reject the idea either, that the ROM is not perfect. After all compared to C65 (which is indeed has very buggy versions of ROM) CLCD is even much more rare and probably even much more "not ready" than the C65 ... But for sure I wouldn't blame someone else for my fault, so I still find it much more likely that it's my fault, of course. But I'll see, I'm really planning for today to try to create some more comfortable way to load and save basic programs on-the-fly from the UI menu. Sure, not the perfect solution but I guess it would help still.
I have already found it before: the Basic pointers are beginning at $65 (101), where the first pair is the start of Basic memory, whereas the second is the end of program pointer (the first free byte after the program code as usual, and probably the variable area is starting afterwards), so it is at $67-$68 (103-104), you can check it easily.
Yes, but ... If you check the source of the emulator, I've already done that exactly Since you mentioned my method is not perfect, so my assumption, that there are more pointers should be set, than just these (well, the beginning should not be bothered too much anyway).
Anyway, a quick comparison now on layout of these pointers for C64, C128 and Plus4 revealed, that the addresses can be different, but it seems, the order is the same on all of these machines with the very same meaning. Thus my conclusion that what $2B/$2C on the C64, should be $65/$66 on CLCD basic, and just by guessing, the 7 pointers from there are the same on C64/128/+4, so my idea that probably it's true for the CLCD too: after all if Commodore has managed to keep the same order of these pointers at a single place (even if the actual address varies), I would guess it's true for the CLCD as well. By assuming this is true, I guess there is well known solution for C64 how to do this, so then just the solution should be offset'ed to the CLCD zero page area for the very same meaning.
Btw, meanwhile I've put a memory dumping menu item, and basic load/save items as well. I need the implement the "right policy" though.
It was just a quick 15 min check/compare (of memory maps of c64,c128,plus4) and hack (in Xemu), so of course it's not ready or in the official Xemu repo yet. Maybe tomorrow if I have time, it seems it's not a big deal to do, I mean shouldn't take too long for me.
