ICET-6809

[Prime]

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.

[hoglet]

Hi Phill,

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]

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]

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.

[hoglet]

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?

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

[hoglet]

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

[Prime]

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 3 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.

[hoglet]

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

[hoglet]

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

[Prime]

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.

[hoglet]

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

[BigEd]

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]

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.

[hoglet]

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.

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.

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

[Prime]

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.

[Prime]

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.