ICE T65/Z80/6809

[hoglet]

Thanks for the Wiki invite Mike.

I'd still be interested in looking at any traces you manage to capture and export.

I've been thinking a bit more about writing a 6809 Decoder. This would be an instruction stream decoder (like the old HP inverse assemblers), plus it would model the internal 6809 register state, and also the external memory state. Having access to some interesting traces from a real machine would be a very good motivation to actually get started!

All the information to write a decoder is in the data sheet in the state machine shown in Figure 17:
https://www.bitsavers.org/components/mo ... df#page=21

It's a fair bit more complex that the 6502 (obviously) but the presentation of figure 17 is very close to how I would implement this in C. It's probably only a couple of days work to get to something that's useful.

Much as I love the old HP Logic Analyzers (I have two 1650As and a 16702B), I find myself using a modern (and very cheap) USB logic analyzer that will capture 16 channels (data + control).

The main advantage this has is the ability to do very long captures (seconds, even minutes). So you don't have to be precise about triggering, and you usually only have to do a capture once.

It may seem that 16 channels is very restrictive, but as long as the processor is functional, the value of the address bus can be inferred at all times. This makes the tool useful to a wider audience, because 16-channel USB logic analyzers are far more common (and lower cost) than 32-channel logic analysers.

Anyway, keep up the good work, I'll be following this closely here and on twitter.

Dave

[Witchy]

Much as I love the old HP Logic Analyzers (I have two 1650As and a 16702B), I find myself using a modern (and very cheap) USB logic analyzer that will capture 16 channels (data + control).

The main advantage this has is the ability to do very long captures (seconds, even minutes). So you don't have to be precise about triggering, and you usually only have to do a capture once.

When I started with analysers I bought a Hobbytronics 8 channel one, based on a Cyprus FX2 I believe. Early version of Sigrok/Pulseview. When 8 wasn't enough I bought a Saleae clone from China which still works well - I use it more often on fixing ACT Sirius 1's than anything else at the minute. Its pseudo-'clock' will work with the Logic software for address decoding. Useful! Then 16 channels wasn't enough and I saw this 1660A on ebay for not much given that it had nearly a full complement of pods.

Now that the Posi is booting up to a certain point I should be able to find the reset vector with 0xFFFE followed by 0xFFFF with BS high (I believe).
I've got traces of it executing some of the cold boot code and looping at the SetSvc routine but that's as far as it goes so far. Tonight's task is to add the RAM controls to the schematic since that side is NOT tidy at the moment.

Cheers

Witchy

[Witchy]

As luck would have it, my boot trace triggering at 0xF053 also includes the RESET and jump to 0xFEF6 at machine start. Here you can see it go to DATinit then down to the COLD start routine at 0xF053, then process and loop until end of trace which is unfortunately before it hits the jump to SetSvc. I have a trace of that too, but it's just looping around the routine before falling off the end.

https://binarydinosaurs.co.uk/posiboot.txt

Note: this also contains unused traces (at this point) like the enable pins on IC150 and IC145 (ROM and CPU buffers). If it's useful I'll tidy it up and add IRQ etc.

Cheers

Witchy

[hoglet]

As luck would have it, my boot trace triggering at 0xF053 also includes the RESET and jump to 0xFEF6 at machine start. Here you can see it go to DATinit then down to the COLD start routine at 0xF053, then process and loop until end of trace which is unfortunately before it hits the jump to SetSvc. I have a trace of that too, but it's just looping around the routine before falling off the end.

What do you think is happening in cycle +54?

I'm wondering why BS and BA both go high for one cycle?

Do you think it's possible to get a longer trace? The HP 1660A should allow a memory depths of 4096 samples, or 8192 samples in half-channel mode.

Dave

[bluearcus]

That single BA / BS high cycle rather suggests something spurious going on with the !HALT line.

[Witchy]

Do you think it's possible to get a longer trace? The HP 1660A should allow a memory depths of 4096 samples, or 8192 samples in half-channel mode.

