6502.org

Great to hear :-)

Please keep in mind the feature page is where I started thinking about the design, with I'm sure in some cases inconsistent parts - just a scratchpad to keep my ideas. The actual specs will be the real specification.
This is definitely desirable but I cannot promise it.
During interrupt the 65k will keep the legacy and only save the most basic state - return address and status, no other registers. Where did you find this? That was meant about the single-byte opcodes (i.e. without operand, meaning like all 6502 opcodes). Only 105 are not used, and even less if you also implement the CMOS opcodes C'mon, I did multi-tasking with the 6502 already :-) Yes, that is part of the considerations. A larger processor will most likely have a wider memory interface, which helps with longer opcodes.
You will see how I designed it on the programming specs page. No, that would just take too much opcode space. I'm afraid the PowerPC address translation is somewhat complicated. I'm not sure I did understand it correctly either. I find using a hash code somewhat strange here. Maybe just look at the programming specs and discuss what I designed. Sorry, but basically all modern processors and operating systems use an MMU with multitasking. Even my GeckOS does this on my CS/A computer. Why do you think it is not suitable? In fact I don't know of any operating system that actually takes a segment approach. My segmentation approach is to easily implement some kind of virtual environment. If you look at the programming specs, it's prefix byte, then opcode and "quick" operand #1-#8 combined, which makes it a two byte opcode. Using a three-byte approach is actually worth thinking about. You seem to be assuming that opcodes are aligned to word (2 byte) boundaries. That is not the case. Even with 16 or 32 or even 64 bit addressing, the smallest addressable unit is the byte. The instruction fetch and data read/write logic will have to break up misaligned accesses. Bit 5 is only used to indicate the stack frame size on the exception/interrupt stack frame. If it is one, then two address bytes follow (compatible to 6502), if it is zero, then on stack the extended status follows, plus a possibly wider address - see the programming specs for details. There is no such thing as a "native mode". All opcodes, all register widths etc are always available. There is only two state bits: decimal mode and hypervisor mode. See programming specs for details. See programming specs. I decided to use the second approach, as 1) the bus can have different width options, which would require different binaries for different widths and 2) you'd waste some memory (with today's memory sizes maybe not a problem but Motorola/Freescale stripped down the 68k opcodes from always two-byte to be single or two byte for the dragonball/coldfire (don't remember which one if not both), and 3) how would you address the second byte in such an address? If you can address them separately, you can address words misaligned - so you'd need some compensation anyway. These problems made me go for the byte-alignment of opcodes and an opcode cache (where, as you write it, surplus bytes are cached for the next access). Will comment on that shortly :-)

André

This is only the first option. The PC is "just" an address register, which gets larger with the 32 and 64 bit options. There will be no 24 bit option, but you could decide to simply not use the upper bits. The interrupt vectors are considerably placed at the upper end (not the upper end of the lowest 64k but the upper end of the whole address space). "deprecated" basically means "outdated". Well, new spec and already outdated? :-) Actually I started to describe everything with "LL" for 64 bit, but I found other docs where 64 bit are noted with a "Q", so as I prefer single characters here, I'm moving to Q. This is actually only used in the exception/interrupt stack frame, to detect the extended stack frame. There are 32 prefix1 values and 16 prefix2 values. Both can be placed before certain opcodes. Those opcodes that support both prefix can actually have both prefix bytes, prefix1, prefix2, then opcode. With two-byte opcodes, the full opcode can even be four byte now.

With the 32 prefix1 values you can define 5 bits, which I designed to define register/operand size (RS1/0), Address Offset (OF1/0) and Addressing Mode (AM). With prefix2 you can define 4 bits, 2 of which are currently defined: "no Zero extension" ZE and "User Mode" UM bits.

