BBC BASIC on the 65816

[hoglet]

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

To answer my second question, I see that a native mode interrupt wrapper is installed by BAS816:

Code: Select all

F82056 : C8          : INY            : 2 : A=0104 X=0015 Y=0005 SP=01E4 N=0 V=0 M=1 X=1 D=0 I=0 Z=0 C=1 E=0 PB=F8 DB=F8 DP=1900
F82057 : B7 2F       : LDA [2F],Y     : 6 : A=0125 X=0015 Y=0005 SP=01E4 N=0 V=0 M=1 X=1 D=0 I=0 Z=0 C=1 E=0 PB=F8 DB=F8 DP=1900
F82059 : C9 25       : CMP #25        : 2 : A=0125 X=0015 Y=0005 SP=01E4 N=0 V=0 M=1 X=1 D=0 I=0 Z=1 C=1 E=0 PB=F8 DB=F8 DP=1900
F8205B : D0 15       : BNE 2072       : 2 : A=0125 X=0015 Y=0005 SP=01E4 N=0 V=0 M=1 X=1 D=0 I=0 Z=1 C=1 E=0 PB=F8 DB=F8 DP=1900
F8205D :             : INTERRUPT !!   : 8 : A=0125 X=0015 Y=0005 SP=01E0 N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=F8 DP=1900
000A5B : 0B          : PHD            : 4 : A=0125 X=0015 Y=0005 SP=01DE N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=F8 DP=1900
000A5C : 8B          : PHB            : 3 : A=0125 X=0015 Y=0005 SP=01DD N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=F8 DP=1900
000A5D : 4B          : PHK            : 3 : A=0125 X=0015 Y=0005 SP=01DC N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=F8 DP=1900
000A5E : 4B          : PHK            : 3 : A=0125 X=0015 Y=0005 SP=01DB N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=F8 DP=1900
000A5F : 2B          : PLD            : 5 : A=0125 X=0015 Y=0005 SP=01DD N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=F8 DP=0000
000A60 : 4B          : PHK            : 3 : A=0125 X=0015 Y=0005 SP=01DC N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=F8 DP=0000
000A61 : AB          : PLB            : 4 : A=0125 X=0015 Y=0005 SP=01DD N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A62 : 08          : PHP            : 3 : A=0125 X=0015 Y=0005 SP=01DC N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A63 : C2 30       : REP #30        : 3 : A=0125 X=0015 Y=0005 SP=01DC N=0 V=0 M=0 X=0 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A65 : 48          : PHA            : 4 : A=0125 X=0015 Y=0005 SP=01DA N=0 V=0 M=0 X=0 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A66 : DA          : PHX            : 4 : A=0125 X=0015 Y=0005 SP=01D8 N=0 V=0 M=0 X=0 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A67 : 5A          : PHY            : 4 : A=0125 X=0015 Y=0005 SP=01D6 N=0 V=0 M=0 X=0 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A68 : 62 0A 00    : PER 0A75       : 6 : A=0125 X=0015 Y=0005 SP=01D4 N=0 V=0 M=0 X=0 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A6B : E2 30       : SEP #30        : 3 : A=0125 X=0015 Y=0005 SP=01D4 N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=1 E=0 PB=00 DB=00 DP=0000
000A6D : A9 04       : LDA #04        : 2 : A=0104 X=0015 Y=0005 SP=01D4 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=1 E=0 PB=00 DB=00 DP=0000
000A6F : 48          : PHA            : 3 : A=0104 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=1 E=0 PB=00 DB=00 DP=0000
000A70 : 38          : SEC            : 2 : A=0104 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=1 E=0 PB=00 DB=00 DP=0000
000A71 : FB          : XCE            : 2 : A=0104 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=0 E=1 PB=00 DB=00 DP=0000
000A72 : 6C FE FF    : JMP (FFFE)     : 5 : A=0104 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=0 E=1 PB=00 DB=00 DP=0000
00DC1C : 85 FC       : STA FC         : 3 : A=0104 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=0 E=1 PB=00 DB=00 DP=0000
00DC1E : 68          : PLA            : 4 : A=0104 X=0015 Y=0005 SP=01D4 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=0 E=1 PB=00 DB=00 DP=0000
00DC1F : 48          : PHA            : 3 : A=0104 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=0 C=0 E=1 PB=00 DB=00 DP=0000
00DC20 : 29 10       : AND #10        : 2 : A=0100 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=0 E=1 PB=00 DB=00 DP=0000
00DC22 : D0 03       : BNE DC27       : 2 : A=0100 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=0 E=1 PB=00 DB=00 DP=0000
00DC24 : 6C 04 02    : JMP (0204)     : 5 : A=0100 X=0015 Y=0005 SP=01D3 N=0 V=0 M=1 X=1 D=0 I=1 Z=1 C=0 E=1 PB=00 DB=00 DP=0000

