<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Fri, 23 Jun 2006 12:54:28 +0200 (BST)
From   : Johan Heuseveldt <johan@...>
Subject: Re: Torch Graduate (Was: Re: PEDL Z80 Board)

Hi Jules,

On Thu 22 Jun, Jules Richardson wrote:
> 
> >> Doesn't the Graduate plug into the 1MHz bus?
> > 
> > Spot on - dug the docs out and indeed it does plug into the 1MHz bus. 
> > Why, I'm not sure - I only leafed through the docs but they didn't seem 
> > to say. Maybe Torch intended you to own one of their other copros (Z80 / 
> > 68000) and so they kept the Tube free.
> > 
> > I've got one ex-Torch contact who worked on some of their BBC-based 
> > stuff; I'll ask in case he remembers.
> 
> Here we go:
> 
> Anyway, the way it was told to me was that the Graduate people
> (founded by the man that founded TORCH, Martin Vlieland-Boddy) knew
> Paul (?) Bond, one of the developers of the BBC Micro MOS, and so
> were aware of the special feature in the code. If you assert the
> interrupt line on the 1MHz bus early on in the boot cycle the MOS
> will execute the code in the 256 byte memory mapped window in the
> 1Mhz bus space in the memory map

In the past (many years ago) I've studied the MOS 1.20 code
extensively. I can't remember anything 'odd' that could now
suggest something like above. OTOH, it's just like trying to find
something in a medical/forensic lab: You can only find something
present/absent if you look for it in the first place!

The disassembly is within reach, so I may be tempted! :-)

Most likely it should be found in the RESET code, and not in the INT
code, which is the first snag to watch out for!


> (was it "Shiela" - I can't remember).

Defenitely not:

 'Sheila' or page &FE : internal Memory Mapped I/O
 'Jim'       page &FD : 64 KByte RAM (with paging reg at 'Fred &FF')
 'Fred'      page &FC : external Memory Mapped I/O

Sheila is dedicated to all internal hardware chips.

The AUG on page 437 states:

      The standard use of the one megahertz bus allows up to 64K
      bytes of paged memory to be used as well as 255 direct
      memory mapped devices (plus the paging register). 'FRED' is
      normally assigned as the memory mapped I/O page and 'JIM'
      is normally assigned as the 64K memory expansion page.
      Communication between FRED, JIM and programs should be
      implemented using OSBYTEs &92, &93, &94 and &95.

and at (the bottom of) page 438 (28.3.2 Extended page allocation)

      'Extended pages' &00 - &7F in JIM are reserved for use by
      Acorn. The other pages &80 - &FF are reserved for user
      applications.

When from cold start - or reset - code is supposed to be run
in JIM, then it seems appropiate (to me) to reset the paging
register at &FDFF by the RESET signal. 

Just as Sideways ROM can never change (for obvious reasons) the
ROMSEL register at SHEILA &30, code in whatever JIM page can never
change the JIM-paging-register at 'FRED &FF'.

The concept you're describing is both absolutely new to me, as well
as looking very interesting! Although code can be run from a single
page in JIM, this is the only way to do it from a machine (re)start.

> This could enable the machine to bootstrap itself into the BBC Micro
> memory and take over the machine entirely without the need for a
> sideways ROM to be installed.

I can see that. But only a single page can be used. The page number 
must be unambiguously known, hence a RESET connected latch.

So probably the code does an upload of more code to somewhere in
main RAM from where the actual boot process is started/continued.
A bootstrap of 256 bytes maximum, for that scenario doesn't seem
inpossible to me! :-)
See later...

> I think the principle was that you could sell the device more
> easily, especially to businesses, if you didn't have to open the BBC
> up to do it. Plus, the ability to take over the BBC was important
> given the low level at which it all worked - the BBC became the
> memory mapped screen RAM rather than an actual computer.

Hm, I don't follow you here.
IMO the Beep can't be run from another processor atached to
the 1MHz bus. The principle of a dedicated I/O sytem, just as
with a TUBE connected coproessor, with still its own processor,
still applies here.

But probably I misinterprete you?

> Of course, the down side is that the 1MHz bus wasn't all that quick
> (neither was the Tube in the cosmic scheme of things)
> so performance wasn't all that special.

But the TUBE maintains a 2MHz speed at the Beeb (as the I/O system)
during communications.

What's more, the actual speed of the 1MHz bus is less than 1MHz:
For accurate timing of the 100 Hz clock - and its derivatives - from
the System VIA timer, it is necessary to have a fixed 1MHz clock. On
top of that, there is a (kind of) free running 2MHz processor clock.

There is a relationship between the two, which I would describe as
out of phase. If you look carefully at

  Figure 28.2 - 1MHz bus timing showing page select signals

you can see the actual speed is about 2/3 (0.666) MHz: The pulse width
of the 2MHz signal is stretched to THREE times its nominal value!

> Also, it made writing a DFS to use the Graduate drives (where the BBC was
> left active) much more challenging as all the code had to be fitted into a
> 256 byte page and subroutines were difficult as that would involve paging
> in another 256 byte page to run them.

It would make sense to me that the code in JIM (256 bytes at max)
would first load some code in main RAM. One way to do that is to copy
itself into main RAM, from where the paging register could be accessed
without problems. Then a lot of pages of code can be copied from many JIM
pages to main RAM, setting up the actual BOOT code to start up the whole
system, including (advanced) access to the drives.

> The reason that the machine shipped with a limited DFS was that was
> all we had time to write. An Advanced DFS which did fully work was
> subsequently produced by Tony Sherman, one of the other developers.

Can't comment on that, but surely an 'Advanced DFS which did fully work'
can't be put in 256 bytes, so a concept as described above by me seems
valid, though there must be more than one way to do it I recogn.


greetings,
Johan

-- 
Johan Heuseveldt <johan@...              >
  aka  waarland

  The best place is a Riscy place
 
It is easier to run down a hill than up one.
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>