Talk:VIC-20

message: 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)
replies: text: 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)
replies: text:  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)

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

text:  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)
replies: text:  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)
thread_title:  Onboard Memory 

message: 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)
thread_title:  Commodore VIC-20 A/V 

message: 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)
thread_title:  Comments 

message: Did the 20 in the name have any significance? boffy_b 13:11, 24 August 2006 (UTC)
replies: text: 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)
thread_title:  Name 

message: 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)
replies: text: 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)

text: 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)
replies: text:  VC-20 was the name used in Germany, because "VIC" is vaguely obscene there. WHPratt (talk) 14:58, 26 February 2009 (UTC)
thread_title:  Picture 

message: 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)
thread_title:  Binary prefixes 

message: 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)
replies: text: 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)
replies: text:  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)

text: 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)
thread_title:  Why 5K of RAM? 

message: 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)
replies: text:  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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
replies: text:  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)
replies: text:  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.
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)
thread_title:  Mention of Amiga Computer 

message: 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)
thread_title:  1540 floppy drive 

message: 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)
replies: text: Well spotted. :) - Bilby (talk) 04:40, 2 August 2010 (UTC)
thread_title:  PET 

message: "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)
replies: text: 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)
thread_title:  What??? 

message: 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)
—<B>Torchiest</B> talkedits 18:22, 28 February 2016 (UTC)
thread_title:  Saving external links 

message: 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)
thread_title:  What was displayed at Winter CES 1980? 

message: 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)
thread_title:  BASIC memory 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 09:56, 11 August 2017 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: 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)
thread_title:  Ports and sockets. 

message: 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)
replies: text: 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)
thread_title:  Units Sold? 

message: 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)
thread_title:  Germany stuff in the lede 

message: :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)
replies: text: Commodore 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)
thread_title:  Requested move 1 September 2022 

message: 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  tag.
CapnZapp (talk) 16:37, 31 January 2023 (UTC)
replies: text: "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)
replies: text:  If you feel you can resolve this better than the  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...
* 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)
thread_title:  MOS:COMPUNITS