After quite some testing under Logisim, and with all my available fingers tightly crossed, the order for B3 (SDR and ICR) has been placed. With this one, only TOD is missing, so a lot of testing is due on real hardware, with as many as possible Commodore computer I can get my hands on.

As we're nearing the end of the year, holidays, family gatherings, and the usual stuff, I may not start with this new board until next year, but I'll keep the board posted

Cheers!

Hi all, I hope you're having a great start of the new year!

I want to introduce you to the newest member of the family.



B3, with ICR fully populated. The upper half of the board is the SDR, but I won't be soldering that in until ICR is validated. There are a couple of expensive ICs there (Two 74299 shifters) which I'd rather not to solder until I know the ICR works fine.



And... to my great surprise... it does. I've been only able to do some minor tests, as I finished assembling the ICR just a couple hours ago. So far :

• Interrupt mask can be properly set and cleared.
• Timer A and Timer B interrupts work, and I'm proud to say, the appear cycle exact!
• Flag interrupt it's not working for some reason. Could be a a bad connection or solder joint, as at first glance, I see nothing out of place in the schematic. Further investigation is required.
• TOD and SDR interrupts can't be tested yet, as there's no TOD or SDR to be fire the interrupt. Hopes are high, given the circuit for them is pretty much the same as TA and TB
• Timer B bug will require extensive testing. Theres a 50/50 chance of it being "fixed". If I've managed to replicate it, I'm afraid I will also have a Timer A, SDR, TOD, and FLAG interrupt bug.

This is truly a huge milestone. I will test as soon as possible the full stack on a real C64, as now I have pretty much everything needed by the computer to work properly. TOD, SDR and Flag interrupts are not used a lot.

Today, after 4 and a half years of work, I'm 99% sure this project will succeed!

Cheers!

A thing of beauty! Well done!

Thanks!!

I figured out what's wrong with the flag interrupts.

I was using this (somehow unorthodox) circuit for edge detection :



When /FLAG went low, it sent a clock pulse into the first DFF, setting it to high. At the same time, /Q was fed into /SET on the second DFF, and /RESET of itself. This sets second DFF to 1, while resetting first one to 0.

I've used the same setup for CNT edge detection on the timers and it worked with no issues, but somehow, it's not working here. Connecting the first DFF /RESET pin to /Q of the SECOND DFF solves the problem, and it's probably a more correct approach.



A quick fix on the PCB, and now FLAG interrupts are working as expected. Also... they're also cycle exact. I'm getting used to this!

Now, time for testing on a C64. I'll keep you posted.

Cheers!

And we're looking at a partial success with the SDR.

Sending a byte, causes CNT to pulse 8 times, and an interrupt is generated afterwards. (Empty buffer interrupt)
Sending two bytes, causes CNT to pulse 16 times, and an interrupt is generated afterwards. (Empty buffer interrupt, again)

This means the state machine that controls the output is pretty much correct. However, no byte is received on the second CIA. Or, more accurately, a 00 is received. (The second CIA being a real MOS6526). The interrupt bit is set in the second CIA, so it acknowledges the byte being received, even though it is zero. I need to get the Logic Analizer out, to check is SP is doing anything, but probably it's flat at 0.

Receiving a byte is not looking good. I can see the timer counting CNT pulses, when configured to do so, so CNT is being received. However, no interrupt is generated, and nothing gets written into the SDR. This points to an issue in the shift register(U307) and/or bit counter (U308)

The SDR is aware of the SPMODE bit (input or output). Trying to send a byte when the SDR is configured for INPUT, doesn't do anything (except writing to the SDR register, which is expected), but nothing is shifted out.

The output stage fix feels easy. As it is sending enough pulses, and stoping right when it has to stop, I can trust the state machine is doing it's job. I'm now pretty sure the clock pulse to load the shift register (U313) is arriving too late, right after it has been put into output mode (S1=0), so it's not loading the value present in the register. Delaying this control bit for the shift register by one clock cycle should do the trick. I have no spare FFs in the board, so some hacking will be needed.

Regarding the input stage issues.. there's a couple points where I'm replicating the DFF arrangement seen in here http://forum.6502.org/download/file.php?id=17004&mode=view. I'm using it to sync the CNT pulses, and again to generate the FULL signal, that indicates 8 bits have been received. Any of these two circuits failing would cause what I'm seing. Two bodge wires and two cut traces should correct this, and hopefully, bring the input stage to live.

The schematic for B3 is here https://github.com/dmolinagarcia/74HCT6526/blob/main/pdf/B3.pdf if anyone feels like taking a look.

Cheers!

I was, indeed, right!



Here you can see the 74HCT6526 SDR block, sending byte after byte to a real MOS6526. As expected, adding a flipflop to delay the S1 signal to the 74299 shift register, is enough for it to load the byte from the register. From there, it gets sent with no issues via the serial port. Woo hoo!!

