geoff@burl.UUCP (geoff) (06/11/85)
References: I have a set of print routines for the apple IIe which write directly to the display page (both 40 and 80 column pages). I have a lot of trouble with dos getting lost and having to resync the head. While my routines work ok (they are part of an editor) and dos works fine (files are read and written without errors), I would like to eliminate the resync clatter. I understand that dos (3.3) keeps some of its variables in the display pages in the left-over space between the visible lines, and I suppose I am trashing at least one of them. The problem usually happens on long (200-400 line) files, and is decidedly more prevalent on writing files than reading them. However, sometimes even very long files are written without problems, and sometimes even very short files have problems. I am using the Manx open, read, and write routines, but I am sure their editor uses them and it never screws dos up. A very common place to get lost is between opening and writing the files. Does anyone out there have any ideas about specific places to look? I don't have an assembly language debugger (all of the display routines are in assembly language) so debugging is more by inference than a step-by-step process. Again, the display works *perfectly* (so far as I can see, anyway). It doesn't lose characters, so I don't see how it could be writing them in non-visible (i.e., dos) locations. I don't know of anything else that could be causing the problems. ??help?? geoff sherwood
zben@umd5.UUCP (06/12/85)
Well, this has been posted before, and I'm *sure* it will be posted again.
Nevertheless, here's my stab at it.
The display uses only *SOME* of the memory assigned to the hardware display.
The few bytes that it does *NOT* use are assigned to the peripheral cards for
use as RAM memory. Some of the peripheral drivers (e.g. the disk driver)
saves *state information* in these locations, and if you blow away these
bytes you will confuse the driver, causing the problem you describe.
The relevant documentation can be found on page 125 of the Apple ][e
reference manual, the section entitled: "Peripheral-card RAM Space".
My boss has the office ][+ and all its books at home right now, but this
information *IS* in the ][+ reference manual.
To avoid blowing away there RAM locations, you will have to stop saveing and
restoring display memory with a block IO from 400 to 7FF or 800 to BFF and
instead do a bunch of little IOs. First cut is to do 24 of them:
400-427
480-4A7
500-527
580-5A7
600-627
680-6A7
700-727
780-7A7
428-44F
4A8-4CF
528-54F
5A8-5CF
628-64F
6A8-6CF
728-74F
7A8-7CF
450-477
4D0-4F7
550-577
5D0-5F7
650-677
6D0-6F7
750-777
7D0-7F7
But, note that *the order doesn't matter*, as long as you read them in with
the same order you wrote them out! Some of the ranges are contiguous, and
thus the task can be simplified to 8 IO requests:
400-477 (rows 1, 9, 17)
480-4F7 (rows 2, 10, 18)
500-577 (rows 3, 11, 19)
580-5F7 (rows 4, 12, 20)
600-677 (rows 5, 13, 21)
680-6F7 (rows 6, 14, 22)
700-777 (rows 7, 15, 23)
780-7F7 (rows 8, 16, 24)
If you compare this against the table on page 125, you will see that this
IO sequence avoids the Peripheral card RAM locations...
--
Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA