6809 experiments

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
joachim
Posts: 95
Joined: Wed Jun 21, 2006 1:20 am

Re: 6809 experiments

Postby joachim » Fri Jun 23, 2017 7:17 pm

Ha, you people are in violent agreement. With RTW's proposal there is no code slowdown because all variables are big-endian all the time. The !x% problem that was pointed out upthread can *only* happen when using the ! operator, so you just implement the ! operator in a way that reverses the bytes. No other code changes are required, so only the ! operator is slower.

It'll look weird if you watch the BASIC internals, because when you execute !x% = A% you'll find that the left hand side and the right hand side are stored in different integer formats. But actually executing BASIC, including manipulation of ?, ! and $ operators, will work in the (little-endian) documented way.

(I mean, of course some things still won't work, but only implementation-specific stuff like expecting (&FFFF AND !6) to be a synonym for HIMEM or expecting !&404 to be a synonym for A%.)
Last edited by joachim on Fri Jun 23, 2017 11:23 pm, edited 1 time in total.

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

Re: 6809 experiments

Postby dominicbeesley » Fri Jun 23, 2017 10:28 pm

Ok, be my guest, you show me how to implement that without using either more code or slower code. I'm genuinely interested.

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

Re: 6809 experiments

Postby jgharston » Fri Jun 23, 2017 11:13 pm

dominicbeesley wrote:There are enough BASIC programs that expect

Code: Select all

x%!=&12345689
A%=?x%
...
And it's defined to be little-endian in the closest thing we've got to a language specification, The User Guide p410:
M=&2000
!M=&12345678
would set location
&2000=&78
&2001=&56
&2002=&34
&2003=&12

Code: Select all

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

joachim
Posts: 95
Joined: Wed Jun 21, 2006 1:20 am

Re: 6809 experiments

Postby joachim » Fri Jun 23, 2017 11:51 pm

dominicbeesley wrote:Ok, be my guest, you show me how to implement that without using either more code or slower code. I'm genuinely interested.

The implementation I'm talking about (we can discuss whether it is correct and whether it is slow, but there's no need for there to be ambiguity about what the implementation is) is:

  • when interpreting a literal ! operator that was typed into BASIC, either as a peek (PRINT !x%) or a poke (!x%=&12345), reverse the bytes. This is the one operation that will be slower. My previous post implied that nothing at all was slower, so apologies if that was what caused confusion. So for example, the algorithm for interpreting "!x%=&12345" would be:
    • parse "&12345" into a native (big-endian) dword
    • look up where x% is stored (it is stored as a native (big-endian) dword), load its lower 16 bits into index register
    • store the value of "&12345" into the location pointed to by the index register *reversing order of bytes* (this step, only, is slower due to endianness). So &45 ends up in the first byte.
  • when interpreting anything except a literal ! operator, use the fast, big-endian code you wrote originally.

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

Re: 6809 experiments

Postby dominicbeesley » Sat Jun 24, 2017 12:37 am

There is no confusion at this end. Merely a statement of the fact that it is not as simple as you propose. A lot of work would need to be done to redo the way BASIC handles evaluation, assignment, parsing.

For instance, when BASIC evaluates an expression such as

!&3000=23*56+200

The first thing it does is evaluate !&3000 and stores in a VARIABLE POINTER &3000 and VARIABLE TYPE &04 (int) it then goes off into the evaluator to do the arithmetic and stores the result where the variable pointer says, when it is doing the store it no longer remembers about ! just where to store the result and the type of the result (int)

A%=23*56+200

It works out that we're wanting a single char integer var, sets VARIABLE POINTER to &404 and VARIABLE TYPE &04 goes off to evaluater ... stores where the pointer says, again no longer knows or cares what type of variable just its address and type

AAAA%=23*56+200

finds or creates dynamic variable sets VARIABLE POINTER to point at dynamic variable location and VARIABLE TYPE &04 .... same

If a store to another type i.e.,

BB=23*56+200
find BB, set VARIABLE pointer to point at BB set VARIABLE type &05, call evaluator, check VAR TYPE, it isn't same as type returned by evaluator, do conversion real to int, store at address

