Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!actrix!ewen From: ewen@actrix.gen.nz (Ewen McNeill) Newsgroups: comp.os.cpm Subject: Re: Flame returned (was Re: VT100KAY.LBR problems) Keywords: Amstrad, CP/M+, UNCR, UNCRLZH, bug, BIOS Message-ID: <1991Mar21.212330.21080@actrix.gen.nz> Date: 21 Mar 91 21:23:30 GMT References: <1991Mar19.054726.11637@actrix.gen.nz> Organization: Actrix Information Exchange Lines: 30 Comment-To: ianj@ijpc.UUCP [I would send this by Email, but this site (way off in NZ), doesn't know about the UUCP psuedo-domain, and just bounces the stuff. Sorry, everyone else.] In article ianj@ijpc.UUCP (Ian Justman) writes: > [In reply to a flame rebuttal from ewen@actrix.gen.nz (Ewen McNeill)] > My deepest apologies. I guess I assumed that all BIOSes were > pretty much well-behaved and it seems to be restricted to some > BIOSes. Also, it probably has something to do with the fact that > those computers are running CP/M Plus, which I've heard can be > flakey at times. That's why I stick with my CP/M 2.2 stuff > (highly uprated w/ZCPR33 and stuff like that...) Your apology is accecpted. I have heard a fairly large number of BIOSes which have problems with various things - most written for Z80 machines in the days when 8080 code was the most common, so they assumed that they had the extra registers to themselves. This is no longer true. I doubt that the fact they are running CP/M+ has anything to do with it. CP/M+ seems okay to me, most of the time. Occassionaly it fails to relog in a disk, but that is only because of the way it detects a new disk (directory checksumming). No where near as much hassle as logging in disks under 2.2! The trouble with the Amstrad implementation of CP/M 2.2 is that they used a graphics screen (all the machine has - bit map 16K), which steals most of the useful memory. There is only about 42K TPA - hardly enough to do anything. -- Ewen McNeill. Email: ewen@actrix.gen.nz