Matchbox sized 6502 / Z80 / 6809 Co Pro

emulators, hardware and classic software for atom + system machines
Post Reply
User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Fri Nov 28, 2014 12:27 pm

Trying to keep the technical stuff in this thread:
flynnjs wrote:I have a plan to add paged memory on the parasite. I've contemplated it being in a write-only register that overlaps with the client ROM to "keep it out of the way".
On the Z80 it's simple, use the linked-to circuit accessed through OUT (&xx0F),nn. The 6809 is just the same circuitry, I'll check the SWTPC schematics but off the top of my head the Tube client code reserves &FEC0-&FEFF for I/O with Tube at &FEFx. With the 6502 the best option is to check how John Kortink's 65816 CoPro pages in its memory. I'll report back later, but in general &FEC0-&FEFF is reserved for I/O in 64K memory-IO CPU CoPros with Tube at &FEFx, and there are 8 spare locations in the Tube area at &FEF8-&FEFF.
flynnjs wrote:Is there any software which overwrites the client code after it gets copied to RAM and then implements Tube protocol with some other code?
Yes, the NMI handler gets modified for every data transfer.
flynnjs wrote:Question is, where should the page window be in the memory
map?
The usual option is that there isn't a page window, like BBC sideways ROMs, every page in the logical memory map is pageable to every page in the physical memory map, like the RISC OS scheme.

Code: Select all

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

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Fri Nov 28, 2014 9:53 pm

I was thinking &ffee won't modify as it's a well known entry point / os call so that could be a write only shadow. A full memory management system doesn't sounds hard in hardware. .. more of a nightmare in software :)

User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Sat Nov 29, 2014 8:15 pm

flynnjs wrote:I was thinking &ffee won't modify as it's a well known entry point / os call so that could be a write only shadow.
You can't use anything outside the &FEFx range, as all other addresses are written to on startup to copy the ROM to RAM. And some code does modify locations in the MOS entry block at &FFxx, such as my Tube Atom/System environment which puts an Atom/System entry block at &FFxx.

Doing some investigations, none of the Tube Status registers are ever written to from the parasite side by any client code. Without detailed investigation I don't know if they are even writeable. Only Status1 contains bits that are directly modifiable (the control bits) and they are only modifiable from the host side, all the other registers just contain the TxRdy/RxRdy flags in b7 and b6. So, that is four I/O locations with six bits in each for reading, and four I/O location with 8 bits for writing.

The client code and memory map reserves 16 bytes for I/O, but there are only 8 Tube registers in TUBE+0 to TUBE+7 at &FEF8 to &FEFF on the 6502, and the hardware is wired to only respond to TUBE+0 to TUBE+7. So, that leaves another 8 bytes free for I/O at TUBE-8 to TUBE-1 at &FEF0 to &FEF7.

(Years ago I sketched up something that you could plug multiple CoPros into and it decoded an address in the host's TUBE+8-15 range at &FEF8-F to decide which CoPro was seen in the TUBE+0-7 range. Of course, that doesn't conflict with anything in the parasite, so TUBE-8 to TUBE-1 at &FEF0-&FEF7 are free, and also recognised as being reserved and not trampled on by the standard client code.)

So, from the parasite side, there are 8 bytes and 4 x 6/8 bits available for I/O from the parasite:

&FEF0 (TUBE-8) b7-b0
&FEF1 (TUBE-7) b7-b0
&FEF2 (TUBE-6) b7-b0
&FEF3 (TUBE-5) b7-b0
&FEF4 (TUBE-4) b7-b0
&FEF5 (TUBE-3) b7-b0
&FEF6 (TUBE-2) b7-b0
&FEF7 (TUBE-1) b7-b0
&FEF8 (TUBE+0) (&FEF0) b5-b0 for reading, b0-b7 for writing
&FEFA (TUBE+2) (&FEF2) b5-b0 for reading, b0-b7 for writing
&FEFC (TUBE+4) (&FEF4) b5-b0 for reading, b0-b7 for writing
&FEFE (TUBE+6) (&FEF6) b5-b0 for reading, b0-b7 for writing

I once toyed with the idea of adding some sort of extra I/O to a 6502 CoPro with careful cutting of a track near IC4. Not sure what I was thinking of putting there, maybe some blinkenlights. But that was probably at the back of my mind when I sketched up a recommended 6809 CoPro design and suggested putting an ACIA at TUBE+8/9. (I thought it was on this diagram).