if we have ! stored differently to A% and AAAA% then a new variable type would have to be added (say 03) that would mean all the code where the variable types are tested would need to be changed to cater for the new type (there are a lot) and conversion / store / load routines added to do the endianness swap. I suspect that that would be, in general, add more overhead than would be gained in having things in big-endian order. There are a lot of optimisations that would also be lost i.e. there tend to be things like

In parts of the system where it is certain that a number is being dealt with then there are currently only 3 options (0 == byte, 4 == int, 5 == real), these are tested easily with one CMPA #4 then BCS, BCC, BEQ to deal with each, with another option being added this would mean each of these tests would need at least one extra instruction and branch. As these occur frequently (unlike 32/16 bit arithmetic) they will add more of an overhead than the measly 2 bytes / cycles that are saved in the occassional add / subtract.

The 6809 can only do simple adds and subtracts with no Carry in on 16bit numbers so the advantage of loading bytes in the correct order is minimal in 32 bit calculations as outlined in my previous post.

Before ordering me to do things in a certain way I suggest you spend some time going through the BASIC code. It is not as simple as you seem to think.

joachim
Posts: 95
Joined: Wed Jun 21, 2006 1:20 am

Re: 6809 experiments

Postby joachim » Sat Jun 24, 2017 4:44 am

Thanks, this was a really good explanation. So the specific rebuttal to my argument "this can't make things slower" is that since I wanted to split the ! case away from the usual integer case, I had to add an extra test-and-branch which slows down the integer code even if the branch isn't taken.

(If I had read the BASIC code, I would have learnt that ! shared code with integer types, but I would still have forgotten that I was back in 1980 and extra branches aren't free and code unrolling isn't free either.)

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

Re: 6809 experiments

Postby dominicbeesley » Sat Jun 24, 2017 8:33 am

That's pretty much it. It's easy to forget just how efficiently these things are coded when used to more modern approaches. That's my point though. A test and branch is a relatively expensive operation (five or more cyclyes) and there are quite a few places where that would need to be added.

What I miggt do is make an all bigendian and all littleendian version and compare the speed. If there is a big difference in speed, which is doubtful, I'll look into it further. However, getting it all working is the first task!

I'm still working through the graphics routines in the mos Rom....so far I have it drawing dots in the roughly the right direction

D

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

Re: 6809 experiments

Postby B3_B3_B3 » Sat Jul 08, 2017 9:00 pm

I think I remember a recently linked Sophie Wilson video mentioned that the 6502 was little endian because, in combination with its instruction pipelining, it allowed an 8 bit ALU to do 16 bit address arithmetic with no speed cost.

also here https://softwareengineering.stackexchange.com/questions/95556/what-is-the-advantage-of-little-endian-format/95854#95854

Presumably the 6809 has a 16bit ALU.

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

Re: 6809 experiments

Postby dominicbeesley » Sat Jul 08, 2017 11:48 pm

It does have a 16 bit ALU yes, I'm actually using a 6309 which has a 32bit ALU.

The big-endianness of the 6809 is probably its greatest drawback, for this project at least. Not so much from any quasi-religious standpoint, just that all the 6502 code is little endian. The next biggest pain is that carry operates in the opposite sense to 6502 for CMP and SBC and tends to get cleared by some instructions (along with V) so some of the MOS and BASIC code needs to save the flags more often.

If Sophie says its true then I'm not gonna argue. I never could get excited about which was "better" little or big endian...but in my day job it has occasionally been a real pain that both exist.

The 6809 does seem to have a lot of "dead" cycles I'm not sure how much of that is down to endianness.

When I've got a bit further with the MOS/BASIC ports then I'll be doing some experiments on how much faster/slower, bigger/smaller, things are with 6502/6809/6309. For now my interrupt handling and sound routines are rather inefficient and they seem to be eating a lot of my cycles...

I've started designing my first full motherboard...trying to resist feature creep! I'm still not sure whether to include a floppy controller on board...I've not used a floppy disc for years...maybe a built in HDC...no stop, stop, what about an ANSI text mode, ooh econet, no! ethernet, USB, MMC, filter coffee machine, no a built in paper tape reader...

D

User avatar
1024MAK
Posts: 6684
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: 6809 experiments

Postby 1024MAK » Sun Jul 09, 2017 10:37 am

Of the popular 1970s CPUs, only the 68xx (and later 68xxx) went for big-endianness.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

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

Re: 6809 experiments

