6502.org

Hey Dani, that is just great! I’m happy that the 6502 model was helpful to you, and it’s amazing to see it being used in this way to drive other components being modeled. Of course it’s perfectly capable of doing that. Fantastic! Looking forward to seeing more of your progress.

Definitely, as it is still unclear when I'll be able to properly setup my lab again, I decided to move to a virtual one. @Drass model of the 6502 in logisim has proven extremely useful
This is my first crude attempt at a 6526 in logisim. With both DDR modules implemented.
And this is the very same logisim6526 working with Drass CPU, running the same code I've been using until know for my SBC6526 with just very minor tweaks.

I plan to implement mu current design of ports, control registers and timers during this weekend. We'll see how they behave.

Cheers!

It took a bit longer than expected but..
DDR, PORT, CREG, and TIMERA. Done, and more importantly, working.

I have tested all the test cased I had... and they all work just as expected. I'm now coding a 6502 test suite for them, but it's quite reasuring so far.

Nice progress Dani. I'm excited to see the 6502 and 6526 models working together. Very cool.

(I will be posting an NMOS version of the 6502 component shortly. You may not need or want the NMOS functionality but I thought I would mention it anyways just in case).

Cheers.

Just saw your post on the 100Mhz TTL cpu! Nice achievement!

So far, I'm doing fine with our previous model. Even though I do have some good assembly knowledge, I'm not an expert... and I usually revert to the most basic opcodes. So far, everything I've thrown at your model, has worked for me, but thanks!

Meanwhile, I've spent the weekend getting close and personal with the TOD on a real 6526, putting it through all possible transitions... both valid, and invalid ones. Even though TOD behaviour accuracy won't be critical for any possible 6526 uses, I want to know how it behaves.

My findings so far.

TOD is composed by 4 registers, Hours, Minutes, Seconds, and Tenths. Each one is (almost) a full fledged counter, with apparently some additional logic to turn them into a BCD counters.

Boths minutes and seconds are the same. High nibble represents first digit, low nibble, the second. High nibble is a 3 bit counter, lower nibble, 4 bit. Whenever high nibble transitions from 5 to 6, it reverts to 0 and pushes a tick pulse to the next counter. Same goes for lower nibble, when transitioning from 9 to A.
However, if you write an invalid value on them (let´s say, 6A) they happily count over, rolling back to zero after 7 (3bit) and F (4 bit). In this cases, no increment happens for the next in line counter.

In the tenths register, only the lower nibble is usable. Again, 4 bit counter than resets to 0 when transitioning from 9 to A and pushing a tick, in this case, to the seconds lower nibble. Writing and A allows you to count all over to F and then it rolls over to 0, without a tick. Upper nibble always reads 0.
As TOD can be programmed to work with both a 50HZ or 60 Hz signal, there must by some kind of internal counter to control this. It's not readable, it's not writeable, but it's there. It's also not clearly visible on the die, but it has to be there. Writing to the tenths register always resets this counter (if clock is not running!). So far, in my design, this is an aditional counter hardwired to an input of all 0s. Again, this doesn't seem to be the way it's really implemented, but behaviour should be the same.

Hours register is the most complicated. Low nibble, this is the last digit of the hour. In the upper nibble, high order bit is the PM/AM flag. Lower bit is the first digit of hours (Only 1, or 0). 2 and 3 bits always read 0, and there doesn't seem to be any evidence of any storage for them existing on the die.

For this, the cycle is as follows (Expected) 01 - 02 - 03 - 04 - 05 - 06 - 07 - 08 - 09 - 10 - 11 - 12 - 01
Whenever 12 is written here, the AM/PM flag flips, so, Writing 0x12 in this register results in 0x92 being actually stored. Writing 0x92 results in 0x12.
Same as other registers, the lower nibble is a full 4 bit counter, so writing 0x0a allows to go up untill 0x0F, then it flips to 0x00 (Invalid by the way). Writing 0x13, then it goes until 0x1F, and rolls over to 0x10. In both this invalid counts, AM/PM flag is never affected.

There's no indication on which value does TOD take on reset. Testing reveals that, most of the time, it gets set to 81:00:00:0. There's no clear indication on what the AM/PM flag represents. 1 is PM? AM? I guess it's up to the programmer here! But, on a few ocassions, it resets to 01:00:00:0. So probably everything except the AM/PM flag is wired to reset to a specific value, but the flag maybe takes whatever's on the bus.

Besides this, everything else is pretty well documented already. The latching of the TOD value on read, the stop and restart of the TOD on writes, and ALARM.

Regarding ALARM, I have yet to investigate it's famous bug. Same goes for the ALARM initial value which is, at least for me, completely unknown.

Interesting low-level details! About the 50/60Hz count, what you say seems to differ from what was written in the bug report you link:
> According to Vice the counter is never reset, according to my C64 it IS reset when all registers are written, but not when only the 1/10 seconds are written while the clock is running.

