On 25/10/02 at 20:51 Dave P wrote: [68SZ328]
>Can it support: >A simple expansion interface? Yes. In fact, it is easy even to do a Ql style bus as it has 8 decode areas which can be configured to be either 8 or 16 bit, automatic transfer termination or external, etc, etc. >Some kind of expandable flash area? Flash ROM is external and can be 8-bit (or 16 bit) - the trick is that it uses one of the decodes as a 'boot', i.e. all addresses are initially routed to it, with sensible bus speed parameters etc. I think each decode is up to 16Mbytes so... >What roughly would be the cost of such a system, and the design period? I >understand the issue with it being a BGA, as I have had to deal with that >once with the 7500FE in a mBGA package, where the boards had to be sent >off for x-ray checks of the mounting. *shudders* It can be avoided if the balls sit on vias, but it makes the PCB a bit more challenging. >> - effectively a 66MHz 68000 (and could possibly be made to run a bit >> faster than that) >If the "manufacturer" routinely stuck a nice big fat heatsink on it? Not even that I suspect. The SZ is a curious beast, I think it runs on 3.3V with a 5V IO compatibility, but it's core is low voltage and it uses an internal regulator. IIRC it only uses somethink like 1W of power - after all, it is intended to work in a PDA. >> - 'connect the dots' system design - has everything on the chip and >> interfaces with everything else with, in most cases, 0 glue logic. In >> particular things that every system needs to have, such as SDRAM, Flash, >> peripherals... this all means that designing the hardware is easy and >> quick. >Would this require custom logic? CPLDs? Any of those other little >complexities that slow down a design? :o) For most of it, it requires nothing - as you say, it's a question of mechanics rather than electronics. Perhaps the IDE interface would benefit from some buffering and an external decoder, but this could best be done by surface mount 74HCT or similar devices as PLDs, as good as they are at fitting lots of glue logic into a small space, use hundreds of times more current. >What I was playing around with on my ARM design (and I just KNOW what >Nasta's gonna say about this!) was more mechanical than electronic. He is going to say that this is exactly the case - a 68SZ328 system would essentially be about 10 chips all told, and most of the problem would be fitting all the connectors in the limited space available! >> RAM is currently cheap enough that one could simply stick on the >> maximum possible size and leave it there (I believe that's 64MB >> but there are tricks to expand this as the internal addressing >> is 32 bit). >I suspect making the "trick" standard might be a smart idea. The thing is, the user's manual for the SZ is HUGE, I think 12Mbytes PDF or something like that. It takes a while to dig out the relevant data. IIRC the limit has to do with the SDRAM decoder being able to drive only two banks of SDRAM, not to be confused with the banks inside the RAM chip itself (usually 4). This has to do with a limit on the number of pins to interface to the SDRAM. Another side of that is the support for linear or bank interleaved memory access. The first is best for the video circuits, but slower for the CPU, while the latter is best for the CPU but VERY slow for the video. In addition, when both CPU and video operate in the same bank, they additionally get in the way of one another. The optimum solution would be to dedicate the two banks as follows: Bank 1 would be configured as interlieved. This could then be optimized for size - by making the chips 'narrow' (4 bits) but 'deep' - currently 64M x 4 are available so one 16-bit wide bank would be 128M bytes of RAM. The disadvantage is that it's 4 chips. The largest available single chip is 16M x 16 (=32M RAM), the middle solution would be two chips with 32M x 8 (=64M RAM). All are commonly available. The other bank would be an x16 organization chip and doesn't need to be large, the point being it should be set up as linear and be the screen RAM. This could be expanded but the access would be slower for the CPU, while being optimal for video. Because it is separate it also does not interfere with the interlieve from the first bank so provides best possible bandwidth for video. This could also hold other things that require linear access, such as sound files etc. The SZ also has DRAM controllers which can shift data about quite quickly, and in a semi-automatic manner. >> The negatives: >> 2) Video goes up to 1024x512 max and 65536 colors, but is in practice is >> limited by the total data rate from memory, as it's a shared memory >> system (like the original QL). >And just like the ARM7500FE. It's a trade-off of colour-depth against >resolution. I would take a sweet 256 high res desktop over a chunky >65536-colour desktop any day of the week - but generally, the window >managers are so disappointing graphically that more colours don't really >give anything... (imho, personally, for me. ymmv!) QDT may prove you wrong. But then, it's 256 color based. That's perfectly enough IMHO, anyway. I think the SZ could do VGA-ish x 512 in 256 colors no problem. Perhaps even the full 1024x512. It even has a palette. There is also a 12-bit color mode but it essentially throws away 4 out of 16 bits and provides no advantage either in memory size used or the required bandwidth. >> A genie in a lamp so I can wish away the cr*p that is going to happen in >> the next two months as I prepare to move and then move back to Croatia. >> More about that privately, if you want - or you can give me a ring. > >Could you email me your number and I can call you this evening? It'll save >me having to go through the hundreds of emails in my Nasta folder looking >for it - rereading ONE of your epic emails takes a good while!;) 704 597 1283 N.