Postby dominicbeesley » Wed Jul 12, 2017 6:56 pm

Yes, I suspect big-endian was a "differentiator" for Motorola (To a marketing person a differentiator sounds like a wonderful opportunity, to a programmer it's sounds like a pain in the bum!)

Now, some questions on "validity" of my project. This uses quite a number of modern components, be it for cost or availability. However I am trying not to "cheat". Where "cheating" would be doing something that would be impossible or nigh on impossible in 1987/88. So I _am_ using (modernish) CPLDs but I don't think I'm doing anything that would be outside the realms of a custom ASIC of that era. I _am_ using SMD but only due to cost/ease of construction. I am using a modern SRAM which is my biggest cheat, I just can't be fussed sourcing, soldering, messing with DRAMs....Comments?

Where I am cheating of course is using modern development tools and Logic Analysers....

Would something like the InMos G171 RAMDAC have been available before the VGA card was released? An old 8-bit VGA card fell out of my junk box onto my head earlier today and I got to pondering the RAMDAC and whether I should use that...

D

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

Re: 6809 experiments

Postby BigEd » Wed Jul 12, 2017 9:30 pm

RAMDAC is fine.
CPLD is fine.
And SRAM is fine.
Go!

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

Re: 6809 experiments

Postby Elminster » Wed Jul 12, 2017 9:39 pm

dominicbeesley wrote: I am using a modern SRAM which is my biggest cheat, I just can't be fussed sourcing, soldering, messing with DRAMs....Comments?

Where I am cheating of course is using modern development tools and Logic Analysers....


I don't think it is cheating but then I own a gas barbecue.

I think if you can buy the parts New then use same parts, otherwise use equiv as loads of junk fake parts on eBay ( he says waiting for his knock off logic Analyzer to turn up).

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

Re: 6809 experiments

Postby dominicbeesley » Thu Jul 13, 2017 1:38 am

I've been working on my next generation hardware and taken a break to actually start trying out my ideas in VHDL to sanity check them. It's a good thing I did as there were a few assumptions I'd made that wouldn't have worked out in the real hardware!

I've decided to have two CPLDs a VIDC (which does the video ULA stuff) and a MEMC (memory controller).

I've come up with a rough scheme, well two schemes (see below). A "linear" scheme where there is a 16 register mmu that works a bit like the MMU in a CoCo 3 and should be capable of running OS-9/6809. And a BBC mode that works kind of like the Master but with the ability to swap out both the MOS and SWROM for memory but any interrupt or OSCALL (to F000 onwards) will cause the MOS rom to reappear at C000 with a scheme for the OS to be able to restore the user memory at the end of the interrupt or OS call by executing an RTI which restores the mapping....

I'd be grateful if you could all have a look to see if there are any holes in my idea! I've got this roughly working in a VHDL testbench tonight.

Code: Select all

PHSYICAL MEMORY MAP, used in memory mapping hardware


$00 0000        +-----------------------+
                | RAM 0 (512k)          |
$08 0000        +=======================+
                | RAM 1 (512k battery)  |
$10 0000        +=======================+
                | RAM 2 (512k opt)      |
$18 0000        +=======================+
                | ROM 0                 |
$18 4000        +=======================+
                | ROM 1                 |
$18 8000        +=======================+
                | ROM 2                 |
$18 C000        +=======================+
                | ROM 3                 |
                +=======================+
                ...
$1B 0000        +=======================+
                | ROM E                 |
$1B C000        +=======================+
                | ROM F                 |
$1C 0000        +=======================+
                | unused                |
$1F E000        +=======================+
                | unused                |
$1F FC00        +=======================+
                | I/O registers         |
$1F FF00        +=======================+
                | unused                |
$20 0000        +=======================+


==============================================================================
LOGICAL MAPS - In Linear mode
==============================================================================

MEMCMODE        = b'xxxxxxM1
                M =     0 for SYS  map (MMUMAP0..7)
                        1 for USER map (MMUMAP8..15)
                (default $00)

BANKS are 64k
CHUNKS are 8k

There is a USER map and a SYS map, reset, interrupts etc cause the map to
switch to SYS map (i.e. reset M bit(s) above).

SYSLOC          (SYS ROM)
SYSLOC2         (LOGIC TO PHYS MAP AT $C000) <-- this is the one used to do
SYSLOC3         (SAVED SYSLOC2)                 the actual mapping!
[       
-       writing to SYSLOC sets SYSLOC2, SYSLOC3)
-       writing to SYSLOC2 changes map and SYSLOC3)
-       interrupts and accesses to $FFXX reset SYSLOC2
        to SYSLOC but preserves SYSLOC3
