TTL 6502 Here I come

[cbmeeks]

Incredible work!

[ttlworks]

To me, that C64 motherboard looks like ASSY-NO.326298 / REV.A (1982), but say... the SID is missing ?
Now this explains why a TTL implementation of the SID seems to be more interesting to you than a TTL implementation of the 6526.

Congratulations on getting the C64 up and running, I already was afraid this would require a lot more work.
Now why does it always take most of the time to find the most simple errors.


BTW: When running the oscillator and the SBC from different power supplies,
and they both are not powered up at the same time,
another trick for limiting the current that goes through the OSC line from oscillator to SBC
could be something like this:

[Drass]

Thanks for all the support and interest along the way gents, and especially thanks for Jeff and Dieter. It’s a heck of journey and very rewarding indeed.

I’m curious about what the pedigree of the motherboard tells us. I bought this one in a bit of a rush to get testing started, and it is indeed missing SID. The video signal on it is also a bit flaky, and the display turns to black and white periodically. I thought it would do for testing since it runs properly otherwise (just without sound and sometimes black and white). But I am making the rounds now online looking for one in nicer condition, one with the whole chip set.

As a next step, I want to spend a little time testing compatibility with a variety of games and programs. All suggestions welcome on that. It would be nice to know of any specific programs which exercise different techniques and features on the machine.

Regarding the VFO, does the circuit above have the ‘245 without power if VCC2 is down? I thought that might present the same problem Dr Jefyll described, where the VFO tries to supply power. Another idea is having an AND gate, powered by VCC1, with one input being the VFO output and the other VCC2, with a large value pull-down. That way, if VCC2 is down, the pull-down prevents the pin from floating and the AND get will keep the output low. Does that work?

[ttlworks]

Drass wrote:

Thanks for all the support and interest along the way gents, and especially thanks for Jeff and Dieter.

You are welcome, and... go, Drass, go !

Drass wrote:

The video signal on it is also a bit flaky, and the display turns to black and white periodically.

From the picture of the test setup, your approach of sending the composite video signal into the monitor
isn't exactly "inspiring confidence", please try using a proper connector that fits the monitor input
instead of two ground clips first...

Drass wrote:

Regarding the VFO, does the circuit above have the ‘245 without power if VCC2 is down?
I thought that might present the same problem Dr Jefyll described, where the VFO tries to supply power.

The '245 is without power if VCC2 is down, but if VCC1=5V that 1kOhm resistor would limit the current to 5mA
to prevent the VFO output driver and the '245 input protection diodes from being damaged.

Of course, the resistor plus the '245 input capacitance would form up a low pass filter,
and that's why I had added that 220pF capacitor in parallel to the resistor (a smaller capacitor probably would do)
to make sure that the edges of the clock signal at the '245 input would stay "nice and clean".

Drass wrote:

Another idea is having an AND gate, powered by VCC1, with one input being the VFO output and the other VCC2,
with a large value pull-down. That way, if VCC2 is down, the pull-down prevents the pin from floating and the AND
get will keep the output low.

Might work too, but to me it feels less safe than putting a resistor between VFO output and gate input.
...Especially if VCC1 > (VCC2 + 0.3V) by accident, like when VCC1 powers up before VCC2.

;---

Edit: about test software:
The page about the Chameleon core bugs (C64 in a FPGA) mentions a VICE test programs repository.
Also, take a look at the FPGA64 page, which mentions some games and demos.

[Drass]

Thanks for the suggestions Dieter. Some good info to work with. I went ahead and got a C64 with a SID chip in it so I could be a little more thorough in the testing. It seems to work perfectly, so far as I can tell, so I was ready to get started with some trials.

The basic functions in the TTL CPU work, so it stands to reason that lots of games should work as well. I still found the whole thing amazing nevertheless -- every successful run of a new game put a smile on my face:

But, there were problems as well. Some of these games push the limits on the C64, and there are lots of subtle tricks being used. It's going to be fascinating to explore the extent of compatibility here. For the actual tests, I used the list of games from FPGA64 above, various other titles, and a list of “best of” titles from one of those showcase YouTube videos. Here now are the results so far:

