BBC BASIC on the 65816

[dominicbeesley]

Over the past six or so years I've been trying out various ways of using the 65816 in the Beeb/Master/Electron computers.

I've had some success with going down the TUBE (r) route: viewtopic.php?f=3&t=9975&start=30
And in the main CPU socket: viewtopic.php?f=3&t=7877&start=30 and more successfully viewtopic.php?f=3&t=14125
Also BigEd and Revaldinho have also been working on a 65816 cpu replacement board viewtopic.php?f=3&t=20752

There are no killer apps for the 65816 but an obvious (at least it seemed obvious to me) would be to look at the communicator and try and port BASIC to a Model B/MOS environment as a first start. To that end I've been working through the stuff available on MDFS.net and been disassembling various parts of the Communicator ROMs. The work I'm doing on this is on GitHub at https://github.com/dominicbeesley/CommunicatorBasic100

Getting the Communicator BASIC to run on the older MOS has required a lot of work, first to get a changeable disassembly - there are a lot of code offsets and other stuff that mean a straight disassembly may build and work but will be brittle if changed or any addresses move. What I've got in basic4186new.asm should be a good starting point. Another challenge is that the Communicator has a shared ARITHMETIC module that BASIC calls for some, though not all, of the floating point arithmetic...so I've had to port that too (see arith_new.asm). To get this I used the excellent SourceGen tool and JGH's COPCALLs document and disassemblys as a starting point....plus a few very late nights.

To run on my Blitter card I've also had to implement some OS shims - these are small bits of code that allow the original MOS to handle interrupts, disk I/O, VDU etc. This is slightly complicated by Communicator BASIC running in Native mode - this allows for a large memory foot print but does various things that upset the MOS i.e. running in a different bank, moving the zero-page offset, interrupts call new vectors. The rather bodgy shims are in bas816new_natshims.asm, these are far from complete, for example most of the OSWORD, FILE I/O need still to be implemented. I've been concentrating just to get enough to get JGH's very useful ClockSp to run to get a rough idea of whether BASIC works at all and the relative speed of the BASIC ported from the Communicator.

Here's the rather messy load sequence (I will improve on this but for now it will have to do):

Palaver-sm.jpg

Because the new BASIC runs in "Chip RAM" i.e. outside the normal BBC's memory map the XLOADD1 tool is used to load both the BASIC program and the BASIC interpreter. For now the BASIC interpreter runs from &10000 and PAGE is always at &20600, HIMEM is at &80000 i.e. roughly 382k for programs or variables. Unlike the John Kortink version variable/program space aren't separate.

Here it is running ClockSp on the 65816, in Native Mode - the processor is running at roughly 5.5MHz (more on that later).

BLIT4816_0-s.jpg

It works! But not really as quickly as I'd hoped (more later)

For a comparison here is the same 65816 running some other versions of BASIC (this is a model B but because the processor is a 65816 it can run Master versions of BASIC too):

Montage.png

It is quite clear that Communicator BASIC is not that great - I'll make a post later analysing some of the reasons.

When I started porting this a couple of weeks ago I'd started under a misaprehension that Communicator BASIC would be based upon BASIC 4 but it looks like it's more likely based on BASIC 2 - though I'm not sure. Also, once I'd realised that that was wrong I at least though that it might be quick-ish as my original test on the Communicator in MAME (2.00MHz machine) looked promising:

commy_wrong.png

But looking at the code I couldn't work out why it would be faster than BASIC2 at 2MHz - in fact it should be slower as it does extra work to access the large memory and to call the separate floating point module but there has been little optimization for the 65816. So I checked MAME out and found that TIME was running at half speed - this was boosting the results somewhat! Luckily we have Nigel (pernod) on hand and he's fixed MAME and rerun ClockSp for me:

commy_correct.png

Ah, so as expected it is slow!

Now, I don't want to sound overly critical of Acorn and whoever did the porting, they probably had deadlines and a product to launch - I've been there and something that works now is better than something that is perfect after everyone else has bought something else! However, the Communicator BASIC is really not up to the usual Acorn standards. Firstly there's a lot of dead code, secondly there has been no real attempt to optimize the thing. Secondly the ARITHMETIC module has some bugs that mean it probably never worked correctly on large memory and is full of dead code and some rather silly stuff. For some reason all subroutines are returned from using an RTL opcode, this is unnecessary for internal calls but is made even worse by the fact that they're all called with a PHK:JSR sequence instead of JSL!

Splitting out Arithmetic probably seemed like a good idea at the time but with a bit of optimization it would probably have taken less space to keep the stuff in BASIC for faster calling and keep the module for ViewSheet.