-       RTI copies SYSLOC3 to SYSLOC2

SYSLOC  = F (normal SYSROM)
SYSLOC2 = 3 (user routines)
       
        SEI
        LDA     #3
        STA     MOSLOC
        CLI
        ... program using $C000 = ROM 3

        IRQ / SWI / OS CALL enter       MOSLOC2 -> MOSLOC
        LDA     MOSLOC3
        PSHS    A               ; .. save mosloc
        ... interupt call processing ...
        ... possibly reenable interrupts?
        ... possibly reset MOSLOC2
        PULS    A
        STA     MOSLOC3
        RTI                     ; copies MOSLOC3 -> MOSLOC2 on LIC
]

]

SYS (MAP 0)
$0000           +-----------------------+
                | MMUMAP 0              |
$2000           +-----------------------+
                | MMUMAP 1              |
$4000           +-----------------------+
                | MMUMAP 2              |
$6000           +-----------------------+
                | MMUMAP 3              |
$8000           +-----------------------+
                | MMUMAP 4              |
$A000           +-----------------------+
                | MMUMAP 5              |
$C000           +-----------------------+
                | MMUMAP 6              |
$E000           +-----------------------+
                |                       |
                | SYSROM                |
                |                       |
                |                       |
                |       vectors at F7FX |
$FC00           +-----------------------+
                | I/O  FRED             |
$FD00           +-----------------------+
                | I/O  JIM              |
$FE00           +-----------------------+
                | I/O  SHEILA           |
$FF00           +-----------------------+
                | SYSROM                |               
                +-----------------------+

USER (MAP 1)
$0000           +-----------------------+
                | MMUMAP 8              |
$2000           +-----------------------+
                | MMUMAP 9              |
$4000           +-----------------------+
                | MMUMAP A              |
$6000           +-----------------------+
                | MMUMAP B              |
$8000           +-----------------------+
                | MMUMAP C              |
$A000           +-----------------------+
                | MMUMAP D              |
$C000           +-----------------------+
                | MMUMAP E              |
$E000           +-----------------------+
                | MMUMAP F              |
                +-----------------------+


==============================================================================
LOGICAL MAPS - In BBC banked mode
==============================================================================

RAM  BANKS ARE 64K in size
RAM  CHUNKS ARE 4K in size
ROMS ARE 16K in size

MEMCMODE        = b'xxxxxxx0
                ( default at boot $00 )

MMUMAP [0..7] contains 8 bit pointers to 4k chunks in
RAM 0..1 only, these map to first 32k
                ( default contents = 0 to 15 )

SHADOW          = b'IxRRxxDD
                = I, when set causes an IRQ, read SHADOW to clear
                  RR when set causes instructions at C000-DFFF to
                  read memory in bank RR
                  DD display memory at bank DD

                  (default = $00)


ROMLOC          = $00..$0F maps SWROM to ROM 0..F
                = $10..$1F maps SWROM to RAM 1 $08 0000-$0C 0000 in 16k blocks
                = $40..$FF maps SWROM to RAM $00 0000 - $17 FFFF in 8k blocks
                  (access all RAM)

                  (default = $00)

(NOTE: MOS only recognises ROMS at $00-$1F!)


MOSLOC          (MOS ROM)
MOSLOC2         (LOGIC TO PHYS MAP AT $C000)
MOSLOC3         (SAVED MOSLOC2)

                (default = $00)

[       
-       MOSLOC1..3 are interpreted as ROMLOC
-       writing to MOS loc sets MOSLOC2, MOSLOC3)
-       writing to MOSLOC2 changes map and MOSLOC3)
-       interrupts and accesses to $FFXX reset MOSLOC2
        to MOSLOC but preserves MOSLOC3
-       RTI copies MOSLOC3 to MOSLOC2

