38911 Bytes Free? Commodore 64's BASIC RAM

[@MichaelDoornbos]

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 😅

[@windsaw151]

There's a german proverb I like to abbreviate for this purpose: "Wer das Byte nicht ehrt ist des Kilobytes nicht wert!"

[@damouze]

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!

[@damouze]

@@windsaw151 Ha ha ha.. I'm pretty sure that's not the original phrasing of that proverb, because it sounds very similar to Dutch proverb!

[@James_T_Quirk]

That was the C64, your code had to be "Tight" ,,,

[@Starchface]

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!

[@MylesSmith-q4y]

From what I heard on another video the VIC-20 had 8K of RAM when it was first sold in Japan but later had its ram dipped.

[@8_Bit]

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.

[@phill6859]

It was never sold with 8k. During development, one person said it needed to be 4k for cost reasons, another argued 8k was needed to be useful. 5k was a compromise.

[@falksweden]

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!

[@monarch73]

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]

I paid 1299.00 for My first C64, in the 90's I was a Commodore dealer, selling them for $199...

[@monarch73]

@@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)

[@James_T_Quirk]

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

[@AaronOfMpls]

@James_T_Quirk Was that supposed to be 129.00? (You have a possibly doubled 9 there.)

[@James_T_Quirk]

Do you read ? @@AaronOfMpls

[@TheTRONProgram]

Great educational video and history on Commodore's choice of DRAM. Loved that song at the end with the fantastic harmony!! :)

[@AndyHewco]

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 :)

[@vwestlife]

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.

[@8_Bit]

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?

[@WarrenPostma]

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.

[@arlasoft]

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]

Are they all Speccy users, or from other platforms as well?

[@arlasoft]

@@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.

[@8_Bit]

@@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.

[@CRCO1975]

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...

[@NuntiusLegis]

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.).

[@CRCO1975]

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.

[@8_Bit]

Yes, it's bizarre, and on top of that there's the technically true claims of it being a 16-bit computer, but it performed worse than most 8-bits.

[@damouze]

@@8_Bit The TMS video chip is the reason that a lot of MSX-es were also marketed as having, for instance, 80kB of RAM...

[@FuerstBerg]

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.

[@justinmijnbuis]

@@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 🙂

[@CanberraUser]

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!

[@MasticinaAkicta]

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!

[@RudysRetroIntel]

Great video and explanation! FYI, the Kaypro II computer came out in 1982 with 64K. Thanks so much for sharing!

[@8_Bit]

Aha, the Osborne killer! I forgot about that one, thanks for the reminder.

[@mikegarland4500]

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. 🙂

[@piotrmironowicz7450]

Wow! That was impressive, insightful explanation of memory organization, with historical context, and lot of clear presentstion of C64 internals.

[@xtraOhrdiNAIR]

I even found out that 63999 is the last number you can use in a basic script. Line 64000 returnes a syntax error :D

[@mudi2000a]

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.

[@8_Bit]

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.

[@mudi2000a]

@@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.

[@DarkMoe]

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

[@James_T_Quirk]

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..

[@stephanerieppi]

"And no, I'm never go say Kibibyte". THANK YOU!

[@movax20h]

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.

[@MK-ge2mh]

Great video, Robin! I learned a lot.

[@frankmathieson3029]

"and no, I`m never going to say kibibyte" you sir, just earned yourself a subscriber!

[@808v1]

I always love your music! Melancholy retro music - just frickin' great.

[@ronaldjensen2948]

If memory serves, the two bytes pointing to the "next line" are only used for listing the program so it is possible to "hide" lines from being listed by altering the pointer. In the example around 26:20 you could change 0B 08 to 11 08. Listing would just show "20 END" but running would still print "HI"

[@8_Bit]

I'm pretty sure the next line pointers are also used by GOTO as it searches for the appropriate line number. So you wouldn't be able to GOTO a hidden line either, you'd have to GOTO the previous regular line and let the program flow take it there. This is a subject I need to investigate further sometime!

