Debugging my first SBC

[sepseel]

Well, the ROM chip Im using is only 8k, and it starts at C000 like you said.
That leaves me with only two options to correclt allign the reset vector the start of my code, right ?
I either need to change the wiring, so the ROM starts at DFF8.
Or I have to buy a 16k EEPROM to replace my 8k one.

[BigEd]

Sorry, got all my numbers and arithmetic wrong... let me edit that post... done.

[Dr Jefyll]

sepseel wrote:

Well, the ROM chip Im using is only 8k, and it starts at C000

I'll just jump in here to quickly mention a simple but perhaps overlooked point. It's the computer's decode circuitry that determines the size of the memory area occupied by a ROM or other memory-mapped device. For example, if the decoder activates a given device for 16K of the memory map, then even a smaller device such as 4K or 8k will entirely fill that space! It's just that multiple, identical images of the device will appear.

In your case, sepseel, if the decoder activates your (EEP)ROM chip-select for the region C000-FFFF (size: 16k) then your 8k ROM will appear twice: from C000 to DFFF and from E000 to FFFF.

This would allow you to put a program in the bottom of your ROM which the CPU "sees" when it accesses its C000 to DFFF range. And the vectors could be in the top 6 bytes of the ROM, which the CPU sees when it accesses its E000 to FFFF range. I'm not sure this would be helpful for you, but it's something to consider.

[BigEd]

Aargh - it is a 16k space! I'll re-edit my post and refer them down-thread!

[sepseel]

Then what would happen if I used a ROM chip bigger than 16k ?
Would then only the first 16k of the chip be available, or what would happen ?

[BigEd]

It's a useful exercise, at around this point, to have a think about ROMs, how many pins they have, why, and how many lines there are in your address bus, and how address decoding works. I recommend it! Garth's primer is one of many places - but the schematic you have in front of you will help too.

Edit: let me add, this is because you get ten times the experience points from figuring something out, compared to asking questions first. By all means ask questions, but be sure you've had a think and read some stuff first.

[Dr Jefyll]

sepseel wrote:

Then what would happen if I used a ROM chip bigger than 16k ?
Would then only the first 16k of the chip be available, or what would happen ?

Alright, suppose you had a 32k ROM. The answer to your question will depend on the ROM's A14 input. (On a 16k ROM the A14 input doesn't exist .) If A14 is tied low then only the first 16k of the chip be available, as you say. If A14 is tied high then only the other half will appear.

As Ed says, this brings us back to basics regarding how many pins there are, and why.

[sepseel]

So I have looked into how the addres decoding works. This way I made a block diagram of my memory map. I feel like I have a better understanding of it now.
I also found out I have a 256k eeprom laying around, so I replaced my 8k one, and ran another NOP test just to verify I did everything correctly.
I have burned the rom image found in the example files of the symon emulator on my EEPROM but I dont seem to be getting any output on the acia.
What tests can I do to find out what's going wrong ?

[Dr Jefyll]

sepseel wrote:

What tests can I do to find out what's going wrong ?

First, can we assume the hardware design is correct? If you've made modifications to the known-good schematic you linked to then you should post the revised schematic so we can have a look.

But let's say the actual design is OK -- meaning other factors are in play, such as a construction error or mis-configured software. There are several different directions you could take. One good approach is single-cycle stepping.

You said you have an arduino acting as a variable clock. Can you arrange for the arduino to issue one cycle at a time, pausing with the 6502's Phi2 high? The pause is half of the cycle. The other half is when you manually hit a pushbutton or by other means indicate you want to proceed. The arduino sends Phi2 low then high again, then resumes waiting.

This lets you observe in stop motion what the hardware and software together are doing. The technique can be somewhat tedious but it's very powerful. You get to see, cycle by cycle, how each instruction achieves its function (which is also educational).

As a fairly simple starting point, I suggest you watch the state of the UART chip-select input. Restart the 6502 and quickly step through until the UART chip-select goes active (which, depending on the software, will probably take a few dozen cycles). Now, with the 6502 still paused, you can verify that the address and data buses contain the expected data. I haven't looked at the program you're using, but I assume the first access to the UART will be a write cycle.

Even this simple first test reveals a lot! And it'll suggest what direction further tests should take.

PS- be aware that the 6502 requires clock pulses as it performs its reset. IOW don't just hit reset then begin clocking. Also: I added some detail to the section above re what the arduino does for single-cycle.