Yep, now that I know the address/data buses are stable I can get analyser usage down to the two pods necessary for an 8K run. I'll do it today. Actually, before I do that I'll reinstate all the LS244/245s I removed to isolate the data bus. This will restore access to all components so it'll be interesting to see if I still get a clean trace.

Cheers

Witchy

[dominicbeesley]

... thinking a bit more about writing a 6809 Decoder ...

Yes please!

D

[Witchy]

Yep, now that I know the address/data buses are stable I can get analyser usage down to the two pods necessary for an 8K run. I'll do it today. Actually, before I do that I'll reinstate all the LS244/245s I removed to isolate the data bus. This will restore access to all components so it'll be interesting to see if I still get a clean trace.

OK, chips reinstated and the traces are the same so I increased the memory to 8K half bus (pods A1 and A3). I also added all active CPU signals, there are 2 MMUs installed and I put all the DIP switches back to what they were originally.

First is boot from cold, 0xFFFE onwards: https://binarydinosaurs.co.uk/posiBoot0xFFFE8k.txt
There are a few loops that take up all the trace memory so I isolated things from the last boot loop which starts from 0xF105: https://binarydinosaurs.co.uk/posiBootF105.txt

It drops off the end of SetSvc so the PC or SP has gone at this point.

Cheers

Witchy

[hoglet]

It drops off the end of SetSvc so the PC or SP has gone at this point.

So this is the LBSR F439 instruction at F187:

Code: Select all

    544     F187   17  0  0    1    1   1   1
    545     F188   02  0  0    1    1   1   1
    546     F189   AF  0  0    1    1   1   1
    547     FFFF   F6  0  0    1    1   1   1
    548     FFFF   F6  0  0    1    1   1   1
    549     F439   E6  0  0    1    1   1   1
    550     FFFF   F6  0  0    1    1   1   1
    551     08FF   8A  0  0    0    1   1   1   <<<<
    552     08FE   F1  0  0    0    1   1   1   <<<<

this writes the return address (F18A) to the stack at 08FE/08FF

The matching RTS instruction at F43F:

Code: Select all

   2376     F43F   39  0  0    1    1   1   1
   2377     F440   10  0  0    1    1   1   1
   2378     08FE   00  0  0    1    1   1   1   <<<<
   2379     08FF   00  0  0    1    1   1   1   <<<<
   2380     FFFF   F6  0  0    1    1   1   1

The value read back from the stack at 08FE/08FF is 0000.

This is pretty solid evidence you have a RAM issue.

I've started work on the 6809 Decoder and realized that as the 6809 doesn't include the LIC output, there is no easy way to recognise the start of an instruction. This is not a complete show stopper, but it does mean all the state emulation needs to be working before you'll get much useful output. That's a few days work.

Dave

[Witchy]

This is pretty solid evidence you have a RAM issue.

I've started work on the 6809 Decoder and realized that as the 6809 doesn't include the LIC output, there is no easy way to recognise the start of an instruction. This is not a complete show stopper, but it does mean all the state emulation needs to be working before you'll get much useful output. That's a few days work.

Dave

Absolutely no hurry, Dave. I've been working on this for a year but I must admit getting it running anything at all was a pretty momentous day last week

Later today I'll carry on drawing out the rest of the RAM circuits. The whole thing appears to rely on a single 74LS155 for RAS/CAS decoding and a pair of 74LS00s for MEMWR so they're probably the first thing to look at. The 16x 4164s installed all test good.

Cheers

Witchy

[Witchy]

One of the 74LS00s had a bad gate so I replaced it and got some write action; initially it was *almost* correct but after 0xF18A was written to RAM it came back as 0xF1F1 which is in the middle of an instruction. Since then it's not been stable at all and will return to 0x0000, 0xFFFF and a few others. I also suspected the 74LS155 that generates the CAS0-4 and RAS0-4 signals. Typically the TL866+ logic tester doesn't do an LS155 so I made a circuit on a breadboard to test it and it was good. Maybe I should add it to the list of testable chips since you can add your own.