[@JSRFFD2]

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...

[@8_Bit]

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.

[@8_Bit]

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.

[@manobit]

Wow! I never thought that I can see the memory inside of the Basic code! Thank you for your great video!

[@FadkinsDiet]

I was actually hoping this week someone would make a video explaining 38911!

[@8_Bit]

I've had it on my list "todo" for quite a while, I'm glad it arrived at the right time for you :)

[@Roxor128]

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.

[@dougjohnson4266]

The C64 was just a very good design for the time. Especially the ROM bank out feature.

[@greggoog7559]

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 😄

[@arlasoft]

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.

[@NuntiusLegis]

With the color RAM being 1024 extra nibbles, the C64 is actually a 64.5 K RAM machine.

[@ryancraig2795]

Well, now I know more than I ever needed or wanted to about how Commodore BASIC programs were laid out in memory 😂 (yes, I watched til the end)

[@fr_schmidlin]

The MSX cameo gave you an instant like and subscription. :)

[@OscarSommerbo]

The "FRE(0)" response used to bug me to no end in the 80's.

[@RacerX-]

Well that was fascinating. My younger self as a teen in those days would have appreciated this explanation because I remember feeling ripped that we didn't get the full 64k for programming in BASIC.

[@64jcl]

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.

[@HelloKittyFanMan]

Haha, wow, I wonder why I never knew about that color-changing "sys" until now!

[@landsgevaer]

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. 💛

[@platimatic]

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).

[@Smokr]

May your bits never flip. Merry Christmas and a happy new year!

[@TheUtuber999]

Unless it's between 55 and AA.

[@chouseification]

Thank you for calling out the legendary Wizball! That was one of the best games ever!!!

[@ga57cas]

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.

[@MrMegaManFan]

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.

[@8_Bit]

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.

[@pikadroo]

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.

[@tonym2464]

When will Robin make the upgrade to the Amiga? It's going to be epic.

[@8_Bit]

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]

Why upgrade? Once you go down that path, there are 40+ years' worth of hardware choices.

[@8_Bit]

@@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.

[@TheUtuber999]

@@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.

[@Okurka.]

@@8_Bit 16/32

[@wisteela]

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?

[@Thingumybob_C64]

@27:58 I started to have an Acid flashback... Seriously though, this is the type of question we all had back in the 80's. I wonder if there's any magazine articles from back then that could explain the subject so thoroughly? I did get a slight bit of insight into this type of thing back in 1985. I knew Bob Lentini when he was programming Bobsterm Pro. He said his terminal program had a 32K file transfer buffer because he swapped out all the ROMs with his own code. He overwrote the Kernal and character ROMs and swapped out the BASIC ROM. The program also relied partially on the operating system in the 1541. If you tried to reset your 1541 by turning it by power cycling it, the program wouldn't run anymore because part of the programming in the drive was lost.

[@Kingcobra6699]

These primitive machines were used so creatively, it's amazing. I learned to code in BASIC in 1990 and being online taught me English. That C128 was probably the best investment my father ever made. It must have paid off 1000x - literally, thinking of it.

[@akira808state4]

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.

[@uriituw]

Well, it doesn’t do bank switching while running BASIC programs.

[@vytah]

Character ROM doesn't need to be in CPU address space, and in the boot configuration it isn't.

[@jandjrandr]

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.

[@Jammet]

Thank you for the amazing videos! :3

[@filevans]

3:50 you've got spectrum wrong. There were two models, the 16k and the 48k model in 1982

[@8_Bit]

I was talking about the maximum RAM available for each system, not every spec available. The PET, Apple, and Atari computers were available with less too, but this is about how shipping with 64K and only 64K was a big deal.

[@filevans]

@8_Bit the other ones you mentioned that they came in different sizes

[@8_Bit]