(BTW, ignore the 17.7 MHz display... for reasons I yet do not understand... the clockmeter has gone wild, I'm still at 1 MHz)

Just two minor issues remain. After the byte is sent, CNT stays low. It shouldn't. This should be fixed, as it's not a good thing to keep an open collector line busy. Turns out, I have and OR gate that already takes care of this situation, by gating the control bit for the CNT output with the SDRCOUNT signal, so it will release the line when not sending data out. Quick fix!

And with that, the final issue. It's not 100% cycle exact. Sending a byte with TimerA set at 0x00FF fires the interrupt 4 cycles earlier than the original. I'll keep this in mind, but it's on the bottom of my priorities.

Now, time to fix the input stage! I'm still clueless here, so I'll have to rig the Logic Analyzer and see what's going on.

Cheers!

Yep... I was definitely clueless...



See that Flip Flop? It's upside down! So... Flop Flip?

I'll never kwow how it happened. Fortunately, only the /RES and /SET inputs are wrong. Clock, Data, Q and /Q are tied correctly, so I wasn't totally clueless I think...

I lifted up those two pins from the PCB, added a couple of wires to it... and... no, still does not work at all.



Still true. Working on it!

Great progress nevertheless! Keep up the good work!

I know the 6526 is a pain, I once programmed the CIA timer emulation a long time ago...

So I congratulate already on the work done so far!

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I do now have a fully working SDR. Awesome!!

Here you can see a capture of the byte 0x15 being sent from a real CIA :



Of course, it can receive other bytes too. It has been running on a loop for over half an hour. Not a single bit has been misplaced!

There were two issues on the input stage. First one, the reversed flip-flop I mentioned earlier. Second one, same issue as with the FLAG edge detector in the ICR. The circuit I used in the Timers to detect CNT edges:



won't work here. The /R input for the first pin, has to be connected to the /q input of the next flipflop:



The only difference between this board and the timers, is that on the timers, FFs are clocked by PHI2. On the SDR and ICR, they're clocked by /PHI2. As the sending CIA is on the same PHI2 as the receiving CIA, I think the edge arrives precisely at the rising edge of /PHI2, so it's missed by my circuits. It works on the timers by mere luck, so I will change that for a more correct edge detector.

To fix this two issues, a little bit of surgery was required :




Sending a byte is not cycle exact. I'm off by a handful of cycles. Receiving a byte... is exact! The interrupt fires at the same exact cycle.

So now... time to clean up my lab (eerrr... I mean... the kitchen.. ) and update all the schematics with all the fixes I've implemented. I won't order new boards for now, but I will publish a completely updated release. There were some minor things to tweak on all boards anyway, so it's time for a clean up.

Before getting into TOD, I want to plug this beauty on a real C64. I should even build a second one. With only TOD missing... This is going to be fun.

And... wow... only TOD left to do... Even though it's probably the biggest unit... there's not a lot of complexity there. I can already see the light at the end of the tunnel!

Cheers!

Nothing much to add. I've really enjoyed following your project and I like seeing the mistakes and bodges. I find them oddly inspiring (or maybe comforting).

Thanks Andrew. It's very nice knowing that my work is having some good impact. This week I've re-read the whole thread, and it's amazing how much I've learnt from all the good advice of the great people in this forum. To know that I'm returning a least a bit of that gives sense to this project.

BTW, I've just updated the gitHub repository with all the fixes I had pending. Everything has been given a cleanup. In the unlikely case that someone feels like building a 74HCT6256, please take a look at the readme, as I explain the differences between all the releases. This latest update has introduced something (A change in the controlbus) thay could cause incompatibilities between the boards. This means, I've moved to version 0.2.0 (from 0.1.2).

Now, I'm taking a week of, before getting my hands dirty with the TOD.

Cheers!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ya, language is hard. And I'm sure there's an interesting philosophical discussion to be had about how you can never truly understand someone unless you know the full context of their head.

I find a beauty in seeing wires on an otherwise clean board. Sure, it means mistakes were made in design but also that there was the ingenuity to correct them. A hard to reach pad has been soldered, an unexpected signal has been repurposed. An LDO SOT23 has been carefully folded down onto another one because the power requirements were misread and it was absolutely awful but it worked

The short of it is I think we're both saying the same thing

"to spoil something by doing it badly"

May not be the most accurate definition for our loved wires. Sure, sometimes there're done pretty badly, but they're not spoling our builds, they making them better

And, sure, the quality of my bodges is not great. I've got quite good at soldering SMDs, with very few errors, and a nice looking result, but my bodges... they don't look good. They work at least, which is always the first step. Quoting myself from 4 years ago...

Just a quick ninja update.

I've just booted up a C64 with CIA2 replaced by the 74HCT6526.

I'm getting mixed results from the VICE test suite, but leaning to the success. I need to investigate the code to fully understand them, as some tests seem to be failing if boths cías are not the same (New Vs Old). The 74HCT6526 seems closer to the old CIA than to the new one.

Anyway, just to show off a bit... I've tried running some demos, as I expect them to squeeze as much as possible the whole system.

https://twitter.com/DaniMolina1982/status/1618710992783020032?t=Ar6LfL_cJlRa4N0lo-W61Q&s=19

Sorry for linking social media. I know this is not for everyone liking, but I'm on mobile right now and it was the easiest way.

I'll post detailed test results soon.

Cheers!