I'm working on a small, embedded microcontroller and I am trying to minimize the number of chips, so I was wondering if I could just use ROM, i.e. a RAMless machine.

I figure it would work okay as long as I didn't use interrupts or JSR or the stack, what do yall think?

I really doubt this would be usable except for a toy program. You'd have extremely little state to work with, with several restrictions. You get 32 bits of general-purpose bits from A, X, Y, and S. The S (stack) register would be most useful for long-term state, since it's the least useful for general operations, though you can use it as a counter without much trouble:



I'd be interested in any stories of actual systems implemented on a RAM-less 6502. Slightly related, I was reading the PowerPC G3 documentation recently and noticed that you can lock the cache, effectively allowing you to store data and code in the cache as if were RAM, allowing external-RAM-less operation.

At the risk (RISC?) of sounding like a defector, all I can say is, "If only they made PowerPCs in 40-pin DIPs with simple to use, 8-bit or 16-bit bus interfaces..."

If the job is really so itty-bitty that you could go without RAM, you might as well use a PIC. Otherwise, you could use a 65c134 microcontroller, or use something like the 6532 RIOT (RAM, I/O, and Timer IC) if you can find one.

Oh yeah, if I can ever get this sucker into production I will definitely use a PIC, but right now all I've got in my toolchest is the trusty ol' 6502. I'm wiring it up right now, I'll post my results a little bit later tonight.

You can still use JSRs. First prepare a special part of the ROM filled with return addresses only. Before eexecuting the actual JSR, set the SP for the according address. The RTS at the end of the routine will fetch this return address from ROM and on goes the program again.

FYI, this is not my own idea, this trick is use by the BIOS of the IBM-XT before the RAM has been initialised.

_________________

This is pretty ugly, and is god-awful hard to precompute the list of return addresses, especially when you may not know a priori what order subroutines are going to be invoked (e.g., think event-driven hardware responding to interrupts, or polling for user input; there's no way to know in advance what inputs will occur, nor when).

The 65C02 uses the stack for return addresses, so you can't ever use JSRs.
It wont simply go to a certain place for the JSR return, it will push it onto the stack as a part of the way it does things.

If you want to seriously hit the chip count, I also vote for the 65C134 and just use an external ROM. It has built in:

192 bytes of RAM
4K library ROM
serial port
4 ports
tons of interrupt ports
network port
time of day clock

you can use a small Prom or CPLD to do the r/w qualifying and add in a 27C256 eprom for your program. That gives you a 3 chip set which is quite powerful.

I am working on a fun public development board for the 65C134, based on the first revision. I twill be out for sale when running and completed....watch this space.

_________________
"My biggest dream in life? Building black plywood Habitrails"

As Samuel said, it would be pretty ugly, but Ruud's suggestion would work for extremely limited applications. (Uglier things than this were common in the early days of computers when harware limitations were all the more cramping.) You'd have to have ROM in page 1, ie, the stack area. With a decent assembler, it shouldnt' be hard to compute the return addresses to put in the ROM in page 1. I'd use macros to automate some of it so the code isn't so unmanageable. It would still rule out interrupts, and it would take more time than just wire-wrapping another socket to add RAM. If room is the problem, maybe you can piggy-back the RAM on the ROM (or the ROM socket on the RAM). Most of the pins are the same, and for those that are not, you can bend them out and take wires from them to the appropriate places on the board.

Hi Everyone,

The person could use an FRAM from

http://www.ramtron.com/

This device is a "dream machine" for the original posters application. This is because it can function as a pseudo RAM and NVRAM at the same time.

Note, I haven't actually used one of these in practice, so be sure to read the data-sheets carefully.


Cheers,

Paul

DS1220. 6116 battery backed up, pins and acts liek the 6116.

_________________
"My biggest dream in life? Building black plywood Habitrails"

Well, it was a success; You can run the processor without RAM, it requires a lot of register juggling but yes, it does work.

My application just has to monitor serial port data and respond to a certain string, so I really didn't need any temporary storage since the data comes in byte by byte.

I used a 74hc259 latch to act as output ports, and I think it worked quite well. If anyone is interested in the schematic and code, shoot me a message.

[quote="kc5tjaThis is pretty ugly .... think event-driven hardware ...[/quote]

I never said it was going to be a beauty :) And you are absolutely right about events. But the originator of this thread didn't mentioning them.
The main question was: can it be done? The answer to this is: yes! If it is usable/workable, that is another matter.

_________________

Hallo Garth,



I disagree. Imagine a main loop that does nothing more then 'JMP *-3'. The interrupt occurs, the CPU writes the usual things to the stack (= ROM, does nothing happens actually), looks for the IRQ or NMI routine and executes it. And after the routine it starts doing that 'JMP *-3' routine again. Even no RTI needed.
In contrary to my previous answer, it seems that some event handling is possible indeed. Possible, but limited.

_________________

Post the code, please. I was still under the assumption that a JSR instruction would push the return address onto the stack, rendering it an impossible instruction to use.

A calculated jump table I CAN see using jmps to do the return, a quasi JSR setup. But using actual JSRs I simply cannot.

_________________
"My biggest dream in life? Building black plywood Habitrails"