@@filevans Some I did, some I didn't. The TRS-80 Color Computers also came in smaller sizes and I didn't say anything about them either. The point was the max. size, I only mentioned some of the earlier specs to show that they did increase the RAM, but not all the way up to 64K.

[@filevans]

@@8_Bit yes I know the max is the main point, I just thought you maybe didn't know the spectrum came in 16k in 1982 as it wasn't very popular

[@8_Bit]

@@filevans Yes, the 16K Spectrum is the main reason that Commodore UK wanted to introduce a 16K Commodore computer of their own in 1982. See my video about the Commodore VIC-30 for more info about that and I'm pretty sure I mention the 16K Spectrum in it.

[@ahmad-murery]

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!

[@damouze]

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.

[@ahmad-murery]

@@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👍

[@mikegarland4500]

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.

[@8_Bit]

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.

[@mikegarland4500]

@@8_Bit it's very possible I saw someone else's video on it, or maybe read about it..

[@anon_y_mousse]

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".

[@64jcl]

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.

[@TheAtomicCrusher]

I just assume that all Canadian C64s had AA as a filler in the RAM.

[@maxpoulin64]

That memory structure raises additional questions for me. If the lines are just a linked list in memory like that, how does it find or list lines in an efficient manner? Could a given program be slower or faster based on what order you typed your line numbers and take a hit on your gotos? Did any program ever try to optimize for that or would you just go assembly if you're that deep?

[@8_Bit]

BASIC does just traverse the linked list from the beginning each time when searching for a line so yes, the earliest line numbers are found quickest. I think there's one optimization that forward GOTOs start their search at the current line, but I need to confirm that with study sometime. I've seen some inconsistent explanations of how that works exactly so I'm slightly skeptical. Some programs have definitely optimized for that by opening the program with a GOTO to program initialization at a high line number, and once that's complete they GOTO the 2nd line of the program for the main loop so it executes quicker. Note that even the linked list is potentially an optimization in itself, as I've heard rumours of some implementations that don't even do that; the code is just a series of null-terminated lines that are scanned through in full. I haven't tried to confirm this for myself :)

[@maxpoulin64]

Fascinating! I never thought much of BASIC and just assumed it had some crazy programming to make it as fast as possible. But I guess that makes sense from the 80s point of view and it being one of the first interpreters. It looks like a bunch of stuff I would expect to be optimized away aren't, down to parsing numbers. I might finally go download VICE and play with it and see how it actually runs BASIC programs. I might finally go download VICE and explore how they made it work and how much faster I can make it using today's knowledge.

[@FuerstBerg]

CBM BASIC always searched through the link list, I think even versions 7 and 10 did. Locomotive BASIC (Amstrad CPC series) had different BASIC tokens at least for GOTO and GOSUB. They were replaced transparently. One token had the line number in code, the other the address of the BASIC line. LIST always showed the line number. I was said Spectrum BASIC stored line number and address after GOTO and GOSUB. LIST always showed the line numbers but the interpreter always used the address. Saved BASIC programs could use this to hide somehow how the program works.

[@NuntiusLegis]

@@8_Bit I recently tested it, C64 BASIC does have that optimization for forward jumps - the speed only depends on the number of lines between the calling line and the destinantion line, no matter if the count starts from the beginning (backward jumps) or from the line following the calling line (forward jumps). So the advice in many books to put ALL subroutines at the start of the program usually results in slower code.

[@HelloKittyFanMan]

