Hoping anyone can point me in right direction since I'm stuck, completely stuck and I'm not sure what else to try at this point. Have been hard at work drawing out designs based on the Apple 1 Replica Creation book, so hopefully the errors made are of the patchable kind. I'm using an Arduino Nano to talk to the computer via an MC6821 chip. CPU used is UM6502A, HM62256LP-10, AT28C256 EEPROM with Basic and Woz Monitor installed - logic chips used originally were 74LS, but switched to 74HCT series to see if that made a difference. Not sure what other information to include, code and schematics on github (https://github.com/tebl/RC6502) - Arduino code in the serial folder.

When I connect to the serial monitor on the Nano and then hit the reset on the computer I can see that I receive a single '\' from the computer, and as far as I know that should mean that the monitor starts running. Problem is, I can't seem to receive anything else from it. Also varied or-ing the character sent out to ensure that bit 7 is high (also did a version where I tied it high like other designs do). Seems so close

Any ideas, or even just a nod that the Arduino code seems somewhat sane?

Welcome, tebl! I'm sure some helpful people will be along soon.

Have you got a means of gaining confidence in your EEPROM having the right contents? It might be that a good start would be to run some different startup code to make it easier to see what the board is doing.

What kind of diagnostic equipment do you have? Can you measure voltages and frequencies? If the monitor is waiting for input, then most of the address bus bits should be in known territory, and the Sync output from the 6502 should be toggling at an appropriate frequency, as should the RnW output and the clock output pin.

Hmm... I assumed the EEPROM was working as it should since the \ showed up, I believe that was the expected first character the Woz monitor should output. Did swap out the current EEPROM with a fresh one, CAT28C256 this time in order to check if that made any difference - doesn't appear do so, but I can see that if i remove the EEPROM completely letting the system run on air then the \ disappears so for the moment I'm assuming that works.

What I've got on hand is a cheapo multimeter that I recently upgraded from a super-cheapo multimeter so that I could atleast get a beep when checking continuity. Also tried hooking up the Phi 0 and Phi 2 to a DSO-138 that I built, but do not know how to use properly (why not be honest here) - both seem to oscillate in an orderly fashion. Checking them with a multimeter they seem to be around 2-3V (), which I'm guessing is just the multimeter evening things out.

I'm going to do some further on those pins you've mentioned - haven't connected sync to anything so didn't check it so far

If you have a way to do it, changing the monitors output character from a "\" to something else would let you verify that you were actually seeing the monitor start up.

I'm not familiar with the setup you are working on, but another thing I do when a serial connection seems dead is to "fly blind" and type in a few commands to see if the machine seems busy. Just recently I had and 1802 based machine I'd built seem dead on the serial monitor, but when I did a memory dump (even though nothing was appearing on the terminal) I could tell the processor was cranking along. That helped me focus my effort on the serial connection instead of wondering if the machine itself was locked.

If the machine is locked in a loop waiting for input, the higher order address lines might be locked either high or low and just the lower bits of the address bus are going to be busy. (They might toggle to read the status of an ACIA or UART from whatever address it is at, but if the ROM and devices are being read are all above $C000 then A15 and A14 would be high when there is a valid address on the lines.)

Depending on the code, I would also expect it to be reading not writing at that point. (I'd also expect that the chip select line for the ACIA or UART would be getting pinged on a regular basis if it is stuck trying to read input.)

It is just a totally blind guess, but if the monitor is getting a prompt out and then nothing else seems to happen I would tend to suspect either the input (hardware or software) or something like a flaky interrupt sending thing to never-never land. And as you can see, my troubleshooting approach tends to start with a fairly scattered approach looking for something that doesn't make sense to me.

Jim

That DSO should be enough to confirm that the clocks are ticking fast, the Sync a bit slower, and RnW a bit slower than that. The chip select on the UART should be toggling away too, if the monitor is in a polling loop.

Eureka! I found the error, after spending a lot of hours of checking every tiny bit of code, checking everything out using the DSO and programmed a new Arduino sketch in order to sniff out what was going out over the buses. Given that sync toggled as described, clock ticking and R/W alternating here and there - except that what I was seeing just seemed like a random mess. Didn't even see the \ being transferred even though I knew it was going over the wire. Even built various versions of the clock with dividers and stuff since it looked all wavy and not square at all.

Problem was... I mislabeled the RAM adressing pin so that it was set to respond to upper 32K instead of lower, meaning that most of the time the first few cycles worked and after that it was just reading garbage all over the place. That's what you get for not double-checking what you put on the silkscreen

Thanks for all the help guys, attached a picture of the computer now that it's in a somewhat working condition. Guess I'll have to do more 6502-based projects since I ordered a lot of stuff yesterday, in case a W65c02 or a W65c21N would make a difference

Still have a lot of stuff to do though, I made a huge mess of the power separation on the serial card. Hmm... maybe make a SBC-version of it now that it works

Excellent! It can sometimes take some determination to check things which you don't think are wrong - that's one place where two heads can be better than one.

Nice-looking system too. Seems to be a lot going on there - five boards?

Yep, it's a lot for a system that does almost nothing at all. I originally bought the Z80-based RC2014-computer and spent a lot of time dissecting it's inner workings, and like the creator of that system I found that doing a lot of things made it a lot harder to debug so separated out most functions so that one board only does one thing. Did not end up reusing other components than the backplane for this project, but it's all pluggable so can mix and match to my hearts content (or rebuild the original). Want to doing something with a 6507-CPU, just use a different CPU board

Is the backplane used unaltered from the RC2014? How did you find adapting the Z80 bus to the 6502 signals? Is the backplane mostly just straight-through so it's for connecting SIL40s in parallel or do some lines have some extra circuitry?

I'm using it without any alterations - the one I'm using is the 8 slot one, as far as I can tell only the 5 slot is online with schematicsthough there are no differences between them other than the number of slots. There's no circuitry on the backpane itself other than power and a reset button, but those mostly work without any changes (reset button pulls directly to ground, the reset circuit I'm using has a more proper design for the 6502). Other than that I just laid out the signals where I wanted them - other than GND/5V, just think of the others as 38 bus lines to do with as you please

Is there a support thread/forum for the RC6502 project? I've built one, with the five basic boards and the backplane. I have some questions about the jumper settings, particularly for the RAM/ROM board Rev D, and the ROM board Rev B. I already poured through Github, but the jumpers are not covered that well. It would be great if there is a list of minimal jump settings. I'm using a 28C64 for the ROM, and a HY62256A SRAM module for the RAM.