74HCT6526 - A MOS6526 implementation with 74xx ICs

[daniMolina]

Ok, so, testing on TIMERA is completed. I may still try more stuff eventually, but it feels quite good. I manage to get my missing CNT pulses... I just missed a pull-up resistor on the SBC!

Yesterday I said START was arriving a cycle earlier, however I have one extreme case, which makes me doubt it, and now I'm thinking it's a deeper issue. This fragment of code :

Code: Select all

					lda #$06
					sta CIA2_TALO
					lda #$00
					sta CIA2_TAHI
					lda #$01
					sta CIA2_CRGA
					lda #$00
					sta CIA2_CRGA

I setup TIMERA to count down from $0006. Then load $01 into CREGA to start the timer, then load $00 to stop it. Even though the timer is running in continuous mode, and we should see 6-5-4-3-2-1-6-6-5-4-3-2-1-6-6, by stopping the timer right on underflow, reload is not triggered. This is normal behavior, and I get it on original hardware, but also on 74HCT6526. So, if timer is starting one cycle later, then it's also stopping one cycle later, and indeed... In my last revision, I added a new FF in the clock pipeline to sync the clock pulses, instead of trying detect rising edge of PHI2 to count. This, of course, delays the whole pipeline by one cycle.

But also, a flip flop was also added to extend the LOAD Pulse for the timer (Before, as soon as one timer output was reloaded, the pulse ended, and this was causing many issues). Again, this delays forceload by one cycle.