Thanks, interesting video (even if a little bit went over my head and I wouldn't be able to explain in what way)! Hey, for one of your next videos soon, will you please write a BASIC program without any pokes that prints something and then sends the actual "enter" signal rather than just entering a line-space (like "chr$(13)" only does)? Because I thought I had seen that before but I don't remember which chr$ it is, and it would be fun for me to play around with now since I didn't think of it back when I was between 8 and 16!

[@8_Bit]

Do you mean you want BASIC to interpret and process what was entered as a BASIC command? That can't be done while a BASIC program is running. The closest thing to that is to print something to the screen, POKE a CHR$(13) into the keyboard buffer, then position the cursor correctly and then END the program so the READY. prompt appears right above the command you printed on the screen. Then the chr$(13) in the keyboard buffer is executed immediately, and the BASIC interpreter will execute it. You can even chain multiple commands including re-RUNning the program this way.

[@HelloKittyFanMan]

@@8_Bit: OK, so we need at least one poke, but that's pretty cool! Will you please show us how to do that? In essence, this means that BASIC *CAN* have self-modifying code! (But it just needs to dabble into the machine language a little, using that poke, but it's started by BASIC and doesn't use any "sys," so so it still really counts as BASIC, anyway.)

[@BubblesSmurf-vk9uj]

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

[@derekdresser9214]

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.

[@AaronOfMpls]

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.

[@maxxdahl6062]

@@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.

[@alex_6874]

Hi, Robin! I love watching your videos and this one also great! I'm programming Commodore game in the style of Dungeon Crawler. And I want to ask, how would you do the graphics engine for this king of game? I'm using raycasting now (three bytes of map for each column). My action screen is 64*128 pixels as i use hires multicolor. And each ray is checking for a three blocks in front of it. Of couse i have lookup tables for this (sacrificed 4K of RAM for texture indexes and rays data). But it is too slow. It takes +- one second to draw full 64*128 screen. And it takes a lot of time to shift two bits of texture to the two bits of screen byte. This is because i want to draw separate textures for each block (byte) of the map (like Wolfenstein 3D). Not like the Might&Magic, which have one texture for the whole level. And there is no information in the web how to make this kind of engines

[@8_Bit]

Sounds like a really neat project. Sorry to say I've never coded a routine like this so I haven't really thought through it. If the shifting is where most of the CPU time is then is there anything that can further speed it up? Can some of the shifting/rotating be eliminated with more lookup tables? Can the algorithm be reworked so some of the results can be ORA'd into the screen instead of shifted? Is there an area where your routine can "cheat" or take a shortcut to a "good enough" result even if it's not the most accurate/correct one? I know there are some Wolfenstein-like routines that some demo coders have created for the C64. Perhaps disassembling one of those will provide some good ideas?

[@alex_6874]

@@8_Bit Thanks for the answer! Actually I found one technique yesterday. It calls EOR filling. But I can't clearly understand how to make it. Now the game screen pixels are filling with OR instruction. And about shifting. For example, I have a byte with %11000000. This is screen mask where I need to put pixel. And I have another byte with %00001100. This is a texture mask, from where I need to get pixel. And I need to mask a pixel from texture and shift it to the screen mask. I'm using comparing. If texture mask if higher then screen mask, then shift pixel right while masks are not equal, and vice versa. But I think it's too slow

[@lovemadeinjapan]

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.

[@xtraOhrdiNAIR]

btw when I set poke2048,1 the "new" command returnes a syntax error, but the listing will be deleted anyways ?

[@8_Bit]

Yes, it's weird! With poke 2048,1 RUN also gives a syntax error, and doesn't RUN, but NEW gives a syntax error and works.

[@frankmeyer9984]

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 😊

[@DavidYoud]

Isn't there 1/2K from color RAM?

[@8_Bit]

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".

[@vytah]

@@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.

[@8_Bit]

@@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]

@@8_Bit I guess it might depend on the PLA. I just described what happened to work for me, but maybe different revisions are different.

[@8_Bit]

@@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.

[@MaciejStachura]

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?

[@8_Bit]

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.

[@melkiorwiseman5234]

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.

[@RogelioPerea]

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 😎

[@8_Bit]

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.

[@damouze]

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!

[@davelasertie4967]

"I'm never going to say KibiByte", well said sir, I like you!!

[@TomStorey96]

Kibi, mibi and gibi sounds like names you'd give to SeaMonkeys.

[@HelloKittyFanMan]

