Picaxe programmable RAM?

Minifig666

Senior Member
Hello again,
Today I am looking for a RAM chip for my upcoming TTL computer. It will be for program storage. I am looking for a chip that I can program with a PICAXE, probably a 18M.
I want to use a PICAXE to interface the RAM to save me the laborious task of hand programming.
I've been having trouble finding an 8-Bit wide serial RAM. The size is not too important, 64 lines would be the smallest I could do, 128 would be better.
I must admit that I aren't fully clued up on the topic and I'm lost as to whether an EEPROM would be better.
Thanks in advance, Minifig666 ;)
 

MartinM57

Moderator
RAM will lose all its data when you turn the power off.

EEPROM will keep its data when you turn the power off.

FRAM will keep its data when you turn the power off - but is probably overkill for what you want...

...but which type do you want?
 
Last edited:

Minifig666

Senior Member
RAM will lose all its data when you turn the power off.

EEPROM will keep its data when you turn the power off.

FRAM will keep its data when you turn the power off - but is probbaly overkill for what you want...

...but which type do you want?
EEPROM would be nice, but not vital. I'm on a bit of a budget (I realise its not going to be cheap for the whole thing) so the more I can get for less the better.
As I say the programs will be saved on my PC, so, unless it is cheaper, I'll stick to RAM.

Scratch that, I forgot the one I linked was an EEPROM, at that price, if it looks ok for my ideas, I'll stick to that!
 
Last edited:

MartinM57

Moderator
If you're going to program RAM with a PICAXE then how will you then connect the RAM to the TTL computer without it losing it's data? (answer - use dual port RAM - even more expensive)

If you're going to program EEPROM with a PICAXE then you can just pull it out of the PIAXE circuit and plug it into the TTL computer - which will also be a hassle after you done it for the first 5 times...

EDIT - I wonder if you could simulate parallel RAM or EEPROM with a suitable PICAXE. I'm sure you could, if you could put up with the delay in reading/writing compared to a real RAM/EEPROM chip...then you can change the contents (if its EEPROM you want) by programming it through the programming circuit and have it connected to the TTL computer at the same time. Sorted..
 
Last edited:

Minifig666

Senior Member
If you're going to program RAM with a PICAXE then how will you then connect the RAM to the TTL computer without it losing it's data? (answer - use dual port RAM - even more expensive)

If you're going to program EEPROM with a PICAXE then you can just pull it out of the PIAXE circuit and plug it into the TTL computer - which will also be a hassle after you done it for the first 5 times...

EDIT - I wonder if you could simulate parallel RAM or EEPROM with a suitable PICAXE. I'm sure you could, if you could put up with the delay in reading/writing compared to a real RAM/EEPROM chip...then you can change the contents (if its EEPROM you want) by programming it through the programming circuit and have it connected to the TTL computer at the same time. Sorted..
Actually that's not a half bad idea. However I still want to be able to address it as normal RAM/EEPROM and then by the time I've made a address decoding program would I have enough space left to store the program? I'm not sure how much space a program like that would take. Any guesses?

My idea if I was to use RAM was that I would use a row of buffers to connect the I/O pins to the right place so it wouldn't have to come out of the board.
 

Minifig666

