@davidgro That was a different thing. You can write or read from the physical memory address 0 even on the systems of the today - except that practically all the OS-es are using their paging or memory management to make that address unreeachable. Actually, as far I can remember, on Linux, the addresses between 0 - 65535 are mapped unreachable. If try to write them, you will get SIGSEGV. This is because a memory page is 4K, that is the granularity of the memory permissions. Beside that, we also need SIGSEGV (which would map to a "null pointer dereference" or analog) if it actually tried to access the part of a larger struct (what would be visible as an access to a non-zero, but very small memory address).
C64 had no memory protection, you could read or write anywhere where you wanted. Although it had memory-mapped I/O, meaning that instead of bus-level port communication, all the IO, i.e. communication of the CPU with the chips of the mainboard, happened as if they would be memory. Some chip happily crashed the system on such writes, particularly the CIA did it (general purpose I/O chip and hw clock) for not enough well thought memory operations in the $DC00 - $DFFF range.
You could happily write into 0 on C64. Actually, on the address 1, you could access the chip select pin of some RAM chips, meaning that you could with that switch from the basic ROM into an additional RAM area. Writing to the 0 byte did not had any on the spot visible effect on my experiments, but today I read in the docs, it had actually effect to the GPIO ports related to the memory chips managed at the address 1.
Actually, c64 went even more: the first page, i.e. the addresses between 0-255, very accessible a bit faster, because they required a lesser amount of CPU and data bus cycles. Very important registers, used for important operations, were there.
However, this all is about the C64 hardware. The C64 basic v2.0, which was written by the microsoft, quickly evaporating all my youth nostalgy, had nothing similar to the NULL (of C) or null (of Java). It not even had an "unset", "undefined" or similar type. The 3 types it had, were: 32-bit floating point, 16-bit integer and 0-254 byte long string.
@forestbeasts @p4rzivalrp2 Quite honestly, I am a bit disappointed on wayland - it promises a fast X, but it does not provide it. The cause of the slow X was not that it is an old monster, the cause was the much lesser developer resources. Wayland has even much lesser.