ICET-6809

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
Post Reply
Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

ICET-6809

Post by Prime » Tue Oct 09, 2018 10:15 am

Hi All,

This is probably a question mostly for hoglet.....

Does the ICE-T 6809 target sdupport both the 6809 and 6809E......the board I may want to use it in has the former.

Cheers.

Phill.

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

Re: ICET-6809

Post by hoglet » Tue Oct 09, 2018 11:26 am

Hi Phill,
Prime wrote:
Tue Oct 09, 2018 10:15 am
This is probably a question mostly for hoglet.....

Does the ICE-T 6809 target sdupport both the 6809 and 6809E......the board I may want to use it in has the former.
Yes indeed it does.

It you look on the Wiki there is a "E Mode" jumper to select between the two modes:
https://github.com/hoglet67/AtomBusMon/wiki/ICE-6809

Dave

Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: ICET-6809

Post by Prime » Tue Oct 09, 2018 12:02 pm

hoglet wrote:
Tue Oct 09, 2018 11:26 am
Yes indeed it does.

It you look on the Wiki there is a "E Mode" jumper to select between the two modes:
https://github.com/hoglet67/AtomBusMon/wiki/ICE-6809
Cheers Dave,

Though I think I worked out why my System clone 6809 board is not working.....helps to have the code in the right section of ROM so the CPU can read it rather than just getting FF :)

Cheers.

Phill.

Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: ICET-6809

Post by Prime » Mon Apr 08, 2019 9:54 am

Right,

First sorry for resurrecting an old thread.....

Now trying to do some debugging on a Dragon. For some reason the ICE doesn't seem to like the Dragon 64, and is very flakey on the Dragon 32, especially if I have anything (e.g. DragonMMC) plugged into the expansion bus.

It almost seems to be addressing random locations or mis-addressing so acting as if one or more address lines is either perminently gnd / vcc. Could also be that the data being read from the bus is somehow getting corrupted. I have tried extending the data hold time (on writes), but this seemed to have no effect.

One thing I couldn't seem to work out is where you always driving the address bus & R/W when TSC is low.

Cheers.

Phill.

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

Re: ICET-6809

Post by hoglet » Mon Apr 08, 2019 10:22 am

Prime wrote:
Mon Apr 08, 2019 9:54 am
For some reason the ICE doesn't seem to like the Dragon 64, and is very flakey on the Dragon 32, especially if I have anything (e.g. DragonMMC) plugged into the expansion bus.
I do have a Dragon 32 motherboard, but no keyboard, so my ability to do testing is quite limited.

If there's anything I could try with just a motherboard that might duplicate the problem, I'm happy to try.

There are several sets of schematics for the Dragon 32 listed on this page:
http://www.dragondata.co.uk/tech/circui ... dex32.html

Which should I be looking at?
Prime wrote:
Mon Apr 08, 2019 9:54 am
One thing I couldn't seem to work out is where you always driving the address bus & R/W when TSC is low.
Here:
https://github.com/hoglet67/AtomBusMon/ ... n.vhd#L341
and
https://github.com/hoglet67/AtomBusMon/ ... n.vhd#L346

Dave
Last edited by hoglet on Mon Apr 08, 2019 10:22 am, edited 2 times in total.

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

Re: ICET-6809

Post by hoglet » Wed Apr 10, 2019 2:17 pm

Phill,

Thanks for PMing me a link to the schematics. I don't see anything them that gives me cause for concern wrt replacing the 6809E with a GODIL.

I've been looking at the VHDL a bit more, and I did spot a possible issue with the data bus. According to the data sheet, the data bus should only be driven by the 6809 during the second half of the clock cycle. It doesn't look like I've implemented this. If the host machine was trying to use the first half of the clock cycle to read memory for another purpose, then a bus conflict would occur.

Do you know what the Dragon does in this respect?

Dave
Last edited by hoglet on Wed Apr 10, 2019 2:17 pm, edited 1 time in total.

Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: ICET-6809

Post by Prime » Wed Apr 10, 2019 10:44 pm

hoglet wrote:
Wed Apr 10, 2019 2:17 pm
Phill,

Thanks for PMing me a link to the schematics. I don't see anything them that gives me cause for concern wrt replacing the 6809E with a GODIL.

I've been looking at the VHDL a bit more, and I did spot a possible issue with the data bus. According to the data sheet, the data bus should only be driven by the 6809 during the second half of the clock cycle. It doesn't look like I've implemented this. If the host machine was trying to use the first half of the clock cycle to read memory for another purpose, then a bus conflict would occur.

