Advanced User Guide (AUG) [Remastered PDF]

[SamSkivington]

I'm now more confused than when I discovered this anomaly.

On the Model B with OS1.20 in front of me, &F0 and &F1 contain the ZP ROMSEL copy's value and 0 respectively. Output from your ROM code:

*FX114 20 30
<72><0B><00>

I'll validate the OS ROM (looks like an original) against a known good one and report back.

[philb]

The MOS disassembly from http://mdfs.net/Docs/Comp/BBC/OS1-20/E6B0 does seem pretty clear:

Code: Select all

**************************************************************************
**************************************************************************
**                                                                      **
**      OSBYTE  DEFAULT ENTRY POINT                                     **
**                                                                      **
**      pointed to by default BYTEV                                     **
**                                                                      **
**************************************************************************
**************************************************************************

E772	PHA         ;save A
E773	PHP         ;save Processor flags
E774	SEI         ;disable interrupts
E775	STA &EF     ;store A,X,Y in zero page
E777	STX &F0     ;
E779	STY &F1     ;

[philb]

On the Model B with OS1.20 in front of me, &F0 and &F1 contain the ZP ROMSEL copy's value and 0 respectively.

Obvious question I guess, but do you have any other ROMs installed that might possibly be corrupting the zero page locations in question?

[SamSkivington]

Yep. That was it - another experimental ROM in higher priority is making a keyboard scan OSBYTE call regardless of service call no. which naturally overwrites those addresses.

Good shout @philb

Thanks and apologies!

[6502]

The book appears to include two different types of OSBYTE &81. Pg. 152 & Pg. 153

[SKS1]

As you would hope it did! "If called with Y=&FF and X=0 this call returns the machine type (see previous page)."

[jgharston]

Some of the low numbered OSBYTEs state Y=0 on entry. That's incorrect, all low OSBYTEs are Y=ignored on entry, and the OSBYTE dispatcher explicitly sets Y=0 within the dispatch code.

This gives rise to confusion with OSBYTE 3 implying you can set Y to a bitmask to modify selected bits of the output stream. That's incorrect, *FX3,n,anything becomes internally *FX 236,n,0 /always/.

Also, as OSBYTE &81 (INKEY) lists post-OS-1 machines, OSBYTE 0 should also.

Also, OSBYTE &81, all Compacts return &F5, not just MOS 5.10 - MOS 5.00, MOS 5.10, MOS 5.11, most likely any other MOS 5.xx. (Hmm, must check the Olivetti MOS)

[6502]

The book appears to include two different types of OSBYTE &81. Pg. 152 & Pg. 153

As you would hope it did! "If called with Y=&FF and X=0 this call returns the machine type (see previous page)."

Okay, thank you for clearing that up for me.

[tom_seddon]

