6809 experiments

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Mon May 29, 2017 11:46 pm

Thanks lads,

As far as I know this is the first 6809 port of BBC Basic but I may be wrong....I started it ages ago when I first got my matchbox copro, then I got carried away and built a machine round it!

Hoglet, I will open source it at some point when it is in a more stable and tidied up state. At the moment neither the MOS nor BASIC are particularly useful and require a lot more work, I'm not averse to sharing but I'm making too many changes at the moment to really share with other devs...and I keep changing my mind on things like APIs and OS Calls. When it is settled I'll stick it up somewhere to share...I just don't want to get into the admin of version control, that would make it too much like my day job to be enjoyable. I've attached a snapshot, be warned it ain't pretty!

Elminster, wires, I like the wires! Seriously though I will be making a proper motherboard at some point, hopefully. Most of the wires are the "bus" most of the stragglers are the logic analyser which is not part of the system. There are a few bodge wires for things that I didn't think of when I made the first board. Like a take off for the Vsync interrupt!

D
Attachments
beeb6809-code-posted-20170530.zip
(179.31 KiB) Downloaded 15 times

roganjosh
Posts: 16
Joined: Sat Dec 10, 2016 6:51 pm

Re: 6809 experiments

Postby roganjosh » Tue May 30, 2017 8:42 am

It's a great credit to this group that the thread has got this far without anyone making a 'Port noICE Complaint'.

Alan

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Tue May 30, 2017 9:59 am

[-X

User avatar
BigEd
Posts: 1389
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: 6809 experiments

Postby BigEd » Tue May 30, 2017 10:11 am

Thanks for the snapshot!

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

Re: 6809 experiments

Postby jgharston » Tue May 30, 2017 1:10 pm

dominicbeesley wrote:As far as I know this is the first 6809 port of BBC Basic but I may be wrong....I started it ages ago when I first got my matchbox copro, then I got carried away and built a machine round it!

Sort-of how I wrote PDP11 BASIC. I wrote an assembler and needed a project to assemble with it. Naturally, I had to then write an emulator to test the assembled code. ;)

You've got the code type set to '6502 BASIC'.

Code: Select all

         FCB   $60            ;  ROM type=Lang+6502 BASIC
It should be $63 for 'Lang+6809'.

I'm working out of a hotel for the next few days, so will be looking for something to do to keep my brain working. I'll probably get around to checking the 'Check with JGH' bits in the code.

Code: Select all

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

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Tue May 30, 2017 2:15 pm

Thanks for that - one of my questions I forgot to ask: how to indicate the ROM target processor processor, answered!

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm

Re: 6809 experiments

Postby B3_B3_B3 » Fri Jun 02, 2017 8:25 pm

Has anyone written a 6502 machine-code interpreter in 6809 assembly: then you could only hand convert speed critical stuff:
it could be entered with a jsr (like Woz's Sweet16 he used in Apple Integer BASIC).

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Tue Jun 06, 2017 5:13 pm

You'd need to store the interpreter and its variables somewhere so probably not that useful for ROM code.

Another milestone achieved today. My first "real" BASIC program. It' is still a bit limited (not division, uses GOTOs not PROCs) but it works and compares well for speed on BeebEm (137s for BeebEm, 1178s for 6809). I had to get a large chunk of the floating point stuff up and running to get this far and 75% of the evaluator. The floating point multiply routine may come under scrutiny tomorrow as it is a simplistic translation of the 6502 routine, with a bit of thought I should be able to get the 6809's MUL instruction into play and speed things up significantly....

D

20170606_172940-s.jpg
first successful run


20170606_180352-s.jpg
larger soak test

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Wed Jun 07, 2017 11:15 am

That should be 118s for the 6809.

Here's all the code zipped up. I'm going to split the .asm files up into smaller logical chunks for easier change tracking and navigation. I'll look at hosting it in an SVN repository (I just can't get on with GitHub).

D
Attachments
beeb6809-code-20170607-posted.zip
(873.3 KiB) Downloaded 10 times

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Thu Jun 08, 2017 9:24 am

I couldn't sleep last night so stayed up late, now got a floating point multiply that uses the 6809's MUL instruction and the Mandelbrot set test is down to 106s, I could probably improve on that but would rather get on with sorting some more BBC Basic stuff out and get it tested on the Matchbox.

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

Re: 6809 experiments

Postby jgharston » Thu Jun 08, 2017 5:57 pm

Who was the chap at Cambridge ABUG coding with a 6809 CoPro, who I helped write functions to read the palette? I've done some checking comparing the Flex disks and can report back the findings.