Edit: I had the 16-byte I/O addresses the wrong way around above. I've been coding the 6809 client most of the day which has &FEEx(*) for I/O with the Tube registers in the first eight bytes. But while the 6502 also has 16 addresses reserved for I/O, at &FEFx, the Tube registers are in the second eight bytes at &FEF8-&FEFF. Edited the above to match reality.

(*)The reason the 6809 doesn't also use &FEFx is because the hardware vectors are mapped to &FEFx by toggling A8 to move them away from &FFFx.
Last edited by jgharston on Sun Nov 30, 2014 1:08 am, edited 3 times in total.

Code: Select all

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

User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Sat Nov 29, 2014 8:27 pm

flynnjs wrote:A full memory management system doesn't sound hard in hardware. .. more of a nightmare in software :)
Yes, though getting it working in hardware is the first step, software is much more mutable and can work around it. There are odd little weird bits in the Tube host code that appears to be a result of a flawed or forced design in the silicon that was easier to work around in software.

For the Z80 and 6809 it's simple. Extend A12-A15 to A15-A19 as with this circuit to give 16 4K pages each of which can access any 4K of extended memory. This is the standard MMU system on 6809 systems such as Flex and OS-9 inherited from the original 6809 SWTPC. The simplest implementation (as used on the SWTPC) uses 16 memory locations. On the 6809 CoPro I reserved &FEC0-&FEFF for I/O and remapped vectors and pencilled in &FEDx for the MMU. The thread from back in 2008 on the mailing list mentioned a VIA so I'd also pencilled in a VIA at &FECx and the aforementioned ACIA at &FEE8/9.

For the 6502 there's the OS65 MMU system which is the same concept, 16 4K pages; and there's the ReCo65 which has two pageable memory windows, &4000-&7FFF and &8000-&BFFF. The ReCo65 method is implementable as a subset of the OS65 method, and has the advantage of the "same" MMU hardware. The only problem is that with the standard Client code we only have 8 spare I/O locations, &FEF0-&FEF7.

The immediate solution to that would: patch the client code to reserve another 16 memory locations. But, there is an advantage of being able to drop in the raw unpatched 6502 client code and have it work without worrying that it's going to trample over extra hardware. Or arrange the hardware so it doesn't get upset at every location being set to &FF at RESET - the standard 6502 Tube clients have &FF in &FEC0-&FEEF.

The simplest solution is to use the CRTC method: use one I/O location to select the register you want to write to, and another to write the data. So, to write to MMU register 6 instead of doing something like: LDX #6:STA MMU,X you'd do: LDX #6:STX MMU+0:STA MMU+1, just like with the CRTC. I think that's the method I'd prefer.
Last edited by jgharston on Sun Nov 30, 2014 1:14 am, edited 2 times in total.

Code: Select all

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

firthmj
Posts: 238
Joined: Tue May 26, 2009 9:37 am
Location: Ipswich, UK
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by firthmj » Sat Nov 29, 2014 10:34 pm

Hi Jason,

You mentioned on Friday that you were having some issues with the SPI flash chip you've put on your prototype board.

The chip that I mentioned having used successfully with the Spartan 6 was the Adesto (formerly Atmel) DataFlash family:

http://www.adestotech.com/dataflash

My experience was with the 8Mbit part, which is fully supported for indirect programming in even quite old versions of the Xilinx tools.

There are 16Mbit and 32Mbit versions, but it is probably worth checking the Xilinx docs to ensure that the larger sizes are supported fully by Impact.

(hopefully discussing here is OK!)

Regards

Michael
Had fun at the
Image
Meeting 21st September 2019

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Sat Nov 29, 2014 11:06 pm

No really an issue, I just bought the latest Spansion part for the prototype which I later discovered isn't compatible with Spartan 6. I read the Spansion document which list which parts are qualified for Spartan 6 and the problem was solved. I will just by a batch of those for the final assembly. The Spansion ones are similarly priced to the ones you mention, both of which are MUCH cheaper than Xilinx configuration devices!
Thanks for your advice tho.

Jason

User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Sat Nov 29, 2014 11:23 pm

I've done a few more tweeks to the 6809 Tube client, mostly bits of tidying and optimisation. Also updated code entry to avoid data transfer overwriting the stack.

