To my embarrassment, I'd forgotten about these cores. Seems like a good development though. I'll watch with interest. (LGPL too - excellent!)

It's very exciting to suppose the '816 would have a 32-bit sibling!! I wish you well with this venture, Rob, and I'm a little surprised you haven't received more acknowledgment for this project and its predecessor, the FT816.

Does the data bus remain 8-bit with this latest version? I can see pros & cons, but clearly there's a potential bottleneck when dealing with 32-bit values. And, unlike a 68008 (another chip that's 32-bit internal, 8-bit external), your core requires extensive interaction with its "registers" in zero-page. (OTOH it's fair to observe that the FT832 can handle 32-bit data far more efficiently than an '816 or '02 attempting the same job.)

Something that worries me is the challenge of in-depth testing. At present there's no '816 equivalent to Klaus's test suite, and that's a problem -- it'll hold things back for FT816, FT832 and any other projects attempting to equal and exceed the capabilities of the '816. This includes emulators like Scot's.

Although I myself can't volunteer, I wonder if there are person(s) among us who would be willing to begin working on this. Even partial coverage of the 816's operations would be a welcome improvement, as compared to piecemeal manual testing or hoping bugs will be revealed by running a preexisting application.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yes, the databus is still eight bits. The bus structure mirrors the bus of a real '816. My thought was that it might be possible then to use it more directly as a substitute for an existing processor. It will be a bit sluggish to move 32 bit values across an eight bit databus but it's still faster than if one had to do the 32 bit ops using 16 bit or 8 bit op instructions. For an FPGA implementation limiting the design to an eight bit bus may not work out all that badly because memory (DDRAM) is much faster than the FPGA processor. It should be possible to burst read with a burst length of eight say, (64 bits) into the processor faster than it could be handled anyway. (But that's if one throws a DDRAM controller into the picture).


I would agree with you there. It's the capacity to get something that works well enough to be acceptable that bothers me. It has to be close to perfected or nobody will buy it. I have an '816 processor test program I've developed along the way that IIRC test all the address modes and instructions. But it's not really a comprehensive test suite. The FT816 is based on the '816 emulation in the RTF65003 which I had working fairly well. But for some reason Supermon816 hangs whereas it works fine in the RTF65003, which hints that there is a bug somewhere yet to be discovered.

A preponderance of working software is a good indication that the processor is okay. I believe the big companies test by running thousands of pieces of software on a processor before they release it.

_________________
http://www.finitron.ca

I did a preliminary coding of most of a 32 bit core in the past two days to get an idea of how a 32 bit mode would work. Some of the issues are listed below. What I'm wondering is if to keep all the existing instructions the way they are and define new ones using a second opcode page, or to modify the meanings of the existing opcodes to suit a 32 bit mode.

Adaptations for 32 bit mode:
Stack - stack is always 32 bit aligned. (future performance issues).
Therefore "d,sp" and "(d,sp),y" mode displacements are shifted left twice before usage by the processor (Otherwise the two LSB's would be a useless 00 all the time).

Bank Registers
- the program bank register and data bank registers would be converted to be effectively segment registers (code and data).

Program Counter
- the program counter would be 24 bits. This is to avoid wasting too much code space on high order bytes that are always zero in a JMP or JSR instruction.
- The JMP and JSRS instruction would have to work with 24 bit addresses instead of 16 bit ones.

Segmented Jumps / Calls.
- Without defining another page full of instructions, the JML and JSL instructions would need to be redefined to allow a segment specification as well as an offset value.

Leaving 32 bit mode
- a long jump instruction to a specific code segment is used. Because 32 bit mode uses a code segment, this segment has to be switched to zero to get back to 8/16 bit emulation.

Long addresses
- long addresses including indirect long addresses would be 32 bits rather than 24.

_________________
http://www.finitron.ca

The core will be 65C832 backwards compatible. I added the CS and DS registers as completely new registers rather than modify the usage of the program bank, and data bank registers. The registers not desired to be used can always be set to zero.
I decided to use a second page of opcodes rather than changing how existing opcodes work. The new opcodes are also available to the '816 and '02 emulation modes. The opcodes are primarily 32 bit address modes. For instance LDA $12345678,X. There are segment prefix instructions to allow overriding the default of the data segment. CS: prefix selects the code segment, but there is also a SEG0: prefix to select segment zero. IOS: selects the input / output segment ($FFD00000).
I've coded the core with an instruction cache which can't be disabled. It's pretty meaningless to have the VPA signal active during internal instruction fetches. This changes the sense of the VPA and VDA signals. VPA is active during a cache line fetch. Bot VPA and VDA are active for the first byte of a cache line fetch.

The core is going to be about double the size of the '816 core.

_________________
http://www.finitron.ca

The core is running in an FPGA now in 816/02 compatibility mode. It doesn't work 100% yet, it hangs running Supermon. But it does clear the screen and display the startup message. It also accepts keyboard input which is a bit flaky yet. I found a bug in the 816 core and fixed it for the 816 / 832 core. The TRB/TSB instructions weren't setting the zero status correctly.

An update to the assembler is needed to support the new 832 instructions.

_________________
http://www.finitron.ca

Fixed the bug that was causing Supermon to hang. It was in the software portion of the terminal emulation. Supermon 816 seems to work now. The core is about 8,000 LUTs or 12% of an xc7a100t.

The assembler has been updated to support the 832. This may be the first assembler to support the '832.

_________________
http://www.finitron.ca

I've been busy raking leaves among other things, but I still had time to update the core significantly.
I fixed a few more bugs in core, software, and assembler. The core is constantly getting better. There is room for further improvement. Data memory access currently uses A two cycle approach because it was originally based on a WISHBONE bus interface. Using the 6502 bus this isn't really necessary and it could be improved to be single cycle. (Currently back-to-back memory cycles have a dead cycle in between.)
An instruction was added to allow cache control. It's now possible to invalidate the entire cache, or just a single line. I may use the same instruction to control other core features.
A PC history capture feature was added. This is composed of a scrolling window of the last 64 instructions executed. I found this useful to figure out where software was crashing.
The opcode map has been updated. Updated source code has been placed into GitHub. The source code for the assembler is under the RTF65003 core folder.

_________________
http://www.finitron.ca

A "black box" Flight Recorder?? Cool!! (morbidly sensational)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Nope, I added it to mine years ago.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Almost. I was thinking of adding the capability to do a history capture of all the registers - the 6502 has so few registers that it might be doable. If old memory values were captured as well, then maybe an undo feature could be added, allowing a program to go back to a previous state. But it means all write operations would be read-modify-write operations so that the old value in memory could be captured. Then there's the problem with I/O which makes it almost impossible to have undo.


You were anticipating the release of the '832 then. The FT832 is backwards compatible; it adds new addressing mode and instructions, so I'd be the first to support the FT832 The 65832 doesn't really change the programming model very much, except that it provides 32 bit registers. FT832 doesn't change the programming model very much either except for adding support for 32 bit addressing. Extra long address modes and extra long indirect addressing.

One thing I don't like about the '832 is the way mode switching is handled. The overflow flag has to be set when executing the XCE instruction to set the mode to '816 compatible. It's somewhat of a trick to set the overflow flag. Also some of the register sizes can't be changed without switching the processor mode. So switching the size of a register will likely toast the stack pointer. Meaning the stack pointer may need to be saved and restored in addition to other code to switch register sizes. I've been thinkin of adding byte and word prefix instructions to allow narrower than 32 bit memory operations to occur without switching the registers sizes and processor mode around.

_________________
http://www.finitron.ca

I re-wrote the core to support byte and half-word prefix instructions. So there has been a lot of change to the core recently. An issue that crops up in project work is finalizing a design in order to limit the amount of change taking place. This core is really still being designed, and while it works at the moment it's not ready yet for thorough testing. How do you design a test when you don't even know what all the instructions are yet ? A lot of bottom up parallel construction taking place here.
I've been thinking about adding task switching support, in part because of the problem of how to handle interrupts. One possibility for interrupt support is to switch modes, perhaps to native mode on an interrupt. The idea would be to allow running emulation modes for legacy software support, but handle interrupts natively. Automatic task switching might help to control things. The mode setting would be part of the task, and the task would be switched on interrupt. But, I don't want to make the core too complex. So maybe I'll create a complexity branch. But the way to control different core configurations is through parameters.

The number of bytes required to save the core context during an interrupt may be an issue when the stack is only 256 bytes. At four bytes per register to save and eight bytes for the CS:PC it really starts to eat into the stack, should the stack be limited to page 1. It may not be an issue assuming that one doesn't run emulation modes at the same time as running natively. If one were just to switch the core to native mode and leave it at that setting then I guess there isn't an issue.

_________________
http://www.finitron.ca

Task switching instructions have been tentatively added to the core. These instruction work in emulation modes as well as native mode. The core has been setup with 256, 256 bit wide context registers which are used to store the register context for a task. All the core registers are stored to, or restored from the context registers in a single cycle. So task switching is fast. The task switch primitive instruction TSK takes only three cycles to execute. The sample below (which has been tried) shows task switching for an interrupt routine.



The context registers can be initialized from a context record stored in memory using the LDT address,X instruction. The LDT instruction loads a 32 byte context record into the context register identified by the .X register.

Context Record Layout:

_________________
http://www.finitron.ca

Tonight, I've spent some time playing with interrupts, multi-tasking and 32 bit code. It's been a thrill to get something working.
I got the following Hello World code to work, running in a native mode task called from an emulation mode task. This is the first 32 bit code that has been tried.
Internally the core manipulates 32 bit values for it's value processing (essentially the ALU is 32 bits). It then truncates the 32 bit values down to 8 and 16 bits for emulation modes. So it's not surprising that the 32 bit code works once the bugs have been ironed out testing with 16 bit code.


You may notice the branch directly after the RTT. This branch is necessary because the next time the task is invoked it will begin executing code at the next instruction after the RTT.
Invoking a task isn't quite the same as calling a subroutine.

Also the number of task context registers has been increased to 512 from 256. Apparently this does not increase the resource requirements in the FPGA. Only half of the RAM was being utilized. My initial thoughts were to provide for only a small number of tasks, since this is more likely to be used for embedded systems.

_________________
http://www.finitron.ca

Rob:

Not that you need too much encouragement, but I thought that I'd note that I like to follow your progress on your various projects. Invariably I find that your efforts provide great insights on how I can improve my efforts. I've had virtually the same thoughts regarding task switching that you are adding to your core. I am looking forward to your continued posts on how your implementation pans out.

Please keep sharing your projects; you can count on at least one interested reader.

_________________
Michael A.