"Overhead for the OS." In my early years of trying to understand computers, I always thought that when we ran a cartridge instead of loading from disk, it was instant because not only didn't it have to copy anything from disK into RAM, but that we were running instructions straight from ROM. And then a little later, I thought that my idea of that was confirmed by the fact that computers with bigger OSes when developers started to want to make improvements more often once they discovered new things they could do, would loadthem from disk into RAM because making new tips for every new version would cost too much, but that we didn't have to worry about that with these older computers because the OSes were just hardwired into the ROM. So I thought that meant that in these older computers, we were just running instructions straight from the ROM instead of having to copy the ROM into RAM, unless we wanted to adjust something like the font or the set of basic commands, like adding "say." I thought that was also confirmed by learning that the character set on the 64 only needs to be loaded into RAM when we're changing the font like they did in the Sword of Fargoal, etc. (which, once I learned how to do later, could be pretty fun sometimes). If that's the case with the character set, then why is it not also the case with the OS? And this is what has made me wonder why modern devices like smartphones still have to load their OSes from ROM into RAM, especially when it can take just as long to boot from that ROM as it might if you were to load that from a disk. Haha, can you imagine Android on a disk? Why can't we just run OS instructions straight from the ROM and only use the RAM for part of the OS when we have to modify a value in order to make something from it work? Can't a CPU fetch an instruction straight from ROM?

[@csbruce]

The access speed of RAM these days is orders of magnitude faster than ROM, so you'd only want the minimal amount of ROM in a modern system to bootstrap the OS from flash storage.

[@HelloKittyFanMan]

@@csbruce: Cool, but it doesn't really... "ADDRESS" (ha!)... what I'm asking.

[@AaronOfMpls]

"Why can't we just run OS instructions straight from the ROM" -- I assume we could. But updates would be more difficult, especially security updates that can touch a lot of different parts of the OS. Presumably it's cheaper to keep the OS on disk (or flash memory equivalent) instead of re-flashable ROM, and save the true ROM for system firmware.

[@HelloKittyFanMan]

@@AaronOfMpls, I'm not talking about "security updates," I'm talking about the Commodore 64 and related things here, mostly But even in the case of modern devices, security updates are added to the misnomered "ROM" (writable "read-only" memory; EEPROM flash in the phone or tablet) anyway. They're still booted into RAM when the device turns on, and that has nothing to do with security.

[@csbruce]

@@HelloKittyFanMan: What I was saying is that you wouldn't want to run your OS from ROM because it'd be super-slow compared to running it from RAM on modern machines. This was true even in the DOS era, so many systems had the option to copy the BIOS ROM to "Shadow RAM" to run faster.

[@stevethepocket]

I wonder how many programs ever bothered to use the 4K hiding under the I/O registers. It seems like it would be a hassle to get anything in or out of it since you can't access the serial or cassette ports while it's in use. And loading is slow enough as it is!

[@weedmanwestvancouverbc9266]

Some programs did use this as they came up with their own input output routines

[@8_Bit]

Or the program would just load the 4K data to another area of memory (not under I/O) then switch out I/O and quickly copy the data to the correct place. The copy can be done in a fraction of a second.

[@arlasoft]

Almost all of my games put sprite data at $C400 and depending on the game this will often include the I/O area. The VIC chip just sees the RAM underneath whether IO is banked in or not. Nowadays getting the data there is easy with VICE's inject to RAM feature, and for distribution Exomizer is smart enough to automatically handle the unpacking to the IO area.

[@FuerstBerg]

Cassette port is handled by the 6510's I/O port, so there is at least this I/O available. But I don't think it was widely used. But it is possible to use this area for graphics data not changing during gameplay like sprites or characters.

[@noelht1]

ZX Spectrum users in my school playground used to rip on the Commodore as a distraction from the object and destitute poverty they were living in and not being able to afford a proper computer like a Commodore 64

[@DroppingIllusions]

Your voice is very relaxing.

[@mokalhor]

Absolutely! Yes please, more msx videos!