Do you know what the Dragon does in this respect?
The SAM / 74LS783 in the Dragon does share the RAM between the CPU and the 6847, so basically it gives the VDG access when the E clock is low and the CPU access when the E clock is high. Datasheet here :
mc6883 (SAM).pdf
SAM datasheet.
(840.07 KiB) Downloaded 5 times
Notice from the data sheet that the outputs from the RAM is gated through an LS244 buffer, this prevents the video data getting onto the CPU data bus, but the data inputs to the RAM are connected directly to the CPU data bus, however during a video cycle the write enable to the RAM will be held high by the SAM.

I've also designed (though not yet etched) a CPU buffer board that sits between the CPU socket and the CPU, basically just 3 LS245s two on the address lines just wired for a single direction and the other on the data lines who's direction is switched by R/W.

Cheers.

Phill.

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

Re: ICET-6809

Post by hoglet » Thu Apr 11, 2019 6:06 am

hoglet wrote:
Wed Apr 10, 2019 2:17 pm
I've been looking at the VHDL a bit more, and I did spot a possible issue with the data bus. According to the data sheet, the data bus should only be driven by the 6809 during the second half of the clock cycle. It doesn't look like I've implemented this.
Actually, the above statement is incorrect. I do only drive the data bus (during a write) when E is high. That's done with the data_wr term.

Code: Select all

    data_wr    <= E_c;
...
    Data       <= memory_dout when TSC = '0' and data_wr = '1' and memory_wr1 = '1' else
                         Dout when TSC = '0' and data_wr = '1' and R_W_n_int = '0' and memory_rd1 = '0' else
                  (others => 'Z');
So I'm a bit stuck for ideas.

I'll dig out my Dragon 32 board today and give it a try.

Dave

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

Re: ICET-6809

Post by hoglet » Thu Apr 11, 2019 12:39 pm

hoglet wrote:
Thu Apr 11, 2019 6:06 am
I'll dig out my Dragon 32 board today and give it a try.
Not having a keyboard limits the testing I can do, but I've been able to reproduce the unreliability just by letting it sit there at the OK prompt. I'm seeing random junk get written to the screen, and occasionally the relay clicks.

I've compared the timing with a real 6809E on the scope, and it was out by a bit.

See if you get on better with these settings:

Code: Select all

    cpu_clk    <= not E_d;
    busmon_clk <= E_d;
    data_wr    <= E_b;
Dave
Last edited by hoglet on Thu Apr 11, 2019 12:40 pm, edited 1 time in total.

Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: ICET-6809

Post by Prime » Thu Apr 11, 2019 1:15 pm

hoglet wrote:
Thu Apr 11, 2019 12:39 pm
hoglet wrote:
Thu Apr 11, 2019 6:06 am
I'll dig out my Dragon 32 board today and give it a try.
Not having a keyboard limits the testing I can do, but I've been able to reproduce the unreliability just by letting it sit there at the OK prompt. I'm seeing random junk get written to the screen, and occasionally the relay clicks.
Yeah that's pretty much what it was doing for me. Though I have noticed it ocassionally doing this with a real 6809, it tends to be OK once warmed up :) but with the ICE, it was doing it pretty constantly though once it was working it did work.
I've compared the timing with a real 6809E on the scope, and it was out by a bit.

See if you get on better with these settings:

Code: Select all

    cpu_clk    <= not E_d;
    busmon_clk <= E_d;
    data_wr    <= E_b;
Right I'll give those a go this evening.