Looks like the screen scrolling wraparound table on page 419 is wrong? - the 10 KB and 20 KB values are swapped. See the way MOS 1.20 programs it (https://tobylobster.github.io/mos/mos/S-s4.html#SP14) and the working lookup table that b2 uses (https://github.com/tom-seddon/b2/blob/a ... ro.cpp#L86).

I think the table should be:

20 KB: B5 = 1 B4 = 0
16 KB: B5 = 0 B4 = 0
10 KB: B5 = 1 B4 = 1
8 KB: B5 = 0 B4 = 1

--Tom

[mygrandmawheels]

I think you're right, at least for the 20Kb screen; I just tried with somthing like

Code: Select all

LDX #%00001111              ;set System VIA PORT B to output on bits 0-3; input on bits 4-7
STX sysVIADDRB              ;.systemVIADataDirectionRegisterB

; set mode 2 (20 kb screen)
LDA #22:JSR oswrch
LDA #2:JSR oswrch

; set the "wrap around"
SEI
LDA #4  
STA &FE40           ; write system VIA register B
LDA #13
STA &FE40           ; write system VIA register B
CLI

; set the screen origin at &3000 (20Kb screen)
LDA #12 : STA &FE00 : LDA #&30 : STA &FE01 ; MSB
LDA #13 : STA &FE00 : LDA #&00 : STA &FE01 ; LSB

so i set B5 = 1 B4 = 0, and it's the only way the screen doesn't show artifacts.

Really strange, anyway, that there's such a mistake. I'm not a guru of the bbc, so I doubt of myself, but my test seems correct.

[hoglet]

I think the table should be:

20 KB: B5 = 1 B4 = 0
16 KB: B5 = 0 B4 = 0
10 KB: B5 = 1 B4 = 1
8 KB: B5 = 0 B4 = 1

I've also just worked through the logic and I agree with this...

This was my workings:

Code: Select all

---- Inputs -------   --- NAND Gates ---    ---- Adder ----   Address
MA12 = 0 C1 C0 = XX : X4=1 X3=1 X2=1 X1=1 : 1111 + 1 = 0000 : unchanged
MA12 = 1 C1 C0 = 10 : X4=0 X3=1 X2=0 X1=1 : 0101 + 1 = 0110 : +&3000
MA12 = 1 C1 C0 = 00 : X4=0 X3=1 X2=1 X1=1 : 0111 + 1 = 1000 : +&4000
MA12 = 1 C1 C0 = 11 : X4=1 X3=0 X2=1 X1=0 : 1010 + 1 = 1011 : +&5800
MA12 = 1 C1 C0 = 01 : X4=1 X3=0 X2=1 X1=1 : 1011 + 1 = 1100 : +&6000

[Rich Talbot-Watkins]

Yes, I remember the screen wraparound thing being in error from back in the day (and always having to set it by trial-and-error)! Along with the internal key codes for 9 and I being transposed. I was never aware of any other errors in the AUG though, and I far prefer the layout to the NAUG which I can never find my way around.

[tricky]

Same here Rich, but I have vague revolutions of another typo, but if have to find my copy to be sure.

[KenLowe]

If this is still getting maintained, I think there's an error in section 25.3:

Code: Select all

25.3 The Econet station ID register – Sheila &20 Read only

I think this should read:

Code: Select all

25.3 The Econet station ID register – Sheila &18 Read only

https://mdfs.net/Docs/Comp/BBC/Hardware/SHEILAddrs

[dv8]

If this is still getting maintained, I think there's an error in section 25.3

I am still maintaining these books, I just haven't had any time over the past year to dedicate to retro projects.

I'm currently catching up with all the changes posted to the various threads and will be issuing updated PDFs later this month.

Thanks for your correction, and to Tom, JGH and others for their contributions.

[dv8]

The PDF in the opening post has been updated to revision 6.

Changes since revision 5 (January 2021):

• p116 (118) OSBYTE &00 : added other supported OS versions from NAUG
• p117-130 (119-132) OSBYTE &01-&0E : removed Y=0 from entry parameters
• p119 (121) OSBYTE &03 2nd last para : clarified use of OSBYTE &EC with Y as bit-mask
• p123 (125) OSBYTE &07 : 'baud transmit' should be 'baud receive'
• p152 (154) OSBYTE &81 (INKEY -256) : added other MOS 5.xx versions for X=&F5
• p260 (262) 10.7 NETV 0,1,2,3,5 : added hyperlink to user printer driver
• p262 (264) 10.9 KEYV C=1,V=0 : removed redundant 'on exit'
• p419 (421) 23.2 Addressable latch B4,B5 : 20K screen should be B5=1,B4=0 ; 10K should be B5=1,B4=1
• p428 (430) 25.3 Econet station id : Sheila &20 should be Sheila &18

[dp11]

Typo Page 37 section 5.6
The example should be

LDA #&40 \ load accumulator with &40
STA &1900 \ store low byte of indirection
LDA #&28 \ load accumulator with &28
STA &1901 \ store high byte of indirection
JMP (&1900) \ goto address in &1900 and &1901

[Coeus]

Another error, I'm afraid: Events, page 290, 12.8 ADC Conversion complete. The text states that the channel is contained in the Y register but it is actually in the X register.

[MarcRetro]

I found an error in the June 2022 release.
The picture on page 446 shows '+5V' inside the block but it needs to be 'CLR'

See the picture from the scan.

[dv8]

The PDF in the opening post has been updated to revision 7.

Changes since revision 6 (June 2022):

• p18 (20) 2.14 *OPT 3,n : 'relevent' should be 'relevant'
• p37 (39) 5.6 example JMP (&1900) : 'goto address in 61900' should be &1900
• p171 (173) OSBYTE &98 'After using this call...' : 'instructions' should be 'instruction'
• p257 (259) 10.2 BRKV b) : 'ie' should be 'i.e.'
• p276 (278) 11.4 Page three &34C : 'ie' should be 'i.e.'
• p281 (283) 11.9 Page eleven &B00 : end of string calculation &B00+?(&B01+n) changed to '&B00+o, where o is the lowest start offset greater than ?(&B00+n)'
• p290 (292) 12.8 ADC conversion complete : channel number returned in X not Y
• p325 (327) 15.1.1 service call &FE : On entry, Y=&FF if tube present, Y=0 if absent.
• p338 (340) 16.3 OSARGS A=&FF : 'ie' should be 'i.e.'
• p346 (348) 16.10 CFS OSFSC : 'ie' should be 'i.e.'
• p368 (370) 18.9.1 Light pens : 'ie' should be 'i.e.'
• p382 (384) 19.2.3 Physical colour field : 'ie' should be 'i.e.'
• p385 (387) 20 SHEILA &08-&1F : 'ie' should be 'i.e.'
• p388 (390) 20.6.1 CR0/CR1 : 'ie' should be 'i.e.'
• p425 (427) 24.2 Port B : 'ie' should be 'i.e.'
• p446 (448) Figure 28.4 'Clean up' circuit 2 : +5V should be CLR
• p447 (449) 28.6.3 Connection : 'ie' should be 'i.e.'
• p495 (497) Glossary, Open Collector : 'ie' should be 'i.e.'

