Talk:VIC-20
![]() | This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
![]() | On 1 September 2022, it was proposed that this article be moved from Commodore VIC-20 to VIC-20. The result of the discussion was moved. |
Onboard Memory
As of Dec 3, 2013, the article says 20 KB of RAM (both in the main article and the summary at the size) - later on it more correctly states 5 KB of ram, with only 3.5 kB accessible to basic programming. The 20 KB references should be replaced with 5KB. — Preceding unsigned comment added by 70.76.73.15 (talk) 19:33, 3 December 2013 (UTC)
This article states that the VIC 20 came with 5 KB RAM as standard. However I do believe that it only came with 3.5KB of RAM. Bear in mind that this is based on the UK/PAL version. Also perhaps some of the RAM is taken up by BASIC much like it does on the C64.
Re: Memory Basic free memory is 3.5K on a stock machine (3583 bytes). However, the overall RAM in the machine is 5K plus 1K x 4bits colour RAM for the VIC chip. The operating system uses 1K and screen character memory takes up the remaining 0.5K. 209.5.225.86 19:20, 17 April 2006 (UTC)
I believe that the Vic-20 came with a total of 20K of RAM, but only 5K was available for programming in BASIC. Kaydell (talk) 00:53, 20 October 2008 (UTC)
- No. The "20" had no particular significance with regard to its stock amount of memory. Toward the end of its run, the VIC 20 was sold as the "Vic 21" which was merely a VIC 20 sold together with a 16K memory cartridge. 95.209.102.165 (talk) 12:17, 20 May 2011 (UTC)
- One detail: this was never an official designation. This was something the New England Lechmere department chain came up with. Source: InfoWorld March 28, 1983, pages 1 and 6. CapnZapp (talk) 18:31, 1 February 2023 (UTC)
- No. The "20" had no particular significance with regard to its stock amount of memory. Toward the end of its run, the VIC 20 was sold as the "Vic 21" which was merely a VIC 20 sold together with a 16K memory cartridge. 95.209.102.165 (talk) 12:17, 20 May 2011 (UTC)
The standard Vic-20 came with 5K RAM installed as follows:
1K 0-1023 System RAM (1K used) 3K 1024-4095 empty - 3K RAM expansion area 4K 4096-7679 BASIC program user area (3583 bytes free) 7680-8191 Screen text memory (~0.5K used) 24K 8192-32767 empty - 24K RAM expansion area
VIC RAM expansion is complicated. There were four RAM expansion banks: 1 bank for adding 3K RAM in between the installed RAM, and 3 banks for addng 8K RAM each at addresses 8192, 16384 and 24576. With 24KRAM expansion added at 8192, usable BASIC memory was over 27K RAM with the screen address moved to address 4096 and the start of BASIC user memory moved to address 4609. A fully loaded VIC 20 has 32K RAM locations; however, the video chip is hard wired to the 4096-8191 bank of RAM and screen memory must be there. The system start up checks for the largest contiguous RAM and places the screen memory at either 7680 for the 3K RAM expansion or at 4096K for 8K or more RAM added at address 8192. Different memory test locations can be poked into start of RAM (641 byte addr, 642 page addr) and top of RAM (643 byte, 644 page) with a sys64818 call to reset the system to believe it has a more limited RAM allocation. ROM and system memory is as follows:
4K 32768-36863 ROM Character Sets 1K 36864-37887 Chip Registers 1K 37888-38911 Screen color memory (weird 4 bit RAM memory locations, 2 banks of 512 nybbles @ 37888 and 38400) 2K 38912-40959 unused, reserved for IEEE interface 8K 40960-49151 ROM Expansion (program or game cartridges) 8K 49152-57343 ROM CBM BASIC (Microsoft ver 2) 8K 57344-65535 ROM System Kernal
A bare-bones VIC 20 thus had 5K RAM, 4K ROM character sets, 1K color memory, 8K ROM Basic and 8K ROM System Kernal, with expansion for upto 27K RAM and 8K ROM, with some memory locations mapped to address chip registers.
I had a VIC 20 with the Superexpander cartridge (3K RAM expansion and 8K ROM BASIC extension) piggy-backed on a 24K RAM expansion. In BASIC mode, screen memory was address 4096, start of user BASIC was 4609; after invoking BASIC graphic mode, start of user BASIC mode was moved to address 8193, with the whole 4096-8191 RAM block dedicated to the video chip. Naaman Brown (talk) 16:54, 24 September 2009 (UTC)
- You're mostly correct, except for one thing: The VIC chip was limited to the first 8K bank of memory, not specifically to 4096-8191 as you state. So, in theory, if you had both a 3k expander and the 24k expander, you could move the screen memory to 1024 by POKEing a few registers (but not below that, since the first 1k was used for vitally important system functions). There wasn't much point in doing so; I'm just saying that you could have done so. In any event, if you had both a 3k and an 8k (or 16k or 24k) expander, the 3K 'hole' between 1024-4095 was useful for storing custom character sets and/or machine language routines without having to futz around with RAMTOP pointers to 'reserve' memory (like the 4K 'hole' at 49152 in the Commodore 64). 67.61.121.158 (talk) 21:04, 5 October 2013 (UTC)
- For those of you who never programmed the VIC 20 or Commodore 64 who might want to know why you had to reserve memory for custom character sets or machine language routines - Commodore BASIC stores numeric variables at the end of your program, filling from the bottom up. String variables were stored at the top of RAM, from the top down. If your program used any strings, and you didn't move RAMTOP to reserve memory, your custom character set would be overwritten by the strings. (Yes, I know the way strings are stored is slightly more complicated than that, but there was no need for excessive detail... a simplified explanation gets the point across.) 67.61.121.158 (talk) 21:13, 5 October 2013 (UTC)
- Furthermore, the VIC-I chip can only address internal memory, so adding a 3K memory expansion only can be used by the CPU - programs in BASIC or machine code, data which the 6502 will read. You can not put the screen matrix nor custom character definitions in that hole, unless you piggy-back solder RAM chips inside the computer, which has been done by some people but is not standard. I've been programming this machine for so many years and tried to do it with success, so I'm sure. Earlier revisions of VIC-20 emulators like VICE omitted this fact so they allowed for advanced programs not runnable on real hardware, but it has been fixed since a couple of years ago. Carlsson~svwiki (talk) 13:15, 8 April 2016 (UTC)
- Ahh, that explains things and corrects a misunderstanding I had. Further research indicates that you are correct... the VIC chip could access internal RAM only. Thank you for correcting me. 24.117.80.197 (talk) 02:00, 6 May 2016 (UTC)
Fixed • Sbmeirow • Talk • 01:13, 4 December 2013 (UTC)
Graphics modes
The article talks about hi-res graphics being available at 160*160. I don't recall there being a limitation on the grid size other than the 176*184 - anyone know differently? —The preceding unsigned comment was added by 193.61.96.249 (talk) 15:45, August 21, 2007 (UTC)
There is no such restriction to 160x160, either theoretical or practical.
For character-based display, any size up to aproximately 28 x 36 characters is displayable on PAL displays (for NTSC displays this becomes approx 25 x 30). To bitmap a screen however (ie taking control of each individual bit) then the display must fit within 4k, as the VIC-I chip can only address internal memory. The 4K must also contain the screen memory, unless the user wants to place the screen in the first 1K of memory (eg in zero-page) Displays of 192x160, 160x192, even 184x176 (not 176 x 184 though due to the use of 16-byte high characters to represent the bitmap) are therefore possible.
160*160 was used by Commodore's 'Superexpander' cartridge to represent 'high-resolution' screens, perhaps this is where this piece of information came from.
Commodore VIC-20 A/V
I just fixed my old VIC-20, and I have no idea how to use the A/V cable. I'm not A/V-literate, so I'm having trouble. The color code is red, but that means audio nowadays, so I know something's changed. Anyone have any idea? Thanks. --70.119.19.133 22:47, 12 February 2006 (UTC)
Re: Video cable I have one here. Typically yellow=luma, red=chroma, white=audio. You can safely try all the outputs on cable to the video input of the TV until you get a picture. If none of them generate a picture, you either have a dead VIC or bad cable. Go over to Denial forums for more help (see the links). 209.5.225.86 16:00, 5 April 2006 (UTC)
As far as I remember, the Vic20 output adapter provides RF output and not 'AV' output (as people today may know of AV output as a 'yellow' RCA video connector). The red colour of the connector probably has little relevance to today's connections?. You will need a slightly less than commmon TV aerial (RF) cable which has an RCA connection at one end to a common RF connector at the other end. Place into the input of your TV, and then you'll need to tune in the TV channel that allows reception of the Vic20 signal. I think this was the 0 or 1 channel on TV's of the day, but of course, now-days everything is different and it's probably simpler to just "auto-search" until the start page appears? Mmmaaarrrkkk (talk) 14:14, 15 September 2008 (UTC)
- Please use the 'Discussion' section to 'dicuss the article', not your personal technical problems. There are forums to do that.
Comments
Moved here this comment from the main page:
(and, frankly, not so unlike the TRS-80 Model I – a possible inspiration?)
At18 19:48, 6 Sep 2003 (UTC)
Name
Did the 20 in the name have any significance? boffy_b 13:11, 24 August 2006 (UTC)
No, other than it sounded nice to the marketers at Commodore at the time. 209.5.225.86 18:18, 18 September 2006 (UTC)
- Yes. Sorta of. The number was to be VIC-22, based on the screen width, but it was rounded down to 20 to sound friendlier. This was the published story of the day in whatever magazines I had - maybe Compute's Gazette (or Family Computing). --199.3.104.138 15:06, 30 November 2006 (UTC)
Michael Tomczyk is reported as saying: "VIC sounded like a truck driver, so I insisted on attaching a number. I picked ‘20’ and when Jack Tramiel asked, ‘Why 20?’ I replied, ‘because it's a friendly number and this has to be a friendly computer.' He agreed." Source: http://www.old-computers.com/museum/computer.asp?c=252 —Preceding unsigned comment added by JustSomeGuyToo (talk • contribs) 06:18, 8 January 2008 (UTC)
I recall reading in the Programmers reference guide way back in 1982-83 that the "20" referred to the 20K of ROM that the orginal VIC-20 came with. This was later continued with the Commodore 64 (or C64 as is was abbreviated to) but this time the "64" referred to the amount of RAM. (I have just checked for this guide at and found that the VIC-20 ROM was located within the 64KB address space of the 16bit address register as follows: addr (hex)
8000-8FFF 4K Character ROM;
C000-DFFF 8K BASIC ROM;
E000-FFFF 8K Kernal ROM;
Reference: http://www.geocities.com/rmelick/prg.txt, figure 3-5, page 115.) 59.101.2.201 20:52, 4 April 2007 (UTC)
- I've taken the liberty of correcting the above: C000-DFFF, not C000-BFFF as the original writer said. -- 85.183.213.23 21:12, 2 June 2007 (UTC)
Why are we using a hyphen in "VIC-20"? The VIC 20 computer case label, the box packaging, the brochure, the print and TV ads, they all were "VIC 20", not "VIC-20". The case badge for the VIC-1001 (Japanese VIC 20), as well as competitors like the TRS-80 and TI-99/4A, all had a hyphen, and so did the internal docs of the VIC-II chip. But this should not influence the correct entry of the VIC 20, should it? —Preceding unsigned comment added by Hi-Toro (talk • contribs) 16:34, 28 January 2009 (UTC)
I used to own a VIC-20 and read that VIC came from Video Interface Chip TTFN Chunner (talk) 17:16, 22 August 2012 (UTC)
Picture
Is is picture of the VIC-20 actually a VIC-20? Although some later VIC's had grey function keys, the case appears to be a C64 tone. Should we update this perhaps?
- Since this is an Image taken from eBay, a new one is badly needed. The resolution is low, the logo is disturbing and the uploader might not be the photographer. --UbeMarsh 07:26, 8 May 2007 (UTC)
- It's a VIC20 with a Commodore 64 keyboard. I agree a 'real' VIC20 would be better. 203.14.156.193 (talk) 05:04, 23 March 2008 (UTC)
I removed the low-quality eBay picture with a hi-res version I took. Looks much better. This is long overdue.
cbmeeks —Preceding unsigned comment added by Cbmeeks (talk • contribs) 00:07, 10 September 2007 (UTC)
- I'm fairly certain some late VICs were manufactured in C-64 cases
Not really possible, since the VIC-20 has a different rear port configuration. However, I have seen late generation VIC's with white cases and 64 grey keyboards. —Preceding unsigned comment added by 209.5.225.86 (talk) 17:46, 11 December 2007 (UTC)
- VC-20 was the name used in Germany, because "VIC" is vaguely obscene there. WHPratt (talk) 14:58, 26 February 2009 (UTC)WHPratt
The current picture is definitely a Commodore 64. There are numerous VIC-20 pics available online. Why hasn't this been changed? —Preceding unsigned comment added by Mortarmopp (talk • contribs) 15:40, 18 February 2010 (UTC)
Binary prefixes
Recently changes have been made to this article to use binary prefixes (KiB, MiB, kibibyte, mebibyte etc). The majority of reliable sources for this article do not use binary prefixes. If you have any thoughts/opinions then this specific topic is being discussed on the following talk page Manual of Style (dates and numbers) in the sections to do with "binary prefixes". Fnagaton 10:26, 25 April 2007 (UTC)
Why 5K of RAM?
I understand why the 3K "hole" in the memory map exists, given that there are 5K of RAM: you need to have the zero page ($00xx) and the stack page ($01xx) on any 6502 system, and having the built-in memory end at $1FFF makes expansion easier than it would be if the RAM ended at $13FF. But why was 5K memory size chosen in the first place? It would seem that 4K or 8K are the more logical choices. -- 85.183.213.23 21:16, 2 June 2007 (UTC)
- it probably had more to do with cost considerations than anything technical. (i.e. including 6k of ram would have bumped the computer's price up substantially) —Preceding unsigned comment added by 69.125.110.223 (talk) 21:14, 17 December 2007 (UTC)
- They used 1024x4b static ram chips. Thus every extra kilobyte would add 2 such chips to the board. —Preceding unsigned comment added by 193.238.96.4 (talk) 14:54, 6 February 2010 (UTC)
- static ram in 1981 was expensive; 4K would have left the user 2.5K (after first K for the 6502 and 512 bytes screen memory were deducted) which was too little; 8K apparently would have upped the price too much. You could write usable programs in 3.5K of user memory. A lot of folks did buy the 3K expander for 6.5K user memory: but it was a significant cost for a home user.--Naaman Brown (talk) 17:01, 13 October 2013 (UTC)
Mention of Amiga Computer
The Amiga was NOT a 16 bit computer, but a 32 bit computer. The Motorola 68000 CPU was often called a 16-/32-bit processor, hence the misunderstanding by journalists that the computer would be 16-bitted. The 68000 had at least 16 general purpose registers (data/address) that were 32 bitted. Instructions like "MOVE.L" summoned a 32-bit execution, while "MOVE.W" were 16-bitted. AmigaOS was fully 32 bitted, using a flat memory model, and the 68000 itself had only 24 address lines (for 16 MB max) but the 68020 expanded that to the full 32 address lines (which made memory up to 4 GB possible, in theory). That's why there were Amigas equipped with 256 MB of RAM for graphics and video purposes already in the early 90ies, long before such large memory was used in PCs.
- Not accurate. While the processor in the Amiga 500 is capable of using 32 bit quantities the external data-bus interface to the CPU is 16 bits wide ergo it is a 16 bit computer. For your information the StrongARM processor is capable of manipulating 64 bit quantities with its long multiply and accumulate instructions but this does not however make the Acorn Risc-PC a 64 bit computer. Fnagaton 09:25, 29 July 2007 (UTC)
- By that definition , i386SX would be a 16bit CPU while i386DX a 32bit one, which is clearly not the case. Also many mid-to-high-end GPUs would be 256 or 512bit processors. Not to mention Pentium IV FSB width. (22:28, 31 August 2007 (UTC)) —Preceding unsigned comment added by 83.245.252.197 (talk)
- Whatever the marketing efforts of compaines selling chips, the strict thruth is that the number of bits of a processor should represent the external data bus. For this reaons the Super NES was not really a 16 bit machine, for example, as it still only had an 8 bit external data bus. At least as I understand it, happy to be proven wrong.Dndn1011 22:30, 1 September 2007 (UTC)
- Read up on http://en.wikipedia.org/wiki/32-bit , http://en.wikipedia.org/wiki/64-bit and http://en.wikipedia.org/wiki/16-bit for starters. A bad compromise would be to take the smallest of a CPUs ALU register width(not 64/128 bit FPU/vector/SSE reg width), address bus width, or data bus width. Sort of works on 32/36/64 bit CPUs (eg. Pentium II/III), not so well on 16/32 bit (386sx, 68000) or 8/32 bit ( 68008, a 68000 variant with 8-bit databus). 193.229.159.16 09:50, 2 September 2007 (UTC)
- The original 68000 was a largely 16 bit datapath (16-bit ALU) with a 32-bit microcoded instruction set. 32-bit arithmetic was executed by double-pumping the 16-bit datapath. Against the backdrop of the "race for more bits" among video game systems, you still see SEGA calling the 68K "16 bit," not 32. So, calling 68000 16-bit isn't unwarranted. The 65816 is also similarly 16 bit, again not due to bus width, but rather due to the native width of the instruction datapath. Going by external bus width doesn't make a lick of sense if you look across the full range of processors. Some processors don't even have an external bus that you can measure the width of! --Mr z (talk) 07:48, 2 May 2009 (UTC)
- Using the width of available general-purpose registers makes most sense, as that is what users see. After all, the difference between a double-pumped 16-bit datapath and a single-pumped 32-bit datapath (likewise for data bus width) is just a matter of twice the effective speed. In contrast, the difference between 16-bit registers and 32-bit registers (assuming similar available operations on them) is tremendous for an assembler programmer and not just a matter of "needs more instructions, thus is slower". Just compare 68k assembler programs to 8088 assembler. The segmented memory model stemming from the 16-bitness of the latter has haunted application developers for decades, even in languages like C ("Do I need to compile this program in small, medium, or large memory model?"). It even affected end users: think about the MS-DOS XMS/EMS mess. Developers and users of 68k machines laughed about such issues. -84.129.167.174 (talk) 20:01, 2 November 2009 (UTC)
- The only bit width that matters is the general purpose operand width in CPU's ISA. The same ISA may have different hardware implementations but will run same code seamlessly. For example, PDP-11 is canonical 16bit machine but it had both 16bit and 8bit ( [[LSI-11] ) hardware implementations. The external bus width is of lowest importance since it only affects the memory speed.
- Using the width of available general-purpose registers makes most sense, as that is what users see. After all, the difference between a double-pumped 16-bit datapath and a single-pumped 32-bit datapath (likewise for data bus width) is just a matter of twice the effective speed. In contrast, the difference between 16-bit registers and 32-bit registers (assuming similar available operations on them) is tremendous for an assembler programmer and not just a matter of "needs more instructions, thus is slower". Just compare 68k assembler programs to 8088 assembler. The segmented memory model stemming from the 16-bitness of the latter has haunted application developers for decades, even in languages like C ("Do I need to compile this program in small, medium, or large memory model?"). It even affected end users: think about the MS-DOS XMS/EMS mess. Developers and users of 68k machines laughed about such issues. -84.129.167.174 (talk) 20:01, 2 November 2009 (UTC)
- The original 68000 was a largely 16 bit datapath (16-bit ALU) with a 32-bit microcoded instruction set. 32-bit arithmetic was executed by double-pumping the 16-bit datapath. Against the backdrop of the "race for more bits" among video game systems, you still see SEGA calling the 68K "16 bit," not 32. So, calling 68000 16-bit isn't unwarranted. The 65816 is also similarly 16 bit, again not due to bus width, but rather due to the native width of the instruction datapath. Going by external bus width doesn't make a lick of sense if you look across the full range of processors. Some processors don't even have an external bus that you can measure the width of! --Mr z (talk) 07:48, 2 May 2009 (UTC)
- Read up on http://en.wikipedia.org/wiki/32-bit , http://en.wikipedia.org/wiki/64-bit and http://en.wikipedia.org/wiki/16-bit for starters. A bad compromise would be to take the smallest of a CPUs ALU register width(not 64/128 bit FPU/vector/SSE reg width), address bus width, or data bus width. Sort of works on 32/36/64 bit CPUs (eg. Pentium II/III), not so well on 16/32 bit (386sx, 68000) or 8/32 bit ( 68008, a 68000 variant with 8-bit databus). 193.229.159.16 09:50, 2 September 2007 (UTC)
- Whatever the marketing efforts of compaines selling chips, the strict thruth is that the number of bits of a processor should represent the external data bus. For this reaons the Super NES was not really a 16 bit machine, for example, as it still only had an 8 bit external data bus. At least as I understand it, happy to be proven wrong.Dndn1011 22:30, 1 September 2007 (UTC)
So strictly speaking 68000 is a 32 bit CPU. But there is also a marketing classification which has no practical sense except for it is roughly based on the overall performance class. 68000 is typically dubbed a 16 bit simply because it has a performance on the level with true 16bit CPU's like 8086/186/286. On the other hand, neither i8088 nor 68008 are called a 8bit CPU even though they have a 8bit data bus, because their performance is significantly higher than the 8bit CPU's. —Preceding unsigned comment added by 193.238.96.4 (talk) 14:49, 6 February 2010 (UTC)
1540 floppy drive
The article states that "the VIC 20 did not originally have a disk drive available for sale [...]". However, Commodore did produce the Commodore 1540 disk drive unit which only works on VIC-20s. How should these two details be reconciled? --Mr z (talk) 07:31, 2 May 2009 (UTC)
When VIC 20 was first put out, there was only the Datasette tape drive. The disk drive was put on the market later. Naaman Brown (talk) 19:43, 28 September 2009 (UTC)
PET
Changed it so that the Predecessor is not the Commodore CBM-II but the Commodore Pet. CBM-II was released in 1982, while the Vic-20 was released before. —Preceding unsigned comment added by 213.163.71.100 (talk) 04:37, 2 August 2010 (UTC)
- Well spotted. :) - Bilby (talk) 04:40, 2 August 2010 (UTC)
What???
"Television personality Henry Morgan (best known as a panelist on the TV show I've Got A Secret) became the ironic voice on a series of clever Commodore product ads."
I'm feeling pretty positive that Henry Morgan was best know of either Dragnet or MASH at that time, since MASH was one of the top rated shows of the time.
You're thinking of Harry Morgan who played Col. Potter on M*A*S*H and Officer Gannon on Dragnet.
Here is a VIC20 TV commercial and the VO is definitely Henry Morgan, the IGAS panelist.
https://www.youtube.com/watch?v=CLvu3DH32CI
- Henry Morgan was a different guy, and did not appear on Dragnet. WHPratt (talk) 20:28, 20 October 2011 (UTC)
- And, I would still maintain [in my comment only just removed here] that "ironic" -- in the sense of employing irony -- describes his delivery better. Were he truly "iconic," he'd be less obscure to present-day readersthan Harry Morgan, and the above debate suggests that he isn't. It's nicer than saying "sarcastic."
WHPratt (talk) 13:50, 7 November 2020 (UTC)
Saving external links
These links were removed in a recent edit, but some of them could be good sources for article expansion, so I'm saving them here:
- VIC-20 Gamer - Videos of games produced for the Vic 20
- Rick Melick's Commodore VIC-20 Tribute Page
- atarimagazines.com: A 40/80 Character Expansion For The VIC-20 (Compute!, November 1982)
- sleepingelephant.com: 40 and 80 column boards
- "The VIC 40-Column Operating System / Turn Your VIC 20 into a PET" (Ahoy!, October 1984)
—Torchiest talkedits 18:22, 28 February 2016 (UTC)
What was displayed at Winter CES 1980?
I understand a prototype was on display at Winter CES on January 5, 1980, but was it the TOI, Yannes' MicroPET or even the Vixen? I have a printed magazine source from 1982 that mentions a private suite at CES where the prototype was displayed, but I'm too lazy and confused to look up which one it was, perhaps it is mentioned in Bagnall's book?
The same magazine explicitely mentions the VIC-1001 was launched in Japan on October 10, 1980, two months ahead of schedule and that 24.000 units were sold over night. This probably should go into the main article with proper source credit, but there got to be additional sources about this. It also says the US launch took place in March 1981, that the PAL 6561 VIC-I chip was finished testing in June and out of 125.000 preordered VIC-20's, the first batch of European VIC's reached the UK and Germany in October 1981, and rest of Europe following in small volumes in November - for instance only about 1.000 machines sold in Sweden before New Year. Carlsson~svwiki (talk) 13:25, 8 April 2016 (UTC)
BASIC memory
The infobox says "3.5 KB for BASIC (expandable to 30.5 KB)." This is incorrect. Note the memory map in the "Memory expansion" section. Ignoring the screen RAM, having a 3k expansion below the built-in RAM and 24k of expansion RAM above it would yield a contiguous block of 31k. Presumably, the editor who added that number was thinking of this block with the screen RAM moved to one end (since the screen RAM is 512 bytes). However, the screen RAM can't be moved to expansion memory, it must stay within the 4k that is built-in. That means the largest contiguous block would be created by moving the screen RAM to the bottom of the built-in memory, and installing 24k of expansion memory above it, yielding a 27.5k block. The BASIC memory must be a single contiguous block, so this is the maximum amount possible. 98.27.182.28 (talk) 23:10, 6 January 2017 (UTC)
External links modified
Hello fellow Wikipedians,
I have just modified one external link on Commodore VIC-20. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Added archive https://web.archive.org/web/20150214213644/http://michaeltomczyk.com/Tech-Pioneer.php to http://www.michaeltomczyk.com/Tech-Pioneer.php
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}}
(last update: 5 June 2024).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.—InternetArchiveBot (Report bug) 09:56, 11 August 2017 (UTC)
Ports and sockets.
The paragraph under this heading states that the expansion port used a proprietary connector. This is completely incorrect. The card edge connector for the expansion port was one of the most widest available out there. MANY companies, including EVERY Radio Shack store in the country, sold proto-board PC boards (breadboard style layout for traces) as well as perfboards (pad per hole) with the exact card edge to fit the VIC-20. I did several such projects myself, including one with the General Instruments SP0-256 AL2 speech synthesizer using such boards. The card edge was chosen probably because it was widely used in industrial electronics. 174.207.21.10 (talk) 01:27, 21 May 2018 (UTC)
- I think the intended meaning is that the connections, logic sense and pin-out was proprietary. Several other computer companies claimed that their connectors were proprietary when the actual connector was an off the shelf part. Historically, Apple and IBM (not to mention others) have gone to court of such matters. 86.153.135.111 (talk) 17:09, 22 May 2018 (UTC)
Units Sold?
How many of VIC-20 were sold by Commodore? Does anyone have reference(s)? Please add to the "unitssold" field of the infobox, similar to Commodore 64 and Commodore 128. Thanks. • Sbmeirow • Talk • 11:25, 19 February 2019 (UTC)
- Over 2.5 Million units were sold. The actual number is unknown, but it was just under 3 million units. Had it reached 3 million units, You can be sure that Commodore would have celebrated it as they celebrated both the 1 million and 2 million production marks. - Tony K., Melbourne, Florida Commodore Collector/Restorer. 2603:9001:3C04:B286:40B3:96C0:9525:DE03 (talk) 01:37, 27 March 2024 (UTC)
Germany stuff in the lede
Is the chitchat about Germany so important that it belongs in the lede? More like trivia? 85.76.74.229 (talk) 14:25, 19 July 2021 (UTC)
Requested move 1 September 2022
- The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.
The result of the move request was: moved. (closed by non-admin page mover) ASUKITE 18:06, 28 September 2022 (UTC)
Commodore VIC-20 → VIC-20 – "VIC-20" is the name of the computer. "Commodore" is the manufacturer. Precedents include Amiga (instead of Commodore Amiga), TI-99/4A (instead of Texas Instruments TI-99/4A) and Master System (instead of Sega Master System). This is a list of books with VIC-20 or VIC in the title; only 2 include "Commodore". Commodore even published Personal Computing on the VIC-20. Dgpop (talk) 17:46, 1 September 2022 (UTC) — Relisting. – robertsky (talk) 18:01, 8 September 2022 (UTC) — Relisting. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 17:42, 20 September 2022 (UTC)
- Comment. Most computer models are titled this way, if I recall correctly. "TI-99/4A" is very different, since "TI" stands for "Texas Instruments", so the company name is already part of the abbreviation. "Texas Instruments TI-99/4A" would have obvious redundancy. (There was an RM about that last year.) — BarrelProof (talk) 00:49, 3 September 2022 (UTC)
- Support per nominator. VIC-20 is the name of the computer. I agree with the nominator that Amiga is preferred over Commodore Amiga as the computer was originally created by an independent company called Amiga Corporation instead of Commodore, but Commodore then bought this company. It should be noted that this is not a general guideline as Commodore 64 can hardly be moved to 64 or Commodore 128 can hardly be moved to 128. (Disambiguation pages linked intentionally to illustrate my point). JIP | Talk 00:58, 27 September 2022 (UTC)
MOS:COMPUNITS
Reading MOS:COMPUNITS we are clearly being told to choose "The definition most relevant to the article" as "primary" for our article. This way we only need to "specify wherever there is a deviation from the primary definition".
In plain English: assume either prefix and tag instances where we use the other only.
For this article, we obviously use the binary prefix throughout, so having that as "primary" is a no-brainer. We do not then need to tag each or even most instances where this primary usage is meant.
This article previously sported no less than 19(!) instances of the {{binpre}}
tag.
CapnZapp (talk) 16:37, 31 January 2023 (UTC)
- "The definition most relevant to the article" as "primary" is K=1024 here, no argument. However, MOS:COMPUNITS clearly tells us there's nothing obvious in an article: Disambiguation should be shown in bytes or bits, with clear indication of whether in binary or decimal base. It's likely obvious for an IT aficionado, but not so for a casual reader and those we need to write for. MOS:COMPUNITS doesn't really provide clear guidance on how to do this. I'd be happy with some kind of headnote that settles the issue but I don't have a good idea how to do it. And perhaps it would be appropriate to discuss the general issue on MOS instead of here. --Zac67 (talk) 21:09, 31 January 2023 (UTC)
- If you feel you can resolve this better than the
{{binpre}}
tag, feel free. (That tag's main problem, in my opinion, is being indistinguishable from how a reference footnote looks like.) Other than that, I would like everybody to agree to the following. Look at these two bullet points from MOS:COMPUNITS...
- If you feel you can resolve this better than the
- The definition most relevant to the article should be chosen as primary for that article, e.g. specify a binary definition in an article on RAM, decimal definition in an article on hard drives, bit rates, and a binary definition for Windows file sizes, despite files usually being stored on hard drives.
- Where consistency is not possible, specify wherever there is a deviation from the primary definition.
...together they pretty clearly tells us not to specify "wherever" when there isn't a deviation from the "primary" definition. In other words: since this article never deviates from its primary definition, I would expect one (1) instance of KB defined. (I left two. Still much better than 19) CapnZapp (talk) 18:09, 1 February 2023 (UTC)