Some classics and others

Defender — OK
Pac-Man —OK
Pole Position — OK
Space Invaders — OK
Galaga — OK
Pit stop 2 — OK
Rambo — OK
Last Ninja II — OK
Ghostbusters — OK
Kickstart — OK
Commando — OK
Neoclyps — OK
Metroblitz — OK
Mody Dick — OK

FPGA64 list
(http://www.syntiac.com/fpga64.htmll)

ACE2 — OK
Barbarian — OK
Bluemax — OK
Delta — OK
Elidon — OK
Karateka — OK
KillerWatt — OK
Paradroid — OK
IK+ — Runs but crashes
Impossible Mission — Runs but hangs

"Best of" from YouTube
(https://youtu.be/ZLHhyI35Dgw)

1983: Lode Runner — OK
1984: Boulder Dash — OK
1986: Legend of Kage — OK
1987: International Karate — OK
1987: Maniac Mansion — OK
1987: Barbarian — OK
1987: Last Ninja — OK
1987: California Games — Runs but title screen loops ???
1987: Bubble Bobble — Runs but title screen loops ???

Definitely mixed results, but not bad at all for a first go! I've omitted from the list several titles that I either I don't have, or that were flaky (i.e., the games also had problems with the 6510 installed, I'll need to track down reliable versions of these and try again). As for the problems, I’m not altogether sure how to proceed. Are the issues related to cycle-accuracy, timing, illegal opcodes, ??? No idea! I'll have to think about some strategies to investigate. Any and all suggestions welcome on that score.

Cheers for now,
Drass

[BigEd]

Might be worth checking hoglet's Protocol Analyser thread?

[ttlworks]

IMHO when comparing NMOS 6502 and 65C02, RDY works a bit different, and we probably had underestimated this effect.

OurCPU aims to be cycle exact to the NMOS 6502, except for RDY.

If it would be cycle exact to the NMOS 6502 _including_ the response to RDY,
another idea (not sure if it's a good idea) for identifying "compatibility problems"
might be running OurCPU and a 6510 "in parallel".

Means to have a little PCB with a 6510 plugged between the C64 6510 socket and OurCPU,
then to wire /RES, NMI, /IRQ, RDY, AEC and the clock input together for both CPUs.
Then to connect the 6510 address and data bus and I\O port to the C64,
while leaving the address bus and the I\O port of OurCPU "open",
and to place a 74245 (or 74541) in the data bus between 6510 and OurCPU to make sure
that OurCPU can only read data, but not write it to the C64.

_If_ the CPUs would be doing the same, when the CPUs own the bus the output on the address bus
and the I\O port are supposed to be identical, same thing for the data during write cycles.
So we could compare the output of both CPUs with some 74688 comparators and latch the result
into a 7474 at the falling edge of PHI2.
When triggering the 'scope with the first "comparison error" pulse output of the 7474,
we would have the exact point where both CPUs are acting differently to the code.

Both CPUs probably might need a diffrent amount of cycles to come out of the RESET sequence,
but this could be fixed when delaying the /RES input of one of the CPUs with a 74164
clocked with PHI2 or such.

Hmm... better try if this "comparator idea" works out as intended with two 6510 chips first.

[ttlworks]

Dug out some info about RDY:

MOS MCS6500 family hardware manual, page 37:
The RDY function will not stop the processor in a cycle in which a WRITE operation is performed.
If the RDY line goes from high to low during a WRITE cycle the processor will execute that cycle
and will then stop in the next READ cycle (R/W = 1).

From Christian Bauer's article about the 6567/6569:
2.2 6510 processor:
Interrupts are only recognized if the RDY line is high.

Not sure, how important those little details are for software running on the C64... but at the moment, I don't see any other hint.
The "illegal" NMOS 6502 instructions in the TTL CPU are supposed to work, except for ARR in decimal mode which isn't implemented.
Hmm... If it would be a problem related to bus timing, probably a lot more of the C64 games would crash.

[GaBuZoMeu]

The idea of comparing the TTL-CPU against the 6510 sounds logical - but I suspect it could become a signal quality nightmare

Is there any realistic chance to disassemble these games - perhaps using White Flames interactive one ? Just to seek for "illegal" opcodes.

[Dr Jefyll]

GaBuZoMeu wrote:

Is there any realistic chance to disassemble these games - perhaps using White Flames interactive one ? Just to seek for "illegal" opcodes.

Illegal opcodes, or at least most of them, are supposed to function as on an actual 6510. But it might be a good idea to check and see which ones are encountered. If Drass wants to search, disassembly is a valid option but it might not be the easiest way.

Perhaps Drass's Logic Analyzer is capable of detecting any given illegal instruction on the fly. Ideally it could detect any of several illegal instructions. Failing that, the TTL CPU's microcode could be adapted for the job. The machine has microcode to implement every 65xx instruction, and he could cook up a custom microcode version that somehow traps illegal instructions rather than executing them. This would mean blasting a new set of microcode EPROM's, but the effort would be less than disassembly (especially if multiple programs are to be examined).

Hmm, another idea. Leave it so illegal instructions do execute, and merely flag them (ie, the trap becomes optional). Assuming there's an output somewhere that's unused or could be borrowed, the custom microcode could activate that output during execution of an illegal instruction. That action could cause a trap if desired (just tie the output to /NMI). But otherwise the event could be merely observed on a scope or recorded.

-- Jeff

[ttlworks]

GaBuZoMeu wrote:

The idea of comparing the TTL-CPU against the 6510 sounds logical - but I suspect it could become a signal quality nightmare

I suspect this too.

That's why I'm not sure if it's a good idea and suggested to test the concept with two 6510 chips first.

Dr Jefyll wrote:

Ideally it could detect any of several illegal instructions. Failing that, the TTL CPU's microcode could be adapted for the job.

Well, we still have that K24 PCB for extending the address bus to 24 Bit.

But with a different microcode and a little bit of creative tinkering, maybe those 8 additional address lines could be turned into signal outputs for debugging instead...

Problem is, that the microcode PROMs are only one time programmable, and extracting them out of the PCB too often won't be fun because their PLCC sockets
certainly are not designed for this.

[GaBuZoMeu]

I did not dive into the schematics - sorry if this "idea" might not be applicable:
There is a seldom used input "/SO" (set overflow flag when driven low). Perhaps this signal is not in use in the C64. Perhaps this line can be changed to act as an output flagging unofficial opcodes?

Just a silly thought.

[ttlworks]

Don't know, if using /SO for this will work...

But this brings me to another idea:
The NMOS 6502 instruction set doesn't contain WAI and STP,
so maybe with a little bit of tinkering the internal signal for stopping the TTL CPU could be turned into a debugging output instead.

Edit: Dang.
I'm starting to remember that because WAI and STP don't modify registers,
generating this signal was implemented as "as special case of register access" in the microcode.
So using this signal for debugging and keeping the CPU cycle exact probably won't work out well.

GaBuZoMeu wrote:

Just a silly thought.

Nah, at the moment there are no 'silly thoughts': We just collect some odd ideas and sort them out later.

[Chromatix]

The NMOS RDY behaviour, only stopping on reads, is certainly relied upon by some extremely tightly-written C64 code which requires cycle-accurate timing. The RDY signal is manipulated by the VIC-II during "bad lines" of the video scanout, and some software is known to rely on the write-RDY interaction to fine-tune their synchronisation with the VIC-II. This is necessary for certain effects involving changing the VIC registers mid-scanline.

[ttlworks]

Thanks for the info, that's helpful !
So tinkering with the RDY circuitry in the TTL CPU for making it more NMOS 6502 compatible should be tried first.

From the list of games tested with FPGA64, IK+ had worked.
On the TTL CPU, IK+ had failed.
So if tinkering with RDY won't bring results, another idea would be digging into the VHDL code of FPGA64...