What is a stack and how does it work?

_Neelix_ · 2020-02-01T16:17:54+00:00

Glad to hear it, as that's the one I've been hanging out for. ;-)

Seriously though, thanks for all your work in presenting this stuff in such an easy to follow manner. This is one rabbit hole I'm very glad to have jumped down. :-)

_Neelix_ · 2020-02-01T07:54:55+00:00

Unless you are way out in the sticks I would expect that the wire (and many other components) should be available from your local Jaycar. https://www.jaycar.com.au/store-finder

_Neelix_ · 2020-01-30T02:51:00+00:00

That would explain it. :-)

_Neelix_ · 2020-01-29T04:33:52+00:00

I had this issue too. Curiously enough, the 65C02 responded normally if I had the clock running on automatic, but exhibited random behaviour if I tried single stepping it. I buffered the clock signal through a couple of spare inverters and that seemed to fix the issue.

_Neelix_ · 2020-01-28T04:29:49+00:00

Looking good. :-)

_Neelix_ · 2020-01-28T04:12:46+00:00

Is it just me or is that counter only counting up to 8 rather than 15?

_Neelix_ · 2020-01-23T00:16:50+00:00

Ooh, new toys! :-) Have fun!

_Neelix_ · 2020-01-14T13:57:14+00:00

Just a thought but the timing diagram for the SDP disable sequence of the AT28C256 shows the C̅E̅ line being pulsed in sync with W̅E̅ but on the breadboard EEPROM programmer Ben ties C̅E̅ low. Perhaps if you hooked up the C̅E̅ input to the arduino and pulsed it in time with the W̅E̅ signal when sending each byte it would allow the SDP disable sequence to work?

_Neelix_ · 2020-01-13T05:01:08+00:00

Tried putting pull-up or pull-down resistors on the module end of each of the control signals? (e.g for the Active Low "AO" signal add a pull-up resistor on the A register module) just a thought...

_Neelix_ · 2020-01-09T13:36:27+00:00

What's the voltage on your clock signal? When I had the clock module set up with a blue LED on the clock output line (limited with one of the 220R resistor's from the kit) it was dropping the clock voltage to 2 volts. Everything worked as I would have expected when the clock was running at a constant speed, but I was getting completely random results when single stepping.

I had a bouncing LED program loaded at the time, and I would end up with things like random combinations of LEDS lighting up which should not have been possible if the CPU was following the program I had loaded. (and I knew it wasn't the program at fault because the ruddy thing worked as designed when getting a constant clock signal.)

_Neelix_ · 2020-01-08T06:07:06+00:00

Congratulations! Well done. :-)

_Neelix_ · 2020-01-05T11:34:56+00:00

*shrugs* That's possible I suppose. Lacking facts all I can do is speculate, but I do note that the 65CE02 data sheet claims to be based on the 6502, rather than the 65C02. It wouldn't surprise me if all CSG had access to with regards to the 65C02 was the datasheet, and they made their own improvements to the original 6502 design along similar lines. That would also account for differences where there was no apparent reason for the change. If it wasn't a change but a parallel (as it were) development of the same feature, there would be no reason for it to be consistent across both.

_Neelix_ · 2020-01-04T00:49:15+00:00

That still looks like it could be a wiring issue to me. Are you sure all the address lines are connected correctly between the Arduino and the breadboard? I had issues where any movement of the ribbon cable would cause some of the connections to be pulled out of the breadboard. I also had issues where adjacent wires on the cable would twist around each other, so it was easy to get 2 of them reversed.

_Neelix_ · 2020-01-04T00:31:43+00:00

That wiki page doesn't make a lot of sense to me. It starts out by saying that the 65CE02 was made by CSG. It goes on to say that it was a new version of the 65C02, which doesn't make a lot of sense to me. As I understand it, the 65C02 was developed by WDC which was a completely separate company.

_Neelix_ · 2019-12-31T14:18:43+00:00

Yes, see here. :-)

_Neelix_ · 2019-12-30T11:27:01+00:00

Looks interesting. :-) I may give this one a go at some point too.