Most CoPro clients have some local *commands to do things like examine memory and enter code. Not all CoPros have the same range of commands, for instance, the 6502 has *GO, the Z80 has *GO and *Mdump, but the 6809 (currently) doesn't have either. I've added *GO to my Utilities Disk 1 so you can have *MDUMP and *GO available from any environment (I need to get around to finishing *MEDIT):
* Utils1 Archive
* Utils1 DFS image

Code: Select all

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

User avatar
Arcadian
Site Admin
Posts: 3600
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by Arcadian » Sun Nov 30, 2014 12:13 am

Apologies if this has already been covered, but ...

- I assume it will be easy to install the board inside the case (e.g. on the underside of the lid) via a ribbon cable? (Just thinking if I were to put one out on public display I'd want it to be secure)

- just wondering whether has the board been laid out so that it will slot into a cheese wedge case (I think J Kortink's ReCo boards were designed with this in mind, I think?)
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by 1024MAK » Sun Nov 30, 2014 1:26 am

A photo of his first generation board: Image

The layout of the next generation board:
Image

The next:
Image

And the latest prototype PCB:
Image

(the last three taken from this thread)

Mark

User avatar
Matt Norman (BANNED)
Posts: 35
Joined: Thu Feb 21, 2013 7:32 pm

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by Matt Norman (BANNED) » Sun Nov 30, 2014 11:17 am

Will it be possible to switch between copros easily ? Or will this require reprogramming the serial flash every time ?

User avatar
Matt Norman (BANNED)
Posts: 35
Joined: Thu Feb 21, 2013 7:32 pm

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by Matt Norman (BANNED) » Sun Nov 30, 2014 11:18 am

<Link removed by admin>

It's raining copros !

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Sun Nov 30, 2014 12:56 pm

On initial shipping, selection will be made using the DIP switches
meaning a power cycle, and probably brief removal of the board
from the underside of the Beeb.

In later releases of firmware I hope to allow switching via some
Beeb software. It feasible without any hardware changes, just
firmware hasn't been written to do it yet.

Jason
Last edited by flynnjs on Sun Nov 30, 2014 12:59 pm, edited 1 time in total.

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Nov 30, 2014 12:57 pm

JGH,

I've just tried out your latest 6809 client code (v0.22), and it seems to be working as well as the previous version (v0.21 with my fixes).

I've had a go at running your EXBAS09 from here:
http://mdfs.net/Software/6809/Basic/

I can *LOAD this, *MDUMP and it seems to have loaded, but when I *GO 8000 I just get:
6809 EXTENDED BASIC
(C)1982 MICROSOFT

And then the parasite hangs.

I've tried to verify the image loaded correctly, by *SAVING it, and in doing this I have found that *SAVE is unreliable. It looks like a similar NMI problem to the Z80, so I'll try to add some synchronization.

Dave

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Sun Nov 30, 2014 1:03 pm

Matt Norman wrote:<Link removed by admin>

It's raining copros !
It's a very nice and tidy piece of engineering but is a Master only option and only for 6502.

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Nov 30, 2014 1:20 pm

hoglet wrote:I've tried to verify the image loaded correctly, by *SAVING it, and in doing this I have found that *SAVE is unreliable. It looks like a similar NMI problem to the Z80, so I'll try to add some synchronization.
The same synchronization fix worked for the 6809, and now *SAVE is reliable.

It's not clear to me whether the issue here is with the processor cores requiring IRQ/NMI to be synchronous, or with the Tube design not doing as good a job as the original. I guess the processor data sheets would provide the answer, but I also assumed that interrupts could be completely asynchronous.

Anyway, I can now *LOAD and *SAVE the EXBAS09 program, and there is no corruption happening. So I need to look elsewhere for the problem. It's possible this is a bug in the 6809 core I'm using.

JHG, Any thoughts? What level of testing as EXBAS09 had?

Dave

firthmj
Posts: 238
Joined: Tue May 26, 2009 9:37 am
Location: Ipswich, UK
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by firthmj » Sun Nov 30, 2014 1:33 pm

flynnjs wrote:
Matt Norman wrote:<Link removed by admin>

It's raining copros !
It's a very nice and tidy piece of engineering but is a Master only option and only for 6502.
The multi-chip design does mean one of the level translators ends up in a sub-optimal place. The signals from the right side connector are tracked all the way across the board, then level translated, then back into the CPLD.

With an FPGA based design, you could have the FPGA in the middle, one level translator on each side, and the RAM either above or below.

And the cost for a fixed CPU design, that he won't guarantee to run faster than 4MHz, is the same as the multi-CPU version of yours that doesn't have external RAM.

(plus shipping costs from Europe too)

Regards

Michael
Had fun at the
Image
Meeting 21st September 2019

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Nov 30, 2014 1:45 pm

There is a much later version of John Kent's 6809 core in the fpgaarcade svn repository.

Here's the additional revision history:

Code: Select all

-- Version 1.22 - 2011-10-29 John Kent
-- The halt state isn't correct. 
-- The halt state is entered into from the fetch_state
-- It returned to the fetch state which may re-run an execute cycle
-- on the accumulator and it won't necessarily be the last instruction cycle
-- I've changed the halt state to return to the decode1_state
--
-- Version 1.23 - 2011-10-30 John Kent
-- sample halt in the change_state process if lic is high (last instruction cycle)
--
-- Version 1.24 - 2011-11-01 John Kent
-- Handle interrupts in change_state process
-- Sample interrupt inputs on last instruction cycle
-- Remove iv_ctrl and implement iv (interrupt vector) in change_state process.
-- Generate fic (first instruction cycle) from lic (last instruction cycle)
-- and use it to complete the dual operand execute cycle before servicing
-- halt or interrupts requests.
-- rename lic to lic_out on the entity declaration so that lic can be tested internally.
-- add int_firq1_state and int_nmirq1_state to allow for the dual operand execute cycle
-- integrated nmi_ctrl into change_state process
-- Reduces the microcode state stack to one entry (saved_state)
-- imm16_state jumps directly to the fetch_state
-- pull_return_lo states jumps directly to the fetch_state
-- duplicate andcc_state as cwai_state
-- rename exg1_state as exg2 state and duplicate tfr_state as exg1_state
--
-- Version 1.25 - 2011-11-27 John Kent
-- Changed the microcode for saving registers on an interrupt into a microcode subroutine.
-- Removed SWI servicing from the change state process and made SWI, SWI2 & SWI3
-- call the interrupt microcode subroutine.
-- Added additional states for nmi, and irq for interrupt servicing.
-- Added additional states for nmi/irq, firq, and swi interrupts to mask I & F flags.
--
-- This version - 2013-11-02 Arnim Laeuger
-- Numerous changes and updates to comply with MAME driver.
-- Aims to be cycle accurate wrt to cycles/instruction.
I've just tried this, and while it does boot, even less seems to be working. For example, *MDUMP no longer works; it just return EE's.

Probably something obvious I'm doing wrong in the use of this....

More later....

Dave

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Nov 30, 2014 5:39 pm

Another update...

The most recent version of the SYS09 core I could find was a version 1.26 that was part of Grant Searle's Multicomp Project:
http://searle.hostei.com/grant/Multicomp/index.html

Unfortunately, this version still seems to have problems. Specifically, MDUMP is just returning EE bytes, which means nothing is being written into the FIFO by the parasite. Now, MDUMP, as well as LOAD and SAVE, uses the transfer type that was implemented with the SYNC instruction. So this is where I started debugging. And a few minutes with the logic analyzer confirmed that indeed the SYNC instruction is broken, as it didn't continue execution when the IRQ interrupt arrived.

Armed with this data point, I was able to spot and fix the bug in the VHDL (which seems very nicely written).

So, with the latest 6809 core, and with a working SYNC instruction, it was back to trying to get JGH's Microsoft Extended Basic to run.

Unfortunately, this is still not working. Very occasionally it will print:
6809 EXTENDED BASIC
(C)1982 MICROSOFT

But most of the time it just hangs, or returns the * prompt and then hangs.

Dave

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Nov 30, 2014 7:12 pm

JGH,

The EXBAS09 problem is actually happening much earlier than I thought. It looks like *GO (and *RUN) are now broken (i.e. tube transfer type 4).

With v0.21 of the client code, *GO FFE7 gives the expected results, i.e. I get a new line printed, and then we're back at the * prompt.

With v0.22 of the client code, *GO FFE7 crashes.

If I trace instructions executed executed, the JSR [,X] at 0xF950 is going to the wrong address.

It's possible this is a hardware bug, but I wonder if you could cast your eye over the updated code, and see if you can spot anything. (I can't....)

Edit: Looks like there is an extra level of indirection somewhere. If I *GO FFE7 then it jumps to 860a which is the contents of FFE7.

I think the problem is:

Code: Select all

f94e :                  EXEC_ENTER:
f94e : 8601             	LDA  #1		; Enter code with A=1
f950 : ad94             	JSR  [,X]	; Call program execution address
f952 : 3510             	PULS X
f954 : bfff8a           	STX  MEMTOP	; Restore MEMTOP if code returns
f957 : 39               	RTS


i.e. JSR [,X] seems wrong

Dave

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Nov 30, 2014 9:05 pm

JGH,

I've patched:
JSR [,X] AD 94
to
JSR ,X AD 84
and now *GO is working, so I can continue testing Extended Basic EXBAS09.

It's still hanging, executing code between the following addresses:

0x8470
...
0x84EA

plus calling out to a subroutine at 0x813A

Could you post an assembler listing for Extended Basic EXBAS09 so I can debug this further please?

Dave

User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Sun Nov 30, 2014 11:58 pm

hoglet wrote:I've patched:
JSR [,X] AD 94
to
JSR ,X AD 84
and now *GO is working,
Ta, I'll merge that back into the source and bump it up to v0.23. Because that previously said JSR [PROGRAM] I obviously changed it to [,X] instead of ,X. The syntax does suggest that JSR [something] would be correct. I'll have to check the 8912 client as well, it may have the same error. I remember it took ages digging through the manual to work out how to do the equivalent of the 6502's JMP (addr).
hoglet wrote:so I can continue testing Extended Basic EXBAS09.
It's still hanging, executing code between the following addresses:
0x8470 ... 0x84EA plus calling out to a subroutine at 0x813A
Could you post an assembler listing for Extended Basic EXBAS09 so I can debug this further please?
Yes, here. I've been having similar problems with EXBAS09. It's some of the most appalling code I've ever seen. I wonder if this is typical of 1979-era Microsoft code?

I've fixed some problems with it since the last upload, specifically the workspace initialisation was wrapping around past $0000 and clearing $FFFF as well, and wrapping past $8000 and trampling over itself.

Running on my emulator, it seems to be working so far:
Image
Last edited by jgharston on Wed Dec 03, 2014 5:35 am, edited 1 time in total.

Code: Select all

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

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Dec 01, 2014 9:05 am

JGH,

I've just given the updated version of EXBAS09 a quick try.

All I get is:
6809 EXTENDED BASIC
(with no newline, and no copyright message)

Looking at the code, the only explanation I can think of is that the top of the ROM vectors is still getting nobbled. Or maybe the stack, so that the JSR doesn't return properly.

I'll do a bit more debugging tonight.

Dave

User avatar
jms2
Posts: 2677
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jms2 » Mon Dec 01, 2014 12:24 pm

Matt Norman (BANNED) wrote:<Link removed by admin>
What's all this about? I've obviously missed a controversial incident here... or has someone pressed the wrong button and accidentally erased this person? The post doesn't look at all inflammatory, and neither do the responses.

User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Mon Dec 01, 2014 2:12 pm

hoglet wrote:I've just given the updated version of EXBAS09 a quick try.
All I get is:
6809 EXTENDED BASIC
(with no newline, and no copyright message)
...
I'll do a bit more debugging tonight.
Go ahead. The source for EXBAS09 is so horrendous it could be doing anything.

I've been dumping some bits of test code here and fixed an embarrassing off-by-one error in the Client's HexPrint code. ;)

