Commodore-LCD.lgb.hu :: Commodore LCD Specification

Tervetuola! The purpose of this page is to give a specification on the Commodore LCD machine. If you don't know what it is, visit this link first.

Important: it seems there are more Commodore LCD versions! This document and my emulator is about the version I have ROM images of. Any help would be nice to get the ROM images of the "other version" though. Also in general: any help about any information on this site (including the documentation, and the emulator) is welcome!

I write this documentation from partly the experiences got from my own Commodore LCD emulator and my try to disassembly the KERNAL of this machine, but still; it would be impossible without some great guys who helped me in various ways! Big thanks to them! Without them there would be no usuable emulator and not a detailed specification like this. Also as they are (as far as I know) the actual designers of the Commodore LCD, I must thank for their original work as well, it's a shame that this machine was never released, it would haven been a great hit in its time, I am quite sure. However never underestimate the power of time: it's not so easy to get information, find documentations or even just remembering things happened many years ago, especially if they're technical details ... That's even an important factor me to try to collect information and write an emulator before everything fades out totally, this machines deserves to be saved at least in this form.

As usual, information on this site should be considered as "may be" and shouldn't be trusted blindly! Also, I often update this page (last section on this page tries to summarize the changes) in case of corrections, new findings or information. If you have any idea what I can write about, or you have more information, possible corrections, please tell me. Contact for me can be found on this page.

Sorry for my not-so-perfect English / typos in advance.

Summary

