6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Nov 12, 2024 3:49 am

All times are UTC




Post new topic Reply to topic  [ 178 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 12  Next
Author Message
PostPosted: Thu Aug 10, 2023 12:34 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
Even though I haven't figured out what to do about construction yet, today I hooked up my keyboard card and "ported" PAGIMON over to Blue August so I could do some more testing. (Does it count as porting if you only have to change 2 addresses?) I also ordered some more oscillators so next week I'll be able to try some different speeds and see how it responds.

In the meantime I think I've discovered a real problem. My output port for ROM banking doesn't work like how I think it should. *ANY* write to the output port's I/O range results in a total lockup, even a write of "0."
Attachment:
Screen Shot 2023-08-09 at 8.18.21 PM.png
Screen Shot 2023-08-09 at 8.18.21 PM.png [ 17.88 KiB | Viewed 6654 times ]
I have a spare line on Port B of the VIA (the LCD only uses 7 bits) that I can use for testing, but in the long run I was planning to not have a VIA on the main board. I've checked the wiring 2 or 3 times to make sure it matches the schematic, so I must have made a real thinking error. :(


Attachments:
Glue-v2.pdf [87.35 KiB]
Downloaded 38 times

_________________
"The key is not to let the hardware sense any fear." - Radical Brad
Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 10, 2023 8:00 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
Paganini wrote:
In the meantime I think I've discovered a real problem. My output port for ROM banking doesn't work like how I think it should. *ANY* write to the output port's I/O range results in a total lockup, even a write of "0."

The 6502 doesn't drive its data bus immediately during write operations. For RAM this doesn't matter because by the time the operation ends (phi2 falls) the data is there, and the RAM writes continuously during the cycle. But your flipflop is edge-triggered so it only samples D0 at the start of the operation, when the data may not be ready yet. Using an OR gate may fix the issue as the sample would occur at the end instead.

Something there must also be qualified with phi2 - you need to sample D0 around its trailing edge. So if either /WRITE or /DEV0CS is already qualified then that's fine. If not then phi2 needs to feed in here as well.


Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 10, 2023 3:17 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
gfoot wrote:
The 6502 doesn't drive its data bus immediately during write operations. For RAM this doesn't matter because by the time the operation ends (phi2 falls) the data is there, and the RAM writes continuously during the cycle. But your flipflop is edge-triggered so it only samples D0 at the start of the operation, when the data may not be ready yet. Using an OR gate may fix the issue as the sample would occur at the end instead.
The idea being that the OR gate will go high when the 6502 releases the write strobe at the end of Ø2, so the flip-flop will latch during tDH in immediately following Ø1, right?

Honestly, I'm experiencing some strange confusion here. I got the idea for a 1-bit output port from this article: https://www.atarimagazines.com/computei ... page17.php where the author clearly uses an OR gate (even though the text says AND). In my original glue logic, I used an HC32. In glue v2 it has changed to a NOR gate, but I don't remember changing it, or why!

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 10, 2023 4:07 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
Paganini wrote:
gfoot wrote:
Using an OR gate may fix the issue as the sample would occur at the end instead.
The idea being that the OR gate will go high when the 6502 releases the write strobe at the end of Ø2, so the flip-flop will latch during tDH in immediately following Ø1, right?

Yes exactly. For these kinds of thing - whether they're asynchronous, continuously sampling their inputs while their activation signal is low, or synchronous like flipflops, only sampling it once at the rising edge - you can use the same active-low signal and it all works out.

Quote:
Honestly, I'm experiencing some strange confusion here. I got the idea for a 1-bit output port from this article: https://www.atarimagazines.com/computei ... page17.php where the author clearly uses an OR gate (even though the text says AND). In my original glue logic, I used an HC32. In glue v2 it has changed to a NOR gate, but I don't remember changing it, or why!

HC32 should do the trick, yes. Perhaps they wrote "and" because logically it is an "and" operation, but with active-low signals so in positive-logic terms it's an "or".


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 11, 2023 12:27 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
`HC32 sorted it all out. :D I had just verified that my copy ROM to RAM routine worked and I was indeed running from RAM, when a tree fell down and took out power to the neighborhood for about 9 hours!

Updated schematic:
Attachment:
Glue-v2.pdf [79.61 KiB]
Downloaded 41 times

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


Top
 Profile  
Reply with quote  
 Post subject: Take 2
PostPosted: Sun Aug 20, 2023 4:56 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
I started putting together a second try at Blue August over the weekend. If you've seen Peanutbutter-1, this will look familiar. I've gone back to the protoboard I built Peanutbutter-1 on. In fact, since Blue August is an expansion of Peanutbutter-1's design, you could think of it as Peanutbutter-2! It's the same construction concept; glue logic along the top, big ICs along the bottom. The edge connector is 30 signal pins and 30 ground return pins. I had wanted to get the whole 32 bit 65c02 bus onto those pins, but it doesn't fit onto this board (which is why I started out using different protoboard in the first place). Still, I probably won't ever need the full 16-bit address bus to be on the connectors; I could use up to 14 address lines if I wanted to use al 8K of the VGA board's dual port RAM, and I just have room for exactly that many lines after losing the 2 pins. But, I don't actually need all 8k for the frame buffer.
Attachment:
File comment: Component side
20230820_123725.jpg
20230820_123725.jpg [ 3.82 MiB | Viewed 6520 times ]
Attachment:
File comment: Solder side
20230820_123737.jpg
20230820_123737.jpg [ 4.48 MiB | Viewed 6520 times ]
I'm waiting for some pin headers to be delivered so I can finish the soldering and start wrapping. Meanwhile, I updated the schematic a bit:
Attachment:
File comment: Rev. 4
Glue-v2.pdf [85.81 KiB]
Downloaded 27 times

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 20, 2023 5:19 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
Great! What do you use to drill out the tracks? I always found I got a really tired wrist from doing that!


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 20, 2023 5:46 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
gfoot wrote:
Great! What do you use to drill out the tracks? I always found I got a really tired wrist from doing that!


A drill.

:D



To be more specific, it's a regular Black & Decker electric hand drill with a 3mm brad point bit. The brad point keeps it centered in the hole and stops it from slipping.

Honestly, I'm not super happy with how it performed this go round. There are a few tracks that it peeled up rather than cutting, and in some spots it left quite a bit of copper behind in the circle. It all seems *functionally* good (connections are cut where they're supposed to be, and no shorts to neighboring tracks) but it looks messy, and I'm concerned the leftover copper will become detached later on and cause intermittent shorts. I may get a real "Vero" tool bit the next time I try this.

Edit: Well, it occurred to me that I haven't sharpened that drill bit in probably 2 or 3 years. So I did that; now it's working great. Those messy holes cleared right up. :D

BTW, anyone who is thinking of doing this at home, make sure you have a good mask. You don't want to breathe fiberglass!

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 25, 2023 12:42 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
The new board is all finished! I didn't take a lot of in-progress photos, since this isn't really new territory. I made a few mistakes right before powering it up for the initial test and got chaos. I ended up ripping out the first ground network and redoing it. Not sure if that was the problem or not, because as I was making a new ground network I realized I'd left the top two address pins of the ROM floating! :oops: Those are the bank-select pins, and they're supposed to be grounded until I have some front panel switches to select between banks. Anyway, here it is:
Attachment:
20230824_202303.jpg
20230824_202303.jpg [ 3.93 MiB | Viewed 6452 times ]
I never did manage to get fx2pipe and the Cypress dev board working reliably. I tried to use it again just now and I'm *almost* certain I have everything hooked up the way I did a few days ago when I got at least something, but it just sits there spinning its wheels. Jumper on, jumper off, A4 grounded, A4 floating, it's all the same. The little 8-channel analyzer works great though. I'm using it with sigrok-cli, and hoglet's decoder works just great in 8-bit mode.
Attachment:
20230824_202409.jpg
20230824_202409.jpg [ 3.77 MiB | Viewed 6452 times ]
I have a 32MHz oscillator installed right now, which makes phi2-fast 16MHz and phi2-slow 4MHz. Right now it's just nopping from the ROM, but this is an encouraging result, because it means the decode is getting done before phi2-fast goes high and is successfully stretching the clock for the ROM access.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 25, 2023 1:59 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
It's great that the fresh build of your system is working now - a shame about the logic analyser though. Since it started working for me, it has been very reliable and I've left the jumper off.

The trouble with 8 bit sigrok captures is the decoder can't tell where the clock edges are, so it might not work well when you're decoding something more complex than a stream of NOPs!

Getting fx2pipe working with a test circuit was a useful step for me, taking the 6502 etc out of the equation temporarily. Simply driving it from an oscillator is enough to check the data capture is working, and all the pins are correct. I only have PA4, PA5, RDY1, and IFCLK connected these days. My clock stretching was causing problems until I figured out how to wire that into the logic analyser as well.

I feel there might be potential for a kind of "HAT" board to go on top of the Cypress board and provide a few helpers for this sort of thing... like better pin layouts and silkscreen tailored for this use case, jumpers to select between capture modes, and then maybe some electronics like latches for the data bus.


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 25, 2023 4:30 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 959
Location: Potsdam, DE
(Re data-bus analysis: it occurs to me that my STM PoC boot loader could be used in this way, particularly as it's providing the clock to the 6502 and so could generate timed reads automatically, slowing the clock if necessary to get data out to a host computer. Hmm, something for later... first I have to build it!)

Neil


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 25, 2023 2:49 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
gfoot wrote:
The trouble with 8 bit sigrok captures is the decoder can't tell where the clock edges are, so it might not work well when you're decoding something more complex than a stream of NOPs!
I may give it another go today. Sometimes things go better at the start of a session than at the end of a session! I should clarify that it's the -ifclk mode that isn't working. I didn't try -a mode yesterday.

Edit: Derp, it's working now. I had the A5 (reset) wire plugged into A7. Now that I'm in my early to mid 40s I can't see as well... 8)

Quote:
I feel there might be potential for a kind of "HAT" board to go on top of the Cypress board and provide a few helpers for this sort of thing... like better pin layouts and silkscreen tailored for this use case, jumpers to select between capture modes, and then maybe some electronics like latches for the data bus.
Last week when I was reading everything I could find about this I came across a guy who made something like that for it and mounted the whole contraption in an Altoids tin! He was worried about current protection, so he added a bunch of resistors, and connected the input pins to a shrouded pin header that poked out of the side of the tin. That way he could just plug in an IDC cable with all of his leads on it. Was pretty cool. I just did a quick search to try and find it again, but I can't remember what he called it, so I came up with nothing.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 25, 2023 4:32 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
Paganini wrote:
Edit: Derp, it's working now. I had the A5 (reset) wire plugged into A7. Now that I'm in my early to mid 40s I can't see as well... 8)

Haha, well that's more good news then! I've made the same mistake with the same pin, and recently realised how long-sighted I am becoming - I rely on magnifying glasses way too much these days.


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 25, 2023 5:28 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
This is both cool and annoying. I replaced the NOP tester with BDD's ZP RAM test. I see it start working, then I get a prediction failure and a bunch of NOPs - but the NOPs are FB not EA - and then it picks up again. At first I thought that maybe the LA was just reading garbage off the bus and I needed to tweak it somehow, but when I looked more closely I saw it was working fine and, in fact, the prediction failures were unexpected resets! So I started looking at the reset line. It's at 4.8 volts, while everywhere else on the board is 5.1 volts. Why this voltage drop? I don't know. I also looked at it with my oscilloscope. VCC and GND both seem quiet - they don't trigger the scope. But reset is corrugated... it seems to be coupled to the clock signal. After lunch maybe I will add another bypass cap to the power rails near the DS1813 and see if that helps. It is fairly close to the `163, which I know from experience switches hard. A bit frustrating there. But, it's pretty cool to get a practical result from the LA and hoglet's decoder. It would have taken me a lot longer to track notice this problem without it!

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 26, 2023 12:26 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 490
This post turned into a kind of stream of consciousness troubleshooting log. I started out intending it to be an update, but then I kept thinking of things I wanted to try, and writing down the results. I'm going to go ahead and post it as is, because I'm too tired to try and edit it into anything entertaining! The short version is, I made some progress. All this troubleshooting has uncovered a few mistakes that I've corrected, but the main problem is still there. That main problem seems to be that the board freaks out whenever there's a "LDA 0,x" instruction. It does not freak out when there's a "ROL 0,x" instruction. I don't know what this means. I guess tomorrow I'll have to put together a test to see what addressing modes make it freak out. If there's bus contention reading from RAM, I would have thought that read-modify-write instructions would also cause it to happen. Anyway, if anyone feels like slogging through all this, I'd be grateful for advice!

Well, I have definitely made some progress. I'm not sure what it all means. I redid the VCC/GND connections for the DS1813 and the 74HC163, and added another bypass cap. RESET\ still looks a little bumpy, but it's better, and I don't *think* I'm getting glitchy resets any more. I'm not sure what I'm getting. Like I mentioned earlier, I copied BDD's ZP RAM test from that other thread:
Attachment:
File comment: I didn't copy BDD's comments... if you want to know how it works, you should go read his code!
ramtest.s [1.22 KiB]
Downloaded 43 times

I'm still not able to get good results with the -ifclk mode of fx2pipe. However, the -a mode seems to work fine:
Code:
paganini@Ariel:~/6502$ fx2pipe -a -n=32k >capture1.bin
paganini@Ariel:~/6502$ decode6502 -ahisy --mem=00f --phi2= --rdy= --rst= --vecrst=8080 capture1.bin >capture1.txt
Attachment:
capture1.txt [310 KiB]
Downloaded 20 times
Code:
paganini@Ariel:~/6502$ head capture1.txt
???? :          : RESET !!       : 7 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=1 Z=? C=?
8080 : A2 00    : LDX #00        : 2 : A=?? X=00 Y=?? SP=?? N=0 V=? D=? I=1 Z=1 C=?
8082 : 8A       : TXA            : 2 : A=00 X=00 Y=?? SP=?? N=0 V=? D=? I=1 Z=1 C=?
8083 : 38       : SEC            : 2 : A=00 X=00 Y=?? SP=?? N=0 V=? D=? I=1 Z=1 C=1
8084 : 95 00    : STA 00,X       : 4 : A=00 X=00 Y=?? SP=?? N=0 V=? D=? I=1 Z=1 C=1
8086 : A0 09    : LDY #09        : 2 : A=00 X=00 Y=09 SP=?? N=0 V=? D=? I=1 Z=0 C=1
8088 : 36 00    : ROL 00,X       : 6 : A=00 X=00 Y=09 SP=?? N=0 V=? D=? I=1 Z=0 C=0
808A : 88       : DEY            : 2 : A=00 X=00 Y=08 SP=?? N=0 V=? D=? I=1 Z=0 C=0
808B : D0 FB    : BNE 8088       : 3 : A=00 X=00 Y=08 SP=?? N=0 V=? D=? I=1 Z=0 C=0
8088 : 36 00    : ROL 00,X       : 6 : A=00 X=00 Y=08 SP=?? N=0 V=? D=? I=1 Z=0 C=0
You can see it's executing the right code. It works fine for a while, and you can see .X counting up as it scans through RAM. But then it freaks out:
Code:
80A8 : D0 EC    : BNE 8096       : 3 : A=FF X=3B Y=00 SP=?? N=0 V=? D=? I=1 Z=0 C=0
8096 : A9 FF    : LDA #FF        : 2 : A=FF X=3B Y=00 SP=?? N=1 V=? D=? I=1 Z=0 C=0
8098 : 95 00    : STA 00,X       : 4 : A=FF X=3B Y=00 SP=?? N=1 V=? D=? I=1 Z=0 C=0
memory modelling failed at   809A: expected A0 actual 7D
memory modelling failed at   809B: expected 09 actual 7D
memory modelling failed at   809C: expected 36 actual 7D
809A : 7D 7D 7D : ADC 7D7D,X     : 4 : A=7C X=3B Y=00 SP=?? N=0 V=0 D=? I=1 Z=0 C=1 prediction failed
memory modelling failed at   809D: expected 00 actual 7D
memory modelling failed at   809E: expected 88 actual 7D
memory modelling failed at   809F: expected D0 actual 7D
809D : 7D 7D 7D : ADC 7D7D,X     : 4 : A=FA X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0 prediction failed
memory modelling failed at   80A0: expected FB actual 7D
memory modelling failed at   80A1: expected B0 actual 7D
memory modelling failed at   80A2: expected 10 actual 7D
80A0 : 7D 7D 7D : ADC 7D7D,X     : 4 : A=77 X=3B Y=00 SP=?? N=0 V=0 D=? I=1 Z=0 C=1 prediction failed
memory modelling failed at   80A3: expected F6 actual 7D
memory modelling failed at   80A4: expected 00 actual 7D
memory modelling failed at   80A5: expected D0 actual 7D
80A3 : 7D 7D 7D : ADC 7D7D,X     : 4 : A=F5 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0 prediction failed
memory modelling failed at   80A6: expected 0F actual 7D
memory modelling failed at   80A7: expected E8 actual 7D
memory modelling failed at   80A8: expected D0 actual 7D
80A6 : 7D 7D 7D : ADC 7D7D,X     : 4 : A=72 X=3B Y=00 SP=?? N=0 V=0 D=? I=1 Z=0 C=1 prediction failed
memory modelling failed at   80A9: expected EC actual 7D
80A9 : 7D 7D 7D : ADC 7D7D,X     : 4 : A=F0 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0 prediction failed
80AC : 7D 7D 7D : ADC 7D7D,X     : 4 : A=6D X=3B Y=00 SP=?? N=0 V=0 D=? I=1 Z=0 C=1
80AF : 7D 7D 7D : ADC 7D7D,X     : 4 : A=EB X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
It's nothing but 7D for ages. Then, suddenly, it changes to a different kind of junk:
Code:
83FD : 7D 7D 7D : ADC 7D7D,X     : 4 : A=DD X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
8400 : 55 55    : EOR 55,X       : 4 : A=88 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
opcode 57: cycle prediction fail: expected 1 actual 5
8402 : 57       : ???            : 5 : A=88 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
8403 : 55 15    : EOR 15,X       : 4 : A=FF X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
8405 : 55 55    : EOR 55,X       : 4 : A=AA X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
8407 : 55 77    : EOR 77,X       : 4 : A=F4 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
8409 : 55 5D    : EOR 5D,X       : 4 : A=81 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
840B : 55 55    : EOR 55,X       : 4 : A=D4 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
840D : 55 45    : EOR 45,X       : 4 : A=A5 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=0
840F : D5 55    : CMP 55,X       : 4 : A=A5 X=3B Y=00 SP=?? N=0 V=1 D=? I=1 Z=0 C=1
8411 : 55 55    : EOR 55,X       : 4 : A=F0 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=1
8413 : 55 55    : EOR 55,X       : 4 : A=A5 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=1
8415 : 55 55    : EOR 55,X       : 4 : A=F0 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=1
opcode 57: cycle prediction fail: expected 1 actual 5
8417 : 57       : ???            : 5 : A=F0 X=3B Y=00 SP=?? N=1 V=1 D=? I=1 Z=0 C=1
8418 : D5 5D    : CMP 5D,X       : 4 : A=F0 X=3B Y=00 SP=?? N=0 V=1 D=? I=1 Z=0 C=1
It does that for a while, the finally bombs out with:
Code:
8801 : 00 00    : BRK #00        : 7 : A=FB X=3B Y=00 SP=?? N=1 V=0 D=0 I=1 Z=0 C=1
F004 : 40       : RTI            : 6 : A=FB X=3B Y=00 SP=?? N=1 V=0 D=0 I=1 Z=0 C=1
8803 : 00 00    : BRK #00        : 7 : A=FB X=3B Y=00 SP=?? N=1 V=0 D=0 I=1 Z=0 C=1
F004 : 40       : RTI            : 6 : A=FB X=3B Y=00 SP=?? N=1 V=0 D=0 I=1 Z=0 C=1
8805 : 00 00    : BRK #00        : 7 : A=FB X=3B Y=00 SP=?? N=1 V=0 D=0 I=1 Z=0 C=1
F004 : 40       : RTI            : 6 : A=FB X=3B Y=00 SP=?? N=1 V=0 D=0 I=1 Z=0 C=1
for the rest of the capture.

*HOWEVER*

If, without resetting the 6502, I immediately do a second capture, I get:
Code:
???? : 38       : SEC            : 2 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=1
???? : 4C 00 A0 : JMP A000       : 3 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=1
A000 : 38       : SEC            : 2 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=1
A001 : 4C 00 A0 : JMP A000       : 3 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=1
A000 : 38       : SEC            : 2 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=1
A001 : 4C 00 A0 : JMP A000       : 3 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=1
A000 : 38       : SEC            : 2 : A=?? X=?? Y=?? SP=?? N=? V=? D=? I=? Z=? C=1
which suggests to me that the garbage in capture1 represents the capture failing somehow. Clearly, the 6502 has completed the RAM test and is sitting in the result loop, as it's supposed to be. On the other hand, the result loop is one of the failure loops for bad RAM. Is it possible I actually have a bad RAM chip and that it is, somehow, freaking out the capture when I run into the bad spot? I don't know. I ran some more captures. They all fail at *about* the same place: .X = 37..3D. I also tried using a very slow clock (500Khz) and got the same results. At this point, I think I need to try a different RAM chip. I have a couple of spares, so... nope. Same thing, it bombs out at X=3C. This time, however, when I do my second capture, it's still spewing garbage! (55, 55, 55, 55, 55, with the occaisional 7D thrown in).

Well, is it something about that specific area of the address space, or is it something to do with how long we've been running? Let's tray starting .X at $35 and see how far we get. Aaand, it crashes immediately at LDA 0,X when .X is $35. That's something then. Wait a minute, I never tied off all those unused inputs on the `14, because I wasn't using it when I/O was in zero page. But then I moved IO into ROM so I could do the RAM test. (10 minutes later) OK, that's something. The decoder now has no "prediction fails." But this still happens:
Code:
808B : D0 FB    : BNE 8088       : 2 : A=35 X=35 Y=00 SP=?? N=0 V=? D=? I=1 Z=1 C=1
808D : 90 1E    : BCC 80AD       : 2 : A=35 X=35 Y=00 SP=?? N=0 V=? D=? I=1 Z=1 C=1
808F : B5 00    : LDA 00,X       : 4 : A=35 X=35 Y=00 SP=?? N=0 V=? D=? I=1 Z=0 C=1
8091 : 55 55    : EOR 55,X       : 4 : A=60 X=35 Y=00 SP=?? N=0 V=? D=? I=1 Z=0 C=1
8093 : 55 55    : EOR 55,X       : 4 : A=35 X=35 Y=00 SP=?? N=0 V=? D=? I=1 Z=0 C=1
8095 : 55 55    : EOR 55,X       : 4 : A=60 X=35 Y=00 SP=?? N=0 V=? D=? I=1 Z=0 C=1
Could something be wrong with A4? When I beep it out it seems to go everywhere it's supposed to, and not other places. It seems like any read from $8090 - $80FF returns 55. That's about the same size as my I/O window. Once it gets out of the $8090-$80FF area it starts behaving properly... All those BRK / RTI is what it should really do when reading from that area of the ROM (it's full of zeros). And when it eventually works through all those it runs into the "RAM FAIL" loop at $A000.

I can test this really easily by having my reset vector start later in the ROM.

No that didn't fix it. There are still lots and lots of $55s, and this time when it read over $A000 and $B000 it didn't see what's in the ROM, just $55. It didn't start seeing what's in the ROM until $C000.

I went and checked all the wiring for yet another time. I would start to think maybe my ROM is bad, and just randomly freaks out and spews garbage, *except,* it always seems to happen after the instruction "LDA 0,x." That seems like bus contention. But why wouldn't it happen after ROL 0,x?

_________________
"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, 2, 3, 4, 5, 6, 7 ... 12  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 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: