Question. SYNC in MOS6510 ?

[Dr Jefyll]

grzeg wrote:

Dr Jefyll wrote:

(The scheme used by the 6509 is flawed, IMO.)

-- Jeff

I've never run a 6509, but Steve Gray ( sjgray ) answered some of my questions over in the 6509 lookalike thread.

What we want -- or at least what I want -- is a 16 MB space. What the 6509 gives you is a pair of IO registers, then 65,534 bytes, then the same pair of IO registers, then 65,534 bytes, then the same pair of IO registers....

OK, so we lose 512 bytes out of the overall 16M -- not a problem in itself. But the space is all broken up into pieces! There's no easy way to code an application that uses a big data structure -- like, say, an array of 20 or 30 elements, each of them 40K in size. Or maybe you're doing digital audio, and want to hold a stream of 90,000 or 190,000 bytes in memory. An '816 can easily hold and address a big array like that, as can my KK computer. But on 6509 the same application would be much harder (or impossible) to write.

The solution I'd try is to make the IO registers appear or not depending on the instruction and addressing mode that generates the bus access. Most instruction/mode combinations would see the registers, but bus accesses caused by $B1 and $91 would not. Maybe the 6509 already does it this way, but indications are that it doesn't. They came so close!

ETA: the fix seems tolerably easy for us to include, and it doesn't break compatibility with CBM-II programs. Even though MOS didn't include it, we could.

-- Jeff

[Dr Jefyll]

grzeg wrote:

You could even use the 6502 and add registers as in 6509 and 6510.
Now, I think it would be the easiest.

I like that idea, too! But we still have the other problem to solve. Can you think of a way that the circuit could find out (or be told) whether...

• a 6510 program is running, and accesses to 0000 & 0001 need to have 6510 behavior, or...
• a 6509 program is running, and accesses to 0000 & 0001 need to have 6509 behavior ??

[grzeg]

idea
RAM extension is based on the Commodore C64.
Here it is very easy for the bus access cycle to determine whether it is to be i / o (D000-DFFF) or RAM (D000 -dfff)
1. 6502 used (can be CPLD)
2. apply the 2 modes for one processor compatible with 6510 and the second just like 6509
3. In 6510 mode, the CPU registers are saved $ 00 and $ 01

4. In the "like6509" registers with $ 00 and $ 01 actually put in the i / o c64 (eg. $ Dx00 and $ dx01) and the addresses $ 00 and $ 01 to have the RAM.
5. NOP instruction could be used as a prefix (this should facilitate the decoding)
Areas $d000-$dfff ( i/o or RAM) swap dynamically depending on the CPU mode, the prefix and the bank in which the program.
and so
NOP ($ B1 or $ 91) as well as 6509 (banks switchable) (D000 - DFFF - RAM)
xxx <> NOP ($ b1 or $ 91) as in 6502 within the same bank, (D000 - DFFF -RAM)

other commands (lda, sta ... )preceded by a NOP access to i / o D000-DFFF
without prefix NOP access to the RAM in the D000-DFFF

EDIT
Why not ?

[Dr Jefyll]

Quote:

5. NOP instruction could be used as a prefix

grzeg, I'm confused about one thing. (OK, several things! -- because I don't know much about Commodore machines.) But I thought you wanted to run 6509 CBM-II programs. Would you modify them to include the prefix?

The prefix idea is good, but I thought you needed something that would "just work" with an existing program. Would a mode bit (that you only need to set once) be better than a prefix (which has to appear before every extended meory reference)? What would happen to the 6510 programs -- do they get changed, too? Please explain what your goals are so I have a better understanding what you're doing.

cheers,
Jeff

[grzeg]

What I want to receive?
I think , does not know yet.
Well, from the beginning.
1. Now my system is 256 "of virtual" c64 with a common i / o. I have virtually full compliance with software commodore c64 and absolutely must be preserved.
2. I'm looking for a way to easily manage the memory and here I liked the solution used in the 6509 , it seemed to me quite easy
and effective.
3 ... If still managed to make compliance with the CBM-II (if only slight adjustments source code) that would be perfect ...
I just keep looking the best solution

cheers,
Grzegorz

[Dr Jefyll]

grzeg wrote:

I'm looking for a way to easily manage the memory [...] If still managed to make compliance with the CBM-II (if only slight adjustments source code) that would be perfect ...

Are you talking about CBM-II software that someone else wrote, or something you will create yourself? I don't know about what is available already -- you need to explain that for me please.

White Flame wrote:

Another alternative (even though this is the hardware forum) would be software emulation via code analysis. Given that this is a very short-lived architecture, you could suppose that the software you'd run on it was well-behaved in terms of accessing the new hardware features. For instance, assume that $00/$01 access was all done by straight LDA/STA zp instructions, and detect those in the code stream.