MOSLOC  = 0 (normal MOS ROM)
MOSLOC2 = 3 (user routines)
       
        SEI
        LDA     #3
        STA     MOSLOC
        CLI
        ... program using $C000 = ROM 3

        IRQ / SWI / OS CALL enter       MOSLOC2 -> MOSLOC
        LDA     MOSLOC3
        PSHS    A               ; .. save mosloc
        ... interupt call processing ...
        ... possibly reenable interrupts?
        ... possibly reset MOSLOC2
        PULS    A
        STA     MOSLOC3
        RTI                     ; copies MOSLOC3 -> MOSLOC2 on LIC
]


)

$0000           +-----------------------+
                | DP and OSWKSP         |
$E00+           +..........PAGE.........+  ($1000 in multitask mode)
                |  USER PROGRAM         |
$3000           |                       |==========+=====+=====+
                |.........HIMEM.........| shadow   |     |     |
                |                       | screen 1 |  2  |  3  |
                |  SCREEN (0)           |          |     |     |
                |                       |          |     |     |
$8000           +-----------------------+==========+=====+=====+
                |                       |
                | SWROM / RAM           |
                |                       |
                |                       |
                |                       |
$C000           +-----------------------+
                |                       |
                | MOSROM                |
                |                       |
                |                       |
                |       vectors at F7FX |
$FC00           +-----------------------+
                | I/O  FRED             |
$FD00           +-----------------------+
                | I/O  JIM              |
$FE00           +-----------------------+
                | I/O  SHEILA           |
$FF00           +-----------------------+
                | MOSROM  OS calls      |
                +-----------------------+

FRED, JIM, SHEILA always map to hardware

The screen display is always at the end of bank 0,1,2,3 depending on
shadow registers. It wraps at $10000 (as opposed to $8000 on beeb)


User avatar
fordp
Posts: 877
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: 6809 experiments

Postby fordp » Thu Jul 13, 2017 12:02 pm

I have a suggestion that you make it an Electron compatible PCB. The Electron is simple and compact and there would be no need for a disc interface as the Electron already has one for instance.

Just an idea. As for using modern chips, I would say great go for it.

