Commodore LCD (xemu/xclcd)

Hi here too

In general: my lgb.hu site is dead currently (xemu-dist.lgb.hu is another web server it works, and in fact tt has a Commodore LCD emulator as well, even in browser demonstration mode!), BUT you can find my Commodore LCD stuff at least with acrhive.org for now:

https://web.archive.org/web/20…p://commodore-lcd.lgb.hu/

The emulator mentioned here, is an earlier one written in "hand-crafted" JavaScript, it may not work there, but anyway, Xemu's Commodore LCD emulator is better. About the specification, hw/sw on this machine, for now:

https://web.archive.org/web/20…lgb.hu/specification.html

The reason of that ugly bold red text on the first page: it was some interesting happening that Blacklord mentioned my work which was then included on the Commodore News as his work, because the misunderstanding from the side of the editor of that material which then confused many people.

To my understanding I was the first who has about meaningful amount of information on Commodore LCD, and who managed to write a working emulator for Commodore LCD. Unfortunately again, there was some kind of rude guy from the MESS/MAME (?) team who contacted me, that "he almost did it, waaay before me", well. According to me, jumping over a big valley "almost" is still falling into the void, it's totally irrelevant that "almost" done it, or at least a bit. Then I helped HIM quite bit so his emulator can work too, but there was not even a "thanks" for it (not even in private ...) but always the feeling that "I know much better than you" can be felt by me from his words. I really don't understand these kind of people, I am sorry. I enjoy talk/share/get to know more things, and these kind of personal flames are just so lame ... Anyway. sorry about this story, I don't want (never wanted) a personal "fame" or being "famous" or anything, but I'm kinda picky if some want to even argue that I did something at least ......

And btw, no, Commodore LCD has no SID. It's intended as a "business portable machine", it has barcode reader port, true serial port, some kind of auto answering modem (or just planned?), fixed character set in ROM (in my specification it was not clear, what I mentioned above, in fact Commodore LCD's character set is fixed an in ROM, you can't modify it, _though_ it has also got bitmap mode ...). So it was not exactly a "home computer" class planned as most of the other Commodore machines, it's important to declare.

It's also interesting to note, that on Commodore 128 there is an "OFF" command, you get "unimplemented command error" so clearly there is some command meant to be "OFF". It seems, it may have origins in Commodore LCD where OFF command probably meant to "cleanly shutdown" Commodore LCD (as it has battery backed RAM, thus the crude version of current's day "sleep mode" of computers).

I guess there is some kind of sound by hardware. See my specification at section "The VIAs". But this means that basically you can "shift out" (using the VIAs, funny saying via the VIA ....) some information realized in audible beeps and such, but probably that's all. The other thing, that MAYBE it has some connection with the DTFM generator needed by the modem in tone dial mode. Honestly, I haven't tried to explore this realm of Commodore LCD too much ... And for BASIC too, like with Commodore 65: many routines are unfinished not working yet etc, that's a common thing on unreleased/in-development machines. Clearly if you see unimplemented command error, it means there is some BASIC token, handler stub implemented for that at least, jut the routine was never finished thus pointing to the "TODO" kind of error, ie "unimplemented command error" ;-P It's very interesting that C128 retained the OFF command MAYBE (?) from Commodore LCD, maybe it's just a mistake since there is no sense on C128 to have that OFF command, but who knows ... Bill Herd should be asked, as he was a developer of both machines (and btw Plus4 too), we exchanged quite few mails during my Commodore LCD mapping project btw, he is a very cool guy. But others helped a lot too, it's important to declare that I don't want to still the credits from others contribution, so:

https://web.archive.org/web/20…re-lcd.lgb.hu/thanks.html

Zitat von Freddy

@LGB-Z In my bash I see -> "FILE: #clcd-u104-parasite.rom cannot be open, tried path(s):"

Parasite?? Is it a build-in virus??

Yeah, sounds scary enough, right?! But no, much simple answer Commodore LCD has an interesting feature to scan for "ROM signatures" at power-on and checking some kind of "ROM directory" with accessible applications (which can be seen in the menu as well later, that is called the "SHELL") , and also to auto-bound file extensions with handler programs. My parasite ROM is just a way, that I did experiments with my own ROM routines to be "top of" on an unused part of an existing ROM area, thus I called "parasite" ROM I also wrote a small "demo" (well not so much), a scroll of Yoda, to test LCD emulation in bitmap mode, though this demo cannot be accessed now because of the malfunction of lgb.hu I mentioned

