Hi all.

Partly because I need a proper test system for my 74HCT6526, and partly because I just enjoy adding stuff to my TO-DO List, I've started working on my first SBC. It's purpose will only be to serve as a testbed for 6526 TTL Clone.

Until now, I'm using a C64 for this, and it's serving its purpose pretty well. However, the inability to go over 1MHz and the small weird quircks of the 65xx bus on the commodore are the main issues that have driven me to this point.

With this in mind, I've put together the following list of requirements.

• Continuosly variable clock, from 1MHz to as far as possible. I have an upper limit of 30MHz in mind for the clock. I know 20MHz is possible with a 6502, 30 should be pretty much impossible I think. This variable clock would allow me to find any limits
• Clock Frequency Display.. Useful, and should look very cool.
• No input at all. Program the ROM (more on this later) and just run a suite of tests for the 6526.
• Basic output.. Something like a 20x4 Character LCD will do.
• Easy, quick, and on board ROM programming. I will be modifiying the code continuosly, so this is very important.
• Include a 6522. Why not!? It can also be useful for the tests
• Include a socket for a 6526. Compatibility with old NMOS 6526 is not needed, although it would be nice.
• Allow testing of all 6526 pins. Ports, serial, /FLAG interrupt, etc
• Independent reset for 6526.

Ambitious? Sure. Doable? I think it is. Fun? Yeah!

I've come up with the following memory map.



The SBC will have a single 64kb or 128Kb SRAM, fully visible on the lower 32KB of the address space. The upper 16KB will be visible also in the upper 16KB of the address space. the remaining 16KB are splitted into 8 2KB blocks, for the different IO devices.

To startup the system, I intend to disconnect the 6502 from the bus using the BE pin, have a microcontroler write the RAM, return the bus to the 6502 and reset it.

------------------------------

GitHub repos:
SBC6526 https://github.com/dmolinagarcia/SBC6526
LOGISIM6526 https://github.com/dmolinagarcia/LOGISIM6526
74HCT6526 https://github.com/dmolinagarcia/74HCT6526

Second post. I'll use this as a place holder for the schematics. I'll be updating the post as I make changes.

Nov'20 Edit:
After quite a long time without working on this... I'm starting to catch up again. I've reworked the whole SBC to fix some issues I had.. A few pull-ups missing... some errors in placement... I've also taken this oportunity to finally move away from Eagle, so the SBC6526 is now created using KiCAD.

Here are the new schematics for it, much much cleaner than it was:



I'm keeping here the old schematics, as a reference.


SCHEMATICS

Core

CPU, RAM (128KB), 6522 and 6526, and LCD Display.
MemDecoder, Reset and Clock

Arduino bootstrap and Frequency meter

Added Clock&Reset circutry to the second post.

All of this is very, very, very untested! I've come up with the clock circuit after investigating many options, and this felt like the easiest way to have a variable clock. C1 and P1 values should give me a range between 1 and 60 MHz. Divided by two and with a 50% duty cycle after the FlipFlop, and ready to drive the SBC.

Reset comes from Garth excellent 6502 Primer (Thanks, thanks, thank you so much for that) with the addition of a signal from the Arduino, which has the ability to reset the SBC.

Just added the SBC core schematic into second post.

Some notes:
- 6526 Reset is tied to 6522 PA5. I can reset the 6526 individually. PA5 was chosen for layout reasons.
- 6526 and 6522 Serial Shift registers are connected. Could they communicate?
- 6526 IRQ goes to CPU IRQ. 6522 goes to CPU NMI.
- 6526 TOD input is fed by the arduino. It will generate 50hz/60hz after startup
- 6502 BE is controlled by arduino too
- I still need to figure it out how to use /PC and /FLAG in the 6526
- Plenty of free peripheral bits on the 6522. Could add a keyboard in the future
- PA and PB from 6526 goes to a pinheader for probing and testing.
- I'm thinking about somehow connecting 6522 and 6526 Peripheral ports between them for testing.