Something else that might be useful (to the other cores too), is the ability to not single step interrupt service code. The Dragon has a 50Hz interrupt, generated by the VDG, so when you set a breakpoint, and then single step it immediately goes off and steps the int handler, not very useful :(

Cheers.

Phill.

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

Re: ICET-6809

Post by hoglet » Thu Apr 11, 2019 3:46 pm

Prime wrote:
Thu Apr 11, 2019 1:15 pm
Something else that might be useful (to the other cores too), is the ability to not single step interrupt service code. The Dragon has a 50Hz interrupt, generated by the VDG, so when you set a breakpoint, and then single step it immediately goes off and steps the int handler, not very useful :(
I've wanted to do that as well, because it really annoys me on the Beeb.

The thing is, it's not actually that easy to do. The only way I could think of doing it was to have a command that causes the interrupt line to be temporarily disconnected from the 6502. Do you have any better ideas?

Dave
Last edited by hoglet on Thu Apr 11, 2019 3:46 pm, edited 1 time in total.

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

Re: ICET-6809

Post by BigEd » Thu Apr 11, 2019 5:02 pm

Could you free run until you hit an RTI? Or until the stack pointer comes back to the level it was at in the application?

Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: ICET-6809

Post by Prime » Mon Apr 15, 2019 11:08 pm

Ok,

I tried your updates to the timing, still doesn't seem to improve things.

Running through a buffer board (buffering address and data with LS245s), does seem to make some improvement but not much :(

One thing I have notice is that often the Dragon will power up with less than 32K of memory available, PRINT MEM from basic should return about 24K, as its' free memory so like the block between HIMEM-PAGE on an Acorn machine. Often this will be as little as a couple of KB, sometimes print mem will display and ?OM error (I don't have enough memory to display how much memory you have!).

If I at this point break in on the ICE console and dump the registers I'll find that the stack pointer register is something like $2100 (it would normally be $7Fxx), the Dragon as part of it's power on checks all the memory up to 32K and assumes the top is at the point that it reads back a different byte to that written. So the low stack pointer indicates where this failed.

Now comes the odd part, if I thin use the test command to test all the ram so : TEST 0000 7FFF all the tests pass, I've tried doing it several times in a row and all pass, but use the reset command and continue and it will again fail at some low value, which is odd.

BTW are you going to be at the Riscos show, I could bring you a Dragon keyboard if it would help test things.

Cheers.

Phill.
Last edited by Prime on Mon Apr 15, 2019 11:09 pm, edited 1 time in total.

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

Re: ICET-6809

Post by hoglet » Tue Apr 16, 2019 7:26 am

Prime wrote:
Mon Apr 15, 2019 11:08 pm
I tried your updates to the timing, still doesn't seem to improve things.
OK, that's a shame. Once I get through the backlog of PCB designs, I'll have another think.
Prime wrote:
Mon Apr 15, 2019 11:08 pm
Now comes the odd part, if I thin use the test command to test all the ram so : TEST 0000 7FFF all the tests pass, I've tried doing it several times in a row and all pass, but use the reset command and continue and it will again fail at some low value, which is odd.
I agree that is a bit strange, and probably a useful data point.
Prime wrote:
Mon Apr 15, 2019 11:08 pm
BTW are you going to be at the Riscos show, I could bring you a Dragon keyboard if it would help test things.
No, I won't be going. It's a bit too far for just a day of show.

Actually, the lack of a keyboard isn't actually blocking me, as the issue occurs during the startup sequence, or when just idling.

A couple of Dragon questions..

When boot and idling, what's actually going on? Are interrupts routinely happening for example?

Dave
Last edited by hoglet on Tue Apr 16, 2019 7:27 am, edited 1 time in total.

Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: ICET-6809

Post by Prime » Tue Apr 16, 2019 8:00 am

hoglet wrote:
Tue Apr 16, 2019 7:26 am
Actually, the lack of a keyboard isn't actually blocking me, as the issue occurs during the startup sequence, or when just idling.

A couple of Dragon questions..

When boot and idling, what's actually going on? Are interrupts routinely happening for example?

Code: Select all

Boot sequence :
  Init Hardware, PIAs, SAM, ACIA (d64).
  Including testing input port of PIA to determine RAM type 4116 or 4164.
  Program SAM for correct memory type.  
  Test and size RAM.
  Place stack at top of RAM, sysvars at bottom and screen at $400.
  Init screen and print signon message.
  Enable Interrupts.
    if a FIRQ happens 
       jump to the code at $C000, this is an auto-start cartridge e.g. a game, this generally never returns.
    else :
    Check if the two bytes at $C000 are 'DK', call subroutine at $C002, to initialise cart e.g. DOS.

    enter basic loop.
    On every FS from the VDG, generate an IRQ interrupt this :- 
      updates the time variable, 
      deals with PLAY note durations, 
      flashes the cursor  
      scans the keyboard.         
In bare board like you have you should never get an FIRQ or NMI interrupt, as the lines are not connected to anything (and a re pulled up).

Cheers.

Phill.
Last edited by Prime on Tue Apr 16, 2019 8:01 am, edited 1 time in total.

Prime
Posts: 2758
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: ICET-6809

Post by Prime » Tue Apr 16, 2019 2:16 pm

Just to comment, The Dragons in question work as normal with a standard 6809 in them, so hopefully the fault's not there :)

Cheers.

Phill.

Post Reply