I think it would be just if they added an addenda to the data sheet.

If it's a PDF, you can "annotate" the PDF, but I don't know if all readers support annotations.

And if you don't make a note on the sheet itself, then a note on the link to the sheet discussing the conundrum would be relevant.

Further updates:

• After realizing that I was still using phi2_6509 on all of the Verilog logic, I switched to PHI2_6502 and the bank logic started working. I now see the long pause as the RAM gets tested and I can write programs and use the function keys
  
• I don't know that anything special is needed on the PHI2 signal.
  
• I simplified the Verilog (and Dr. Jefyll's schematic by performing the combinatorial logic on the DATA and SYNC inputs before storing into the flip/flop. This reduces the number of flops (macrocells) needed by 7. NOt terribly useful, since there's plenty of space, but it's more compact.
  
• The bleed through of RAM to the CPU during reads of $01/$1 is still a problem, but it appears to not be an issue with the current CPLD Verilog. I will address it correctly in the next board rev.

https://github.com/go4retro/Fake6509

https://github.com/go4retro/Fake6509/bl ... /Fak6509.v

Jim

(I notice that Mike has prepended a warning page to the 6509 datasheet found in the archive section here on 6502.org:
http://6502.org/documents/datasheets/mos/
)

Excellent, that's perfect.

I know the owner of that page (Martin Hoffmann-Vetter). I emailed him and he has corrected it.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

My apologies for the spurts of activity, but I can now state that I have a working 6509 emulator using an NMOS 6502 IC.

The v3 board, as was previously noted, inserts itself into the databus connection, so as to allow the 6502 to see $0/$1 and ONLY $0/$1 during a read of those two locations.

However, that fix did not allow the design to pass Michal Pleban's test suite. The fix was to do the following:

assign oe_bank = r_w & phi2_6509 & ce_bank;

Needs to be:

assign oe_bank = r_w & ce_bank;

In other words, I typically gate reads of data with the clock signal, just to keep the bus clean. With this fix, NMOS 6502 will perform well.

2 more steps remain:

Rockwell CMOS 65C02 does not work in the same board with the same logic. Traces of the bus during operation for both CPUs is available at:

https://github.com/go4retro/Fake6509/tree/master/ref (ignore port and r/w, as I did not connect those signals for this test)

I am anticipating a WDC 65C02S to arrive, which I will then test and provide updates.

As well, I am trying to simplify the logic. I'd prefer to convert the logic into a state machine, but initial attempts were not successful.


Jim

To update:

WDC 65C02S works fine in the existing PCB, using the NMOS logic. I will leave it up to others to debug the Rockwell 6502.

I have placed the newest code on the github repo. I will spin a few boards if there is interest. Please PM me with numbers of boards desired, and whether you want them assembled, or just a bare board.

The current design has a few components:

1x 40 pin socket
1x 40 pin header
1x Xilinx xc9572xl vq64
1x *1117 3v3 regulator
1x 22uF 0804
1x 10uF 0804
4x .1uF 0402

As the question has been posed, I now turn attention to redoing the board to support the 65C816S. I am interested in how to simplify the logic in this thread with the '816 since the unit has more indicators.

I assume I need to do

opcode = (VDA & VPA & ((data == 91) | (data == b1));
use_ext_port = opcode & VDA & !VPA;

What about IRQ and NMI and such?

Jim

(Hi Jim, it would be great if you could publish a photo, for publicity purposes. It's always good to see a physical thing.)

Nice to hear about the progress, Jim. (And I, too, would enjoy a photo! )

Rockwell 65C02, you mean -- is that right?

I wonder if you'd mind summarizing what you found. I recall from CBM-Hackers that you were using two programs for testing, namely the memory test built into the kernal of a CBM machine, and some sort of 6509-specific test which Michal Pleban wrote. Were there any important revelations, and did you get to a stage where the two tests agree? Using your latest Verilog code in the adapter, what was the verdict re the various CPU's?

Re the prospect of using an '816, yes you can treat (VDA AND VPA) as equvalent to SYNC. And I'm not aware of any reason NMI and IRQ need to be treated differently than on earlier 65xx processors, at least as far as the actual inputs go. (But different vector locations are used if you're in Native Mode.)

Not sure if this is what you meant, but I personally think it would be cool if your adapter (which plugs into an existing 6509 computer) could access the full memory space using two different methods -- the legacy 6509 method (for kernel and other existing code) and either an original, improved alternative method or a native mode '816 method for new or ported code. I'm pretty sure that's possible, but unfortunately there aren't that many 6509 computers around, so you might have to satisfy yourself with the intellectual challenge (rather than by supplying a large number of adapters).

(edits)

-- Jeff

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

https://www.facebook.com/go4retro/photo ... =3&theater

I can put the pic up elsewhere if Facebook is a problem.

Jim

Yes, 65C02

As recorded in this thread, after designing the adapter, my first issue was the mis-naming of the PHI lines on the datasheet. With that fixed, the NMOS 6502B would boot the B128 and the memory test (which takes a bit of time) started working, but Michal's test code did not succeed on all tests.

His tests, which are at https://github.com/MichalPleban/6509-test, perform the following:

• Reading and writing from/to another bank via LDA (zp),Y and STA (zp),Y
  - also when crossing a page boundary.
  
• Reading memory using other (zp),Y instruction (which should NOT fetch from another bank).
  
• Executing code in another bank.
  
• Reading back the value written to registers, using both normal instructions and LDA (zp),Y.

The "reading back from registers" tests were the ones that failed.

We *thought* the issue with the register reads was due to contention on the data bus, as my logic could not prevent a real data access at $0/$1 from displaying on the CPU data bus.

As well, a Rockwell 65C02 did not work correctly (failed some of the tests and did not complete the memory test on bootup)

Thus, I implemented a revision of the logic that intercepted the databus and thus can keep values from the motherboard from appearing at the CPU.

The new board performed the same as the original board. Along the way, I modified the $0/$1 register reads to not gate with PHI. After that, the NMOS 6502 started passing all tests. The 65C02 was still not working correctly.

Mike N (of board fame) sent me a 65C02S, and it worked immediately using the same logic as for the NMOS 6502.

Well, I am laying out a board now, so let me know if my equations are correct.

I understand and I've already implemented that. In short:

• When the unit boots, it's in "emulation mode". Old $0/$1 behavior is active
• If the developer sends a specific set of values to $0, the extended behavior is activated.
• In extended mode, the bottom 4 bits of the bank address are placed on P0-P3, while the remaining bits are placed on pads on the board. In this mode, $0 and $1 are not accessible as registers, they will store and return data from the main bus

I forgot about the 'E' line on the '816 showing emulation mode state. I *can* create some optimizations:

• Use the 'E' line as the trigger to switch to the new behavior. Downsides are that I think you can switch the 816 to emulation mode in a bank other than 0 and continue executing code
• Use the 'E' line as a trigger to allow switching to the new behavior. This seems pretty straightforward with few downsides.
• Don't use E line at all.

Thoughts appreciated.

Sorry to be a pain, but yes please, if you could attach a good size pic here that would be much better for me.

Can you see this?

That's great - thanks!

Very puzzling. Before the mod, which test(s) had been failing?

Again, which test(s) failed, please? I know these chips all have their quirks, but some of these results differ from what I would've predicted, and if I've missed something I'd like to learn what it is.

It's very exciting that you have in the works an '816 version capable of using Native Mode! Regarding the concern you mentioned, you're thinking the programmer might have a piece of code that switches to '816 Native Mode then eventually returns to Emulation Mode -- and you're hoping this piece of code can reside in a bank other than bank zero, is that right?

The first part seems alright, because legacy 6509 capability could get you into the desired bank, and the 816's Program Bank Register (PBR) can I think be loaded with a matching, non-zero value even while still in Emulation Mode. Then you use the XCE instruction to engage Native Mode, and that's when the 816's E output goes false and your CPLD stops relaying 6509 high address bits to the mobo and starts relaying '816 high address bits instead.

Using XCE to switch back to Emulation Mode will, AIUI, cause the '816 to re-initialize the PBR to zero. But that's also when E will go true again, and the CPLD will stop relaying 816 high address bits to the mobo. Does this answer the question, or have I misunderstood what you were getting at?

BTW thanks for the pic. In future you may find it more convenient to simply attach the image with your post, which this forum (unlike many) does allow.

edit: fix slipup re one of the references to the E pin -- which is true (high) during Emulation Mode and false (low) during Native Mode.

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