74HCT6526 - A MOS6526 implementation with 74xx ICs

[daniMolina]

ttlworks wrote:

Maybe they sometimes just had not enough time at hands for writing documentation.

I think we can be pretty sure about that. I've seen the talks Bill Herd gives, and I can only be amazed at what they did accomplish.

ttlworks wrote:

If you do hardware design for a living, you are used to datasheets that are not 100% correct and\or leave out some "subtle" details, sorry.

I do software/database design for a living. We are much much much worse

ttlworks wrote:

the first revision of new hardware always tends to end up in the trash can

Right where it belongs. After spending 4 hours running some code in an emulator cycle by cycle, everything matches, cycle by cycle, Wolfgang Lorenz document. I can only assume this is as closer as I'll be able to get to the inner workings of the 6526 without being able to inspect the silicon, or without a bigger logic analizer. Good news, I've been able to replicate it, and, pending a lot of tests, it feels OK. I'll post some diagrams later once I've cleaned them up a bit.

ttlworks wrote:

had problems to get hands on down_counters

I'm using the 74193. Binary, 4 bit, UP/DOWN counter. Cheap ,easy to find (~0.30$ each), and until now, it's doing what I need it to do.

ttlworks wrote:

You got to be creative.

Unfortunately for me, that usually happens around 3 or 4 AM

Cheers!

[ttlworks]

daniMolina wrote:

I think we can be pretty sure about that. I've seen the talks Bill Herd gives, and I can only be amazed at what they did accomplish.

Unfortunately, it's a sort of job where you are not getting old.

daniMolina wrote:

I do software/database design for a living. We are much much much worse

Just make sure that the binaries don't contain hidden 24 Bit *.BMP pictures of Mickey Mouse.
//There _has_ to be a reason, why them binaries are that big nowaday.

daniMolina wrote:

to get to the inner workings of the 6526 without being able to inspect the silicon

There are microscopic pictures of the 6526 silicon, but polygonizing them or extracting schematics won't be fun.

daniMolina wrote:

I'm using the 74193. Binary, 4 bit, UP/DOWN counter. Cheap ,easy to find (~0.30$ each), and until now, it's doing what I need it to do.

Hmm... well, this increases the chance that a redesign of the TTL 6526 might become necessary when aiming for 20MHz PHI2.

daniMolina wrote:

Unfortunately for me, that usually happens around 3 or 4 AM

Go, Dani, go.

[Dr Jefyll]

ttlworks wrote:

BTW: had problems to get hands on down_counters, so for implementing the 6522 timers I just had used 74163 up_counters and inverted the 74163 data inputs and outputs with some 7404 chips to make them look like down_counters to the CPU.

Ha! I used the same solution for the opposite problem. My KK Computer has a 6522, and of course counting down is what it does naturally. But KK is an expanded 65C02, with a bunch of new instructions and 6 new registers. One of the new registers -- "IP," used by the NEXT instruction -- is mapped to T2 of the 6522... and it's a register which is supposed to count up.

[ttlworks]

To quote Garth: "If all you have is a hammer, every problem becomes a nail."

[GARTHWILSON]

ttlworks wrote:

To quote Garth: "If all you have is a hammer, every problem becomes a nail."

That wasn't me, unless I was just repeating an old saying. There is some truth in it though. We get creative and find ways to solve problems with whatever resources we have available. I definitely do that myself. Furthermore, if we don't have the tools to solve a particular problem, we tend to evaluate whether this one even needs to be solved. Maybe we can get where we want to go without solving this one.

[daniMolina]

ttlworks wrote:

To quote Garth: "If all you have is a hammer, every problem becomes a nail."

I'm always looking for a bigger hammer.

Here they are, CREG and TIMERS, first try at second iteration

Highlighted items are input/output from each unit. Even though CREG and TIMERS are very interconnected, I've chosen to make them separate units in my design, to reflect more closely the Block Diagram in the MOS6526 datasheet.

I'm pretty sure I'll need some NOT gates at some places. As the Clear/Set inputs are, of course, active low, and I don't think that's built into Wolfgang implementation.

I'm implementing it now into a simulator to verify the design... the only bad news I have (for myself, that is) is that even though I've planned to build CREGA, CREGB, TIMERA and TIMERB into a single board, I don't think that will be possible now. At least, good design (or luck?) was on my side, with the buses I've put into my boards, this won't be a problem. Board1 for CREGA and TIMERA, Board2 for CREGB and TIMERB. Adding some jumpers should allow making the two boards identical.