The clock pipeline is complex, big, and kinda has it's own consciousness. It's based on Wolfgang Lorenz model (https://ist.uwaterloo.ca/~schepers/MJK/cia6526.html) with many tweaks to make it work. Although it now seems to work ok, I feel it's the weakest link, and that any attempt to make it better... will just make it worse.

After a very intense week, I'm going to let it cool a bit. Meanwhile I'll start working on B2 reusing B1 as it is.

Cheers!

[fachat]

Did you check the behavior with the famous c64 test suite of that guy I right now can't remember the name? I assume yes but just checking.
This is the gold standard for c64 emulators...

Edit:
Ah obviously it was Wolfgang Lorenz
The VICE emulator has even more tests. https://www.lemon64.com/forum/viewtopic ... ceec830ede

[daniMolina]

fachat wrote:

Did you check the behavior with the famous c64 test suite of that guy I right now can't remember the name? I assume yes but just checking.
This is the gold standard for c64 emulators...

Edit:
Ah obviously it was Wolfgang Lorenz
The VICE emulator has even more tests. https://www.lemon64.com/forum/viewtopic ... ceec830ede

I plan to do so, however, I need the full CIA to run them, as many tests are based on the interactions between the different units. So far, I do have DDR (A and B), PORT (A and B), TIMER A and CREG A. Not enough to run this suite. But yes, I will definitely run it.

[BigDumbDinosaur]

daniMolina wrote:

Regarding the ALARM bug, I have around 8 CIAs, ranging in date from 1986 to 1992, and I haven't been able to reproduce it. Of course, I don't mean it doesn't exists, but again... I see no need to replicate this

The TOD alarm bug was also not consistent from chip to chip. I personally never encountered it, mainly because I never used that alarm feature. If I needed an alarm I did it in software using the built-in jiffy IRQ by wedging into the ISR front end.

Looking back on my Commodore development days (primarily the C-128—I was doing business stuff, which the C-64 really couldn't handle well), it seemed just about every I/O chip produced by CSG had some “feature” to snag the unwary. For example, there were the 8563 and 8568 VDCs, both of which required their registers be set up in big-endian order. Now, why would a company that produces the 65xx family, which is little-endian, do something like that?

Frankly, I’m amazed this stuff actually worked. In particular, the C-128 was a timing nightmare almost beyond comprehension—my hat’s off to Bil Herd for getting that mess to actually run and to Fred Bowen for being able to write a kernel that was able to deal with the hardware kinks.

[fachat]

The VDCs basically were extended rip offs of the Motorola 6845 CRTC

[BigDumbDinosaur]

fachat wrote:

The VDCs basically were extended rip offs of the Motorola 6845 CRTC

That they were. In their favor was the simplicity of the surrounding circuitry needed to connect one to the system, but that was about it.

Stupidly, the guy who designed the thing provided only one register for setting the copy/repeat byte quantity, which limited the device to 256 bytes per operation. Scrolling an 80×25 screen meant programming the copy count to 199 and repeating the operation seven times after the initial copy. Since the attributes also had to be copied, that was eight operations as well. Had the designer provided a pair of registers, the same thing could have been accomplished in one iteration for display RAM and another for attribute RAM. Ditto for clearing the screen and other operations that involved memory copies or fills.

All-in-all, it was a lame design and Bil Herd made his dislike of the VDC no secret.

[daniMolina]

daniMolina wrote:

As stated before, FORCELOAD is a cycle earlier than it should be.

Not quite correct... FORCELOAD was a cycle later, not earlier!

Just bypassing one flipflop solved the issue, and now the behavior on FORCELOAD is cycle exact. Saving this one FLIPFLOP means I can remove a whole IC from the board.

[daniMolina]

One last thought for TIMERA, before moving on to B2.

This is my clock pipeline for the timer:

These are the sections of the pipeline :
Timer Input. It switches counting between CNT to PHI2, depending on the TAINMODE input from the Control Register. When TAINMODE=0, timer input always outputs 1. When it's 1, it emits a pulse after each CNT rising edge. As the CNT input is not syncronized to the system clock, these DFF convert the rising edge to a single clock pulse.
Start. If TASTART is 1, it equals the Timer Input value, allowing the timer to count. If TASTART is 0, nothing happens after this point
Underflow & Reload. This section handles the timers reload from the latches whenever needed. It isn't relevant to my issue.
Timer Clock. This section mixes the output of Timer input, whenever START=1, with PHI2, to generate a pulse each time the timer needs to count down. It's, I'd say, very convoluted, and it is so it can replicate the behaviour of MOS6526.

When counting down on PHI2, the moment we reach 0000 in the timer, it resets and reloads the original value from the latches. At this moment, U118B is reset, so during a PHI2 cycle, there's no clock to the timers, and the reloaded value is repeated for a cycle, with no 0 appearing at any time (3-2-1-3-3-2)

This is different when counting CNT pulses (Or TAPULSES for TIMER). Here we get 3-2-1-0-3-2-1....

I've made the following time diagram, when counting PHI2.

The issue is, the second FF (U119A) delays the clock by 1 cycle, so the timer starts counting 1 cycle late. Removing this FF fixes this, but then I'm not able to skip a clock after underflow. I've been scratching my head for a week, trying different solutions, but doesn't feel I'm getting any closer.

As I said before, this pipeline feels... delicate. Changing anything affects everything, and I'm actually amazed it works the way it does. So, for now, I'm moving into B2. Schematic is complete, and routing of the PCB is almost there. It's pretty much a reuse of B1, so it's been an easy one.

Oh, BTW, If the pipeline is complex, keep in mind that, when TIMERB is counting TA underflows, I'll have two of them chained.

Let's just hope a cycle offset it's not harmful

[daniMolina]

daniMolina wrote:

One last thought for TIMERA, before moving on to B2.

Ok, I'm very sorry, but I lied. I didn't know it when I posted this.... but I lied. I couldn't move it out of my mind... I was so close...

I've spent the last four days drafting tons of time diagrams. Trying to understand all the signals from the "timer clock" section of my previous schematic.

Reloading was perfect, skipping the cycle it had to skip. Starting and stopping seemed OK, counting just as many cycles as an original MOS6526.. but one cycle late. Start was arriving too late, and I needed it to reach the pipeline faster. But every attempt failed. At one point I got creative and I kind of invented the FFFF (FlipFlop From the Future). It had the value of my start bit, one cycle before setting it (Impossible, of course, but desperate situations require desperate measures), and with this, my hand-made simulations worked.

Yesterday, I gave up. There must be something very wrong with the whole design, if I need a FFFF, right?

Nope.

I have to go back to school... I may need some basic maths, like... very very basic.

Start wasn't arriving one cycle late, it was one cycle too early. Timer was one tick ahead of where it should, so... I was starting to count to early, not late!

So, of course, my FFFF became a regular DFF, of which I have no less than 100 in handy little packages of two (74HC74).

So...

And...

All test pass. So, until now, everything is cycle exact.

Now, for good, time to move on to B2. And of course, I'm going to need a new pcb for B1, but that no longer seems an obstacle.

Time to celebrate.

[BigEd]

Glad you didn't have to violate the space-time continuum!

[daniMolina]

BigEd wrote:

Glad you didn't have to violate the space-time continuum!

Who knows... those FFFF could be pretty useful... like... chain a few thousands of them together, so each one is one clock cycle further into the future and then... nothing is impossible

BTW, after adding the new FF into the START bit, I had to add again the one I removed for the FORCELOAD signal, so, in the end, only one FF was missing for B1 to be perfect!

[daniMolina]

Hi all.

I hope you've had a great summer. As my summer leave is comming to and end (Back to office this next monday... ugh!) I wanted to give you a quick status update.

I used some time this last few week to refine and prepare B2 (TimerB + CREGB). The board is now in production, and should be here in a couple of weeks, together with some missing components. I plan to have it assembled and tested sometime before the end of October. After the success of B1, I expect no big issues. This probably means there will be some, or a lot anyway. Feeling confident now.

Meanwhile, work is ongoing for B3 (SDR + ICR). SDR is mostly done, with very solid results from my logisim simulations. There´s still some stuff to iron out in the ICR. Design is pretty much unchaged from this, and i have zero confidence on some points. Specially, what happens when a IRQ fires during a ICR read. I have the feeling I'm reproducing the TIMERB bug on all interrupt sources.

For SDR, I think I may finally cheat a bit. I'm tring to simplify the state machine than controls the register, but with no results. I may need somewhere between 8-10 74xx ICs to build this. So I may go the GAL route. I have no experiences with them, but I think a 16V8 will be enough. I need 7 inputs, 3 outputs and 3 FlipFlops. Will need to investigate further, but seems within the capabilities of this chip. Still. I will try a full 74xx implementation.

Cheers!

[daniMolina]

daniMolina wrote:

For SDR, I think I may finally cheat a bit. I'm tring to simplify the state machine than controls the register, but with no results. I may need somewhere between 8-10 74xx ICs to build this. So I may go the GAL route. I have no experiences with them, but I think a 16V8 will be enough. I need 7 inputs, 3 outputs and 3 FlipFlops. Will need to investigate further, but seems within the capabilities of this chip. Still. I will try a full 74xx implementation.

Ah! The wonders of boolean algebra!

In turns out that this :

Is exactly the same as this :

I resorted back to 2 bit states instead of 3. One less bit, one less equation for the state machine. Juggling around the value for each state, and with some simplications... I can cut the IC count in half.

The main improvement has come from one little change. I have an idling state, a "Load shift register" state, and two for "Emit byte", one with no more bytes in the queue, one with an additional byte in the queue. By loading the shift register also on the Idle state, everything fell into place. True, I'm reloading the output shift register eache PHI2 cycle but... it doesn't matter at all.

This brings down the total IC count for SDR to around 21. ICR will be aproximately the same, so I'm looking at 40+ ICs in a single board, meaning this will be, so far, the densest of all the stack. Right now B2 is the densest one, with 28 ICs.

However, either I'm getting better at this, or somehow SDR turned out ot be more logically organized. The point is, layout is coming out very nicely, and I'm managing to cram the ICs very very close to each other :

This is how B3, with only SDR right now, looks so far :

[daniMolina]

Just a quick early-october update. B2 PCBs and components arrived last week, and it's now assembled and fully functional.

I still need to check if TIMERB counting TIMERA underflows is cycle-accurate, but everything else, just checks out.

My goal is to have SDR+ICR done before end of year. Design and layout is done, and just needs a last review before ordering PCBs. This is getting closer and closer to an end!

[daniMolina]

TimerB counting TimerA underflows, is also cycle-exact!

Moving on!