[hoglet]

OK, I've got a bit further with CLOCKSP:

capture6.png

capture7.png

The first issue was that the Too Big error seemed to occur when assigning a floating point value to an integer variable.

I'm guessing you have trodden this path as well.

Do you have an 816 Basic compatible version of CLOCKSP?

Dave

[BigEd]

Still a work in progress, evidently, but a marvellous development!

BTW, although beeb816 does have SRAM in bank F8 and up, I think it's best to start at the lowest image of that SRAM, in bank C0. That allows later boards to fit more RAM and still have everything start at the same address.

[dominicbeesley]

No no EOF problems in XLOAD but mine is a hacked one, post yours up I'll give it the once over.

Normal "bog standard" CLOCKSP works here though mine is an old version I think. I've attached my copy. Probably first thing to check is what the value of F the PROCp call does PROCp(F*41000/T%) so check to see what those values are.

The irq handler is all in the bas816native_shims.asm file.

Did you bodge CLOCKSP to get further or is it doing different random stuff each time. I've not had any of those errors here. In theory the code is pretty much identical other than the bit that installs the native shims and even there there's not much difference other than the method of poking high memory.

I've run CLOCKSP here to check I've not messed anything up and all looks fine and I've compared the .lst files and I can't see any unexpected differences.

I've attached my binaries and build intermediates for comparison and the ClockSp that I'm using.

Probably the first thing is to make sure all my shims guesses were right - but that trace looks good. Then it's going to be a case of trying to narrow down to the actual problem. It will either be something daft that I've done - or possibly a timing problem with the 816 in which case we might have to start comparing traces to see where/if they are diverging on test cases?

Ah, Ed just spotted your post - that's all tinkerable in the .inc files

D

[BigEd]

That error from printing COS(0) must be worth a bit of a dig. Does that fail in your case too Dominic?

[dominicbeesley]

Good point - it's rock solid here. That is the part of all the transendentals that limits the angle to a quadrant, if that's not right then there's something up with the way the arithmetic module is being called possibly.

I've just done a compare on the build files and apart from the shims install step everything looks to be identical so this might take a bit of tracing!

D

[dominicbeesley]

Aha,

I've got it. Arithmetic workspace. Try changing the line: (in bas816new_BEEB816.inc)

Code: Select all

MOS_ARITH_WKSPC			:=	$01FD00		; just below page

To something more suitable for the beeb816

Code: Select all

MOS_ARITH_WKSPC			:=	$F8FD00

Should do it - sorry should have spotted that - it has gone fairly smoothly though I suppose!

[dominicbeesley]

That should fix it - if it does let me know and tweak the stuff on Git.

Also, I'll probably move the direct pages up to 1D00...I'm about to start using ADFS!

D

[hoglet]

That should fix it - if it does let me know and tweak the stuff on Git.

Yup, that fixed it!

capture8.png

Cool!

Ed, tomorrow I'll try to package this up as a bootable .ssd file for you and Rich to play with.

Dom, and chance of wrapping OSCLI. It would be nice to be able to use * commands

Dave

[BigEd]

Splendid! Those timings are all over the place - I suppose that says something about the use of '816 extra features.

[dominicbeesley]

Cool, one stupid mistake isn't too bad for me on a Friday

I think if you can make sure the direct page locations, scratch workspaces and stack are served from fast ram then it will all be more even (and faster!)

I've checked in that fix and also just got a bit of time to make OSCLI work - which meant doing some more shimming to route an emulation mode BRK up to our own native mode handler. It's a bit involved but I made another vector that will accept a long address.

I should be able to get this fairly full-functioned soon. The main differences will be that LOAD/SAVE will need to load chunks of a program to Bank0 and copy up to high ram but that shouldn't be too big a deal.

I've not really done any optimisations yet but hopefully when I get a Dave's decoder up and running I can attack some of the core and get it a bit more slick.

D

[dominicbeesley]

I've made some more tweaks. Most of the OSWORDS (SOUND, ENVELOPE, POINT, TIME, etc) are all now full implemented, GET, GET$ and most importantly LOAD...no SAVE yet but that should be easy.

It's all fairly noddy at the moment, for instance LOAD is OPENIN followed by a load of BGETs so it's slow - we can't use OSFILE as that doesn't know about hi memory. I will make it use OSGBPB at some point.

Anyway, I thought it would be worth mentioning at least for being able to LOAD, with OSCLI implemented too it's staring to feel more real!

D

[BigEd]