Code: Select all

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

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by 1024MAK » Mon Dec 01, 2014 2:39 pm

jms2 wrote:
Matt Norman (BANNED) wrote:<Link removed by admin>
What's all this about? I've obviously missed a controversial incident here... or has someone pressed the wrong button and accidentally erased this person? The post doesn't look at all inflammatory, and neither do the responses.
I have no idea what happened, but the subject matter was another co-pro.

Mark

User avatar
Samwise
Site Admin
Posts: 1820
Joined: Mon Mar 14, 2005 9:13 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by Samwise » Mon Dec 01, 2014 2:50 pm

jms2 wrote:
Matt Norman (BANNED) wrote:<Link removed by admin>
What's all this about? I've obviously missed a controversial incident here... or has someone pressed the wrong button and accidentally erased this person? The post doesn't look at all inflammatory, and neither do the responses.
The post itself wasn't particularly controversial - that forum member was removed for breaching our clear and simple guidelines on community etiquette.

If anyone interested in the other co-pro product that was linked to wants to start a new topic to discuss it, you're more than welcome.

Sam.

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by BigEd » Mon Dec 01, 2014 3:05 pm

Samwise wrote:If anyone interested in the other co-pro product that was linked to wants to start a new topic to discuss it, you're more than welcome.
Done - see viewtopic.php?f=3&t=8954

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Dec 01, 2014 7:45 pm