I have the correct RAM bank populated with tested 4164s so now I'm tracing backwards through the schematic to find possible trouble points. It may be worth ordering some spare LS260, LS373 and LS390 just in case. Oh, and LS244/245 because there are a LOT of these on the board.

Weekend fun

Cheers

Witchy

[bluearcus]

The following would provide a good starting point:
- D0..7
- RnW
- BA
- BS
- nRESET
- nIRQ
- nNMI
- nFIRQ

If you're doing decoder implementation, for the 6809E it would be better to add A1-A3 (to decode the vector fetch) and LIC instead of all four interrupt lines? Then LIC allows immediate sync if the grab starts in mid run. But on the 6809, yes, problem, though BA/BS can work if interrupts are occurring, and BUSY might provide some help instead of LIC.

On second thoughts, to make the decoder common, A0-A3 and forget the signals not common to both variants might be best...

[bluearcus]

For the 6809E target, does it generate AVMA / BA / BS and take notice of TSC? I'm trying to debug a machine** that uses those, and I can't get it to work.

AVMS / BA / BS are driven directly by John Kent's CPU09 6809 Core.

Code: Select all

      vma      : out std_logic;                     -- valid memory address (active high)
      ba       : out std_logic;                     -- bus available (high on sync wait or DMA grant)
      bs       : out std_logic;                     -- bus status (high on interrupt or reset vector fetch or DMA grant)

I'm using version 1.26 of the core. The latest version is now 1.28, but the updates relate only to IRQ and FIRQ.

Data, Address and RnW are placed in the high impedance state as soon as TSC is taken high (i.e. it acts just like an asynchronous output enable signal). This is done independently of the CPU09 core. I implemented this bit, so it's more likely any errors are here than in John Kent's core.

Thanks Dave,

I possibly need to download the latest version of the code too, my 6809E probe was programmed ages ago (couple of years).

Cheers.

Phill.

I looked at the 6809 core code a little while ago, after seeing that is doesn't work with my RTC board... and it turns out it's some way off being cycle accurate. It does models the 6809 VMA signal, but for the 6809E simply outputs that with timing all wrong on the AVMA line, which scuppers the DragonBeta entirely! And dead cycles are all modelled as fetches from FFFF, rather than some of them as PC+n or SP address related <don't care> cycle behaviours. I doubt all the dead cycles are present either, so timings might be a little off.

Programming the thing with a Pi was enough of an adventure for me, so I doubt I'll start delving into building new firmware with fixes to the core. Too far down the list!

[hoglet]

If you're doing decoder implementation, for the 6809E it would be better to add A1-A3 (to decode the vector fetch) and LIC instead of all four interrupt lines? Then LIC allows immediate sync if the grab starts in mid run. But on the 6809, yes, problem, though BA/BS can work if interrupts are occurring, and BUSY might provide some help instead of LIC.

On second thoughts, to make the decoder common, A0-A3 and forget the signals not common to both variants might be best...

Thanks for that feedback Mike.

We've made a lot of progress over the last couple of weeks on the 6809/6809E decoder, which is being discussed in a seperate thread:
- 6809 Protocol Decoder

It now works with the 6309 as well as the 6809, and with both the E and none-E variants.

It's all on github if you fancy a play:
https://github.com/hoglet67/6809Decoder/tree/dev

I ended up settling on the following signals:
- D0..7
- RnW
- LIC
- BS
- BA
- A0..3

LIC is optional - about the only thing it's currently needed for is to correctly handle a TFM that has been interrupted.

I looked at the 6809 core code a little while ago, after seeing that is doesn't work with my RTC board... and it turns out it's some way off being cycle accurate. It does models the 6809 VMA signal, but for the 6809E simply outputs that with timing all wrong on the AVMA line, which scuppers the DragonBeta entirely! And dead cycles are all modelled as fetches from FFFF, rather than some of them as PC+n or SP address related <don't care> cycle behaviours. I doubt all the dead cycles are present either, so timings might be a little off.