• CPU: 65C102, 1MHz clock (but see later at chapter "CPU")
• Display: monochrome LCD with 480*128 resolution, 80*16 text resolution (6*8 character matrix) or 480*128 hi-res mode, 32K addressable RAM by the controller. The quality of the LCD is said to be excellent to its age.
• Memory: 256K system address space, max of 128K RAM, and 128K ROM, default RAM size seems to be 32K which can be expanded on-board to 64K, and additional external 64K expansion is possible. Also note: maybe the total number of RAM/ROM is not fixed but the sum can't exceed the 256K limit of course.
• I/O chips: two 65C22 VIAs, one 65C51 ACIA (some sources reports four I/O chips used, I don't know what can be the fourth then, maybe the LCD controller is counted as well?)
• RTC chip: OKI MSM58321 or similar
• Sound: unsure (description of VIAs seem indicate a simple "beeper" connected at least, though some sources mention "no sound")
• Battery: The Commodore-LCD is a portable computer, it has batteries. RAM is battery backed, so after a "clean switch off" the user can continue the work on next "power on" event.
• Included softwares: in ROM; monitor, BASIC (v3.6), word processor, spread sheet, terminal emulator, file manager, calculator, memopad.
• Interfaces: CBM IEC serial, RS232C, internal modem, centronics port (though not with standard connector), barcode/joysick port
• Storage: RAM file system, wafer tape drive (? no idea if it was really produced or just planned), external drive (1541 would work, I guess, 1561 seems to be planned which would be 3.5" also battery powered external floppy disk drive)

Early information

It's important to mention: there is a seems-to-be nice PDF describes the Commodore LCD. However as it turned out for me, that PDF is not about the "final" (well ...) Commodore LCD. As far as I can imagine, it was a very early proof-of-concept design, and the actual design went into a different direction at the end. To demonstrate the differences, here are some:

• system address space is 1Mbyte (real: "only" 256K)
• totally different MMU
• dedicated I/O space from $D000 (real: from $F800, write-only regs are even "behind" the ROM)
• I/O chips are 6524 PIATs (real: 65C22 VIAs)
• LCD controller is an MCU-like entity, only one port is used for communication with it, even of the screen data, there is no video memory in the RAM at all (real: dedicated LCD controller chip, four registers, there is memory mapped video RAM)
• BASIC 2.x with some "enhancements" (real: 3.6, though it's possible 3.6 is basically mean this ...)
• different proposed "menu screen"

Anyway, if you're interested, here is the link.

The rest of the document is not based on this document, but on the actual situation seems to be true for the real machine what we have ROM images for. This document was even a bit confusing for me, when I started to write my emulator I find the "display port" where ASCII/PETSCII values are written to be displayed (as I know now, Commodore LCD uses memory mapped video RAM), and when I found a location which seems to be often meanigful to form understandable text, I thought it was. However it was only an MMU register, the "dummy write" style (ie, it's not important what you write there just the fact of writing itself).

Correctness of this and other specifications

It's very important to note, that specifications should never been treated as fully correct. See the previous section for an example (I thought it's the actual specification at the beginning of the project). But even seems-to-be more correct information resources can have problems. For example the documentation I managed to get was about the VIA pin usage by the RTC chip. It took me hours to try to emulate this, but it didn't worked. After watching the KERNAL disassembly list for a long time, I had the idea that WR and RD are exchanged in the table. And bingo, it was the problem, the specification had this "minor" fault. Also the RTC chip, besides the type, it seems some registers are not at the "right" position. In these cases, I always modified my emulator to work with the known-to-be-real ROM images. However, it's still possible that for example the KERNAL is incorrect and had bugs, since the Commodore LCD was not released yet, thus we may have to consider the possibility it's not production ready code, and have faults of its own.

My specification (this page) is an odd mix: it contains information which is more or less only guessed by me, but it also contains actual "facts" written by seems-to-be-official specification. As I've stated, even those seem to contain bugs (or it's the KERNAL's?) so I tried to present the correct information here.

In nutshell: I try my best, but I can't guarantee that this specification is fully correct. But the opposite, I am very sure it's not ...

You should also read the page of my emulator, there are some known bugs mentioned there.

The name

Name of the computer is "Commodore LCD". Since just saying "LCD" can be confusing (is it about the whole machine or just the LCD display/controller of it?), I will name it as "CLCD" for being short. However, it seems, some documents mention it as "LCDC" instead of probably for "LCD Commodore" or "LCD Computer"?

Availability

As Commodore LCD was never released and it's told only two (or four?) "fully assembled" units exist, thus it's not so realistic as with other machines: if you want to write an emulator and you have question, try it out on the real "iron"! As I am not so rich to try to buy one of the existing Commodore LCD machines (but I am open to get one as a gift - ok, back to the serious parts ...), my only choices:

• Fortunately we have saved ROM images
  • Disassembly them, and try to understand the hardware the code was written for
  • Try to write a rudimentary (even not so correct) emulator running the ROM image which helps to understand some aspects while you debug/trace the code, and/or experiences during you try to use the emulator (even for writing simple softwares for the target machine).
• Try to find people for help who really own a machine.
• Try to find poeple who has information on the machine.
• Try to dig the Net for available information.

To be clear: I've tried all the methods above in paralell to achieve some progress. This is also an answer for the qestion: why my documents are quite inconsistent: it's possible that some sections or pages contain outdated information got from another source, my guesswork or from understanding the ROM disassembly, while I write about newer information at the other place. I'll try to fix these kind of errors though.

Again: thanks to all the people who helped me in collecting information!

My emulator

You can try an emulated CLCD out with my emulator.

The CPU

The CPU seems to be 65C102 though some sources mention 65C02. I guess, it does not matter too much, as 65C02 and 65C102 are software compatible. My emulator doesn't (or didn't, it depends when you read this ...) emulate bit oriented new opcodes compared to NMOS 6502, only TSB/TRB and new immediate addressing mode of BIT. So no SMB/RMB/BBR/BBS. It would stop the emulation with fatal error in case of an unemulated opcode, but it didn't happened with the original ROM images. For me it's always confusing what is 65C02 and 65SC02 opcodes and various extensions (like "GTE") so I wouldn't judge here.

The CPU clock is also interesting. 1MHz and 2MHz can be seen as well. I assume 1MHz is the right, as the ROM dissasembly suggested that (because of the software TOD updating and the used value to generate IRQ with the help of VIA's timer).

Physical memory map

The physical memory address space of CLCD is 256K width (as I thought too from the usage of $FF00 from disassembly) and it's constructed like this:

Video ram means in the table: the LCD controller can only access this RAM (regardless of the MMU state, see later). It seems this RAM area is shared between the LCD controller and the CPU on the clock, half of the clock cycle signals the CPU to use the bus, on the other half the CPU, as we would expect.

I find a bit lost now, as the saved ROM images are 128K in size and not 96K though ... Maybe the "applications ROM socket" is filled on those together or such.

IMPORTANT: I really don't know what is the exact order of the ROM images (you can find them on this page): it's clear that kernal is the last. But I have no idea about the others. I picked a "random" order and it seems working, maybe it's not even important what's the order, as the ROM scan routine scans ROMs at boot-up and register things what it found (see later).

CPU memory map

From the view point of the CPU, the memory layout (CPU's address space is 64K, of course) is the following (I've already understood that partly via disassembling the KERNAL code, but not fully, eg the window of $4000 was quite clear for me):

More about the MMU (and the meaning of 'window') can be read later in this document.

I/O area and "top ROM"

As you could see from the table above, the top of the memory (F800-FFFF) from the CPU's view point is always "fixed", and it's KERNAL "top" code and I/O. This "top" area can be thought to be divided into two parts:

F800-F9FF is a read/write I/O area (even if you can "see" the ROM content there in the disassembly list, the CPU read/write I/O here, not the ROM. I don't know though if it's possible to read "the real ROM" by mapping the top 16K of the ROM into another window, like to $4000 in KERN mode). I guess, not fully decoded, so while there is 128 addresses for each VIAs, a VIA has only 16 registers, so there is some "memory echo" within that area. Of course it's true for ACIA as well, but it has only 4 registers.

FA00-FFFF functions as ROM in case of read access, the top of the KERNAL code, including the 65xx CPU RESET, NMI and IRQ vectors as well. However on write, special meaning is assumed as write only registers. AFAIK within a 128 byte long area, the same purpose is true for all bytes (maybe not the LCD controller though, but the others!), the address is not decoded further (but it seems this fact is not exploited by the KERNAL at least). MMU select/save/recall stuffs seems to be "dummywrite", ie you can write _any_ byte value, only the fact of write access counts, not the value itself ("don't care"). However the five MMU offsets registers are different: in these cases, the written value has important role to form the offset for the given window.

The table (column "u.s" is useful size, ie the guessed useful number of registers within the 128 bytes, ie VIAs have 16 registers for each, thus VIA#1's registers can be accessed from F800, F810, F820, etc too, as far as I can understand - for MMU registers there are even 128 possibilities to address a single register):

I guess, the "EXP I/O" areas is something like with the Commodore 64, reserved space for I/O expansions (cartridges, etc).

The MMU

The MMU works like the tables above shows. Windows are memory areas where the exact mapped memory is up to the programmer. Five offset registers are given (four for appl window #1-4 and one for kernal window). Their purposes to define an offset (in Kbyte granulity, to say differently: offset is shifted left by 10) the CPU address is added to (in "test" mode only the offset registers value are generated, unusable for normal operation, see later).

The purpose of the "top" fixed area is to provide an always-fixed region of executing hardware vectors (IRQ, RESET, NMI) and kernal entry points (the ROM code can map the lower addressed part before jumping there), and the same for I/O.

The purpose of the "bottom" fixed area is to provide a stable space for the important 65xx CPU constructions: the fixed position zero page, and the stack. Also, since it's 4K (and not only 0.5K for only ZP+stack) there is enough room for various other storage space for the operating system needs to be always there (both data and code), and even the default text video memory is there (from $800). This also means that you can provide different stack and/or zero page for the CPU, as the bottom part is always fixed to be the same memory (RAM) area.

The MMU also provided the ability to save the current mode and recall (restore) the last saved mode. This is an important feature, eg you can have IRQ while you use MMU in application mode, the top kernal code will save current mode, and sets up kernal mode before jumping to lower parts of the kernal (and after returning from IRQ, it restores the saved MMU mode). Of course it's just one example, there are more (eg calling kernal entry routines from outside of kernal).

The "test" mode is interesting, but not useful for normal operation: it simply causes the window offset registers are outputed for all addresses for the given CPU address window (for C000-F7FF there is a split at E000 to emit appl window #4 or kernal window). As you can see it cannot be even used normally (CPU wouldn't be execute normal opcodes etc) only for hardware check it can be useful. For writing an emulator, this mode can be ignored safely (in the CPU memory table, offsets 1-4 means the content of appl window registers, while offset 5 is the kernal window).

The MMU hasn't got RESET input, thus software must set it up after RESET. Since the 65xx RESET hardware vector is at the top memory, which is always the same (in all MMU modes) it's not a problem, the RESET vector and the initial code will always run correctly.

The MMU chip seems to be named as "5707 LCD MMU CHIP (gate array)".

The display

The LCD panel of CLCD has resolution of 480*128 and said to be excellent quality to its age. The LCD controller IC can drive it in character mode (with 6*8 or 8*8 character matrix, the first is used only on CLCD though, so it gives you 80*16 characters), or hi-res graphical mode (1bpp 480*128).

As a foreword / live test, you can try my emulator in the test mode (click on the link to learn more).

Registers of the LCD controller:

The generic description:

• XS is for X-Scroll register bits
• YS is for Y-Scroll register bits
• GRAPH is 1 for hi-res graphical mode, 0 for text mode
• ALT is 1 for producing high CHARSEL output, selects the upper 1K of the chargen ROM instead of the lower
• TEST is for some test mode, 1 means increment dot counter on each character rather than line (I don't emulate this though)
• CHRW selects the text mode width: 0 = six dots wide characters, 1 = eight dots wide characters
• CS80 and S40 selects the display module connected (so I guess it should be the very same always, maybe more CLCD models are planned, or more future machines at least using different LCD panels but with this LCD controller chip):
  • CS80 = 0 and S40 = 0: 40 * 6 (64 plex)
  • CS80 = 0 and S40 = 1: 40 * 8 (32 plex)
  • CS80 = 1 and S40 = 0: 80 * 16 (64 plex), it seems this is used with CLCD
  • CS80 = 1 and S40 = 1: this seems to be invalid

The LCD controller is capable of addressing the first 32K of RAM of CLCD (regardless of the MMU/window states, it always address the RAM directly, the first 32K of the physical address map) in the PHI1 phase of the system clock (CPU access it in PHI2). The first 32K of RAM is also named as "video" or "shared" memory because of this. The exact memory location where video RAM starts is selected by the XS and YS registers (see later). The standard location of (text) video RAM on CLCD is $800, which is a nice choice as the MMU provides 4K fixed RAM (in all modes) at the beginning of the CPU address space, so video RAM is always available for the softwares in this way. Of course, it's still possible to use video RAM at higher addresses (in the first 32K) but then you wouldn't be able to access it directly in some MMU modes. In text mode, only the lower 7 bits of the video RAM is used to determine the character, the MSB controls the inverse mode.

The ROM disassembly suggests that there is a KERNAL routine to set these registers up, and $FF83 & $FF84 registers are always set with the same value, allowing only the lower two bits to be set up by the caller, forcing bit 3 to be set. As these two registers have used/unused bits seems to be "inverted" to each other, the algorithm is understandable. Also, you can notice, that the panel type if "fixed" in this way (see above), also the CHRW (I have no idea what would happen on a real CLCD if you modify the panel type bits, but I guess CHRW can be modified without dangers, if you write register directly not with the kernal routine - without too much sense as charset is in ROM, thus is it not even emulated by my emulator) to be 6 pixel wide characters. The two lower bits is allowed to be programmed, which seems to mean the graphical/text mode, and the character set selection (in BASIC you can select as with the Commodore 64 from keyboard).

It seems LCD controller does not allow for custom character set, and dedicated ROM is assigned as the character generator ROM. However in general about the character set: I'm more or less guessing only.

The layout of the video RAM is somewhat complicated (especially with different CS80/S40 settings) if you try to find out/understand the situation, currently I don't try to explain it, but I provide the information I use with my emulator which seems to be work in text and graphical mode (I've tested that with entering into LCD BASIC and typing a simple program which draws an ellipse in graphical mode):

• YS contains the start of the video RAM in 128 bytes units (technically YS is two four bit registers but it seems it can be thought this way too)
• XS: best guess according various sources: low 7 bits are added to the start address of the video RAM, in gfx mode it is not used
• in text mode, every line is 128 bytes but only the first 80 bytes are used in each lines (2K RAM is needed, by default ROM softwares uses $0800 ... $0FFF).
• in graphical mode, every line is 64 bytes long but only 60 bytes are used in each lines (however not including this "4 bytes tails", the graphical mode is linear compared to eg Commodore 64), which means 8K of RAM is required. In BASIC the graphical screen is at $1000 (when BASIC start is moved to $3000) as far as I can see

It seems, the 128 bytes and 64 bytes length of display lines are for a simplier hardware/software, to keep byte counters at a power of number two.

Important problems with my emulator and understanding the hardware/software as well:

• It seems the KERNAL ROM image contains a 6*8 mode character set (the "layout of characters" seems to be quite generic "Commodore screen codes") at $F700 but it's only the "upper case" charset. The problem: I was not able to find the other character set anywhere in the available ROM images (if you're interested, here is the funny "ASCII art" dump of the KERNAL, this was the method I found it. I couldn't find the other character set with similar method in any of the available ROM images). That's why I use an odd solution: I picked up a 6*8 matrix of lower case characters from some random web page. So they are not the actual matrices of CLCD. Then I've patched the alternate charset from the original upper-case only with thep with this "alien data" (from the example of C64 at least, the two charset has some other differences too, which is not covered by my emulator currently). I guess, the character set for real is stored in a separated ROM which I have no image for, and the kernal ROM only contains a charset to be used by the software, ie rendering characters in graphical mode with BASIC, or so.
• I am still not sure the update frequency of the LCD display. Unlike with a TV signal (where you are not so free to use different horizontal/vertical retrace frequencies for example) it depends on the display panel as well - I guess. My emulator currently refresh the screen after a given number of CPU cycles, which is not correct for a real hardware of course. If we assume that CPU frequency is exactly 1MHz, and LCD controller only uses the bus in every PHI1 state, this would mean roughly 1 million pixels per seconds in graphical mode. Since screen in graphical mode consists of 60*128 = 7680 bytes (not 8K, because of the "tails") it's about 130FPS ... Of course it's very possible that not every PHI1 "slots" are used to read a byte, and it must be noted that some kind of LCD panel access/etc cycle must be respected, also in text mode, character shape information is fetched too. To be short: I have no idea :)

The exact name of the LCD controller seems to be "5706 LCD controller chip (gate array)", however eg "Secret weapons of Commodore" page mentiones 8653 (not to be confused with 8563!). That page is also interesting because it shows on a picture of the PCB an IC labeled as some kind of chargen ROM. As I've mentioned above, I have serious problem with finding the other character set, and I only found something in the KERNAL ROM image. Maybe the character set for real is stored in separated ROM I have no ROM image file of?

Battery & "sleep mode"

CLCD is battery powered, even if "switched off" (from the user point of view, at last with not flat batteries) the content of the RAM is preserved. CLCD tries hard to check the "state" of the machine as valid to distinguish valid "shutdown" and "fresh power-on" events. The primary "storage" of the CLCD is RAM disk like entity (see later) unless if you connect a real disk drive (CLCD has IEC bus connector). As far as I can understand even the initial ROM scanning (see later again) forms ROM checksums to be ensure the machine state is intact.

CLCD is able to detect if battery is low, more about this at the section of VIAs.

ACIA and serial stuff

CLCD contains a 65C51 ACIA chip at $F980. The built-in TERMINAL application can use it, and also some sources mention that CLCD has true serial port, and even an (auto answer?) modem. I haven't tried to expand my knowledge on this area yet.

The VIAs

CLCD contains two 65C22 VIAs. I will name them as VIA1 (the one from $F800) and VIA2 (from $F880). Note: information on VIAs, and the keyboard are quite weak and only based on my guess-work, which can be fair lower accurate than things got as information for CBM engineers, like some MMU "secret". It's even possible something only seems to be true because it works this way for some reason in my emulator and not on the real machine (but since the emulator tries to emulate the hardware and the software is the original ROM images, some truth should be there, still) ...

[O] and [I] means the default configured direction of I/O in DDR registers (I haven't spent too much energy yet to deal with VIA#2 in general ...). For low-active signals there is "/" sign before the name.

/PowerOn signal on port B of VIA#1 seems to be important as this is one of the first things kernal does after reset before the whole VIA initialization stuff: sets DDR as output for that single pin with output value of zero. Maybe that would control the power on a real CLCD: you have some kind of push button to "turn on" which gives power for the system for the time you press the button. So one of the first thing the machine need to do is to initialize this output which will instruct an electronical switch to turn on, before you release the button. In this way the machine can even turn itself off by setting /PowerOn to high-inactive (this is a low active signal).

Important to note about the Shift register of VIA#1, which is used as a 16 bit wide input port, most likely to optimize the usage of "real" VIA ports. Though keyboard rows are selected for scan through VIA#1 port A (bit is clear = row is elected), the actual read of the state of the selected row(s) are done through the shift register of VIA#1! Also note, that actually it's a 16 bit value to read, the first byte is the state of the keyboard matrix for the selected row(s), the next 8 bits though are mixed purpose:

Bits marked with "??" are quite interesting ones. Setting any of them to '1' seems to freeze my emulator (after clearing the screen and/or scroll it rapidly), they should be "power sense" and "no battery" signals as far as I can understand, but anyway, setting any or all of them seems to result a non-working situation. As "battery is low" also not so nice to have (and it won't occur too much for a software based emulator) I think it's fair enough to say to leave three highest bits as zero in an emulator always, and only feed the lower 5 bits for the VIA emulation.

RTC

CLCD contains an RTC chip, it's OKI MSM58321, which has got a 4 bit wide shared data/address bus, which makes it easy to integrate with the use of minimal number of VIA pins. See section "The VIAs" for more information, name of the signals:

• D0-D3: the address/data bus
• WR: WRITE signal for the RTC (writes latched register from D0-D3 as input)
• RD: READ signal for the RTC (reads latched register, outputing it onto D0-D3)
• AW: ADDRESS WRITE signal for the RTC (D0-D3 is latched inside the RTC chip as selected register address)
• BZ: I guess it's the /BUSY output of the RTC?

WR, RD and AW are high level (not edge) sensitive inputs of the RTC. Bus of D0-D3 is open drain in case of output (during read) according the specification. This may be the key that VIA can read RTC registers, regardless of its DDR (VIA#2 port A is configured as output constantly, but still, it's also used meanwhile to read data!). Please note that in case of port B it wouldn't work (VIA port B has different behaviour in this case compared to port A).

Please refer the data sheet of OKI MSM58321. Years are shown as 0 being 1984, thus there will be Commodore LCD Y2K-style problems in 2084 :)

One interesting problem: according to the data sheet, the registers used for month and day of the month should be swapped ... I don't know if it's a KERNAL bug, or another chip (revision?) was used with different register layout ... In my emulator I used the order to have meaningful date display in SHELL. BZ (BUSY) is not even emulated by my emulator, and I guess it's not even needed (as the KERNAL seems to read then compare all registers if was no time update during the read).

My emulator currently does not support writing the RTC registers (so it won't work in SHELL to set the clock), however the time/date should be correct as it gets values from clock of your computer via JavaScript date/time functions.

Sound

Some sources state, there is no sound at all. However the VIA pin usage suggests "beeper". Anyway, don't think about a complex stuff like a SID, even if there is sound, it's intended only for beeping or so. Anyway, as we know from ZX Spectrum, 1 bit should be enough for everyone :)

As Timer2 of VIA2 is seems to be used as the beeper output, sound at a programmed frequency can be produced without using the CPU itself.

My emulator currently does not support sound though.

The keyboard

CLCD's keyboard is quite similar to the one of the Commodore Plus/4, however there are few differences, more keys (eight function keys) and some matrix differences. Also the most notable thing is that "special" keys (especially modifier keys) are not part of the matrix but handled separately. This description and also the generic way to read the state of the matrix can be found in section "The VIAs" above.

This really ugly table tries to demonstrate the keyboard matrix (based on my work with checking the visible (or functional) result of each sel/sr combination in my emulator):

The order of bits (0...7 numbers) can be though as being odd, etc, but it was the first version I checked the key events with my emulator (yet in X-Y system not with bit masks), and I am lazy to re-order the table now :) "Linesel" is the value should be written to VIA#1 port A (here, bit value of 0 means selected), and the "read value" can be read (here, bit value of 1 means the pressed state) for selected line(s) then through the SR of VIA#1 if the usual matrix read request transition is done on VIA#1 port B bit 0 (see the VIAs section above for more description on this topic).

More-or-less correct VIA SR implementation is needed for an emulator, as VIA's SR has the feature to start the actual shift-in (or shift-out, but not in our case) on read/write SR register and then you can read the result later. As the shift-in operation reads another data after the "VIA#1 port B bit 0" transition, it's esential to emulate this well to be able to use the keyboard.

Also, some special keys are not found within the generic matrix, but read separately, see the VIAs section (again).

Some KERNAL code/data related to the keyboard:

• keyboard decoding data
• kernal scnkey
• reads kbd state (note the "via1 port B bit 0 transition" stuff)

IEC bus

As you can see in section "The VIAs", total of five pins from VIA#1 port B is used for the IEC bus. The position and direction of bits seems to be similar as with port A of CIA#2 in Commodore 64.

The KERNAL

If you donwload the zip file containing the ROM images, you'll find kernal with the file name of kizapr-u102.bin.

You can see my disassembly try here, but please note: many parts are wrongly interpreted as code instead of data or vice versa. I mainly corrected this and commented some parts and even inserted meaningful labels which were interesting for me during my detective work, and it was hard to remember for, by heart :)

KERNAL (as on CBM machines in general) is very important as its code is executed on power-up/reset, also the hardware vectors (which includes IRQ and NMI too, not just RESET) are there. Note, that in all MMU modes, the top of the kernal is always there! It's an important fact for two reasons:

1. the MMU chip does not have a RESET pin, so the MMU state is undefined after power-up
2. you can have IRQs enabled while you alter MMU settings without a crash as that part of kernal cannot be "mapped out" ever

The KERNAL's first task is to set up the MMU mode to be kernal mode as the state can't be known for sure. It's needed to access the lower parts of the kernal too, not just the "top area".

The kernal's top area also contain the usual Commodore standard kernal entry points. Please note that compared with eg Commodore 64 the major difference that on Commodore LCD you quite often see "two step" call. I mean: calling a given kernal entry first hits a code which sets up the MMU to access the lower part of the kernal and only then it will jump there. Here, the Commodore LCD's MMU is really nice as it provides a "save current MMU mode" and a "recall last saved MMU mode" functions. It's important as the routines may be called from various MMU modes. The IRQ/NMI vector works also like this: you can't tell what is the exact MMU mode when you get an IRQ.

Initialization

Major feature of the CLCD is the ability to remember the "state" of the machine including the content of the RAM disk ("virtual 1541"). This is possible as RAM is always powered from battery even if the machine is "switched off". From the KERNAL disassembly I have confusing ideas on this area. It seems CLCD does not care too much if the content of the memory is "invalid" (ie a "cold" boot when all the memory is empty, which is always the case with my JavaScript based emulator of course). It merely displays some warning, and simply skips the proper initialization of the machine which cause serious problems later (eg you see PI signs instead of numbers in BASIC, virtual 1541 does not work, and other anomalies. Maybe the intent from the developers was the following: let people to continue even if state is not intact in the hope that some data can be still there and can be rescued, but give a warning about the situation. And indeed, in this case some warnings are displayed and user even needs to press a key to continue to be sure they can see it before SHELL clears the screen. I am not really sure what user can do if they want a proper initialization anyway after an event like this, maybe that keyboard combination (C= SHIFT STOP at the same time).

Currently I have the ugly solution in my emulator to patch the KERNAL image to always force the full initialization. It would be interesting to know how it is done on a real CLCD: it's possible there too, eg battery is totally flat (memory content is not valid), after the first power on, or after a misbehaving software which corrupts the memory ... As far as I can tell, there are some sings in the KERNAL to use an interesting key combination (C=, SHIFT, STOP pressed at the same time?) during the power up, which forces the initialization though.

ROM installing on boot-up

Foreword: for a "live" demo to demonstrate the process (and the graphical mode of the LCD controller) with my own ROM installed, check this page out.

The information on software (in contrast of hardware, where I got help from some people, like with the MMU) is enterly based on my own knowledge only got by reading and trying to understand the disassembly of the kernal. As usual I can be wrong here, any corrections, additions are welcomed as feedback.

Commodore LCD kernal scans the available ROMs on start up. The kernal uses the machine with MMU state of "kernal mode" (no wonder the name ...). During the scan, the kernal window from $4000 is used to "page in" the possible memory locations where system ROMs can exist. So you can even remove ROMs (other than the kernal, of course) and the machine will work, however only with kernal you'll dropped into monitor mode (the experience got with my emulator).

The ROM scanning itself means altering the kernal offset register of the MMU to be able to see memory areas from $20000 in 16K steps (8 choices). It tries the find the string "Commodore LCD" (without the quote marks of course) at offset of 8. Even the kernal has this identifier, so it will find "itself" and the identifier string of the kernal itself is used to compare the values in the kernal window. On each found ROM images simple (16 bit) checksum is calculated, byte at offset 4 tells how many Kbytes should be used to form the checksum. I don't know the purpose of the other bytes in the very first 8 bytes beside the byte at offset 4.

The ROM images and their first 8 bytes:

Just to note: in case of 04-12-85 byte sequence it can be even date in packed BCD format (if month-day-year is assumed with year of '85 and one day earlier than the file names suggests), almost the same as in the file names (I don't know how these file names were choosen by people (Bil, I guess) who saved the ROM images), but then what's up with DD DD DD? As I've already mentioned, I don't know the exact order ("phys.addr") of the ROM images. One thing is sure: the KERNAL is at the top of the system address space, so it must be $38000. In my emulator currently I load ROMs in the order as you can see in the table, KERNAL from $38000, and every ROM images at an address 32K lower than the previous. However I still use the question marks as this is probably not the "real" order (but it seems to work, and maybe the exact order is not even important? - detected and used then by the ROM scanning routine in the given order).

I can't tell why two ROM images have not used space and exactly from offset $6480 for both ...

The 16K steps rule may signal the idea that you can have smaller but multiple ROMs, though the default ROM images seems to have only the identifier string and "application directory" only at the beginning of every images, and those images are 32K in size.

After the identifier string a "directory" follows which describes the applications in this ROM. I guess this is used later by the menu system (named "SHELL") to show applications. As far as I can understand the structure of this "directory" is the following:

• the first byte indicates the size of the entry (which includes six bytes - including this byte as well - and the size of the name itself), OR it can be zero which indicates no more directory entry in this ROM.
• then five bytes follows, I can't really understand their exact purpose but the last two bytes seems to form a word and idicates the entry point of the given software. I know only a single effect of the second byte: if it's $10 or $20, the SHELL won't show those entries, no wonder SHELL itself and MONITOR is not shown in the SHELL app menu.
• then name follows, there is no end-of-name indicator, as size of the entry byte shows the size of the name if you substract six (the six bytes before each name when you include the size byte itself as well) from it. It seems SHELL does not use the "extension" in the name (.MON, .CMD, etc) directly, however there are some signs that extensions are used to "bind" a given extension to an application. Eg: BASIC.BAS, the SHELL will show "BASIC" but any file has extension of .BAS will be assumed to be BASIC program. Or so ... You can try that in SHELL by typing example.bas, BASIC app will open with trying example.bas to be loaded ...

Applications in various ROM images:

Of course KERNAL ROM has the important role that besides of the "applications" it also contains the KERNAL itself (so it contains only two relatively small applications in addition compared to the others).

It seems the content of the X register is important when an application is started by jumping on its entry point. I don't know the exact values yet, but it seems zero means the "boot time" so when the ROM scan utility finds ROMs and applications, then every application is called with X=0. Later, other X register values are used, so you can have an "init" routine called only on "boot time" only by inspecting the value of X.

Also note, that there are entry point addresses ("START" in the table) like around $4000 in "BASIC ROM", while even $E280 and such in others. As far as I can imagine this is because there can be different MMU modes/used windows to execute a given application eg, apps in KERNAL (monitor for example) seems to be logical to run in kernal MMU mode anyway.

The monitor software ("MONITOR.MON")

Interestingly, the monitor itself is not snown by the SHELL. However you can access it at least four different ways (according to my experience with my emulator):

1. In SHELL, type monitor, then press return
2. In BASIC, type monitor, then press return
3. Remove all ROM images from the emulator but the kernal
4. Execute a BRK opcode, and kernal puts you into monitor mode

MONITOR.MON is in the KERNAL image, so it's always available even if you remove all of the ROMs (or images, in the emulator) but the kernal. That's why you will be dropped into monitor mode if no other ROMs are found: there is no other command to be executed, eg the usual menu system (SHELL, see later) is in another ROM (image).

The MONITOR seems to be similar to Commodore 128's monitor (at least I can tell, I am not really familiar with the C128 ...), maybe the C128's one based on the CLCD's code, at least this is said for BASIC (see later) so I assume this can be true in this situation as well.

One thing to note: in BASIC, if you activate the MONITOR, the scroll of the screen ignores the last line (function keys' bar) but if you activate from the SHELL, it's not. That's understandable, as apps launched from the SHELL are expected to set up its own screen (ie, clear the screen, display what it wants) but MONITOR is not this kind of app. Maybe it was not even designed to be able to start "manually" from SHELL, but still you can do that.

The command ("COMMAND.CMD") application

Besides of monitor (MONITOR.MON) it's the other application which is in the kernal ROM.

I guess, its function is executing commands (whooo, what a surprise), and in the SHELL what you type into the SHELL "command line" is also executed with this (maybe also the filename extension and application bind is handled here). The disassembly of this part is interesting.

RAM disk (or "RAM file system") aka "virtual 1541"

CLCD has the interesting concept so it can be usable even without a "real" disk drive. Of course in theory you can connect an 1541 or similar (CLCD has serial IEC bus) but then the portable nature wouldn't be too nice anymore - unless with the planned 1561 which is also battery powered. Anyway ...

The trick is to use the RAM as "disk drive" and the KERNAL even emulates some kind of functionality (like directory listing) of a real disk drive. As the CLCD always powers the RAM from battery, it will preserve the content (unless the battery is flat). This is the kernal part creates the directory listing.

The virtual 1541 can be accessed as the device 1, ie LOAD "$",1 loads the directory (but you should use the DIRECTORY command as it won't overwrite the BASIC program in the memory).

Even "memopad" application works this way: what you type there is saved, and loaded back if you start memopad again (it seems the file name would be: MEMO.MEM). This way you have some kind of "multitask feeling", it feels like it is a background application having your data all the time.

The "menu system" aka the shell ("SHELL.SHL")

SHELL is the "menu system" you'll see after your CLCD boots up. It resides in the ROM image named as "sizapr-u103.bin" which also contains the BASIC (v3.6) interpreter. SHELL provides:

• time/date printout
  I have the suspect that CLCD contains an RTC chip (my reasons to think this is written at the "Summary" section). My current emulator unable to provide an RTC emulation because of the lack of information, so some meaningless date/time is shown.
• a "commodore lcd computer" printout
• number of used blocks
  I guess this is the used number disk blocks on the default configured storage which is the RAM disk ("virtual 1541") by default.
• list of built in applications (it does not show "itself"), you can use the cursor keys to navigate and return to process
  The content of this field is the result of ROM scanning, so it's not a fixed list stored in the KERNAL itself
• directory listing
  IMHO it'd display the content (directory) of the selected default storage, which is the RAM disk by default ("virtual 1541").
• command line
  This is the line where the cursor blinks, you can type here and press RETURN to execute. I guess the given command is executed with the COMMAND.CMD program, which is in the "directory" of the kernal image and its entry is also shown by the SHELL itself.
• function key bar
  Please read the next section about the "function key bar"

Besides the "what you can see", the functionality of the SHELL:

• provides a menu for the user to select an application
• inform user about various things (date, time, used blocks, directory listing, etc)
• provides some common file operations (see function key bar)

I wrote about the file name extension - application binding. Now you can try the theory, type something like this into the SHELL: example.bas

Tasks provided by functions keys can be also accessed with typing the name, ie F6 for RS-232 settings, but you can also type rs-232 (and press RETURN at the end, of course).

The function key bar display line & function keys

In various applications you can see inverse "labels" at the bottom of the screen. It shows the function of the F1...F8 function keys. Usually F8 is the exit in many situations, though not in SHELL (as you can't exit from the SHELL as it is the first application running).

In the SHELL, the function keys are system settings or for invoking often used functions. The list:

• F1: RENAME
• F2: COPY
• F3: DIRECTORY
• F4: SCRATCH
• F5: CLOCK
  allows you to set the clock
• F6: RS-232
  allows you to set up the serial settings, some settings here is about the ACIA configuration
• F7: SYSTEM
  various system settings

In case of the SHELL and F6, F7, you have multiple choices to set up, so another function key bar is displayed. You can use the functions keys to navigate between settings, but you can also use the cursor left/right to do this (or the Fx keys). F8 exists. In one setting you can use the cursor up/down keys, and no need to use RETURN or whatever to select a setting, simply leave the inversed item where you want and navigate away, or exit.

In other applications the function key bar is different of course. Usually the F8 means there to exit to the SHELL. Interestingly there is a POPUP mode (at least in BASIC) which is some kind of "multi tasking" like feeling: if you choose MEMOPAD there, you can use the MEMOPAD without exiting from BASIC first.

Again: I can't tell too much about the file functions as it seems I have problem with storing any file on the RAM disk, so I can't test it too much. Maybe this is also the reason as the nice "popup" feature does not show the last typed text in memopad, as it would load the text back from the RAM disk (?).

BASIC ("BASIC.BAS") as also an application

On CLCD BASIC interpreter is a 'regular' application as others, not the default mode as with usual CBM micros. According to the screen, it's "COMMODORE LCD BASIC V3.6". Interesting feature compared to other CBM BASICs is the existence of the function key bar display at the last line. You can use command "EXIT" to get back into the SHELL. Since RESET vector points to $FA07 in LCD kernal, you can "reset" the machine with the following BASIC command: SYS 64007. You can try to "shut down" the machine with: POKE 63488,255 which would make the /POWERON signal high (inactive). Currently my emulator only alerts the user about power-off but accepting the alert window will cause to continue the emulation. A real Commodore LCD would lost its power at this point, I guess (without a "clean shut down" though, to preserve the state). If you click on the RESET button at this point, odd things will/can happen, I am not exactly sure why. Of course reloading the emulator page works, so it must be something about the RAM content, and state information.

Because of the habit (I guess) the upper case charset is used by default in BASIC in contrast of other applications (including the SHELL itself) of the CLCD.

It seems the BASIC memory starts at $1001 (right after the text video RAM default location). LCD BASIC can use the graphical mode (of course no colours), I was able to use GRAPHIC and CIRCLE in a short BASIC program to draw an ellipse on the screen. It seems, in graphical mode the BASIC memory start is shifted to address $3001 (since gfx screen needs $2000 bytes of RAM, the $2000 increment in start address seems to be logical).

Short test program to test graphical mode:

10 GRAPHIC1,1
20 CIRCLE,240,64,230,60
30 GET A$
40 IF A$="" THEN 30
50 GRAPHIC0

It's said that LCD BASIC can run BASIC 7 programs if it does not contain platform specific SYS/PEEK/POKE and features about colours, etc (as those cannot be implemented on the CLCD, it has monochrome LCD display). I can't comment that further too much. BASIC is in a separated ROM (or only ROM image file?) contains only the SHELL itself other than BASIC. Commodore-128's (V7) BASIC is said to be the further developed LCD BASIC, so it can answer questions like why "unimplemented command error" for some C128 BASIC keywords like "OFF", maybe it was for the CLCD originally to switch off the machine, turn display/the machine/something OFF (I've tried the "OFF" in LCD BASIC, nothing happened - but at least no error unlike on the C128 - but it can be the limitation of my emulator).

About disk handling: wikipedia says about the drive status: Commodore BASIC versions 4.0 and later provide a pseudo-variable referred to as DS$. However even with LCD BASIC (3.6) seems to support this feature, try it: PRINT DS$. As I've stated before, virtual 1541 is emulated as device 1 (would be tape on C64), DLOAD, DIRECTORY and similar commands access that as well by default (but if you change the default storage in the SHELL with F7 -> F4 then those commands would use the device you selects there).

You can save BASIC programs with any name, but it's worth to use .BAS "extension" as then SHELL can be used to start it directly with the .BAS ~ BASIC "filename extension binding".

Memopad (MEMOPAD.MEM)

Memopad is a simple utility to give some short text as a reminder. It has two interesging features:

• You don't need to load/save content manually. On disk (by default the virtual 1541 disk) it's stored as filename of MEMO.MEM. As it always tried to load the file first, you may have the feeling it's always running in the "background" though, so it's quite ideal to use as a reminder utility, indeed. It's interesting to note that you can force mempad to use another file, with the "filename extension binding": type a filename with the extension of .MEM at the SHELL. But I guess this is not the intended use of this application :)
• Most applications (even BASIC) allows you to start memopad without exiting first (the "normal" usage is from the SHELL as the "main" application). In BASIC it's called "POPUP", but eg word processor has the "OTHER APP" function key bar title for these kind of usage. It's really nince and also creates the illusion that memopad always run in the background as some kind of light multitasking environment.

Calculator (CALC.DMB)

Calculator application is a (surprise!) calculator. Like the MEMOPAD it's possible to start it from another application before exiting that first. Calculator has many input and format modes. It does not use files too much, so while it's possible to launch it with the filename extension binding method, the given file won't be accessed at all.

Word processor (WORDPROC.WPR) and spreadsheet (CALCSHEET.SPR) applications

I am not a great fan or user of word processors and/or spreadsheet applications too much in general (not only on CLCD) so I can't say too much. However one interesting thing that CLCD allows you to use both of these at the same time on splitted screen! That's also one reason I mention these in one section. An early newspaper article mention that CLCD's spreadsheet application is much faster than Visio (?) or Lotus-1-2-3 on IBM PC, and even has more features.

Specification changelog/history

Only major changes (or the ones can be important) are shown here.

• 2014/Jan/22: more Commodore LCD versions & other (future?) emulators
• 2014/Jan/21: about the machine initialization problems
• 2014/Jan/18: published