My feeling is that we might be well served by a filing system which can access high memory - although of course that's no small thing. Even in 6502 mode, the '816 has access to 3 byte pointers, so moving data between an I/O device and a high memory area isn't a big deal.

BTW, I did wonder if using COP for OS calls would be a good idea. The 816 native application uses COP, and the interrupt handler provides translation to 6502 mode facilities.

It might even be that the Communicator's usage of COP is a good design to borrow from!

It might also be that the blitter OS already does some of this.

(Native code running in a high bank can't JSR FFEE, or JSL 00FFEE, as one won't get to the OS and the other won't come back. And neither would have the 816 in the right mode to run OS code anyway.)

[dominicbeesley]

Hi Ed

I've been thinking about these things on and off for a while now. Here a brain dump of some of my thinking... all subject to change and probably wrong

The shims thing is a start on what a native on emu os would need to do which is probably the best option for maintaining compatibility and is achievable without too much work.

There are pros and cons to using cop. In its favour its clean and tidy and can be succinct and expressive. Against its that one has to do more work (mucking about getting the addresses of the instruction to get the call number etc) so it's maybe slower in some circumstances.

The communicator API is a start possibly though unfortunately it uses a mixture of cops and long jumps for the API. I did consider trying to implement the relevant bits of the communicator api to get basic working but without better documentation it would have been a lot of work and an uphill struggle.

The other part of the communicator api that is worth a look is the idea of modules.

On the fs front is something I've been touring with for years but never quite started. I was thinking of doing just that to hosts/upursfs first as I use it during development all the time and there's plenty of room left in the rom.

What I've not worked out yet is how to manage addressing as we have 3 memory maps to consider. System (i.e bbc motherboard resources), Chip (i.e. our extended 65816 memory and for me other processors) and TUBE. There are also wrinkles that jgh had added for shadow screen access etc i think.

I was thinking of having a crack at something along the lines of:

With TUBE:
FFxxxxxx ... System/host
FExxxxxx ... chip
Everything else TUBE

But then there's a load of complication around the fact that not all fs's record the full 32bits of load/ execute address so there would be some shoehorning there and it would be nice to try and play nice with existing standards (official and defacto).

There are other wrinkles about how code is detected and its type etc etc

Perhaps I ought to just get on with it and stop worrying! I might make a prototype soon. I'm playing wit RobC's doom port and so I've been looking at hacking hosts for faster transfers anyway

I'm going to try and get BASIC fully functional (with the possible exception of TIME$) before I am tempted away though

D

[hoglet]

Dom,

FYI, I'm getting a minor build error with latest version of BASIC816:

Code: Select all

bas816new_natshims.asm(574): Error: Symbol 'OSRDCH' is undefined

I've fixed this locally, and it all seem to work fine.

Dave

[dominicbeesley]

Oops I must have messed up checking in. Is LOAD working OK for you. Its at slow here but functional

[hoglet]

Oops I must have messed up checking in. Is LOAD working OK for you. Its at slow here but functional

Yes, it seems to work.

I've only used it a couple of times though.

[Bobbi]

This is probably a stupid question. For the 65816 Tube copro, I assume we are using the 8 bit MOS code and either switching to emulation mode on each MOS call or at least switching to 8 bit m and 8 bit x. Is this a correct assumption? Does it need to be emulation mode, or is the MOS code happy running in native mode as long as m and x are 8 bit?

I am thinking vaguely about what it would take to port this to Apple IIgs. I guess the relevant bits of MOS (VDU drivers, file system drivers, graphics routines etc.) would need to be reimplemented on the GS and perhaps the memory layout is going to be different, but otherwise is seems straightforward in principle. Of course if we are writing a GS 'MOS' from scratch, could be 65816 native rather than emulation mode.

[BigEd]

We are flipping to emulation mode (which I call 6502 mode!)

In native mode with 8 bit index and memory enabled, things look rather like a 6502 but with notable exceptions: zero page accesses don't wrap, and TXS doesn't do what you expect. So some applications might work, or could be written do they did work, but arbitrary 6502 code could fail.

[Bobbi]

I knew about the wrapping of the stack being different, but not about TXS. Thanks

[BigEd]

Bruce's doc is very handy:
http://www.6502.org/tutorials/65c816opc ... l#APPENDIX:

[hoglet]

For the 65816 Tube copro...

One clarification.

Dominic's Blitter + 65816 isn't a Tube Co Pro; it replaces the Beeb's main 6502.

Same for Beeb816 (BigEd/Revaldhino/myself); it also replaces the Beeb's main 6502.

There is a 65816 Tube Co Pro (by John Kortink) called ReCo6502 / ReCo65816:
http://www.zeridajh.org/hardware/reco6502/index.htm
But it's out of production now and is closed source.

B-Em emulates ReCo65816, but very very slowly indeed:

Screenshot from 2020-12-05 19-29-04.png

PiTubeDirect doesn't (yet) have a 65816 Co Pro, but I might try and port the code over from B-Em if there is any interest. It might then be possible to add a debugger, which would help folk developing new software.

Dave

[dominicbeesley]

Give me a shout if you do Hoglet, I've also got a 65816 co-pro I made for myself about 5 years ago and I did some work on client code...no idea where it is but I should be able to find it.

To answer bobbi's question, I've not tried the MOS in native mode but I suspect it would be difficult to control, all the roms it might call would have to be vetted. Switching to emulation mode is the least of the worries really, in terms of speed/ease.

The current native entry points for the MOS calls all live in Bank0 and have a sequence like this:

Code: Select all

nat_OSWRCH:	
		php				; save flags			
		phb
		phd

		phk				; reset direct page register for MOSishness
		phk
		pld

		phk
		plb				; reset databank register TODO: is this the most efficient way?

		sec
		xce				; enter emulation mode

		jsr	OSWRCH

		clc
		xce				; back to native mode

		pld
		plb
		plp

		rtl

We need to preserve the current data bank then set the B and DP registers to 0 (where MOS expects them) then enter emu mode call and do the opposite on exit. The native MOS calls also all (at present) expect to be entered in M=8, X=8 mode. I could change that but it in BASIC that's the easiest and makes sense as none of the MOS calls would know what to do with a 16 bit register anyway!

Any calls that need to return flags have a bit of extra code on exit to get them out, so far just simple BCC/BCS to return carry.

I don't know anything about the Apple's operating system but I should think it would be possible to make suitable wrappers for most of the stuff. Graphics/VDU calls would need some quite involved work if they were to behave as normal.

[dominicbeesley]

SAVE now working...on Git.

So, for a tester, are there any good/large BASIC only games/demos that would test this out, perhaps something that would only run on a TUBE?

D

[BigEd]

This is a sort of test:

Code: Select all

   10 INPUT "SIZE";S
   20 DIM X%(S)
   30 FOR I%=1 TO S STEP 13
   40 X%(I%)=I%
   50 NEXT
   60 FOR I%=1 TO S STEP 13
   70 IF X%(I%)<>I% PRINT "OH NO",X%(I%),I%:STOP
   80 NEXT
   90 PRINT"FINE"

[dominicbeesley]

Latest BASIC up on Git, now has OPENIN/OUT/UP, PTR, EXT, BGET, BPUT etc so should be pretty close to complete with the exception of TIME$.

I've changed the prompt back to ">"

Thanks Ed, that should be a good test of memory. I'll try it later this evening if I get a chance.

What I'd really like is a huge adventure game or something that is written in BASIC and would only run on a larger MEMORY machine...probably not going to happen though!

D

[hoglet]

What I'd really like is a huge adventure game or something that is written in BASIC and would only run on a larger MEMORY machine...probably not going to happen though!

Sigma Experiment is written in BASIC and is ~20KB.
viewtopic.php?f=65&t=20402

Dave

[dominicbeesley]

Cool. I'll give it a try tomorrow.

D

[BigEd]

Thanks Ed, that should be a good test of memory. I'll try it later this evening if I get a chance.

What I'd really like is ... something that is written in BASIC and would only run on a larger MEMORY machine...probably not going to happen though!

I believe my program does that: the DIM will fail, if SIZE is too large, for any given machine. What I haven't done is carefully delineate values of SIZE which should distinguish a 16k or 32k machine, a machine with shadow memory (HIMEM at &8000), a second processor (PAGE at &400) or a second processor running HIBASIC, let alone a machine with more than 64k of RAM for data. Oh, and BAS128 is another case.

But at 4 bytes per increment of SIZE, we can say that SIZE of 17000 would not work on any existing 8 bit Basic. Size of 33000 will demonstrate that we span more than two 64k banks.

For the memory test aspect, it would be good to be probing for aliasing, and so the STEP values should probably be a power of two: 64 or 128 should do the job. I don't really expect memory to fail to be memory, but I do expect it to be possible to hit an alias of a lower memory location.

[dominicbeesley]

Thanks Ed, I've just given it a go and it looks like the communicator BASIC only allows up to 16382! So There must be a 64k limit on the size of DIM's (give or take room for the linked list pointer etc). This makes sense as it looks like there are 16 bit length markers.

I tried editing the program to make two arrays and testing them separately and it works as it should. This is a tad disappointing and would need a fair bit of work to fix up but not impossible.

D