Date : Wed, 19 Oct 1994 08:47:13 +0100 (WET)
From : Peter Coghlan <PETER@...>
Subject: Re: BBC Emulators
On Sat, 15 Oct 1994 17:08:07 +0100 (BST) you said:
>
>Crikey... it sounds like the classic program which has been added to and
>altered over a period of time! ;-)
>
Strangely enough, no. That part of the code has been like that from day one.
The operating system requires that programs do terminal i/o in block mode
EBCDIC so I implemented the buffer and translate scheme as a get-me-off-the-
ground scheme so that I could see some output to see if things were working. I
expected it to behave atrociously and that it would be a very temporary
arrangement. However it behaved quite reasonably under most conditions so I
left it alone to concentrate on other more urgent needs such as the filing
system. Now that I am moving it to an ASCII system which is capable of
character mode terminal i/o, things should get a lot nicer. If I get really
ambitious I might be able to implement the screen as a window under VWS (a
rather old VAX windows system). Unfortunately there is a lot of work to do to
convert the filing system stuff.
>> it but it is perfect for holding the BBC file attributes - Load address etc.
>
>Good idea; I was chatting with someone the other day about fitting them
>into the PC time/date fields.
>
Are there any unused bytes in dos file directory entries? It seems a pity to
mess up the time and date fields (Well, I always missed not having them on the
beeb). I suppose there are a few more kludgey ways - you could include a header
in the top of the file (My friend's system uses this one), or have a second one
line file with a different extention hold the info, or you could have a single
dos file wich contains the attributes of all files to be used with the BBC
system. The BBC filing system could then read and update this file when files
are opened/created/closed and if the file was in text form, entries could be
added with an editor when you need to import files created by dos.
>
>I did used to implement OSWRCH, but now the O/S does its own screen
>writes. I don't trap screenwrites; I just update the whole thing now and
>again. It takes about 1/25th second to update the screen, and I think I
>might actually have found a quicker way with lookkup tables and things.
>
Are you using the BBC OS code to update the BBC screen memory and then
copying this out to the screen every now and then? How about if you trap
accesses to the screen memory so that they set flags noting which part of
the screen has changed so you don't have to update the whole thing. For example
if you divide the screen into 256 byte blocks, you could use the high byte of
the screen address being written as an index into an array of flag bytes.
Then, when it comes to update time you run through the flags and only update
the required parts of the screen. Of course it would be slower if the whole
screen had changed but it ought be quicker on average. (Mind you, trapping
all memory writes to check for screen addresses might slow things down a lot
too.)
Is the eventual aim to be able to use all of the native BBC OS code?
(Btw, I have source assembly for OS 1.2 - I wrote something to disassemble it
and insert labels etc and did some hand tidying afterwards such as changing
the labels provided to meaningful names).
>You seem to be one of those people who are as lucky as I am. The best
>blunder like that I heard recently happened to a friend of mine. He FTPed
>the whole of Linux (about 60 disks) and then realised that there was a
>bug in the ftp program that didn't write the last 512 bytes of a file
>saved on floppy.
That reminds me of the one that I managed when trying to rescue a BBC floppy
with a bad sector. It was in the middle of a large basic program and I had
other versions so it would be easy to fix if I could recover the chunks of
program on either side. Rewriting the block with a disk sector editor did not
help. *LOAD got me the first part of the program so I thought I'll cobble
together a program calling osword 7f to retrieve the rest. I wrote most of
it from memory but couldn't remember the value of the read sector code. So
I rummaged in the advanced disk user guide or something and found an example
based on reading multiple sectors. Without checking the context, I scanned
the example quickly for the byte in question and plugged it into the program.
I spent ages trying to find why the program was not updating the buffer from
the disk yet not returning an error either. When I checked the example I'd
used more carefully, I found that the first part wrote out some stuff to disk
so that it could be read back by the second part.... If only I'd turned the
page.