In my recent (virtual) travels I did come across a more recent 6809 Core that does claim to be cycle accurate:
- https://github.com/cavnex/mc6809

Their validation page is very impressive:
- https://github.com/cavnex/mc6809/blob/m ... idation.md

At some point I might try switching the ICE-6809 over to that core.

Dave

[BigEd]

Oh, some great READMEs in that project, thanks Dave!

[Witchy]

Hi Dave,

I'm back on the Positron as of this weekend, there's an odd stack error where 0xF18A is written to it after a subroutine call but 0xF1F1 is read back at the RTS statement. I've started looking at your decoder this afternoon but all the work I did didn't sync to my cloud drive so I can't post on the separate thread until tomorrow. Bloody computers

Thanks for including the posi related stuff in the test directory too, most useful!

Cheers

[Prime]

What is the current status of the non-godil version of the design?

I'm trying to trace a problem on a Dragon (normal one not the dual processor beta!).

I'm not getting the results I expect, which I suspect is due to the bus handline / timing on the Godil.

Cheers.

Phill.

[hoglet]

What is the current status of the non-godil version of the design?

As long as the processor it's replacing is a 6809E, then it should work fine.

Let me know if you experience any issues and I'll investigate.

I did test both versions with a Dragon motherboard, see:
viewtopic.php?p=252988#p252988

You might need to populate the clock filter, see that post for details.

There were also issues with the GODIL version, due to the 1.5K pullup messing up the Dragon's reset circuit.

Dave

[fraido]

Hi, I'm just wondering, can the 6502 core/pod be used to troubleshoot a commodore 64 or similar 6510 equipped machines?

Ok the c64 it's a machine that's quite simple to troubleshoot and repair, the 6510 CPU is pretty the same of a 6502 but the pinout is different.

Ok the core will not support the special opcodes handled by the 6510 but routing signals to match the pinout would be enough to exercise lines and signals to access rams, roms, etc. and troubleshoot them out?

Otherwise I think a modified FPGA core code will do the trick, but I don't know how difficult it could be even not supporting special opcodes.

happy new year to everyone!

[hoglet]

Hi, I'm just wondering, can the 6502 core/pod be used to troubleshoot a commodore 64 or similar 6510 equipped machines?

Ok the c64 it's a machine that's quite simple to troubleshoot and repair, the 6510 CPU is pretty the same of a 6502 but the pinout is different.

Ok the core will not support the special opcodes handled by the 6510 but routing signals to match the pinout would be enough to exercise lines and signals to access rams, roms, etc. and troubleshoot them out?

Otherwise I think a modified FPGA core code will do the trick, but I don't know how difficult it could be even not supporting special opcodes.

happy new year to everyone!

I think this would be possible, but it would involve a fair bit of work:
- redesign the 6502 CPU Adapter PCB for the 6510 pinout
- write a wrapper for the T65 FPGA Core to implement the parallel IO pins (or use the MiSTer 6510 wrapper)

Happy New Year!

Dave

[calphool]

Hi all,

I work on old arcade machines, and I would *love* to have an in-circuit emulator like the one described here. In fact I've got a Z80 based PCB on the bench right now that would absolutely benefit from one (replaced most of the chips but it's still misbehaving... seems like somehow the address decoders aren't behaving as expected, but I can't tell if it's because the code is in a loop or what).

Seems the eepizza boards aren't available and only work on the 6809 anyway. The other ones appear to no longer be available. I'd be willing to spend some cash on a working z80 in-circuit emulator. Anybody have any suggestions?

I've got a couple of Altera Cyclone IV boards that I used for a custom VGA card for the TRS-80 (the Waveshare CoreEP4CE6 FPGA, which is a bit like the Nano DE), and I'm familiar with programming it. Anybody have a read on how difficult it would be to port the Xilinx vhdl over? Any other ideas for how I might get one of these clever little bits of kit?

[BigEd]

Welcome! Perhaps see the new thread

