Hmm, thanks for the pointer to that thread. It does seem to show that you can't please all the people all the time. On the positive side, it shows that there's no shortage of assemblers, or people able to write one.

I won't fret about the odd missing feature - this is a new CPU we're talking about, and having an assembler beats not having one by a wide margin, so that's the first step. (I have a lot of first steps lined up.) It can't be difficult to add shift operators to a python assembler, so that can go on a list. Nor can it be difficult to substitute a macro when encountering an unknown opcode.

I'd be interested to see an example of what you mean by nested macros and how they'd be useful. (Maybe in that other thread??)

Cheers
Ed

I made some quick changes to Dave Beazley's assembler: here's the first working output. It's Bruce's minimal bootstrap loader:



It's kind of obvious, but I think it's still helpful to see these 16-bit bytes in black and white.

As a soft goal, I'm trying to arrange that the same source (software and hardware) can build for both 6502 and 65Org16. I'll give up if that's too hard - it can be revisited.



There's a (specification) bug here: instead of loading just shy of 256 bytes as a bootstrap, it now loads just shy of 64k bytes. So we will need a slightly longer bootstrap. Or a change to the initial value of X. But also, I haven't taken any note that I'm loading from an 8-bit peripheral. So, the assembler is functional, but the bootstrap certainly needs work.

Cheers
Ed

Instead of bootstrapping with an external serial EEPROM adding another device, wouldn't you want to boot up from the FPGA PROM?
It could contain at least the bootstrap code and could run everything internal, at least in the beginning stages. That way, you'd just start off with the FPGA and PROM with JTAG programmability. The assembler would need to compile a binary file though, and then you would use Arlet's bin2coe converter for ISE to make the ROM.

My plan is to boot from a block RAM which is preloaded with some bootloader image, which will have been assembled by a patched assembler.

I'm not thinking of serial EEPROM, or the FPGA boot PROM. The point of the i2c slave module is that I already own a USB to i2c interface, so for me this is the simplest way to make a bidirectional serial channel to a host computer. With that, I'll be able to load code, talk to a monitor, talk to a basic interpreter or other application, and so on.

In fact, as it's easy to preload any image into the block RAM, I could load a monitor there and dispense with the bootloader. (But I don't yet have a monitor)

(It's possible to patch an FPGA bitstream with new RAM contents without re-synthesising, if you need quick turnaround and if synthesis takes more time than is convenient. See the Data2BRAM tool, and app. note Xapp463)

Hi EEye
oops, I realise I'm closer to agreeing with your post than I thought I was. If I put my code into initialised block RAM, by means of having it encoded in the bitstream, then indeed I will end up storing it in the FPGA program PROM.

as you say, I need to convert the assembled output to a suitable format for the ISE tools: maybe bin2coe will help, as you suggest.

Cheers
Ed

see also here for mention of bin2coe and other techniques

Hi Garth, having clarified that you meant that you want to be able to use macros within (other) macro definitions - which is reasonable - I checked, and indeed Ophis does support that.

Cheers
Ed

I would like to learn how to do this. I read the App. But I don't see Data2BRAM anywhere on ISE or iMPACT.

Looks like Data2BRAM is now part of Data2mem - see this forum thread

I'm delighted to announce that 65Org16 today ran a first test program on FPGA.

Here's the program (*):

I need to tidy up the verilog and put it on github. I suspect I need also to add RAM - with only ROM there's not much point writing a program loader.

Presently I have an i2c peripheral for I/O and a bank of 8 LEDs too. There's no flow control on the i2c so I'm not sure yet how much work there is in making it into a usable interface to the host. Also, the i2c verilog I'm using isn't freely redistributable.

Got a picture - not much to see, just 4 wires connecting the OHO module to the i2c to USB adaptor, two for data and two for power.



Cheers
Ed

(*) There was an earlier test program which just wrote the data straight to the LEDs, but I wasn't convinced it was doing anything - was it just my previous bitstream without the CPU which just connected the i2c to the LEDs? So I added an ADC. But that blew the carry, so I changed to EOR. Then I finally realised I hadn't adjusted the branch offset. This hand-adjustment of ROM contents isn't ideal.

Edit: fixup missing photo link

And we're delighted to hear it! Reminds me of the old days with my KIM-1

Congratulations, Ed! I think some of us out here are suffering a slight case of project envy!
All the best,

Jeff

Cheers! I have to say it took two solid days of procrastination from downloading the i2c module to writing some verilog to put it on the FPGA. But doing that did break my mental block.

Also, I must point out that 65Org16 is conceived as being a least-effort solution to the problem of a 32-bit address space. The core is essentially a patch to Arlet's, and I haven't done much work. Should I be ashamed to say that I was beginning to doubt the correctness of his core when I finally realised that I hadn't patched the new branch offset?!

Cheers
Ed

BigEd, congratulations on your first successful test! I have a few questions if you don't mind.



What do you mean: 'downloading the i2c module to writing some Verilog'?
Which I2C module are you using?

Also, just to refresh, you mentioned before your mod of Arlet's core has a 65K zero page?

It took me two days to get started - sometimes it takes me a while to get started on things. So, I'd downloaded the verilog i2c code from fpga4fun, but I needed to write some more verilog to hook it up to the FPGA pins even to test it. And beyond that of course to hook it up as a peripheral to the CPU core. (Note that I'm doing all the design in verilog, not in schematics or in the GUI.)

Because the i2c verilog from fpga4fun isn't redistributable, I won't be able to include it in my project. I might leave a hole, or I might find a replacement.

That's right - a byte is 16 bits, so a one-byte address gives you a 64k zero page.

Cheers
Ed

Ah, I've seen his core. It's a I2C slave only core.

Very interesting so far! Good luck...

BTW, what are we to call your take on Arlet's core? Just for shortness sake when referencing...

I'm calling it 65Org16.

I suggest any architectural enhancements (extra instructions, etc) should use suffices to avoid confusion. 65Org16 just has the basic NMOS opcodes, with the exception of BCD which is undefined.

Cheers
Ed