ttlworks wrote:

There are microscopic pictures of the 6526 silicon, but polygonizing them or extracting schematics won't be fun.

.

I tried this... with a 7404 die. So far, the process is not clicking into my mind... maybe another time

Cheers!

[John West]

Ken Shirriff's blog has a number of posts that go into detail on the reverse-engineering process. Lots of pictures showing how various types of transistor work, what they look like on a chip, and how they fit together.

For TTL, "Inside the 74181 ALU chip" is a good introduction: http://www.righto.com/2017/01/die-photo ... ering.html
For NMOS, perhaps "Reverse-engineering the Z-80: the silicon for two interesting gates explained": http://www.righto.com/2013/09/understan ... -gate.html

There are plenty of others, all worth reading.

[ttlworks]

Project 54/74 is about reverse engineering TTL chips.

For understanding the basics of NMOS, I would suggest to read introduction to VLSI systems, Mead & Conway 1978.
There is a nice thread in our forum: C64: 8701R2 clock generator chip dissected.

[daniMolina]

ttlworks wrote:

Project 54/74 is about reverse engineering TTL chips.

For understanding the basics of NMOS, I would suggest to read introduction to VLSI systems, Mead & Conway 1978.
There is a nice thread in our forum: C64: 8701R2 clock generator chip dissected.

I have the feeling polygonizing a silicon image is the kind of obsessive stuff that could keep me hooked for hours and hours... but hey, I have enough on my desk at the moment . Maybe when I eventually finish this...

Back on topic, my 1541 has arrived today, and it works, which is quite nice, as it was listed as untested. I don't have the time to test it with my 74HCT6526 until next weekend though but I'm really excited about it.

The design for the control registers is complete. Simulations are, I'd say, 100% clock-exact.
Regarding the timers... I'd say 90% complete also. All the weird details I've found :
- When the START control bit is set, it takes two cycles for the timer to begin counting. DONE
- When counting in PHI2 mode, as soon the timer reaches 0, it's reloaded and then it skips one cycle. So, if we load 4 into the latches we would get 4-3-2-1-4-4-3-2-1 and so on. DONE
- The same won't happen if we're counting from other source (CNT, TA, TA*CNT). We would get 4-3-2-1-0-4-3-2-1-0. DONE

I'm still missing the timer pulse/toggle output, but it doesn't seem complicated.

As I mentioned before... timers have ended up more complicated than expected.. so, unless I'm able to optimize them, each timer/creg pair will go into it's own board.

So, plans for next couple of weeks... test using a 1541 with my Board0, and begin real world testing of the creg/timers.

Cheers!

[Drass]

daniMolina wrote:

All the weird details I've found :
- When the START control bit is set, it takes two cycles for the timer to begin counting. DONE
- When counting in PHI2 mode, as soon the timer reaches 0, it's reloaded and then it skips one cycle. So, if we load 4 into the latches we would get 4-3-2-1-4-4-3-2-1 and so on. DONE
- The same won't happen if we're counting from other source (CNT, TA, TA*CNT). We would get 4-3-2-1-0-4-3-2-1-0. DONE

This attention to detail is bound to pay off on the C64. A lot of those demos and games require near perfect emulation to operate properly. Nicely done!

[daniMolina]

Drass wrote:

daniMolina wrote:

All the weird details I've found :
- When the START control bit is set, it takes two cycles for the timer to begin counting. DONE
- When counting in PHI2 mode, as soon the timer reaches 0, it's reloaded and then it skips one cycle. So, if we load 4 into the latches we would get 4-3-2-1-4-4-3-2-1 and so on. DONE
- The same won't happen if we're counting from other source (CNT, TA, TA*CNT). We would get 4-3-2-1-0-4-3-2-1-0. DONE

This attention to detail is bound to pay off on the C64. A lot of those demos and games require near perfect emulation to operate properly. Nicely done!

Yep, that's a question I can't get out of my head... How far can I be until things stop working? Firing an interrupt one cycle earlier would be acceptable? Right now, I don't think I can measure with enough accuracy a working 6526, at least, with my current equipment... So many questions!

Anyway, at least, timers are done, 100%. I'll start working this week in a breadboard prototype.

Cheers!

[daniMolina]

Just a quick update. I managed to steal a few moments today to try the 1541 and it worked. Beautifully, flawlessly. Great! I was able to read, write and format my one and only floppy disk.

