Live data from Hacker News

The MOS 6502 and the Best Layout Guy in the World

research.swtch.com

41–50 of 53 posts

Re: The MOS 6502 and the Best Layout Guy in the World

#41
post #5

Earlier quoted context omitted.

Plus, it was delightful to program. Simple maybe, but not delightful to program. I don't know of any assembly language that is delightful to program. BTW, I knew someone from junior high & high school who could write code for the 6502 using a hex dump with amazing speed. You might have heard of him: Randy Linden.

I had a lot of fun with the 6502 and I really liked the 6809, so I guess they felt delightful to me. It is a different type of mindset and can really make you focus on the problem at hand. The IBM 370 was a might bit of a pain though.

One of the delightful things in programming a 6502-based computer is the relative importance of the OS. In those times, you had complete control over the machine and you called the OS (or the ROM routines) to do whatever you wanted it to.

I remember that when I had to do floating-point math or calculate a screen address (something convoluted on an Apple II) I would simply call a subroutine in ROM and pick up the results.

Re: The MOS 6502 and the Best Layout Guy in the World

#42
post #40
post #37

Earlier quoted context omitted.

You use two cycles, but the 6502 could execute the instruction while fetching the next one.

That's not the pattern I see when looking at the op-code/cycle chart. I recently implemented part of a C64-emulator in JavaScript and it seems very much like every step takes a cycle. For example the instructions NOP(or CLI, STI, INX etc), 1 byte, 2 cycles. 1 cycle for fetching the instruction and one for executing the fetched instruction. LDA addr,x seems to be pipelined a bit though. It's "AD lo hi" in memory and t…

I will have to dig up my 6502 documentation, but, IIRC, by the time the processor executed the NOP (CLI, INX etc) it already fetched the next instruction, so, if it's another NOP, it will complete in one cycle instead of two. Unless you crossed a page boundary, which implies a one-cycle penalty.

Re: The MOS 6502 and the Best Layout Guy in the World

#43
post #42
post #40

Earlier quoted context omitted.

That's not the pattern I see when looking at the op-code/cycle chart. I recently implemented part of a C64-emulator in JavaScript and it seems very much like every step takes a cycle. For example the instructions NOP(or CLI, STI, INX etc), 1 byte, 2 cycles. 1 cycle for fetching the instruction and one for executing the fetched instruction. LDA addr,x seems to be pipelined a bit though. It's "AD lo hi" in memory and t…

I will have to dig up my 6502 documentation, but, IIRC, by the time the processor executed the NOP (CLI, INX etc) it already fetched the next instruction, so, if it's another NOP, it will complete in one cycle instead of two. Unless you crossed a page boundary, which implies a one-cycle penalty.

I see, but that's not how it worked on the C64 at least. I did some raster-programming and counted cycles a lot.

Re: The MOS 6502 and the Best Layout Guy in the World

#44
post #43
post #42

Earlier quoted context omitted.

I will have to dig up my 6502 documentation, but, IIRC, by the time the processor executed the NOP (CLI, INX etc) it already fetched the next instruction, so, if it's another NOP, it will complete in one cycle instead of two. Unless you crossed a page boundary, which implies a one-cycle penalty.

I see, but that's not how it worked on the C64 at least. I did some raster-programming and counted cycles a lot.

Since I never wrote timing-critical code for the 6502 (apart from "make it as fast as possible") I cannot recall many specifics. Since you did, you certainly have a better understanding of how it worked.

I am restoring a 65c02-based //e clone, so, I may be able to properly measure instruction timings, but I won't hold my breath.

Re: The MOS 6502 and the Best Layout Guy in the World

#45
post #44
post #43

Earlier quoted context omitted.

I see, but that's not how it worked on the C64 at least. I did some raster-programming and counted cycles a lot.

Since I never wrote timing-critical code for the 6502 (apart from "make it as fast as possible") I cannot recall many specifics. Since you did, you certainly have a better understanding of how it worked. I am restoring a 65c02-based //e clone, so, I may be able to properly measure instruction timings, but I won't hold my breath.

Ye well, it could be C64-specific quirks since it shared the bus with the graphics hardware.

