Sorry for asking again.

The 65org16 emulation core is almost finished. I only had to take the old 65c02 core from my AppleII emulator and extend it a bit. Now I plan to make the 65org16 an optional processor for the AppleII with the ability (unlike the real thing) to start emulation in compatibility mode and then switch to the 65org16. Anyway, while doing that I came across two more questions:
1) What happens if the 65org16 hits an illegal undefined opcode? Since the FPGA core is based on a 6502 core I guess it might partly execute the illegal opcodes of the 6502 (except for the new 65c02 opcodes). Would it be possible to execute a special IRQ dedicated to "illegal instruction" instead?
2) How about accessing the memory when the 6502 performs its ALU operations? The original 6502 has the habit of always accessing the memory. For example, when executing the instruction 'DEC zp', the 6502 will perform the following cycles:
- read the zero page address
- read the value from the zero page
- decrement the value but also write the old value back to memory!
- write the new decremented value to memory
Though the 65c02 replaces the additional write with an additional read (*), the 65org16 nevertheless does not really need these superfluous memory accesses at all. So I wonder, since the 65org16 is based on the 6502, whether you leave them in (on purpose) or just drop them. Currently my little 65org16 emulator still emulates them (as it is also derived from the 65c02), but I thought, maybe this could reduce the code in the FPGA a bit, but I may be wrong here.
My apologies, if this has been asked before. I've already read quite a lot, but you have done so much developing and discussing throughout the years that it is quite hard to follow.
Cheers

Miles

* As a side note, IIRC some programmers used the two writes on the C64 to clear the IRQ signal in $d019.

The FPGA core is only loosely based on an NMOS 6502. The undefined instructions are undefined. They'll do random stuff, and most likely not in the same way as the 6502. The behavior may even change when you rebuild the FPGA. This was done on purpose to save resources. Trapping the illegal instructions is certainly possible, but would make design bigger, and possibly slower.


The FPGA does a similar thing. Memory is always accessed (the 6502 does not have a Output Enable signal), so during the dummy cycles, it will read arbitrary addresses. The addresses may not be the same as the 6502. It always does a read access, though, not a write. The reason for these dummy cycles is that the design is based on a single ALU that does all address and operand calculations, and the ALU always takes 1 cycle. So, in case of a DEC operation, it takes 1 cycle to read the memory, 1 cycle to do the DEC, and 1 cycle to write the result back. While doing the DEC, it is not possible to avoid a memory access. It could be fixed by removing a cycle to produce: 1 cycle to read the memory, 1 cycle to write the modified value back. This would slow down the maximum clock speed, though.

Thanks for your answer!

I thought that dropping both could mean an increase in speed but as you've explained actually it would slow down the core. Oh dear, I've got to learn a lot.
Come to think of it: since I don't know anything about hardware design (unfortunately) and I'm also an absolute newbie when it comes to FPGA programming, may I ask if there is some kind of simulation tool that would simulate the 65org16 FPGA core on my laptop (Windows7 64bit, sorry)?

Cheers

Miles

Yes, the Xilinx ISE tools will do that, but there's a steep learning curve, especially if you're not already familiar with hardware design. You can download them for free from the Xilinx site.

Agreed, there is a learning curve. But have a go! I tend to do most things at the command line:

I just checked my 65Org16 project on github... I have provided a Makefile for the synthesis of a system-on-chip, and a shell script for the simulation of it. In both cases they are very simple, so if for any reason you didn't want to install Cygwin to run them, you could probably just study them and paste similar commands into a CMD shell prompt. Look for the build-xilinx and simulation-isim subdirectories of the project. If you don't want to use git, the download buttons allow you to download a zip file.

You should pretty soon get traces like these

Cheers
Ed

By the way Miles, if you want to compare your emulation against another, have a look at py65.

Okay, here's the current development state:
The new 65org16 emulator written in x86 assembly is up and running. I mapped the Apple//e memory (including rom and IO) via an 8 bit bus (top 8 bits = 0) to $e000 0000. The 65org16 rom is currently located at $ffff 0000 (64KB). Why integrate it in an Apple//e emulator? Because this way I've got an already working and also familiar hardware emulation (keyboard, display..) for testing. The speed of the 65org16 can be set within a few steps (double) from 0.125 to 32 Mhz. I stopped at 32 Mhz because the emulation attempts to be clock cycle exact, which also applies to the video output. Without the display and using just an instruction exact emulation the speed could certainly rise above 100 Mhz. Little test programs (write string to text screen, fill the hires screen with a bit pattern) work fine so far. Right now I continue converting my basic OO kernel to the 65org16 but apart from a few missing methods it's almost done. So here's the big question:
- What kind of software do you need?
- And how much of the software do you want to store in rom? (Is there a maximum rom size?) I ask because this also affects the programming style: self-modifying code allowed? yes or no.
Please let me know your wishes and ideas, so maybe I can come up with something.

I think I'll register at Xilinx and download them within the next few days.
Unfortunately, for me the biggest hurdle to overcome is to become aquainted with the tools. Setting up the tool chain is the most tedious task I can think of, especially because I'm a noob who has hardly ever used an IDE apart from his text editor and some home-grown assemblers and compilers.

Yep, even a failure can be a fruitful experience.
Thanks! Got it.
That's a good idea, indeed, but I don't have Python installed on my laptop. Is there a Python implementation you can recommend (still using boring Windows7 64bit)?

Cheers

Miles

I don't think there's much to choose, for this purpose, between any of
- original python http://www.python.org/getit/
- activestate python http://www.activestate.com/activepython/downloads
- the python that comes with cygwin http://www.cygwin.com/install.html