Hi Dani,

I suspect you might be able to simplify address decoding by modifying your memory map slightly. Any reason why you can’t keep RAM to the lower 32k? If so, then /MEM = /A15 and the ‘138 can decode addresses for I/O devices in the upper 32k (with A15 tied to the G1 pin of the ‘138).

Also, you can probably also make LCDE = /(IC8.15 + PHI1). (PHI1 is already generated by your clock divider circuit at the /Q pin of the clock divider flip-flop). Finally, you may want to use gates rather than tristate buffers to avoid transient collisions on /MEMCE. With the simplified memory map /MEMCE = (/A15 + PHI1 + /BE) * (/CE + BE).

Cheers,
Drass

EDIT: Corrected LCDE above.

_________________
C74-6502 Website: https://c74project.com

Hi Drass. Thanks for your tips. In some form or another, they've crossed my mind at some point. Being my first attempt at a SBC, and being so early in the design process (No more than two weeks) I still have a lot of "ifs" and I may change nothing, I may change everything.



To save on chip count, simplify layout, and get rid of the hassle of EEPROM programing over and over, I won't have any ROM on board, Just RAM. With the current memory map, I have the full 32K in 0000-7FFF, and the upper half on the RAM is mirrored at C000-FFFF. I need memory in the upper range of the address space for the reset/interrupt vectors. I've considered using a 128K SRAM, so memory at C000 won't be a mirror of 4000-7fff. PCB layout is easier (Although this won't affect address decoding). However, I'm finding it easier to locate faster 32K SRAM than 128K SRAM.



This was the original setup. The current design saves one IC, as I don't need a '32 and I had spare inverters and NAND gates. Anyway, propagation delay is longer and layout becomes a bit messier, despite of having one less IC, so I may try to squeeze one more IC on my board. Right now, I'm pretty sure LCD is the longest propagation delay in the system. (Ignoring of course anything inside my 74HCT6526!)



This one's really nice. I wan't too comfortable with those buffers. Somehow I was failing to combine /CE with /MEM... Now that I see it it's very obvious!

I'm now thinking I may not neet to generate /CE from Arduino at all. When I assert BE, a couple of '595 will be enabled and will drive the full address bus, so, /MEM will be enabled when reading/writing to RAM from Arduino except... It won't be in control of PHI2, so some writes/reads may go nowhere. I can work around this, by repeteadly writing/verifying each byte until it succedes. I won't be fast, but it only needs to be done once during startup...

Anyway... I'm a bit tired right now, so I may not be thinking straight

Seems like a shame to complicate things just for the vectors. What’s your Arduino doing while the 6502 is running? Can it sniff the bus and supply the vectors as necessary?

_________________
C74-6502 Website: https://c74project.com

Hi, dani. If I may... an example decoder method for a 64K RAM system (using a 64K or 128K SRAM chip)...

Good luck on your project. Cheerful regards, Mike, K8LH

I totally agree. Don't have any IO pins free though to do that. The startup sequence is as follows

1.- Arduino releases BE and waits for a "RAM Image" from the host PC. Meanwhile, 6502 happily crashes while reading an "empty" memory
2.- Host PC starts to send the RAM Image to the Arduino. BE is asserted and, by using a couple of 74595 shift registers, RAM is accesed and writen to.
3.- When RAM is complete. Arduino resets the SBC, releases BE, and then releases Reset.

After that, the Arduino just sits there waiting for another programming cycle, if requested. It only generates a 50hz square wave to feed the TOD signal in the 6526.

@Mike, of course you may, all help is appreciated, even though any new idea sparks a new tree of posibilities, with the risk of making me go crazy

I'm pretty sure I've seen that image before, most likely in this same forum. I like it's simplicity, and I can't think of many ways to get a faster propagation delay to RAM.

I've managed to combine some ideas from you both into this:


