I’m the other person in the world who cares where that other byte is. After packing so much into a single byte into VCS programs lately I’ve come to appreciate how useful a byte is. No byte left behind!!! 21:15 twos compliment is better than one compliment 😅
No you're not. I knew about the sentinel byte and its purpose, because it shows up in other BASIC variants that trace their lineage to the original Microsot BASIC. Now we know that an empty BASIC program fits in only 3 bytes!
The Atari 800 only had 48K of RAM, but 37K was available to the user in BASIC, almost as much as the C64's 38K. A 64K TRS-80 CoCo had 41K available in BASIC.
The C64 designers could have seemingly easily put the BASIC ROM at $B000-$CFFF thus freeing up 4K of RAM at $A000-$AFFF, leaving 42K RAM contiguous for BASIC. But they didn't, and I'm still not sure why. As a young machine language learner I always appreciated that 4K of free RAM at $C000 that was safe from BASIC's dynamic variable allocation and garbage cleanup; did they put it there for us hobbyists? Or was there another reason? Or... no reason?
Thank you for this great trip down memory lane Robin! While we are on the subject, perhaps there is an opportunity to disassemble selected parts of the BASIC ROM and examine the operation of the interpreter as it does its work of parsing and executing program lines. I would also enjoy some of that MSX content you proposed. It figures that the same folks who would entertain the notion of standards in computing would use a "Zed-eighty" processor. Preposterous!
Starting from 3. 5, I was envious of all that BASIC RAM even if it wasn't the full 64. I always wondered what the reason for ? FRE(0) returned 2 bytes less was. Now I know :)
A 4164-IC (64KBit) was priced at around $50 USD by 1981. That is $400 for the total of 64KByte just for the RAM-ICs alone. Prices dropped very quickly though. By 1985, its been 10$ USD for 64KBit. Today a 4164 costs around 30ct.
@@James_T_Quirk $1299 including diskdrive and monitor...otherwise you paid too much. I got my first used C64 back in '87 including a diskdrive, a green monitor and about 50 Floppies ...My parents paid around 1000DM (around $600 USD by that time)
In 1982, 2 Weeks after Release, here in Australia, $1299, C64, $ 299 for a Datasette Bundle of Commodore Tapes & "Telengard" a D&D Game, the 802 Printer Cost 799, I waited for a 1541 as it was 1199, I bought a 1541 a Couple of years later @$399, I was already using Tape on Tandy, so it was no biggie @the Time .. & My Parents didn't pay for it, I did as I was working for a Car Parts Wholesaler in Melbourne ( I had used a computer, they were computerizing @ the time, So Tandy & C64 knowledge was worth something), in another State from Mum&Dad @@monarch73
oh this is gonna be great, Always wondered what that random number was about. Cool thing that the system actually calculates the memory and its not hardcoded. Figured it out while coding my emulator, it had 64k of free memory until it got more accurate
This video is very educational! It answers a lot of questions about C64 BASIC and RAM usage. Plus you throw in a new SYS command at the beginning I never knew before. Thank you!
It depends... some things were genius (probably thought of when they were not in a rush), and others were total hacks when they were in a OMG WE NEED TO GET THIS THING OUT, AND CHEAP phase 😄
I wish they had found a way to map the colour RAM into main memory so it could be relocated on the fly, then it could be double -buffered and much faster and larger areas of scrolling would be possible. Add arbitrary start addresses for screen/colour ram and the sky's the limit.
Somewhere in my skull the 38911 BASIC BYTES FREE message is basically burned in there permanently just like it was on the 1702 monitor at the Canadian tire near me, back in the day.
OMG! Don’t get me started on that KiB nonsense. A megabyte is a megabyte is a megabyte and it’s always going to be 1024. That’s just how the world works! 😂
My pet peeve is the metric system being base-10. It's an arbitrary number, a combination of non-consecutive primes. Use a prime instead. No, use the lowest prime. No, too clumsy. Well, use a power of the lowest prime. Base 8? Base 16? 16 = 2**4. Four is a power of two also. Perfect. There you go.
Regarding the IBM PC's 16KB variant, that 16KB was soldered to the motherboard (as 9 chips (8 data + 1 parity)), but there were sockets to add additional chips to bring it up to the 64KB variant. You could add more via ISA expansion cards, but those would have cost a small fortune in RAM chips, but could in principle get you up to 640KB (the rest of the 1MB address space being occupied by I/O, VRAM, and the BIOS). There was a later version of the motherboard that came with 64KB and could be expanded up to 256KB, too.
It would be interesting to make a similar video with the TI 99/4A's very odd memory layout. If you thought bank switching ROM out to get the full 64K of RAM is kind of a kludge, the 99/4A only has 256 bytes of CPU memory available in its standard configuration, but bills itself as a 16K computer, all of which is video RAM that the CPU can't address directly. Ahh, the good ol' days.
A friend's father had one. Not only the computer but also the big box for extension slots and one 5¼" disk drive. My friend and his brother later got a Schneider CPC 464 (Amstrad CPC, rebranded). The TI then was used to control somethin. Until the mid 1990ies it was replaced by a PC running Windows 95. I don't know if the TI was broken or if it still exists.
@@8_Bit It's not bizarre but super interesting. Apart from a CPU with a minicomputer instruction set (orthogonal, inspired by the DEC PDP and in its turn inspired the SUN SPARC) it has an interpreter for a different kind of machine language (GPL) in a special type of serial ROM's. This interpreter was a novel idea that we see today in Java for instance. And it's rather easy to add 32K of 16bits RAM to the console for some "blinding" performance. Yes I am a TI enthusiast 🙂
38k was a godsend, I started on Tandy level 1 model 1 with 2k, I bought a C64 2 weeks after it released, C64 was a improvement, is a understatement, As pointed out in this Video After a few years, Coders started reclaiming these Higher Memory Locations, Swapping out Basic/Kernal You did this for MACHINE LANGUAGE Programs, you still need to rewrite a smaller section of Code to handle I/O & Character Set, Screen but you could get access to more memory for main code, it has now been more than 40 years, with Some of the Expansions currently available, the C64 will still be around for next 40 years..
Have had a lot of people who don't write C64 software try and tell me that a C64 only has 38K of RAM available, whether to BASIC programs or machine code.
@@8_Bit Some of the time yes, but also sometimes C64 users saying X or Y game isn't possible because there isn't enough RAM. And to be honest, almost all my games would have fit in 38K anyway, with no real attention paid to being particularly efficient with memory usage - it's a huge amount.
@@arlasoft Yes, it's amazing how far RAM can go when coding in machine language. Even 8K (regular cartridge size) seems huge unless you have a lot of graphics eating up memory.
Back in the day, I used SpeedScript, from Compute! as my word processor. It switches out BASIC ROM when started, giving a text area of 43520 bytes. I used that to show friends who claimed my computer didn't have 64K of memory to show them it had more than 38K...
With some machine subroutines, even BASIC programs can use 64 K (not for BASIC code or variables, but for sprite or screen data, character sets, etc.).
16-bit Show and Tell, here we go! I've been thinking about doing Amiga videos for ages but don't really know what to cover. Top contender: me complaining about how bad AmigaBASIC is...
@@TheUtuber999 I bought an Amiga 500 in 1988 and did have a lot of fun years using it. But I didn't sell (or give away) my C64 and kept using it too. If I made any Amiga videos it would be about my experiences using it in the '80s and '90s I think. The C64 ties into some of that too.
@@8_Bit Yeah, I've owned an Amiga 500 and 1200. Loved creating Mod files with Protracker. Also owned various other Commodore computers, but pretty much settled on my 64-C these days.
Thank you Robin! I have wondered about that lost byte for about 40 years. And the explanation is fully logical, thinking about it. I'm going to sleep well tonight!
Strange that with the high RAM prizes back in the days, They did not go for 48kB of RAM. The BASIC and KERNAL ROMs did not have to be in RAM. Also apparantly no banking. Our 8-bit machine had 256 banks of 8kB above the base 32kB of RAM (true RAM, not RAM holding ROM code). So you could make it use 2080 kB of RAM.
Well, the correct amount of free RAM is 38909 because any BASIC program will end with a "00 00" pointer to the next line. So 38912 - 1 (the 00 at 0x800) -2 (the said end pointer) = 38909. The computer will never skip the final 00 00.
The space available for a BASIC program is 38911 bytes free, and there's 38909 bytes left once the null 00 00 pointer is put in. But if you're going to argue that any BASIC program will have those end bytes, then you should also argue that any BASIC program will have a line number (2 more bytes), a pointer to the final null pointer (2 more bytes), and at least one token (one byte), and that line's null terminator (one byte) so then the correct amount of free RAM is 38903. But I think that's getting kind of silly.
Nice video and good to see the MSX featured as well! Even though the MSX is Z80 based, if I recall correctly, a BASIC program is stored in RAM pretty much the same as on a C64 (although the BASIC tokens themselves differ), which goes to show that the BASIC of both platforms share their origins at Microsoft. On an MSX1 (like the Sony Hitbit you showed), there is 64kB of total RAM, but the BIOS and BASIC ROMs are both much larger than on a C64, namely 16kB. That means that there is at most 32kB of RAM available to BASIC directly. And just like with the C64, there is RAM, but this time at the top of the address space, that is reserved for system routines, variables, etc. The amount of memory available to BASIC according to the fre() function is calculated exactly the same way. It takes two pointers and subtracts them from eachother. Those 28815 bytes shown on the HitBit are only available when there are no peripherals attached that take up a bit of their own system space. For instance, if you hook up a floppy drive to an MSX, the DISK BASIC, which gets its own ROM space (but not in the same physical addressing space as the BIOS and BASIC ROMs), eats up a little bit of memory for its variables, but also for 2 FCBs (DISK ROM contains the BDOS part of the MSX-DOS, which is basically a Z80 implementation of MS-DOS 1.x, which in turn was a 16-bit clone of CP/M). An interesting feat of the MSX standard is its slot-based design. In fact, in most implementations (there are exceptions, and these usually deviate from the standard a bit), the BIOS and BASIC ROMs do not share the same physical address space with RAM or any peripheral ROMs. Slots can in turn be extended to sub-slots so everything does get somewhat convoluted, especially if there's also a memory mapper present (which in most MSX2 computers there is), because that banks the memory inside a (sub-)slot in a manner similar to the Beeb's sideways RAM. I am always amazed by how much the engineers of those 8-bit platforms, be it the MSX standard that I grew up with, the C64 or any other 8-bit system, managed to squeeze in so very little address space. Kudos to them! Even my current MSX2 computer is maxed out in a fashion that by far outstretches the original specs. It has more storage and more RAM than my original PC had! And to you of course for all the explanatory videos. Keep them coming!
You have to love these old machines, they really did wonders trying to work around quite hard limitations. So much if the space is reserved, the ROM needs addressing space, the GRAPHIC memory, the other IO parts... Hell if you get an Memory Extender it has to use switching trickery just to make that magic happen!
I 1024% agree with you regarding the baby talk names. A kilogram may be 1000 grams but a kilobyte will always be 1024 bytes, and a megabyte 1048576 bytes and so on. I guess I shouldn't be surprised about those odd sizes of RAM usage since it was originally developed by Microsoft and it sounds like just the sort of trick they'd use with an intentional off by one "error".
Nice. This video takes a lot of stuff you've said before and ties it all in a nice bundle. And yeah, I hate the binary prefixes as well :) On a tangent, I've recently been playing around with the version of Microsoft BASIC made for the Atari computers. It's kinda nice, usually faster than Atari BASIC, and has little affordances like built-in scaling for the random function and that graphics plotting is a little more "integrated". And I certainly appreciate the presence of a preformatted TIME$ string. Little unfortunate, then, that it's on a non-switching 16K cartridge, so there's 8K less program space available (not that I've ever really hit that sort of limit yet, lol). I probably just need to read the manual more closely, but what really threw me for a loop is that it seemingly doesn't tolerate almost any amount of abbreviation or removed spaces. Up til that point, most of my knowledge of MS BASIC came from your videos! Funny.
Oh wow, I had forgotten about the Kaypro II. My uncle had one, and he brought it one time when he visited. Pretty sure that was the first time I played ADVENTURe.. I remember being annoyed that the filenames were 8 characters, and typing 'ADVENTUR' to start the game bugged my OCD tendencies even at such an early age. Pretty sure it was the Kayrpo II he had, as I do remember the disk drive slots (two of them) being horizontal like that. On a related note: Was it the Commodore 128 that had a CP/M mode?? Looking at the wikipedia page for Kaypro, that "Boy with Kaypro II, 1984" could be me!! Except the year is wrong, that kid looks a few years younger than I would have at 14. Still, I had the same blonde hair and glasses. 🙂
I think we cannot underestimate the importance of having such a high bar in available ram, graphics and sound capabilites on the success of the c64. Especially this early in the 80s. Few 8 bit Machinces could touch it for years, and non would be as successful. Again all in part due to the consistent feature set.
Heck, even Commodore's own offerings suffered later from _not_ having a consistent feature set. - The Plus/4 had 64K -- but its little brother the Commodore 16 had only _16K_ on what was otherwise the same hardware internally. So software for the platform was largely written for the lower system, so it would run on both. (Though that was hardly the _only_ issue that made these two models flop.) - And the Commodore 128 in its native mode had a lot more capability than the C64. But software mostly continued to target the C64 instead, since it would generally run just as well on a C128 in 64 mode as on the millions of C64s still out there ... and still being manufactured and sold. As far as I know, there was never a big C128 killer app to draw users and developers in before the Amiga 500 obsoleted it altogether. And the C64 itself continued on as a budget system with a still-vast amount of software available.
@@AaronOfMpls Yep, making c64 games you could sell it both to 128 owners and the millions of 64 owners. No real reason to make c128 versions at that point.
The reason why it’s 38 K and not 64 K is because both BASIC and the Kernel need their own address space in RAM in order to work. The same goes for the Character ROM. Some of that also goes to zero page, along with the SID and the VIC-II, which also needs their own address space.
Very interesting indeed, If I remember correctly MSX1 has 32KB BASIC ROM so that's why it has a lesser free bytes available for BASIC. I wish you can do some videos on MSX and compare it with Commodore (The pros and cons in each system) Thanks Robin!
I second that! By the way, from a design perspective, the MSX1 standard calls for two ROMs (although in many implementations they are in the same chip), a 16kB MSX-BIOS ROM and a 16kB MSX BASIC ROM. Subsequent MSX standards, such as those for the MSX2 and MSX2+ usually have a third 16kB ROM, called the MSX SUBROM, which contains the MSX2(+) extensions to the MSX BIOS and to MSX BASIC. Because of the "slotted" design that the MSX uses, none of these usually share physical address space with eachother, or any installed RAM. The MSX BIOS places several routines in the System Area near the top of RAM that facilitate so-called interslot calls. These are calls to routines that are present in (sub)slots other than the current slot for the current memory page (in the MSX, the Z80 address space is divided into 4 16kB pages). This means that it is possible to call a routine in almost any part of physical memory, as long as that part of memory can be mapped into any of the 3 lower pages (the top page can also be used for this purpose, but because the System Area (with those interslot call routines) is in that page, this is generally avoided as it would complicate matters severely). As an aside, similar routines also exist in the MSX BIOS itself. This means that the MSX BIOS itself can be mapped out and RAM can be mapped in. This allows for the full 64kB of RAM to be mapped into the Z80 address space, with only the System Area (itself in RAM) being reserved for system use. For instance, under MSX-DOS, the amount of RAM available to programs is around 54kB, which by the standards of the day was a reasonable amount for an 8-bit system.
@@damouzeWow, that's beyond my ability to understand 😁 anyway, regardless of the VDP limitation in I still believe that MSX1 is a very capable machine. You can't find a lot of MSX programming related content on the internet (at least in English) and I hope Robin can take the step and deep dive into it as he did with Commodore. Thanks for your great reply👍
I could have sworn you already did this one.. or maybe mentioned it previously? No matter, I enjoyed it and thought you explained it very well as you usually do. Thanks for this.
Interesting. I did a search for 38911 through all my notes and it doesn't seem like I've covered it before. I've had it on my list of possible subjects for years, and then a few months ago I was working on a script about VAL()'s bug and this became relevant but it was such a big subject on its own it became its own video.
Didn't the computer that was used in the weird science film have 64k? and that was 1985 if i remember right But lets face facts, the C64 and Toshiba MSX were MILES ahead of the other 8bit machines of the time. If commodore were still around today at the proress in levels of technology as they were in the 80s, the PC and mac would get crushed.
That was apparently an MTX512 and yeah, it has 64K. But my list was about computers that were available in 1982 when the C64 was released. The MTX was released after the C64.
What I never understood is why the BASIC ROM is at A000 , the kernal at E000 but there is a gap of 4K between C000 and D000 where the IO range starts. Why did they not put the ROM at a contiguous area e.g BASIC C000 Kernal E000 and IO at B000. Then there would be 4K more of BASIC RAM without the need of bank switching.
I'm not sure why either, but some of us hobbyist programmers sure loved having that $C000 area safe from BASIC for dabbling with our machine language routines, and lots of type-in utility programs lived there.
@@8_Bit yes true, back then I wrote my own BASIC extension which was rather crappy (I used it mostly to learn assembly language) and could put it at C000 without losing memory for BASIC.
Location 0 can be used somewhat freely as if it were RAM it seems, as the input/output setting doesn't matter much in a lot of cases. Location 1 is more tricky, but an REU can access the RAM directly, and the VIC-II can also display location 0 and 1 as graphics and then the sprite collision system can be used to determine its contents :) Practically it's best to just not use those bytes, but they're not completely inaccessible either.
When I was a kid, I never understood that two registers shadowed memory locations 0 and 1, I thought they were actually stored in memory. Nor did I understand those registers were designed as an 8-pin GPIO- address 1 baffled me for years. I understand it as an adult and find it very interesting.
I still remember the feeling of getting your first c64, setting it all up, turning it on and the message, what? Where's my 64K? What a ripoff! Like your first paycheck, who is FICA and where did he go with my money?
Robin you may find this hard to believe but 38,911 used to cause me anxiety. I put in a cartridge, it didn't load, and the BASIC prompt came up but I got a number other than 38,911. It would make me think I broke the cartridge or broke the computer. Every time I turned on the C64 after that I'd get a little nervous wondering whether I'd see that strange number or not. This was all in the mind of a pre-teen, but still.
I remember that happening to me too, and it was worrisome! For a common type of C64 cartridge, when you plug it into the C64 it replaces the 8K of RAM at $8000-$9FFF (the last 8K of BASIC RAM) with the ROM of the cartridge. If the cartridge fails to start, BASIC will start up but that 8K of RAM is missing, so it'll likely print 30719 BASIC BYTES FREE instead.
My computer anxiety came from friends that used to tell me, an almost urban legend. That if you typed a command just so in the Apple II it would ruin it, permanently. As though there was some sort of self destruct command. Never recall that they knew exactly what was command was, if it was in basic or assembly. Many a times when it over heated and the screen went crazy with random text. I thought for sure it was done for, and then I would turn it off for a while and it was fine.
A bit later, OCT 1983, the first MSX computer, was sold, Mitsubishi ML-8000, 32K, would have around 28000, bytes free in Basic, while not using a Disk interface. But remember MSX used the TMS99X8, Videoprocessor, which had there own 16K video ram while you at Commodore, poke/peek directly to the memory, you had to in/out to the ports of the VDP. But All graphics data was stored in the VRAM and did not take up space in the mainram, that thats not 100% true, cause normally your data would need to be in RAM to be sendt to VRAM. But some games loading graphics into RAM copy to VRAM and then continue load the game program overwritten the previous graphics data in RAM, cause now it was it VRAM so the mainram could be recycled.
I've never heard about this. The Japanese VIC-20 is called the VIC-1001 and as far as I'm aware is exactly the same as the VIC-20 except for a different ROM character set. According to the VIC-1001 User Manual that can be found on archive dot org, RAM is "MPS2114 x 10". Each 2114 chip is the equivalent of 512 bytes, so multiplied by 10 is 5K, same as the VIC-20.
That book looks really interesting... it's a couple of years too late for me... by the time the arguments were Spectrum Vs C64, I was at college and obsessed with CP/M and the PDP-11. But it still looks well worth a read, it's not like I didn't listen in on "the kids" and their arguments. ;)
TRS-80 Color Computer came in when maxed out with 64K, never 48K - 4K, 16K and 32K were the other variations. With 32K or 64K only about 24K were available to BASIC, the other half was taken by the ROM and system needs - ROM could be mapped out, usually copying the ROM; having access to the whole 64k RAM environment one could enhance the ROM code with patches or use an external OS altogether like Flex or OS9 😎
Yes, I had 32K in my notes but messed up when typing that out unfortunately. Some other commenters already called me out on that :) As far as I know the CoCo 1 only shipped with a max. of 32K and it wasn't until the CoCo 2 that shipped in 1983, after the C64, that 64K was officially available.
Commodore could have made 16 more bytes available actually by not having sprite pointers at the last 8 bytes of the 1KB block where the screen is (at $0400-$07ff), but placed them just at the end of the screen, as there is only 1000 bytes needed for the screen, so there is actually 16 unused bytes after this and then the 8 bytes for the sprite pointers. I am sure Commodore did this to both simplify the way the VIC-II read those pointers as well as having a 16 byte "buffer" just in case you wrote some bytes at the end of the screen memory that overflowed and would then mess up the sprite pointers. I have sometimes wondered why they didn't just place the default screen address in the $c000-$cfff area. But in order for the VIC-II to see the chargen rom for the default charset, it has to be pointing to the banks where those are at bank 3 (default) and bank 1. Since $c000 is at bank 0 so they would likely have troubles finding a spot for them as the last 8KB of ram in that area was also brilliant for bitmap images and the chargen rom would be in the way then, oh and they could likely not be on the same areas as ROM was already in. Both $1000-$1ffff and $9000-$9ffff are in address ranges with just ram under them, and mapping the chargen at $c000 would take the whole 4KB block there with no room for the actual screen. Would have been cool to be a fly on the wall when the designers pieced this puzzle together.
As Basic uses the Kernal extensively, using bank switching for code below it was probably not seen as worth it. Sure VIC always reads RAM, but Basic not to be able to use Peek to read-modify chars from this bank, would probably confuse novice.
I will accept any decision made by commodore - but not the cursor keys. I know what I'm doing if I ever obtain the ability to write complaint letters to the past.
C64 was my first ever computer (excluding game consoles) so at the time I didn't think anything of it. But in retrospect - what were they thinking?! I will happily cosign your complaint letter to the past 😂
@@ge97aa - C64 was basically my first too - but I did actually have a Plus4 first, when they were a failed product and on sale super cheap to get rid of stock - but I guess my parents were informed about the game situation as the next year it was replaced with a C64 setup purchased from a massive C64 user that moved to the Amiga - so I got commodore monitor and a disk drive (really rare in the UK at the time) and 3 big boxes of mostly copied games lol If I should ever acquire such an astonishing ability, I shall inform you and we shall address the priorities : Cursor keys, graphics chips in both the C128 and the Plus/4 - and then WW2 if there's time.
But a BASIC program must not only start with a zero sentinel but also end on a zero next line pointer, is it not so? So those two bytes, although they move around to always eventually be at the end of the programme, will never become available capacity to store more BASIC stuff in. So in reality the bootscreen should have said 38909 BASIC bytes free. It is indeed so weird to ship a low cost computer with banked RAM back in the era. Many early 80s computers were DRAM based and still maxed out at 48k just so they could spare the extra address decoder complexity. One of the reasons Z80 was preferred, since it has built-in DRAM controller, so it was cheap and easy to build computers on it which have that 16-48k RAM capacity range. 4416 IC has the same density as 4164. Commodore computers never struck me as the most penny pinchiest of them, i don't know if Tramiel's reputation in this regard is so deserved. After all they did come with a real keyboard and real connectors, and numerous luxuries.
I still own my Commodore 64 64c,128d, and 128. 1581 3.5inch disk drives, 1571,1541 5.25", all programs since 1979. The 1200 baud modem, printers etc. Never found support since 1990
You forgot the first Laptop, Epson HX-20 Portable Computer (released 1981, price I don't remember at the moment). Officially it could have been upgraded to 32kB RAM; but I own two special computers that were modified for the German Army, with 64kB RAM installed! But only 32kB usable at the same time, you needed to switch the memory banks with a special list of steps 😊
I was surprised the free RAM at $C000 wasn't moved lower to give an additional 4KB free for BASIC, you could have always changed the pointer at the top of BASIC giving you the choice.
Nice video! However, I still don't understand why they shipped 64 KiB of RAM when 16 KiB of the available address space was blocked by ROM. Couldn't they have achieved the same if they shipped 48 KiB of RAM and 16 KiB of ROM? Edit: should have listened for like 2min more -.- The answer is bank switching the ROM, thank you
The Commodore 64 never shipped with 64K, it was 64.5K! I mean, yes there's 64K of DRAM, but there was also 1024 nybbles of static Color RAM. It was architecturally inelegant compared to, say, the TED where color was mapped to normal RAM (at the expense of twice the badlines). But oh well, end users didn't care about architectural elegance.
Re: 14:40 It would be quite interesting to see what kind of videos you would come up with on MSX BASIC (which I guess is more comparable to BASIC on the C128).
Oh. Nice video. Literally few days ago I was exploring doing some memory mapping of C64 (I was exploring memory banking strategies on various small computers, and general memory maps), and was wondering why it does not show 38912 on C64, and assume there is some kind of marker or weird dynamic memory allocation schema. I did not explore it further at the moment, but was still interested. Todya I found this video by accident on a front page, and it answered my curiosity.
Fascinating look at the memory map. From a gaming point of view, I’d look to see how a large game like Wizball or MinM used memory exactly. What ROMs where disabled and how and where did they store game data and code etc. I would find that interesting.
Commodore was really blazing a trail back in the 80's when they made the C64 with 64K RAM. Many of its peers were playing catch up for years afterwards because it stole the scene for awhile.
Actually the C64 has not 64kByte but 64,5kByte. The colour RAM has 4096 Bits for the Character Colour. It is a static memory chip and you can actually fully use this memory for data.
Good catch - my notes even say "TRS-80 Color Computer: 32K" and yet I messed up when typing. As far as I know 32K is the most the CoCo shipped with in August 1982 when the C64 was released.
@@8_Bit The 32k CoCo is weird. It uses 8-64kx1 DRAMs and has provisions for using either the upper 32k or the lower 32k of the memory and there was a simple hack to use both halves. That isn't the odd part. The odd part is after yields on 64kbit DRAMS got better and there weren't so many half bad chips on the market any more, they stated selling machines that had the full 64k of RAM with both halves enabled but still marketed as 32k. It was only later that they started sell machines as 64k machines.
"And that's ("kernal" is) the 'correct' spelling for this kernel..." Yes, sort of, but/and also no. 1. Not really, because some goof writing the first Commodore manual or something like that just misspelled "kernEl." 2. But "kernAl" just stuck from that in Commodore world.
The Commodore 64 Had it not been for the Atari Line of home computers would have never been a success, most of the crossover team and work came from Atari to Commodore, and its those same people set up Commodore International inc, Tramiel made it a competitor to Atari, but also other 8-bit marketeers, the c64 also didnt come without its design flaws, most of these would had to be altered and ironed out during the years of its production life, it never was a perfect machine, but we did fall in love with it and embraced its rather wierd and wonderful programming abilities which people would later discover and use its full potential.
Wow, MSX Content! Now we need more 😂 Seriously, here in Brazil MSX machines were sometimes advertised as having 80 KB or even 96 KB of "memory". That's 64 KB of RAM, plus 16 KB of Video RAM, and... 16 KB of ROM! Trully dishonest.
Well, ROM is also memory. I think I have seen CBM ads where the ROM was also mentioned in addition to the RAM. It is a legitimate selling point to have nice things in ROM that are instantly present when the machine is switched on. I never quite took to the Amiga because BASIC had to beloaded from disk.
Amazing video, thanks! Once I started learning assembly language on my 64, the difficulty wasn't the 38911 bytes for BASIC, but rather then very tiny amounts of truly free space in zero page. This was quite a shame, really, since zero page usage makes programs faster and smaller. Before I had a good memory map, I would write into random places zero page to see if I could use them. Typically this ended poorly...
Yes, if you're trying to write an assembly language program that can co-exist with BASIC, then free zero page is hard to find. But if you don't need BASIC then many zero page addresses are free for use, roughly locations $02-$8F are only used by BASIC.
And even if you are using BASIC there's a bunch of zero page that's only used by the RS-232 routines, for example, so those can be available if you don't use them.
How do you check how much Basic bytes free when developing a program for Commodore 64? How do you make sure you're not running out of RAM when you're not done with the program?
You can check how much memory the program is using by doing a RUN, and use the program far enough that all the variables (including arrays) have been defined, then hit STOP and type: PRINT FRE(0)+2^16 and hit return and it'll return the number of bytes free. Unless you're using big arrays, that 38K of RAM will go a long way.
I have never had C64, but was always curious how the binary programs are loaded. For example: you use BASIC to load the program from the floppy disk, then you enter RUN command and the game runs. But where is it stored if BASIC is still in use? How does that mechanism of loading big programs with BASIC still in memory work?
Generally the initial program you load will fit completely in the 38K of free RAM. Once RUN, the program can use machine language routines to switch BASIC ROM out and make all RAM available. The BASIC ROM can be switched in and out as needed depending on the program's needs.
An interesting thing about basic is that if you write 3 lines of code and then remove the middle one, it actually copies down all the lines of code after the one you removed down and have to recalculate all the "next line" addresses for every line that is copied down. So removing a low numbered line in a large program takes a bit longer than one at the end. :) This is likely also why a GOTO parameter is actually storing the line number verbatum and not just a two byte pointer directly to the line where the code is as it would mean they would have to modify all these too when you removed a line. It would ofc also mean that saving a basic program snippet meant that it contained pointers in a fixed memory layout which would limit how the program was loaded. Basic programs can after all be loaded no matter where you set the basic start pointer to. However a possible performance/memory improvement they could have done is to not store next pointer for each line of code, but instead the length of the line in one byte. The screen editor can after all only handle two lines on the screen as one line of code when you enter it (even when using short form). Even on an 80 column display you would be still not able to fit more in a line of code that one byte to indicate length would be enough to cover. It would also simplify removing lines as no recalculation of pointers would be needed.
So dumb question. The ROM is accessible, I always thought ROM was set and cannot be altered. Or is it that there is 64k of RAM and the ROM chips put the BASIC ROM and I/O etc into RAM on start up unless you clear it?
Both the ROM and RAM "under" it both exist, but the 6510 CPU can only "see" one or the other. There's essentially a switch available for each of the ROM chips. So at the area $A000-$BFFF the C64 can either see RAM *or* the BASIC ROM. Likewise at $E000-$FFFF, the C64 can see either the KERNAL ROM *or* the BASIC RAM at that location. The ROM is still there and can't be modified, but the 6510 CPU can choose to see either the RAM or the ROM, and in an instant, change to the other one.
Used to wonder what kind of basic program would use all that memory. A program that big would be too slow to run all the way through in a loop. It would have had to be all data but it couldn't use bitmap mode.
I have wondered that for years, and I was on the Spectrum side of the playground argument here in the UK so was happy to berate C64 owners for their pathetic memory size!
I find it odd they didn’t move the rom up just a bit so that extra 4k block was available to BASIC programs. It bothers my ocd a bit they had that clunky map for some reason lol. I made good use of it when I learned assembly but it still seems like a marketing blunder.
I like to think they provided it as a safe little playground for us aspiring assembly language programmers :) It's actually true that if you look at the PET, VIC-20, and other platforms with built-in BASIC, a common question was "but where can I put my machine language routines?". Well, here's Commodore's answer. I think.
Excellent. Mystery solved. And that SYS command at the start is cool. Next mystery to solve: Why is there is a left pointing arrow key in the top left corner?
0:45 It has more than 64K of RAM since it has 1K-nybbles of Color RAM and some bytes and bits of I/O chips that can be used as if they were RAM. Trivia question: how do you read the value of RAM location $0000? I wonder if STA $0000 writes to it. 1:14 Would you say "binary kilobyte"? This wasn't a big problem in the 1980s, but today, most storage sizes are decimal rather than powers of two. Even SSDs reserve a significant fraction of their power-of-two storage for internal use. My 2TB SSD has 2,000,398,934,016 bytes available. And broken systems like Microsoft Windows pour fuel on the fire by showing sizes as "GB", an SI unit, when they actually mean GiB, and confuse consumers into believing that the drive manufacturers ripped them off. Quick question: how many bytes are in 1.1 MiB? (No calculators allowed!) How many MiB/s is a 1-Gbps link? 2:38 Relatedly, "K" is the only unambiguous multiplier, since it always means 1024 (it's not a metric prefix), where "k" always means 1000. 14:20 The SLOW-mode C128 is even worse, at 7.94 seconds. It improves to 3.97 seconds in FAST mode. 14:43 There's a size beyond which a Commodore-BASIC program is impractical, with its two-letter global variable names and linear lookups for GOTO statements. Imagine programming a Holo-Shed with "four million lines of BASIC"!
Here's a weird thing. I just tried in VICE something like: FOR X=0 TO 255:POKE 0,X:PRINT PEEK(0):NEXT and was surprised to see the numbers 0 to 255 scroll up the screen. It really seems like location 0 behaves just like RAM? Doing the same with location 1 crashes, as I would expect since it's switching BASIC and the KERNAL out. But I think I've heard of setting a sprite to get its display data from location 0 and then using sprite collisions to read the RAM out from "under" location 0... or was it location 1? I'm just going to keep on saying kilobyte meaning 1024 as if I'm still living in 1984 and ignore any problems that might cause. Wow, C128 BASIC is *really* slow. I like how it so precisely doubles in speed in FAST mode though. Yes, huge BASIC programs just become unmanageable at some point anyway. In a recent video (device 9 stuff?) I was pretty amazed at that one BASIC strategy game. The listing went on for over a minute!
@@8_Bit: You can also use the REU to access the RAM under the CPU I/O registers. You'd think the C128's FAST mode would be ★more★ than 2× since the VIC stops stealing cycles from the CPU. I wonder if the scanline interrupts stop, too.
Windows correctly shows sizes in GB, a non-SI unit. They do not actually mean GiB, because GiB is an SI unit that nobody uses, asked for or needs, and which only confuses consumers into accepting the inflated numbers made up by the drive manufacturers that are ripping them off. Nobody cares how many bytes are in 1.1 MiB because nobody needs SI units when working with computers. Stop supporting this nonsense and let us go back to the non-ambiguous quantities that we've been using from the beginning.
You can come up with a system for "local" variable names, especially useful for reusable library routines, starting with A0, A1, A2 etc., by not using these for anyrthing else, and keekping track of the last one of these used in a routine. On first use, the names can be longer, using the extra characters as a comment indicating the meaning, like "A1VICBANK". If subroutines don't live too far behind the place from which they are (mostly) called, they are accessed quickly even in big programs.
Regarding the C16/Plus4 BASIC interpreter, it's almost unbelievable that Commodore managed to make in slower than on the C64. What on earth did they do? Perform bank switching for every single byte that's fetched from memory? I'll have to disassemble the ROM and have a look.
It's determined by the size of the bus, i.e. how much data can be moved around in one micro-instruction. It would get pretty confusing if the address range was used, an i7 that can address 64GB would be a 46-bit computer.
The TRS-80 CoCo could have 64K RAM installed, but it was rarely all used. However, like the C64, you could bank switch all 64K of RAM into play. One of the final programs written for the CoCo after the PC began to push out all other computers was a serial buffer machine code program which loaded itself at the bottom of RAM and used the rest of RAM as buffer memory.
Color RAM is a 1k x 4-bit SRAM, and I think I mention its existence in passing in the I/O section, but (in my opinion, anyway) it has very little bearing on the topic. Were you thinking I should highlight it to say we actually have 64.5 KB of RAM? But since it's not part of the 64K DRAM, and as only the low 4-bits are accessible, it's in no way general-purpose RAM that could be used by the BASIC system for code or variables. I suppose if you need a bunch of values effectively ORA'd with #$F0 then it's a neat trick :) Many of the VIC-II registers, such as the sprite co-ordinate registers, actually work more like general-purpose 8-bit RAM than the color RAM. Maybe another apt comparison is that color RAM is essentially dedicated 4-bit video RAM, and at least some 8-bit systems such as the MSX machines don't lump system RAM and video RAM together: that MSX I showed has 64K of RAM, and also has 16K of VRAM, but the marketing (rightly) didn't try to spin it into "80K of RAM".
@@8_Bit When reading from colour RAM, the high nibble comes from whatever VIC read in the other half of the cycle. So if you fill the graphics memory (screen+charmap, or bitmap, depending on the graphics mode), the sprite pointers (I forgot if you need to fill the sprites as well if you don't use them) and the last byte of the 16K block with bytes with the same high nibble, you can get a reliable high nibbles when reading from colour RAM and you can even run code from it. But since all the opcodes have to share the high nibble, the available set of opcodes is very limited; the arguments have to share it as well. I managed to cycle border colours using $Dx opcodes, but that's probably the most interesting thing you can do. BTW, I wonder if you could hot-swap RAM in a C64 running code from colour RAM without it crashing.
@@vytah Do you know if the high nybble (sorry, I'm sticking with the "y" spelling) colour RAM behaviour is consistent across all C64 revisions? I hear conflicting reports about it but haven't dug into it. I do remember the article in C=Hacking years ago about it and will have to revisit it. I think I've seen some colour RAM that just consistently returns $Fx no matter what, but I really need to experiment with this sometime.
@@vytah Yes, to be clear I totally understand (and believe) that some C64 work exactly how you describe. I'm just not sure they all do. I'm especially interested in the final 64-pin "SuperPLA" for Rev. B shortboards that apparently has colour RAM built into the PLA! I'd expect that returns %1111 in the high nybble every time like other disconnected I/O pins but I don't know that at all. I'm not even sure if I have a C64 with that SuperPLA, I will have to look.
As I understand it, the original CoCo shipped with a maximum of 32K (catalog number 26-3003). I mistakingly put 48K on the screen even though my notes said 32K. It was the CoCo 2 released in 1983, after the C64, that had 64K available.
@@8_Bit Yes, that’s right, though it may have been even 1984. They did offer a 64K upgrade kit for the Color Computer for sale at the same time. Great video as always!
I had an MSX Sony hitbit when I was young. Learned myself basic, but not assembler. Never understood the peeks and pokes, so would love to see more of that. 💛
Depends on the game; a surprisingly large number of C64 games keep the KERNAL and even BASIC switched in. But yes, most technically advanced games drop all that.
