And you can even reuse (most of) the other RC2014 modules/boards.

So if you have been looking at the RC2014 community from the outside and don't want to learn Z80 programming (and hardware), but like the idea of a modular approach to building retro hardware, I have just what you are looking for:



A couple of articles in my blog (http://ancientcomputing.blogspot.com/) describes in some detail the hardware design and what RC2014 modules work with the 6502.

An initial Monitor/Debugger is available. It's based on the lite version Daryl's monitor but heavily modified so that the user interface is similar to my Monitor/Debugger for the Z80 on the RC2014. Many thanks to Daryl for making his code available.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

Ooh! I think I have a new project for the next time I have some spare change...

There was a small mistake in the Readme.md in the schematics directory on your Github repo: Pin 1 of the 65(C)02 should be grounded UNLESS you're using a WDC chip, not IF you're using a WDC chip. The picture above is wrong too: it should have JP1 in place with a Rockwell 65C02 mounted. I filed a pull-request in Github to fix the documentation.

Great project! I was thinking of designing something similar (and I was going to name it "RC1402", feel free to use that ). Are you considering making this available as a kit? I might be interesting in buying one.

===Jac

Thanks for the correction, Jac. 've fixed the documentation. You're the first contributor!

To be honest, I had no problem using the board with pin 1 disconnected. I'd tested out with a CMD and a Rockwell 65C02, and also a Synertek 6502 at frequencies from 1MHz to 3.072MHz.

That's probably why WDC felt that they could "reuse" the pin: leaving it disconnected with the older 65x02 didn't result in anything bad...

Regarding making it available as a kit: absolutely no plans. This is to avoid any appearance of conflict of interest with the day-job. However, nothing prevents anyone else from doing so.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

Yeah, the pin is probably just connected to the substrate, just like pin 21. I don't know much about CMOS vs. NMOS properties but I have a feeling that it was probably more important on NMOS chips to keep the voltages stable all across the chip. NMOS needed more current (so more voltage drop, I reckon) and I'm pretty sure early chips were made bigger than they are now, too.

Either way, your mileage may vary so pin 1 should be connected on non-WDC chips and (because it's an output) should be disconnected on WDC chips.



Understood. Thanks for posting the project anyway!

===Jac

As long as there's an easier way to get the PCB than trying to do home etching with a photocopier, I think we can cope

Quick update for those who don't frequent the EhBASIC list.

I've put together a port of EhBASIC (https://github.com/ancientcomputing/rc2014/tree/master/source/6502/ehbasic). It runs combined with the Monitor with the latter providing the "BIOS". There is are COLD and WARM start entry points and a SYS BASIC command brings you back to the Monitor.

The Monitor itself includes a tweak to Daryl's original breakpoint code to allow a resume from breakpoint. It's a good way to "step" through parts of your code without having to re-assemble and upload.

I've an initial build of MS BASIC from Michael Steil's article (http://www.pagetable.com/?p=46) which I'll share soon. Interestingly enough, MS BASIC is slower than EhBASIC (the latter is really enhanced!) running a prime number benchmark.

Finally, I've an RC2014 6522 board out for manufacture with OSH Park. I'll put together a 6532 board soon and am thinking of doing a SYM-1-ish system built around the RC2014 bus and associated boards. The I/O addresses will not match but with the original source code, I might be able to get both the SYM-1 monitor and BASIC working.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

I'm not an expert on either of them, but I got the general impression that they were more similar than different in the way they stored and interpreted code. I believe that EhBASIC uses 32-bit floats, and MS BASIC uses 32-bit or 40-bit floats, depending on the way you build it. Is it possible that you're comparing EhBASIC to a 40-bit build of MS BASIC?

Mike B.

Very nice...

Good point. I've actually compared both builds of MS BASIC with different options for CONFIG_SMALL. The 9 digit version is quite a bit slower than EhBASIC. The 6 digit version is more in the ballpark but still a little slower than EhBASIC.

I'm finishing up the porting work (my fork is in GitHub: https://github.com/ancientcomputing/msbasic) and will rerun the benchmarks.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

I'm beginning to look at doing this now that I'll have a little spare change pretty soon. My question is this: I don't have any particular interest in the Z80 RC2014 kit, and it looks like the 6502 board does its own clock generation. I'd also look at using your 16550 UART board since I have a couple of those laying around, and those use their own crystals for the baud rate clock, correct? Given that, I shouldn't need the RC2014 reset/clock board, Z80 board, or serial board. If I build my own RAM/ROM board (as I'm planning to do,) I should only need to order the backplane kit and some prototype boards from the RC2014 shop, correct?

(Also, have you run this at higher clock rates? Any idea what the highest stable frequency for it is?)

At the min, you'll want the backplane. I use the 5-slot. You're correct that you don't need the Z80 CPU & clock boards. Yes, I run a 1.8432MHz osc with my 16550 board separately from the CPU clock. I haven't implemented UART interrupts/buffer and am using a 16C550 with the autoflow control to keep things sane...

If you are building your own RAM/ROM, be sure to set the A15 jumper correctly. In position 2-3, it's set up to flip the Z80 address space around to get ROM in upper memory and RAM in lower. So if you doing RAM/ROM the 6502 way, the set the A15 jumper to 1-2. If you're like me (i.e. too lazy to wirewrap/point-to-point), you may want to consider the RC2014 32KB RAM and default Switchable ROM board. The former works without changes (A15 jumper at 2-3) and there're instructions to mod the ROM board on my blog.


I've run it at 4MHz max at the moment. I've run a Z80 at 20MHz in the same environment (using my own Z80 CPU+ board). My limitation is the 150ns 28C256 EEPROM that I use. When I'm bored this coming long weekend, I'll probably swap in a 14MHz WDC chip and try with an EPROM with different oscillators

BTW for those interested, I've put my spare boards for sale on Tindie. Search for rc2014 and 6502.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

Yeah, I could use the standard RAM & ROM boards, but I really don't care for the 32KB/32KB split everybody defaults to; I'd rather try for something closer to 48KB or 56KB RAM. But I'm gonna have to give that a think and run some possible approaches by the folks here who know more about it. Though it helps at least that the CPU board already handles carving out a chunk for I/O ports!

If you are just running a basic program loader or a Monitor, you can go as high as 62KB of RAM minus the i/o space.

If you want to include a variant of BASIC plus the Monitor or just BIOS, you might be able to get 56KB of RAM. Some variants of MS BASIC build to 8KB. I found that with EhBASIC, you'll need more ROM space e.g. 12KB if you include a monitor.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

Yeah...the aim is to build a basic ROM Forth learning system, so I need to poke around some of the 6502 variants and see if it looks like something you can pull off in 8KB ROM or if it's going to need 16KB...