Did commodore attempt development of an upscale 6502

[carmel_andrews]

I was reading some commodore site previously (i think it might have been lemon 64 or it might have been someone else) and it had sections or parts of a chapter of Brian Bagnals new Commodore History book (which essentially has most of the content of 'Home computer wars' and continues the story as such)

Anyway part of the chapter that was most interesting was that it read like commodore were attempting to develop some sort of 'upscale' 6502 (i.e. a 16bit 6502), but according to the text Tramiel basically poopooed it and wouldn't fund any further development

The weird thing is, is that back in my school days I remember reading a library book called 'Penguins guide to home computers' (by Penguin books)...Can't remember the Authors name but he came from the same part of London Douglas Addams lived in while he was writing 'Hitch Hikers Guide'

Anyway the author of the penguin guide mentioned something similar to the text from the commodore history book, but actually went a lot further and claimed that commodore had given the processor a name (the 65000) and also were developing a new system around the processor, which would apparently also feature an Atari and Apple 8bit mode alongside various commodore modes (I'm assuming the Atari/Apple modes were done via emulation)

Perhaps anyone here or if any ex commodore people from that period come here can shed some light on this attempt by commodore to develop an upscale 6502 and how far along was the project before tramiel got wind and pulled the plug and also whether this system that featured an Atari/Apple 8bit model as well as various commodore modes how far along that was developed

Thing is, if the text in both books is true (and commodore had started then aborted development of an upscale (16bit) 6502) then why did Tramiel a few years later get commodore to tie up with Zilog and license a 16bit version of the Z80 (the z8000), which would came infamous a little after Tramiel left as it featured heavily in the legal spat between Atari/Commodore and the ST and Amiga developments

[GARTHWILSON]

From http://web.archive.org/web/201003310757 ... /65xxx.txt:

Quote:

Around 1980, MOS Technologies (having long since been bought out
by Commodore) began making noises about a 16-bit upgrade to the 6502
designed to compete with the 68000, Z8000, and 8086 microprocessor.
In the true one-upsmanship style common to semiconductor houses, MOS
Technologies called their chip the 650,000. I glanced over the
extremely tentative specs for the chip. It reminded me of Intel's iAPX-
432 processor so I immediately wrote the chip off. Fortunately for
Commodore's sake, MOS Technologies completely abandoned work on the
chip before it got out of the wish list stage.

The Commodore 65CE02 had some 16-bit operations, plus extra instructions (the op code chart was full), and it eliminated most of the dead bus cycles, resulting in at least 30 instructions that only took one cycle. There's a rundown of the differences at http://www.commodore.ca/manuals/funet/c ... 65ce02.txt, and I thought we had the data sheet here on this website but I can't find it at the moment. I have a couple of samples.

For more, see the http://wilsonminesco.com/links.html#65fam portion of my links page.

[TMorita]

The only other 16-bit 6502 I remember hearing about was the 6516.

There's more info about it in this thread:

http://atariage.com/forums/topic/151182 ... r-a400800/

EDIT: oh, it's already mentioned on the apple.org.za link...

Toshi

[Dr Jefyll]

From the link Garth supplied... http://web.archive.org/web/201003310757 ... /65xxx.txt

Quote:

The 65c816's design was not without it's problems. Bill Mensch "improved" the bus interface on the 65c816 (over that used by the 6502). Unfortunately, the Apple's disk drive controller relied on some of the old kludges in the 6502 chip. With those problems removed, the 65c802 and 65c816 chips worked fine on an Apple computer, but the disk drives didn't work. [...] If WDC wanted Apple to use the '816, WDC would have to redesign the chip. They did.

What "old kludges in the 6502 chip" were exploited by Apple's disk drive controller? Was it really a matter pertaining to the bus interface, or is that statement misleading? I'd be interested to learn more about this bump on the road to the '816's creation.

cheers,
Jeff

[enso]

The Apple ][ disk interface relied on tight timing loops, which would be broken by a processor that executes instructions in fewer cycles. That much is definitely true.

[barrym95838]

Dr Jefyll wrote:

... What "old kludges in the 6502 chip" were exploited by Apple's disk drive controller? Was it really a
matter pertaining to the bus interface, or is that statement misleading? I'd be interested to learn more
about this bump on the road to the '816's creation.

Well, it's been over twenty years, but I seem to remember yanking the 6502 from my ][+, slapping in a
65c802 that I bought from Jameco, and experimenting with 16-bit mode with no Disk ][ problems at all.
I was using an un-modified DOS 3.3 most of the time.

I was writing and hand-assembling bubble sorts and hi-res graphics routines, trying to decide just how
cool it was. In the end, I decided that it was going to be for personal gratification, since no-one else I
knew had done this upgrade, making code-sharing impossible.

Mike

[BigDumbDinosaur]

Dr Jefyll wrote:

From the link Garth supplied... http://web.archive.org/web/201003310757 ... /65xxx.txt

Quote:

The 65c816's design was not without it's problems. Bill Mensch "improved" the bus interface on the 65c816 (over that used by the 6502). Unfortunately, the Apple's disk drive controller relied on some of the old kludges in the 6502 chip. With those problems removed, the 65c802 and 65c816 chips worked fine on an Apple computer, but the disk drives didn't work. [...] If WDC wanted Apple to use the '816, WDC would have to redesign the chip. They did.

What "old kludges in the 6502 chip" were exploited by Apple's disk drive controller? Was it really a matter pertaining to the bus interface, or is that statement misleading? I'd be interested to learn more about this bump on the road to the '816's creation.

cheers,
Jeff

I seem to recall that Apple depended on the fact that some 6502 instructions did false writes on the bus during so-called dead cycles. Both the 65C02 and 65C816 do not have this behavior (but the '816 does do false reads, which can be detected via proper use of the VDA and VPA outputs). Also missing from the '816 is the SOB input that was occasionally used as a handshake for controlling a disk (Commodore did that in the 1541, for example)—I used SOB in a project of some 20 years ago to handshake SCSI operation. I wish that input were present on the '816, as it would allow me to step up the SCSI processing speed of POC V1.1.

[TMorita]

BigDumbDinosaur wrote:

...
I seem to recall that Apple depended on the fact that some 6502 instructions did false writes on the bus during so-called dead cycles.
...

I don't recall the Apple being dependent on false writes on the bus.
I did a lot of Apple II programming, so I'm pretty sure I would have remembered this.

The 6502/65816 difference which affects timing-dependent loops is the branch cycle count.
On the 6502, branches which cross a page boundary incur a clock cycle penalty.
On the 65816 in native mode, branches which cross a page boundary do not incur a clock cycle penalty. However in emulation mode, an extra clock cycle is added to maintain timing compatibility.

More info here:

http://romhack.wikia.com/wiki/6502_emulation_mode

Toshi

[Rob Finch]

Quote:

What "old kludges in the 6502 chip" were exploited by Apple's disk drive controller

I'm going from memory on this IIRC,
Not really cpu related, but I think the AppleII streched every 63rd clock so that the video timing would work out to 63.5us instead of 63 or 64. And the disk controller picked up this behaviour in it's timing.

[TMorita]

Rob Finch wrote:

Quote:

What "old kludges in the 6502 chip" were exploited by Apple's disk drive controller

I'm going from memory on this IIRC,
Not really cpu related, but I think the AppleII streched every 63rd clock so that the video timing would work out to 63.5us instead of 63 or 64. And the disk controller picked up this behaviour in it's timing.

From http://mirrors.apple2.org.za/ground.ica ... ideocycles

" It may have implications in precise speed calculations, but it only
affects the execution speed by 0.2%. I'd be more worried about hardware
implications, but there isn't anything critical enough for this to be a
serious problem."

Toshi

[MichaelM]

Rob Finch wrote:

Quote:

Quote:
What "old kludges in the 6502 chip" were exploited by Apple's disk drive controller

I'm going from memory on this IIRC,
Not really cpu related, but I think the AppleII streched every 63rd clock so that the video timing would work out to 63.5us instead of 63 or 64. And the disk controller picked up this behaviour in it's timing.

That's pretty amazing Rob to remember that detail. Your recollection triggered my memory of that interesting circuit. I no longer have my Apple II Technical Reference, long gone with my other Apple II stuff. As a young engineer, I was very much into the circuits of the Apple II, and this particular circuit was "magic" in my opinion given my complete lack of experience or knowledge of the particulars of NTSC video.

I looked this up in the Gayler book (Howard Sams Books), and he describes the circuit as being related not as much to the horizontal scan frequency, but to the phase of the color burst frequency. By stretching the clock period of every 65th Apple II clock cycle, the starting phase of the color burst signal could be properly maintained from line to line so that the color decoder in standard TV sets would operate correctly when the Apple II was attached.

The color burst frequency was correct because the Apple II actually operated from a 14.31818 MHz crystal. The basic clock for the processor was that frequency divided by 14, or approximately 1.023 MHz. The clock stretching required for an integer number of color burst frequency periods per horizontal line brought that number down a small amount to (65 / ((64 * 14) + 16))) * 14.31818 MHz, or 1.02048 MHz. (Every 65 cycle is stretched by two 14.31818 MHz clock periods. That's why there are 64 * 14 + 16 clock cycles in every group of 65 Apple II clock periods.)

[enso]

I don't believe that a 2% clock jitter affects the operation of the drive in any measurable way, personally. The drive was designed to work within a very wide tolerance window, given that the spindle motor rotation rate varies among drives.

I've had to recalibrate the drive, and believe me, it operates over a pretty wide range of rotation, easily detectable by my ear as different pitch.

[TMorita]

enso wrote:

I don't believe that a 2% clock jitter affects the operation of the drive in any measurable way, personally. The drive was designed to work within a very wide tolerance window, given that the spindle motor rotation rate varies among drives.

I've had to recalibrate the drive, and believe me, it operates over a pretty wide range of rotation, easily detectable by my ear as different pitch.

It's 0.2%, not 2%.

Also, it's technically incorrect to describe this as "clock jitter".
Wikipedia describes jitter as:

"In electronics and signal processing:
Jitter, an irregular time variation of period signal properties, such as small, unpredictable delays in scheduling."

The clock frequency deviation in discussion is regular rather than irregular.
So this does not match the denotation of the word "jitter".

If I remember correctly, the Apple II disk drives were fairly insensitive to drive speed variation because the data was encoded using GCR with no more than two zero bits in a row. This allows the clock used for the sampling the data to frequently resynchronize with the implicit clock in the data coming from the disk drive.

Toshi

[TMorita]

BigDumbDinosaur wrote:

I seem to recall that Apple depended on the fact that some 6502 instructions did false writes on the bus during so-called dead cycles. Both the 65C02 and 65C816 do not have this behavior (but the '816 does do false reads, which can be detected via proper use of the VDA and VPA outputs). Also missing from the '816 is the SOB input that was occasionally used as a handshake for controlling a disk (Commodore did that in the 1541, for example)—I used SOB in a project of some 20 years ago to handshake SCSI operation. I wish that input were present on the '816, as it would allow me to step up the SCSI processing speed of POC V1.1.

Based on what I found it looks like you're almost correct. I finally found a reference to this, and apparently the Apple Disk II controller is dependent on the dummy read cycle generated by an indexed store instruction. I found a reference to it in Jim Sather's "Understanding the Apple II" in the disk controller section.

See page 2 of this PDF:

http://apple2online.com/web_documents/u ... rt_11_.pdf

"The STA $C08F,X without indexing across a page boundary actually puts $C08F,X on the address bus for the last two MPU cycles of this four cycle instruction. The first $C08F,X cycle is a read access and the second is a write access with the MPU controlling the data bus during the greater part of PHASE 0. The first $C08F,X cycle causes READ/WRITE to switch to WRITE about 90 nanoseconds after PHASE 0 rises."

So apparently the false read of $C08F,X triggers the logic state sequencer in the Disk II controller to be in a write mode for the subsequent store.

This explains the note in the 65816 and 65832 documentation which states, "VDA and VPA should not be used to qualify addresses during disk operation on Apple systems. Consult your Apple representative for hardware/software configurations."

Toshi

[Tor]

But we shouldn't look for differences between the 65c816 and the 6502/65c02, let me re-quote what Dr. Jefyll quoted:

Quote:

The 65c816's design was not without it's problems. Bill Mensch "improved" the bus interface on the 65c816 (over that used by the 6502). Unfortunately, the Apple's disk drive controller relied on some of the old kludges in the 6502 chip. With those problems removed, the 65c802 and 65c816 chips worked fine on an Apple computer, but the disk drives didn't work. [...] If WDC wanted Apple to use the '816, WDC would have to redesign the chip. They did.

Note the "They did." part. So the 65c816 from WDC is a redesigned variant, from the quote it looks as a particular piece of the original 65c816 design was modifed before production really started. If so, then there's not much point looking at current 65c816 behaviour when trying to figure out what the issue with the disk drives could have been.

-Tor