[sepseel]

I have not modified the schematic, I have just swapped out the eeprom I had, with a bigger one. they both have the same pins, just a different layout.

I had already made a single stepping device out of my arduino.
Using this I first tried using the rom image from the symon examples, and single-stepped through this, but I did'nt seem to be getting the data I was expecting.

So then I moved on from this, and tried to find where FFFC and FFFD are on my eeprom. Using a calculator I found out that they should be at 3FFC and 3FFD.
However, when I filled my eeprom with FF, and changed just 3FFC and 3FFD, to verify if I was correct.
The led's on the data lines showed a value of FF.

What could be causing this ? an error in wiring maybe ?

[GaBuZoMeu]

Try it with something different than $FF. $FF is somewhat a bad choice, because IF your EPROM isn´t selected at all there is no bus driving at all, so you frequently get $FF as "answer". Second $FF is what an erased EPROM contains. If your wiring isn´t 100% ok, you will probably read from a wrong address.

Perhaps you can fill your EPROM with a pattern, first byte = inverted low address, second byte correct page address like: $FF $00 $FD $00 .... $01 $00 $FF $01 ...
upto ... $03 $3F $01 $3F

Good Luck.

[Dr Jefyll]

sepseel wrote:

I had already made a single stepping device out of my arduino.
Using this I first tried using the rom image from the symon examples, and single-stepped through this, but I did'nt seem to be getting the data I was expecting.

We both made a mistake, I'm afraid. NMOS 6502's can't be single-stepped in the fashion described. It works for CMOS CPU's -- 65C02 -- but the NMOS part requires a more complex circuit that keeps Phi2 running constantly and manipulates the CPU RDY input instead.

Sorry for the bum steer -- really I do know better, but it's easy to forget the old NMOS stuff. Is it possible you could acquire a 65C02? It has numerous significant advantages compared to the NMOS part. Garth describes the differences here.

[sepseel]

Aah, that would explain why my 6502 was acting up. I thought it was broken, because when I tested it with a 65c02 chip I have, it did work..
As for using a 65c02, would I need to make changes to the code if it was originally written for a 6502, and would I need to reassemble the code ?

[Dr Jefyll]

sepseel wrote:

Aah, that would explain why my 6502 was acting up. I thought it was broken, because when I tested it with a 65c02 chip I have, it did work..

Ah! So you already have one! Excellent!

Quote:

As for using a 65c02, would I need to make changes to the code if it was originally written for a 6502, and would I need to reassemble the code ?

No, and no.

[Dr Jefyll]

GaBuZoMeu wrote:

IF your EPROM isn´t selected at all there is no bus driving at all, so you frequently get $FF as "answer".

GaBuZoMeu makes a good point here. And single-cycle execution is one way to ensure your EPROM is selected when needed.

Earlier I mentioned a simple test for single-cycle execution. On reflection I see it can be simplified even further. But first:

In the PS to my earlier post I mentioned that a 6502 requires clock pulses as it performs its reset. This applies to the 'C02 as well. Your circuit will require a small change, as shown below. In red I've shown how to bypass components that limit the length of the reset pulse to a very short time -- too short for you, a human, to manually request a few clock pulses from the arduino. Hence the need for the circuit change.

(On 'C02 there's no need to limit the length of the reset pulse. FWIW, even on NMOS '02 the need is questionable. There's a forum thread about this here. Followups to that discussion don't belong in this thread.)

modified RESET circuit.png (7.63 KiB) Viewed 3400 times

Here's the simpler single-cycle test I propose:

• issue a half-dozen clocks
• press and hold the Reset button (which should force low the CPU /RESET on pin 40)
• issue a few more clocks -- at least two
• release the Reset button
• issue two more clocks
• stepping onward, and monitoring the RAM /CS input, you should see a dummy stack access lasting three cycles
• stepping onward, and monitoring the ROM /CS input, you should see the vector fetch lasting two cycles (for the low byte then high byte)

The cycle following the fetch of the vector high-byte should be the start of your program. On the data bus you should see the opcode of the first instruction of the program. If this isn't present then you need to find out why -- there's no use going any further.

If the first opcode doesn't appear, maybe the ROM isn't getting a Chip-Select. Or maybe the vector bytes are muddled up somehow. To see about that, rerun the test but stop sooner and see what's on the data bus. You get the idea...

whew! Did I miss anything? Any questions? Good luck, and keep us posted!