A8 vs C16/Plus4

[JamesD]

Yes it is, but i'm not entirely sure why demonstrating that it's less useful than another option somehow negates it being useful in it's own right. A speed increase for around a third of the CPU time on a PAL machine is still a reasonable improvement and being able to go full 2MHz for data crunching helps a lot of tasks too.

 

As for simplicity... type FAST into BASIC 7 on the C128 to activate. =-)

BTW, you leave out the part where that jumbles the VIC II's display and can't be used with the VIC II's display without jumping through hoops.

 

 

That's what the 264 series does essentially, toggling between 1MHz for the parts of the screen where the TED is active and 2MHz for the borders.

I believe I already mentioned how many cycles are gained drawing borders but thanks for your input.

[TMR]

BTW, you leave out the part where that jumbles the VIC II's display and can't be used with the VIC II's display without jumping through hoops.

But that still doesn't stop being useful because there are a few hoops; even with the VIC-IIe screen blanked in BASIC 7's FAST mode there are things like renumbering a BASIC program where it can be put to good use, anything using the VDC display can use it freely as well and the assembly language to keep the 40 column screen enabled is pretty easy. Now abusing the test bit or using the Z80, those are a bit trickier. =-)

[JamesD]

And you are STILL ignoring the entire point

[kool kitty89]

Now, if the 2MHz mode were something the hardware was designed to enable automatically when the VIC II doesn't need to access memory, then that's a different story.

It becomes a whole lot more useful.

 

Is that a hardware or software issue on the C128? Particularly in context of BASIC, if it WORKS but BASIC didn't implement it, than only machine code programs would be able to take advantage of it.

 

 

 

I'm not sure it was just cost, it was also time.

The whole reason the Commodore drives were slow was because they insisted on rushing a product out the door instead of fixing the chip.

A slightly delayed intro of the VIC 20 could have eliminated years of criticism about slow Commodore drives.

 

They could have compromised and made the C64 disks incompatible with VIC-20 disks and drop the problematic drives used with the VIC-20. (without doing something more complicated to allow backwards compatibility)

From what I understand, the slowness was down to code/software (ROM used for the 6502 used as the disk controller and I/O handler onboard the drive) so it shouldn't have even been that big of a hardware change. (bigger change if they went for normal CAV formatted disks or double-density)

 

 

 

 

 

 

 

Atari did not want to draw attention to the fact that the 5200 and the computers shared the same hardware because they wanted to control the 5200's cartridge library. I'm not sure how it would have turned out if the 5200 had used the computer-style cartridges. There would have been massive compatibility issues with the lack of a real keyboard and it would have probably led to tech support headaches.

 

From listening to the Atari employees on the Antic podcast, it seems like Atari originally intended to market the 400 as a console with a keyboard and the natural upgrade path from the 2600 but then decided to keep the divisions completely separate.

