Date   : Tue, 06 May 2014 20:21:41 +0100
From   : jgh@... (J.G.Harston)
Subject: 6502 second processor ROM disassembly

Steven Flintham wrote:
> What has been puzzling me is how OSWORD 14 (read CMOS time) with
> function 0 (read clock value as string) works across the tube. The
> returned data is 24 bytes. Looking at the OSWORD control block length in
> JGH's disassembly of 1.10 and a random copy of 1.10 I managed to find on
> the web, the tube OS expects 24 bytes to be returned. Which is great and
> makes sense and doesn't confuse me at all.

I was going to say that the Tube Client 1.00 was originally used on the 
external CoPro with the BBC before OSWORD 14 had been implemented, but 
as you say, it does read 24 bytes to read the full RTC string, so 
somebody at Acorn must have spotted something.

The three sole differences between v1.00 (in the external 6502 second 
processor) and v1.10 (in the internal "6502 CoProcessor") is:
1) The title string
2) The help string
3) OSWORD 5 sends a 4-byte address instead of a 2-byte address to read 
I/O memory, so it can read (potentially) the full range of I/O memory, 
eg &FFFExxxx for shadow screen memory, etc.

The Z80 Tube Client erroneously only read 16 bytes for OSWORD 14 and I 
had to include a patch in the ROMable Z80 BASIC to ensure it read the 
full RTC string.

> Except... looking at app note 4, I found two copies.
...
> Is this just a case of app note 4 always having been wrong? That would
> make sense and would explain everything.

A lot of Acorn documentation conflicted with actual implementation. The 
version on my site is a version I had when I was working at AFE(*) in 
1992-3, which somebody had updated, possibly in response to a query from 
me in about July 1992. Including that one I've seen four different 
versions of AppNote 4.

http://mdfs.net/Software/Tube/DocErrors lists some documentation and 
implementation errors I've come across.

> Was there an upgrade to the tube OS needed to make it work with the
> additional OSWORDs in OS 3.20?

No. However, the usual second processor used on a Master was the 
internal CoPro, but people did also use the external CoPro on the 
Master, we did back at school.

> Does the host patch the tube ROM in any way?

No. The host is completely and utterly agnostic as to what is on the 
other side of the Tube. Application software may sometimes test what's 
on the other side of the Tube. For instance, a Z80 language in a ROM may 
probe the second processor to see if it's a Z80 and disable itself if 
the CoPro isn't a Z80, and disable any non-Z80 languages if it the CoPro 
is a Z80. A typical way of doing this is to read the data at &0000FFF4 
or &0000FFF7 and see if it is a jump opcode for the processor you are 
expecting.

> Or was it all thought out in advance and worked perfectly,

Somebody at Acorn must have said something like: ey up, how many bytes 
should OSWORD 14 and 15 transfer? Should they just transfer 16 bytes 
like OSWORDs 21 to 127, or should have a think about what 14 and 15 
should transfer. Hmm. Lets make OSWORD 14 read 24 bytes and OSWORD 15 
send 32 bytes, that should do for whatever we end up putting there.

Or maybe somebody at Acorn did actually say: hold on, a RTC string 
would be 24 characters, let's pencil in OSWORD 14 and 15 for reading and 
writing a RTC.

(*)AFE - Acorn Far East in Hong Kong. I worked there from 1992 to 1993 
and supplied some bugfixes and updates back to Acorn UK while there. I 
did have an Acorn mug from there. Since then taken over by Reuters and 
metamorphed into a generic financial services market trading terminal 
support company: www.afe-solutions.com

-- 
J.G.Harston - jgh@...      - mdfs.net