6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 7:37 am

All times are UTC




Post new topic Reply to topic  [ 178 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11, 12  Next
Author Message
PostPosted: Tue Sep 05, 2023 11:16 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
sburrow wrote:
I was reading through it, and looking at the pictures, thinking, "What the heebee's are you even doing?!" But then I realized, "Oh yeah, wire-wrap." I really like your idea here! You've got a good variety of sockets, the placement looks good, and the idea is great. If you have a really solid power/ground grid, then everything else will work out really well :)
Thanks Chad! That's just what I was thinking. Having rock solid power and ground up front will give me a good foundation for whatever particular design I want to try. I will build my foundation on ... solid ... ground ... :D :D

There is a practical limit of sorts to the number of times you can re-do a wrap (the posts start getting kind of chewed up after a while) but I figure this will give me a lot of flexibility in terms of reconfiguring decoding logic. If I need to add an IC I'll have plenty of spare sockets. There's a bit of board left around the edges for adding discrete components as well, if I need more pull-ups or some diodes or whatever.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 15, 2023 12:31 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Last week I finished building the "SPC." To try it out I put the new faster (V2) version of Blue August on it. The "SPC" works great. The faster version of Blue August works too... kind of. Which is to say, it works exactly like the old one, except faster. So now I can go splat at 16MHz instead of 10MHz! :lol: :x

I decided that this is too hard to troubleshoot because I'm trying to do too many new things at once. Clock stretching, RAM banking, new power supply, logic analyzer, etc. So, I took Blue August back off the SPC and built this:
Attachment:
Screen Shot 2023-09-14 at 7.58.21 PM.png
Screen Shot 2023-09-14 at 7.58.21 PM.png [ 93.66 KiB | Viewed 6692 times ]
(There's also a 6502 and some ROM; no RAM or I/O, but the signals to drive them are generated so I can look at the timing.) This works perfectly fine with the clock stretcher tied low (i.e., 4MHz). There's an area of my testing code that does this:
Code:
STZ     $00
STZ     $01
.
.
STZ     $0E
STZ     $0F
When I enable the clock stretcher by connecting the "NC" wire on the schematic instead of the ground wire, I start having problems. I think. It doesn't go splat the way Blue August did (with the data bus flooded with junk and RDY going low). But what does happen is that I start seeing 'STZ $00' for all 16 STZs. So, maybe the clock stretcher is causing a problem I don't understand. But, maybe the board is working fine, and the clock stretcher is confusing the capture. I recall George saying he had some trouble with his I/O wait states. One thing that makes me suspect maybe the LA is getting confused is that the board never seems to stall out the way previous ones did. When I probe it with my scope I see activity on the control lines, the bus lines are switching, and so on. I don't understand why my clock stretcher would confuse the capture, though. I'm using the --IFCLK=xi mode, with the IFCLK pin connected to the same clock signal that the CPU is getting. So it should just capture on every falling edge. I wouldn't think it would care how much time has elapsed between edges.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 15, 2023 1:28 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
Paganini wrote:
I don't understand why my clock stretcher would confuse the capture, though. I'm using the --IFCLK=xi mode, with the IFCLK pin connected to the same clock signal that the CPU is getting. So it should just capture on every falling edge. I wouldn't think it would care how much time has elapsed between edges.

In this mode the logic analyser's microcontroller is itself running from your IFCLK, and it requires at least a certain clock speed - especially, the duration of any low or high clock phase must be below a certain time. The issue I was having was that my stretched clock had very long "high" phases, and the LA would glitch or reset at those points.

To fix it I had to connect IFCLK to the unstretched clock, rather than the stretched clock, but also connect PA4 or PA5 to the stretching signal depending on its polarity - the LA ignores any clock cycle when PA4 is high or PA5 is low (or the other way around, I forget). So this way it receives a nice fast clock to run from, that's in sync with your cpu clock, but is told to ignore the false cycles during stretching, and not capture them.

As a test, you can also use the unstretched clock without connecting the stretch signal to PA4 or PA5, and it will just oversample during stretching. The decoder won't understand this, but you can at least look at the hex values captured to check it looks reasonable by eye. Then connect PA4 or PA5 as appropriate and compare, to check that's working.

I did wonder whether it was worth extending the decoder to be able to know when stretching would occur, but it wouldn't have worked in my system. It would be possible for your system though, as the stretching is predictable. Still I think PA4/PA5 is a better solution.


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 15, 2023 3:37 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
I changed my tester program this morning to get a better idea of what's going on. I have it loading an immediate value into .A (slow clock, reading instructions and values from ROM) and then writing the value to different addresses in the I/O space (just one fast cycle). It seems as though the board *is* working; what happens is that the LA occasionally misses a fast clock pulse and gets confused. So instead of LDA #5, STA IO5, LDA #6, STA IO6, LDA #7, STA IO7, every so often it will just see LDA #5, LDA #6, LDA #7. I don't have a DSO scope, but as far as I can tell with my analog one the board isn't actually missing any write cycles. The fast cycles are only about 60ns, so maybe that's just at the very edge of what the LA can handle. I'll try swapping in some slower oscillators and see if there's a point where it never gets confused. If it still gets confused at slower speeds, maybe I'm wrong and the board is glitching but I just can't see it on the scope.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 15, 2023 5:22 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
I'm not sure that a slower clock will help, it may make things worse in the IFCLK mode. The datasheet (https://www.keil.com/dd/docs/datashts/c ... xxx_ds.pdf) says in table 9-10 that for Slave FIFO Sychronous Write mode with external IFCLK, the clock period must be at most 200ns, i.e. a frequency of at least 5MHz. So it may be malfunctioning when driven below that speed. This is where what I said above might help - supplying it with a fast unstretched clock to drive the microcontroller, but telling it which clock pulses to then skip when sampling data.

If you were to use a slower clock speed for your circuit then I think you'd need to use the asynchronous mode instead, with your clock connected to whichever of the RDY pins is correct. But you'd really need your fast clock to be a lot slower for this to work reliably - maybe a slow as your slow clock currently is!


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 15, 2023 7:22 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
I think that pretty much nails the problem, George. It's hard to find a speed where both Ø2 and Ø2/4 fall within the capabilities of some operating mode of the dev board. I went back to async mode at 4MHz / 1MHz and can capture indefinitely without any problems.

I did try what you described, using a fast clock and disabling the dev board for stretched cycles, but I couldn't get it to capture at all. I probably had something wired up wrong. There are so many little fussy opportunities for mistakes with this device! Maybe after lunch I'll try that one again with a fresh brain.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 15, 2023 10:52 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
I had a look at this, and I think I see where the problem might lie - I'm not sure whether any signals in your circuit already are quite right for what's needed. Here's a timing diagram as far as I can see, showing a couple of fast cycles and one slow cycle:

Attachment:
paganini_clockstretch.png
paganini_clockstretch.png [ 6.13 KiB | Viewed 6623 times ]


(Sorry it's so large, the forum seems to scale up the previews when things are not very tall!)

The signal I'd suggest sending to IFCLK is the one from Q0 of the counter - it is consistent and fast enough for the logic analyser, and it falls in sync with PHI2 most of the time, except during stretching which we'll need to fix.

I would try just wiring Q0 to IFCLK and not trying to make it skip any cycles first of all, to look at the raw data stream and see if it at least looks like it's working but capturing too much during stretching.

During stretching it is going to sample on all of the red and green marked edges, when we'd really like it to only sample on the green ones. So we need a signal that's high for the green edges, and low for the red edges - or vice versa. In my circuit I happened to have one handy, but in yours unfortunately CLK_STRETCH isn't it - it doesn't change back from low to high soon enough at the end of stretching.

The thing that's actually causing PHI2 to go low - stretching or not - is Q1 and Q2 both being high prior to the marked edges. In this case a falling edge on Q0 is going to "increment" Q1, causing it to carry into Q2, causing it in turn to go from high to low. So one option that might work could be an AND between Q1 and Q2, which will be high if the logic analyser should take a sample, and low otherwise.

Another option that ought to work is to use the TC output of the counter - this will go low (or is it high? I forget) for the cycle just before PHI2 goes low, so it seems ideal.

Either of these might work, but they may need slight delays or latching, as while they're both valid leading up to the fall of Q0, they change immediately after it - especially TC, which will change at the same time as Q0 - and the logic analyser might want a bit of hold time there.

As you said, with clock stretching (equally, RDY, WAI, etc) this is a bit fiddly to get to work, and it's interesting that our two circuits need different handling. I have made an adapter to make it easier and more reliable to connect the logic analyser to my system - and my system has other elements that make it rather awkward without the adapter - and having thought about your circuit, I think I can see a way to make the adapter work for both. I will have to think about that some more.

In the meantime, I'm hopeful the above ideas will work, and if they don't, I'll be interested to hear what goes wrong!


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 16, 2023 2:07 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Hi George,

Thanks for putting so much thought into this! Your diagram is hilariously huge. But that's not such a bad thing. Now that I'm middle-aged I have to wear magnifiers constantly to work on this stuff, so it's nice and easy to see! :shock: 8) :shock:

Upthread a ways you will find a PDF called "Clock Register." Here it is again:
Attachment:
Clock Register.pdf [214.13 KiB]
Downloaded 36 times
It has all the possible states where the `163 loads on one tap. Here are a couple of relevant excerpts, so you don't have to download the whole PDF if you don't feel like it:
Attachment:
File comment: Fast clock
Screen Shot 2023-09-15 at 8.39.47 PM.png
Screen Shot 2023-09-15 at 8.39.47 PM.png [ 41.46 KiB | Viewed 6614 times ]
Attachment:
File comment: Slow clock
Screen Shot 2023-09-15 at 8.41.11 PM.png
Screen Shot 2023-09-15 at 8.41.11 PM.png [ 38.98 KiB | Viewed 6614 times ]
My "Clock Stretch" signal (actually just the ROM chip select for now) pulls Q1 and Q2 low for ROM cycles, and drives Q1 and Q2 high for RAM cycles. Because the counter load is synchronous and the decision to stretch is always made before the rise of Q0, we get nice transitions between the two states (a long low is always followed by a long high, and a short low is always followed by a short high). This is more or less what you already just said; these are just the diagrams I've been using to express these ideas to myself, and they also include TC, so you can see how it fits into the picture.

gfoot wrote:
I would try just wiring Q0 to IFCLK and not trying to make it skip any cycles first of all, to look at the raw data stream and see if it at least looks like it's working but capturing too much during stretching.
I got this far after lunch; the first try before lunch I had A4 wired up wrong, so I wasn't capturing anything! I did do some other things this afternoon that give me confidence that my board is working; I wired up some RAM and then, at a capture friendly speed, I ran a RAM test. Then I sped back up to 16MHz / 4MHz and took another (garbled) capture. With the clean capture and the garbled capture side by side it was pretty easy to pick out where there were missing bus cycles. Also, to communicate results, the RAM tester jumps to infinite loops at various locations in the ROM (for example, RAM_OK: jmp RAM_OK is located at $F000, while BAD_RAM1: jmp BAD_RAM1 is located at $A000), so I can take an additional capture after the test is concluded to see if it succeeded or failed (since it's only accessing ROM by then, there are no fast cycles to confuse the fx2). Even though the missing bus cycles confused the decoder, I could see that it was executing properly and getting to the RAM_OK result.
gfoot wrote:
So one option that might work could be an AND between Q1 and Q2, which will be high if the logic analyser should take a sample, and low otherwise.

Another option that ought to work is to use the TC output of the counter - this will go low (or is it high? I forget) for the cycle just before PHI2 goes low, so it seems ideal.

Either of these might work, but they may need slight delays or latching, as while they're both valid leading up to the fall of Q0, they change immediately after it - especially TC, which will change at the same time as Q0 - and the logic analyser might want a bit of hold time there.
I have PA5 hooked up to RESET\, so I'd like a signal to connect to PA4 that is high during the slow clock cycles and low to enable sampling. I think NANDing Q1/Q2 or Inverting TC would give me the right signal, but I dunno if one gate delay would be enough. I do have some `HC14s, which might be just the right thing for inverting TC. IIRC, they have a 10ns-ish propagation delay. As a bonus, I'm not actually using TC for anything, so it would be easy to wire up!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 16, 2023 6:53 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Welp, time to get down into the thick of it! I tried both of those ideas, first inverting the TC signal with an `HC14, and now NANDing Q1 and Q2 with an `HC00. They both sort of work, in that they don't just capture garbage - I can see the capture working most of the time, and the decoder producing a correct instruction stream, most of the time. But, with both configurations, the FX2 still gets out of sync. Here is the first missed instruction, preceded by a good one.
Code:
00000063  0 36 ? ? ?
00000064  1 00 ? ? ?
00000065  2 00 ? ? ?
00000066  3 40 ? ? ?
00000067  4 40 ? ? ?
00000068  5 80 ? ? ?
Rd:   8008 = 36
Rd:   8009 = 00
Rd:   0000 = 40
Wr:   0000 = 80                                                                        ; Correct instructions
8008 : 36 00    : ROL 00,X       : 6 : A=00 X=00 Y=02 SP=?? N=1 V=? D=0 I=1 Z=0 C=0    ;
00000069  0 88 ? ? ?                                                                   ; 88  dey
0000006a  1 d0 ? ? ?                                                                   ; d0
0000006b  2 d0 ? ? ?                                                                   ; fb  bne .2 - we read d0 twice
0000006c  3 fb ? ? ?                                                                   ; 90         - then maybe skipped from here...
0000006d  4 90 ? ? ?                                                                   ; 52  bce F1
0000006e  5 36 ? ? ?                                                                   ; B5
0000006f  6 00 ? ? ?                                                                   ; 00  lda $0,x
00000070  7 00 ? ? ?                                                                   ; D0
00000071  8 80 ? ? ?                                                                   ; 51  bne F2 - these branches are not taken
???? :          : RESET !!       : 9 : A=?? X=?? Y=?? SP=?? N=? V=? D=0 I=1 Z=? C=?
00000072  0 80 ? ? ?                                                                   ; A2

Where did these 80s come from? There are no 80s in the instruction stream, ever. The only byte in the whole ROM that is $80 is the high byte of the reset vector (which explains why the decoder thought this was a reset!) so this must be a read cycle (lda $0,x (B500) ( reading back the value of we just wrote to RAM. Or, it could be the write cycle from the next time through the loop, meaning we missed a LOT of cycles.

00000073  1 00 ? ? ?                                                                   ; 00  ldx #0
00000074  2 88 ? ? ?                                                                   ; 18  clc
Rd:   8000 = 80                                                                        ; A9
memory modelling failed at   8000: expected A2 actual 80
Rd:   8001 = 00                                                                        ; FF  lda #FF
8000 : 80 00    : BRA 8002       : 3 : A=?? X=?? Y=?? SP=?? N=? V=? D=0 I=1 Z=? C=? prediction failed
                                                                                       ; 95
                                                                                       ; 00 sta $0,x
                                                                                       ; A0
                                                                                       ; 09 ldy #9
                                                                                       ; 36          - ...to here, so we missed 15 cycles
                                                                                       ; 00 rol $0,x - then read this one twice, maybe?
                                                                                       ; 88 dey          - and this one too
                                                                                       ; D0          - the capture is back on track for a couple of instructions
                                                                                       ; FB bne .4   - but then it gets off again after this FB
I'm not sure what this tells me in detail, but it seems clear that the FX2 is sometimes missing cycles and sometimes reading a cycle two times, which sure seems like a clock synchronization problem. Before I do anything else, I'm going to try a couple of things to see if I can make sure it's not just some local (host-side) USB problem, or some such thing, causing the FX2 to glitch. After that, I'm going to rig up the FX2 to clock on the *rising* edge of the oscillator (32MHz), which is what governs all of the system timing. I should get lots of captures I don't want, but I shouldn't *miss* anything, so that will tell me something.

Addendum: Before doing those things, it occurred to me to try a 16-bit capture with R/W\ and SYNC mixed back in; if those 80s were from RAM reads/writes, having access to those signals might help the decoder sort things out. So I did that; I got a much better result. The capture didn't get out of sync for many cycles. Then, while executing this loop:
Code:
Last good time through the loop:
0003c3f2  0 98 O 1 ?
0003c3f3  1 91 D 1 ?
Rd:   8032 = 98
8032 : 98       : TYA            : 2 : A=46 X=00 Y=46 SP=?? N=0 V=? D=0
 I=1 Z=0 C=0
0003c3f4  0 91 O 1 ?
0003c3f5  1 00 D 1 ?
0003c3f6  2 00 D 1 ?
0003c3f7  3 3e D 1 ?
0003c3f8  4 3e D 1 ?
0003c3f9  5 46 D 0 ?
Rd:   8033 = 91
Rd:   8034 = 00
Rd:   0000 = 00
Rd:   0001 = 3E
Wr:   3E46 = 46
8033 : 91 00    : STA (00),Y     : 6 : A=46 X=00 Y=46 SP=?? N=0 V=? D=0 I=1 Z=0 C=0
0003c3fa  0 88 O 1 ?
0003c3fb  1 d0 D 1 ?
Rd:   8035 = 88
8035 : 88       : DEY            : 2 : A=46 X=00 Y=45 SP=?? N=0 V=? D=0 I=1 Z=0 C=0
0003c3fc  0 d0 O 1 ?
0003c3fd  1 fa D 1 ?
0003c3fe  2 98 D 1 ?
Rd:   8036 = D0
Rd:   8037 = FA
8036 : D0 FA    : BNE 8032       : 3 : A=46 X=00 Y=45 SP=?? N=0 V=? D=0 I=1 Z=0 C=0
Code:
Failed time through the loop:
opcode 98: cycle prediction fail: expected 2 actual 5
0003c3ff  0 98 O 1 ?
0003c400  1 91 D 1 ?
0003c401  2 3e D 1 ?
0003c402  3 3e D 1 ?
0003c403  4 3a D 0 ?                    ; Where did this 3A come from? Did we sample the bus while the lines were changing?
Rd:   8032 = 98
8032 : 98       : TYA            : 5 : A=45 X=00 Y=45 SP=?? N=0 V=? D=0 I=1 Z=0 C=0
0003c404  0 88 O 1 ?
0003c405  1 d0 D 1 ?
Rd:   8033 = 88                         ; Now we're out of sync, this read is actually from $8035
memory modelling failed at   8033: expected 91 actual 88
8033 : 88       : DEY            : 2 : A=45 X=00 Y=44 SP=?? N=0 V=? D=0 I=1 Z=0 C=0 prediction failed
0003c406  0 d0 O 1 ?
0003c407  1 fa D 1 ?
0003c408  2 98 D 1 ?
Rd:   8034 = D0                         ; $8036
memory modelling failed at   8034: expected 00 actual D0
Rd:   8035 = FA                         ; $8037
memory modelling failed at   8035: expected 88 actual FA
8034 : D0 FA    : BNE 8030       : 3 : A=45 X=00 Y=44 SP=?? N=0 V=? D=0 I=1 Z=0 C=0 prediction failed
This is actually BNE 8032; the decoder is two-bytes off from the actual PC.


Edit: BTW, things get better if I slow down. With an 8MHz oscillator (4Mhz / 1MHz) I get error free captures.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 16, 2023 8:00 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
Just a quick note with something that jumped out - I'll look more a bit later:

Code:
Wr:   0000 = 80                                                                        ; Correct instructions
8008 : 36 00    : ROL 00,X       : 6 : A=00 X=00 Y=02 SP=?? N=1 V=? D=0 I=1 Z=0 C=0    ;
00000069  0 88 ? ? ?                                                                   ; 88  dey
0000006a  1 d0 ? ? ?                                                                   ; d0
0000006b  2 d0 ? ? ?                                                                   ; fb  bne .2 - we read d0 twice

Reading "d0" twice is normal - DEY is a two-cycle instruction, with the second cycle being an internal cycle. For these, the 6502 has to do something on the bus even though it doesn't care about the result, so it reads the next opcode redundantly. The first "d0" is this dummy cycle, the second is the true first cycle of the BNE. Normally the decoder decodes this but here I think it got confused because it thought it saw a reset. I'm not sure why it thought that - what do you pass for the --vecrst argument?

Code:
0000006c  3 fb ? ? ?                                                                   ; 90         - then maybe skipped from here...
0000006d  4 90 ? ? ?                                                                   ; 52  bce F1

So we have d0, fb, 90 - that's the BNE, to FB (signed -5). 90 will be the opcode of the instruction following BNE. If the branch is not taken then this is the first cycle of that next instruction; if the branch is taken though, it's discarded and the byte afterwards will be the next opcode, from PC-5. This kind of taken/not taken decision seems to be a pain point for the decoder - it's fine if its state is in sync, but after anything puts it out of sync, it gets these things wrong and things go from bad to worse. So it's important that it's always in sync, and the thing to diagnose and fix is usually the first failure it reports - anything after that is hard to navigate!

I suspect though that the "BNE" was taken, so the "90" opcode was ignored, and the next byte ($36) is the next opcode - it's executing the ROL again. The first one was:

Code:
    $36   - opcode
    $00   - address
    $00   - dummy reread of address
    $40   - read the value from $00,X
    $40   - dummy read
    $80   - write the rotated value back to $00,X


This second sequence is:

Code:
    $36   - opcode
    $00   - address
    $00   - dummy reread of address
    $80   - read the value from $00,X
    $80   - dummy read
    $00   - write the rotated value back to $00,X


So really that makes sense - it read $80 back, having written it earlier in the trace - and looks like these bytes were captured fine, just decoded wrong due to misdetecting a reset. I'm not sure how actively it looks for resets, I've never knowingly had this happen though. Ensuring you specify all three bytes for the reset vector argument might help.


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 16, 2023 8:39 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
> Ensuring you specify all three bytes for the reset vector argument might help.

I had to look that up... from the wiki:
Quote:
If RST is not connected, an alternative is to specify the reset vector:
- D9CD (D9 is the high byte, CD is the low byte)
- A9D9CD (optionally, also specify the first opcode, LDA # in this case)


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 16, 2023 9:39 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Hi George,

You're quite right; that branch was taken, my annotation was a mistake there. Currently, I use --vecrst=8000, although I did at some point try adding in the leading opcode (A2, I think, for this code). I don't know why I took it out again.

After I wrote that post, this afternoon I went ahead and tried switching between host computers. With Ariel, a 2015 MacBook Air running Ubuntu Jammy, I'm able to get error-free captures at 4MHz. I did 3 or so in a row to make sure it wasn't just a fluke, and I'm confident it isn't, because I was able to get good captures using the same configuration yesterday too. Switching over to my old Thinkpad X40 running an older version of ubuntu I got failures in the capture using the same identical configuration, to the degree I was able to control it. (I mean, same command arguments, same oscillator, locally built fx2pipe). So it seems at least some of the trouble may be from host side problems - USB not being fast enough, or some such thing.

I then went on and made an "enable" signal based on clocking the FX2 with the 32MHz clock, rather than Q0. I ran TC to the D input of a AHC74. I inverted the 32MHz signal with an AHC14 and used that to clock the flip flop. I attached the Q\ output of the flip-flop to the PA4 pin on the FX2. This gives an inverted TC signal that's a half-cycle out of phase with the master oscillator pulse. The results were just about perfect on the scope; I got a low pulse with the falling edge of Ø2 smack dab in the middle of it. Using this to drive the FX2 I actually got pretty good results... it didn't miss any instructions, but I got some memory model failures. In the capture, the decoder would think the CPU was reading or writing different values to/from RAM that it actually was. I don't understand why that would be; in theory the FX2 should be sampling the bus at exactly the same time the CPU does for reads, and for writes it should be sampling well within the hold time.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 22, 2023 9:23 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
I'm overdue for an update! My season has started, so I don't have as much time to spend in the workshop / online, but last week I did carry on adding "subsystems" to the super simple cut down version of Blue August I built on the SPC for troubleshooting. I got every part of it working in isolation, including the clock stretcher when it was connected *only* to the ROM_CS signal. However, any time I tried to multiplex multiple chip select signals I ran into trouble, even using a fast (AHCT08) AND gate. Then I remembered that, in his original post, Jeff had suggested using a diode matrix to connect multiple slow devices to the clock stretch signal. I thought I remembered that Jonathan Foucher's "Planck 6502" had used diodes successfully for this purpose, and indeed it does. I haven't done much with diodes, but I do have some 1N914 signal switching diodes left over from my keyboard adapter, so I rigged up a breadboard sidecar. I don't know if these are exactly the right kind of diodes to use for this, but they seem to work!
Attachment:
20230919_183217.jpg
20230919_183217.jpg [ 3.92 MiB | Viewed 6458 times ]
This runs at 16MHz / 4MHz, and is able to bank out the ROM and run from RAM. So, I'm going to tentatively say that I've got a finished design here. I'll have a finished board, too, as soon as I figure out where there's room to add a couple of diodes and more pin headers.
Attachment:
BlueAugust.pdf [56.79 KiB]
Downloaded 39 times

I never did manage to get completely error free captures with the logic analyzer. I went ahead and ordered one of these: https://www.amazon.com/dp/B0BLGNS946

Because the photo actually says "LCSOFT," I was hopeful that it might be one of the real mini-boards and not a generic product. Sadly, what I received was just another low quality generic board. After cleaning off a heavy coating of flux and resoldering a loose pin, the board does work, but not any better than the other one I have.

Nevertheless, I'm pretty happy with the current state of things. I realize 16MHz is not so fast, compared to some of the high-speed voodoo that Bill and George are doing, but this is the first time I've built a 6502 system clocked faster than the "official" 14MHz, so I am pleased.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 25, 2023 4:51 pm 
Offline

Joined: Sat Oct 09, 2021 11:21 am
Posts: 718
Location: Texas
Paganini wrote:
Nevertheless, I'm pretty happy with the current state of things. I realize 16MHz is not so fast, compared to some of the high-speed voodoo that Bill and George are doing, but this is the first time I've built a 6502 system clocked faster than the "official" 14MHz, so I am pleased.


Well, congrats! Heck, anything over 3 MHz is still scary to me :)

So, what's the next step? Are you going to use a different board revision and try again for higher speeds? Are you going to use this build for something special, adding peripherals and all that? Or, is there something entirely different that you have planned next? I know your job will keep you busy, but I personally always need to have a project in my mind so that I can work on it in my brain while driving a car, eating a meal, or laying around in bed at night.

Lots of learning here, and that's also an important take away. And mistakes help us learn even faster, even though it hurts. Hopefully there was a lot of take-away here for you. I've been learning vicariously too!

Thanks for the updates, excited to hear what the next project will be.

Chad


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 25, 2023 8:45 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Hi Chad!

Well, I haven't lost sight of the original goal of an honest-to-goodness retro-computer with case, front panel, ports to plug in display, keyboard, and so on. So, on the to-do list is building a card like this one for my VGA circuit (it's currently still on breadboards), and a similar I/O module with some VIAS and an ACIA.

But, because I'm a stubborn motherboarder, before I do that I'm going to go back and see if I can apply what I learned from the SPC to the problematic Blue August board. This will mean a little rejiggering of VCC and GND, but not much. I will also have to change the glue logic slightly in order to generate the chip select signals for the single 64k SRAM (the SPC has two 32k SRAMs). Since you ask, :) here's the current version of the working schematic for that:
Attachment:
BlueAugust2.pdf [67.01 KiB]
Downloaded 47 times
It's basically a cut and paste of the working subsystems from the SPC, plus glue logic tweaks. The old board had pull-downs on all the P inputs of the comparator, and they're the wrong value for TTL anyway, so I took that resistor pack off. I'm planning to try out the 74ALS520 on this one - it has internal 20k pullups on all the Q inputs, which is very convenient - I can leave them unconnected until I'm ready to attach them to the front-panel switches that pull them to ground.

I think this version might be eve faster than the SPC one. If my math is right, it should be able to manage 20MHz. I probably will not test it at 20MHz, though. For one thing, I don't have a 40MHz oscillator! For another, one of the reasons (in fact, the main one!) for exploring the clock stretcher with this project is that I want to use a bug-free Rockwell ACIA for my serial port. They're specced for 4MHz, which is why my target speed this whole time has been 16MHz / 4MHz. I have heard that those Rockwell ACIAs can be overclocked, so maybe I'll try 20MHz / 5MHz at some point, once the board is working really well. :)

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 178 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11, 12  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 42 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: