CBFalconer wrote:
To start with, coordinates are two-dimensional. Of course, you could compute a sequential offset yourself, but this doesn't exactly sound like a high-level language to me.
Just as an example, one of my systems in bygone years did screen updates. The file was defined as a FILE OF RECORD .... where the record included a 24x80 array of char and a "cursorlocation" x y pair. The main program could examine and alter these fields in f^ as it desired, and then execute "put(f)", which did the actual transmission.
There was then no difference in the code running an external terminal on a serial line, and that running a memory mapped display. There was a great difference in the drivers, which were mapped into the actual file system via a set of tables for such things as open, close, put, get, status.
Close and status (what does this do?) are non-standard, BTW ...
As I said, this sounds rather inefficient to me. The driver would have to partly undo your work (you want to write a string, you map it to character writes, possibly in different lines, perhaps interspersed with attributes, then the driver recoginizes sequential writes, with the same attributes if applicable, and turns it back into a sequential string output.
Another factor is that non-memory mapped I/O behaves more nicely if buffered. Some things are easier to program when you can overwrite characters with the user only seeing the end result (e.g., clearing a window, drawing a border, printing a title over the border ...) EP has a record-granularity `Update' routine, but nothing on a bigger scale.
The actual operation could be asynchronous, and handled by interrupts in a serial drive, none of which complication was needed in a local memory driver. That meant a difference in throughput to the actual program, but the apparent speed was virtually unaffected.
If significant variations in the end device existed, they could be reported by invariant fields in f^, such as MAXX and MAXY.
So every program would first have to read, and possibly store these values (unless it's hard-coded to 24x80 which I hope isn't the case), and then do manual offset computations? Sorry, but that's what I'd expect to do in assembler code, not even in C, let alone Pascal ...
After a put to the serial device completion could be detected by examining a 'busy' field.
Which can require a busy-waiting loop if you want to wait for it. In some situations one needs something more advanced, such as select/poll in Unix. Unfortunately, standard Pascal I/O doesn't provide any means for this, so we need some extensions.
Etc. The details are unimportant, the point is that all this can be mapped into the standard Pascal file system.
Almost anything can be mapped to anything (Turing machines etc.), but I'm not convinced it's very useful ...
Frank