Although cygwin is more than just python, I would recommend it because it gives you a posix command line which is rather like unix or linux. The best way to use it is to install as many packages as you might ever need quite early on, because after 6 or 12 months it isn't so clever at managing the version skew between packages (it does try)

All of the three choices are non-disruptive to your windows setup.

Probably activestate will be easiest, if py65 is the only thing you're trying to get going.

Cheers
Ed

Great to hear that your emulator is running! When can we see it?

For software... I think we're still at the point where good tools for tracing and single stepping would be useful. (We do have Bruce's Compact Monitor, so I mean something a bit more roomy) Also a robust program loader would be useful - development over a serial channel is normal, rather than something with mass storage. Actually, adding a loader to the Compact Monitor would be incremental progress - it should take the format which TT's HXA assembler produces.

Porting EhBASIC, or pursuing that C compiler (or another C compiler) would be good.

Bruce did port TinyBASIC, and I had some success running it on FPGA, but the RND function misbehaved. You might see how you get on with that.

Cheers
Ed

Since you've already mentioned cygwin in combination with your Makefile, I might indeed be better off using that.
Well, if you are seriously interested, it just depends on what you mean by 'see.' I don't have a youtube account, so, I'm afraid, I can't show you the running emulator. I could show you the snapshot of the video output but that's not very meaningful . If you like to have the source code, I could send it you. No problem. If you want the full executable .. I must warn you. It's a hideous beast, very uncomfortable to use, a total mess overall, and it does only run on Windows (not sure about Wine). Anyway, that's your decision.
Tried downloading the latest version 2.22 but keep getting 404. Regarding the C compiler I must admit that it's too much for me to begin with. Before doing that I better write a 65org16 version of my virtual stack machine so I can port some of my tools (those that can be compiled to bytecode).
I assume the format basically just follows the Intel HEX standard:
';' <8 bit byte count> <low word of address> <record 00> <list of 8 bit byte data> <8 bit checksum>
I've put together a little debugger that can read data in this format (BTW: how do you display the information from the debugger?). However, I don't have a (real) serial port to toy with, so I had to use a dummy object instead. You would have to replace that for your system. .. <keep thinking> .. <scratch head> .. Well, indeed, how are you going to use the software?

Cheers

Miles

Hi Miles
The download link for EhBASIC here is working for me. Also, Chris has a modified copy of the source in his stm6502 project on github. You can get it from the Raw button here

For your emulator, if it's Windows-only then I'd be interested in trying to spin up the executable in WINE, but I wouldn't try to build it. It might be interesting to see the source though.

On the subject of the C compiler... I think generally we're trying to bring up a new machine, and the two merits it has are being rather like a 6502 and being bigger and faster than a 6502. So, for some purposes programming in assembly is most appropriate - after all, if one were to program exclusively in a high level language then it need not be 6502-like. But for other purposes it would be nice to have something higher level. It turns out (from the DCPU-16 experience) that converting compilers to work with 16-bit bytes can be quite a bit of work. Compiler writers do expect 8-bit bytes and byte-addressable memory. So that compiler that Jeff found is particularly promising, because it's meant for a machine just like ours. It might be that the DCPU-16 tools are also an interesting starting point now.

On the subject of the hex loading format, yes it's like Intel format, but everything is 16-bit bytes. A good starting point might be to download TeamTempest's HXA assembler and assemble Bruce's program for today. Or just load the code I put there.

All my platforms use character input and output, over actual or virtual serial lines. So that's how I debug. I didn't quite get to the point where I could use Bruce's Compact Monitor for single-stepping on the FPGA, but I did have it working on py65.

I suppose if needed I could prefix each output byte with a stream ID so I could distinguish ordinary output from debugging output. Or I could have several i/o devices multiplexing over i2c and then USB, in the FPGA case. In other words, something which looks from the CPU side like dual uarts. That's somewhat like what BitWise is doing.

Cheers
Ed

Here's another pointer on the hex format:
viewtopic.php?p=15690#p15690

Here's something which arose in off-board conversation, but which might be of more general interest.

A reasonable app needs a reasonable amount of RAM to run in, and a major point for the 65Org16 existing is the 4Gword address space. However, my github project's demonstration system-on-chip only supplies a measly 4kwords because it's a design using only on-chip memory and that's all I needed for trivial test programs. Here's the state of play:

I have a few relatively inexpensive FPGA dev boards. The OHO boards with Spartan3 chips offer on-chip memory of 12k words or 20k words max. One of those boards has an 8-bit-wide on-board SRAM which would fit 256k words. The on-chip memory I can make use of right away, but I'd need to write up an interface for the off-chip and haven't done that. These are the boards I've been using for bringup.

I also have an Avnet board with a Spartan6 LX9, which has 32k words on-chip capacity and 32M words of 16-bit wide on-board RAM. That's LPDDR SDRAM, don't know how tricky it will be to hook up. I haven't touched this board yet.

EEye's dev board design has 16Mword SDRAM. This board also uses an LX9, but it's not a BGA part which makes it good to solder but means it has less onboard help for memory interfacing. Nontheless, Arlet has written an interface. Both Arlet and EEye have these boards and the SDRAM interface is working.

So, that's three routes to reasonable amounts of RAM.

Cheers
Ed

(Edit: corrected memory space, thanks DrJ)

Yes, the devboard has a 16Mx16 SDRAM. It's a $5 part. Micron does have a 32Mx16 part available now for a "reasonable" price of $20. It was more than twice that 1/2yr ago... I would suspect just a few changes need to be made to Arlet's code to accomodate another address line and the new timings.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Hi EEye, just to check: has the SDRAM now been thoroughly exercised? Can the CPU access it, and run code from it?
Cheers
Ed