MEMCE propagation delay goes down to a mere 8.5 ns max(6.5 typ, 3 min!)
Peripherals enable gets the same 22~ ns as before.

By using a RAM chip with to enable inputs, I can let the address decoder handle one, the arduino the other, so I save 3 gates needed to mux both signals. Same number of ICs though, but routing is going to be much much nicer.

I've found 128k, 12ns RAM ICs on mouser that should be a good choice.

Once I double check this new version. I'll update the initial posts.

Thanks!

Edit: Corrected the order of pins 14/13 on IC2B, as correctly pointed by Mike in the next post.

Looks good but I think you may have the inputs on IC2B reversed...

This "Bus Enable" Boot Loader interface method requires controlling a whole bunch of pins and will only work with a WDC part, yes, no?

You're right, they were reversed. I got confused, as in you schematic, the pins in the IC are in different order as in my library. And believe, I checked it before uploading

Regarding BE, yes, I need a good amount of pins on the arduino

BE: To tristate the buffer of the 6502. It will also enable the output of two shift registers.
CLK,LATCH,DS: 3 pins to control the 2 shift registers that will generate the address
D0-D8: 8 Pins to handle the databus, once tri-stated by the CPU
CE and R/W.

On top of that, one more pin to trigger a reset of the SBC, and one more to generate TOD for the 6526.

Some time ago I did an EEPROM programmer with an Arduino and it used the same concept to drive the address and data buses.

And yes, as far as I know, BE only exists on WDC chips.

Even though there will be plenty of stuff to fix, I've updated the second post with the full schematic. This is the result of two weeks of head scratching starting from zero, but I feel quite confortable with the solution.

For those of you who've been following the thread, you'll notice many components have been renamed, to put some order in the numbering.

I'm going to let it cool down for a week now. I've ordered some of the components and when they arrive, I'll start doing some tests.

I also want to thank you everyone for the tips, on this thread, and spread through all the forum.

I'm not sure how important performance is to you, but if it were me I'd be using a 74AC00 in place of the 74AC139 (U10). The average prop time of one section of an 'AC00 is about half of the 'AC139. This isn't too important a consideration with U10b, but could matter with U10a.

Also, I fail to see the need for U9a as you have it wired. A write operation to the LCD module does need to be qualified by Ø2, but it's unnecessary with a read operation if you are using a 65C02. As you have it, you're adding an unnecessary gate delay to the LCD chip select. Again, it all depends on how much performance you expect.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Agreed. (And I also endorse the goal of reducing the number of gates in the chain, if possible.)

During read cycles, all 65xx peripheral IC's refrain from driving the data bus except when Phi2 is high. This is not a fluke or some kind of coincidence, and it's advisable to do as they do. Although with 65C02 (unlike '816) it's often possible to get away with breaking the rule and letting a device drive the bus even before Phi2 goes high, there are reasons that's not a great idea.

But is the question even relevant? It looks to me as if the "LCDE" signal that's output by U9a is used by the LCD module to enable both reads and writes -- isn't that true? As BDD noted, it's mandatory that writes be qualified by Phi2. And it looks as if reads are qualified, too, which addresses my concern.

ETA: the output of U9a as wired is an active-high signal. Is that what the LCD module requires? Just checking...

-- Jeff

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

Hmm...I didn't see that earlier (oh, the perils of crummy vision). An active-high device select is unusual, although not unheard of.

BTW, I see a 74ABT74 is being used as the source for /PHI2 and PHI2. That flop should be a 74AC74, as the 'ABT74 has TTL-level outputs. You may run into trouble, since the 65C02 requires CMOS levels at its Ø2 input. I know from experience that using an 'ABT74 to clock the 65C816 will produce erratic behavior. In the application where I ran into this, the 'scope showed that logic 1 from the 'ABT74 was only making it up to about 3.2 volts. WDC's specs call for VDD × .7 logic 1 minimum at PHI2, which would be 3.5 volts in a 5 volt system. Best not to run on the ragged edge.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!