JGH's Docs.Comp.BBC.MemAddrs

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
tom_seddon
Posts: 226
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

JGH's Docs.Comp.BBC.MemAddrs

Post by tom_seddon » Fri Jan 19, 2018 11:37 pm

I suppose this is a question for JGH, but maybe I'm just being dense and anybody could answer :)

It's regarding http://mdfs.net/Docs/Comp/BBC/MemAddrs. What's bit 20 of the address for in this scheme?

In the summary table towards the end, there are rows for addresses of the form $FFXxxxxx where the X digit is even, and a row for when the X digit is $F, but no rows for any of the other odd digits.

Is bit 20 actually supposed to be how you distinguish the $FFFxxxxx cases, meaning $FFFxxxxx and $FFDxxxxx map to the same areas? Or does the table mean exactly what it says, and that any other time bit 20 is set, the result is undefined or something?

Additionally: the heading last column in that summary table reads "Bitmap of address b23-b21+4". What does "+4" refer to?

(I'm intending to adopt this addressing scheme for some of the debugging functionality in my emulator. Seems no point my making a new scheme when there's one already.)

--Tom

User avatar
jgharston
Posts: 3296
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: JGH's Docs.Comp.BBC.MemAddrs

Post by jgharston » Sat Jan 20, 2018 1:47 am

I was going to post: is the Wiki article clearer, but there's actually nothing much there!
tom_seddon wrote:It's regarding http://mdfs.net/Docs/Comp/BBC/MemAddrs. What's bit 20 of the address for in this scheme?
Nothing, just like "what's bit 4 in SHELA I/O addresses?".
tom_seddon wrote:In the summary table towards the end, there are rows for addresses of the form $FFXxxxxx where the X digit is even, and a row for when the X digit is $F, but no rows for any of the other odd digits.
Yes, ignore bit 20. That's what happens when you divide 16 by 8. Just like SHEILA is &00/&20/&40/&60/etc, and there's no way of writing "&abcdxxxx" where the top x overlaps into the d, so the convention is that a list that goes, eg, &4x, &6x is that it is saying %010xxxxx, %011xxxxx. Just as, you don't write:
&FE4x System VIA
&FE5x reflection of System VIA
&FE6x User VIA
&FE7x reflection of User VIA
you just write:
&FE4x System VIA
&FE6x User VIA
tom_seddon wrote:Is bit 20 actually supposed to be how you distinguish the $FFFxxxxx cases, meaning $FFFxxxxx and $FFDxxxxx map to the same areas? Or does the table mean exactly what it says, and that any other time bit 20 is set, the result is undefined or something?
Just like in SHEILA addresses which are &00/&20/&40/&60/etc, extra bits are used to split up one area further, just like in SHEILA &00 is further split into &00/&08/&10/&18.

Is &FFD there a typo for &FFFD ? &FFFFxxxx and &FFFDxxxx don't map to the same memory, unless there is no shadow screen present.

For memory <&8000, where shadow screen memory is present
&FFFFxxxx is the program memory
&FFFExxxx is whatever memory is currently being displayed, which could be the program memory (eg MODE 0) or the shadow memory (eg MODE &80)
&FFFDxxxx is the shadow screen memory regardless of if it is being displayed or not

See also Paging_in_video_memory which is how you should interpret a &FFFxxxxx address to select memory in the I/O processor below &8000. Note that there is an edge case that it is difficult to detect what &FFFExxxx means, and that is on the Aries when you are using a 20K screen mode with only 16K of shadow memory.
tom_seddon wrote:Additionally: the heading last column in that summary table reads "Bitmap of address b23-b21+4". What does "+4" refer to?
A clumsy way of saying: take b23-b21 and add four to it, and it becomes a bitmap. I added that note when I suddenly noticed the pattern and used it to optimise some coding.

Maybe the Micro User article might be a bit clearer. That's slightly rewritten from the original as I looked through the code some years ago when I needed to correctly implement full 32-bit addressing, and realised the lovely comment-free published version it had coding errors in, plus I had no idea any more what it was doing.

Would it be clearer to expand it to:

