BBC BASIC on the 65816

[dominicbeesley]

Some of the answers...I've been using the Software Tools and Systems Manual there's a lot there but its a bit of a struggle to find what's what, there's very little on the BASIC assembler, though it looks like it should be good if we can work out the syntax for the 65816 extras. I guessed STAL etc but still not figured how to specify the mode (not change the mode). I'm sure there must be some more comprehensive documentation somewhere. It would be great to get hold of it as it looks to be a very interesting operating system,.

[Bobbi]

I think that assemblers that use STAL etc. do not need a pseudo-op to change the mode. It is an alternative way to do it.

One way (this is how ORCA/M does it on Apple IIGS):

Code: Select all

        REP #$20	# Set m to 16 bit mode
        LONGA ON	# Tell the assembler!
        LDA $1234	# Assembler knows this is 16 bit load
        SEP #$20	# m back to 8 bit
        LONGA OFF	# Tell the assembler
        LDA $1234	# Now this will be an 8 bit load

Or, you the assembler supports L suffix for 16 bit ops, there is no need for LONGA (or .a16 or whatever):

Code: Select all

        REP #$20	# Set m to 16 bit mode
        LDAL $1234	# 16 bit
        SEP #$20	# m back to 8 bit
        LDA $1234	# 8 bit (no L)

Either way if you get the SEP / REP out of sync with the pseudo ops, you will end up disappointed!

[BigEd]

Hmm, I'm not sure about that. I'd say that LDAL is to say that the address is a three byte address, and says nothing about whether A and M is 8 or 16 bits. I think directives are needed, but as it turns out I don't see anything useful in that manual.

(In the '816, you set the size of the registers, and the operands follow suit - it's quite unlike a normal 16 bit machine.)

We may need to read the code to find out!

[dominicbeesley]

Yes I guess the bbc basic for communicator reference manual is MIA. The assembler will take a bit more work to understand. I have done the assembler before when porting to the 6809 but this looks quite different.

There should be some clues in the compacted opcode table...I just need to reremember where my decode script is

[RobC]

Yes I guess the bbc basic for communicator reference manual is MIA.

I have a physical copy of it (as part of the AFJ10 manual set).

EDIT: Just dug it out and, although I've only skimmed it, it seems to say that the M flag dictates the memory/accumulator size (M=1 => 8 bits, M=0 => 16 bits) and the 'L' suffix denotes 'long' addressing modes which use 3-byte addresses.

[dominicbeesley]

Thanks Rob does it say anything about pseudo op codes too tell the assembler what mode you're entering in?

[RobC]

It mentions the directives BYP for "set byte assembly mode" and RRD for "set word assembly mode".

However, I think there may be typos in the sections relating to both of these:

BYP - Set byte assembly mode
This directive is followed by a number. Two bits of the number are significant - bit 4 and bit 5. If bit 4 is set, the assembler will start to assemble subsequent code for X-flag=1 operation, ie byte mode for X and Y index registers. If bit 5 is set, the assembler assumes byte mode memory and accumulator operation. The directive is almost always used in conjunction with the SEP instruction and with the same operand, eg:

SEP #&20 ; Byte memory mode
BYT &20

RRD - Set word assembly mode
This directive is followed by a number. Two bits of the number are significant - bit 4 and bit 5. If bit 4 is set, the assembler will start to assemble subsequent code for X-flag=0 operation, ie two-byte mode for X and Y index registers. If bit 5 is set, the assembler assumes two-byte mode memory and accumulator operation. The directive is almost always used in conjunction with the RSP instruction and with the same operand, eg:

RSP #&30 ; Two-byte memory mode
WPD &30

An attempt to use the WRD directive in emulation assembly mode will give a 'Bad MODE' error.

So are the directives BYP and RRD or BYT and WPD (or even WRD!)? I'd say BYT and WRD would seem to make the most sense but the text is confusing (although this could just be my lack of knowledge about the 65816...)

It also mentions the directive EMU for emulation mode: EMU 0 for 65816 mode and EMU 1 for single byte (6502?) mode. And BNK to set the program bank.

[RobC]

I've found an example earlier in the chapter that does seem to indicate that the directives are BYT and WRD:

Code: Select all

100   EQUS FNloadBHA(&65342)
140   EQUS FNloadBHA(longAddr)
1000 DEF FNloadBHA(addr)
1010 [ OPT @OPT%
1020   BYT &20
1030   RSP #&20
1040   LDA #addr DIV &10000
1050   PHA
1060   PLB
1070   WRD &20
1080   SEP #&20
1090   LDA #addr AND &FFFF
1100 ]
1110 =" "