Anyway, that's enough for now. I've now got to watch the rugby then do some archaeology on the BAS4816 (based on BASIC 4.32) that I started on and lost interest in 5 years ago. I got some useful improvements and I think I should be able to knock something together that combines the Communicator's large memory ability with the speed of BASIC 432.

[BigEd]

A very interesting thread! With luck there will be low-hanging fruit and this Basic can get a bit quicker. It seems to me '816 code could be marginally slower (per MHz), if the extra addressing specifiers take too many extra clocks, or marginally faster, if 16 bit operations can be usefully used for pointers, offsets, and 32 bit integer and mantissa calculations. (The 816 has four so-called native modes, and I suspect which one you pick as the base will affect the overall efficiency of the result, because mode-switching is a bit cumbersome.)

But as we will almost always be running the '816 faster than 2MHz, we'll always have a faster, and larger, Basic in any case.

[dominicbeesley]

Thanks Ed

The 8/16 bit switching is a bit cumbersome but worthwhile wherever there maths going on. Most of the time I can to the conclusion that 8 bit mode was the way to go as most parsing is character by character.

I did do a fair bit of 16bitting on the 6x09 port and I'm going my experience there might help plus what I'd already done 5 years ago....trouble is my memory is like a seive so there's lots for me to reacquaint myself with.

First up is probably to ditch the arithmetic module and get the fp stuff from 4.32 in there as it is much improved.

I also did some work on the 6809 to reduce the reliance on having two text pointers on the go in basic and instead use a single processor register that might not be possible on the 816 though as swapping modes loses the top bits of X and Y. The direct page long,Y addressing of the 816 is pretty good and not much slower than the 16bit version

I'll try and get some optimising started tonight

[hoglet]

It's great to see this running.

I've started to work on adding 65816 support to the 6502 Decoder, and it would be great to some more 816 code to test this on. The 816 version BBC Basic would be a great test case.

