bowdidge@cory.Berkeley.EDU (Robert Bowdidge) (03/30/88)
Robert Freimer (freimer@svax.cs.cornell.edu) gave the best reason why the
project (put a mac-like interface on the TRS-80 Model 4) couldn't work --
speed of the hi-res board. The puppy takes quite a while (2 seconds?) to
clear the screen. Does anyone know why the board is so slow? Is it just the
OUT instructions take a certain amount of time, or can the graphics board
delay the processor 'till it finishes an instruction?
George Madison's suggestion about needing a good input device is correct; the
solution might be to just get an Apple mouse. The mouse used for both the
Apple II line and for the Macintosh is not a proportional one like the
Radio Shack mouse but (what I believe) is a superior design, sending a signal
when it's gone up, down, left, or right a unit. We could poll it during
interrupt time (as is done on the Apple IIc.)
Finally, George's comment about Z-80 versus 6502: I thought that a 6502 ran
faster because it was able to pipeline instructions. Almost (99+%) every
cycle is a memory fetch, and since both can only deal with 8 bit data, I would
assume that this could make the 6502 faster. It's also the first "RISC"
machine; it's got a simple instruction set that can be operated fast.
Expert opinions welcome.
Anyone want to start coding?
-- Robert
Robert Bowdidge
==========================================================================
..ucbvax!cory!bowdidge | bowdidge%cory@ucbvax.BERKELEY.EDU uhclem@trsvax.UUCP (04/01/88)
B>speed of the hi-res board. The puppy takes quite a while (2 seconds?) to B>clear the screen. Does anyone know why the board is so slow? Is it just the B>OUT instructions take a certain amount of time, or can the graphics board B>delay the processor 'till it finishes an instruction? It's been a while since I wrote code for that board, but it does have a few gotchas that make it slow. First, it is I/O mapped. So you have a port for X, Y, control and data. The "real" model 4 graphics board provides some assist in that it can be programmed to increment either the X or Y pointer after a read and/or write. So a code fragment like this would clear one line of pixels: xor a ;[4-t] out (x),a ;[11-t]Set x to zero ld b,50h ;[7-t]80 bytes (8 bits per byte) xloop: out (data),a ;[11-t]Clear 8 pixels djnz xloop ;[13-t/8-t]Do some more Yeah, I didn't set the Y coordinate, THIS IS AN EXAMPLE. That code took 1079 T-states. That works out to 269.75usec to clear a single scan line. Now just to repeat that code for the entire screen we get 269.75 x 200 = 53,950usec, not including code to increment Y, write it out to the hardware and determine when we have done it 200 times. Now 54msec is speedy enough, but there are more problems. The most important is that the Model 4 asserts waits on the video system accesses to avoid hashing. The system will hang until a vertical or horizontal retrace (min 64usec). So at best the above code may only get two of three bytes updated per horizontal sync, which changes the time to 1,706usec per line or 341,333usec for the screen (real rough, best-case figures.) The Model 4 graphics adapter allows you to disable the wait mechanism (you get hashing), but most code was written for the Model III board and does not utilize that function. Hashing would be acceptable if it occurred during operations that update the entire screen (clearing or filling.) The Model 4 board also allows normal ASCII text to be mixed on the screen with graphics, instead of having to draw the characters in pixels the way the Model III board did. Again, I don't know of any software that takes advantage of this way to speed text output. (Collisions of "on" pixels between graphics and text are XORed.) Also, BASICG was written for the Model III board, and even then rarely uses the autoincrement functions, so the potential speed of the board cannot be judged by the time it takes to do something in BASIC, even if it is a single statement like CLR. At one time, BASIC set the X and Y coordinate for each access. Oh yes, all of the Model III and a lot of the Model 4 software kicked the CPU speed down to 2MHZ. The Model III did it because they were setting other bits in a port and the speed bit was only a "RESERVED" back then, and the Model 4 software did it because it wasn't noticed, the Model III code worked as it was, etc. So double all the times above for 2MHZ. B>George Madison's suggestion about needing a good input device is correct; the B>solution might be to just get an Apple mouse. The mouse used for both the B>Apple II line and for the Macintosh is not a proportional one like the B>Radio Shack mouse but (what I believe) is a superior design, sending a signal B>when it's gone up, down, left, or right a unit. We could poll it during B>interrupt time (as is done on the Apple IIc.) It is fairly easy to interface the Tandy PC and/or 2000 mouse board to the Model 4. This required three of four IC's. I wrote drivers for this a few years ago but nothing ever came of it. In addition to setting the system clock and date (fringe benefit), the driver had two modes: translate a certain amount of movement in any direction into the appropriate arrow keystrokes and push them into *KI or the user program could make a SVC call to ask what the mouse has done since the last time I looked. Because of the mouse processor's design, using its interrupt capability was not possible. It interrupts far too often. If you are interested in information on this (schematics, etc.) send me mail. B>Finally, George's comment about Z-80 versus 6502: I thought that a 6502 ran B>faster because it was able to pipeline instructions. Almost (99+%) every Hard to believe and it goes against everything I have ever heard. Like the 6809 (designed by the same group of people), the 6502 gets far more bang for the cycle, and when you are doing memory mapped operations, it should run away from the Z80. Don't forget that the Z80 always inserts a refresh cycle after each M1 (opcode fetch) cycle even if it is not really time for one. The resulting overkill eats away at performance. The HD64180 (Z80 + stuff) selectively inserts wait states based on how you program it and that helps some. It also has some additional opcodes like MUL and some test and set/reset which would be nice for graphics. <My opinion, not that of my employer. They would rather none of the mentioned processors or computers (except for the PC [Ed: please stand]) ever existed. This is because some of them are better than what is now advertised as being "state-of-the-art".> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...convex!infoswx!hal6000!trsvax!uhclem ...ihnp4!sys1!hal6000!trsvax!uhclem