Code: Select all

  Address                   &0000-&7FFF   &8000-&BFFF   &C000-&FBFF  &FC00-&FDFF
 <&FFxxxxxx   lang memory   lang memory   lang memory  lang memory
  &FF0rxxxx                 main memory   SROM/SRAM r   FS RAM         MOS ROM  
  &FF1rxxxx   reflection of main memory   SROM/SRAM r   FS RAM         MOS ROM       
  &FF2rxxxx                 main memory   SROM/SRAM r   FS RAM           I/O         
  &FF3rxxxx   reflection of main memory   SROM/SRAM r   FS RAM           I/O         
  &FF4rxxxx                 main memory   VDU RAM       MOS ROM        MOS ROM       
  &FF5rxxxx   reflection of main memory   VDU RAM       MOS ROM        MOS ROM       
  &FF6rxxxx                 main memory   VDU RAM       MOS ROM          I/O         
  &FF7rxxxx   reflection of main memory   VDU RAM       MOS ROM          I/O         
  &FF8rxxxx                 main memory   VDU RAM       FS RAM         MOS ROM       
  &FF9rxxxx   reflection of main memory   VDU RAM       FS RAM         MOS ROM       
  &FFArxxxx                 main memory   VDU RAM       FS RAM           I/O         
  &FFBrxxxx   reflection of main memory   VDU RAM       FS RAM           I/O         
  &FFCrxxxx                 main memory   SROM/SRAM r   MOS ROM        MOS ROM       
  &FFDrxxxx   reflection of main memory   SROM/SRAM r   MOS ROM        MOS ROM       
  &FFErxxxx                 main memory   SROM/SRAM r   MOS ROM          I/O         
  
  &FFF0xxxx   main memory   SROM/SRAM 0   MOS ROM          I/O         
  &FFF1xxxx   main memory   SROM/SRAM 1   MOS ROM          I/O         
  &FFF2xxxx   main memory   SROM/SRAM 2   MOS ROM          I/O         
  &FFF3xxxx   main memory   SROM/SRAM 3   MOS ROM          I/O         
  &FFF4xxxx   main memory   SROM/SRAM 4   MOS ROM          I/O         
  &FFF5xxxx   main memory   SROM/SRAM 5   MOS ROM          I/O         
  &FFF6xxxx   main memory   SROM/SRAM 6   MOS ROM          I/O         
  &FFF7xxxx   main memory   SROM/SRAM 7   MOS ROM          I/O         
  &FFF8xxxx   main memory   SROM/SRAM 8   MOS ROM          I/O         
  &FFF9xxxx   main memory   SROM/SRAM 9   MOS ROM          I/O         
  &FFFAxxxx   main memory   SROM/SRAM 10  MOS ROM          I/O         
  &FFFBxxxx   main memory   SROM/SRAM 11  MOS ROM          I/O         
  &FFFCxxxx   main memory   SROM/SRAM 12  MOS ROM          I/O         
  &FFFDxxxx   shadow mem    SROM/SRAM 13  MOS ROM          I/O         
  &FFFExxxx   display mem   SROM/SRAM 14  MOS ROM          I/O         
  &FFFFxxxx   main memory   SROM/SRAM 15  MOS ROM          I/O
Most of that is just relections just as you can see the User VIA at &FE7x, but should use &FE6x, you can see sideways ROM 4 by paging in bank &34, but you should page in bank &04.

The main thing is that this is just a consequence of coding to get:
{*} FFFF0000 to FFFFFFFF - main memory and MOS ROM
{*} FFFE3000 to FFFE7FFF - the currently displayed screen
{*} FFFD3000 to FFFD7FFF - the shadow screen memory
{*} FFFr8000 to FFFrBFFF - sideways ROM/RAM number r
{*} FF8x8000 to FF8xAFFF - the spare sideways RAM on the BBC B+ (with ROM x visible at &B000-&BFFF)
{*} FF8x8000 to FF8x8FFF - the VDU workspace RAM on the Master (with ROM x visible at &9000-&BFFF)
{*} FF8xC000 to FF8xDFFF - the filing system RAM on the Master
{*} FFCxFC00 to FFCxFEFF - the hidden MOS ROM on the Master

Note that for most cases you don't have to check for boundary cases, you just select the mapping and the hardware does it for you. For instance, you don't check what address withina sideways ROM you want, just page in &00+x or &80+x and that bit which is banks RAM will be seen as banked RAM, and that bit that isn't banked RAM will be seen as the sideways ROM. The hardware does the "up to &AFFF" checking.

MDump105.src demonstrates mapping the required memory in for the specified addresses.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

tom_seddon
Posts: 226
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: JGH's Docs.Comp.BBC.MemAddrs

Post by tom_seddon » Sat Jan 20, 2018 3:12 am

OK, thanks. It makes a bit more sense now.

I'm still not sure how you'd unambiguously access non-shadow memory on the Master, though. It looks like $FFFE3000-$FFFE7FFF lets you access what's displayed, either shadow or main. $FFFD3000-$FFFE7FFFF lets you access the shadow RAM. I'm not sure what $FFFx3000-$FFFx7FFF is for, in practice, when x<13... but that's easy to say with nearly 30 years of post-1989 hindsight.

But $FFFF3000-$FFFF7FFF presumably must access whatever's paged in for CPU accesss. The scheme looks to be designed to be backwards compatible with the Acorn-style addresses that are used for *LOAD and *SAVE and whatnot. So then what if you explicitly want main RAM rather than shadow RAM?

I want to show these addresses in the memory view and disassembly view, so it's clear exactly which bit of RAM is being referred to. So the distinction between main RAM and shadow RAM is relevant.

2. How does the annoying extra 12K of B+/Master RAM work precisely? The diagram has 8K Private Workspace RAM at $FFF8xC000, and 8K MOS Workspace RAM at $FF8x8000... but that can't be right, as there's only 12K of this stuff! Surely it should be 4K MOS Workspace RAM at $FF8x8000. Then the Spare BBC B+ RAM is 8K at $FF8x9000...$FF8xAFFF.

Either way, does Spare BBC B+ RAM and Private Workspace RAM count as the same thing? Like, can you access the Spare BBC B+ RAM at $FF8xC000, and so on, and can you access the Private Workspace RAM at $FF8xA000, and so on?

--Tom

Post Reply