Yes, the 5200 was intentionally made incompatible in a rather ineffective scheme to make the system more proprietary. Omitting PIA also saved a little but given the 5200 launched at a price higher than the 400 was being discounted to in late 1982, it seems to have been rather moot (especially compared to the cost-reduced Atari 600 that went unreleased -keeping the 400's keyboard would make it even cheaper).

 

Atari's own internal mismanagement of product volumes and distribution (and real market demand) were the more serious route problems with 'controlling cartridge distribution/sales' on the 2600 itself and the market as a whole, so the 5200 was a rather cynical ... or just oblivious direction to take there. (especially since they had the Atari 3200/Sylvia in development which should have been cheaper, backwards compatible AND potentially more secure -not A8 compatible though, seems to be an upgraded/faster TIA fed by ANTIC with a full 6502C and 2kB SRAM)

 

 

And the omission of PIA and change in memory map would be the bigger issues than lack of keyboard. The system I/O was totally different with POKEY and GTIA handling the controllers rather than the keyboard and pots. (given the keys most games used -especially up to 1982, they also could have introduced a further cut-down 16k 400-compatible system with a simple keypad including only the necessary keys -either on the system, or corded; the numeric keys, some function keys, and the space bar were commonly used iirc -the latter usually for pause) Or really, just keep the 400's cheap membrane keyboard and mate it to the 600's cost-cut circuit board. (with the 1200XL's memory map or just retaining the old 400/800 map and OS ROM for compatibility)

 

 

[JamesD]

Is that a hardware or software issue on the C128? Particularly in context of BASIC, if it WORKS but BASIC didn't implement it, than only machine code programs would be able to take advantage of it.

The high speed mode for the C128 was designed to work with the new video chip in the C128. If you enable it while using the VIC II (the part that is compatible with the C64), it messes up the screen.

You can enable the high speed mode during the vertical blank without messing up the screen because the VIC II doesn't make any memory accesses during that time.

It's usable but you have to enable it at the start and disable it at the end of the vertical blank.

The only way to do that is assembly language.

BASIC does support the fast mode but it doesn't enable and disable it automatically like I just described. It just turns it on or off depending on which command you use.

 

 

They could have compromised and made the C64 disks incompatible with VIC-20 disks and drop the problematic drives used with the VIC-20. (without doing something more complicated to allow backwards compatibility)

From what I understand, the slowness was down to code/software (ROM used for the 6502 used as the disk controller and I/O handler onboard the drive) so it shouldn't have even been that big of a hardware change. (bigger change if they went for normal CAV formatted disks or double-density)

I don't think they really needed to worry about the disk format, just the communications speed.

 

 

 

Yes, the 5200 was intentionally made incompatible in a rather ineffective scheme to make the system more proprietary. Omitting PIA also saved a little but given the 5200 launched at a price higher than the 400 was being discounted to in late 1982, it seems to have been rather moot (especially compared to the cost-reduced Atari 600 that went unreleased -keeping the 400's keyboard would make it even cheaper).

 

Atari's own internal mismanagement of product volumes and distribution (and real market demand) were the more serious route problems with 'controlling cartridge distribution/sales' on the 2600 itself and the market as a whole, so the 5200 was a rather cynical ... or just oblivious direction to take there. (especially since they had the Atari 3200/Sylvia in development which should have been cheaper, backwards compatible AND potentially more secure -not A8 compatible though, seems to be an upgraded/faster TIA fed by ANTIC with a full 6502C and 2kB SRAM)

 

 

And the omission of PIA and change in memory map would be the bigger issues than lack of keyboard. The system I/O was totally different with POKEY and GTIA handling the controllers rather than the keyboard and pots. (given the keys most games used -especially up to 1982, they also could have introduced a further cut-down 16k 400-compatible system with a simple keypad including only the necessary keys -either on the system, or corded; the numeric keys, some function keys, and the space bar were commonly used iirc -the latter usually for pause) Or really, just keep the 400's cheap membrane keyboard and mate it to the 600's cost-cut circuit board. (with the 1200XL's memory map or just retaining the old 400/800 map and OS ROM for compatibility)

I think the original idea of using the 400 as the game console made a lot more sense than the 5200.

 

 

Hindsight is great. We can see the mistakes that were made and speculate as to what could have been but these companies did what they thought was right at the time.

Even if Atari or Commodore did what WE think they should have, there is no guarantee the machines would have been successful.

 

[peteym5]

Looking just at the 8-bits Atari had multiple console systems with incompatibility, they even managed to used the same chipset for the Atari 5200 and make it incompatible with the computer line. I wonder if an issue for both Atari and Commodore were multiple internal units who were developing products independently and saw each other as competition?

 

 

Honestly I thought the 5200 design was a mistake and Atari themselves canceled the console even before Tremial took it over. They were working on building the 7800 when Tremial took over, he had to shelve it because Warner owed money to develop it. Plus many believed the console system was done until the Nintendo became popular. If Atari did something more like the XEGS back in 1982 with everything mapped the same as the computer and did not use those awful joystick ports, it probably had done better. Given the memory prices of 1982, most likely be a 16K system with a modified XL OS. Maybe Atari could had put a 32K cartridge port and sale an adapter to play 400/800 carts. I do not seeing dropping the PIO chip really saving them any money.

[TMR]

And you are STILL ignoring the entire point

No, i'm just disagreeing with it. i spent several years writing C64 code on a battered C128D (which was cheap because it lacked an internal drive and had a fault which prevented it booting into C128 mode that i never got fixed) and relying on 2MHz mode to speed up program assembly, file crunching and numerous other long-winded data juggling jobs; my little cosine curve generator and several bespoke data converters/code unrollers used it from BASIC, the tools i wrote for converting bitplane-based Amiga images or compressing bitmaps into character sets from assembly enabled 2MHz as well. None of this was juggling 2MHz at the borders, but all of it was what i'd call useful.

[JamesD]

No, i'm just disagreeing with it. i spent several years writing C64 code on a battered C128D (which was cheap because it lacked an internal drive and had a fault which prevented it booting into C128 mode that i never got fixed) and relying on 2MHz mode to speed up program assembly, file crunching and numerous other long-winded data juggling jobs; my little cosine curve generator and several bespoke data converters/code unrollers used it from BASIC, the tools i wrote for converting bitplane-based Amiga images or compressing bitmaps into character sets from assembly enabled 2MHz as well. None of this was juggling 2MHz at the borders, but all of it was what i'd call useful.

Just out of curiosity, what year was that and were you in VIC II mode or using the new C128 video mode?

[TMR]

Just out of curiosity, what year was that and were you in VIC II mode or using the new C128 video mode?

The C128D turned up in the early 1990s, but i started on a borrowed C128 with a 1571 around a year after they were released and then moved on to my own using a 1541. i was working in C64 mode using 40 columns on RF for the entire time.

[Bryan]

And the omission of PIA and change in memory map would be the bigger issues than lack of keyboard. The system I/O was totally different with POKEY and GTIA handling the controllers rather than the keyboard and pots. (given the keys most games used -especially up to 1982, they also could have introduced a further cut-down 16k 400-compatible system with a simple keypad including only the necessary keys -either on the system, or corded; the numeric keys, some function keys, and the space bar were commonly used iirc -the latter usually for pause) Or really, just keep the 400's cheap membrane keyboard and mate it to the 600's cost-cut circuit board. (with the 1200XL's memory map or just retaining the old 400/800 map and OS ROM for compatibility)

 

I was assuming that if the 5200 took A8 style carts, it would have been made compatible. The incompatibilities were mostly for the sake of that stupid controller (and to shave any possible parts out of the design).

 

It's hard to say how well it would have worked to massage the 400 into more of a console. It could have been a sleek, black unit with the membrane keyboard possibly sold as an add on. IMO, that's the main purpose of including the console keys anyway- providing a minimal set of gaming keys.

 

It's possible it would have hurt the 800's reputation though, and made it look like a glorified toy.

 

A time machine would answer all these questions.. or we'd obliterate our own existence. One of the two. Anyway, back on topic...

[kool kitty89]

I think the original idea of using the 400 as the game console made a lot more sense than the 5200.

 

 

Hindsight is great. We can see the mistakes that were made and speculate as to what could have been but these companies did what they thought was right at the time.

Even if Atari or Commodore did what WE think they should have, there is no guarantee the machines would have been successful.

 

A lot of the problems with the 5200 are related to the same things that caused the market crash: Atari's poor distribution and market analysis infrastructure giving very flawed feedback on sales volumes and demand and further inflated projections for increasing demand. (and related issues with consumer research and testing)

 

Ray Kassar, I believe, did attempt to utilize Warner's record distribution network and experience to address this fairly early in his time at Atari (one of the more sensible things he did as CEO, if I'm remembering right) but Warner management refused this and thus killed one of the best avenues for avoiding market collapse and Atari's own collapse that they had.

As best as I can gather, the 3200/Sylvia was abandoned less for technical reasons (like STIA not working right) and more for not being 'deluxe' enough, not high end enough. They thought the market wanted a BIG FLASHY EXPENSIVE LUXURY SYSTEM ... per the above disconnect with the market at hand. (failing to realize the big market for something ALMOST AS CHEAP as the 2600 but closer to or better than the IV and CV in performance) Sylvia also could have filled the proprietary format role like the 7800 did with software based lockout. (Atari realizing their OWN cart distribution/sales were so far off base was still the bigger deal, of course ... and realizing they could charge licensing royalties to 3rd parties rather than locking them out entirely would also be a big deal)

 

 

 

It's hard to say how well it would have worked to massage the 400 into more of a console. It could have been a sleek, black unit with the membrane keyboard possibly sold as an add on. IMO, that's the main purpose of including the console keys anyway- providing a minimal set of gaming keys.

 

It's possible it would have hurt the 800's reputation though, and made it look like a glorified toy.

Curt posted a photoshopped nice sleek black 'consolized' Atari 400 a few years back, I'd have to search around a bit to find it again, though.

 

As far as hurting the 800's name, that's down more to marketing than anything, and the C64 had criticism for similar reasons given the 'supermarket sales' route Tramiel pushed. (Atari selling through Sears and electronics dealers would tend to have better customer support than many of the C64's outlets and be less at the mercy of local user groups for said support -all kind of a non-issue in Europe given the tighter-knit community and more precocious consumers on average at the time)

 

 

The Atari 600 wouldn't have had that 'toy' look to it either, full console and keyboard probably better built than the VIC-20 but much cheaper than the multi-board, cast aluminum shielded, 1979 Atari 400. (if they thought the 'toy' keyboard was bad for marketing then they could omit that entirely, at least in the US market) The prototype 600 also had a nice black and silver look to it, none of the beige of the 1200XL, 800XL, or 600XL. (AND a nice top-mounted cart slot like the 600XL and 800XL -it was pretty much a 600XL with slightly different case and different DRAM chips used, but could have been out alongside the 1200XL in 1982)

 

The 600 really seems like the best compromise short of introducing the 3200/Sylvia: it's cheaper to build than the 400, more compact, and has a proper keyboard and could be priced to be competitive with the Colecovision and Intellivision while being much cheaper than the C64. UNLESS you want to go and change the 1200XL's design to retain the 4 controller ports and use different memory mapping and OS. (like plain 48k mapping or up to 62 kB XL-style by banking out the OS ROM ... there's other issues with not using PIA's ports for RAM control though, and cost trade-offs for using various memory mapping techniques -keeping cost down on the Atari MMU is one of the reasons for the incompatibility I believe, and definitely a problem several older 3rd party RAM expansions didn't have)

 

The 3200 was the route to go in 81/82 for something more 7800-like (as far as being a cost-effective compatible development of the VCS) and should have been significantly cheaper than the 600 or 5200. (5200 style controllers wouldn't be too tough either so long as you compromised for a less complete keypad, and 2 instead of 4 controller ports obviously) It should have been able to better undercut the console/computer pricing at the time too.

[kool kitty89]

Oh, and JamesD, another missed option (already in line with some of what you've said) is a 1.79 MHz CPU with interleaved VIC-II accesses provided through an added bus latch (or combination latch/MMU also covering the expanded memory mapping -which might be kind of like what Atari did with FREDDIE, not sure if that allowed interleaving but I recall SOME sort of improved DMA/CPU bus cycle sharing)

 

You could push that to 2 MHz AND interleave if you pushed the DRAMs out of spec like the ST did (or BBC Micro), but you'd need to change VIC timing for that too. (would clocking the VIC higher screw up video synchronization or any other analog stuff, assuming chip operation was otherwise stable? -it obviously wouldn't work with older software and would have an Atari ST style boarder and pixel shape, but would it work at all is more what I'm wondering)

 

Given the VIC-II already ran hot, that might not have been a good idea either.

 

 

Edit: I think Wiki may also be wrong about the VIC-II's pixel clock on the C64 article. It mentions 'approximately 8 MHz' and I think it's closer to 7 MHz for both PAL and NTSC similar to the Amiga. (I used to think it was closer to the ST and an integer multiple of the CPU clock, but it seems 7.09 and 7.16 MHz are more likely)

Edited October 25, 2015 by kool kitty89

[Rybags]

Supposedly with Vic-II the original idea was to do 1.79 Mhz and have cycle steals like Atari.

For whatever reason they changed their mind - quite probably so more Vic2 memory accesses could be accomodated. Though they didn't use all the available cycles, they could potentially have had an extra sprite or two.

Maximum Vic2 cycle demand on a scanline = 40 chars + 40 font + 24 sprite + 8 spr pointers + 5 refresh = 117 plus throw a few more in since /RDY is used preemptively for some accesses and it falls a little short of the 126 cycles total per scanline (PAL - NTSC machines are 128 or 130 depending on revision).

No special tricks would be needed with DRams I should think, the demand is for access time of ~ 220 ns if accessing them at 2 MHz and all machines are build to accomodate that.

 

Fairly sure Vic2 pixel clocking is virtually identical to the ST. It certainly isn't ~ 7.2 Mhz like A8 and Amiga. Slight difference from ST would be since ST is 263/313 lines per frame and C64 is 262/312.

[JamesD]

Oh, and JamesD, another missed option (already in line with some of what you've said) is a 1.79 MHz CPU with interleaved VIC-II accesses provided through an added bus latch (or combination latch/MMU also covering the expanded memory mapping -which might be kind of like what Atari did with FREDDIE, not sure if that allowed interleaving but I recall SOME sort of improved DMA/CPU bus cycle sharing)

 

You could push that to 2 MHz AND interleave if you pushed the DRAMs out of spec like the ST did (or BBC Micro), but you'd need to change VIC timing for that too. (would clocking the VIC higher screw up video synchronization or any other analog stuff, assuming chip operation was otherwise stable? -it obviously wouldn't work with older software and would have an Atari ST style boarder and pixel shape, but would it work at all is more what I'm wondering)

 

Given the VIC-II already ran hot, that might not have been a good idea either.

 

 

Edit: I think Wiki may also be wrong about the VIC-II's pixel clock on the C64 article. It mentions 'approximately 8 MHz' and I think it's closer to 7 MHz for both PAL and NTSC similar to the Amiga. (I used to think it was closer to the ST and an integer multiple of the CPU clock, but it seems 7.09 and 7.16 MHz are more likely)

The 1.79MHz CPU interleaved with VIC-II access is essentially what the CoCo 3 did with it's high speed mode if I remember right.

The VIC-II might have to be replaced because it's buss access times are too long but with different clock dividers and timing circuits it's certainly doable.

The alternative is to isolate the VIC-II from the CPU and access through an intermediate buss controller that latches data from system RAM quickly and then buffers it for the VIC-II's lower speed. (which is what I think you are talking about)

That is sort of how the SAM in the CoCo 1/2 worked. The SAM sat between the VDP and RAM, plus it also controlled the CPU clock, which is how it could enable double speed for the 32K ROM bank access.

 

I'm guessing the high speed mode for the VIC-II was left off for two reasons. Reduce costs and reduce time to market.

The speed control would require more gates and they would have to use a 2MHz 6502... I mean 6510.

Not only would the VIC-II need development time, they would need to make the 6510 work at high speed as well.

Edited October 25, 2015 by JamesD

[kool kitty89]

No special tricks would be needed with DRams I should think, the demand is for access time of ~ 220 ns if accessing them at 2 MHz and all machines are build to accomodate that.

I was suggesting setting up the bus to allow the VICII to interleave with a 2 MHz 6510 using timing closer to the ST (250 ns memory cycle times, not access times, which the 6510 would need to interleave and still avoid wait states, at least for zero page accesses). You'd need latches to buffer that through some sort of intermediate bus controller though, without modifying the VICII that is. (if you're going to update the VICII, you might as well take advantage of the potential 2x bandwidth as well -ie half the ST's bandwidth, but that's beyond the hardware situation going into the C128)

 

I'm pretty sure the BBC Micro did use that sort of memory timing with interleaved CPU and VDC access at resolutions/bit-depths similar to the Amstrad CPC. (not sure if the CPC interleaved too, but given it was closer to ST vintage, that'd be less surprising)

 

 

 

Fairly sure Vic2 pixel clocking is virtually identical to the ST. It certainly isn't ~ 7.2 Mhz like A8 and Amiga. Slight difference from ST would be since ST is 263/313 lines per frame and C64 is 262/312.

Unless the master clock values are also wrong, it seems like 14.32 and 17.73 MHz would be inconvenient to devide down to 8 MHz (or 4 MHz)

 

I'd originally assumed -a few years back- that the VIC just used a multiple of the CPU's clock ... maybe it does do that but dividing by 17 and then multiplying back up by 4 and 8 using PLLs seems a bit elaborate. (though 17.73 MHz is the lowest clock rate that divides really close to 1 MHz AND the PAL colorburst 4.43 MHz)

 

 

 

 

 

 

 

 

 

The 1.79MHz CPU interleaved with VIC-II access is essentially what the CoCo 3 did with it's high speed mode if I remember right.

The VIC-II might have to be replaced because it's buss access times are too long but with different clock dividers and timing circuits it's certainly doable.

The alternative is to isolate the VIC-II from the CPU and access through an intermediate buss controller that latches data from system RAM quickly and then buffers it for the VIC-II's lower speed. (which is what I think you are talking about)

That is sort of how the SAM in the CoCo 1/2 worked. The SAM sat between the VDP and RAM, plus it also controlled the CPU clock, which is how it could enable double speed for the 32K ROM bank access.

 

I'm guessing the high speed mode for the VIC-II was left off for two reasons. Reduce costs and reduce time to market.

The speed control would require more gates and they would have to use a 2MHz 6502... I mean 6510.

Not only would the VIC-II need development time, they would need to make the 6510 work at high speed as well.

For 1982, yes, but by 1984 it might have been more doable ... except you'd still need internal chip redesign there which wasn't in the C128's timetable. (and changing the VIC-II's external clock would screw other things up) Nix the bit about running hotter from earlier though, I forgot we were talking NMOS stuff here, so relatively little change in power dissipation at lower or higher clockspeeds, unlike CMOS. (just hot and power hungry all around) Running hot and unstable obviously makes higher clock speeds less practical in that sense, of course. A 2 MHz 6510 was obviously possible by '84 though, given the historical C128.

 

I'm also pretty sure the Atari ST MMU included a bus latch to handle that sort of arbitration between the CPU, SHIFTER, and DMA chip.

 

The really cheap and simple option obviously would have just been adding bank-switching circuitry without further enhancements (possibly a RAM expansion port to go beyond 128k too) aside from improvements in peripherals and on the software end. Or maybe just include the C128 style 2 MHz switching in vblank but include that feature as part of BASIC (more like the CoCo 1/2) or some other CBM native OS other than just BASIC. Leave more comprehensive modifications to a later date. (perhaps part of a full CMOS chipset redesign or just smaller/newer process NMOS)

[Rybags]

Master clock crystal for C64

 

PAL = 17.734475 MHz

NTSC = 14.31818 MHz

 

Colour clocking for both is derived by dividing master clock by 4.

 

CPU clock derived by /18 (PAL) /14 (NTSC). Pixel clock = CPU clock * 8.

 

Though supposedly the ~ 8 MHz clock for VIC-2 is generated and VIC in turn feeds back the ~ 1 Mhz signal used by the CPU.

 

http://codebase64.org/doku.php?id=base:cpu_clocking

 

 

Crystal Y1 develops a 14.31818MHz fundamental frequency clock signal. U31 is a Dual Voltage Controlled Oscillator. The output on pin 10 is a 14.31818 MHz clock signal called the color clock. R27 can be adjusted to obtain exact output frequency. U30 is a frequency divider that outputs a 2MHz signal on pin 6. U29 is a D flip flop which outputs a 1 MHz signal on pin 9. U32 is a Phase/Frequency Detector which compares the output of the U29 to the phase 0 clock, and outputs a dc voltage on pin 8 that is proportional to the phase difference between the inputs. The second half of the Dual Voltage Controlled Oscillator U31 generates an 8.1818MHz clock signal called the DOT Clock. The VIC IC divides the DOT clock by eight and outputs this as the phase 0 clock on pin 17. The output of the Phase/Frequency Detector is applied to the frequency control input pin 2 of U31. This causes tracking of the dot clock and the color clock because one input, pin 3 of U32, is the phase 0 clock which is derived from the dot clock, and the other input pin 1 of U32, is derived from the color clock.

[JamesD]

For 1982, yes, but by 1984 it might have been more doable ... except you'd still need internal chip redesign there which wasn't in the C128's timetable. (and changing the VIC-II's external clock would screw other ...

Yes but what? I didn't say anything about it not being doable.

 

The SAM chip was designed at the same time as the 6809 which puts it available in 1978. So a chip between the VIC-II and RAM that takes care of the high speed mode while making the VIC-II work without any changes could have been done even before the VIC-II was introduced and could have been done without messing with the VIC-IIs timing. And if Commodore had time to engineer a new chip & computer (TED), they certainly had time to upgrade an existing one.

 

An MMU certainly would be a nice addition if they were just putting a chip in between the VIC-II and RAM. An MMU that lets you re-map memory would have been useful with expanded memory. But simple memory paging at one address would have been sufficient for expanded RAM given the competition. It would have been a lot easier to program than the mess on the Apple IIe. The only reason the CoCo 3 included a programmable MMU was to support OS-9 Level II.

 

Expanded RAM could have required a daughterboard similar to the one on the CoCo 3. By being on a daughterboard, upgrades with 64K, 256K or 512K would have been possible with the same motherboard and would leave the motherboard about the same price to produce as the C64. I suppose an 80 column mode could also have been added with the daughterboard, after all, the Apple IIe did that.

[kool kitty89]

Master clock crystal for C64

 

PAL = 17.734475 MHz

NTSC = 14.31818 MHz

 

Colour clocking for both is derived by dividing master clock by 4.

 

CPU clock derived by /18 (PAL) /14 (NTSC). Pixel clock = CPU clock * 8.

 

Though supposedly the ~ 8 MHz clock for VIC-2 is generated and VIC in turn feeds back the ~ 1 Mhz signal used by the CPU.

 

The CPU clock would seem to be derived from dividing the PAL Master Clock by 18 and the NTSC one by 14. (or 9 and 7 since it's 2-phase, if I understand that concept properly) Dividing by 9/7 to get ~2 MHz and using PLLs to get up to ~4 and ~8 MHz pixel clocks would make sense too. That might also explain why 8.867 and 7.159 MHz master clocks weren't used. (one fewer PLL to use if you're multiplying up ~2 MHz rather than ~1 MHz)

 

 

 

 

 

 

Yes but what? I didn't say anything about it not being doable.

 

The SAM chip was designed at the same time as the 6809 which puts it available in 1978. So a chip between the VIC-II and RAM that takes care of the high speed mode while making the VIC-II work without any changes could have been done even before the VIC-II was introduced and could have been done without messing with the VIC-IIs timing. And if Commodore had time to engineer a new chip & computer (TED), they certainly had time to upgrade an existing one.

 

An MMU certainly would be a nice addition if they were just putting a chip in between the VIC-II and RAM. An MMU that lets you re-map memory would have been useful with expanded memory. But simple memory paging at one address would have been sufficient for expanded RAM given the competition. It would have been a lot easier to program than the mess on the Apple IIe. The only reason the CoCo 3 included a programmable MMU was to support OS-9 Level II.

I meant not messing with the VIC-II at all would be a safer bet than trying to redesign it. (designing a bus latch or combo MMU chip in a way that could be efficiently integrated with a 'VIC-III' of sorts later on would make sense too -as it was they made some odd/stupid mistakes with the C64C ... like the too-quiet bias-modulation '4th' channel in SID that's easily fixed with a single resistor)

 

Still, investing in at least TRYING to improve (or at least respin on a smaller/newer/cooler NMOS process) the VIC-II would have been a better and safer investment than TED ... or the VDC. (making the VIC cheap and reliable in a plastic DIP with no heat sink would be a good cost savings ... so would a 5V SID, let alone actual further chip consolidation) CMOS would be nice, but I'd assume more pitfalls and mean heavier investment in updating MOS's facilities.

 

And yeah, worst case would be simple single-bank paging akin to the TRS 80 (or at least the model II) though multi-pages or other remapping schemes would obviously be useful.

 

 

Expanded RAM could have required a daughterboard similar to the one on the CoCo 3. By being on a daughterboard, upgrades with 64K, 256K or 512K would have been possible with the same motherboard and would leave the motherboard about the same price to produce as the C64. I suppose an 80 column mode could also have been added with the daughterboard, after all, the Apple IIe did that.

Expansion through a simple edge connector would probably be cheaper and/or socketed DRAMs upgradable via service or DIY warantee violation opening of the machine.

 

An expansion connector COULD allow for card-style expansion module units too like the CoCo had (sort of), or TRS-80 model I, or TI 99/4, and Atari XL series was planned to get. I think some Apple II clones did that too, and the IIC. (short of that you're stuck with single module upgrades when you've got just one expansion port) Shame the ST didn't have its cart slot more PBI (or ECI) style. Same for the 7800. (would have made a RAM/sound/IO upgrade cheaper than using the cart slot instead -granted the American NES DID do that but never used it ... and stupidly omitted the sound lines from the cart slot too)

 

Form factor on that's tricky, of course, given boxy units in close contact with the console, or ribbon cables and signal degradation and such. (a desktop box or pizza box style form factor would make sense ... turning the A8 into a modular Apple IIe of sorts, maybe with keyboard articulation, maybe rigid connection with facilities for cable management ... ideally having the PSU built into the expansion unit and A/V passthroughs as well)

Edited October 26, 2015 by kool kitty89

[Rybags]

There's only so many valid clock combinations to give you 40 columns that fits in the space you want it, abililty to derive colour clocking (or at least be fractionally relative to it e.g. 4:5 like PAL Atari) and give you a "sensible" CPU speed (1.4-1.6 MHz is "wasteful" and >1.7 MHz came from parts with poorer yield numbers than ones that did 0.9-1.1 MHz).

Also it's desirable for PAL/NTSC to have clock speeds that aren't too distant and preferably the same cycle count per line (Atari got that, C= didn't with the 64 but it's close).

 

Finally you need to satisfy the demands for video processing. All that accounted for, I should think that's how they came up with the speeds for C64. They probably could have given it 9 sprites but in computing we usually see things in powers of 2.

[JamesD]

Seems to me the VDC started out life as a part for the Z8000 workstation Commodore was going to build (CBM 900) but that was cancelled when Commodore purchased the Amiga.

The C128 was pretty much a bunch of hacked together parts.

 

Expansion through a simple edge connector would probably be cheaper and/or socketed DRAMs upgradable via service or DIY warantee violation opening of the machine.

 

An expansion connector COULD allow for card-style expansion module units too like the CoCo had (sort of), or TRS-80 model I, or TI 99/4, and Atari XL series was planned to get. I think some Apple II clones did that too, and the IIC. (short of that you're stuck with single module upgrades when you've got just one expansion port) Shame the ST didn't have its cart slot more PBI (or ECI) style. Same for the 7800. (would have made a RAM/sound/IO upgrade cheaper than using the cart slot instead -granted the American NES DID do that but never used it ... and stupidly omitted the sound lines from the cart slot too)

 

Form factor on that's tricky, of course, given boxy units in close contact with the console, or ribbon cables and signal degradation and such. (a desktop box or pizza box style form factor would make sense ... turning the A8 into a modular Apple IIe of sorts, maybe with keyboard articulation, maybe rigid connection with facilities for cable management ... ideally having the PSU built into the expansion unit and A/V passthroughs as well)

But Commodore already had the external expansion port and the REU.
The REU wasn't exactly a big hit.

But then it's memory wasn't directly paged in the C64 memory map and it was a giant external dongle (which is what any external RAM expansion would be at time).
It also lacked significant support outside of GEOs which used it as a RAM disk.
Given the way it worked that was probably the best use for it anyway.

Keep in mind that the Amiga 500 used a trap door to expand memory internally so an external expansion isn't necessarily a must.

It was also a lot larger but it's possible.

RAM expansion is one of those things that I'm not sure which way to go on.

The Apple IIe had 128K upgrade as an option from Apple but very few machines on ebay have the RAM card installed.
That could be partly due to sellers selling individual parts to make more money.

There were plenty of programs that used expansion RAM but only a few required it.
But then there are also RAM cards with 512K or more which people were willing to pay a lot for.

The Atari 130XE didn't offer any other features to differentiate itself from other Ataris for companies to justify requiring the extra RAM to run their software.

The CoCo 3 had 128K built in so programmers took advantage of it but very few CoCo 3s on ebay have any more.
Some of the new graphics modes required the extra RAM so building it in made sense.

 

If that is any indicator, most of the people out there wouldn't buy any RAM expansion unless some program they wanted to run required it.

Then maybe 10% would buy the lowest level of RAM expansion to use as a RAM disk, print buffer, to run that one program, or just because.

128K was probably enough for most people that needed a RAM expansion.

The power users OTOH would buy as much as possible. They are probably 5% of owners or less at the time.

If you want people to pay more for this hypothetical new machine than the C64, they need a reason.
The question is, do more colors, a faster CPU and the RAM upgrade justify the extra cost or does it need something more?
Commodore supposedly had a blitter in the works to go with the CBM 900. Maybe some form of that could have made it in as well?

Edited October 26, 2015 by JamesD

[Rybags]

They didn't make the C128 any better than it was for the same reason they didn't go ahead and release the C65.

 

It would have taken sales away from the Amiga. It would have taken 3rd party support away from the Amiga.

 

Really it's almost as much a "WTF?" machine as the Plus4, big difference being it gained market acceptance and actually sold pretty well.

To release an 8-bit machine when the things were becoming irrelevant and have it sell practically as many as the Atari 8-bit line which predated it by about 6 years just goes to show what some good marketing can achieve.

[JamesD]

They didn't make the C128 any better than it was for the same reason they didn't go ahead and release the C65.

 

It would have taken sales away from the Amiga. It would have taken 3rd party support away from the Amiga.

 

Really it's almost as much a "WTF?" machine as the Plus4, big difference being it gained market acceptance and actually sold pretty well.

To release an 8-bit machine when the things were becoming irrelevant and have it sell practically as many as the Atari 8-bit line which predated it by about 6 years just goes to show what some good marketing can achieve.

 

I'm not sure it had anything to do with competition. Commodore designed, introduced, and cancelled a lot of machines in that time period. They even designed and cancelled multiple Amigas or Amiga upgrades.

[kool kitty89]

Supposedly with Vic-II the original idea was to do 1.79 Mhz and have cycle steals like Atari.

For whatever reason they changed their mind - quite probably so more Vic2 memory accesses could be accomodated. Though they didn't use all the available cycles, they could potentially have had an extra sprite or two.

Maximum Vic2 cycle demand on a scanline = 40 chars + 40 font + 24 sprite + 8 spr pointers + 5 refresh = 117 plus throw a few more in since /RDY is used preemptively for some accesses and it falls a little short of the 126 cycles total per scanline (PAL - NTSC machines are 128 or 130 depending on revision).

 

Looking at this again, that 40+40 bytes for the char/font alone would be enough to allow a 640 pixel 1bpp scanline bitmap format ... and a 320 pixel 4 color mode and 160 pixel 16 color mode if they'd tweaked things a bit for a simple framebuffer. (come to think of it, now I wonder why ANTIC doesn't support double the resolution in its bitmap modes, unless that's more a GTIA limit) Framebuffer logic tends to be a lot simpler than character modes and the 640 pixel wide one is the really important one for 80 column text and other highres graphics.

 

 

 

 

RAM expansion is one of those things that I'm not sure which way to go on.

 

The Apple IIe had 128K upgrade as an option from Apple but very few machines on ebay have the RAM card installed.

That could be partly due to sellers selling individual parts to make more money.

There were plenty of programs that used expansion RAM but only a few required it.

But then there are also RAM cards with 512K or more which people were willing to pay a lot for.

 

 

I wonder if piggyback upgraded 520STs are more common than any of those above upgrades. The presence of the 1040ST (and MEGA STs) Same for 48k/64k support on the 8-bits though there the smaller RAM models were discontinued in favor of 64k models. The 64k Ataris weren't so easy to expand to 128k, but the same problem would crop up with the C128. Amiga trapdoor expansion was limited to slowram (same timing as chipram but no chipset access) or fastram with an added DRAM controller, so not 500+ compliant. (had the 500+ added 512k of FastRAM instead it might have been another story given increased software development incentive -better if the 68k could run at 2x speed in FastRAM, or higher -16.11 MHz would work synched up with every 18th chipRAM cycle -or every 9th interleaved 68k slot)

 

Adding bitmap modes to the VIC-II along with the RAM and CPU speed boost would be a lot more useful, plus having the CPU run faster in vblank would be really useful for software blits to a framebuffer.

 

If they REALLY wanted a CP/M machine it might have been cheaper and more convenient (to CMB and consumers) to just build a Z80+VDC system with added I/O. (a more business/office oriented machine than the C64 or 128 and far cheaper than the Amiga -and a year earlier) A cheap, console form factor COLOR TRS-80 Model 2 of sorts. (sans the model 16 options -given the Amiga's pending existence)

 

 

 

 

 

 

They didn't make the C128 any better than it was for the same reason they didn't go ahead and release the C65.

 

It would have taken sales away from the Amiga. It would have taken 3rd party support away from the Amiga.

The C64 was just too late and not powerful enough to really be marketable (An AGA amiga is what they really needed at the time ... or even just a faster ECS Amiga -like I suggested the Amiga 500+ should have been in the first place ... plus 500+ is a bad name for a 1 MB machine -in fact, doing THAT would probably be better than a typical AGA machine given the blitter could run full bore, 5 and 6 bitplane modes would be more useful ... and a 14-16 MHz CPU running full bore in local RAM would be a lot more useful for 3D stuff -AGA's lack of chunky pixels makes it much less of a boost there ... Atari and CBM both screwed up in that regard ... aside from the A8's chunky pixels).

 

A cheaper, simpler C128 would have conflicted LESS with the Amiga's market, something closer to the C65 by 1987/88 would have been far more significant too given the Amiga was still expensive. Having the Amiga slot into the bottom end market wouldn't make sense until the early 1990s. With an upgraded AND cost-reduced C64, they could discontinue the original model entirely while better filling and competing in the lower end of the market. (including cutting WAY more into console market sales)

 

In the 1984 context though ... a modified VIC with similar memory timing and added framebuffer modes and fast CPU in vblank seems like a really good fit. (320 pixel 2bpp mode less so, 640x200 1-bit definitely useful, and 160 pixel 4-bit 16 color mode would be great for games -especially if they upgraded the palette rather than just going direct 16 colors)

 

 

 

Really it's almost as much a "WTF?" machine as the Plus4, big difference being it gained market acceptance and actually sold pretty well.

To release an 8-bit machine when the things were becoming irrelevant and have it sell practically as many as the Atari 8-bit line which predated it by about 6 years just goes to show what some good marketing can achieve.

That doesn't mean it was worth it compared to selling more C64s and consolidating marketing, distribution, and software development, and investing in cost-reducing and expanding on the hardware sooner.

[Rybags]

Both Atari & C64 only utilize half the possible bitmap bandwidth available.

 

GTIA is stretched as it is, AFAIK only the luma output is able to run at 7.2 MHz, the remainder of the chip isn't even able to support colour switching above 3.6 MHz.

What would have been nice is something like 16 colours @ 160 resolution and 256 colours at 80 resolution.

But among other things there's only the 3 ANx lines from Antic giving 12 bits worth of data per 8 hires pixels and only 9 colour registers though there'd be nothing wrong with a higher bandwidth mode reusing registers and giving derivative colours e.g. halfbright, invert colour component etc.

Edited October 26, 2015 by Rybags

[JamesD]

...

Adding bitmap modes to the VIC-II along with the RAM and CPU speed boost would be a lot more useful, plus having the CPU run faster in vblank would be really useful for software blits to a framebuffer.

...

In the 1984 context though ... a modified VIC with similar memory timing and added framebuffer modes and fast CPU in vblank seems like a really good fit. (320 pixel 2bpp mode less so, 640x200 1-bit definitely useful, and 160 pixel 4-bit 16 color mode would be great for games -especially if they upgraded the palette rather than just going direct 16 colors)

 

That doesn't mean it was worth it compared to selling more C64s and consolidating marketing, distribution, and software development, and investing in cost-reducing and expanding on the hardware sooner.

FWIW, I was kinda just implying adding the Plus/4 graphics features to the VIC-II but maybe I never spelled it out.

If you add modes like the CoCo 3's 16 color and 640x200 bitmapped modes they are nice but very RAM intensive. That's why the CoCo 3 came with 128K and it's part of what made the MMU useful. I definitely agree, they make the machine a whole lot nicer, but that's a lot of pixels to push around for a 1.7ish MHz 6502.

The 6502 will do alright as long as you don't try to move too much data.

 

 

...Amiga trapdoor expansion was limited to slowram (same timing as chipram but no chipset access) or fastram with an added DRAM controller, so not 500+ compliant. (had the 500+ added 512k of FastRAM instead it might have been another story given increased software development incentive -better if the 68k could run at 2x speed in FastRAM, or higher -16.11 MHz would work synched up with every 18th chipRAM cycle -or every 9th interleaved 68k slot)...

You realize that has absolutely nothing to do with adding RAM to some C64 successor right?