The 6507 is a reduced capability CPU in the 6502 family. It has an 8K address space and has no interrupt inputs.

This project was completed about 2 years ago. It was undertaken at the request of a company that had a need for a small controller that could execute existing 6502 code and that had a pre-defined parallel control bus to attach the controller.

As a part of the process in creating this controller, I used Tom Pitman's Tiny Basic interpreter. This was basically a lost language, but Tom had an old HEX file intended for a KIM-1 computer which I disassembled and produced a assembly language source for it. Tom posted my first working version on his site www.ittybittycomputers.com. I have made a few improvements since then.

I used a 3 step process to test and improve the harware design.

Here is the Alpha prototype done on solder less breadboard:

Several changes were indicated by the Alpha, especially in the memory map decoding. It was also used to develop the console monitor and 'boot loader' (these are property of the client and will not be included). Once all that was sorted out, I moved on to a Beta prototype:

This was done on strip board using top-side point to point wiring. I find the top-side wiring allows for easier changes if they are required. In this phase we added and tested the connection bus. Due to testing in this phase resulted in changes to the bus driver chips. Several tests were made with the client's code and controlled devices using this board. Once the tests were signed off the final product was committed to copper:

The final product featured 2 ROM banks and 2 RAM banks each of 4K. This allowed the client to load two controller programs for testing and, if they choose to use NVRAM, they could save the test parameters and data.

The I/O space overlaps the first few bytes of the ROM.

It has a standard RS232 serial interface that can be used for control inputs or status outputs. If used with the Tiny Basic and terminal monitor, all programming can be done thorough the serial interface.

Here is a small jpeg of the schematic. I will try to produce a better one and update this post later along with the parts list.

And finally, the Tiny Basic source code is attached. This version has some sub-routines for timing and stepper motor control that can be called from Basic using the USR() function.

 

I belong to a newer generation and all that sounds a bit strange to me. Can you explain what is the purpose of that computer and give some examples of use, or maybe what the mentioned company needed it for?

 

Tthe predominant application was chemical mixers. There were other items too, but mostly mixers.

When I was first contacted about doing this I tried to get them to switch to a more modern alternative such as a PIC/AVR or PLC. They thought the PLC option was too expensive and they did not have any experience in ladder logic. They thought the MCU option would end up more expensive as they would need to get all the software re-written.

They opted for this project as they had existing code and spare interface cards that used the familiar bus. Go with the devil you know (cause he's cheap).

Most of the electronics was destroyed when a switch gear in their power sub-station failed and caused a transformer to go in a spectacular fashion. The original manufacturer was no longer in business. So, they ordered 30 of these off me at a cost of $300 each. 12 were needed as to replace the ones that got destroyed, 18 were spares. Build price was about $35 a piece. The total bill was about $10,000. My next cheapest estimate (PIC/AVR) was $17,000 and the PLC option was about $25,000 as I needed to hire in someone that had enough experience with ladder logic to re-do all their little processes.

Don't let the Tiny Basic throw you off. That was merely for my purposes. Just a way for me to test things out as I went along. They did not use Tiny Basic. Their code was all machine language, developed on a PC using a 6502 cross assembler. Something they were familiar and comfortable with.

Does that cover your query?

 

Something I might be interested in. I was into Commodores deep when they were king, I've written a few machine level programs. It is an excellent beginner code, 6502 assembly did not evolve like the 8080 and beyond, but was written from scratch. It is possible to figure out commands in 6502 because they relate to their neighbors in a very logical way, as opposed to having command op codes stuck in a slot because the slot was empty.

8K seems a bit small, but assembly is pretty tight. I've seen decent chess games written in that size.

I can't see it on the schematic, are there any 6526 CIA chips?

 

There is a 6551 ACIA for serial com.

You could easily use a full 6502 and add the requisite decode logic Then you'd have a full 64K space except what's used for I/O. Actually I have a decode circuit for a personal project that provides the followoing memory map:

0x0000 - 0x7FFF - RAM
0x8000 - 0xEFFF - ROM
0xF000 - 0xF7FF - I/O in eight 256 byte blocks
0xF800 - 0xFFFF - ROM

It was originally designed to run the UK101 / OSI firmware with the OSI CEGMON monitor and Microsoft's 8K basic. I have now also ported Lee Davidson's EhBASIC (enhanced Basic) to it. It might be of more interest to you. Just as easy to build.

 

Nice work keep it up...............

 

You answered my question, yes, but you raised another:

I understand that the developing cost of that circuit might justify its price. It has ample wiring and needs a lot of testing before put into action.

But why is the PIC solution more expensive? Does it require more hardware? I imagine that the PIC solution would be more compact and easier to debug. Or is it the writing of the code anew the costly factor?

 

I heard this was a preference of managers. Knowing the managers I've worked for over the years this pretty much explains everything.

A PIC would have been a lot cheaper, but if they want something else and are paying the bills...

Maybe they liked the Commodore (or early Apple) too?

 

You answered my question, yes, but you raised another:

I understand that the developing cost of that circuit might justify its price. It has ample wiring and needs a lot of testing before put into action.

But why is the PIC solution more expensive? Does it require more hardware? I imagine that the PIC solution would be more compact and easier to debug. Or is it the writing of the code anew the costly factor?

There is a lot to what Bill Marsden said here. I got the impression they just did not want to change. The MCU option had in it the re-design of the interface cards as well as the programming time. The interface cards were simple relay drivers and optically isolated switch inputs and the associated latches and line drivers. But they operated on the old bus which was not ideal for the modern MCU paradigm. During the initial consultation I advised them that we could program the MCU to work with the old bus, but it would be a little less than ideal. So they said something to the effect of 'If we move ahead, we do it right'. It also would require a change to the support process and infrastructure. Change is scary.

Not that any of this has anything to do with the little computer, but you ask, I answer.

BTW, there were other anomalies with this project. The monies to pay for it came form their capital investment budget, so I had to roll all my consulting time into the cost of any hardware. The things we do to live.

Wait until you get out there in the working world my young friend. You will see things you never imagined.

 

Heh, I can't wait (I think).

Thanks for your time.