Bringing up a 65org16 core

[enso]

I am trying to get a minimal 65org16 system together. So far no luck, any help is much welcome.

My premises (please correct me if I am wrong)
-start vector is at $FFFFFFFC,$FFFFFFFD;
-stack RAM is necessary, stack pointer initialized to $0001FFFF;

So I rigged up a very simple circuit around the core with the goal to flash an LED.

A single BRAM configured as a 1K x 16 is selected as the top 1K of the memory space, FFFFFC00 - FFFFFFFF. It is pre-configured with the vectors and the test code.

Another BRAM, 1K x 16 is selected as the top 1K in both pages 1 and 0. This provides stack RAM, as well as some 0-page RAM (at the bottom).

An IO port is decoded at $FFFFC000. Writing this port toggles the led (for now).

I'm working on eliminating stupid errors; haven't had any luck yet (for a while the LED was flashing really slowly - every 10 seconds or so, but it's probably nonsense).

[ElEctric_EyE]

Your understanding seems correct... your 1K stackRAM should be decoded for $0001FC00-$0001FFFF.

[BigEd]

Even a single BRAM should be OK, multiply mapped to the entire address space, provided you look out for the usages in zero page, stack, vector space, and any addresses you use for program or data.

I'd strongly recommend a LDX # and TXS at the beginning though.

Because the stack pointer has 16bits, a rogue stack can cause a lot of damage - that's a possible reason for decoding the stack separately, at least at first.

You might want to have a look at my 'system' design which is about the same size and shape as the one you're working on. See https://github.com/BigEd/verilog-6502/t ... system-rtl - gop16.v seems to be the top level, and nearby you'll see the boot code. The build takes place in the build-xilinx dir, where you find the makefile and ucf file. This code has been seen working!

Cheers
Ed

[enso]

I've thought about mapping a single BRAM, but decided against it as it gets a little complicated.

I should check out gop16v - I meant to but forgot...

[enso]

And it's up, flashing an LED. Assembling via the Makefile - I am all set!

I have a 65org16 running on a CHOCHI (and DILDAR for that matter)! I didn't think it would fit, bit it does, with plenty of room to spare. Only internal BRAMs are used, so the maximum is 4K of 16-bit bytes, but it's something!

I will clean it up and post the bitstream. Well, I should get the UART working first I suppose.

[enso]

And yes, the serial port appears to work! Time to reward myself with the 50th aniversary Doctor Who episode. Hope it doesn't suck.

temp.png (3.07 KiB) Viewed 3977 times

When I get back I'll have to dig up that 65org16 Forth thread. I am excited about doing some 16-bit work. I like the minimalism of 8 bits, but it quickly becomes tiring. 16 is really enough for many useful tasks...

[barrym95838]

enso wrote:

... I am excited about doing some 16-bit work. I like the minimalism of 8 bits, but it quickly becomes tiring. 16 is really enough for many useful tasks...

Kickin' @$$ and takin' names!! Go, enso, Go!

Mike

[BigEd]

Great!

[ElEctric_EyE]

enso wrote:

... Time to reward myself with the 50th aniversary Doctor Who episode. Hope it doesn't suck...

How was it?
I can only tolerate Tom Baker.

[Justin]

enso wrote:

And yes, the serial port appears to work! Time to reward myself with the 50th aniversary Doctor Who episode. Hope it doesn't suck.

temp.png

When I get back I'll have to dig up that 65org16 Forth thread. I am excited about doing some 16-bit work. I like the minimalism of 8 bits, but it quickly becomes tiring. 16 is really enough for many useful tasks...

16 bit was "good enough" for the first 14 years of the PC revolution (1981-1995)

[enso]

Tom Baker was in it! It was pretty good.

[enso]

Runs at 100MHz with internal BRAMs. Similar to Arlet's original core; I would expect 40-45MHz performance with external 10ns SRAMs just like current CHOCHI, not too bad.

[ElEctric_EyE]

Yeah I would expect even better speeds when we finally get the 32-bit version hammered down! Since alot of stuff will be trimmed out.

[Arlet]

On the other hand, with 32 bit, a lot of stuff goes in. Even though in most cases(*) the paths don't get longer, wider buses will cause more routing congestion.

(*) 32 bit adders will be slower because of the ripple carry.

[enso]

Arlet beat me to it. In my previous explorations, the carry delay winds up catching up with you. I seem to remember something along 0.4ns per bit carry propagation delay. There are ways around it, but none of them too elegant.

32 bit seems a bit too much. My choice would be to add some 32-bit support and maybe a MAC if the hardware supports it. Anyway, that's what my 'present self' feels - I don't know about my 'future self' after messing around with 16 bits.

As for trimming - I don't know if it will affect FMax much. If we trim enough instructions to make the main state machine down to 32 states - that would probably fold the decoding into 5 bits. But that is unlikely. I haven't tracked down critical paths enough to think of other approaches.

Not to mention that in real life SRAM is slowing us down anyway.