Or perhaps I misunderstand?

Nice catch! I've been writing to all registers during my tests. Hours, then minutes, then seconds, then tenths. Time stops when writing to hours, restarts when writing tenths, and yes, in this case, the internal counter is reset.

Will need to test it writing only to tenths, with the time running.

Just to put an end to this weekend.
I can now confirm this is the case. The 50/60hz counter (I've been calling it "ticker", as in what makes a clock tick, not sure how accurate the use of 'ticker' here is but...) is reset when writing the tenths register only when the clock is stopped (after a write to the hours register)
Writing to the tenths when the clock is running won't make it reset.

Regarding the interrupts, I've been running a loop firing them at an exact second (tenths=0) and it has not skipped a single interrupt. It sometimes fires earlier. 1 tenth earlier, but this could be some internal latching of the value. It's not consistent either way, around 50/50.

And the very last quirk. Let's say the ticker goes from 0 to 5, then the next transition, it reverts to 0 and advances the tenths registers. If you switch from 60hz to 50hz when the counter is between 0-4, it correctly behaves, and when it reaches 5, it advances the tenths. If however the change happens when the ticker is at five, it skips a beat, and 5 additional ticks are needed to advance 1 tenth.

This pretty much I'd say fully describes the 6526 I have on my SBC. With a datecode of 3486, it seem to be a somewhat old model. Not a 6526A rated for 2Mhz. Problaby the old NMOS, versus newest HMOS.

I may repeat all testing with a newer one to look for any differences in behaviour, but only to have a fully documented IC. I may cut some corners when implementing TOD in my 74HCT6256. Seeing as the behaviour changes for some critical part of the IC, such as the timers, between revisions, I don't think TOD has to be cycle exact.

So, done for the weekend. Plans for next, implementing TOD on logisim, which, by the way, has already got TIMERB: Cheers!

Please welcome the new member of the family:
We now have a working TOD! This is 4 registers more done, with now only SDR and ICR left.

I knew TOD was going to be massive... but wow!
With 4 registers for the alarm, 7 counters for the Time, plus half a dozen DFF for control, and the HH and PM bits... add 20 gates for the register write and read enable signals, and to compare the ALARM value with current TOD to trigger the interrupt... well... I'm looking at no less than 35 ICs in the 7400 implementation, making this the most dense board I'll have to face.

And this is not the whole story. My current implementation works pretty much the same as the original if you stay within valid values. For example:

On a real TOD. the Minutes low nibbled advances when, and only when, high nibble seconds goes from 5 to 6. I've implemented this detecting when bits 1 and 2 are set, so I will also flip the minutes at other values. Invalid time representations, yes, but no 100% accurate. For this I will need 4 input gates and a bunch of inverters. I haven't do the math... but this could take no less than 5 additional ICs.

I'll leave like this for now. This may only fail on some very specific cases where unorthodox TOD use exists.

Things are moving fast now!

3 days, and SDR is almost done. I can shift in 8 bits and store the resultant byte on the SDR, I can write a byte to the SDR and it is sent via the SP pin as it should. An additional write to the SDR while it is sending results in the new byte being "enqueued" for sending, and any new writes, overwrittes the 1-byte queue.

I'm using a 74299 for the shift register, and a 74193 to keep track of how many bits have been sent/received. I've tried to used just one of them for the whole SDR but, I was having some issues, as the clock pulses do need to behave slightly... I ended up having two separate 299/193 pairs. One to handle the input mode, another for the output.

I still need to do some tweaks to some control signals, and I think I need to shift CNT phase a bit, in output mode.

As per the datasheet:

"Data shifted out becomes valid on the falling edge on CNT and remains valid until the next falling edge."
Right now, I do have data valid at the falling edge, but it changes on rising edge of CNT. Which is not correct.

On another subject. I'm facing a dilemma right now. Glue logic has been manageable until now. But with TOD and SDR.... yikes!

I'm considering using a GAL here. It will reduce my chip counts by a significant amount. (For TOD, from 30 to 24 ICs, for SDR, from 16 to 10 probably) but I do feel this is like cheating somehow . But I will probably stick with 74xx parts. Anyway, if I wanted to do this in an efficient way, I would've gone for the CPLD/FPGA from the very beggining right?

If you post the schematic (or even just the most worrisome subsections) then we forumites could have a squint to see if things can be juggled to reduce the package count. It's a fun game, IMO -- somewhat reminiscent of Tetris!

-- Jeff

Oh sure, I just hope I don't give anyone a Christmas headache

TOD is a couple of posts above. It has 4 mayor "logic" groups.
- On the lower right, a bunch of gates to control the Hours register, including the AM/PM Flag. Lot of transitions happen here at weird points. Like MSB of the Hours fliping when going from 12 to 01, and from 09 to 10. Then AM/PM flips on transition from 11 to 12, and any time 12 is written to the register.
- In the middle, another group controlling when all the registers advance, or reset. Most are a simple 2-input AND gate. Tenths has the TODIN input to complicate things (Control if we're on 50hz or 60hz). And of course, the HOUR register again.
- In the upper left corner, the register selection logic. 4 register enable inputs, together with the ALARM control signal to select OE on 4 registers, or WE on 8.
- And last but not least, the moster 32 bit XOR compare. I'm using a 32 bit here for convenience, but actually only 24 bits are important. The others are always 0. In real world implementation, this could be 3 74688 comparators.

Now with the SDR. The bulk of gates is on the left. 3 DFF and a ton of gates to implement a sequential state machine. This handles the output behaviour of the serial register. This has 2 inputs: Regiter write and Shift End, and actually, 4 states.
- 000 Shift register idling. Not sending data, and no data to send in the register
- 100 We transition here on data write. The byte written into the register is transferred to the shift register.
- 010 Transition where from above on next PHI2 cycle. We start sending the byte, MSB first.
- If a new write is done before ending, we go to 011. We have a new byte waiting in the register. Move again to 100 when current byte has been sent. Reload the shift register again and continue transmiting
- From 010, is no new byte is written, jump back to idle, and trigger a interrupt in the transition.

Even though it's only 4 states, and it could be solved with only 2 bits for them, it needed bigger gates (3/4 inputs) for the transitions. This way, S2 and S1 conveniently match my control signals.

Everything else is simpler, with just gates to enable/disable the input and output parts of the circuit.

I'm only missing a few buffers to multiplex CNT and SP pins, as they are bidirectional. I still haven't figured bidirectional pins out in logisim.

It's probably been 20 years since I've done a sequential state machine. It works, which is nice milestone.
Schematic is a mess so far. I need to untangle it, very much.

If you really fell like taking a look at it, and need more details, just let me know.

To close for today, the latest family photo:
Only ICR missing!

Oh wow, this was fast.

It took me about 2 hours to implement ICR. I had it drafted since like 1 year ago maybe. It turned out to work pretty well.

ICR: The full 6526: And how it looks inside my Logisim SBC: I really do like how it looks with all the registers there... It actually gave me the idea of adding little 7 segment displays to the physical impementation showing the internal values. We'll see how that goes.

You may see there are still some unconnected pins in the SBC, and a couple inside the 6526 itself. There's plenty of stuff on my to-do list still!!

- Cleanup and tidy the LOGISIM implementation. Both inside the registers, and in the block diagram
- Complete the LOGISIM SBC so all pins are connected and can be tested
- Complete a full test suite. I will gather as much as I can from VICE test suite, and all other 6526 lying around
- Then, back to the real world! i'm working in parallel in a new version of my SBC. Besides fixing some first version issues, It will have two 6526 slots. In the first version, I could connect either a MOS6526 or my 74HCT6526. Also, all SBC core functions will be handled by the 6522. Right now, the 6526 drives the LCD, and as I'm resetting the 6526 all the time for the tests, it's messing up with the display.
- After all of this... time to finally break up with Eagle Cad, and recreate the LOGISIM6526, this time with KiCad
- And of course... order the pcbs, build the pcbs, test the pcbs, watch them fail, and repeat until success, or exhaustion

Very nice Dani. A big thumbs up!

I imagine there are many boundary conditions and interactions to test here. I like your idea of using the VICE test suite to exercise the Logisim model. I’ve not looked at it so I’m looking forward to what you discover there. Once thing to remember is that the 6502 Logisim component may still have errors, so be on the lookout for bugs there. Also, the VICE test suite may rely on NMOS side-effects that are not implemented in the version you are using. Some of these side-effect are common usage on C64 code. (I recall at least one instance where a missing NMOS side-effect caused the C74-6502 to crash on the C64).

When you get to the hardware, it might not be a bad idea to have a couple of spare footprints on the PCB just in case you need to patch the boards here and there.

Thanks Drass. As usual, yours is a very valuable insight!

Yep, getting a 6526 to work as per its specification (If we dare to call that datasheet specification) is easy. Getting it to be cycle exact to a real one, and, more importantly, to replicate any unexpected side effects thay may arise from it's construction... just feels unreachable for me and my equipment at the moment.

I somehow expecting the 6526 to be not so much time critical as the CPU itself, specially when we talk about the C64. Even back in the 80's, programmers took advantage of a lot of quircks, and I can barely imaging what modern day demos even do. But, as some things had changed as commodore evolved the fabrication methods (Interrupts firing one cycle earlier or later, depending on the mode, comes to my mind) it may turn to be less demanding here.

Quarantined holydays make for a great testing season. So today I got my C64 out, my spare CIAs, and I'm inspecting the serial port behaviour. So far. it's looking great. This a comparison of the LOGISIM6526 and a real MOS6526 outputing 0xAA (10101010) on it's serial port:
Consecutive writes also work the same.

On to more testing!