Senior Member
Store it in a (cheap, serial e,g, 24LC256 or whatever they're called) EEPROM :D
Cheap is without a doubt the right word, 40p for 8K*8 (24LC64-I/P) :eek: but then the PICAXE is not so cheap, and I can't find them on Digi-Key where really I wanted to get everything to save on shipping. :( (cheap old me!)

I might have to look through my box-of-tricks to see what I can find, a 28X-1 seems overkill to me!
 

Minifig666

Senior Member
Oh, and one other question; construction technique!
I do have some blank doube sided PCBs laying around and some FeCl3 crystals int' box-o'-tricks but I have never used it before! I'm guessing double sided wouldn't be advisable for first time attempts at the toner transfer method?
Wire wrap would mean investing in wire wrap tools and probably be a pain to debug.
Soldering to matrix board was my first idea but might take up too much space.
My final (worst?) idea was to persuade my electronics teacher to be kind and donate some of his protoblocks.
 

westaust55

Moderator
Hello again,
Today I am looking for a RAM chip for my upcoming TTL computer. It will be for program storage. I am looking for a chip that I can program with a PICAXE, probably a 18M.
While you indicate a possible use of an 18M, if you do consider an 18M2 instead, notwithstanding greater onboard memory then i2c comms is available for chips such as the 24LC256. (basic "M" series chips do not have i2c)

Another possibility with i2c capability is a DS1307 real time clock in which case you ALSO get 56 bytes of battery backed RAM to store data.
 

Minifig666

Senior Member
While you indicate a possible use of an 18M, if you do consider an 18M2 instead, notwithstanding greater onboard memory then i2c comms is available for chips such as the 24LC256. (basic "M" series chips do not have i2c)

Another possibility with i2c capability is a DS1307 real time clock in which case you ALSO get 56 bytes of battery backed RAM to store data.
Again, a good point, however at £5.49 total it is a bit more costly than the £2.97 of the EEPROM I mentioned itself.
 

westaust55

Moderator
Again, a good point, however at £5.49 total it is a bit more costly than the £2.97 of the EEPROM I mentioned itself.
Maybe true wrt cost,
but unless you (effectively) spend more on the M2, X1 or X2 PICAXE parts with only 126 bytes of program space in an 18M you are not realistically going to communicate with any i2c part such as the 24LC256 or DS1307, etc.

bit-bang type i2c code in a M part takes about 90 bytes of program space (based on hippys past work) so leaves roughly only 160 bytes for the rest of your PICAXE program.
 

BeanieBots

Moderator
Maybe you should tell us more about this "TTL Computer".
Will it be able to use I2C type RAM?

I might be completely wrong but I'm picturing something that might be a lot easier to implement using static RAM which employs full data, address and control lines.
 

Minifig666

Senior Member
No, It won't wont be able to communicate through I2C without loading a program first. Currently it is still in design but it will be a 16-Bit CPU with 10 registers.
The 18M was an example. I will be using a 28X1 I never got round to using as a programmer. The outputs will be used for the data and the C outputs for the addresses. As soon as I have all the schematics I might put them up here.
 

BeanieBots

Moderator
So, you'll be wanting 16-bit RAM as well then? (for speed and ease of addressing).
Maybe two static RAM chips with their address lines paralleled together.
I'm still a little confused over the architecture so I'll wait for the schematics to appear.
 

Minifig666

Senior Member
No, it is the RAM for saving the program that I've been talking about, not the data. It only uses an 8-Bit instruction set.
The schematics may be a while as I only started them today. I've just finished the boring ALU. Now for something more 'fun'!
 

BeanieBots

Moderator
Data or program, I don't see the difference.
Doesn't matter if you don't have a detailed schematic, just post a diagram of the overall architecture. I'm even more confused now:confused:
 

Minifig666

Senior Member
I'll have an architecture diagram up tomorrow. Could you tell me what you are lost on and I'll try and help. Often I don't explain things as I should.
 

BeanieBots

Moderator
I'm lost over the interaction between your (assumed to be home-brew using TTL) CPU, RAM and the PICAXE. How YOUR CPU will read & address the "RAM" and exactly what part the PICAXE plays in being able to do ANYTHING with said "RAM" rather what your CPU might need it for.
I'm sure a simple sketch will make it all more obvious.
 

Minifig666

Senior Member
The PICAXE is only there to let me program the EEPROM that holds the program for the CPU to run. At no point does the PICAXE interface with the CPU itself. The program is entered byte by byte into the RAM by the PICAXE, emulating the manual inputs.

Allthough it isn't really important:
The CPU itself addresses and reads the RAM as follows:
Each time the clock pulses it increments a binary counter.
This counter is connected to the address pins of the EEPROM.
When the address moves on one the data in that address is sent to the program control.
The command is interpreted by the Program Control and the command is executed.

I would do a architectue diagram if I could but at the moment I can't because doing it on an iPod would be a bit tough. I appologise for my lack of explanation/uselessness at explaining.
 

BeanieBots

Moderator
It sounds like what I first thought you meant. It was all the talk of EEPROM normally associated with PICAXE apps (namely I2C) that threw me.
So, you really DO need the classic type of static RAM (or EEPROM) with full independant address and data lines.

Unfortunatley I can't remember the part number but there is (or used to be) a RAM version of the classic 2764 EPROM which even has a built in battery for data retention. I know I've still got a few floating around from my Z80 days so I'll and find one and get the number for you.

It should be simple enough to make the busses and controls tri-state so that the PICAXE can take control and pre-load the RAM.
 

westaust55

Moderator
Another RAM option but no in-built battery is the MCM6810 (if it can still be bought), which is 128 bytes of 8-bit static RAM.
Has 7 address and 6 chip select lines.
This sort of thing is going to need at least a 28X1 to provide:
(1) 8 bits parallel data bus
(2) 7-bits parallela ddress bus
(3) from 1 to 6 chip select lines.
So at least 2 full PICAXE ports required as a minimum.
 

kranenborg

Senior Member
Hello Minifig,

I have got a number of Cypress CY62256 32Kb x 8 RAMs in a 600-mil wide DIP (CMOS, 4.5V minimum Vcc, read/write cycle time: 70ns, full device code: CY62256NLL-70PXC), and I could miss one. Since we both appear to live in Europe, postal costs will be negligible for just one device and could be skipped. If you are interested, please send me a PM,

/Jurjen
 

Minifig666

Senior Member
Hi,

I think the chips you refer to were the 6262LP or the 62256

Regards....john
Thanks for the links john! The 62256 looks like the right sort of thing.
@Westaust55 The MCM6810 is on sale at LittleDiode for £15! :eek:
@BeanieBots The talk of I²C was that of using a PICAXE to emulate a parallel RAM from one of the cheap I²C EEPROMS, yeah...
@kranenborg Thanks for the very kind offer, after I get the plans done I might have to get in touch. I don't yet know how much all this is going to cost, with the relay adder/subtracter (4-Bit) nearing completion I might have to save up first!
 

Minifig666

Senior Member
Oh, and here is the long awaited basic architecture.
I decided to name it 'Cream Dragon' after the Dragon 32 that I just happened to have in front of me when I decided it needed a name.

If or when it happens I will probably make a VLOG, I will probably post here or on a new thread if I do!
 

Attachments

moxhamj

New Member
I'm playing around with this sort of thing at the moment. You might not need an external eeprom. It depends where you store the program/data - SD cards are by far the cheapest now in terms of cost per byte.

To manually load data into a ram, you can use latches (HC595 or HC374) and then you need to tristate the latches to allow the computer to run. And you need some control lines, eg /RD and /WR and /RESET etc.

Where is the program going to be stored - in a picaxe, eeprom or somewhere else?
 

hippy

Ex-Staff (retired)
I occasionally revisit my dream of building my own computer from logic gates but nothing ever comes of it as it's not high on my priority list, however the issue of 'download programming' is something I considered.

My approach was similar to what seems to being discussed here; have the TTL-CPU use only SRAM, no flash or Eeprom. Only at boot time is there an issue of getting something into SRAM which the TTL-CPU can then run. This was called Initial Program Load (IPL) on old mainframes which worked in the same way and some FPGA also work in a similar fashion.

I imagined a separate sub-system with a PICAXE which could hold the TTL-CPU in Reset, SRAM buses tri-stated, and then copy its own memory or from Eeprom into SRAM having taken control of the SRAM bus. When it's done, the PICAXE relinquishes control of the SRAM Bus, releases the TTL-CPU from Reset and sits back, plays no further part in things.

It's a very simple design and should be easily implemented with a PICAXE with enough I/O and ability to tri-state itself off the bus; 40X2 comes to mind. The PICAXE and TTL-CPU are completely separate bar reset control and the SRAM shared between the two. Use of tri-state avoids the need for multiplexing the SRAM Bus.

The PICAXE side of things could even be used with commercial systems, Home Computers, C64, VIC20, BBC micro, Dragon etc. Replace the ROM with SRAM, connect the PICAXE up as above. As long as the micro can be held in reset and that tri-states the bus the system works as above. Load SRAM where ROM was and let the micro out of reset.

It could be done with one of those 'DIL test clips' mentioned elsewhere, simply clip it onto the original micro.
 

BeanieBots

Moderator
Thanks john hauton, it was indeed the 62XXX series of chips that I was referring to for RAM. Same pinout as the infamous 27XXX EEPROM series. However, the battery backed version (which I now have in my hand) is marked:-
MK48Z02B-25
I think it's a 16k device similar to the classic 2716 but my (and probably its) memory has faded now. I bought it back in the 80's but never used it as I opted for the 62XXX series with external battery.
 

Minifig666

Senior Member
I'm playing around with this sort of thing at the moment. You might not need an external eeprom. It depends where you store the program/data - SD cards are by far the cheapest now in terms of cost per byte.

To manually load data into a ram, you can use latches (HC595 or HC374) and then you need to tristate the latches to allow the computer to run. And you need some control lines, eg /RD and /WR and /RESET etc.

Where is the program going to be stored - in a picaxe, eeprom or somewhere else?
The SD card idea is a good one, however I don't think that I would ever need that sort of memory! Really I don't want a PICAXE having a role int' CPU other than for programming, it detracts from the magic.

I'm confused by your last question. Do you mean the program for the CPU itself, or the program the PICAXE will use to program the program memory with the program for the CPU... wait what? :p
The program memory for the CPU is currently a 62256 battery backed RAM.
The program the PICAXE will use to program the program memory with the program for the CPU will be stored on the PICAXE itself. Eventually I might move on to paper tape.
 

Minifig666

Senior Member
Oh dear, another technical hitch... I think!
Because I've decided to use a 4-Bit address for the registers in order to use move commands I need 10-Bits for the instructions!
If I cut back the 3-Bit I could fit it all the instructions but then I only have 2 registers, not enough.
Even if I moved up to 16-Bit I still can't have a command that lets me put data into the registers.
I imagine there will be a way around my problem but I can't quite think of it. I have attached a .txt file with my instruction set in it.
 

Attachments

MartinM57

Moderator
Not been following this since yesterday - but intrigued how you derived your instruction set. I guess (and I don't know) that an instruction set should be the most primitive operations that can provide the operations to run a useful CPU
- so AND/NAND, OR/NOR and NOR/XNOR are a total of 6 instructions but AND/OR/XOR/NOT are just a total of 4 but allow all 6 to be done (I think the term is orthogonality, but I can't remember that far back to my lectures;))
- most CPUs have flags (overflow, zero etc) and branch to address instructions based on them, allowing conditional statements to alter program flow. Your instruction set seems to only allow linear program flow (despite the "goto") which must limit teh programs you can run.

Just an observation really....
 

Minifig666

Senior Member
The use of all the commands just for convenience, there was space left so I thought I'd use it. This is a massive learning curve for me. What do you mean by flags? Any extra info would be greatly appreciated.
 

moxhamj

New Member
What hippy has described is exactly what I am building at the moment. I'd add just one more thing to hippy's description, and that is to trap input and output calls. These flip a latch which then sends a WAIT to the CPU, and then the controlling chip can take over the clock and clock in or out the data at a slower speed.

I like playing around with discrete logic.

Re The program memory for the CPU is currently a 62256 battery backed RAM.
The program the PICAXE will use to program the program memory with the program for the CPU will be stored on the PICAXE itself. Eventually I might move on to paper tape.


If you have a 62256 then presumably you have up to 32k of program space? So where does that ultimately come from? A PC via a serial port? From a picaxe?

I've built circuits using battery backed ram and they do work well but eventually you might want to store a program somewhere more permanent. Paper tape sounds authentically retro!

A serial port will be handy and the picaxe could do that, and that could be a way of sending programs to and from a PC.
 

hippy

Ex-Staff (retired)
Oh dear, another technical hitch... I think!
Because I've decided to use a 4-Bit address for the registers in order to use move commands I need 10-Bits for the instructions! If I cut back the 3-Bit I could fit it all the instructions but then I only have 2 registers, not enough.
Welcome to the world of instruction set design :)

I dread to think how long I've spent trying to optimise instruction set, especially to make the hardware simple. I'm currently at the simplest I think it can be, everything staged between a single working register, the actual instruction set being what used to be called micro code, basically just three instructions, "Copy Register X to W", "Copy W to Register X", "Move some-bits to a part of W". Even the most simplest 'high-level opcode' takes a long sequence of instructions. Running at 100GHz it shouldn't be a problem :)

High level "ADD A,B,C", A := B + C

W = <B>
MEMADR = W
W = MEMREAD
ALULHS = W
W = <C>
MEMADR = W
W = MEMREAD
ALURHS = W
W = <+>
ALUOP = W
W = <A>
MEMADR = W
W = ALURESULT
MEMWRITE = W
 

westaust55

Moderator
Okay although only a brief glance at your instruction set my initial thoughts are
- no subroutine call and return function That will also need some registers as a stack to function
- no status register for bits such as Carry (for over/under flow) or Zero (is result zero)
- no test function. You have a branch but what will instigate the branch?
If you do instigate a status register with a carry bit then consider rotated only through the carry as per PIC chips or both through and without the carry as per some other microporcessors.

overflow occurs when you add two numbers and the result exceeds the max value of the result register. then you get roll-over and the carry bit is the flag to indicate the overflow into next byte is required. Essential for working with multi byte/nybble value.
 
Last edited:

Minifig666

Senior Member
I've revised my instruction set and included it below. I've included the subroutine idea (But I'm still trying to decide whether to use it), and the goto conditions.
I've removed the excess commands (NOR, NAND, XNOR, Subtract) and added an increment command.
Most importantly I've managed to reduce it to 8-Bit.
I don't quite understand what you mean by the Carry and Zero tests. Mainly I'm lost as to whether it goes in the ALU or the branch logic. I can't see its use in the the ALU.

Hippy I must say I'm very impressed by that tiny instruction set, that's truly RISC!
 

Attachments

Top