Code: Select all

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

B3_B3_B3
Posts: 67
Joined: Sat Apr 08, 2017 9:42 pm

Re: 6809 experiments

Postby B3_B3_B3 » Fri Jun 09, 2017 9:37 am

dominicbeesley wrote:You'd need to store the interpreter and its variables somewhere so probably not that useful for ROM code.......

I had assumed it would go in the OS ROM and use some spare/little used OS workspace*, so usable from any code(except interrupts maybe?)


* Acorn did seem did to preallocate the lower OS workspace RAM to unfitted(and perhaps obscure) hardware quite a bit: perhaps due to 6502 limitations?

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Fri Jun 09, 2017 12:28 pm

You have a go then :D , if you could get something working on the matchbox first maybe?

I had a marathon session last night in between watching the election and being puked on by my daughter.

It turns out my Mandelbrot set test is faster than a Beeb but about the same as a Master. A little faster though if I comment out some of the interrupt code - so I suspect I've got something wrong in the MOS rom handling sound which seems to be stealing a lot of cycles.

Does anyone know, Should the sound system, like the keyboard, go to sleep or does it always check and physically silence each channel when there's nothing to do. I've had a look and I can't see how it wouldn't.

D

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Mon Jun 12, 2017 12:30 pm

Update: I've now got more BBC BASIC done.