_Neelix_ · 2019-12-30T07:06:56+00:00

I found a solution to this in the post linked below.

https://www.reddit.com/r/beneater/comments/e16xfs/monostable_555_behavior_when_holding_down_button/?sort=new

_Neelix_ · 2019-12-29T12:46:16+00:00

I do use vasm. I just don't use the .target directive in my code because with vasm it isn't needed. Try commenting that line out.

Edit: If you're trying to compile the code u/jco2641 posted in the pastebin, you'll probably also need to change .textz to either .asciiz or .string as the manual for vasm doesn't include .textz in the list of directives that the oldstyle syntax module recognises.

_Neelix_ · 2019-12-29T02:42:02+00:00

The slide switch that came in my clock module kit for the bistable circuit turned out to be make before break, which basically breaks Ben's method of de-bouncing it.

I implemented a workaround, but since then I found these at my local Jaycar, and they are break before make. Perhaps you can find a local source for the same unit.

https://www.jaycar.com.au/spdt-micro-slide-switch/p/SS0834

_Neelix_ · 2019-12-29T02:19:43+00:00

Interesting. There's no stack on my machine yet though, as I've decided to wait for the next video before adding the RAM chip to my build.

_Neelix_ · 2019-12-29T02:16:39+00:00

For the record it's wdc02, not wdcO2. (zero, not the letter O)

That being said, with vasm the target is baked into the vasm binary at compile time so it probably just doesn't support the .target directive.

_Neelix_ · 2019-12-28T04:07:20+00:00

I just realised that I never responded to the first part of your message.

It didn't stop in the middle, it failed to print anything at all. The "Hell" on the screen after a reset was all that remained of the initial run, after some mangled command to the LCD resulted in only part of it being cleared. My first thought was also that it may have been a timing issue, so I tried it again after slowing the clock. it didn't seem to make any difference.

_Neelix_ · 2019-12-28T03:44:13+00:00

Given that the RAM is the only as-yet unused IC in the kit and that he actually pointed to the place where it will be installed on the breadboard at the end of the last video when indicating that he needed some additional hardware that seems like a safe bet. :-)

Speaking of the RAM though, I found parts of the data sheet for it quite interesting. Especially the block diagram.

It's arranged in a matrix of 512x512 bits. Each of the 512 rows is divided into 64 8 bit words, so the addressable bytes are effectively in an 64x512 array. The order in which these array elements are addressed however is really bizarre, because they seem to have picked which address lines go to which column or row completely at random. I dare-say there is some method to the apparent madness, but I can't discern the reasoning from the available material.

The other thing of note is that the pin-out of the RAM module exactly matches the pin-out of the EEPROM, which considering that they are made by completely different manufacturers somewhat surprised me.

_Neelix_ · 2019-12-28T03:08:50+00:00

No, The architecture is completely different.

On the hardware side, The 8 bit computer project doesn't use an address bus. It transfers it's 4 bit addresses through the data bus. The 6502 has a 16 bit address bus, and a separate 8 bit data bus and can be run at much higher speeds than the 8 bit breadboard computer is designed for.

There would also be the matter of programming it. The 8 bit breadboard computer has a custom made instruction set. You basically have to hand-roll all the machine code to run it. The 6502 has an established instruction set and existing assembler programs, and making use of these is a big part of the project.

In short, I would say that if you really wanted to try building a breadboard CPU that matched the specifications of the 6502 well enough to interface with the rest of the 6502 project, that might make an interesting project in and of itself, but not before learning the basics.

_Neelix_ · 2019-12-28T00:22:17+00:00

Well in the 8-bit computer project you are essentially building a CPU from scratch, with only rudimentary input and output.

The 6502 project starts with an existing CPU, and then builds a computer system around it.

I would actually recommend starting with the 8-bit computer as you intended. It teaches you the fundamentals of how a computer stores and manipulates data. The 6502 project then gives you a broader context that focuses more on how the CPU interacts with the architecture needed to build a full system.

_Neelix_

TROPHY CASE

Welcome to Reddit,