Maybe this helps? Although I thought BYT went with SEP etc.?

[BigEd]

Nice find Rob - there are hints of BYT and WRD in the manual I do have, but you've evidently got something much better (with bonus OCR puzzles)

[RobC]

Nice find Rob

It's from the set I showed you on Zoom. I had to buy another Communicator to get it though!

I suspect very few people have ever read the BASIC Reference Manual in anger. There is an errata sheet for it but it doesn't cover any of things I mentioned above.

Along with the manuals, I got some correspondence between the original owner and Acorn. Amusingly, when asked for info about the Communicator, Acorn's first response was "never heard of it". Eventually, they found someone who knew about it, located the manual set I now have and sent them free of charge. The original owner also asked whether it was possible to add a disk drive but was told that this wasn't possible.

[Pernod]

Yes I guess the bbc basic for communicator reference manual is MIA.

I have a physical copy of it (as part of the AFJ10 manual set).

Which manuals do you have?

[RobC]

Which manuals do you have?

Communicator User Guide, View User Guide, Viewsheet User Guide and BASIC Reference Manual.

[Pernod]

Which manuals do you have?

Communicator User Guide, View User Guide, Viewsheet User Guide and BASIC Reference Manual.

Ok, was hoping for a Service Manual.

[dominicbeesley]

Thanks Rob,

The rep and sep are the instructions that do the swap, BYT and WRD are (hopefully) the pseudo ops that I was looking for that tell the assembler what mode you expect the processor to be in. They need separate codes as you may enter a routine in 16 bit mode but not have a 16 bit mode swap instruction etc. It is one of hassles of the 65816 world as it is easy to get out of sync.

I suspect those manuals are well worth preserving as I've not managed to find a scan of them.

D

[jgharston]

You can also get hints from the BASIC programs supplied in the ROM set, which have assembler snippets in them:
http://mdfs.net/System/ROMs/AcornMOS/Co ... /Programs/

[dominicbeesley]

Good point. I'd assumed they would be straight BASIC and anything that needed assembling would have been included in the rom in binary form...I should have looked!

[hoglet]

Hi Dom,

I would love to collaborate on the 816 decoder as I've used the 6502 one extensively - it's a truly genius idea.

I'm pleased someone else is using it.

I've been working on the 816 decoder the past few days, and it's getting to the stage where it's useful now. The disassembly and PC prediction parts should be accurate and complete. The register emulation part is still a work in progress. It's about 80% done. I just need to properly implement the 16-bit operations, and the DP register.

The traces you have were very useful - it now decodes each of these without any "prediction failed" errors:

Code: Select all

$ cd test/
$ ./run_816_tests.sh

hog816_emu
../decode6502 -d1 -8 -a -h -i -y -s --sp=01FD --phi2= --rdy= --rst= --emul=1 816_blitter/hog816_emu.data > 816_blitter/hog816_emu.log
  Trace MD5: a019b353; Prediction fail count: 0; Reference diff count: 0

hog816_interrupt
../decode6502 -d1 -8 -a -h -i -y -s --sp=01FD --phi2= --rdy= --rst= --emul=0 816_blitter/hog816_interrupt.data > 816_blitter/hog816_interrupt.log
  Trace MD5: 8a47786e; Prediction fail count: 0; Reference diff count: 0

hog816_native
../decode6502 -d1 -8 -a -h -i -y -s --sp=01FD --phi2= --rdy= --rst= --emul=0 816_blitter/hog816_native.data > 816_blitter/hog816_native.log
  Trace MD5: 50998f6f; Prediction fail count: 0; Reference diff count: 0

Here's the results:

816_blitter.zip

The 816 work is happening in the dev branch:
https://github.com/hoglet67/6502Decoder/commits/dev

Feel free to have a play.

Dave

[dominicbeesley]

Excellent news! I've put off doing any more hacking on 65816 BASIC until I've got some debugging tools and this should fit the bill nicely most of the time. I've still to get a Linux box up for captures but I can probably live with 2048 cycles and triggers most of the time.

If you've any specific scenarios you want me to model (RDY, ABORT, specific instruction sequences, esoteric interrupt testing etc) I should be able to cater to anything.

D

[hoglet]

If you've any specific scenarios you want me to model (RDY, ABORT, specific instruction sequences, esoteric interrupt testing etc) I should be able to cater to anything.

There is limited abount of 16-bit goodness in the Beeb816 Boot ROM, so a trace from Basic816 with some interesting native/16-bit stuff going on would be very helpful.

I would recommend you try to get the FX2 board working. You can easily then capure a couple of seconds worth of test. It also means you don't have to worry about logic analyzer triggers. (You can of course use triggers in the decoder).

