Ben Franchuk <bfranchuk(a)jetnet.ab.ca>ca>: Back when I used to spend long blissful evenings hand-assembling Z80 programs [1] I got the impression that Z80 code was more compact than 6502 code, being able to manipulate 16-bit values with single instructions in many cases. Whether it was actually faster I don't know, but I suspect it was, as long as you stuck to the 8080-like core instructions which didn't take ridiculous numbers of cycles to execute. [1] I didn't do it in a storage locker, although I did often had the heater on in winter. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

Ben Franchuk <bfranchuk(a)jetnet.ab.ca>ca>: Well, yes. But there wasn't much choice in those days. I did start building a 6809-based machine once. Got as far as getting the CPU, memory (56K RAM + 8K EEPROM) and 6845-based monochrome bitmapped graphics display working. But by then ready-made 68K-based machines were around, and it didn't seem worth building a homebrew machine any more. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

--- Louis Schulman <louiss(a)gate.net> wrote: I'm not sure it has anything to do with resistance. Tinning _does_ help with attaching components. I would. Carefully. I think the biggest benefit gained from tinning spots that _don't_ have components attaching to them is that bare copper traces could oxidize all the way through, especially if they are exposed to a corrosive agent (from ammonia to human sweat). I think tin oxides are more protective of the underlying metal, much like aluminum oxides. I am not a chemist or metallurgist, but I _think_ it works like that. -ethan __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com

On Thu, 20 Dec 2001 02:56:31 -0500 (EST), John Lawson wrote: # Just a quick (dumb) question: is this 'tinning' silver? Or Green? In #other words, has the solder itself actually flaked off the trace (meaning #it never bonded in the first place) or has the 'paint' coating called the #solder mask, which is usually green, come off, revealing the trace beneath #it? This very common, and Ethan is right, it should be carefully re-tinned #to avoid long-term corrosion. # It is the actual solder, indicating it did not bond properly in the first place. There is no green coating on this PCB, the board and the tinned traces have no coating over them at all. Louis

On Thu, 20 Dec 2001 19:39:31 +0000 (GMT), Tony Duell wrote: #> before tinning, so the tinning lost its grip. # # #Do you mean the 'tinning' -- as in the solder layer? Or the (normally #green) solder mask? If it's the latter, then don't worry about it. I mean the tin/lead solder coating. There is no green mask on this board, it is bare. # #> #> My questions is this: Is the copper itself sufficient to carry the currents, or is the tinning required to reduce # #Oh, I think the copper will easily carry the current... # #What worries me is that if this tinning is flaking off, are the soldered #joints between components and the tracks still good. Or are they going #open-circuit. If I had a board like this, I'd want to resolder everything... Well, I have this concern as well. My theory, since I don't want to resolder everything, is that when the components were soldered, this reflowed the tinning on the track, making a better bond. The board works, so there are evidently no open circuits. The copper where the tinning peeled off has a tarnished color. # #> Or, putting it one last way, do I need to re-tin the bare spots? # #And yes, I'd re-tin any tracks with missing tinning. # Louis

Ethan Dicks wrote: I suspect the memory interweave was a after thought as memory at that time was 2x faster than the CPU. The video/dram refresh was a good idea for the 6502/6800/6089. I am glad I did not have to program the 6502 however. Nowdays with all the pipelineing, prefetching and other stuff nobody knows how slow a cpu can be. At one time I looked at doing a 68000 cpu but the only small 68000 was the 68008 and it seemed too slow to be useful. -- Ben Franchuk --- Pre-historic Cpu's -- www.jetnet.ab.ca/users/bfranchuk/index.html

I've been on both sides of this question on a number of occasions and I've found that the real challenge is to figure out what defines a level playing field for such a comparison. I once concluded that running each processor at a rate amenable with the same memory bandwidth was appropriate, but there are a number of quesitons, still that have to be resolved. (1) the 6502 is designed in a way that lends itself very well to shared use of its memory, i.e. using the memory for the CPU during phase-2 and letting a memory-mapped video refresh circuit have it during phase-1. That's quite reasonable and impacts the 6502 very little, but, if you try to do the same thing with a Z80, you get tangled up with its variable cycle lengths pretty quickly. (2) the Z80 demands a pretty short cycle for its instruction fetch (M1) cycle, and, if that's to be the rate-determining step for the cmparison, i.e. if the memory bandwidth requirement is determined on that basis, (no wait-states allowed) then the 6502 will eat it alive. That, of course, is because 50% of its memory bandwidth will be frittered away due to the fact that the M1 cycle is short and has a wasted tail end (refresh cycle) while the 6502 doesn't have that burden. Further, if that determines the memory bandwidth, then the M1 cycle (~400 ns with 200ns memory of the era) means that a 4 MHz CPU wouldn't be able to run with it. Fairness might demand a wait state, but that would then raise the question of what's the bus bandwidth at which the 6502 will be run (assume a 20 MHz 6502 and a 20 MHz Z80, but use memory of their own era.) Also, the refresh cycle itself is a mite short for what the CPU does at 4 MHz. How would one stretch it to where it wouldn't impinge on the next memory cycle? If you have to share the memory bus of the 6502, why not the Z80 as well? If you can use timing tricks, why not on the 6502? I'd say use whatever timing tricks the two CPU's can live with, but run them to their best advantage. Run phase-1 on the 65-2 for only 25 ns, then switch to phase-2 for whatever time the Z80 uses the memory. Let the Z80 use a wait or two in the M1, and stretch the refresh so the cycle can be complete when the next cycle is in progress. Since non-M1 memory cycles are 3 clock ticks, the clock could be pretty fast, couldn't it? (Can you see how this gets tangled up in technical problems of fair comparison? That's BEFORE the question of what sort of benchmark software is to be used comes up.) The shortest 6502 instructions take two clock ticks, but some overlap the next instruction fetch. The shortest Z80 instructions take an M1 cycle, followed by refresh, to fetch, and I'm not sure whether they execute during the refresh (they're internal, so that's conceivable) or whether they produce an idle bus cycle. I also don't know what happens during that idle bus cycle. Simply sitting down and calculating the relative instruction timing might not be so easy. It certainly won't be easy to get right. My own experience has been that in controller applications, manipulation of 16-bit values doesn't come up as often as I once believed. Mostly it seems the values that are dealt with are 8 bits or fewer. Others may see this differently, however. Dick ----- Original Message ----- From: "Greg Ewing" <greg(a)cosc.canterbury.ac.nz> To: <classiccmp(a)classiccmp.org> Sent: Wednesday, December 19, 2001 3:30 PM Subject: Re: MITS 2SIO serial chip?