Another thing I keep for a future project (especially now with very great GEOS sources with modern tools and build systems ...) to try to port GEOS to Commodore LCD. it would be fun to imagine an "original" Commodore battery powered portable business computer with GUI OS, just for fun ;-P Though the low vertical resolution can be a problem a bit, but with auto scrolling etc, it may be OK ...

Well, Commodore LCD's resolution is 480*128, if I remember correctly. So it's not exactly 640 pixel horizontally, but still better than C64 (320). The issue is more the vertical resolution being only 128 pixel. That's why I thought it would be nice to have resolution of 480*256, and allow a vertical "panning" that you always see only a 128 pixel width part. Actually that is easy, as you only need to modify the starting address for the LCD controller in video RAM, so no need to copy the whole visible screen or anything like that, at least that's a fortune (ie C64 does not allow to set the starting address that precise, you can "scroll" by some pixels but if you are over 7, then you need to copy everything by the CPU ...).

What kind of spec mentions 1Mbyte? If the one I linked as a PDF, that is the one I mentioned that it's an early design concept of Commodore LCD which is about 99.99% not true for the "real" Commodore LCD created So forget *anything* (!!!) written in that PDF, you should treat it does not even exist. What I wrote as specification is correct, instead (well, maybe not fully, but stil 1000 times better than that PDF ... it's surely not the fault of that PDF as that is not a documentation of the Commodore LCD but a preliminary design concept before Commodore LCD even begun to be designed for real ...) I just mentioned because it's interesting how different the early concept and the final result (well, final ... it was never released, but was shown to the public once in a CES event or such, AFAIK). In fact it would be better that I remove that part of my specification on my site where I talk + link that PDF, since it's very confusing. So no, Commodore LCD does not support 1Mbyte of RAM. The whole physical address space is 256K. Usually there is only 32K of RAM installed, but it can be expanded (the emulator allows to set the amount of RAM). As far as I can see, in the development units there are 128K of space used for ROM chips, that left max of 128K as the RAM. But honestly, I am not sure what happens if you allow to remove some ROM and replace with RAM. In hardware level it would work, but the "OS" of Commodore LCD may not recognize and use it and also for sure then you would lost some applications which can be seen in SHELL, if you remove some ROM (in fact only the KERNAL ROM is compulsory ... if all other ROMs are removed, Commodore LCD still "boots" but drop you into monitor, since SHELL and even BASIC is in another ROM, leaving only the monitor is capable of work, which is also in the kernal ROM). That is even an advantage of ROM, that it maps its own installed ROMs and apps inside on power-on, so in theory you can remove/replace them etc, and the shell automatically will show what is really in the machine. That is exactly a reason why my parasite ROM stuff work, as my extra code as an application for LCD can be recognized by the stock "OS" of Commodore LCD and even linking that as a title in the SHELL menu totally automatically without any code needs to be modified at KERNAL/SHELL/whatever level.

Well, feel free to ask Surely, I am not against if you want to rewrite or extend that ... Unless if you try to say it's totally your work, what makes me angry, as you know now But I DONT think you will do that, just I tell because of the sad story I mentioned in relation with this Commodore LCD project I've already had to encountered

Zitat von Freddy

For now it has just 2 goals: learning how the machine 'ticks' & increasing 'knowledge' for additional users, so they have a better starting point.
And of course it is your work. If i would 'reclaim' something, then only the collect of information and 'the making' it a book (manual).

Even the BASIC 3.6 chapter would be -> (c) CBM/M$ I would only be the guy who put the words together (and erratas)

Btw.: Even 256K (128ROM/128RAM) is impressive.

That is already a GREAT value if you re-work it, especially because often the problem with both of a software or a documentation that regardless how valuable is, it does not worth too much if cannot be used by most people, because too cryptic, badly formatted, or in case of software hard to use So don't underestimate your work either when you do that It's very important for most people that you can provide the format they would like to see and use! Unfortunately this kind of work is under-rated, though in my opinion it is very important. That is the problem with Xemu too in some aspects, that it's hard to use / install /whatever for many people so let it be good or bad, it just renders unusable for many people, you see.

