A8 vs C16/Plus4

[JamesD]

Necro thread ARISE!!!!
I totally missed this comment and apparently have nothing better to do than answer it.

So the astrocade comment was also incorrect? (I'd thought it was a more or less basic framebuffer based system)
...

The Astrocade does have some hardware to speed up screen access but it's not a blitter.
It supposedly allows shifting bits and performing logic operations with screen RAM to reduce CPU overhead with software sprites.
Depending on the implementation, that could eliminate a lot of code.

The 64 column font code I worked on requires two bit masks and an OR per line times seven or eight lines depending on the font.
If all you have to do is set up the masks and logic operation with 3 or 4 writes before using it, that's a huge savings.
By using bit shifting I could use smaller font data and one piece of code to draw to the screen.
That would make the code less than half the size... maybe even one quarter the size.

For a proportional font routine and sprites where shifting is constant it would make a huge speed difference.

The Astrocade hardware is activated simply by writing to the ROM area as if it were the screen and the hardware takes care of doing the rest to screen memory.
Something like this would be a good alternative to an actual blitter but I'd want to be able to overlay it directly over the top of screen RAM so only one one set of pointers needs to be maintained. The key difference vs a blitter is that a blitter requires a little more setup but it automatically transfers all bytes to the display once you send it the last byte of data it needs.

If you are performing multiple blits with similar settings you shouldn't have to redo all the settings on a good design.

For a modern blitter, I think I'd want to give it the ability to perform a list of commands. Then you could just modify things like X and Y coordinates for each software sprite, change pointers to which version of a sprite to display, what bit mask operation to perform and then tell the blitter to go to it when the retrace happens or when a certain scan line is reached on the screen. Then you can start erasing and redrawing sprites sooner and you don't have a limit other than memory bandwidth to how many you can draw.

You'll be locking out the CPU while the blitter is working but the speed gained over blitting with the CPU would be worth it.
For my font code, the blitter could read or write to memory every clock cycle where even the 6502 takes something like 30 clock cycles per byte even if no shifting is required. The Z80 code is probably 2 or 3 times that cycle wise, and even my 6803/6809 code is around 20, though the 6309 cuts off about 5 cycles due to the pre-fetch.
Bit shifting is really costly with a cpu so pre-shifted graphics are commonly used with a CPU and that's costly on RAM. With a blitter you shouldn't need pre-shifted graphics.

Having said all that, if you have a fast enough CPU it's a moot point. The CoCo 3 implementation of Donkey Kong looks exactly the same when running on a 25 MHz FPGA 6809 as it does at normal speed. I think once you crank up the clock speed above 4 MHz on the 6502/680X CPUs you can keep up with to old sprite hardware. Above 8 MHz you can pretty much blit to your heart's content as long as you have enough RAM to hold everything. The Z80 pretty much needs a higher clock speed than the 6502/680X or some internal optimizations to keep up but basically, MHz makes up for a lack of hardware. The thing is, the inverse is also true. Hardware makes up for a lack of MHz and the Astrocade has a Z80 running at 1.78 MHz. Without the hardware assistance the CPU would have been too slow.

[kool kitty89]

Thanks for the detailed response, and a bit of a neat coincidence since I just very recently started browsing the forum again. There's a lot more info I've already picked up over the last few years, but there's some bits there I hadn't known and it's definitely appreciated (and useful for anyone else who browses old threads for information in general).

 

The Astrocade's case also involves two bitplanes forming the framebuffer, so more bit-shifting overhead than a 2-bit cbunky pixel arrangement, and the low resolution makes working on byte boundaries even worse. (too choppy/blocky to be practical) For doing byte-alligned character drawing, the Z80's block-move instructions would be a lot more useful.

 

 

 

Skimming back over the early pages of this thread and the original topic reminds me of a couple of other things, though. The first I'm pretty sure already came up: that an upwards compatible cost-cut 16k C64 would have made more sense for the C-16/C-116's original goals as a VIC-20 replacement and low-end competitor. (even without hindsight it'd be a safer bet, especially hedging their bets on RAM pricing -ie if RAM got cheap enough, a full C64 with cheaper case/keyboard would probably save more on cost).

 

The second thought was on the comments towards CBM management seeing the Plus/4 as a potential 'successor' to the C64. Between that and the 128, it really seems like another C64-compatible derivative would have made more sense and even taking the 'add more hardware' route the 128 took there could have been cheaper and more powerful options. (the simplest I'd think would be adding a memory mapping/DRAM controller chip to allow the CPU to work on a separate bus from the VICII without wait states and probably at 2x the clock speed -so the 'old' 64k plus the new 64k of fastRAM- ... and just drop the CP/M feature and added VDC in favor of a fast 6502 system and updated native OS possibly a CP/M or DOS work-a-like, or just stick with 3rd party developers to offer that) Adding onto the C64 design avoids reverse engineering/redesign of the older hardware and possible compatibility niggles there but the C128 itself seems like an unnecessarily costly kludge in many respects. (and given a 2 MHz CPU without wait-states would be nearly 3x faster than the C64 -practically less due to slow accesses to VICII RAM and I/O- it seems like a very substantial upgrade worthwile compared to simpler bank-switched C64 RAM expansion possibilities ... especially if they also upgraded the disk drive and sidestepped the C64's horrible limitations there, stuff to make it into a more serious office/productivity machine on top of game potential)

 

A full 2 MHz VIC-III (of sorts) upgraded chipset with faster shared memory would probably have been cheaper and more powerful in most cases still, but that's more R&D and time to market lost they probably weren't willing to go for. (putting engineering effort into revised, lower power -not necessarily CMOS- chipset all running on 5V might have been more useful for cost and reliability all around -C64 production included, and further mitigate some of the Plus/4 chipset's advantages)

[JamesD]

I don't think management saw the Plus/4 as a replacement for the C64.
They were probably doing what managers do, trying to invent a market for a product that was never intended for that market to justify their own existence.

If they wanted to replace the C64, they needed to make the machine stand out from the C64.
The Plus/4 stood out... just not in the way it needed to.
The C128 without the Z80 might have sufficed but I thought it was a bit of a baby step over the C64.

[kool kitty89]

The C128 without the Z80 might have sufficed but I thought it was a bit of a baby step over the C64.

 

 

The C128 couldn't use anything but the expanded memory when VIC-II was enabled, unless I'm mistaken. The 2 MHz 8502 mode was limited to using the new VDC which would be OK for certain applications and better than the VIC for a few things (mostly business and technical applications) and obviously not games. Omitting the new VDC (and its RAM) and placing the added 64k on a separate bus (with added memory controller and interface to bank between that and the existing C64 memory map) it should have been cheaper and much more useful for games. (and backwards compatible, obviously)

 

Ideally you'd have an wholely upgraded VIC chip instead (or backwards compatible video/memory controller LSI chip), but I was thinking in terms of a short-run engineering project with the most complicated part being the new memory controller.

 

An intermediate between the much too late C64 and the C64 would have been far more useful though, but not mutually exclusive with the above either. (and no Z80 or new VDC to tag along for compatibility, just the old C64 hardware and fastRAM memory controller) There's a long period before the Amiga 500 would (or could) fill the C64's old market prior to the period where the C65 actually emerged in development.

[pseudografx]

AFAIK the 2MHz mode can be used with VIC-II during vertical blank. It is commonly used in many modern C64 demos to speed some routines up when running on a C128.

[TMR]

AFAIK the 2MHz mode can be used with VIC-II during vertical blank. It is commonly used in many modern C64 demos to speed some routines up when running on a C128.

It can be used that way (set $d030 to $01 at the start of the lower border and back to $00 at the end of the upper), but i can't actually think of a recent example right now because it isn't particularly common. There are a few games running in C64 mode that use it like Alleykat or Uridium Plus though, they throw a few more objects around.

[pseudografx]

It can be used that way (set $d030 to $01 at the start of the lower border and back to $00 at the end of the upper), but i can't actually think of a recent example right now because it isn't particularly common. There are a few games running in C64 mode that use it like Alleykat or Uridium Plus though, they throw a few more objects around.

Ok, maybe it is not as common as I suggested, but it is definitely a well documented technique. I just remember watching a recent demo (2014 or 2015) that supports this. Can't remember its name though.

[TMR]

Ok, maybe it is not as common as I suggested, but it is definitely a well documented technique.

It's well documented yeah, but rarely used; many C64 demo coders would look at it as "cheating" and for anything based on cycle timing you'd need two versions of the code for stock C64 and C128 anyway. Even the small range of C128-specific demos out there don't all use it!

 

VICE doesn't even emulate what happens properly right now (the garbage that appears on screen when 2MHz is enabled can actually be controlled to a degree) and the other "features" of the VIC-IIe like (ab)using the test bit to change the palette are on the "to do" list as well.

[JamesD]

Do I really need to point out that whether or not you can use the 2MHz mode during the vertical blank doesn't exactly make it useful.
Exactly how many programs use it? A handful?
Can you use it from BASIC? Not that I've seen.

Look at the high speed POKE on the CoCo I/II. It got used from BASIC all the time.
That's how the C128 should have worked.

Instead of trying to make a cheaper machine (Plus/4), Commodore should have worked on a better C64.
Imagine if they had come out with a machine that was C64 compatible but you type a POKE and it runs at the speed of the Plus/4?
A machine that added the Plus/4 palette to the C64, 128K of RAM, the enhanced BASIC of the Plus/4 and a built in high speed disk mode.
Maybe even an 80 column text mode that didn't require a 2nd chip, ROM sockets to add built in programs of the user's choice and in a neater looking case.
THAT is the machine they should have created and then let the C64 become the cheap low end model.

Frankly, if Commodore had been smart they would have had sockets like the Sinclair Z88 for the built in software.
Buy whatever you want and plug it into a slot on the front of the machine without opening it up.

But they were going for cheap.

[TMR]

Do I really need to point out that whether or not you can use the 2MHz mode during the vertical blank doesn't exactly make it useful.

Being useful and being used aren't the same thing though, if a program is designed around using 2MHz it can do things that a stock C64 can't. But if you're writing commercial software it makes sense to target all the machines by aiming at the lowest spec.

 

Exactly how many programs use it? A handful?

Being exact is difficult, but there are probably a couple of hundred programs use it themselves and i'd expect to find a couple of thousand more enabling 2MHz when decrunching because the most common use is jobs that spend a lot of time juggling data like file compression; sometimes there's no way to know unless you see the C128 "noise" appear for a frame or or two before the screen is blanked.

 

Can you use it from BASIC? Not that I've seen.

It can work from BASIC but only as a "thinking time" sort of thing whilst calculations are happening, although there's nothing to stop a small interrupt being used to just toggle on and off during the upper and lower borders.

[JamesD]

How many programs from the 80s?

*edit*
And I don't mean ones that have been patched after the fact.


The C128 was produced for 4 years and was introduced just months before the Amiga.
Something that was discovered after the machine was discontinued isn't exactly a selling point for the machine.

The high speed mode on the CoCo was discovered within months of it's introduction my reading the Motorola docs on the SAM, so at least 1981 if not 1980.
Almost every CoCo BASIC program published in magazines within months after that used it and it was in use over ten years before CoCos were discontinued.
It doesn't require an interrupt or assembly language.

I suppose useful wasn't the proper word. Practical maybe.

Edited October 22, 2015 by JamesD

[Rybags]

Very few programs took advantage of it in the day. Though I think in modern times some old commercial games have been modified to take advantage of the speedup.

[peteym5]

A business machine without 80 column support was always going to be a non-starter. In some respects that’s why the CPC 6128 only needed the extra memory to better support CPM and serious software (and why #Amstrad dropped the 664 so quickly its wasn’t any cheaper to produce).

 

It could be argued that was a benefit of Z80 based machines - in theory easy access to a common operating system and applications.

 

It could be argued that all the 6502 machines would have benefited from a common serious OS and 80 column support as standard.

 

Going back to the Plus 4 - originally the chip set was designed as the basis of a replacement for the VIC20, couldn’t they have made the chip set at least VIC-20 compatible at least then you have an existing software base and a logical progression to the C64?

 

I think both Commodore & Atari suffered to a degree from multiple incompatible platforms and confusing product lines. They both suffered from believing each other to be the competition rather than noticing the real threat of the IBM PC compatible (Something that Amstrad in the UK noticed and benefited from after botching the CPC+)

 

Barnie

I think Commodore suffered worse with multiple incompatible platform than Atari did. From the 400 to the 130XE all using the same CPU, sound, and graphics chips. The OS changed going from 400/800 to XL. With a translator or reworking the program from 400/800 can be made to run on the XL/XE machines.

 

I had a Vic-20 and when Commodore made the 64, 16, Plus 4, they frustrated consumers and software companies by having these compatibility issues. If Commodore wanted to cut cost and make a single chip for sound and video, why didn't they combine the VIC-II and SID chip and make a single chip backward compatible with that. They could had taken a Commodore 64, leave 48k of RAM out, and sold that as the 16, and make it expandable to 64K later. The software the Plus 4 was useful, but maybe they should had incorporated that into a Commodore 128 which had 80 column abilities. The plus 4 flopped in the United States after the Commodore 64 became very popular, had some European success. But giving a nick name "The Minus 60" fit.

 

I avoid the argument which machine is better, but it seems to be a question of which company was better with managing their hardware and providing software for them. Seems like Atari was moving ahead with that.

Edited October 22, 2015 by peteym5

[TMR]

How many programs from the 80s?

Off the top of my head there's all of Andrew Braybrook's games from Alleykat onwards (including Uridium Plus and every iteration of Paradroid after the original), a few others that detect the hardware like Tiger Mission (but i can't be sure if they actually use it) and at least a dozen crunchers, some badged like Stoat&Tim's 2MHz TimeCrunch V5.0 but just as many again have it as an undocumented feature. Like i said earlier, it wasn't common in demos and i can only think of C128 World Record from 1988 using 2MHz for vertical splits.

 

But no, it's not commonly used during that time.

 

Something that was discovered after the machine was discontinued isn't exactly a selling point for the machine.

That's moving the goalposts somewhat, a feature doesn't stop being useful if it can't sell the hardware.

 

The high speed mode on the CoCo was discovered within months of it's introduction my reading the Motorola docs on the SAM, so at least 1981 if not 1980.

The C128 Programmer's Reference Guide documents 2MHz, including the BASIC 7 FAST and SLOW commands and information on $d030 for assembly language programmers which also has a note mentioning that the latter works from C64 mode. The system manual covers the BASIC commands.

 

I suppose useful wasn't the proper word. Practical maybe.

i'd say it's both, but not popular amongst developers because only a finite number of users had the appropriate hardware; it's similar to how the bulk of Atari 8-bit software in the 1980s was 48K despite there being 64K or 128K machines available.

[carlsson]

IMHO, the TED project started as an attempt to make an extremely cheap computer that would win competition even among European customers who didn't want to spend a lot of money on a computer. Then it grew, got delayed and eventually became a prestige project: Commodore needed to release something out of 1.5 years of development.

 

Indeed Commodore at an earlier stage worked on a 6562/63 chip which would've been a 40 column VIC-I but due to that chip requires SRAM, it was too expensive to fit it with fast enough memory. There exists at least one prototype version of this chip, that to some degree can be fitted into a VIC-20. Parallel with the VIC-40 as it was called, they also were working on the VIC-30 to become VIC-II which uses DRAM. I don't think at some point it would've been possible to combine VIC-II and SID into one, but surely they could have released a Commodore 32 with half as much RAM.

 

Apparently keyboards and cases compromised a big part of the manufacturing costs, despite Commodore had churned out so many full travel keyboards already from the PET days that you'd think they had a very good discount. This is why the Commodore 116 was to be equipped with a smaller, cheaper membrane keyboard with rubber keys just like ZX Spectrum and many other. I'm sure an imagined Commodore 32 could've had this too, but then customers would ask themselves why the VIC-20 with a proper keyboard was replaced by a cut-down C64 with rubber keys.

 

Compatibility indeed gotta been a factor, which is why there was no real rush to improve upon the Commodore 64. It sold well enough and was one of the market leaders, perhaps next to Atari 800XL, and as noted Atari only made light changes over the years. Actually the C64 to a big part is backwards compatible with the VIC-20, both in terms of peripherals, memory maps and ROM calls, while the C16 and Plus/4 are less compatible in all respects.

 

I can imagine even a Commodore 32 model would have confused the market: how important is it to make games that are less than 32K in size, how many potential customers will we miss if our game is 40-50K? Then again, Atari developers at that time must've had the same issues: should we aim for the 600XL or focus on games for the 800XL, should we expect most 600XL users to have bought a memory upgrade anyway? Same goes for ZX Spectrum in Europe, all the MSX1 models and many other computers that came with several memory configurations but otherwise pretty much the same.

[kool kitty89]

AFAIK the 2MHz mode can be used with VIC-II during vertical blank. It is commonly used in many modern C64 demos to speed some routines up when running on a C128.

 

Do I really need to point out that whether or not you can use the 2MHz mode during the vertical blank doesn't exactly make it useful.

Exactly how many programs use it? A handful?

Can you use it from BASIC? Not that I've seen.

Look at the high speed POKE on the CoCo I/II. It got used from BASIC all the time.

That's how the C128 should have worked.

Was this feature late to being documented or is there some other reason it wasn't more widely used? That sort of arrangement definitely would have been a decent speed boost to the existing C64 chipset at lower cost (and greater flexibility of memory usage) than the fastRAM idea. (adding a small SRAM scratchpad that could map to zero page might have been more useful and relatively cheap too -use a pair of those 1024x4-bit SRAMs CBM seemed to love using in everything)

 

The 2 MHz in Vblank should have gotten CPU performance closer to the Atari's 1.79 MHz CPU (with its DMA wait states) so somewhere along the lines of the 130XE but better for most games. (changing floppy drives would make it a much more useful business machine too, pretty necessary there, really -ability to read/write CP/M or PC DOS formatted disks would be very useful too -so basically like the 130XE with a double-density drive)

 

 

 

 

Instead of trying to make a cheaper machine (Plus/4), Commodore should have worked on a better C64.

Imagine if they had come out with a machine that was C64 compatible but you type a POKE and it runs at the speed of the Plus/4?

A machine that added the Plus/4 palette to the C64, 128K of RAM, the enhanced BASIC of the Plus/4 and a built in high speed disk mode.

Maybe even an 80 column text mode that didn't require a 2nd chip, ROM sockets to add built in programs of the user's choice and in a neater looking case.

THAT is the machine they should have created and then let the C64 become the cheap low end model.

If they wanted a cheaper machine as WELL, that should have been C64 compatible too. The Max machine should have been that machine and it had the right timing, but going with only 2 kB made no sense outside of marketing it as a cartridge based game console. If the Max had been a 'Commodore 16' instead ... same chips, 16k of DRAM and the cost-cut case (with domed membrane keys -so more/better feel than the A400's ) it would have been a good fit for the budget casette software market and especially help the machine break into Europe's mainstream (ie budget) market much sooner than the C64 itself managed. Admittedly, given the way the market went (and RAM prices) it would probably make sense to discontinue that by 1985 anyway with the 64k model taking the bottom end of their market.

 

Doubling CRAM and using the TED palette (or something similar with up to 256 colors) would be great, and as I said above, a fast disk drive would be a real help too. (a standard -probably single sided- 160k DD format would make a lot of sense along with some form of backwards compatibility -great if they replaced the original DOS with a compatible fast alternative, but worst case would be falling back to the old standard)

 

 

 

 

 

I had a Vic-20 and when Commodore made the 64, 16, Plus 4, they frustrated consumers and software companies by having these compatibility issues. If Commodore wanted to cut cost and make a single chip for sound and video, why didn't they combine the VIC-II and SID chip and make a single chip backward compatible with that. They could had taken a Commodore 64, leave 48k of RAM out, and sold that as the 16, and make it expandable to 64K later. The software the Plus 4 was useful, but maybe they should had incorporated that into a Commodore 128 which had 80 column abilities. The plus 4 flopped in the United States after the Commodore 64 became very popular, had some European success. But giving a nick name "The Minus 60" fit.

There's the Amiga in there too, though with Atari you could throw in their game consoles as distinct platforms too. (though the 5200's hardware at least made porting to/from the computers simple compared to cross-developing for the VIC-20 and C64 or C64 and Plus/4 or C16)

And yes, a C64 based 'Commodore 16' instead of the Max (and rather like the Atari 600 or 600XL -expandable to 64k via a simple module) would have made tons of sense as I wrote above. It actually would have made even more sense back in 1982 (same goes for Atari's canceled 600 companion to the 1200XL) given 2kB DRAM chips were still significantly cheaper per bit than the 8k chips used in the 64k machines. (and 8x 1-bit wide chips makes a 16kB 8-bit wide memory bank) http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm

 

Though using a pair of 4-bit wide 8kB DRAMs quickly became the cheaper option still (both for chip cost and board space) and that's what the 600XL ended up using. (still, for a 1982 machine, especially one with manufacturing starting in late '81 or early in '82 and DRAM prices more speculative, using 2k chips was a very safe bet and is what Atari was doing with the prototype 600)

 

 

As to the VICII-SID combo, not really practical at the time. In their existing forms the two were fairly large, warm-running chips as it was and the SID used a 9V supply. That sort of integration would have made more sense around the time of the CMOS C64C chipset, but prior to that they might have managed some die-shrinks and modifications that allowed a simpler single 5V supply and less excess heat but probably not merging those chips. (or if they DID do it, it might have required large enough silicon wafers to be anything but a cost savings with poorer yields and higher cost per chip)

 

Atari OTOH, was developing a combined GTIA+ANTIC chip but that's a bit different given both of those were already 5V designs and both were already companion video chips and some 3 years older than the VIC-II.

 

Still, dropping to 16k alone would have made a big difference, plus the MAX's cheap keyboard.

Edited October 23, 2015 by kool kitty89

[Rybags]

Double speed offscreen isn't a huge increase overall, but worthwhile. Sort of like a typical vs minimal screen situation on Atari.

 

PAL ~ 110 scanlines (actually 112 but let's say lose 2 as overhead due to Raster IRQ processing)

18,656 cycles available per frame on C64 assuming 1000 character fetches

6,380 extra cycles become available if 110 scanlines run @ 2 Mhz, 58 per line for CPU, 5 lost to refresh.

25,036 total for a 34% speed increase

 

NTSC ~ 60 scanlines

16,030 cycles available per frame

3,600 extra cycles become available if 60 scanlines run @ 2 Mhz, 60 per line for CPU, 5 lost to refresh.

19,030 total for an 18% speed increase

[JamesD]

I guess I need to spell it out.
A documented 1.77MHz clock mode that is simple to enable is a whole lot more useful than a 2MHz mode that requires you to jump through hoops to use.

The 2MHz timing just doesn't work with video unless the CPU RAM and video RAM are separate like on the 128's new modes.

You can't interleave memory accesses.
With 1.77MHz, the timing is right to automatically give the CPU access to RAM on any cycles the video doesn't need.

The 2MHz works with this hack because the VIC II isn't accessing RAM at that time.

Which is faster? That depends on how many cycles the 1.77MHz CPU gains during border drawing. The main thing is that it's faster than 1MHz and it can be used with everything, not just code with some tight coding in one spot.

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.

[Rybags]

They could have gone with 2 MHz and DMA halts like Atari from the onset with C64. What they settled with was a compromise that probably cost less to develop.

From a programming POV, the only advantage of it running at 1 Mhz is that timing becomes a lot more deterministic because the only lost cycles are character code and sprite fetches.

 

But that's the C64 in a nutshell. Many aspects of the product were half-baked because they put getting it to market quickly as a higher priority than getting the system designed right.

[JamesD]

They could have gone with 2 MHz and DMA halts like Atari from the onset with C64. What they settled with was a compromise that probably cost less to develop.

From a programming POV, the only advantage of it running at 1 Mhz is that timing becomes a lot more deterministic because the only lost cycles are character code and sprite fetches.

 

But that's the C64 in a nutshell. Many aspects of the product were half-baked because they put getting it to market quickly as a higher priority than getting the system designed right.

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.

 

[TMR]

I guess I need to spell it out.

A documented 1.77MHz clock mode that is simple to enable is a whole lot more useful than a 2MHz mode that requires you to jump through hoops to use.

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

 

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.

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.

[JamesD]

Then I stand corrected.

[barnieg]

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?

 

 

I think Commodore suffered worse with multiple incompatible platform than Atari did. From the 400 to the 130XE all using the same CPU, sound, and graphics chips. The OS changed going from 400/800 to XL. With a translator or reworking the program from 400/800 can be made to run on the XL/XE machines.

 

I had a Vic-20 and when Commodore made the 64, 16, Plus 4, they frustrated consumers and software companies by having these compatibility issues. If Commodore wanted to cut cost and make a single chip for sound and video, why didn't they combine the VIC-II and SID chip and make a single chip backward compatible with that. They could had taken a Commodore 64, leave 48k of RAM out, and sold that as the 16, and make it expandable to 64K later. The software the Plus 4 was useful, but maybe they should had incorporated that into a Commodore 128 which had 80 column abilities. The plus 4 flopped in the United States after the Commodore 64 became very popular, had some European success. But giving a nick name "The Minus 60" fit.

 

I avoid the argument which machine is better, but it seems to be a question of which company was better with managing their hardware and providing software for them. Seems like Atari was moving ahead with that.

[Bryan]

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?

 

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.

[barnieg]

 

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.

I presume that compared to the 8-bit computers the 32k Rom size without bankswitcing required gave some advantages?

 

It's interesting you mention the Atari 400, and looking at the XEGS and the comments made about it being the 5200 done right.

 

Maybe if the apparent rivalries between console and computer divisions hadn't existed they could have come up with a common platform going forward.

 

Sent from my D5803 using Tapatalk