[BBC-Micro] 6502 second processor ROM disassembly
jgh at mdfs.net
Tue May 6 20:21:41 BST 2014
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
> JGH's disassembly of 1.10 and a random copy of 1.10 I managed to find
> the web, the tube OS expects 24 bytes to be returned. Which is great
> 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
> 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
> 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 at mdfs.net - mdfs.net
More information about the bbc-micro