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

5 ай бұрын

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

@damouze

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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

5 ай бұрын

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

@monarch73

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

@James_T_Quirk

5 ай бұрын

Do you read ? @@AaronOfMpls

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.

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

5 ай бұрын

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

@arlasoft

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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!

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!

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

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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

Great video, Robin! I learned a lot.

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

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

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

@greggoog7559

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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

@8_Bit

5 ай бұрын

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

@mikegarland4500

5 ай бұрын

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

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.

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

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.

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

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

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.

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

5 ай бұрын

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?

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

Love the ballad at the end!

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

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.

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

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

@8_Bit

5 ай бұрын

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

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

5 ай бұрын

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

5 ай бұрын

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

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?

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

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

5 ай бұрын

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

5 ай бұрын

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

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.

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.

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

4 ай бұрын

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!

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

5 ай бұрын

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

5 ай бұрын

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

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.

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

5 ай бұрын

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

@vytah

5 ай бұрын

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

Thank you for the amazing videos! :3

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

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)

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

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

5 ай бұрын

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

5 ай бұрын

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.

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.

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

5 ай бұрын

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

5 ай бұрын

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

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

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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

@8_Bit

5 ай бұрын

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

5 ай бұрын

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

@8_Bit

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

@@8_Bit 16/32

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

5 ай бұрын

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

5 ай бұрын

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

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.

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

@8_Bit

5 ай бұрын

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.

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

5 ай бұрын

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

5 ай бұрын

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.

Your voice is very relaxing.

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

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

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

@TheUtuber999

5 ай бұрын

Unless it's between 55 and AA.

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!

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

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

Fascinating stuff.

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

5 ай бұрын

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

5 ай бұрын

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

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

5 ай бұрын

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

19 күн бұрын

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

"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

5 ай бұрын

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

5 ай бұрын

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

@AaronOfMpls

5 ай бұрын

"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

5 ай бұрын

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

5 ай бұрын

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

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

5 ай бұрын

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.

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

5 ай бұрын

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

5 ай бұрын

Oh, you're just typing without pressing enter

@8_Bit

5 ай бұрын

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

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

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.

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

4 ай бұрын

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.

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

5 ай бұрын

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

@HojoNorem

5 ай бұрын

IIRC, the colour ram is only 4 bits wide.

@CrassSpektakel

5 ай бұрын

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

@CrassSpektakel

5 ай бұрын

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

@HojoNorem

5 ай бұрын

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

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

@8_Bit

5 ай бұрын

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

5 ай бұрын

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

Absolutely! Yes please, more msx videos!

I always wished the C64 had a RAM expander that was usable by C64 BASIC and the user (Like the Vic20) Not even emulators today have that feature.

@8_Bit

5 ай бұрын

Yes, it would take a substantial modification to C64 BASIC to support any RAM expansion because of the 64K limits I discuss in this video. It was easy for the VIC-20 because the RAM expanders just filled in empty space in the VIC-20 memory map. On the C64 it already shipped with the memory map completely full, so a lot of extra "juggling" will have to happen to support extra RAM.

@andyc8257

5 ай бұрын

​@@8_BitYeah, it's tricky with the C64 architecture. The ZX Spectrum and Amstrad CPC machines (which were the big contenders in the UK) were able to be more easily extended to 128K or above because the Z80 has an independent 16-bit IO space so registers for adding paging functionality could be easily added to the design without causing conflicts.

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

5 ай бұрын

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

5 ай бұрын

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

@8_Bit

5 ай бұрын

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

5 ай бұрын

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

@borayurt66

5 ай бұрын

@@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" 😁

Brings back some good memories (literally) :>

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.

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

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

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

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

5 ай бұрын

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.

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

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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

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

There is another way to explain signed numbers that most people find easier to understand. The bits are worth 1, 2, 4, 8 .... etc but the most significant is taken as -32768 instead of +32768.

@8_Bit

5 ай бұрын

Interesting, I don't think I've heard of that way of looking at it before.

@kensmith5694

5 ай бұрын

@@8_Bit It is a "once you see it" sort of thing.

Waiting for the Christmas special...

Kilobytes forever!!! I hate that the SI decided it was their right to just take over and push out 50 years ( or more ) of prior use.

@NuntiusLegis

5 ай бұрын

