_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Don't get too overexcited yet!

I'm still running an existing 8-bit core at 1MHz for now, just to verify hardware functionality. Next week I have to iron out the remaining timing issues (it boots, but not quite right - the typical PET chirp when it starts is distorted, screen is not fully initialized, ...) only then can I hope to start testing my own core. It's a step-by-step approach, verification in each step, climbing the ladder.... I think it's realistic to have a _tested_ 65k core in December.

I'm using the GODIL part, a Xilinx Spartan 3E with 500k gates on a development board I made for it.
See here http://www.trenz-electronic.de/products ... ronik.html for the GODIL, and
see this picture for the dev board:
http://www.flickr.com/photos/afachat/79 ... hotostream
The board has 1M of RAM in 16x512k organization, with the upper 8 data bits shared with an Aux port, where I plan a) a PET video output (just video, hsync, vsync) and b) an SPI interface, for ethernet, SD-card, USB device and USB host. I had to do some pin multiplexing because the GODIL only has 50 usable I/O pins...

I'm currently running it with a 40pin flat ribbon cable to the CPU socket of my CS/A computer running Commodore PET ROMs, at 1MHz only. As goes the saying with 1MHz and the proverbial murder.... Still there might be timing issues. The board directly has a CS/A bus connector, so I may opt for using this in further testing, but one goal is to replace a PET CPU with this cable, put it into the PET case, connect the video to it, and have fun showing people a very special Commodore PET

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I have the GODIL board with the FPGA sitting in my adapter board for my selfbuilt computer, and it boots now fine into the PET ROM, but with _the_T65_core_only so far. My own core doesn't work yet. Investigation into that will have to wait for october unfortunately.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

It's been a long time since I wrote the last update. Didn't have time to work on the issues yet.

I only found that my current approach probably was too complicated and too much to begin with. I'm thinking of redoing the 65k core in a more simplistic design. This redo is second on my TODO list, after a major web design update of my web page...

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I know the situation very well. Client projects are quite demanding right now.

As I've already managed to run the t65 core successfully on my hardware, also in push-button-controlled single-step mode, I should be able to step-by-step build up an own new, simple core.
I'm even thinking about using the t65 as "control" core to monitor and control the new core while developing the new core (like memory mapping the register file into the t65 memory, controling the new core's clock from the t65....)
But trying not to think too far. First my web site update, then the 65k core....

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I think since the 6502 was a clone of the Motorola 6800 series, just use 68K opt code for 16-bit and 32-bit modes. Make a 6502 type chip with the same pinouts and find an 8 bit 6502 system and swap out the CPU and modify the BIOS to work with the new 16-bit and 32-bit modes.

Either that or just take PowerPC 32-bit and 64-bit modes and add them, with the 65816 as the 16 -bit mode.

Look into the MAME project, it has MESS merged with it and see what the 65XX and 65816 and 68K Chips do, and see if you can make a 65K chip via emulation first before making it with hardware.

_________________
Orion Blastar
http://blastar.in/wordpress/
http://www.twitter.com/orionblastar
http://blastar.org/
[url]mailto:orionblastar@gmail.com[/url]

Are you thinking of doing 1-cycle instructions, pipelining or just standard 6502-like execution for the new core? Will the memory bus be the same speed as the core?

It ought to go into modes for 6502 mode, 65816 mode, and 680X0 mode. Of which it would be compatible with systems that would use those sort of chips. Much like the 80X86 has 16-bit and 32-bit modes, etc.

_________________
Orion Blastar
http://blastar.in/wordpress/
http://www.twitter.com/orionblastar
http://blastar.org/
[url]mailto:orionblastar@gmail.com[/url]

Ok, I understood that from the previous post. I was more interested in how the basic approach would be.

If you are going for multiple memory operation in each cpu cycle, then you can do most 65xx(x) instruction in one cycle. STA for example does´t require 3 or 5 cycles if you don´t have to wait for the memory. Pipelining and doing several 65xx(x) instructions in one cycle is more complicated, but can be done (and will bloat the core quite a lot). Branch prediction is usually the more problematic in such instances.

As the 65xx(x) instructions are mostly defined by a part of the opcode, while addressing remains another part of the same opcode byte, the problem breaks down quite nicely. This is not true for all instructions, but for many. For example LDA starts with "101" for the MSB´s and STA with "100". The addressing mode depends on the next bits, which means that the implementation can be made quite compact (I use case statements for this in my own small core).

I am not sure if the 68000 cpu break down the instructions in quite the same manner. It is also incompatible with the 65xxx, so you are probably better off by just having separate cores. That is unless you can pre-translate the 68000 instructions into something that is more 65xxx-like. Maybe by doing something like the x86 by using an extension of the opcode set (although not beautiful, it solves a problem). It may make the core large, but it would enable you to reuse most of the 65xxx core and at more or less the same speed.

E.g.:

68000 code --> Pretranslator --> 65xxx extended code --> 65xxx+ core

You may even extend this to the 65xxx instructions and make a full RISC-like implementation out of it:

68000 code --> Pretranslator --> RISC code --> RISC core
65816 code --> Pretranslator --> RISC code --> RISC core
6502 code --> Pretranslator --> RISC code --> RISC core

Which might give you the fastest core, but is probably also a lot of work.

Edit: Actually, the last implementation of these two (above) is probably easier to get working. The reason is that the 65xx(x) series can do code self modification, while this is not strictly something you do on the 68xxx due to the implementation of MMU (at least on most systems). A core with some MMU logic would also fit nicely with the 6502 if you put the page size at 64KB.