MOS 6509 look-alikes?

[brain]

Dr Jefyll wrote:

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

The ones that essentially did some variant of lda $0 or lda $1.

Quote:

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.

This is the issue you looked at on cbm-hackers. The Rockwell 65C02 does not pass the memory test, and so boots up immediately. My theory is that the falling clock turns off the port values one a $91/$b1 call too soon, and the CMOS '02 takes too long to read the returned data, so the value read is wrong.

Quote:

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 changes state 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 false 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?

If moving back to emulation mode forces the next code access to be from a bank 0 location (PBR = 0), then I can safely use the E pin to denote whether to use the old or new way of setting the PORT pins.

Quote:

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.

Ah, OK. I assumed it did not.

[DeskMachines]

I've noticed a misconception in this thread. The port on the 6509 6510 is a general purpose I/O port not a memory maping port, although it can be used as such and is always at location $0000-$0001

This is a quick schematic I drew up of a 6509 6510 replacement. It is an untested theory I have but should work without too much modification. It is a design I have been thinking about for the Commodore 64 to replace the 6510

The components are
6502, 6522, 74LS00, 74LS02 x2, 74LS20, 74LS04, 74LS245

http://deskmachines.com/6510.jpg

[Dr Jefyll]

Welcome, DeskMachines! I have a question about your drawing, but first allow me to mention that on this forum you may, if you wish, include images as attachments to your post.

The 6522 has two Chip-Select inputs, and you're only using one. Can we assume it's the active-low CS you're using (and that the active-high CS is tied high)?

On another topic, twice in your post you referred to "6509 6510," perhaps implying the two processors are equivalent. I hope you're aware they are not (although they do both have ports present at $0000 and $0001). On 6509, $0000/$0001 is not a general purpose I/O port.

The 6509's instruction set is altered in a subtle way that has rather drastic implications. If you want to really understand the 6509 I suggest you start with the datasheet (here). It's not a very well-written document, but pay attention to what they say about how LDA (ind),Y and STA (ind),Y have been altered. This behavior is not shared by 6510 or any other 65xx processor.

cheers,
Jeff

[DeskMachines]

Sorry, I was reading the doc on my lunch and missed the part where the $0000 and $0001 registers are different from the 6510. Is it safe to assume the 6509 has extra op codes to handle this also. Well if nothing else this topic got me to draw up my 6510 plans. Yes CS is the active low CS. I crossed off the 6509 from my schematic and drew a line above the CS. Thanks for looking at my schematic though.

[Dr Jefyll]

DeskMachines wrote:

Thanks for looking at my schematic though.

Happy to do so. And I could suggest changes to reduce the number of gate delays. But I'm not sure we want to go into that in this thread.

Quote:

Is it safe to assume the 6509 has extra op codes to handle this also.

No, there are no extra opcodes. It's quite a clever idea the designers had! But in some respects they dropped the ball, bigtime -- that's my opinion, at least.

-- Jeff

[DeskMachines]

well the opcodes don't look different but I didn't match every one. So there is a port at $0000 and $0001. If you replaced the 6522 in my schematic with 2x 74LS373 and used the sync to select which 373 to use it would essentially use one 373 for execution and the other 373 for memory reads and writes. Although I would imagine it wouldn't secure location $0002-$01FF as stated in the document. Just some thoughts.

Would be happy to hear the suggestions in a pm if not here. I haven't done anything without a PIC in a long time and diving into 74LS logic chips to do the work I didn't have to before.

[Dr Jefyll]

DeskMachines wrote:

If you replaced the 6522 in my schematic with 2x 74LS373 and used the sync to select which 373 to use [...] Just some thoughts.

That's the beginning of a solution, yes -- but it's a long way from being complete. Maybe you should read the thread.

[DeskMachines]

I read the entire thread on my lunch. I get hour lunches. But I will go back through it, or get back to work on my project rather than tinkering with random stuff.

[brain]

The circuit, as designed by Dr Jefyll, works. Just use it. You do need to buffer the data bus, as an extra step, since a read from $0 or $1 will continue to pull data from the bus if you do not.

On the 6510, the same is true, though your VIA idea will work (hard to fit all that on a daughterboard for the 6510) if you buffer the databus. On the 6510, you also need to tristate the address and databus, as per the RDY line semantics, but that's a different thread.

6509 replacement, as you're trying to do, is here: https://github.com/go4retro/Fake6509
I'll put up my 6510 replacement project, as it is working as well.

Jim

[DeskMachines]

I wasn't trying to recreate the 6509. I don't have any reason to. I was just reading the post on my lunch and thought my 6510 idea was compatable so I drew it up too bad it wasn't as useful as I thought. I don't intend to use programmable logic like an FPGA in any of my projects. Just off the shelf parts like 74LS chips. My 6502 board works rather well and will stick with variations of it. I was originally planning to remake the Commodore 64 from off the shelf parts but figured trying to turn a 6522 into a 6526 or remake the 6526 in logic would be too hard and a waste of time.

[Chromatix]

If you *are* going to use discrete logic, don't use 74LS series - it's long obsolete and will give you needless trouble. Most people are using 74HC these days, or 74HCT to have TTL-compatible inputs; they are just as fast as 74LS, consume far less power, and don't have pesky fanout limitations. For more speed, look for 74AHC.

[DeskMachines]

I am using the 74HC versions when I buy new stuff. However, I have a lot of old LS chips still hanging around in boxes.

[brain]

Chromatix wrote:

If you *are* going to use discrete logic, don't use 74LS series - it's long obsolete and will give you needless trouble. Most people are using 74HC these days, or 74HCT to have TTL-compatible inputs; they are just as fast as 74LS, consume far less power, and don't have pesky fanout limitations. For more speed, look for 74AHC.

*mostly*

I mention it because I absentmindedly swapped out all LS for HCT in a project online (EasyFlash), and the unit did not work on all C64 variants. I think the 74hct74 or perhaps another part was somewhat slower, and it was enough to cause issues. AHCT is probably OK, though.

Jim

[BigDumbDinosaur]

Chromatix wrote:

...[74HCT] to have TTL-compatible inputs; they are just as fast as 74LS...

That's not necessarily the case. Many 74HCT devices are slower than their 74LS equivalents. You could use 74ACT for TTL-level compatibility, which will run circles around most other logic families (as well as drive harder). However, you'd likely be grappling with problems related to the 74AC[T] logic's extremely fast switching speed. My POC V1.1 unit is 100 percent 74AC logic and I must tell you I am impressed with the speed at which device outputs change state. The vertical part of the transition from one state to the other is not visible on my 275 MHz 'scope.

[BigDumbDinosaur]

brain wrote:

I mention it because I absentmindedly swapped out all LS for HCT in a project online (EasyFlash), and the unit did not work on all C64 variants.

Part of that may be due to the somewhat rickety nature of the C-64's design. I wouldn't be surprised if doing the same with a C-128 would also result in checkered results.

My attempts to mate a 26C92 DUART with my C-128D have had mixed results. I think the much faster rise and fall times of the DUART get the C-128D's electronics confused at times and even though I'm going through the cartridge port using IO-2 to select the DUART, there are occasions in which an access of the DUART fails. I ended up setting aside the project after the need for it vanished and never did troubleshoot it to the extent required to identify the cause of the flaky behavior. In fact, I have not fired up the C-128D in nearly eight years. I even have a Lt. Kernal setup for it, which I have yet to test.