Micro programmed 6502-like CPU

[JuanGg]

After adding a hidden carry, I have now written microcode for each and every instruction, except SED and CLD, as I'm not implementing decimal mode. Also NMI is missing as of now, I'll add that later if I see the need.

I have lightly tested every instruction and ran some sample programs and it seems to work fine.
After painstakingly writing 1000+ lines of code to generate all microcode and implementing and debugging each instruction, writing in assembly is going to be an enjoyable activity I'm sure.

I'll tidy things up a bit and publish the logisim files so anyone can have play around if they wish to.

Juan

[BigEd]

Congratulations!

[JuanGg]

I am now looking for some sort of test program so I can ensure that all opcodes work well. I have found this
https://github.com/Klaus2m5/6502_65C02_functional_tests
but I'm not able to find the as65 assembler that this code is written for (plenty of sites point to this broken site: http://www.kingswood-consulting.co.uk/assemblers/).
I have tried with a65 assembler (without the s) with no luck, it gives me "Fatal Error -- If Stack Overflow".

Any ideas? Or any other test program that I can use? Thanks. Ideally something that doesn't use any input-output beyond memory and with optional decimal mode, as my CPU does not have that. But I suppose I can modify something to suit my needs
Juan

[BigEd]

Yep, see this post:
viewtopic.php?p=70183#p70183

[GARTHWILSON]

JuanGg wrote:

but I'm not able to find the as65 assembler that this code is written for

Is it this one?  http://www.obelisk.me.uk/dev65/as65.html

[handyandy]

Have you tried archive.org? I was able to locate Frank's assemblers with that.

Cheers,
Andy

[JuanGg]

GARTHWILSON wrote:

JuanGg wrote:

but I'm not able to find the as65 assembler that this code is written for

Is it this one? http://www.obelisk.me.uk/dev65/as65.html

I wasn't able to run that one, it appears that it is only compatible with 16-bit systems.

BigEd wrote:

Yep, see this post:
viewtopic.php?p=70183#p70183

Thanks, I finally got it from here http://web.archive.org/web/201903011236 ... ssemblers/

I have taken the test program from here: https://github.com/Klaus2m5/6502_65C02_functional_tests and changed the configuration at the top so it ignores decimal mode and so that code starts at c000, where I have put a 16k ROM.

I assembled it with no errors and ended up with an Intel Hex file. By virtues of Notepad ++, I have stripped all addresses and check sums, and added a space in between each two characters. This ends up with the format Logisim needs.

Said file starts with 9 BRK opcodes, and as the IRQ vector is set to 0000, it continues execution on said address, where it reads another 00 and off it goes on an endless loop that just fills the stack.

Any ideas? it doesn't seem to specify those vectors in the test file. Maybe I should learn 6502 assembly first...
Juan

[JuanGg]

handyandy wrote:

Have you tried archive.org? I was able to locate Frank's assemblers with that.

Cheers,
Andy

Yes, found it there finally. Thanks

[BigEd]

Most likely you haven't built the binary in the way you expected to: there are several options to comment in or out in the code, depending on how the zero page is to be initialised. What you're seeing as BRK are probably the first few bytes of storage, which shouldn't be placed in your ROM.

IIRC Klaus' repo includes binary images which are suitable for running in emulators. Just take care to load them at the right address. There are also listing files for these images so you can see which addresses correspond to which test fails.

BTW, the 'srecord' set of utilities are very useful for dealing with hex format conversions.

[JuanGg]

I wasn't doing it right. Now i have filled the 64k address space with a unique ram, that makes it easier.
Thanks for pointing srecord out, its awesome.

I have successfully loaded the test and began execution. It got stuck after a couple instructions, and I was able to fix the fault.
Now, it is reiterating though code around addresses $400-500. I don't know if something is failing or if it just takes too long. It seems to me that it's doing the same thing time and time again. Register Y starts at $fe and goes down to $66, then to $5, to $0 ,and back again.

In addition, with a maximun clock speed of 4 kHz, the simulation may take a while (10s of hours) to run the full test I'm afraid.
Juan

[JuanGg]

Worked that out. My jump instruction wasn't working properly. Now it's getting stuck at $a88 and I'm finding it a bit difficult to track down. Any ideas?

Code: Select all

                       >
0a74 : 28              >            plp         ;restore status
                        
                            endif
0a75 : d8                       cld
                                tst_stat $ff-decmode
0a76 : 08              >            php         ;save status
0a77 : 68              >            pla         ;use stack to retrieve status
0a78 : 48              >            pha
                       >            cmp_flag $ff-decmode
0a79 : 0908            >            ora #decmode        ;ignore decimal mode b
0a7b : c9ff            >            cmp #($ff-decmode|faod)&m8   ;expected fla
                       >
                       >            trap_ne
0a7d : d0fe            >        bne *           ;failed not equal (non zero)
                       >
0a7f : 28              >            plp         ;restore status
                        
0a80 : f8                       sed
                                tst_stat $ff
0a81 : 08              >            php         ;save status
0a82 : 68              >            pla         ;use stack to retrieve status
0a83 : 48              >            pha
                       >            cmp_flag $ff
0a84 : 0908            >            ora #decmode        ;ignore decimal mode b
0a86 : c9ff            >            cmp #($ff|faod)&m8   ;expected flags + alw
                       >
                       >            trap_ne
0a88 : d0fe            >        bne *           ;failed not equal (non zero)
                       >
0a8a : 28              >            plp         ;restore status
                        

Juan

[BigEd]

Looks like your CPU hasn't saved (or hasn't restored) (or doesn't implement) the decimal flag in the processor status register.

[JuanGg]

I have disabled decimal flag and mode altogether, but I'm not sure what implications does that have.

Code: Select all

;disable test decimal mode ADC & SBC, 0=enable, 1=disable,
;2=disable including decimal flag in processor status
disable_decimal = 2

Last place it was stuck on, it was because it was expecting unused bits of the status register to be 1, and I had them always set to 0. So I arranged it so unused bits would always be read as one, and D flag always as 0. I have now enabled D flag to be read as its current value and it makes no difference.
Juan

[BigEd]

Hmm, odd, looking more carefully, I might guess that the test is indeed ignoring D and is checking all other bits (all 7 of them) are 1. Have you certainly set all 7 other bits to 1? That's including B and 'unused'.

[JuanGg]

BigEd wrote:

Hmm, odd, looking more carefully, I might guess that the test is indeed ignoring D and is checking all other bits (all 7 of them) are 1. Have you certainly set all 7 other bits to 1? That's including B and 'unused'.

I have indeed, but this is not why it was failing in the end. After chasing red herrings for a while, it helps looking at it a few days later. The problem was due to a flip-flop that buffers the carry flag into the ALU, and me having forgotten to enable hidden carry on the preceding clock cycle... It was not jumping to the correct location and that caused issues. Also found out that my clv instruction cleared I instead of V.
It's coming along, and the logging functionality of logisim helps a great deal. But at effective clock speeds of hundreds of hertz, it takes a while...
Juan