[tom_seddon]

p154, OSBYTE &82, is described as "On exit, X and Y contain the padding address (X–high, Y–low)" - surely Y=high, X=low, as per every other OS call? Indeed, the original B user guide says Y=MSB and X=LSB (see p 431), same as the B+ guide (p 415) and the NAUG (p 257).

Interestingly, the Master 128 manual says X=MSB Y=LSB (see p D.2-40) - ugh, I hate it when this happens. Normally the code would reveal all, but of course in practice X and Y have the same value on exit. So perhaps we'll never know the truth.

--Tom

[sweh]

I would tend to X=low Y=high because that's how the other OSBYTE calls (eg 131, read OSHWM) work, and it's how you set things up to point to parameter blocks for OSWORD calls

[dv8]

Interestingly, the Master 128 manual says X=MSB Y=LSB (see p D.2-40) - ugh, I hate it when this happens. Normally the code would reveal all, but of course in practice X and Y have the same value on exit. So perhaps we'll never know the truth.

Looking at BASIC's use of OSBYTE &82, it appears that X=LSB, Y=MSB as expected:

Code: Select all

&BEE7 A9 82     LDA #&82
&BEE9 20 F4 FF  JSR &FFF4
&BEEC 86 3B     STX &3B
&BEEE 84 3C     STY &3C

I'll get this corrected in the AUG and MRef1.

[BeebMaster]

I wonder if there's a mistake at the bottom of page 340 (replicated from the original):

OSGBPB 1 is "write bytes to file", using the pointer location specified in the OSGBPB block and ignoring the current pointer (ie. the value of PTR#)
OSGBPB 2 is "append bytes to file", using the current pointer location (PTR#) and ignoring any location specified in the OSGBPB block

So the AUG reads to me like they've got 1 & 2 the wrong way round. Or at least, it's sufficiently unclear as to the meaning to need re-wording maybe to explicitly say the call uses or ignores the pointer location in the command block.

[sweh]

It sounds like you and the book are saying the same thing.

1 = "new PTR defined in control block; write there". The key is "new sequential pointer", meaning the value of PTR is changed to be that in the control block.

2 = "ignore any PTR in control block; write to current PTR". The key is "ignore" meaning any value of PTR in the control block is ignored. This is only an "append" if PTR == EXT.