I can see your point, but it must be admitted that the new system has the logic on it's side.

@MurderMostFowl

5 ай бұрын

@@NuntiusLegis I disagree. Bytes is a made up term for 8bits, but is inherently a unit on its own based on base2 numbers. The prefixes should be used as the inventors intended. A kilometer expressed in inches would not be 1 kibbinch… it makes no sense. But, I admit, what’s done is done. Another part of this that makes me a little more cynical is that the only people who benefit from the renaming is storage manufacturers.

@NuntiusLegis

5 ай бұрын

@@MurderMostFowl But it is quite clear that kilo means 1000 all over the place, so I always felt in kilobyte = 1024 bytes it is only a loose analogy. Robin is making a strong point though with the plethora of classical computer literature becoming obscure should the original meaning become forgotten.

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

5 ай бұрын

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

@TheUtuber999

5 ай бұрын

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

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.

One bajillion points awarded for that jab at the modern kibibytes and similar nonsense. :) Is it possible to access that other RAM from within BASIC? Long ago I began writing an adventure game for the C64; never finished it (interupted by uni), but I recall quickly realising that memory would be a problem for the kind of game I had in mind. When I later wrote a word processor in BASIC for the Beeb, I got round the memory capacity issue by storing the text on floppy; scroll through a document and the floppy drives whirs away. :D Was fun running the word-count procedure. Alas back then I never got to meddle with the C64 further (the machine belonged to friend, though now I have several of my own). Plan on doing so in years to come; recently my friend found the old tapes which should include the game I was working on. Excellent video thanks!!

@8_Bit

5 ай бұрын

The $C000-$CFFF area can be accessed directly by BASIC, but I can't think of a way for BASIC to read the area under the BASIC or KERNAL ROM without a bit of help from a machine language routine. It wouldn't take all that much code to support it though.

@vytah

5 ай бұрын

When you poke into ROM, the write goes into RAM under it (which is one way you can detect whether the ROM is banked in: poke and see if you can peek the same value). Reading from the underlying RAM from BASIC is not possible, but you could write a tiny machine language procedure, store it somewhere, and call it with USR or SYS.

@mapesdhs597

5 ай бұрын

@@8_Bit ​ @vytah - Thanks for the replies! Sounds like a bit of asy would be required to do anything useful, not something I've done on the C64 so far. OTOH, occurs to me that back when I was designing the game (when I was 15), which was mainly a text adventure, I did not yet know about text compression techniques. Quite possibly some simple compression methods could solve the memory capacity issue, eg. tokenised words or combinations thereof. Something to ponder for the future.

@mapesdhs597

5 ай бұрын

PS. If you fancy some drool fuel, here's a pic of my Commodore stash: www.sgidepot.co.uk/misc/vintage_Dec2012_05_commodore.jpg

@AaronOfMpls

5 ай бұрын

I actually _like_ the kilobyte/kibibyte distinction myself. But I _do_ wish "kibibyte", "mebibite", "gibibyte", etc didn't sound nearly so silly.

Great deep dive. On the Spectrum 128k the extra memory was referred to as a silicon disk and you could use basic commands such as SAVE,CAT,MERGE with a ! to store and retrieve BASIC programs and data.

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.

Ah, a refresher course.

Hmm, for a minute or two there, I was starting to think that a thing or two in the 64 had a fence-post error. But I see now that it's just this thing with those first 3 special bytes of BASIC. At least... if I understood you right. But of course correct me if you believe I'm wrong. (Also, please watch for any follow-up replies I might have; right now it looks like your comment notifications are still on YT default: "only important" or something like that instead of "all").

@8_Bit

5 ай бұрын

I get too many notifications for them to be of any use. I'll reply if I 1) notice a comment and 2) feel like replying :)

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

@8_Bit

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

@AlexEvans1

5 ай бұрын

@@8_Bithardware jumper.

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.

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

4 ай бұрын

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.

So how does the C128 address 128K?

@8_Bit

5 ай бұрын

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.

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.

@csbruce

5 ай бұрын

Also, C64 BASIC/Kernal was a rushed copy of the VIC-20 BASIC/Kernal, which had no need for bank switching.

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.

@8_Bit

5 ай бұрын

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.

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

5 ай бұрын

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

@8_Bit

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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.