Re: Basic816 - I see it runs from bank 1.

How hard would it be to run it in a different bank?

Dave

[dominicbeesley]

It should be easy enough to make it work in any bank other than 0 on the Blitter - Bank0 is reserved mostly. I'd have to do some work to make it straddle a bank though, it's all coded to work from a single bank. I'm guessing you want some more bank switchy goodness? I can easily make something that does lots of databank switching by just making PAGE=&02FF00 in BASIC.

I have been trying to get a PI up and running this evening but am having (the usual) networking issues getting it to connect to my SMB shares and trying to re-remember how to get my Win10 laptop to work as a network gateway. I may give up on it and either go box diving and find a linux box or switch to a PiZero. My workshop is all WiFi and that is another can of worms - the WiFi 4G router doesn't always play nice.

Do you think it would be a lot of work to get your synchronous fx2 tool to compile for windows or run in WSL? I've not done any usb stuff in C so no idea how high-level the interfacing would be.

D

[hoglet]

It should be easy enough to make it work in any bank other than 0 on the Blitter - Bank0 is reserved mostly. I'd have to do some work to make it straddle a bank though, it's all coded to work from a single bank. I'm guessing you want some more bank switchy goodness?

I'm really looking for a way to easily run this on Beeb816, which has a different memory map.

Bank 0 contains the BBC slow motherboard resources, Banks 248-255 are the 512KB high speed RAM, and there is selective aliasing/remapping of bits of Bank 0 into the higher banks):

beeb816.PNG

(DIagram courtesy of Revaldhino)

Do you think it would be a lot of work to get your synchronous fx2 tool to compile for windows or run in WSL? I've not done any usb stuff in C so no idea how high-level the interfacing would be.

I don't have much experience of devlopment on native Windows, and it doesn't seem like WSL has USB support:
https://github.com/microsoft/WSL/issues/5158

Dave

[Coeus]

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.

That's interesting. In cases where both bytes are needed you'd expect 16bit instructions to be faster even on a processor with an 8bit external data bus because, although just as many memory cycles are needed to fetch, and possibly store back, the data as with 8 bit instructions, there should be fewer instruction fetches.

Perhaps, in this case, though, the initial comparison when working 8 bits at a time is usually false so skipping the fetching of the other bytes (and the instructions to operate on them) so fewer memory cycles overall.

[dominicbeesley]

Coeus, that's pretty much it. Also incrementing a large number is faster as a series of 8 bit INCs and BNEs but more succinct with 16bits.

Hoglet, I need to check the latest in to github but it should be fairly easy to fix up for beeb816. You'll need to make a loader to get the code into whatever bank you run from and jump to it. But the rest should all just be changing a few defines in the .inc file. https://github.com/dominicbeesley/CommunicatorBasic100

I'll have a crack at adding a beeb816 target to the makefile...I need to probably rename the BLITTER define to something more neutral.

The blitter board has a slightly different memory map that works well for other processors. In 816 mode the slow beeb memory is at bank FF mirrored in bank0 with the option to shadow 4k segments in fast ram. The fast ram starts at 0 going up and the current native mode program expected to load at 010000 upwards as there's a system heap that grows down from the top of ram for loading modules, sounds samples etc. Flash Rom sits near the top and extra hardware registers appear at bank FE. There's a whole load of aliasing that I can't remember now (I'm on my phone). The offer still stands for a blitter if you're interested. It would be good to get some convergence on the apps and memory map.

On the USB thing I see there is a libusb for mingw and for visual c so I might give that a crack. I really do need a Linux box again though

[dominicbeesley]

Hi Hoglet,

I've made some changes and now it should build a BASIC for the beeb816. I made some assumptions based upon what I've seen in Ed's boot816 rom but I may well have got hold of the wrong end of the stick.

The main places to look are in:

bas816new_BEEB816.cfg
bas816new_BEEB816.inc
bas816new_natshims.asm

If just plonked basic in bank F8 and workspace from F9 up for 3 banks, this is easy enough to tweak in the files above.

The native shims live in page A in bank 0 but that can be moved. Basic requires a direct page and the arith module direct page and a couple of workspace pages which I've stuck in bank 0 all starting at &1900 to avoid any filing systems, again these can be moved.

There are some extra vectors also at &2000 onward.

The above stuff is all subject to change and is coded in .inc's at present. I intend to add an API to the Blitter support rom to allocate these at run time.

