In article <[EMAIL PROTECTED]>, ZN <[EMAIL PROTECTED]> writes >>> The problem with the Motorola 68000 series is that they aren't making >>> them anymore. >> >> They do. Unfortunately, it's something of a poor relation. They're made >on >> .5 or .65u processes with aluminium interconnects - generally very old >> hat. If they were fabbed at even .25u, they would happily run at >250-400MHz >> speeds. But that would cost a few tens of millions of bucks ;) > >Actually, the biggest problem with the 68k family is that Mot. does not >want to sell the licence to anyone else, so that even FPGA cores that >implement the same instruction set are, strictly speaking, illegal. >Besides, there are compatible (or close enough) CPUs based on the 68k >manufactured using .25u process, the V4 ColdFire. Even here we have a >problem, which is Mot. dawdling over making the chips more freely >available. They are targetted at the embedded OEM market and get 'compiled' >to order along with peripherals. HP uses them profusely in their printers, >for instance, because Mot. gladly maks speciffic versions that reduce the >printer to 2 chips. >The validity of the 68k concept is certainly obvios, otherwise it would >have died a long time ago. Instead, an attempt to reduce the instruction >set in the previous generation ColdFire's has been all but reversed with >the new ones, which can be made almost completely compatible - if you can >get Mot. to sell them to you!
Thanks for the clarity around the 68k. I was gettting the impression that the series had come to the end of its development potential. In terms of Mot doing the manufacturing. Yet obviously not the case. HP do make very good printers ... so that's how they are doing it :-) I guess it is very financially worthwhile too ... as every computer needs a printer, or two. >There are a couple of alternative aproaches, all of which have problems >with mustering the required amount of manhours to make them work. >One interesting possibility would be a Transmeta CPU with a 68k code >interpreter. Even the smaller Crusoe would do just fine. In this case you >also have the problem in getting Transmeta to provide the data to write the >interpreter. Transmeta has invested a lot of work in producing their code >morpher for I86 CPUs, and they principally want to sell you the licence for >that - the CPU just comes along. On the otehr hand, a 68k interpreter or >(wishful thinking) code morpher could be a lucrative venture. The QL >community by far isn't the only one wanting faster 68k CPUs. This is interesting ... what other approaches are there ? >> Is there any QDOS/compatible OS that's written in C? I could try to get >it >> converted to compile on ARM chips - I realize for QDOS itself that's a >> no-no, as it's basically hand assembly... what's the nearest to a version >> of QDOS written in C? > >There isn't one. In fact, I wish there was one because it could be used as >a classic comparison of Assembler vs C efficiency :-) > >>Finally, with "open hardware", and/or doing it the old-fashioned way, >>what is the likely interest in a QL-compatible SBC? note the Q40/Q60 are >>not an SBC - an SBC would have the interfaces and connectors all built >>onto the same board. I can hunt around for a schematic for the original QL >>and dig out my SQB schematics and see what else could be added in... This >>isn't likely to happen, but if it was, what would people be looking for? > >Well, not that I am putting down the idea, but wouldn't that be a step >back, especially considering your lamentation re 68k not being available on >a .25u process :-) >Strictly speaking, no there are no QL based SBCs, but the problem here is >that QL developement being what it is, there is an interesting problem of >conflicting requirements: >1) Because of limited resources, we get to design such a thing about once >in a decade, which means a lot has to be anticipated - whatever is designed >has to last a decade! >2) 'Evolving' too far away from existing hardware results in problems with >actually using the new features - entirely because of a lack of open >_software_ developement, namely the OS. >3) At the same time, whatever you come up with gets compared to the latest >PC, but is required to be able to use all the old QL bits. > >Hardware developement is not really a problem, to tell you the truth. It's >making the OS cope with it that's the real problem. This really requires >the designer of the hardware to become a one-man band and do boththe >hardware, and the software - that's very unlikely to happen. >By all means, I applaud your open hardware developement idea, but I would >at the very least like to see it followed by open software developement - >maybe even preceeded by open software developement. < clip > -- Malcolm Cadman