These 7 bits, 5 from prefix1 and 2 from prefix2 can be seen as opcode modifiers and one of the tables on the page shows which opcode can use which modifier. Two things often pop up when discussing a 6502 extension, PC-relative and Stack Pointer-relative addressing. Using two bits I was able to define another register - "B"ase offset - which can be used as B-relative addressing. I also even think it is very useful for user-defined stacks. In object oriented languages it could point to the base address of the current object for example. The zero extension bit comes in when writing a value to a register. A register is always full width (i.e. as wide as an address). So what should happen when you load a 16 or 32 bit register with an 8 bit value like
LDA #$12
Should only the lowest 8 bit be set in the Accumulator like in the 65816, keeping the upper 8 or 24 bit? Or should the upper bits be zero-extended like the index registers in the 65816? For the principle of least surprise I decided to always zero-extend, and provide a ZE bit to NOT zero-extend the value.

I have actually been thinking about providing two more extension modes: 1-extension, and sign-extension, where the latter takes the uppermost bit of the operand value and uses this to extend the value to the full register width. I'm almost with you there. Yes, where the extension bits are zero - for the original 6502 opcodes for example - no prefix bytes are needed. But what do you do when you combine 32 bit action with one of the extra opcodes and with privileged mode? You'd use 3 separate prefix bytes. Besides, 16/32/64 bit action ARE the RS0/1 bits! But then code for a 16 bit 65k would not run on a 32 or 64bit 65k processor. Not acceptable. But that's just 2 bits in my prefix codes :-) I was thinking along the lines of the CMOS BBR/BBS/SMB/RMB opcodes - I think I forgot them so far actually - which combine the actual bit number into the opcode. I think that's open for discussion.
Although it might be possible to put some special "shift by 8" code into the ALU, but certainly not a shift-by-256, while an INC-by-256 would work again. Multi-shift comes up sometimes in the extension discussion, INY #8 / INX #8 should in my opinion be a must with 64bit registers.
Not sure yet what I'll do, any more opinions? Something like the 8259 is certainly a good idea. I'd want to keep the interrupt tables of the 6502 in memory though. But you're right, the processor could have different options in numbers of interrupt lines, with a byte as interrupt number, working similar to the trap table (unifying these two implementations, which is good).

I could reserve 128 vectors for interrupts and 128 vectors for aborts - where I am still not sure if I should really use the current design, as it limits the number of abort causes (and I already have another abort in mind - OPWIDTH: abort when a wide operation is executed in a smaller processor, like a 32 bit opcode in a 16 bit processor - which would fill up the currently reserved abort table)
What would be the high word of the interrupt routine address? Would it be the same as the interrupt vector? Would be working. Would certainly make the implementation easier - but interrupt handling needs to be within the 64k, at least as you say a long jump. I'll probably just start with this option and see how it works. Other opinions? Because there are many interrupts now, so I replaced IRQ with the BRK vector (which it now already is as well), and placed the interrupts elsewhere. Then NMI ended up elsewhere as well.

Many thanks for your comments, very much appreciated!
I hope I was able to answer your questions.

André

Address translation on PowerPC makes a lot of sense, when you look at it from the OS writer's point of view, and not the virtualized application's point of view.

The hash table is known as an "inverted page table" (see http://en.wikipedia.org/wiki/Page_table ... page_table ). It's a fixed-size structure, proportional to the amount of installed RAM. Hence, unlike on CPUs with page tries (e.g., x86, Sparc), the kernel always knows where to look for both forward- and reverse-page lookups, and can do so without the fear of ever running out of kernel space in the process.

The down-side is that TLB misses are more expensive, since the CPU must now traverse the page table, in effect doing a partial table scan (in the SQL table scan sense of the meaning) looking for a suitable mapping. Only if none is found will the CPU throw a page fault exception. Hashing is used to hasten this process. The PowerPC, for example, limits its page lookup to 16 fetch cycles maximum before it throws an exception (8 with hash function 1, 8 with hash function 2).

Since the IPT is a fixed-sized resource, it follows that page table entries, like pages themselves, are managed using a LRU algorithm. This simplifies writing page fault handlers.

IPTs also allows for more flexible mappings as well, assuming the hardware supports it. For example, even the 32-bit PowerPC architecture defined a 64-bit virtual address space, allowing one to effortlessly write so-called "single-address space" operating system if you really wanted to put up with the PowerPC segment registers. 64-bit PowerPCs expands the virtual address space further still.

Hallo André, http://www.6502.org/users/andre/65k/65k ... ve%201.txt : It seems there is a mutual misunderstanding, just forget about it.
Having read the rest, I understand and accept it.
You saying it is enough to convince me. Thinking your answer over and over again, I think I know how it is/could be used.
Yes indeed, the last 64 KB where the vectors are situated as well.
I have written a program once, based on code written by others, using an indirect jump to the NMI vector to do something. I can magine programs that rely on the information to find those vectors on their original places.
All previous answer were good and understandable. But in this particular case you haven't given me satisfing answer. I really welcome the extra vectors. But what is your reason to rearrange the order?

Looking forward to hear from you! :)