If you do have 16MB, and are emulating a 1MB architecture, and are willing to give up timing accuracy (BRK substitution already does that), then you should have plenty of elbow room for tables & analysis. This is the sort of things that emulators on the PC do with JIT'ing chains of instructions, but in this case no JIT transformation is required because the instruction sets are compatible.

I think it would be more work than a hardware solution, but if the hardware solution isn't feasible it is an alternative.

This is intriguing, even if it's not a good choice for Grzeg. There'd be a 6502 program that looks at the 6509 program, byte by byte, to determine what's going on? Whenever it finds what it thinks is a sequence that alters the 6509 bank registers, it patches in a jump to a substitute sequence (in its own extended RAM space) that matches the actual hardware. But this overseer program only gets called as required... when execution lands on something that hasn't gotten examined yet -- is that right?

[grzeg]

Z CBM-II would like to run at least OS
This
http://www.von-bassewitz.de/uz/oldcompu ... 500.s.html
(of course, after adjustment for my system) can still BASIC ROM.
Software emulation solution completely eliminated due to speed - only 1 MHz.
But the two systems are very similar, so if we could catch only the differences ($ b1 or $ 91), then anything is possible (even patch software / hardware).
I'm thinking of something like a cpu 6502/6510 patches which gave to the ability to simulate 6509.

[White Flame]

Dr Jefyll wrote:

This is intriguing, even if it's not a good choice for Grzeg. There'd be a 6502 program that looks at the 6509 program, byte by byte, to determine what's going on? Whenever it finds what it thinks is a sequence that alters the 6509 bank registers, it patches in a jump to a substitute sequence (in its own extended RAM space) that matches the actual hardware. But this overseer program only gets called as required... when execution lands on something that hasn't gotten examined yet -- is that right?

Right, the easiest would be to replace the indirect operations with BRKs, so that the code alignment would be unaffected. Replacing STA/STX/STY $00/$01 with BRKs would also allow any value from any source to be written to those registers.

PC emulators using JIT are pretty fascinating, and I don't know exactly how feasible mimicking their functionality on a 6502 would be. Basically, they often have interpreters for the target CPU, and if there are known static runs of code which do not modify any existing code, those parts can be translated and executed directly, with a JMP back into the interpreter at the end. Any memory writes to code that's been JITted needs to invalidate that JIT chain; jumps to un-JITted code can lazily create new JIT chains.

But we're already escaping all (zp),y accesses; doing the same for (zp,x) means that all that remains is absolute addressing, which is statically analyzable as to whether or not it tramples code. Indirect JMPs would also need to be escaped, to see if it hits new code areas, and if you want to be complete, RTS would need to as well to catch PHA PHA RTS tricks. Interrupts would be caught by the "hypervisor", to see if the IRQ vectors are new code.

Again, a hardware solution would be easier, as it's just 2 ports and 2 instructions to be modified. But I'm a software guy, and this is interesting.

[Dr Jefyll]

grzeg wrote:

This
http://www.von-bassewitz.de/uz/oldcompu ... 500.s.html

Okay, now I'm beginning to understand. Since you have access to source code, you can change what's necessary, keep the rest, and re-assemble. And you say this ROM implements a BASIC that can use 6509 extended memory?

grzeg wrote:

I'm thinking of something like a cpu 6502/6510 patches which gave to the ability to simulate 6509.

Right. So, you build hardware that lets a 6502 (or 'C02 or '816?) appear as a 6510, and also lets it appear as a 6509. It can't do both at once (due to the conflict re 0000 & 0001), so you have a mode bit -- which gets set to 6509 mode before you enter the ROM code and gets set back to 6510 later (upon exit or reset). Is that right? (What are the 6510 ports are used for? Whatever it is, you'll have to do without that function while the machine is in 6509 mode.)

White Flame wrote:

PC emulators using JIT are pretty fascinating

I'll say! I read a terrific article on the subject back when Transmeta was news. But would simpler methods suffice for the task at hand? I think 6502 simulating 6509 might be doable, even at 1 MHz. This is probably naive, but here's the approach I'd investigate first:

• There are two copies of the code; one that's seen by the supposed 6509, and one that's seen by the overseer (the 6502). Initially the 6509 copy is entirely replaced by 0x00 bytes (BRKs), but these get progressively updated as they are accessed. By "update," I mean the 0x00 byte is replaced by the real value, copied from the overseer's copy. Once "updated," it subsequently runs at full speed.
  
  So, we sic the 6502 on the 6509 code, and immediately get a blizzard of BRKs which later abates. Every BRK calls the overseer, which checks for 6509-specific activity. On occasions when it finds none, it'll do a straight update of the opcode and the following operand bytes if any. But if it is 6509 activity, mods are applied to the update. Hmmm.... that'll cover the code, but we need to get the 0x00s in the data updated, too...

