6502.org

Ok, here's my false-feed testing setup:

The RAM is on the breadboard with all 15 address lines shorted to ground. The control lines are being controlled by an arduino. To read a value, I set /CE low then /OE low, then check the data lines with a multimeter, then put all the control lines high again. To write a value, I connect a data pin to ground, set /CE then /WE low, delay 10ms, then set /WE and /CE high. When reading back, the data line I tried to write to is still high.

The supply voltage is 5.14v and all the control lines are going cleanly between 0 and 5.14v.

Are the other 4 address lines tied hi or lo?

That's frustrating! I notice on your schematic the RAM is just labeled "62256." I'm going to hazard a guess that it's an AS6C62256, since that's currently the only 32k*8 through-hole SRAM that Mouser has in stock. I remember a couple of threads where people had trouble with those specific chips:

viewtopic.php?f=4&t=4329
viewtopic.php?f=12&t=7371

It looks like the first thread veered off topic before a solution was found; but I think Adrian did eventually get his working, somewhere deep in that 11 page thread! I think he's still active here, so maybe if you sent him a PM he could give you the short version.

So I found the problem with the testing setup: I had a typo in my pin definitions and I was pulling /OE low when I thought I was pulling /WE low. The chip works, at least. However, the problem persists in the actual computer.

The voltage is staying stable across the chip and all the control lines are at the right levels (a few tens of mV from 0 and Vcc)

Good news! I got a 43256 off my dad and that works flawlessly. I wrote a quick program to memcheck zero page and that runs perfectly at full 1Mhz speed, so I feel justified in saying the Wren Prototype is functional and ready for usage.

The 62256 mystery can be left for future me. My current hypothesis is that it's not getting enough power, or something is causing the power supply to do weird things.

This is the third report of 62256 being problematic compared to other equivalent 32Kx8 part. I was curious enough to duplicate a problematic design and procure a batch of 62256 but didn't find the problem. Very curious indeed!
Bill

Update: SPI seems to be working correctly. My setup uses the VIA's shift register for data out and a 74hc595 for data in, with the parallel pins connected to VIA port B. I connected CB2 to the '595's input and it successfully echoed bytes back to itself.

I haven't set up any interrupt-driven code yet, but I'm fine with busywaiting for the time being. My next job is access routines for the MAX3100, and then a "proper" monitor program.

Take a look at viewtopic.php?p=90041#p90041 to start.

Signetics? Oh, that's the 25120 ... sorry.

Well, because of a boss I had in the late 1980's who was unreasonably obsessed with cutting costs, we in the engineering department joked that we could save a lot by eliminating the I/O from a computer design.  As a bonus, the customer would never discover any bugs.

Not too distantly related but more reasonable, I wouldn't mind having STA #, STX #, and STY # instructions for self-modifying code, where the operand space becomes the variable space, rather than an address pointing to the variable.

After a prolonged break due to starting university, I'm back and ready to computer.

My current goal is to give the computer a way to talk to the outside world. I was gonna use the MAX3100 for this, but it seems to have disappeared during the move. In lieu of it, I'm going to use an atmega88, which will also serve as a monitor and control thing. I'll probably have it log the bus state and then also pretend to be a simple memory mapped UART.

Just to check, the address lines are valid when phi2 comes up, and the data is latched when it goes down, right?

Yup, that's exactly it:Just a reminder that you control when PHI2 rises and falls (by selecting a clock frequency) so if your clock is too fast the address lines will not yet be valid when PHI2 rises. That only starts becoming a problem around 40MHz* so probably not a worry.

That also means you can start doing address decoding as soon as PHI2 falls and it should have settled by the time you use it (when PHI2 rises or later).

*Assuming a modern W65C02S6TQG-14 or similar

I think I'd say that the address lines are generally, usually, probably, valid at the time phi2 rises. In fact they are usually valid some time before, as the diagram indicates, and that's often useful. For example a write enable is often derived from phi2, so that writes are not directed to the wrong chip or the wrong address. In that case, phi2 is used because it's convenient - it probably won't be optimal.

(I'm not sure if I'm merely being pedantic, or if in fact confusion about Phi2's rising edge might lead to some mistake, or to further confusion down the line.)

The best timing diagrams, I think, have little arrows to show causality - not just that this thing happens after this other thing, which might otherwise be coincidence, but that it is caused by it.