home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / cpm / z280 / new280.txt < prev    next >
Text File  |  1994-07-13  |  8KB  |  125 lines
  1.                        Some Ideas for a new Z280 product
  2.                        ---------------------------------
  3.  
  4. Soon after the Z280 became available I acquired two samples and began 
  5. experimenting. At this moment I have an S100 board working of sorts and am 
  6. beginning to give serious consideration to bringing out a product based on the 
  7. 280. The idea behind this document is to get ideas from prospective users on 
  8. what form it should take and what features should be included to be of most 
  9. use.
  10.   Currently I am using an ICD XLM180, a 64180 based S100 system with 2 
  11. floppies, hard disk, tape backup and 512k memory, to which I have added an 
  12. Illuminated Technologies 1024x1024 color graphics card. Any new system should 
  13. have at least the capabilities of this, and preferably more.
  14.  
  15. Bus Structure
  16. -------------
  17.   The present system uses IEEE S-100 bus which I find very satisfactory. 
  18. However I would not use it for the 280 system. Why? Because first, the 280 
  19. cannot generate strict IEEE spec signals, specifically the sM1 signal. Though 
  20. it is possible by means of external logic to distinguish fetches of operands 
  21. and opcodes and thus generate a sort of sM1 signal, it would be useless as 
  22. because of the cacheing and pipelining in the 280, fetching and execution are 
  23. wholly asynchronous events, thus none of the usual uses of this signal would 
  24. work (hardware debuggers and the like). Second there is the lack of choice of 
  25. really up-to-date peripheral cards for the bus. After lookink at several 
  26. alternatives, I have chosen the IBM AT bus.
  27.   The AT bus is lousy. It is sadly deficient in a number of areas, but most of 
  28. these do not matter to a single user system. In its favour there is an enormous 
  29. wealth of cheap and technically advanced peripheral cards available, and the 
  30. mechanical hardware needed for building an AT-like system is cheap and readily 
  31. available. The 280 can easily be made to deliver 286-type signals to give 
  32. wholly compatible bus timings. As far as I can see the only peripherals that 
  33. would not work without modification would be hard-cards and the like which 
  34. contain ROMS full of 8086 code, which would have to be changed. But as the 
  35. system would come with a hard disk as standard I see no need for hard-cards.
  36.  
  37. Disks
  38. -----
  39.   I propose two 3.5 inch floppies (800k each) and a 40MB hard disk. Though 3.5 
  40. inch disks are not widely used outside 68000 systems, they have surely proved 
  41. themselves and are a big improvement over 5.25 and (heaven forbid!) 8 inch 
  42. floppies. Also they will help to keep the size down. The AT, and my XLM180, are 
  43. huge beasts, and I don't want my new machine to be any bigger than an XT. But 
  44. the disk controller used will support 4 floppies so external 5.25inch drives 
  45. can always be used to read older disks. The hard disk controller would be SCSI 
  46. and easily replaceable for future upgrades.
  47.  
  48. I/O
  49. ---
  50.   Two serial ports, Centronics parallel, and SCSI ports would be included on 
  51. the mother board, as well as a 2400/1200/300 baud modem. Additional I/O can of 
  52. course be added on plug in boards in the six expansion slots provided.
  53.  
  54. Keyboard and display
  55. --------------------
  56.   A normal AT-type plug-in keyboard would be used. The display would be wholly 
  57. unlike anything on an AT, being a bit-mapped 1024x768 color screen of 15 inch 
  58. diagonal. The dispay would use its own processor, a TMS34010, and its own 768KB 
  59. of memory which would be independent of and not encroach the main address 
  60. space. Graphics cpu program memory would, however be accessible to the Z280 so 
  61. new graphics primitives could be developed and loaded. This memory, accessible 
  62. to both processors would be accessed on an alternate-phase system permitting 
  63. both cpu's to access at full speed without using DMA. Graphics commands would 
  64. be passed through a small bloc of this memory. The bit-mapped display would 
  65. enable anything that could be done on a Mac to be done on this machine, and in 
  66. full color. And the resolution is sufficient for decent CAD applications.
  67.  
  68. Memory
  69. ------
  70.   There would be room on the motherboard for 32 memory chips, giving 1MB using 
  71. 256k chips or 4Mb using 1Mb chips. This could be expanded on external memory 
  72. boards to 16Mb, less that used for ROM and the 128k or so of graphics 
  73. primitives.
  74.  
  75. Power Supply
  76. ------------
  77.   A 200 watt supply using a special circuit of my own which gives very high 
  78. efficiency and large power/volume ratio. This will help keep the size of the 
  79. unit down.
  80.  
  81. Operating System
  82. ----------------
  83.   I'm currently thinking of some form of ZRDOS, either a modification by me, 
  84. Echelon, or a third party, or a wholly new clone of same. To be useful in such 
  85. a system, ZRDOS needs adding to it (a) large memory model support (b) graphics 
  86. support, and (c) multitasking would be very useful. Large memory models need 
  87. careful thought; I am already using large (by this I mean >64k) programs on my 
  88. XLM180, but to do the addressing I have to manipulate the MMU registers from 
  89. within the applications program, a highly unportable approach, and one 
  90. impossible on the 280 as changing the MMU registers is a privileged instruction 
  91. and can only be done in system mode. So we need a set of standardised OS calls 
  92. for this purpose, as well as a means of loading a large program (cf. EXE files 
  93. in MeSsyDOS). As far as the graphics are concerned, why not take a look at the 
  94. way the Mac does it. On the IBMs, it's a hopeless mess and I don't see much 
  95. point in emulating that. Also we need an operating system call to 
  96. enable/disable the cache. Again it's a privileged instruction but occasionally 
  97. a user's program may want to disable the cache if it's executing self-modifying 
  98. code in tight loops, though my own experiments suggest that the pipeline is 
  99. probable more to blame than the cache. In any case, despite rumors to the 
  100. contrary, 95% of self modifying code WILL run correctly on the 280. One very 
  101. special case where the cache must be off is where code is loaded via DMA and 
  102. then immediately executed - the cache will still contain the old code. But no 
  103. USER program is likely to do that sort of stuff - much more likely in a BIOS or 
  104. IOP - which would be in system mode anyway.
  105.  
  106.  
  107.   So these are the ideas I currently have for the 280 system. Please let me 
  108. know what you think - any suggestions for improvements - etc. Please keep it 
  109. reasonable - I know you'd all like 100MHz systems with 16Mb memory, 1GB optical 
  110. disks and 4096x3072 pixel realtime color graphics, but it would be so 
  111. preposterously expensive that the customer base would be zilch. This system has 
  112. to be cost effective compared to an AT - thats the reason for using cheap AT
  113. clone parts in it to start with. And don't destroy its compatibility - I see no 
  114. reason we can't have a system that concedes nothing to IBM, Apple, Atari and 
  115. Commodore in up-to-the-minute features yet will still run all our old favorite 
  116. Z80 programs - even faster than before.
  117.  
  118.   I can be regularly contacted on Canada Remote Systems BBS 416-232-0442. Less
  119.  regularly on Znode Central, ICBBS Ottawa or Holly Park RCPM. Or you can 
  120. phone me at home (416-299-0502) after 6pm EST or at work (416-439-4273) 9am-5pm 
  121. EST Mon-Fri on voice. Or even FAX (416-439-3875). Or write to: 1131 Sandhurst
  122. Circle #111, Scarborough, Ontario M1V1V5, Canada.
  123.  
  124.      Greg Trice, Dec 1987.
  125.