Sounds like a fun project.

Re: The MOS 6502 and the Best Layout Guy in the World

#46
post #5

Earlier quoted context omitted.

Plus, it was delightful to program. Simple maybe, but not delightful to program. I don't know of any assembly language that is delightful to program. BTW, I knew someone from junior high & high school who could write code for the 6502 using a hex dump with amazing speed. You might have heard of him: Randy Linden.

Heh, yeah I still remember 6502 opcodes... 4C xx xx is jmp absolute, 20 xx xx is jsr (jump subroutine) absolute, A9 xx xx is load accumulator absolute, 8D store accumulator, 60 is rts... I could go on. Typing shit in to the hex monitor for a few years will do that :)

A9 xx xx is load accumulator absolute

Make that A9 xx; The 6502 accumulator is 8 bits.

Re: The MOS 6502 and the Best Layout Guy in the World

#47
post #44
post #43

Earlier quoted context omitted.

I see, but that's not how it worked on the C64 at least. I did some raster-programming and counted cycles a lot.

Since I never wrote timing-critical code for the 6502 (apart from "make it as fast as possible") I cannot recall many specifics. Since you did, you certainly have a better understanding of how it worked. I am restoring a 65c02-based //e clone, so, I may be able to properly measure instruction timings, but I won't hold my breath.

It seems that all the mysteries of 6502 timing have been revealed thanks to the Visual 6502 project http://www.youtube.com/watch?v=H_15RtVbqGU#t=5m33s http://www.visual6502.org/ .

Re: The MOS 6502 and the Best Layout Guy in the World

#48
post #38
post #31

Earlier quoted context omitted.

In his talk http://www.youtube.com/watch?v=HW9AWBFH1sA#t=3m01s Michael Steil claimed that the 6502 had 60% fewer transistors than the Z80 but was twice as fast (in clock terms, I presume), while the Z80 had more registers and allowed slighly denser code.

> while the Z80 had more registers To somewhat counter that, the 6502 could read and write to the first 256 bytes of memory with shorter instructions. The 65816 expanded that idea to allow you to do that to any place in memory.

The Western Design Centre actually describes the 65xx as an addressible register architecture http://www.westerndesigncenter.com/wdc/Presentation_Artwork/... [zipped PPT], and by that I assume they're describing the zero-page addresses as registers.

Re: The MOS 6502 and the Best Layout Guy in the World

#49
post #31
post #4

Earlier quoted context omitted.

I'm curious why you think so (about the Z80, I mean). I seem to remember it being in very cheap computers as well (ZX Spectrum, doesn't get much cheaper than that) and was a great deal faster. I grew up with a 6502 and love it like a childhood pet but can't see how it 'ran rings' around the Z80.

In his talk http://www.youtube.com/watch?v=HW9AWBFH1sA#t=3m01s Michael Steil claimed that the 6502 had 60% fewer transistors than the Z80 but was twice as fast (in clock terms, I presume), while the Z80 had more registers and allowed slighly denser code.

I'll take a look at that, thanks. The typical Z80 had ran 4 times the clock rate at the 6502. Both CPUs had their pluses and minuses and I think for many practical purposes were roughly comparable. The design differences and choices are certainly interesting. I don't think the OP was right to claim the 6502 'ran rings' around the Z80 and that remains the case, after all the comments I got.

Re: The MOS 6502 and the Best Layout Guy in the World

#50
post #46

Earlier quoted context omitted.

Heh, yeah I still remember 6502 opcodes... 4C xx xx is jmp absolute, 20 xx xx is jsr (jump subroutine) absolute, A9 xx xx is load accumulator absolute, 8D store accumulator, 60 is rts... I could go on. Typing shit in to the hex monitor for a few years will do that :)

A9 xx xx is load accumulator absolute Make that A9 xx; The 6502 accumulator is 8 bits.

Thanks for the correction, you're right A9 is load immediate I was mixing it up with AD xx xx which follows as 8D is the equivalent store.

I wasn't saying that the accumulator was 16 bit though, rather that the load is from an absolute 16 bit address.

Post reply on HN