What is definitely missing is some way to load the stuff into high memory, you'll need a loader to load BASIC into bank F8 and jump to the start, it should be entered in emulation mode and will set its own IRQ handler and other vectors up. The IRQ handler just passes on to the MOS by reentering emulation mode (and a lot of pushing an popping to preserve regs). There's also a native mode BRK handler that is used by basic for error handling. If a BRK happens in emu mode then the thing will drop out.

BASIC is very much unfinished, waiting mainly for me to write shims for other MOS entries. At present just OSBYTE, OSWORD0, OSWRCH are implemented (these are all marked with "TODO" in the code). If they're hit at present they just print a message and hang.

To load programs to basic you'll need to write a loader to plonk the code at &F9000 then do OLD to see them in BASIC.

I've left the new BASIC prompt as '#' so I know when it has crashed back to 6502 BASIC!

All in GitHub

D

[hoglet]

Any hints as to how to build the BEEB816 version from the Makefile?

[hoglet]

Code: Select all

$ca65 --version
ca65 V2.16 - Ubuntu 2.16-2

$ make
ca65  -D COMMUNICATOR -D COMM100 -o build/bas816new_COMBAS100.o -g -l build/bas816new_COMBAS100.lst bas816new.asm
bas816new.asm(604): Error: Syntax error
bas816new.asm(604): Error: `,' expected
bas816new.asm(604): Error: Unexpected trailing garbage characters
bas816new.asm(684): Error: Syntax error
bas816new.asm(684): Error: `,' expected
bas816new.asm(684): Error: Unexpected trailing garbage characters
Makefile:111: recipe for target 'build/bas816new_COMBAS100.o' failed
make: *** [build/bas816new_COMBAS100.o] Error 1

Do I need a newer version of CC65?

[hoglet]

OK, that's better:

Code: Select all

$ ca65 --version
ca65 V2.19 - Git b22d8c74

$ make
ca65  -D COMMUNICATOR -D COMM100 -o build/bas816new_COMBAS100.o -g -l build/bas816new_COMBAS100.lst bas816new.asm
ld65 -vm -Ln build/bas816new_COMBAS100.sy2 -m build/bas816new_COMBAS100.map -o build/bas816new_COMBAS100.bin -C bas816new_COMBAS100.cfg build/bas816new_COMBAS100.o
ca65  -D OPTIMIZE=1 -D BLITTER -D MOS -D BUGFIX -o build/bas816new_BLITTER.o -g -l build/bas816new_BLITTER.lst bas816new.asm
ca65  -D OPTIMIZE=1 -D BLITTER -D MOS -D BUGFIX -o build/arith_new_blit_bas.o -g -l build/arith_new_blit_bas.lst arith_new.asm
ld65 -vm -Ln build/bas816new_BLITTER.sy2 -m build/bas816new_BLITTER.map -o build/bas816new_BLITTER.bin -C bas816new_BLITTER.cfg build/bas816new_BLITTER.o ./build/arith_new_blit_bas.o
ca65  -D OPTIMIZE=1 -D BEEB816 -D MOS -D BUGFIX -o build/bas816new_BEEB816.o -g -l build/bas816new_BEEB816.lst bas816new.asm
ca65  -D OPTIMIZE=1 -D BEEB816 -D MOS -D BUGFIX -o build/arith_new_beeb816_bas.o -g -l build/arith_new_beeb816_bas.lst arith_new.asm
ld65 -vm -Ln build/bas816new_BEEB816.sy2 -m build/bas816new_BEEB816.map -o build/bas816new_BEEB816.bin -C bas816new_BEEB816.cfg build/bas816new_BEEB816.o ./build/arith_new_beeb816_bas.o
ca65  -D COMMUNICATOR -D COMM100 -o build/arith_new_COMARITH100.o -g -l build/arith_new_COMARITH100.lst arith_new.asm
ld65 -vm -Ln build/arith_new_COMARITH100.sy2 -m build/arith_new_COMARITH100.map -o build/arith_new_COMARITH100.bin -C arith_new_COMARITH100.cfg build/arith_new_COMARITH100.o

[dominicbeesley]

I think the 65816 support is relatively new in ca65 but seems to work in ca65 V2.18 - Git edfda72a

D

[hoglet]

Well, that was all rather painless:

capture3.png

I changed XLOAD to use the 816's STA [IDL], Y instruction, and was able to load BAS816 to &F80000

I then just did a JML to &F80000

A couple of questions...

1. Do you get an Eof error with XLOAD?

2. Why didn't I need to install my own native IRQ handler? (I assume this must be running in native mode?)

Dave

[hoglet]

Any thoughts on what might be going wrong here?

capture5.png

It runs for a couple of second then barfs.

Earlier in the thread you had CLOCKSP running.

Can you check it still works?

Dave