If the interrupt has gone away - it has gone away. Obviously it was inadvertently serviced.

(This assumes you use level triggered interrupt lines. You should use level triggered interrupt lines.)

Hallo André,
That's a satisfying answer. But ...
Yes, but it starts up in emulation mode i.e. 6502 compatible vectors. I can replace the 6510 with a 65816 and the C64 will start up as normal. And it even will run programs not manipulating the onboard I/O port or using illegal opcodes.
Could I perform the same trick with your 65k?

That is indeed a good point. I'll see if I can find a solution.

André

Actually, it's really annoying that the Pentium starts up in 8086 real-mode. Dropping the processor into protected mode, and then from there to 64-bit mode (if supported) just adds a lot of complexity to the computer as a whole that really doesn't need to exist. However, if that DIDN'T happen, it's hard to tell whether or not the PC industry would have grown as large as it has.

Making the 65816 backward compatible with the 6502 was a smart move for this reason -- it allowed accelerators for the Apple II and Commodore computers that couldn't perhaps exist otherwise. But, the 65816 is a lot easier to get into native mode (CLC; XCE) than it is the Intel architecture.

fachat, maybe you can let the circuit implementor choose how it boots up. I'm thinking a single wire tied either to Vdd or GND. If Vdd, it boots up in native mode, exactly as you're planning now. If GND, it boots up as an 8-bit 6502, requiring the programmer to manually place the CPU into its native mode.

Good idea!

Yes I've thought about that too. But there is in fact no such thing as a "native" and "emulated" mode. The processor is always in native mode. So to change the interrupt vector location I was thinking about just setting a register to set the vector table base address. When the vector table base address is set these are used, if not then it uses the standard IRQ and NMI vector. Maybe the same for Aborts and Traps, use a single vector when not set, use a vector table when set.

Speed is important for aborts, so a vector table should be used. For example a privilege violation abort should be able to run rather quickly, so that the supervisor can handle SEI/CLI quickly (privileged operations) and return to user mode. Alternatively (maybe using a user mode control bit) I could ignore SEI/CLI in user mode or apply it only to interrupts forwarded to user mode. Not sure about that though...

André

You'll want to also adjust the width of the vector fields; the 6502 uses 16-bit wide vectors, but a system with a 32-bit PC should have 32-bit wide vectors.

That's actually what I specified so far with the current (first) version. The lowest 8 bits of the vector base address are not used (you can set the address in 256 bytes steps), so two bits are used to determine the vector size. That however, makes it very complex and I don't know if I should implement that from the start.

To be able to directly replace a 6502, the system should start with 2-byte vectors - Ruud's approach was that the code pointed to by the vectors is in the same bank as the vectors, then use long jumps - if at all necessary to get elsewhere. The simplicity of that approach is very compelling...

André

OK, that would work too, so that if the vectors appear at $FFFFFFxx, then the routines they point to appear somewhere in $FFFFxxxx -- this makes sense to me.

I approve.

Sorry if I haven't read as much detail as I should have. Been busy, and will remain busy at least until after end of November.

That's Great :-) No problem, the spec is still in flux. Don't expect any VHDL code this year...

André