An update on 6809 Basic

I messed up this morning when transferring EXBAS09 to floppy disk, and ended up truncating the file by 3 bytes, which was the NEWLINE code.

I can now run it, and get the following:

Code: Select all

6809 EXTENDED BASIC
(C)1982 MICROSOFT
OK
From this point, it goes a bit pair shaped.

If I enter:

Code: Select all

10 PRINT"HELLO"
I get the response

Code: Select all

?OM ERROROK
LIST, RUN, NEW don't seem to have any effect but don't generate an error and I get back to the OK prompt.

Made up commands like XXX give:

Code: Select all

?OM ERROROK
So there is some amount of command parsing going on.

Code: Select all

PRINT "HELLO"
also gives

Code: Select all

?OM ERROROK
And the delete key doesn't work at all.

I'll try some more after supper....

Dave

User avatar
hoglet
Posts: 9437
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Dec 01, 2014 10:39 pm

Last update for this evening.

There is a problem with the Ram Test.

Code: Select all

8052 : 9f19                       STX  TXTTAB         ; BEGINNING OF BASIC PROGRAM
                        		
                        ;	LFD: Size of RAM available
8054 : a6890080         LA084:    LDA  128,X          ; LOOK FOR END
8058 : 43                         COMA                ; COMPLEMENT IT AND PUT IT BACK
8059 : a7890080                   STA  128,X          ; INTO SYSTEM MEMORY
805d : a1890080                   CMPA 128,X          ; IS IT RAM?
8061 : 260b                       BNE  LA093          ; BRANCH IF NOT (ROM, BAD RAM OR NO RAM)
8063 : 30887f                     LEAX 127,X          ; MOVE POINTER UP ONE
8066 : 63887f                     COM  127,X          ; RE-COMPLEMENT TO RESTORE BYTE
8069 : 8c7f00                     CMPX #CODESTART-256 ; REACHED START OF BASIC?
806c : 24e6                       BCC  LA084          ; KEEP LOOKING FOR END OF RAM
                        		