[ this is going to need a massive refactor - I'm just hacking at the moment to see how far I can get, and to build my understanding of the 816 ]

Any chance you could post a disk image with the BAS816 and RUNBAS816 binaries.

I'm also interested in what filing system you are using (for XLOADD1).

Dave

[dominicbeesley]

Xloadd1 is a hacked version of Jgh'S xload to work with the blitter for a filing system in using hostfs/upursfs but any fs should work

Runbas816 just pokes a JSL &010000 to &2000 and CALLs it from 6502 BASIC

How are you running your 816? The code i have for the native shims are specific to the blitter's memory map and foibles but should be adaptable

I'm cooking dinner at the moment I'll try and get you more stuff later

[dominicbeesley]

PS an 816 decoder will be excellent help. I just need something that can stream to usb at 8ish mhz now

[dominicbeesley]

Here you go Dave, the attached ssd contains all the binaries and the source for XLOADD1 in B.XLOADD1

Do please let me know (PM?) what your setup is for running 816 stuff and I'll fix this up to run on whatever you have if I can.

Below are some of the specifics that will probably need changing: these are preliminary bodges to get something testable most of this stuff is going to get moved to the Blitter support ROM.

The Blitter has a ChipRAM memory map that runs from Physical &000000-$FF0000 which can be accessed via a safe JIM/page wide memory mapped interface from all processors.

In all processor models the normal BBC B SYStem memory map (i.e. all the motherboard resources) appear at $FFxxxx

The 65816 sees a logical memory map which is slightly different. SYS is also mapped at Bank 0 but pages from $00 to $7F can be copied and swapped over to ChipRAM using the BLTURBO command, as can the MOS (this to speed things up, SYStem memory 2MHz, ChipRAM ~8MHz). Normal ROMs always appear in the 65816 memory map at both $00 $8000 and $FF 8000

However, there is another wrinkle, the 65816 wants to see its own native vectors at $00 FFEx but that is taken by the MOS entry points so the Blitter maps vector pulls to Physical ChipRAM at $00 8FEx (currently unused, user ChipRAM stuff starts at $01 0000 and anything below is reserved for system). The processor will only see this during a vector pull, at all other times $00 8FEx would be a regular ROM and $00 FFEx would be the MOS.

The native shims when they get set up copy entry points to ChipRAM $00 8FEx and install the shims themselves at in normal memory at $A00 onwards.

The native shims (wrappers around OSWRCH, OSBYTE, OSWORD etc - unfinished) themselves are nothing special really they need to preserve the 65816 16bit registers, switch to emulation mode and reset the direct page to 0 (the BASIC and Arithmetic modules both have their own direct pages) and do the obverse when returning.

The native mode IRQ handler does similar, there is code in there to pass on to the original MOS BRK handler but 816BASIC installs its own.

I needed some Bank 0 RAM for the 816 and this is all at $A00-$AFF (this will move) and $1900 upwards.

Now this all probably sounds a bit over-complicated and if your set up is a TUBE based 816 then it probably is! But I'm trying to make a system whereby unless you're running a native mode application everything should behave as on a normal Beeb.

Finally XLOADD1 is needed as of course all the filing systems know nothing about ChipRAM it is just a tool to load data into a PageWide interface (assuming the device number if D1 - I think others can be specified). I've also included XMDUMP which can be used to inspect PageWide memory

I'll be able to give clearer guidance after some sleep and knowing how you're running. I would love to collaborate on the 816 decoder as I've used the 6502 one extensively - it's a truly genius idea.

None of the above is specific to the core of BASIC that I've been porting and any other native mode scheme could be used. The only interaction I think that the core of BASIC needs are: a way of allocating a block of Bank 0 memory for its direct page (larger than that allowed by the MOS) and a way of capturing Native mode BRK (needed to work out the address of the BRK in 24bit memory space)

D

PS: I've just been rereading old threads and may be on to you and BigEd for advice on the continued fraction floating point stuff. I'll have a crack at it myself and probably get stuck

[Bobbi]

This is very cool stuff. As an Apple IIgs owner and programmer I have an interest in 65816. I am not really an expert 816 programmer, but I do have access to quite a few very experienced Apple IIgs game developers from back in the day. If you need any 65816 expertise I can pass questions on. There are some interesting coding tricks such as using unrolled loops of PEI instructions for a rapid memory copy / blit.

[dominicbeesley]

Thanks bobbi,

I'm not sure we'll be getting quite that cutting edge with optimisation but every little helps. It would be cool to see bbc basic on an apple II though!

Do you know are there any good primers on tips and tricks for the 816?

[Bobbi]

There are lots of people in the Apple II community (well at least a few!) who would like BBC BASIC. Let me ask on one of the GS groups if there is a good 'tips' document somewhere. There is an Apple II Slack server where there is a lot of programming chat.

[Bobbi]

Incidentally, is it known how complete the embedded 65816 assembler is? If it is reasonably complete and well implemented it would be really nice on the GS!

[hoglet]

Now this all probably sounds a bit over-complicated and if your set up is a TUBE based 816 then it probably is! But I'm trying to make a system whereby unless you're running a native mode application everything should behave as on a normal Beeb.

Actually, the system I had in mind was Beeb816. But you raise a whole bunch of memory map related issues that I hadn't really considered. So I think it's going to be an uphill struggle.

My immediate goal is extending the 6502 Decoder to support the 65816 in it's native modes(s). For this I need a few logic analyzer traces to develop against that show some code running in various modes. That was what I was hoping to get from running Basic816.

You don't happen to have any traces taken from your system do you?

Ideally they would need to contain D[7:0], RnW, VPA, VDA, RDY (if used), and optionally VPB and IRQ. These would need to be sampled once per cycle on the falling edge of the clock. The longer the trace the better.

Dave

[BigEd]

(Beeb816's memory map is quite different, but I don't know if that's too big an obstacle. Is this a good place to discuss the two? Or should we perhaps have a new thread?)

[BigEd]

Incidentally, is it known how complete the embedded 65816 assembler is? If it is reasonably complete and well implemented it would be really nice on the GS!

I've only typed a handful of opcodes in to a Communicator, but I'd guess that it's a completely featureful embedded assembler - and indeed, it's a major feature for an 816 Basic to have.

[Deleted User 9295]

Splitting out Arithmetic probably seemed like a good idea at the time but with a bit of optimization it would probably have taken less space to keep the stuff in BASIC for faster calling and keep the module for ViewSheet.

Roughly how big is the arithmetic module? The Z80 equivalent in the Z88 is about 3K, which would be a lot to gain back by "optimisation", and it does seem more 'elegant' to me to share the module than to have two copies.

[dominicbeesley]

Thanks all for the replies,

Bobbi, the assembler seems to be pretty complete - the BBC Basic assemblers have always been pretty good. I've not really tested the assembler on my port yet but as BigEd says when it works it will be good.

BigEd, probably a new thread for the memory map etc.

Dave, I've sent a PM about the captures. We could take it over to the OSLA thread?

The ARITHMETIC module is about 5k but much of that appears to be dead code, module cruft and functions that BASIC doesn't call. For the communicator it looks like they either did the module and then decided to move some fp stuff back into BASIC (too slow?) or they never moved it all out in the first place as there's quite a bit of fp stuff left and some duplication i.e. there's a "real to int" function in BASIC which is used for INT() but when converting from real to int for procedure call parameters the module is called (I suspect due to shared direct page variables).

I've not worked out quite what the arithmetic module is doing but it seems to be doing a whole heap of pushing an popping to its stack that looks to be superfluous!

For my purposes having a shared module is not really helpful (no module capable OS on my machine...yet, I've just stuck the object code on the end and it calls the dispatcher) but if I back port BASIC432's fp I may well port it back to the ARITH module in case anyone want's a faster better communicator! It will be interesting if we get Dave's decoder working to see how much time is wasted in the module switching, dispatch and other overhead compared to the actual calculation part.

D

[Deleted User 9295]

there's a "real to int" function in BASIC which is used for INT() but when converting from real to int for procedure call parameters the module is called

They should be different! BASIC's INT() truncates towards minus-infinity (i.e. it's the floor function) whereas coercing to an integer when calling a procedure truncates towards zero. So it would definitely not be correct to use the same function for both:

Code: Select all

      PRINT INT(-3.5)
      PROCint(-3.5)
      DEF PROCint(A%) : PRINT A% : ENDPROC

should print -4 and -3.

[BigEd]

(Confirmed in jsbeeb for 6502 BBC Basic!)

[Deleted User 9295]

(Confirmed in jsbeeb for 6502 BBC Basic!)

I think I'm pretty safe in saying that no version of BBC BASIC has ever got this wrong. In fact it's almost universal in the BASIC language more generally, but there are a couple of outliers: Liberty BASIC is one (its INT function truncates towards zero - ouch).

[dominicbeesley]

Thanks both, I'll mark the difference in the disassembly...I should have spotted that but not really gone into a huge amount of detail yet. It's good to have eyes on so I'll be back with questions as they arise no doubt!

D

[Bobbi]

I asked on the Apple II Slack and these were a couple of the resources recommended:

http://archive.6502.org/datasheets/wdc_ ... manual.pdf

http://www.1000bit.it/support/manuali/a ... s.090.html

Maybe there are some useful nuggets there

[dominicbeesley]

Thanks Bobbi,

I've got all the datasheets but the "Tips, tricks and pitfalls" is new to me...some bedtime reading

Thanks

D

[Bobbi]

I am learning 65816 myself, and it sure is nice to have access to some experts.

[dominicbeesley]

One small step forwards: I got rid of some debug code that I'd left behind and replaced all the phk/jsr...rtl sequences in the Arithmetic module with jsr/rts a modest improvement:

417_arithrtl-sm.jpg

Then I unearthed my earlier tweaks to BASIC432 and for no particular reason a change to the find program line routine was the first thing I saw. Basically a quick change to use 16bit arithmetic, I ported it across and results were disappointing!

417M_gosub16_bas-sm.jpg

This just goes to show that using the 16bit functions doesn't always pay off in terms of speed, in the tight loop that was there before the 8bit comparison of the high byte of the line number was actually quicker! On the plus side the code _is_ smaller.

I think I may end up adding switches to optimize for speed or optimize for size. It would be cool to get the whole lot down to 16k again!

For reference here's the GOSUB change

Code: Select all

prog_search_lineno:
        .IFDEF OPTIMIZE
                rep     #$20
                .a16
                lda     DP_BAS_PAGE
                sta     DP_FPB_exp
                ldy     DP_BAS_PAGE+2
                sty     DP_FPB_mant+1                   ;Point at start of program
@lp:
                ldy     #$01
                lda     [DP_FPB_exp],y                  ;get line no hi byte
                xba
                cmp     DP_BAS_INT_WA                   ;compare to line number in WA
                bcs     @skCkLo                         ;greater or equal
@nextline:      ldy     #$03
                lda     [DP_FPB_exp],y                  ;get line length
                and     #$FF                            ; we only want an 8 bit number!
                adc     DP_FPB_exp                      ;add to pointer and repeat
                sta     DP_FPB_exp
                bcc     @lp
                inc     DP_FPB_mant+1
                bra     @lp

@skCkLo:        sep     #$20
                .a8
                bne     @retCLCY2                       ;greater - exit
                iny
                rts                                     ;returns with Cy=1 - exact match

@retCLCY2:      iny
                clc
                rts                                     ;failed to find return with Cy=0


        .ELSE

                lda     DP_BAS_PAGE
                sta     DP_FPB_exp
                lda     DP_BAS_PAGE+1
                sta     DP_FPB_mant
                lda     DP_BAS_PAGE+2
                sta     DP_FPB_mant+1                   ;Point at start of program
@lp:
                ldy     #$01
                lda     [DP_FPB_exp],y                  ;get line no hi byte
                cmp     DP_BAS_INT_WA+1                 ;compare to line number in WA
                bcs     @skCkLo                         ;;greater or equal
@nextline:      ldy     #$03
                lda     [DP_FPB_exp],y                  ;get line length
                adc     DP_FPB_exp                      ;add to pointer and repeat
                sta     DP_FPB_exp
                bcc     @lp
                inc     DP_FPB_mant
                bne     @lp
                inc     DP_FPB_mant+1
                bra     @lp

@skCkLo:        bne     @retCLCY2                       ;greater - exit
                iny
                lda     [DP_FPB_exp],y
                cmp     DP_BAS_INT_WA                   ;compare lo
                bcc     @nextline                       ;was less continue search
                bne     @retCLCY2
                rts                                     ;returns with Cy=1 - exact match

@retCLCY2:      ldy     #$02
                clc
                rts                                     ;failed to find return with Cy=0
        .ENDIF

I'm not sure how much interest there is in these minutiae? Should I keep em coming or wind my neck in and get on with it?

[Bobbi]

I am always interested to read 65816 code and observations.

[BigEd]

I wouldn't worry about code size: in this context we have acres of RAM to play with. A 24k or even a 32k Basic wouldn't be a problem, I think. Especially if such an approach improves performance!

BTW Bruce Clark wrote an excellent document on the 816:
http://www.6502.org/tutorials/65c816opcodes.html

[dominicbeesley]

Thanks for that pointer Ed, I'll get a look at that later.

I've just done a little more tinkering with the program line find routine (this is not really an important part of BBC BASIC but it's a nice easy to fiddle with and testable part). One thing I've noticed is that using lda (dp),Y and the bank register is a good bit quicker than lda [dp],Y in tight loops. 816 BASIC uses lda [dp],Y all over the place so that might be the thing to attack first. It's likely to be a lot of work so I may give it a rest a few days (I've been obsessing about this far too much) and start a branch to test out the theory. At least I've satisfied myself that the bank crossing thing isn't a problem.

Here's GOSUB test with the faster (larger) code:

418_findprogline-sm.jpg

And the rather more involved code

Code: Select all

                ; attempt to speed up by using 16bit DP pointers and databank register
                ; assumption: databank wrapping won't cause bother!

                clc
                lda     DP_BAS_PAGE
                adc     #1
                sta     DP_FPB_exp
                lda     DP_BAS_PAGE+1
                adc     #0
                sta     DP_FPB_exp+1
                lda     DP_BAS_PAGE+2
                adc     #0
                pha
                plb                                     ; bank is now at start of program

                ldy     #2

@lp:            lda     (DP_FPB_exp)                    ;get line no hi byte
                cmp     DP_BAS_INT_WA+1                 ;compare to line number in WA
                bcs     @skCkLo                         ;;greater or equal
@nextline:      lda     (DP_FPB_exp),y                  ;get line length
                adc     DP_FPB_exp                      ;add to pointer and repeat
                sta     DP_FPB_exp
                bcc     @lp
                inc     DP_FPB_exp+1
                bne     @lp
                ; next bank
                phb
                pla
                inc     A
                pha
                plb
                bra     @lp

@skCkLo:        bne     @retCLCY2                       ;greater - exit
                dey
                lda     (DP_FPB_exp),y
                iny
                cmp     DP_BAS_INT_WA                   ;compare lo
                bcc     @nextline                       ;was less continue search
                beq     @skclc
@retCLCY2:
                clc
@skclc:         php
                clc
                lda     DP_FPB_exp
                sbc     #0
                sta     DP_FPB_exp
                lda     DP_FPB_exp+1
                sbc     #0
                sta     DP_FPB_exp+1
                phb
                pla
                sbc     #0
                sta     DP_FPB_exp+2
@rts:           phk
                plb
                plp                
                rts

[dominicbeesley]

As Bobbi asked I thought I'd give the assembler a whirl to see if it worked. It appears to be good to go. I'm not sure of all the syntax for instance I'm not sure how one tells the assembler the size of M/X etc but it should be deducible from the documentation that's around.

WIN_20201130_17_23_52_Pro-sm.jpg

[Bobbi]

It looks like it uses LDAL, STAL etc to specify 16 bit ops.

[BigEd]

I think the Acorn Communicator Software Tools Manual, a free download from the CCH, has the answers.