(http://blog.tynemouthsoftware.co.uk/201 ... ry-pi.html)
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: 6809 experiments

Postby dominicbeesley » Thu Jul 13, 2017 12:57 pm

I'm not sure I follow you. This will be a replacement motherboard for a beeb not an add on card. Or do you mean electron form-factor, that's a possibility but I only have one (broken) Electron. I have 4 beeb cases and 2 working motherboards....

I'm trying to work out how to get 4MHz and CPU modes working today...I suspect that will be pushing the limits....

D

User avatar
fordp
Posts: 877
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: 6809 experiments

Postby fordp » Fri Jul 14, 2017 7:50 am

If you have a broken Electron then you have the perfect case for your project. I just think the Electron is a good platform for a modern Acorn machine. The BBC PCB is far too big and would cost too much. You would not need all that space anyway.

I would add a Pi CoPro connector on the board. You could add a 1MHz bus and Two User ports and a DB9 Serial Port. I think the rest should be expansion on the back.

My MaxRAM project has a pretty good flash and RAM chip. The CPLD is OK but the JTAG interface is a problem I have stumped up for their expensive one.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: 6809 experiments

Postby B3_B3_B3 » Sat Jul 15, 2017 7:21 pm

dominicbeesley wrote:Yes, I suspect big-endian was a "differentiator" for Motorola (To a marketing person a differentiator sounds like a wonderful opportunity,....

As the original 6809 has a 16bit ALU(and your 6309 32bit), changing to little endian would not offer the '16bit speed for no cost' advantage it would on an 8bit ALU CPU with pipelined instructions (ie 6502), and so would be a disadvantage because now the 6809 has a significant difference from its 6800 predecessor which would scupper the easy porting from existing 6800 source code that was desired by the designers of the 6809.

Here is an article describing the 6809 architecture choices (by the designers):
http://tlindner.macmess.org/wp-content/uploads/2006/09/byte_6809_articles.pdf
page 6 about 6800-ness

I am afraid Darth Marketing persons may not to blame for this one :)

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

Re: 6809 experiments

Postby dominicbeesley » Mon Jul 17, 2017 3:43 pm

Thanks B3,

That looks like a good read, though I couldn't find any mention of endianness on my quick read through of page 6 just about 6800 source-software compatibility. That's not really a justification for endianness, rather for keeping people who are already invested in a particular architecture...I would be interested in the original reason for the 6800's endianness.

Thanks FordP, I get you the, though I'm going to go ahead with the large motherboard. I always loved the beeb and Master, less so the Electron (I had one but really wanted a Beeb). I never really got on with the keyboard or styling. I take your point about the cost but as I am only making one (or maybe a handful) the size of the board is not an issue ($100 for 5 from Pcbway)...I just better not get it wrong this time.

I'm now trying to figure out if CPU at 4MHz is sensible/possible. If I could get the RAM and MMU going at 8MHz that would allow for some funky screen modes...

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

Re: 6809 experiments

Postby BigEd » Mon Jul 17, 2017 4:02 pm

dominicbeesley wrote:...I would be interested in the original reason for the 6800's endianness.

Me too. I found this opinion:
But 68000 big-endianness came from the prior Motorola 6800 8-bit processors being big-endian. And those were because IBM (a customer of Motorola) used big-endian in their System/360 minicomputers.


Many design choices in the 360 are outlined and explained here (pdf, 1964), but I've found nothing there on what we'd now call byte order or endianness.

This article mentions endianness:
The IBM 360 designers had numbered the bytes within a word (4 bytes on the 360) based on the way English words are written -- from left to right. So if text is stored in a word of memory, the first character is stored in the byte that would hold the most significant bits of an integer if that word were used to store a binary integer.

which suggests that in a word-oriented machine where the (long) words will sometimes contain several characters, the left-to-right ordering of characters is, for left-to-right readers, natural - that is, we should not view the endianness question as if all memories are primarily byte-ordered and larger units are composed of addressable bytes. To do so is to think like an 8-bit CPU!

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

Re: 6809 experiments

Postby Rich Talbot-Watkins » Mon Jul 17, 2017 7:18 pm

I'm honestly surprised that big endian ever existed, as I just don't see it making sense, and it surely complicates design too: (If reading 8 bits, load address A into bits 0-7; if reading 16 bits, load address A into bits 8-15, load address A+1 into bits 0-7). Designing with the intention of human readability seems like an odd thing to do if it introduced extra complexity.

Either way, it's part of history and we're stuck with it. But I still mutter curses under my breath every time I have to write code in my job which requires special handling to be endian-neutral.

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

Re: 6809 experiments

Postby BigEd » Mon Jul 17, 2017 7:24 pm

I suspect you're thinking memory is an array of bytes. That's more true in the microprocessor era than it was previously, when it was likely to be an array of words.

I do strongly prefer little-endian, mind. But then it was also the first convention I came across.

User avatar
1024MAK
Posts: 6684
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: 6809 experiments

Postby 1024MAK » Tue Jul 18, 2017 7:10 pm

Systems that use word sizes larger than eight bits may load the entire word in a single operation. Further some can use more than one eight bit byte of a word for some operations. In this context, storing data in a "left to right" order does not sound like such a bad thing... Especially when the "CPU" was not a single chip, but an array of logic chips designed for that application.

As is always, if there is more than one way of doing things, us humans will always manage to have systems using two (or more) systems...

Anyway, Dominic keep up the good work :D. I enjoy reading about it. One day I may do something with the 6809 and 6309 CPUs that I have...!

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

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

Re: 6809 experiments

Postby B3_B3_B3 » Tue Jul 18, 2017 7:37 pm

dominicbeesley wrote:Thanks B3,That looks like a good read, though I couldn't find any mention of endianness on my quick read through of page 6 just about 6800 source-software compatibility. That's not really a justification for endianness, rather for keeping people who are already invested in a particular architecture...

Yes, my point was just that as the 6800 had already chosen big-endian-ness(for whatever reason*), changing the 6809 to little endian would have broken any to-be-ported 6800 code which relied on big-endian-ness, and the article simplly stated making upward porting at a source level as easy as it could reasonably be was a goal of the 6809 design.

*I too am interested in the original reason for the 6800's endianness: some interesting posts about that above.

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

Re: 6809 experiments

Postby jgharston » Tue Jul 18, 2017 8:39 pm

B3_B3_B3 wrote:*I too am interested in the original reason for the 6800's endianness: some interesting posts about that above.

I read something written by the designer of the 9900, and he said a lot of it was accident, plus little-endian data made multi-byte data fetches faster with the method they were using to design CPUs in the early 1970s. Do a search for tms9900 dog of a chip.

Code: Select all

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

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

Re: 6809 experiments

Postby dominicbeesley » Wed Jul 19, 2017 10:02 am

Indeed, I still suspect that Motorola's decision was never so much a design decision as a matter of happenstance, like so many things.

The TMS9900 chip was indeed a dog, I had for a while a TI99 with an assembler (cartridge or tape I can't remember). I though I might be able to get something interesting out of it but it was slow! Not helped by the awfully slow memory of the 4A...16bits all sounded so promising....

D

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

Re: 6809 experiments

Postby dominicbeesley » Tue Jul 25, 2017 12:00 am

I decided to have a quick experiment to see if the RAMDAC idea was a goer...it is!

It takes a bit of "over driving" the IMS G171 to get it to output levels close to the Beeb's 2.5 ish volts for peak white (in its usual job as a VGA RAMDAC it only goes up to 0.7V, however nothing seems to have got hot or gone pop).

I'm not sure whether I'll output RGB at TTL levels or do away with that altogether and output to 0.7V. If I do I'll have to amplify the 0.7V up to 2.5V then all my cables will cut that back down to 0.7V for all my monitors which are 0.7V into 75 ohms.

Does anyone know how many monitors were true TTL and if things like the Microvitec Cub would produce an analogue display if fed non-ttl inputs?

Anyway after some inital confusion over timing and silly software mistakes I;ve got it displaying a nice 16 colour MODE2. Also my Mk.I video CPLD/ULA for memory, timing and video has gone from being chock full with a 6 bit paletter to 38% full with a 18bit palette. I don't feel too much like I'm cheating either as INMOS brought out the (difficult to obtain but more useful) G170 in 1985 and the G171 in 1986

The sprawl on my desk is getting a bit mad.

Left to right:

bread board 1: teletext latch, SA5050, hex inverter
blue main board: main 6809 processor, RAM, ROM, ULA
large green board: sys via, user via, sound chip
smaller green board: PC16550 serial port
large bread board, only first column in use: INMOS G171 RAMDAC, 74ls138 Motorola to Intel style bus translation

I'm surprised my 2.5 year old daughter has resisted the urge to pull all the pretty wires out....she stole all my logic analyser probe ends earlier today...
Attachments
20170725_004450-s.jpg
20170725_003050-s.jpg

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

Re: 6809 experiments

Postby dominicbeesley » Wed Jul 26, 2017 3:25 pm

Oooh, I just spotted the 10 character per line mode that I'd forgotten...256 colours at a rather grainy 80x256 pixels!

I wonder, would this be possible with the VideoNuLA?

D
Attachments
20170726_162219-s.jpg

lezanderson
Posts: 10
Joined: Wed Feb 27, 2013 10:42 am

Re: 6809 experiments

Postby lezanderson » Fri Jul 28, 2017 11:40 am

fordp wrote:I have a suggestion that you make it an Electron compatible PCB. The Electron is simple and compact and there would be no need for a disc interface as the Electron already has one for instance.

Just an idea. As for using modern chips, I would say great go for it.

(http://blog.tynemouthsoftware.co.uk/201 ... ry-pi.html)



If you are wanting a 'New' Acorn Electron ..the first thing to do is put the Electron ULA onto a CPLD.. if you have the VHDL/HDL code for the ULA already then that should not be too difficult. Then you could design an electron as below:

65C02 CPU
6522 VIA
CPLD as New ULA (size depends on number of Macrocells needed)
32K SRAM
32K+ EEPROM or NVSRAM
Glue Logic (probably another CPLD EPM7128 etc ??)
MB8877 +WD9216 Floopy Controllers
CF Card / IDE interface
MCU to read PS/2 KBD

Should be doable for anyone with the technical ability and motivated enough ?? :idea:

paulb
Posts: 765
Joined: Mon Jan 20, 2014 9:02 pm

Re: 6809 experiments

Postby paulb » Fri Jul 28, 2017 7:45 pm

lezanderson wrote:If you are wanting a 'New' Acorn Electron ..the first thing to do is put the Electron ULA onto a CPLD.


See here for exactly this.


Return to “hardware”

Who is online

Users browsing this forum: DutchAcorn and 5 guests