However, joy did only last for 30 minutes. I can send and receive commands from the drive, but I just can't read anything. I didn't have the time to put the original 6526 back, and I only happen to have one single floppy... Which I have badly damaged while opening the notch to enable writing to the disk... So


Is the floppy disk broken?
Is it the drive?
Is it my board?

My bets and my wishes are on the floppy disk. Will need to get some more.

Edit: Just an even quicker update. It turns out, my disk was so badly damaged that it couldn't spin. After some surgery, now everything's working again. It's the worst looking floppy disk I've ever seen, but it's working!

Edit2: https://www.youtube.com/watch?v=LzwmSFyUcMI

[daniMolina]

The first iteration of hardware implementation for CREG and TIMERS is ready. With a very busy board (29 ICs in the end), I'll have to make one board for CRA and TIMERA, another for CRB and TIMERB.

As I didn't create a backplane from the beginning, and my buses are already fixed, I can't use the same design for both timers. The differences will be small, but they will be two different designs in the end.

I have started with TIMERB as it is slightly more complex. to make TIMERB I just need to cut down some functions.

Control Register

Timer Control

Down Counter

I guess there's no need to say it but, just in case, nothing's tested so far. Do not try this at home!

[daniMolina]

daniMolina wrote:

All the weird details I've found :
- When the START control bit is set, it takes two cycles for the timer to begin counting. DONE
- When counting in PHI2 mode, as soon the timer reaches 0, it's reloaded and then it skips one cycle. So, if we load 4 into the latches we would get 4-3-2-1-4-4-3-2-1 and so on. DONE
- The same won't happen if we're counting from another source (CNT, TA, TA*CNT). We would get 4-3-2-1-0-4-3-2-1-0. DONE

I'm quoting myself, as this piece of information is extremely important when it comes to the timers. Being one cycle off may not seem like a lot (And maybe, it really isn't...) But I think it could break havoc in the timer, especially if any piece of code is relying on TIMERB counting underflows of TIMERA, as the effect of a single cycle could be multiplied. That's why I'm aiming, at least, to be cycle-exact.

After spending the weekend working on the schematics, today I've built a small prototype. Just a 4 bit timer, and with a lot of stuff missing. It's just the timer, the input section (CNT, PHI2, all the delays) and the Forceload logic. Time to use my logic analyzer!

Counting CNT pulses (They were actually /IO2 pulses... but.... pulses anyway) As you can see, each time a pulse is sent, four cycles later the counter is decremented. When it reaches 0, then it's reloaded and goes back to the latched value (0011) in this case.

Q3, Q4 and DN are internal values... CNT pulses happens actually 2 cycles before Q3, but I just realized I missed it in the capture!

Counting PHI2 pulses, the counter is reloaded immediately when it reaches 0 (So we don't actually see the 0) and then, skips one cycle, repeating the first value.

Maybe I shouldn't say it... but I'm quite proud of myself

[ttlworks]

Nice going so far.

Building something that's supposed to be bug compatible to an existing chip sure is quite a challenge.
//As in: "if it would be easy, more hobbyists would be doing that".

;---

Noticed, that pin 5 of U21..U24 (74HCT192 UP count) are not connected in your schematic.
You really should tie those pins to VCC to prevent timer B from acting strange by accident.
That's because 74HCT inputs have a high impedance, and they may see some "dirt" when left floating.
Switching a neon light in the same room most certainly would do for triggering a floating UP count pin.

;---

IMHO CD4048 isn't a good choice for detecting timer underflow:
CD4048 propagation delay inputs to output at VCC=5V: 300ns typ., 600ns max.
CD4048 propagation delay expand input to outputs at VCC=5V: 190ns typ., 380ns max.

The UNDERFLOW signal generated by the two CD4048 goes through a 74HCT08 (17ns max.) and a 74HCT04 (17ns max.),
So the worst case propagation delay from counter B outputs to U11A 74HCT74 PULSE flipflop input is:
600ns + 380ns + 17ns + 17ns = 1014ns.

1MHz PHI2 means a 1000ns cycle time.

Would suggest to replace the two CD4048 by two 74HCT688 comparators:
74HCT688 propagation delay A,B to output at VCC=4.5V, CL=50pF, 25°C: 34ns max.
74HCT688 propagation delay /E to output at VCC=4.5V, CL=50pF, 25°C: 24ns max.