• Ted Fried's teensy-based in-circuit CPU replacements

[Xolod]

Is it known that the Z80 has a special reset mode?
http://www.primrosebank.net/computers/z ... _reset.htm

[Super_7b]

Hi All,

I spent a happy afternoon on Sunday reading through this whole thread and noting the heartache caused by the unavailability of the GODIL and EEPIZZA boards.

I have tried to search for either board on the web, but with no luck. Does anyone know if supplies are available anywhere?

Otherwise, is there any prospect of a newer (and available) board being used? Having read the early part of the thread, I would have loved to have been able to build an ICE with both the 6502 and Z80 capabilities.

BR

Mick

[hoglet]

I have tried to search for either board on the web, but with no luck. Does anyone know if supplies are available anywhere?

Sorry, I'm not aware of any supplies of either board.

It might be worth messaging eepizza on ebay and seeing if they would be willing to make a new batch of the XC6SLX9 Mini Board. The XC6SLX92TQG144C FPGA is now readily available again, and JLC has them in stock for $7.18.

Otherwise, is there any prospect of a newer (and available) board being used? Having read the early part of the thread, I would have loved to have been able to build an ICE with both the 6502 and Z80 capabilities.

I have no concrete plans for a redesign at present. I'm keeping a close eye on the Gowin FPGAs and the Sipeed Tang series of boards, but I don't have a feel yet for the longevity of the boards.

Dave

[Super_7b]

Hi Dave,

Thanks for the rapid response. I've sent a messagae to EEPIZZA through ebay. Let's see what they say. I will feedback any rsponse, positive or negative, here.

BR

mick

[Super_7b]

Hi Dave and anyone else who might be interested,

I sent the following message to EEPIZZA via the ebay page Dave pointed me to:-

Hi,

I would like to ask if you would be willing to make a new batch of the XC6SLX9 Mini Board. There are quite a few of us in the retro micro user community who woud like to purchase what we used to know as the "EEPIZZA board" for use in In-Circuit Emulators.

I understand the XC6SLX92TQG144C FPGA is now readily available again.

Thanks

Mick

I just got the following back via Ebay:-

Hello, dear friend

Very glad to hear from you! A big surprise that you still remember us.

Sorry for the late reply. We're leaving for the Chinese Spring Festival.

Sure! We're willing, and going to bring the FPGA boards back to all of you.

So, looks like there may be a fresh supply of the boards he used to sell.

Fingers crossed and I'll update with any further news

BR

Mick

[hoglet]

So, looks like there may be a fresh supply of the boards he used to sell.

That all sounds very positive. I'll keep my fingers crossed.

Dave

[1980s_john]

Hi,
Can I add my name to the list of interested parties for an ICE T65/Z80. I've had a look at the Github AtomBusMon page, is there an up-date BoM for making a unit?

I'm also slightly confused about which development board is current, the wiki (updated in 2016?) talks about a GODIL, but this thread says need a XC6SLX9 Mini Board.

Is there a plan to move to an integrated ICE T65 board that includes the processor, eg in the style of the Greaseweazle , which in earlier form used a Blue Pill?

Regards,
John

[hoglet]

I'm also slightly confused about which development board is current, the wiki (updated in 2016?) talks about a GODIL, but this thread says need a XC6SLX9 Mini Board.

Unfortunately both FPGA boards are unavailable at the moment.

The XC6SLX9 Mini Board (from eepizza) may come back into production soon.

Can I add my name to the list of interested parties for an ICE T65/Z80. I've had a look at the Github AtomBusMon page, is there an up-date BoM for making a unit?

With the XC6SLX9 Mini Board there is a seperate adapter board for each CPU.
https://github.com/hoglet67/AtomBusMon/ ... PU-Adapter
https://github.com/hoglet67/AtomBusMon/ ... PU-Adapter

Is there a plan to move to an integrated ICE T65 board that includes the processor, eg in the style of the Greaseweazle , which in earlier form used a Blue Pill?

There are no plans currently to produce an integrated unit.

Dave