AIM-65 homebuilt semi-replica

[rwiker]

Would using an edge-triggered latch work better (i.e, '374/'574 instead of '373/573)?

[Marta]

Two problems. It will present false addresses just when phi2 goes active and until the address propagates through the decoding logic. It will also take away lots of access time available with a transparent latch.

[Marta]

Now I have checked the signals with a scope. Edges from HC245 was very slow and irregular. Measured it's Vcc and that too had signals! Instantly found the reason, the wire was not soldered to the cards power plane

Soldered the wire and signals looks good. Not sure if there are some contention. Power looks clean, but is heavily decoupled and can probably take a contention whitout excessive noise.

Expectations was very high when testing JSR (ABS,X). Result: FAIL!

That was really disappointing and my troubleshooting ideas starts to dry up.

The setup is now back as it was from the beginning, as that was the only one of the tried alternatives that AFAIK works except for that instruction. One difference, phi2 now has two 245 channels in parallel. The signal looks fine on my scope, but it's too slow to see if the 5ns rise time is met.

The sortware now has capabilities to read back the memory. Everything tested compares perfectly to the original file.

It would be interestning to run the obstructing instruction wiith a logic analyser. Unfortunately I have no access to any...

[BigEd]

Is it still the case that JSR(ABS,X) is fine, except when the instruction sits across a page boundary? It's a three byte instruction, so there are two ways to straddle a page boundary - do both fail the same way?

Have you any idea what the misbehaving JSR does? Can you perhaps check afterwards what got pushed on the stack, if anything? Can you set up code at various guessed destinations to see where you land? Does the value of X make any difference?

[Dr Jefyll]

Nice to hear about the progress with troubleshooting. Regarding your post from yesterday, ....

Marta wrote:

The diagram has a magic symbol, red marked in the picture, that I wonder what it is.

I'm guessing -- and with WDC doc that's not unusual -- but I suspect the odd symbol simply denotes that that segment of the bus is bidirectional.

Quote:

My chips are old Sanyo, are there any known differences with the TSMC chips?

Probably the old Sanyo electrical and timing specs weren't quite up to modern TSMC standards, but with a 1 MHz project which loads the bus only lightly (ie, all or mostly MOS devices) odds are you'll be OK. Slower timing can even be a benefit in some ways! Also, from the Wikipedia article I gather that Sanyo 816's (unlike the modern WDC product) were not fully static. But I can't see why that'd affect your troubleshooting so far.

Quote:

The setup is now back as it was from the beginning

Rather than asking us to mentally edit and rewind, perhaps it'd be better to provide a fresh description. Furthermore, I think we would benefit from a full (or at least fuller) schematic. Some additional photos may prove helpful, too.

Quote:

It would be interestning to run the obstructing instruction wiith a logic analyser. Unfortunately I have no access to any...

The scope can be as good (or better)! Admittedly, with an analog scope only a small time slice can be viewed. Also you need the cycles in question to happen repeatedly. But that's easy to do if the machine is capable of executing a loop. And if not you can apply a pulse train to /RESET, using an EPROM whose reset vector points directly to the test snippet! Or have an EPROM which is entirely filled with identical successive iterations of the snippet.

BTW and FWIW, I think it's best to assume that other things may also broken, not just JSR (ABS,X) instruction.

-- Jeff

[Marta]

The problems are not connected to page crossing, that was a false track.

I have no idea of where the JSR goes, will try to find out. I'm sure it does not hit the intended target.


I will buy new chips next time an opportunity comes up. Maybe the problems disappears... If those chips has dynamic registers, there must be a lowest clock rate. Maybe web archive has an old data sheet.

The setup only has fragmentary schematics of the address decoding. Everything else is wire wound on "freehand"... I will try to find some vector drawing for Linux where a line is just a line and make a complete schematic.
The current setup around the demux is as shown in the data sheet, but now has separate inverters in the same HC04 for latch and buffer.

The scope indicated there are large undershoots of 400mV and ringings. They might be false, it's very short wiring here, the chips are placed close together. I will do more measures tomorrow and post scope photos. Will also get a better image of the card.

Thanks for all Your's info and advices.

[BigEd]

> The problems are not connected to page crossing, that was a false track.

Oh, that's good, because that was really hard to explain!

[Dr Jefyll]

Marta wrote:

The scope indicated there are large undershoots of 400mV and ringings. They might be false, it's very short wiring here, the chips are placed close together.

Probably you're already aware, but here's a reminder for everyone. For all except the very crudest of measurements, it's IMPERATIVE to make use of the ground lead on the probe end of the 'scope lead!! Connect it to ground of the circuit under test.

Quote:

The setup only has fragmentary schematics of the address decoding. [...] I will try to find some vector drawing for Linux

Well, suit yourself. But a hand drawn schematic will communicate the same information. (BTW, it's the glue logic I'm most curious about. You needn't draw all the individual bus connections -- a hand drawn block diagram is sufficient for that.)

Quote:

I have no idea of where the JSR goes, will try to find out.

To answer this question you could arrange things so the entire memory space seems to be filled with the value $FC. One way to do so is to remove the '245 that attaches to the CPU data bus and instead attach 6 pullup and 2 pulldown resistors. The CPU will endlessly repeat JSR ($FCFC,X) and you can examine the cycle-by-cycle behavior on the scope.

Edit: the resistors should be fairly low value -- 1K, say. That's because on an '816 there's limited time for them to do their job. During every Phi2-low period the CPU drives the Bank Address onto the data bus.

-- Jeff

[GARTHWILSON]

Dr Jefyll wrote:

Marta wrote:

The setup only has fragmentary schematics of the address decoding. [...] I will try to find some vector drawing for Linux

Well, suit yourself. But a hand drawn schematic will communicate the same information. (BTW, it's the glue logic I'm most curious about. You needn't draw all the individual bus connections -- a hand drawn block diagram is sufficient for that.)

I will second that.  Do not be intimidated by a supposed lack of nice schematic (or other) software tools for presentation, whether for the forum or even a website.  Actually, there are things about all schematic software I've evaluated that I don't like, so I still do my schematics by hand.  The biggest one I have published is at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU, but some I've done for work have been much larger, drawing very small on 18"x24" paper, hundreds of parts on one sheet (although mostly analog circuitry).  The only reason I drew up the diagram linked here is because so many people asked for a full diagram containing the entire computer.  Really though, that's kind of like doing an exploded view of an entire car in one diagram, with the steering mechanism's parts in the same diagram with the windshield wipers' parts and the tail light parts.  I don't have a diagram for my workbench computer, only diagrams for individual portions as shown at http://wilsonminesco.com/BenchCPU/B1QRG/ .

[Marta]

I will make a hand drawn schematic of the computer part and scan.

I have done some tests to find out where the JSR (ABS,X) actually goes. What I found is that this is 100% pure black magic.

The actual target page address is the specified one.
The specified low address makes no difference. It's just ignored.
Adding to X and subracting the same from base address: no change.
Moving the JSR (ABS,X) in a field of NOP's: no change.
Placing different values adjacent to indirect address: no change.
Moving indirect addres: target address jumps apparently irregularly.
The erroneus actual target is stable.
Moving indirect address an even page gives a new random target.

The test was done in native mode to have long A available as a counter.

Code: Select all

00002 00000
00003 00000                     .pt w-65c816
00004 00000                     .nt crap.bin
00005 00000                     .tf
00006 00000
00007 00000                     .or $b000
00008 0b000             main
00009 0b000  18                 clc                     native
00010 0b001  fb                 xce
00011 0b002  c2 10              rep #$10                idx16
00012 0b004
00013 0b004  a2 00 02           ldx ##$200              inc a fill
00014 0b007  a9 1a              lda #$1a
00015 0b009  95 00      .nxt    sta 0,x
00016 0b00b  e8                 inx
00017 0b00c  e0 00 80           cpx ##$8000
00018 0b00f  90 f8              blo .nxt
00019 0b011
00020 0b011  a9 4c              lda #$4c                put return jump
00021 0b013  8d 00 80           sta $8000
00022 0b016  a2 30 b0           ldx ##return
00023 0b019  8e 01 80           stx $8001
00024 0b01c
00025 0b01c  e2 10              sep #$10                idx8
00026 0b01e  c2 20              rep #$20                acc16
00027 0b020
00028 0b020  a9 00 00           lda ##0                 off we go...
00029 0b023  a2 66              ldx #102
00030 0b025  ea                 nop
00031 0b026  fc 45 b2           jsr (indadr-102,x)
00032 0b029  ea                 nop
00033 0b02a  ea                 nop
00034 0b02b  ea                 nop
00035 0b02c  ea                 nop
00036 0b02d  ea                 nop
00037 0b02e  ea                 nop
00038 0b02f  ea                 nop
00039 0b030
00040 0b030             return
00041 0b030  49 ff ff           eor ##$ffff             convert to address
00042 0b033  38                 sec
00043 0b034  69 00 80           adc ##$8000
00044 0b037
00045 0b037  38                 sec                     emul
00046 0b038  fb                 xce
00047 0b039
00048 0b039  48                 pha                     show it
00049 0b03a  eb                 xba
00050 0b03b  20 46 ea           jsr $ea46               aim numa
00051 0b03e  68                 pla
00052 0b03f  20 46 ea           jsr $ea46
00053 0b042
00054 0b042                     *                       show return address
00055 0b042  20 3b e8           jsr $e83b               aim blank2
00056 0b045  fa                 plx
00057 0b046  68                 pla
00058 0b047  da                 phx
00059 0b048  20 46 ea           jsr $ea46               aim numa
00060 0b04b  68                 pla
00061 0b04c  20 46 ea           jsr $ea46
00062 0b04f
00063 0b04f  60                 rts                     exit
00064 0b050
00065 0b050  4c 50 b0           jmp @                   stop!
00066 0b053
00067 0b053                     .bs 256-(@\256)+256+130+25+16
00068 0b2ab
00069 0b2ab
00070 0b2ab  00 45      indadr  .da $4500
00071 0b2ad                     .bs 300
00072 0b3d9
00073 0b3d9  ff ff ff ff        .bs 256-(@\256)\256
00074 0b400
00075 0b400
00076 0b400                     .en

Changed plain source to an assembly listing.

[Marta]

Here is my very ugly schematic. Had to use mobile camera. Scanner failed. Something must have been "upgraded" on my Linux...

The inverters are 74HC04. The triangles without rings are a HC245 channel. A0..A3 are buffered.
The unbuffered addresses only connects to RAM, PROM and video mux HC157.
The buffered addresses also goes to the other chips and mux for PGRAM and raster addresses.
R/W is also buffered, missed that on the drawing.
The parallel buffers on phi2 are a result of testing separate ones for CPU and system. Phi2 goes in parallel to everywhere needed, two VIA's, CRTC and several CMOS gate inputs. All data buffer enable are qualified by phi2. Same goes for read/write of PGRAM and write of write-only CGRAM.

[Marta]

This is a scope photo of BA4. 5VV, 100ns per square. Last calibrated 30 years ago...
Ground tail of course securely connected to the cards ground plane...

There are substantial ringing and overshots, Much more than expected.The 245 and 373 sits alongside the CPU just 7.5mm apart from it. Nothing else are connected to those lines. Top of the leading edge looks strange. Maybe there is some contention?

[BigEd]

Hmm, where's the code at $41ff ? (Or is that $ff41 ??)

It's possible your assembler is letting you down: perhaps you could share the listing file?

Can you give an example of where the JSR did land, with the inputs and the code you gave it, in one particular case?

[Marta]

As I wrote, the first two hex digits of the target address are correct, the two last hex digits are don't care. Has no effect at all. But if I move the location for the indirect address bytes, then it "lands" at a completely new address without any apparent relation. F.ex $41?? goes to $410C with the indirect at $b482. Moves it up one to b483 and it lands on 418a. Those might be bytes read from some unknown location, I don't now. Maybe looking for 0c8a and if found try more adjacent addresses?

The assembler is new, but all OP's in all addressing modes has been validated. It assembles the AIM monitor to a file that compares to a preassembled one. That of cource does not test the 816-only's, but I have hand validated this program.

[John West]

BigEd wrote:

Hmm, where's the code at $41ff ? (Or is that $ff41 ??)

The loop 'nxt' fills memory from $0200 to $7fff with INC A instructions, then a JMP is written to $8000. The value in A will tell you where the JSR landed.

But yes, the listing file is essential, especially with a new assembler. Even just a hex dump of the binary file. Hand-validation only tests things up to your understanding of how it should work, and even with correct understanding it's easy to make a mistake.