806e :                  LA093:    ;ldy	#$7FFF         ; LFD: top of RedBoard RAM
806e : 9f71                       STX  TOPRAM         ; SAVE ABSOLUTE TOP OF RAM
Looking on the logic analyzer, execution falls straight through the BCC at 806C.

TXTTAB now contains 02 56
TOPRAM now contain 02 D5

The code looks correct to me, so I need to check the carry flag is being set correctly on CMPX #Immediate

Edit: I'm suspicious of the BCC - JGH, was this in the original code?

Dave

User avatar
jgharston
Posts: 4118
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Tue Dec 02, 2014 12:11 am

hoglet wrote:I can now run it, and get the following:

Code: Select all

6809 EXTENDED BASIC
(C)1982 MICROSOFT
OK
From this point, it goes a bit pair shaped.
Same here.
hoglet wrote:And the delete key doesn't work at all.
'cos it's checking for backspace, CHR$8 ! Try pressing Ctrl-H.
hoglet wrote:Last update for this evening.
There is a problem with the Ram Test.

Code: Select all

8069 : 8c7f00                     CMPX #CODESTART-256 ; REACHED START OF BASIC?
806c : 24e6                       BCC  LA084          ; KEEP LOOKING FOR END OF RAM
Edit: I'm suspicious of the BCC - JGH, was this in the original code?
No, it was originally BRA, which meant the test code wandered through the Basic code, corrupting it as it expects to hit ROM before it gets there. That's me getting the 6809's CC/CS after compare the wrong way around. I keep having to stare into the air and think: is lessthan CC like the 6502 is is lessthan CS like the Z80? Even though the 6809 "looks like" a 6502 with memory-mapped IO, it's CS like the Z80.

I've put the original source code at CoCoBasic.zip. My aim was to make the minimum changes to it to get it to run.

Code: Select all

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

Post Reply

Return to “acorn atom and acorn system series”