Btw, I am not sure if I can express myself well enough in English: so, there was not even the basics of some kind of specification (which is true!! that preliminary PDF is totally unusable, almost nothing is true from it just maybe the machine name hehe), so what I meant that the information I provide with my specification is my work that I had to find these out. Not only write the specification but get the information for that first. THAT was the hard part, not to write it. Since there was almost no information or only false information on Commodore LCD before. So that is mainly the result of weeks of disassembly of ROM content by me, trying to figure out how the hardware should work which can run this ROM code, bothering ex-Commodore engineers, lots of trying and failing with various emulator tries in the process (first it was a command line only Python code, then it was hand written JavaScript, then it was C code ...), etc etc you see. So that's the reason only I am a bit picky about this topic all the time, that it was kinda hard work, writing a lame text about it then (lame because I did it hehe ...) was only 0.0000001% of the work about ;-P

The actual limitation of address space btw comes from the MMU's construction primarily. The offset registers are 8 bit wide, and shifted left by 10 bits when added to the CPU address (that 10 bit shift comes from the fact that the MMU can map memory regions on 1K granularities). That is 8+10=18 bits address, as you can see, thus that is 2 on the power of 18, which is 256K. Basically as far as I can imagine the MMU chip itself is just an adder with selectable input for one, to choose the MMU offset register based on the MMU mode and the windows (from the CPU address) and the other is the CPU generated address, the result is the physical address (to be precise the the lower 10 bits are not altered so it can be pass through). Actually this is not hard to implement in some HDL let it be Verilog or VHDL, actually I've already started to create a VHDL implementation of Commodore LCD which is capable of work on a Nexys4 board, so maybe even as an alternative "firmware" for the Mega65 hardware in the future, if someone is so crazy that they want to do that?

I have no idea, the BASIC interpreter is not written by me of course, you should ask Commodore and/or Microsoft But honestly, it can be just a different RND() implementation than other Commodore computer. After all RND() should mean random, that's another question that most times / and in case of most implementations, it's predictable how that is generated in sequence with a given "seed" value, which can "abused" then to create a program like that But that's then depends on the VERY exact RND implementation. So there is no "correct" or "not correct" answer, RND is meant for generating random numbers, these are just "abuses" ;-P But in general, I don't think it's a good idea to except everything working from a never finished computer , that's kinda same story in this respect as with the C65.

Zitat von Freddy

Stupido mio, I really forgot about how random the rnd() -function is.

Still, it's interesting, that Commodore LCD's BASIC uses - it seems - another random number algorithm or so? Just for curiosity maybe it would worth to compare the result with other CBM/MS basics, that only LCD gives another result or there are others too ... Unfortunately, Commodore LCD is extremely rare ... with C65 at least there are hundreds (?) of machines or such, AFAIK we know about 4 machines for LCD, two of them is known where they are (one of them is Bil Herd's unit, another one is another ex-Commodore Engineer's property) . So for C65 there can be a project to compare different ROM development states, but it's kinda hard with Commodore LCD ...

Btw with my "C-LCD is rare" statement I mean, that it's even possible to have different results with different ROM versions, as it was under development too. The same for C65. For other machines, at least we have the "final result" as the released ROM versions being named as "the final one". And with CBM/MS basic I meant that Commodore BASIC is in fact licensed from Microsoft so for real, it's "MS BASIC" in some degree, but surely, the exact implementation can be VERY different from 65xx versions to other, like GW-BASIC etc ...

CBM basic numbering is a mess. For example BASIC 4 (CBM-II) has greater version number than BASIC 2 in C64, or even BASIC in LCD or the Plus4, though for example C128's BASIC (7?) seems to be quite close to LCD (3.6) still 3.6 is a much lower value than 7, and in fact even lower than 4 (CBM-II). I'm really not sure what this is the case ... Or why BASIC 4 has much more tokens than C64's 2, when C64 is a newer machine, etc.

By the way, I am not totally sure that this thread is in the right "category". What I mean here, that we're talking basically about the Commodore LCD itself in any sense, and not so much about the Xemu's emulation on it. Surely, it's not a problem, just I think, it's maybe worth to mention that the machine itself can be interesting for more people, even without any specific emulator, just to talk about its hardware and built-in software, etc ....

Still about the C-LCD: https://www.c64-wiki.com/wiki/Commodore_LCD

Interesting, that the photos on the actual LCDs shows a kinda different thing what you can see with my emulator. That means that it can be the case, it's a different ROM version what I use and have of. I've even written about this, btw:

https://web.archive.org/web/20…-lcd.lgb.hu/versions.html

Zitat von Freddy