Am I off to a good start, or is this completely ridiculous?

-- Jeff

[White Flame]

My idea necessitated a copy each in the 6502 and 6509 spaces, then analyzing which code bytes to zero out in the 6509's space. But I think starting the 6509 out with all zeros is a great idea, lazy evaluation in the extreme. There are of course weird edge cases between code and data, but I think it's doable:

• Everything starts out as zero, data included.
• When the 6502 transfers control to the 6509 at some PC, that PC is marked as 'code' in the 6502's side tables.
• BRK hits
• If the code is an emulated one (a store to $00/$01, or indirection), emulate that instruction, leave it as BRK in 6509 space, and transfer control to the next instruction.
• If the code is JMP (ind), RTS, or RTI, emulate that instruction, checking for the dynamic address it's transferring to. Leave it as BRK in 6509 space.
• Otherwise:
  • We're going to JIT the instruction. Copy that instruction's byte(s) to 6509 space.
  • If the code is an absolute or zp memory op, mark the target location (or the entire 0-255 range if indexed) as 'data'. Copy the real data for that location(s) from 6502 space to 6509 space.
  • Check any static code target (JMP abs, branch, or simply the next instruction address) to make sure it's not 'data'.
  • Transfer to the JITted instruction.

The conflict is when a new store instruction is updating a location marked as 'code' (perform selfmodding or overlay loading), or transfer is controlled to something marked as 'data' (execute loaded/selfmodded code).

I think the former case is pretty straightforward: Reflect the selfmodded byte back into the 6502's view of memory, change the 6509's byte there to BRK, and unmark it as either code or data. Let the store instruction stay emulated for now.

For the latter case, the first thing to do is to copy the byte out to 6502 space, return that byte to BRK, and let it run. HOWEVER, any already JITed access to that data location needs to be un-JITted back to BRK as well (if it's reading an instruction, it should read the real one, not a substituted BRK. If it's writing what was assumed to be data, it can no longer do so natively). So the 6502 needs to track where all the absolute/zp write or RMW instructions are, and what they hit (indirection is always emulated).


Caveats:

• Detecting self-modifying code on the stack won't be done when the code is updated via stack instructions. However, that's insane and I've never seen that ever. Cue somebody who has. Emulate stack instructions if this is an issue.
• Deciding whether or not to JIT indexed instructions at all is a performance tradeoff. If code ever runs in ZP (like the C64's BASIC reader), that should prevent all zp,x instructions from being JITted in the above description. Stuffing little abs,x/y addressed tables inbetween code would also thrash around between JITting and un-JITting if the whole 256-byte range was assumed in the static analysis above. Being selective about which indexed instructions to JIT would still let most code run fast.

[grzeg]

I think if we can source code enough to do it in another bank only table instructions $ 91 & b1 to the supervisor could know what to emulate.
Such a map could be prepared in advance, eg. on the PC.

[BigEd]

I do like this blizzard of BRK. But I see Jeff's point: data tables will be zero too, and not trapped, and that will be wrong. It's almost a question of needing SYNC again, to trap instructions. But how to trap only the ones we haven't yet processed? Perhaps a big bitmap RAM...

[White Flame]

BigEd: Read my post again. That should be a complete, working process, including copying data from 6502->6509 as needed, and 6509->6502 as data changes to code.

[BigEd]

Ah, I see, you copy data, and possible-data reached by indexing, but you also check all control transfers to ensure they don't land in data...

But branches have two possible successor PCs. Is there a tricky case with the byte following a taken branch? If the branch is never taken, that might be data, already speculatively copied because of indexing. But it might be code, if the branch will later not to be taken, and yet it's now non-zero so it won't be trapped.

Is there another tricky case with an RTS that uses pushed constants? You'll capture the first case you see, but later cases with different constants could miss the trap, for the same reason: the destination was speculatively copied because there's nearby data accessed with an index mode.

(There's another trick people use, but I don't think it causes any trouble: a JSR which is followed by constant data, read by pulling the PC and adjusting it.)

[grzeg]

Dr Jefyll wrote:

grzeg wrote:

This
http://www.von-bassewitz.de/uz/oldcompu ... 500.s.html

Okay, now I'm beginning to understand. Since you have access to source code, you can change what's necessary, keep the rest, and re-assemble. And you say this ROM implements a BASIC that can use 6509 extended memory?

This is only a Kernel, but also BASIC could be obtained.
This is the same as the one used BASIC later in the Commodore C128