100MHz TTL 6502: Here we go!

[BigEd]

A test suite for '816 - even a subset of '816 - would be valuable for other situations, such as emulators and re-implementations!

[Drass]

Yes, that's true. I'd be happy to share the code of course.

I wonder if someone with access to a working 65816 might be interested in collaborating a bit on this. I could use some help coming up with a list of tests to exercise boundary conditions, as well as in validating that the code runs correctly on a real 65816 (ideally one with multiple banks of memory). Please let me know if you (or anyone you know) is interested!

[BigEd]

Technically, I have an 816 (in the form of a beeb816 - see thread and presentation) and can help by running short test programs. I have a big problem with procrastination though, so you might need to keep poking me - but it would be good to part of your success, in however small a way.

Be sure to have a good look through Bruce's big document on the 816 - he mentions many oddities and edge cases. Or corner cases. Or boundary conditions...
http://6502.org/tutorials/65c816opcodes.html

[Drass]

BigEd wrote:

Technically, I have an 816 (in the form of a beeb816 - see thread and presentation)

Beeb816 Revival: AND THIS TIME ... IT WORKS.

The beeb816 looks like a fantastic project Ed, congratulations. It looks like there were some early synch issues that you managed to resolve. Very comforting. I'm likely headed for the same sort of quicksand so I might have some questions.

I also noted the PITubeDirect by Hoglet which also looks amazing. Sobering to read that it emulates a 274MHz 6502!

Quote:

and can help by running short test programs.

Fantastic, thank you. I'll PM you.

Quote:

Be sure to have a good look through Bruce's big document on the 816

Yes, I'm using Bruce's document as a reference. I'll definitely review with boundary conditions in mind. Thanks for mentioning it.

[ttlworks]

2014/40/EU.
It appears that by brain isn't working well at all without "the fuel",
and it's difficult to build something "at the complexity of a mechanical wrist watch" when it feels that a shovel is banging at your forehead once within every 5 seconds.

The situation is, that it took me two years to migrate from cigars to tobacco_less nicotine pouches, and it wasn't fun at all.
Now, a bunch of marauding lung/cancer doctors has forced me to go back into cigars again.
Makes perfect sense, because it's good for their business.

Next, WHO probably would be out to ban alcohol, fat, salt, and then make us all vegetarians.

Would be nice if the amount of universities offering "a degree in Public Health" would die back to a non_threatening level.
Thank you.

;---

So I had to choose between:
0) Living a bit longer without any life quality as a "human vegetable", just staring at the wall, staying away from technical topics after leaving this community for good.
1) "Lighting the candle again" for being able to support this project, staying in this community, and to battle things out.

I voted for 1)
Thanks to everybody who tries (and who had tried) to help me a bit with this: Спаси́бо тебе́ за по́мощь.

[ttlworks]

Igopogo is a creature said to dwell in Lake Simcoe, Ontario... not far away from Drass and Jeff.

When a member of the C74 team didn't surface for a while (maybe due to real life issues), it became sort of a "running gag" to send weekly Igopogo greetings...
we later called them 'Igograms'.

It just had happened, that I had stumbled over an Igopogo picture (by Trendorman) on DeviantArt.

So when Igo had smiled at me, saying "please draw me as an Eagle library device to be inserted into a PCB layout", I just could not resist.
Now we have an official project mascot:

It also just had happened that I stumbled over Nordic Folk Music - Viking Storm at youtube...
and I would dare to say that the first 0:00 .. 3:32 of this royalty free music would make a nice theme that perfectly fits Igo.

Eagle 6.4 library:

igo.zip

(9.68 KiB) Downloaded 87 times

[ttlworks]

Just as a "sanity check", I felt a need for drawing a block diagram showing the data paths of Drass's LogiSim model:

Due to the complexity (Igo isn't a small beast), it may contain some errors.

[ttlworks]

Arrangement of the bus systems becomes a bit more clear when "zooming out" by one level:

Edit: registers are supposed to feed the ALU inputs, fixed this error.

[BigEd]

That's a very nice diagram!

[ttlworks]

Thanks for the kind words.

I wasn't involved in creating the LogiSim model of the CPU,
and since Drass currently seems to be busy with the verification,
I felt a need to draw some block diagrams for better understanding what's in his big LogiSim schematic.

When making the documentation for the CPU later, we would be going to need block diagrams anyway.

My Eagle 6.4 block diagrams, just in case somebody needs them:

c74_100_blockdiagrams.zip

(26.71 KiB) Downloaded 92 times

Edit: fixed an error.

[Drass]

The block diagrams are terrific and complement the Logisim model nicely. Thank you ttlworks!

On other news, I’m happy to report that the model just completed its first full test. The test exercises the microcode for all opcodes using E = 0, X = 0, M = 0, D = $5001, S = $6fff, and tries to check edge cases along the way. It’s far from comprehensive, but does a pretty good job of covering the circuits in the model. (I’ll publish the code once we’ve had a chance to validate that it also runs on a real 65816!).

The next step is to work through various combinations of register widths and Direct Page locations and make sure nothing breaks. Once that’s done, a detailed review of the critical path is very much in order. I’ve had to add additional decoding logic to fix some bugs here and there, and I’m now concerned that the critical patch exceeds the required limits.

So still a long road ... but slow and steady wins the race.

Cheers for now,
Drass

[Drass]

I’m happy to report that hoglet and BigEd were able to confirm the validity of the 65816 test code.

After a few intercontinental bug-fixes of both the test code and the Logisim model, the 65816Test ran successfully on the Beeb816 (a 65816 BBC Micro accelerator by BigEd and revaldinho), on the PiTubeDirect 65816 (a 65816 emulation on a Raspberry PI/BBC Micro by hoglet) and on the Logisim model. hoglet used his clever 65816 decoder to validate the test results and reported the successful runs. Honestly, I had to give my head a shake ... this means we now have a reasonably accurate model of a pipelined 65816. Hooray! (always nice to mark a milestone along the way).

The 65816Test runs through all 65816 opcodes testing various conditions as it goes. The tests are geared to exercise 65816 specific functionality in a fairly extreme configuration: Native Mode, with X=0 and M=0, Direct Page and Stack higher in bank 0, the DL register set to a non-zero value and DBR set to $F8. Indexing across page and bank boundaries is tested, as well long jumps and branches, 16-bit ALU operations and Native Mode BRK and COP interrupts.

This does not claim to be a comprehensive test (it assumes basic 6502 functionality is tested elsewhere, for example) but hoglet mentioned it nevertheless helped him uncover a couple of bugs in his ‘816 emulator. That’s good news, and suggests that the test may be of value to others as well. Kowalski Assembler source code for the test is attached below. (I will likely be making subsequent versions to test DL=0, X=1, M=1 variants and will post those as well).

Three cheers for hoglet and BigEd! Thank you for the help gents.

Cheers for now,
Drass

[BigEd]

Excellent progress all round! I'm hoping this will be as important a development in the land of '816 as Klaus' testsuite has been in the land of '02. Emulators, models, reimplementations and decoders all get a benefit from a thorough workout.

[ttlworks]

Three cheers for hoglet and BigEd !

In retrospective, I wish I would have simulated/verified my CPUs before I had started with building the hardware.
This would have saved me a lot of trouble.

To be honest: to me, the sheer complexity of the C74_100 (considering all these edge cases) looks a bit scary.
I think it's better to invest "a reasonable amount of time" into simulating/verifying the concept first,
before even starting to think about the "hardware implementation" related topics...

...and of course, a good 65816 testsuite sure would be helpful for 65816 FPGA\emulation projects.
Keep up the good work, gents.

[Drass]

I couldn't imagine doing this without a model and a test suite. Many bugs were uncovered by exercising the model manually first, and then with the test suite.

I'm working on the DL = 0 microcode this morning. I thought it might be tricky to detect DL=0 and change microcode on the fly, but not so. I only need save the Z flag whenever the DL register is updated. A dedicated DLZ flag can then be used when reading microcode, just like the E flag is now. This CPU also adds a cycle if DH !=0 so a similar DHZ flag will also be necessary. It *should* all work smoothly.

I'll update the test suite once the microcode is done and we'll see how well this works.