Yes, every 'exit' from an emulated/pre-JIT instruction must be checked. If a branch is followed by data, that would prevent the branch instruction from ever being JITted. Ah, but it also needs to un-JIT existing code paths leading into that instruction, a point that I missed. So the 6502 hypervisor needs to track all instruction flow as well, so it can un-JIT any instruction that might lead to that location.


RTS, RTI, and JMP (ind) would always be emulated, because their next address of execution is dynamic. It's checked every time. It would be a "dangerous" optimization to allow RTS and RTI to be JITted, but would be expected to work in the common case.


Yeah, no problem there.

Dangit, I don't have the time to start a new project, but this one is very tempting. It all seems to check out, and isn't super complex. It's very RAM-heavy, though.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Ahh - the branch can't be jitted until it's gone both ways, but most will do that before too long. It needs an extra bit of state. I'm not sure why you say preceding code would need to be un-JITted though.
Instead of a bitmap of all of ROM, maybe a list of ranges would do the trick: we expect all straight-line sequences to be JITted when first encountered.

The un-JITting really has nothing to do with branching: Here's the un-JIT case:


The JMP above is JITted to call foo, and the JITted beq will fall through to it as well. If foo exists as data, then it holds the data byte in 6509 space, not a BRK. Better un-JIT anything that reaches foo, so we can reevaluate if and when it enters that location.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Now I'm thinking about interrupts. When in JIT code, the stack will be used to store the 6509 state, which is fine. However, it needs some stump to escape back into 6502 code, unless the banking hardware does that automatically. This is pretty important, as BRK depends on it, too.

BRKs will also mung some of the stack that wouldn't occur in hardware 6509 execution, but that shouldn't affect well-behaved code any more than any regular interrupt in a hardware 6509 environment.

The emulated environment will need some special place in 6509 space reserved for dealing with this. It can be emulated around, like 00/01 is, if it matters.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

in addition to the software solution singer continued think of other solutions.
What do you think about it, if it was possible and whether it could be used?
http://csdb.dk/forums/?roomid=11&topicid=103353

I don't think those methods are very useful for emulating hardware. That's just a very c64-specific hack to access RAM locations that aren't mapped anywhere, by using leftover bus states from the VIC-II. The only contrived use I could see for it is if zero page is mapped to the screen, and you want characters from $00/$01 to display something particular.

Note that this requires special code to write to $00/$01 as well. If the 6509 code were allowed to do just a plain STA $01 on a 6510, RAM location $01 would not hold that value since those tricks weren't done; the write would only go to the 6510's internal port. If you're rewriting or trapping those writes, then you might as well do a more straightforward emulation of the intended behavior, instead of trying to jump through the hoops of literally stuffing values into RAM addresses $00/$01.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

That's my feeling as well. The reason we have a problem is, 6510 and 6509 both use 0000 & 0001 -- but for different things. Emulation of the desired behavior is why the JIT topic arose in the first place.

We could fix the problem by using a 6502 (for example) and custom hardware. A hardware mode bit would choose between 6510 and 6509 behaviors for 00/01. That would allow the software to remain unchanged. But, grzeg, do you have a suggestion for how the mode bit would get changed? Would a manually-operated switch be acceptable? Or, does the mode need to be settable "on the fly" -- to respond to an interrupt, for example?


Speaking of interrupts, ... In that last part you're just pointing out that we'd come a little closer to overflowing the stack; is that right? And as long as there's sufficient reserve we'd be OK.

But in the first part, can you clarify please: what is the problem that might be solved if, "the banking hardware does that automatically"? Most of us here are not JIT experts -- certainly I'm not; I just read a little about it 20 years ago!

-- Jeff

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

When an interrupt hits while in emulated 6509 "mode", including BRK, the CPU state will be dumped to the stack. It's going to hit some IRQ vector in the current 16-bit banked address space of the 6509 code. We want interrupts to be trapped by the 6502 supervisor, so that it can check to see what location it's trying to jump to. This means the IRQ vector will have to point to a 6509-visible stump that banks in the 6502 emulator core, and does that work. Where to place that IRQ handler becomes a bit of an issue, as again it's technically in 6509 space, but is part of 6502 supervisor code.

If an IRQ also trips the banking register (which would have to be synchronized with the end-of-instruction cycle inside the 6502), then it could read the IRQ vector inside the "privileged" 6502 address space directly, without polluting the vectors in the 6509's addresses.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I realize this thread is years old but thought I would chime in:

The 6510 is a real bear without the sync pin, so much so that when we started the C128 I had some 6510's bonded out in a 48 pin package so we could bring the SYNC pin out.

Unfortunately we should have taken a little more time creating the bonding diagram for the lead bonding department over at MOS, they had to turn the die 45 degrees (so it looked like a tie tack) to make the wires reach the way we had drawn it. (We used pins 1-43 when we should have used 1-22 and 26-48)

I am playing with the concept of firing up an old 6502 logic analyzer and decided I wouldn't be doing any C64's/C128 as an example)

Bil Herd

I would think it would be possible (both in the Original Poster's case and in Bil Herd's case) to just use a regular 6502 and emulate the I/O port in hardware. but I guess if you're sitting on a chip factory and you can ask for a special 6510 for almost nothing, why not

===Jac

I don't think emulating the IO port is the goal, though. The focus is SYNC. Without SYNC, Bil's logic-analyzer data is a whole lot harder to interpret. And the OP wanted SYNC so he could emulate a 6509, which features a 16MB address space for opcodes $B1 and $91. SYNC lets you attach external hardware that "knows" what the processor is doing, cycle by cycle, and this has always fascinated me. You get the extra address space by doing a bank flip for one cycle only -- the one during which the CPU is fetching or storing the data.

More fully realized, this strategy can give 16MB access to all the instructions, not just $B1 and $91; and back in the day I was successful doing that with my KK Computer. (Did I mention this sort of thing fascinates me??)

-- Jeff

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