[@Lion_McLionhead]

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.

[@ser_olmy]

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.

[@willaien9849]

How many carts for development/etc. do you have?

[@8_Bit]

I mainly use variations on the Super Snapshot, either original vintage ones, or in this case I'm using the Kung-Fu Flash which is a flash cartridge that can behave like a Super Snapshot, with an upgraded ROM by my friend Adrian Gonzalez.

[@8_Bit]

I've got a handful of vintage carts that are useful for development, and probably 3 or 4 more modern ones.

[@der.Schtefan]

OMG, how do you switch to a mode where you can just type without the C64 trying to interpret the text as commands? Can you use this as a text edit mode in a program?

[@8_Bit]

I'm just using the regular C64 editor but not hitting the return key, or if I do, using Shift+Return to make it just ignore the text. Pretty handy.

[@der.Schtefan]

Oh, you're just typing without pressing enter

[@8_Bit]

I think I pressed return sometimes, but when I did, I also held down shift.

[@StavroMueller]

Even with all the ROMs and IO swapped out, there's still only 63.99K because location 0 and 1 are never accessible.

[@8_Bit]

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.

[@DavidRomigJr]

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.

[@DavidRomigJr]

(Or did I mean address-0 baffled me? It was whichever one was I/O direction. :P )

[@HelloKittyFanMan]

What's the significance of the RAM that's "under" the ROMs?

[@8_Bit]

The RAM "under" the ROMs can be used for any purpose by the machine language programmer. There's 64K of RAM available in the machine; but if you want to make use of I/O or BASIC or KERNAL functions then you will have to make wise use of that RAM as the 6510 can only "see" one or the other at any given moment.

[@borayurt66]

This brings back memories. When I was in high school, back in 1983, some of had C64's, and some had ZX Spectrums. Of course, there was the endless debate about C64 being not a true 64K computer. Our maths teacher explained this in a different manner, he said the BASIC ROM, Character ROM and the Kernal ROM were read and copied to their respective locations on RAM at boot time allowing faster access compared to reading from ROM at run time. I have learned later on that this wasn't correct, but for a long time I really thought C64 worked like that.

[@magnustveten492]

But it can do if you want, as you can tell it where the char should be and then you can even make custom characters :)

[@borayurt66]

@@magnustveten492 Yes, of course. But for a long time, I actually thought C64 worked like that by default. 😊

[@8_Bit]

Interesting. Do you think your maths teacher explained this to you somewhat later in the '80s? He might have been theorizing what the C64 did based on what later x86 machines actually did, when ROM speeds started to lag behind their system's RAM speed, and it actually was quicker to copy ROM into RAM at boot.

[@magnustveten492]

@@8_Bit you could do a 10print speed test to see if it’s quicker with char in ram or rom :)

[@borayurt66]

@@8_Bit I graduated in June 1984, so it can't be later than that. I am almost sure it was in 1983 because that was the year most of us kids got "computerized" 😁

[@pjcnet]

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.

[@HelloKittyFanMan]

"Where --does-- [do] the other 26K go?"

[@AlexEvans1]

There is essentially no such thing as a 48k coco. Typical ram sizes were 4, 16, 32, and 64.

[@8_Bit]

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.

[@AlexEvans1]

@@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.

[@8_Bit]

Funny! Was switching between the 32K halves only done through a hardware jumper or something like that? Or was it controllable through software?

[@AlexEvans1]

@@8_Bithardware jumper.

[@edgeeffect]

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. ;)

[@greggoog7559]

This man just managed to make bean-counting fun! 😄

[@kjakobsen]

So how does the C128 address 128K?

[@8_Bit]

It has the same 64K CPU addressing limit, so it has an even more elaborate bank switching scheme (supported by a "Memory Management Unit" chip) to handle the extra RAM, and all the extra ROM it also has for the more advanced BASIC and enhanced KERNAL functions. And unfortunately its BASIC is even slower than the Plus/4's because of all this extra swapping.