Most basic arithmetic integer and FP is working (missing some things like ^ that I've not got round to) No trig functions yet
FN/PROCs without params 1st cut (I'm about to start on parameters)
FOR/NEXT loops now work with integer and real control variables
PRINTING works though @% is not setup on initialisation so weird formatting is the order of the day until it is set to 2314, not & operator isn't working yet but ?,!,$ indirection operators are
more graceful death when unfinished code is encountered (registers dumped and the name of the offending BASIC command/function printed)

This works on my own hardware and seems ok on the Matchbox.

To try it:

*LOAD 6809BAS 8000
*GO 8000

That should get you into BASIC then you can LOAD/CHAIN programs....still a long way to go but getting closer.

JGH, I tried it in 6809Em but I just get the first part of the startup message I added (prints the rom number in hex-which is meaningless!) but then I get the screen filled with [1FD] followed by a lot of [M24:F811]s then sometimes a BRK message (such as "No such FN/PROC at line 0) then a register dump...Could it be me calling OSBYTE or something that's not implemented fully in the emulator?
Attachments
beeb6809-code-posted-20170612.zip
source code for 6809 BASIC ROM
(357.42 KiB) Downloaded 7 times
6809BAS-mb-posted-20170612.zip
binary loadable at 8000 on matchbox
(9.14 KiB) Downloaded 6 times

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

Re: 6809 experiments

Postby jgharston » Mon Jun 12, 2017 6:12 pm

dominicbeesley wrote:JGH, I tried it in 6809Em but I just get the first part of the startup message I added (prints the rom number in hex-which is meaningless!) but then I get the screen filled with [1FD] followed by a lot of [M24:F811]s then sometimes a BRK message (such as "No such FN/PROC at line 0) then a register dump...Could it be me calling OSBYTE or something that's not implemented fully in the emulator?

That's probably an unimplemented instruction somewhere. [1FD] is an unimplemented instruction at &01FD, [M24:F811] is addressing mode 24 used in an instruction at &F811. That's in the MOS, so is probably a result of jumping off into the dark from somewhere else. Doing *debug 1 before starting the 6809 execution will turn on a debug display.

Edit: It seems to work here, tho' memory is not initialised on startup (I think you've mentioned that):
Image

Code: Select all

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

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: 6809 experiments

Postby hoglet » Mon Jun 12, 2017 7:18 pm

Dominic,

Do you have a PuTubeDirect?

It should run on the 6809 Co Pro in this.

And you might find the integrated debugger very helpful. It works just like the debugger in B-Em.

Dave

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Tue Jun 13, 2017 10:45 am

Thanks lads,

JGH, I just downloaded the latest (april?) 6809Em and it works ok in there so it must not like something in the old version?

Yes, memory is left deliberately uninitialized at the moment to assist post-mortem debugging.

Hoglet, I've not tried it yet (I have been concentrating on the real hardware), I will have to dig out some level shifters at some point and rig one up. The debugger sounds interesting. I'm using NoIce at the moment though which works very well...

When (if) I finish this project I will be looking at adding the 6309 instructions to a 6809 core....or possibly writing one from scratch to try and home my (almost nonexistent) vhdl skills...I might kick-start that by looking at the pi tube thing and hacking at the 6x09 emulation? Did you include 6309 emulation in the PiTube thing - it seems to be there in the code

Cheers

D

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

Re: 6809 experiments

Postby jgharston » Wed Jun 14, 2017 9:22 pm

Some notes.

BBC BASIC is defined to be little-endian, regardless of the endian-ness of the CPU it's running on. Specifically, for the right size numbers, ?addr=!addr=|addr.

eg, doing !16384=0:?16384=1:PRINT !16384 must print 1.

TUBE_MOS_ERRPTR EQU $FF82 ; TODO: Ask JGH about this!
On the 6809 environment the BRK handler is entered with X pointing to the error message, so you should do:
HandleBRK
STX ZP_ERRPTR
LDB #$FF
STB ZP_OPT
...
and then use ZP_ERRPTR to reference the error message. You should make your 6809 BeebMOS BRK dispatcher do the same, pass to the BRKV owner with X=>error block.

JMP OSWRCH ; TODO - ask JGH about vectors on 6809
The 6502 BASIC jumps via WRCHV just to shave 3(?) cycles off the OSWRCH call. BASIC shouldn't ""know"" anything about vectors, it should really be a direct API call, so yes JMP OSWRCH is correct there.

FCB "(C) 2017 Dossytronics" ; ROM copyright string
Should be no space between (C) and year, to make displaying line up neatly.

; LDA #$84
; JSR OSBYTE ; Read top of memory, set HIMEM
LDX #$3000 ; DB: Hardcode to $3000 - change when relocatable
STX ZP_HIMEM
; DECA
; JSR OSBYTE
; STY ZP_PAGE_H ; Read bottom of memory, set PAGE
LDA #$0E
STA ZP_PAGE_H ; DB: Hardcode to $E00 - osbyte not working and not what we want anyway

The construction I use in my source is:
IF MEMBOT=0
LDA #$84
JSR OSBYTE ; Read top of memory, set HIMEM
ELSE
LDX #MEMBOT ; DB: Hardcode to $3000 - change when relocatable
ENDIF
STX ZP_HIMEM
IF MEMTOP=0
DECA
JSR OSBYTE
ELSE
LDY #MEMTOP DIV 256
ENDIF
STY ZP_PAGE_H ; Read bottom of memory, set PAGE
to make it easier to tweek in the defines at the top of the source - see the Atom/System builds for BASIC II.

The stuff at immediate_loop is specific to 6502 BASIC to implement *BASIC @nn,nn to pass text from the EDIT ROM. It's not needed for non-6502 BASIC, and similarly you can get rid of the code at callOSWORD5INT_WA. If you do want to implement command line parameters (eg *BASIC09 filename otherstuff) you would do it differently anyway. And the standard way of passing a command line to a BASIC program is to do so via CHAIN and the string buffer, not via the *command pointer.

Also, the label immediate_loop at that location is a bit misleading, as it's at the point where a NEW should be done just before entering the actual immediate loop. immedPrompt is where almost all jumps to immediate_loop should be jumping to, immediate_loop should probably be called start_main with the code at 8000 being the only jump to it.

It's usual to have the token table starting in the first 1K of the code, normally just after 'Language startup' as it makes it easier for programs to look for it by looking for the &80,"AND" token and miminimising the chance of running into a &80,&41,&4E,&44 sequence before actually getting to the token table.

Edt: the tweeking to the powers-of-ten table have resulted in the code transfer address becoming &01008000 at High word ($0000) overlaps next table where a zero word has been replaced with a zero byte, causing 6809Em to fall over. You need to stick an extra FCB $00 in.

'Nother edit:
You find out where BRKV is call calling INITERR, so you need:
JSR INITERR ; Set up error handler vectors
LDD HandleBRK, PCR
STD ,X ; Claim BRKV
ANDCC #$AF ; enable IRQ, FIRQ
LBRA startup_main ; Jump to NEW and to immediate prompt

...I'm going to see if my 6809 assember will swallow your code. :)

Code: Select all

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

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

Re: 6809 experiments

Postby jgharston » Wed Jun 14, 2017 10:18 pm

Technical notes on the 6809/BBCMOS environment: http://mdfs.net/Docs/Books/6809CoPro/Technical

Code: Select all

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

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Thu Jun 15, 2017 10:37 am

Thanks JGH, very good of you to spend time looking at it. I've been ploughing away but I don't have insights like the token table thing.

I took a conscious decision to code for big-endian as it speeds things up a fair amount - I take your point though that it is likely to break things. I will have to look at unpicking it all. I'd not realised it was in the spec, is there a copy of that anywhere?

I'll probably finish off getting as many functions working before going back and fixing the big endian thing - it shouldn't be too difficult but I need to be in the right mood to go back at the moment I'm on the march!

What are your thoughts on breaking some other "compatibilities" by redefining some of the zero-page registers i.e. ZP_BAS_SP is not used (at the moment) for the stack pointer, I'm about to sort out ZP_TXTPTR, ZP_TXTPTR2 and the two text pointer "offset" registers as they are not very helpful to the 6809. The usefulness of the secondary pointer is not that clear other than when scanning arguments in PROCs/FNs where there are two pointers on the go, but even there a simple save area or stacking the pointer would do the trick...

The base-line for this was your Basic4.src, I've no idea when or why I moved the token table....it's easy enough to put back. What programs would try to use that? would they need the function pointers putting back in two high byte / low byte tables, that would be more of an issue.

on the BRKV thing (and other vectors) is there a reason you put them where you did and not in page 2? I'll need compile time switches as the MOS I'm building will have the vectors (and other such things) in their normal host locations....many of them will, however, be big-endian. I'll get into that later though!

Thanks for the other pointers. Attached is the latest version, also attached my edited version of asm6809 (add error and warn pseduo ops) it's not a bad assembler and seems to be actively updated.

[I've got notes to change many of the labels (that is the top of the list). I've left some of the misleading ones there for now as it made comparing code easier]

I finally got the ClockSP program to run up to the point of the trig functions. It reports ~2.15MHz for the first few tests (compared to a BBC B) which isn't that great but hopefully can be improved upon when I've got things working - I suspect my MOS interrupt handler is eating a good proportion of the machine cycles.

D

Added:
- string comparisons
- compare ints to reals
- fixed VDU |
- FN/PROCs with arguments
- STRING$
- REPEAT / UNTIL
- eval &HEX numbers
Know problems
bee string concatenation broken "0" + STR$1234 gives "01111"
Attachments
asm6809-2.9.1-dom-warn-error.zip
(810.93 KiB) Downloaded 4 times
beeb6809-code-posted-20170615.zip
(362.46 KiB) Downloaded 5 times

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Thu Jun 15, 2017 11:40 am

Quick question, where does MEMBOT get defined, do I just assume 0 for the matchbox build?

D

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Thu Jun 15, 2017 12:09 pm

You had me going there

LDD HandleBRK, PCR doesn't work it needs to be an LEA* (LDD loads contents of HandleBRK)....that had me going for 10 minutes!

I've addressed most of your points (not big endian stuff yet) I'll test and resend later if I get a chance. I need to finish rebuilding my gearbox and I've just been ordered to vacuum the stairs. It's great taking time off work.

D

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Thu Jun 15, 2017 1:01 pm

Here's latest patch and binary.

This fixes the break handler and starts with PAGE and HIMEM at &800/&8000 on BeebEm (not tried it yet on matchbox).

Also fixed: PAGE, TOP, ADVAL as functions

D
Attachments
beeb6809-code-20170615-patch-r36.zip
(11.74 KiB) Downloaded 6 times

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Thu Jun 22, 2017 8:44 pm

Steady progress, BASIC is now working with PROCs, FNs and some basic trig (SIN, COS, SQR). JGH has been giving me some good guidance and it looks like I need to go back and undo some of my more ambitious code changes ( changing integer arithmetic in BASIC to big-endian)

I've now taken a short break from BASIC to do a bit of MOS level coding for my 6809 hardware because I want some pictures.

So far I've got CLG and PLOT 4 and PLOT 69 working...rest to follow, hopefully quickly.

D
Attachments
20170622_213436-s.jpg

User avatar
Rich Talbot-Watkins
Posts: 1078
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: 6809 experiments

Postby Rich Talbot-Watkins » Fri Jun 23, 2017 7:22 am

If the 6809 is big endian, I'd say you should keep your changes as you'll get better performance (and probably smaller code) that way. Where the endianness is 'visible', e.g. with the ! operator, make a point of converting to little endian before writing memory (and vice versa when reading). BBC BASIC, as a 'platform', shouldn't care one way or the other about its implementation, as long as visible behaviour is consistent. Trying to fight the CPU's natural functionality just sounds like a bad thing to me. There's no way to get the address of an integer variable, for example, so don't worry about storing them in a little endian form. In the case of CALL with a parameter list, this is an entirely platform-specific thing by nature, so I think it even makes sense to expose integers in a big-endian form here (so that 6809 code can natively manipulate them).

(Aside: I hate that endianness is a 'thing', and I never even understood why big endian made sense enough to implement it!)

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: 6809 experiments

Postby Elminster » Fri Jun 23, 2017 8:32 am

Ah the joys of converting commercial systems software from Big to little Endian. Least on SPARC is now supports some little endian addressing.

Convert new 6809 BBC code to SPARC next .........

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Fri Jun 23, 2017 9:58 am

Thanks lads,

RTW, that was my thinking originally but I'm now convinced the other way. There are enough BASIC programs that expect

Code: Select all

x%!=&12345689
A%=?x%


to give A%==&89 that it's worth the effort. Also, I've been looking and it needn't be a big loss in terms of space and speed.

32bit add in big-endian

Code: Select all

                              C   B
   LDD      ZP_INTA + 2         5   2
   ADDD   ZP_INTB + 2         6   2
   STD      ZP_INTA + 2         5   2
   LDD      ZP_INTA             5   2
   ADCB      ZP_INTB + 1         4   2
   ADCA      ZP_INTB + 0         4   2
   STD      ZP_INTA             5   2
                                34   14

32 bit add in little-endian

Code: Select all

                             C   B
   LDD      ZP_INTA + 2         5   2
   ADCB     ZP_INTB + 1         4   2
   ADCA     ZP_INTB + 0         4   2
   STD      ZP_INTA + 2         5   2
   LDD      ZP_INTA             5   2
   ADCB      ZP_INTB + 1        4   2
   ADCA      ZP_INTB + 0        4   2
   STD      ZP_INTA             5   2
                            36   16


So a 14% inscrease in size and 5% increase in cycles. However there are only so many places where there is arithmetic like this and after spending a few hours honing some of the integer multiply and divide routines I have come to the realisation that any improvements in those is swamped by the amount of time doing the actual interpretation and expression evaluation. I will be doing some optimisations there at some point as the lack of lda (ZP),Y on the 6809 has led to me using LDA ,Y+ in a lot of places then quite a few LEAY -1,Y to go back, there's probably plenty of places where I can change that to LDA ,Y and LEAY 1,Y where a test is more than likely to fail etc.

I'm still feeling my way with the 6809 and haven't worked out all the speed up tricks and hacks, there aren't that many sources on the net of tips and tricks for the 6809 that I've found...

I will, when I get round to making the changes, make them compile time options for BASIC and then we can actually benchmark the two.

When I actually get into proper optimisation mode I may change my mind again....

Elminster, Sparc....interesting, maybe later...

Currently I've got my nose in the MOS PLOT 5, draw a line routine and working that out....unfortunately this is one area where the OS dissasembly I have is not very helpful labelling line draw as "do some calculations"...

D

User avatar
Rich Talbot-Watkins
Posts: 1078
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: 6809 experiments

Postby Rich Talbot-Watkins » Fri Jun 23, 2017 10:16 am

Yes, I agree you need to preserve the behaviour of the ! operator (which is why I suggested doing an endian swap when reading/writing memory with the ! operator, but internally keeping everything big endian). Obviously you have a better idea of how this will work for you, but I can't see a good reason to fight the CPU and end up with a bigger, slower program, just to handle things as little endian internally. It seems a shame to ignore the 16-bit features over something which is an implementation detail.

User avatar
BigEd
Posts: 1389
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: 6809 experiments

Postby BigEd » Fri Jun 23, 2017 10:33 am

(Did the 6809's multiply instruction help at all, anywhere?)

dominicbeesley
Posts: 384
Joined: Tue Apr 30, 2013 11:16 am

Re: 6809 experiments

Postby dominicbeesley » Fri Jun 23, 2017 6:41 pm

RTW, the good reason is that all of the code that deals with variables would need overhauling and extra tests on every variable access to decide whether its a pointer to a big or little endian int32. [BASIC, internally once its parsed the ! or var% carries round a pointer and a type code, another new type code would need to be added and extra tests made for all int save/loads this would likely slow things down and add more code, I suspect by more than any potential benefits, which are, as pointed out in the code sample minimal. It's not really fighting the CPU, where the 16bittedness really show is in address pointers and I'm translating all of those!]. I will look at it but suspect its will be flogging a dead horse.

The MUL instruction has been useful. The integer multiply in BASIC is shorter and faster using MUL, I've not done much optimisation so there is probably more to be had from it. It has also been useful in the MOS for graphics routines and other address calculations.

So far I've been following the 6502 code fairly closely and translating. Some of the more complex routines, especially PLOT/DRAW that I'm looking at today, could probably benefit from a ground-up rewrite to better use the facilities available.

D


Return to “hardware”

Who is online

Users browsing this forum: No registered users and 13 guests