The Problem with 'numbering' is not due to Commodore.
It's a pure Microsoft failure.
Proof is in picture below:

Hahahaaaa, that's a good one But seriously, I think CBM version numbers are given by Commodore not MS But still, a good joke

Zitat

About the Commodore LCD:
When comparing the case it looks very familiar to the C64c and the 'flat' C128 case.
It seems they where on the way to this kind of design back then, he?

I'm not sure, Bil Herd should be asked, he is a cool guy to talk with, and he also has many funny Commodore stories, some of them are on YouTube as well, btw Bil was a designer of C-CLD and C128 too, and in fact also the Plus/4. He had an interesting story, that C-LCD as an idea was a MAJOR hit, but CEO of Tandy (if I remember correctly, maybe other company) has a lunch with the CEO of Commodore, and he managed to make Commodore's CEO sure, that a portable computer is a very bad idea, and will be a major failure, so he cancelled the project then. The funny thing: it turned out that exactly that company had major success then with their similar designs later! So it was clear it was just an ugly move ... Bill also told that he was kind an angry, even had a poster in his office so everybody can see the CEO's fault

Zitat

About it's BASIC 3.6
With EXIT you leave BASIC interpreter and land in the 'desktop'. Doing this deletes programm in memory!

Surely it is, I guess. Since this is not a multitasking machine Of course, it's also true for DOS, etc, every non-true multitasking systems, or even multitasking ones, if the program really exits and not running in the background or something. So memory is used by the actual running program, if you exit, it goes away. Surely you can SAVE it before exit. And in fact it will save it into the "virtual 1541" which is in fact a "RAM disk" in the terms of nowadays. That won't be cleared, and you can LOAD program back from that. In fact, since C-LCD has a battery powered RAM (even if it turned off) the content of the RAM disk survives it. Surely it won't work with the emulator, as it is not a real hardware etc (but in theory I would be able to do that by saving the emulated machine's state into a file, or something like that). Some of the C-LCD's built-in software "looks like" being some kind of preserver, but only because they auto save/load data from/to the virtual 1541 (aka RAMdisk) like the MEMOPAD. You can catch this action, start memopad from the SHELL (you call it 'desktop' but it's called the SHELL officially) type something, and exit. If you run MEMPAD again, you see what you typed before, but you can also noticed that a new file appeared in the "virtual 1541" section of the SHELL, that is the savefile, MEMOPAD automatically created to preserve the content. Surely, commodore could choose to do such an autosave for BASIC as well, that's true, however since RAM was kinda limited (AFAIK only 32K by default my emulator uses more by default .....) so it was dangerous to "waste" space for the "virtual 1541 space" (RAMdisk) for every purposes, it's better to let the user decide. But it's only my logic, for sure about the reason.

Zitat

Inside of BASIC programms you can use -> POPUPS command to invoke the popup-tools (calculator, memo-pad), and return to your programm.
Using POPUPS does not delete memory.

It's a bit different, those are "mini" programs more ... Not like the BASIC interpreter. I guess it was just a try to add some interesting features without the possibility to use some kind of true multitask / state save/load system which would required much more system resources, especially RAM. However for example MEMOPAD it's interesting again without POPUPs as well, see my previous part of the answer above.

Zitat

Btw.: How can I attach a real drive to the emu? (I meant of course one xxx.d64) So I can save (and restore) my test programms.

You can't. It's not implemented. In fact, I am not even sure, that it would work, I tried to emulate a real 1541 (not the virtual 1541 now!) since Commodore LCD has an IEC port, so in theory you can attach a real IEC-serial disk drive and use it. So I wanted to emulate this scenario. I am still not sure why I couldn't do it, maybe it was my fault, but it's also possible that there is some ROM bug etc which makes it impossible to work with the unit at least I have ROM image of, and I used as the ROM content of my emulator. I did one ugly hack though, requires some command line stuff. If you have a PRG file to load, specify that after the -prg switch in command line to start Xemu/CLCD. You won't notice it works too much UNLESS if you go to BASIC then, when you see a RUN text appears, you can even press the return key to execute the loaded program, or ignore that and just give LIST, or anything. Yes indeed it's an UGLY hack but at least it allows to load PRG files. Yeah, surely, it won't allow too much to SAVE ... I think, besides of IEC, the most nature way to do this would to provide a way to move files between (so: from/to) the virtual 1541 of the CLCD (ie: ramdisk) and your computer on demand.