[@chrisjpf33]

FYI, pronunciation of Albert’s last name “sharp-en-teer” is correct.

[@CrassSpektakel]

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.

[@8_Bit]

If you could go back in time would you tell Commodore they should have named the computer the Commodore 64.5?

[@HojoNorem]

IIRC, the colour ram is only 4 bits wide.

[@CrassSpektakel]

@@HojoNorem thus I said "for data". I don't know of any reasonable 6502 Mnemonic happily living in four bits.

[@CrassSpektakel]

@@8_Bit I would have called it the Supercalifragilisticexpialidocious but I like your idea too.

[@HojoNorem]

@@CrassSpektakel true. That being said, the upper 4 bits are open bus so you'd have to mask them off when reading to get reliable results.

[@MatthewCenance]

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?

[@8_Bit]

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.

[@marty9248]

More MSX please? MSX was and still is a great platform. MSX1, MSX2, MSX2+, Turbo-R. Audio, video expansion cards, IDE interfaces etc.

[@guessundheit6494]

Ah, a refresher course.

[@csbruce]

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"!

[@8_Bit]

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!

[@csbruce]

@@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.

[@BL-ob9fn]

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.

[@NuntiusLegis]

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.

[@Longuncattr]

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.

[@ReptoidDiscoversMinecraft]

Brings back some good memories (literally) :>

[@rigues]

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.

[@NuntiusLegis]

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.

[@AndyG-_-]

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.

[@8_Bit]

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.

[@AndyG-_-]

Agreed. Anyway, thanks for the videos, I really enjoy your meticulous approach and attention to details. Well done sir.@@8_Bit

[@awilliams1701]

I take it the 2k char rom is part of the 4k of IO?

[@vytah]

No. First, char ROM is 4K, not 2K, as it contains two charmaps (uppercase with graphics, and mixed-case). Second, there is a pin on the 6510 I/O port that determines what you see at $D000-$DFFF: set it to 1 to see the I/O, set to 0 to see the char ROM.

[@8_Bit]

There's actually 4K of character ROM (the regular upper case + graphics set, and the mixed case set) and it's like a 3rd layer in the $D000-$DFFF area that I neglected to mention. That area can be switched between RAM, Char ROM, and I/O.

[@awilliams1701]

@@vytah 2x2k. 2k for 1 set and 2k for the other, but only one at a time is used. My guess is the IO port switches which half of the 4k is used exposing only 2k at a time.

[@awilliams1701]

@@8_Bit Yeah I know you can turn it off. And I know it's 4k, but only 2k is used at any time.

[@vytah]

@@awilliams1701 No, the IO port decides whether the CPU sees all the char ROM, or all the IO devices, or the underlying RAM at $d000-$dfff. Never half. But that is the CPU view. From the VIC view, there's only 16K of memory and the char ROM may appear at $1000-$1fff. Then VIC picks which 2K of memory is used as a charset - it can pick any of the 8 blocks, 2 of which may be the ROM charsets. VIC doesn't care whether the CPU can see the char ROM or not, it has its own memory view, which does not include IO, colour RAM or other ROMs. (And whether VIC sees char ROM or not, depends on the CIA chip, which selects which 16K window of 64K RAM VIC can access: if it's $0000 or $8000, then VIC can see the char ROM, if $4000 or $C000, it can't. The corollary is that VIC can never read RAM at $1000-$1fff and $9000-$9fff. Which is why many SID tunes are loaded at $1000 - less chances of collision.) (And about how VIC reads colour RAM when it's never mapped into VIC's memory view: VIC has separate data and address lines connected directly to colour RAM.)

[@CrazyBossDK]

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.

[@jack002tuber]

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?

[@AaronOfMpls]

Or as a certain game show used as a category once, "What the FICA are you taking out of my check?" 😀

[@TheUtuber999]

You're probably old enough to be glad FICA is taken out of paychecks. 😉