I took a quick look at the price of CPLD's and RAM with the following results:
A CPLD with 48 I/O's costs less than $10.00. A 1/2/4 meg RAM (128K/256K/512Kx8) costs less than $5.00.
With that CPLD and RAM we should be able to build a memory board that uses 12 pins to access 128/256/512KB of ram and speed up emulation.
The CPLD would implement the following commands:
Load 8 bits from Prop to address register low byte.
Load 8 bits from Prop to address register mid byte.
Load 8 bits from Prop to address register high byte.
Load 8 bits from Prop to data register low byte.
Load 8 bits from Prop to data register mid byte.
Load 8 bits from Prop to data register high byte.
Increment address counter.
Increment data counter.
Read instruction from RAM to Prop.
Write instruction from Prop to RAM.
Read data from RAM to Prop.
Write data from Prop to RAM.
Indeed, and Leon is putting together a Prop/CPLD/RAM board http://forums.parallax.com/showthread.php?p=755070 that can be used exactly so. I like this idea of having a "program counter" register out there to step through code at speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Glad you liked the idea. There is also a data register/counter out there to help with moving data to/from ram without affecting the program counter. I am also thinking it might be worth having decrement commands for them as well. The more I think about it, the more uses I come up with for this board. Emulator (8080, 6502, 6800, bytecode, etc.), temporary data storage/buffer, add a battery and it is a data logger, etc.
The CPLD brings some potential. It should also include some read-next address with a toggle of the RD line, that will speed multi byte transfers. For the record the HP-71B memory modules have 2 pointers, one for program and one for data, and a 4 bit bus (it is a 4 bit processor after all, with 64-bit registers). One sync line, one data transfer line and 4 bidi data bits. Expanding that to 8 or 16 can bring throughput to higher and usable levels.
The 573+SRAM is faster to build. The CPLD board is not going to be with us for some time, though.
I like the idea of a register-based architecture. You could make the CPLD with 4 registers, each 3 bytes. You'd need a command strobe, a read-data strobe, and a write-data strobe plus an 8 bit data bus. The command would include the register number (0-3), a number for the sub-byte (0-2), one bit for post-increment, and one for post-decrement. If the sub-byte is 3, subsequent read/write strobes refer to the SRAM data. There's no great need to be able to read the registers, but this makes things symmetric.
Got the 24K CP/M running fine! Super duper great work there, my compliments. I am impressed.
Adding memory is indeed a big topic.
Sounds like a XILINX 9536 PLCC 44 will do the job. I once offloaded an entire 24x80 video sequencer·and some cursor registers into an XILINX 9572 PLCC 84, and this had to arbit access to the Video RAM in a similar fashion. But a 9536 PLCC is small and easy to use.
But I moved back to my original project, which also includes a propeller chip:
If you will have a look at http://projects.steamboat.de/html/ez80.html, you will see my approach to run CP/M on an eZ80 based system - I was planning to handle VT100 type output using a propeller as a video controller instead of the original idea of a dedicated XILINX 9572, which I decided to ditch even though it was completed and worked.
I then noticed the new N8VEM project - looks real nice - but I am still muddling along trying to put an ez80 (48MHz), 512K RAM, a boot flash, a PROPPELLER on a EURO-BOARD and this would have a SD-Card that contains YAZE-HD-Disks, a VGA connector and a PS/2 KBD connector. I'm very close to achieving that by now.
The base CP/M system would also be loaded from the SD-Card, so as to minimise the amount of flash needed.
Current project is loading the Propeller directly from the ez80 (see the 3-4 threads here about how to do that from various non-PC sources), and putting together VT100 or VT52 support (probably not needs to be totally complete) for the propeller (for wordstar, turbo-pascal and whatnot).
Mike, I really like your idea. I was only looking at it from the point of adding more memory for CPM and possibly speeding things up a little without using too many I/O pins. Didn't think of using the 8 bit data bus for commands. I looked at the Xilink xpla3 series just to be sure there was enough I/O and logic to do it.
Maybe we could all work together to come up with a usable design that meets a variety of needs.
I have not done any work with CPLD's for a while so I am not all that familiar with what is available. Any experts out there willing to help with that part of it?
FanDjango: That's great to hear. I have not had many reports of people actually running this thing.
Everyone: Isn't what we need here a "standard" board design like the Prop Demo board but with a bucket of RAM and a little CPLD. Such that RAM hungry objects can be shared with an expectation that people will have the possibility to run and check them.
The nice thing about a CPLD/RAM design is that you can get back the I/O that lost by connecting it in the first place.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Question, why does it require it's own SD card (at least the first MB) instead of
being able to simply run as a file anywhere on the SD with everything else jammed
in there?
It looks like we are already extremely close to being able to do coding on this.
Is there a smaller editor which fits into the 24K limitation or will MBASIC work?
- If you use a CPLD for connecting the RAM, why not take an FPGA instead and do the 8080 Emulation in the FPGA and not the Propeller (there are still proven 8080/Z80 designs on Opencore.org) !
But then I thinked twice:
- Such a chip with an 8080/Z80 CPU and RAM controller still exists, and in DIL 40, easy to handel: An original Z80 !
So why the complicated way with a 100 pin CPLD or FPGA, if you can have it 100% original, in much easier to handle chip, which is also cheaper (around 3$) ?
So I came to a possible design, attached as block diagram. It is inspired by the 6502 Laptop from Dennis Ferron:
- The Propeller can control the Databus and some Control lines of the Z80. This allows to fill the RAM with a Boot code (using the Z80 as address counter), and then start the Z80.
- Then the Propeller can be a Peripheral Device (or better some Devices) and a Terminal.
It's only a basic idea, and not considerated exactly, so far
Uses 12 lines. The HCT chips are 40c each from futurlec. The RAM is $2.90 BUT that is a 5V ram. 3V ones do exist but are not quite as common. I'm not sure about the cost effectiveness of a 5V ram with level shifting vs a 3V one. Regardless of CPLD and other solutions that issue needs to be considered.
This circuit only uses half a 128k! But with another 373 and one extra line you can decode A16.
I haven't checked other suppliers but futurlec has the same price for 32k vs 128k so one 128k is probably better than two 32ks.
Going off on some other tangents, old school dynamic rams use 18 lines. But they are very cheap. ? 5V only. Constant refresh so need a dedicated cog. Overall, probably not a good solution.
You will need data level translation in there, but leaving that aside for the moment, I'm looking at my working N8VEM board and seeing what all the chips do:
EPROM - for the bootloader and CP/M. That can go off into the SD card.
UART - that can go off into the propeller
8255 - that is mainly being used to control the keyboard and LCD display - replaced by the PS/2 keyboard and the VGA.
2 HC273, 3 HC32, HC10, HC04, HC139 - all glue logic that can be in software in the propeller
UART clock and Z80 clock - that can be from the propeller
Big 512k ram chip - a combo of working ram and a disk drive. That can be a cheaper 128k.
DS1210 ram backup chip - replaced with SD card.
The ram can be filled up and the Z80 can be given a reset and go off and happily run the program in ram. Z80 chip is $1.70 to $2.90 at futurlec.
When the Z80 wants some more data, ie a "disk" read, the BDOS could be modified so this sends/receives an IORQ line in combination with a known address.
Similarly, an IORQ In or OUT (eg to send a byte to the display) would be trapped by the propeller.
The hard bit would be writing the custom disk I/O. That is the bit that takes time.
I'm not sure how level translation works, especially on bidirectional lines?
OBC - that chip looks great. The thread was last year - has the price come down? (there was mention on the thread of a minimum of 100).
Post Edited (Dr_Acula (James Moxham)) : 1/3/2009 1:23:05 AM GMT
A couple of reasons for the way SD card is handled:
1. What I want is a CP/M file system not an MSDOS file system.
2. Code space, all that FAT code has to live some where and the current implementation needs all the HUB RAM it can get.
3. Speed, all that FAT stuff must take time.
OK that's three reasons [noparse]:)[/noparse] I know it's a pain for anyone who just wants to quickly try it out but there we go.
I haven't found a small editor yet, not that I've been looking very hard.
Sadly mbasic bombs out with "bad load" with only 24K.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The simplest bidirectional Level shifter is just a 1k Ohm resistor between the Prop and every line of the Databus. These 8 resistors also protect the Z80 and the Propeller if they try to write accidentally at the same time.
I think heaters emulation must still have a way to use the SD card as disk. I can't say if this is easy to adapt, because my knowledge about CP/M is nearly zero.
What it does is to simply put eight CP/M floppy disk images consecutively on the SD card. Eventually I'll get round to adding the hard disk images. There is no FAT layer used, just writing CP/M disk sectors to blocks on the SD card.
For the floppies each sector, slightly over 130 bytes, is written to the beginning of a 512 byte SD card block. Wastes a bit of space. For hard drives 512 byte sectors would be used.
Now I think what your post is getting at is reading/Writing that mess as single file from a PC. I have not tried it but under Linux it should be possible to use the "dd" command to read raw data off the card and dump it into a file or vice versa. Under Windows I have no idea.
So it should be possible to format CP/M and load up disk images under the SIMH emulator. Concatenate the resulting files, with appropriate padding of the sectors and dd them onto an SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@OBC, The N256S0830HDA SPI SRAM looks great. The code seems to be geared up for reading/writing blocks at high speed is it going to work out for the byte read/writes of random locations the emulator requires ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Since the idea of an external cpld/ram combo to assist with the emulator went over well I roughed out a block diagram of a system that uses a minimum number of prop pins.
I also looked at Leons Prop-CPLD board and I think we can combine the two projects or at least have only one board.
The prop-cpld signals would consist of an 8 bit bidirectional data bus, a command/I/O signal, a read strobe, and a write strobe.
The command signal would read/write the command register when true. When false it would perform the I/O command specified by the command register.
The functions of the command register are below.
Bit 4-5 00 No change
01 Post increment * Increments selected Address register or bits 2-3 of command register
10 Post decrement * Decrements selected Address register or bits 2-3 of command register
11 No change
Ariba said...
First thought, when I read the last posts:
- If you use a CPLD for connecting the RAM, why not take an FPGA instead and do the 8080 Emulation in the FPGA and not the Propeller (there are still proven 8080/Z80 designs on Opencore.org) !
But then I thinked twice:
- Such a chip with an 8080/Z80 CPU and RAM controller still exists, and in DIL 40, easy to handel: An original Z80 !
So why the complicated way with a 100 pin CPLD or FPGA, if you can have it 100% original, in much easier to handle chip, which is also cheaper (around 3$) ?
So I came to a possible design, attached as block diagram. It is inspired by the 6502 Laptop from Dennis Ferron:
- The Propeller can control the Databus and some Control lines of the Z80. This allows to fill the RAM with a Boot code (using the Z80 as address counter), and then start the Z80.
- Then the Propeller can be a Peripheral Device (or better some Devices) and a Terminal.
It's only a basic idea, and not considerated exactly, so far
The simplest bidirectional Level shifter is just a 1k Ohm resistor between the Prop and every line of the Databus. These 8 resistors also protect the Z80 and the Propeller if they try to write accidentally at the same time.
I think heaters emulation must still have a way to use the SD card as disk. I can't say if this is easy to adapt, because my knowledge about CP/M is nearly zero.
Andy
There are 74ls245 like devices for 5v to 3.3v level shifting.· Here is one:
A lot of great ideas coming out here haven't had time to absorb most of them yet.
What the CPLD solution needs is ways to minimize the amount instructions needed in the Prop to do the reads/writes especially instruction fetches. So for example there should be an auto-incrementing program counter out there for which strobing a single I/O line will cause it to increment and fetch the next instruction byte. This reduces the opcode fetch sequence to three Prop instructions: set strobe true, set strobe false, read the data.
Possibly there should also be a stack pointer out there with increment/decrement strobes....
Ariba's proposal for using a real Z80 with the Prop is something I'd like to pursue myself but I can't see that I have the time for it. If any one is actually going to go that way it really deserves a thread of it's own. It's no longer CP/M on a Prop after all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The CPLD/RAM circuit I suggested would auto increment or decrement whichever register (1 of 4) was selected to access the memory. It would also speed up the initial setup of the registers by auto incrementing or decrementing the register address for a read or write.
In pseudo code setting up a 24 bit address register would be:
out command ' 8 data bits cmd=1 write=1 ' set command register to access register
out command ' 8 data bits cmd=0 write=0
out addr1 ' 8 data bits cmd=0 write=1
out addr1 ' 8 data bits cmd=0 write=0
out addr2 ' 8 data bits cmd=0 write=1
out addr2 ' 8 data bits cmd=0 write=0
out addr3 ' 8 data bits cmd=0 write=1
out addr3 ' 8 data bits cmd=0 write=0
Now that the address register has been set up we set up the command register and read or write data
out command ' 8 data bits cmd=1 write=1 ' set command register to access RAM with auto increment
out command ' 8 data bits cmd=0 write=0
input data ' read data from memory location address register points to cmd=0 read=1
input data ' cmd=0 read=0
input data ' read next byte of data from memory location address register points to cmd=0 read=1
input data ' cmd=0 read=0
Andrew, Ariba, I agree that if all you wanted to do was Z80 (or 8080 or 6502 or 6800....etc.) emulation building a board with some ram, buffers, and the microprocessor chip of choice is the way to go. I looked at Dennis Ferrons project and thought it was an amazing and elegant idea. What I would like to do is build something a bit more flexible that can be used for more than running code for a single micro or operating system.
How about an optimized bytecode interpeter running on the prop for:
An industrial automation system.
A robotic system.
A process control system.
Emulating the first computer I worked on professionally (a Collins 8400 emulating an IBM 1401).
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A CPLD with 48 I/O's costs less than $10.00. A 1/2/4 meg RAM (128K/256K/512Kx8) costs less than $5.00.
With that CPLD and RAM we should be able to build a memory board that uses 12 pins to access 128/256/512KB of ram and speed up emulation.
The CPLD would implement the following commands:
Load 8 bits from Prop to address register low byte.
Load 8 bits from Prop to address register mid byte.
Load 8 bits from Prop to address register high byte.
Load 8 bits from Prop to data register low byte.
Load 8 bits from Prop to data register mid byte.
Load 8 bits from Prop to data register high byte.
Increment address counter.
Increment data counter.
Read instruction from RAM to Prop.
Write instruction from Prop to RAM.
Read data from RAM to Prop.
Write data from Prop to RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The 573+SRAM is faster to build. The CPLD board is not going to be with us for some time, though.
Got the 24K CP/M running fine! Super duper great work there, my compliments. I am impressed.
Adding memory is indeed a big topic.
Sounds like a XILINX 9536 PLCC 44 will do the job. I once offloaded an entire 24x80 video sequencer·and some cursor registers into an XILINX 9572 PLCC 84, and this had to arbit access to the Video RAM in a similar fashion. But a 9536 PLCC is small and easy to use.
But I moved back to my original project, which also includes a propeller chip:
If you will have a look at http://projects.steamboat.de/html/ez80.html, you will see my approach to run CP/M on an eZ80 based system - I was planning to handle VT100 type output using a propeller as a video controller instead of the original idea of a dedicated XILINX 9572, which I decided to ditch even though it was completed and worked.
I then noticed the new N8VEM project - looks real nice - but I am still muddling along trying to put an ez80 (48MHz), 512K RAM, a boot flash, a PROPPELLER on a EURO-BOARD and this would have a SD-Card that contains YAZE-HD-Disks, a VGA connector and a PS/2 KBD connector. I'm very close to achieving that by now.
The base CP/M system would also be loaded from the SD-Card, so as to minimise the amount of flash needed.
Current project is loading the Propeller directly from the ez80 (see the 3-4 threads here about how to do that from various non-PC sources), and putting together VT100 or VT52 support (probably not needs to be totally complete) for the propeller (for wordstar, turbo-pascal and whatnot).
Maybe we could all work together to come up with a usable design that meets a variety of needs.
I have not done any work with CPLD's for a while so I am not all that familiar with what is available. Any experts out there willing to help with that part of it?
Everyone: Isn't what we need here a "standard" board design like the Prop Demo board but with a bucket of RAM and a little CPLD. Such that RAM hungry objects can be shared with an expectation that people will have the possibility to run and check them.
The nice thing about a CPLD/RAM design is that you can get back the I/O that lost by connecting it in the first place.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Question, why does it require it's own SD card (at least the first MB) instead of
being able to simply run as a file anywhere on the SD with everything else jammed
in there?
It looks like we are already extremely close to being able to do coding on this.
Is there a smaller editor which fits into the 24K limitation or will MBASIC work?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
- If you use a CPLD for connecting the RAM, why not take an FPGA instead and do the 8080 Emulation in the FPGA and not the Propeller (there are still proven 8080/Z80 designs on Opencore.org) !
But then I thinked twice:
- Such a chip with an 8080/Z80 CPU and RAM controller still exists, and in DIL 40, easy to handel: An original Z80 !
So why the complicated way with a 100 pin CPLD or FPGA, if you can have it 100% original, in much easier to handle chip, which is also cheaper (around 3$) ?
So I came to a possible design, attached as block diagram. It is inspired by the 6502 Laptop from Dennis Ferron:
- The Propeller can control the Databus and some Control lines of the Z80. This allows to fill the RAM with a Boot code (using the Z80 as address counter), and then start the Z80.
- Then the Propeller can be a Peripheral Device (or better some Devices) and a Terminal.
It's only a basic idea, and not considerated exactly, so far
Andy
I threw this circuit together as a concept.
Uses 12 lines. The HCT chips are 40c each from futurlec. The RAM is $2.90 BUT that is a 5V ram. 3V ones do exist but are not quite as common. I'm not sure about the cost effectiveness of a 5V ram with level shifting vs a 3V one. Regardless of CPLD and other solutions that issue needs to be considered.
This circuit only uses half a 128k! But with another 373 and one extra line you can decode A16.
I haven't checked other suppliers but futurlec has the same price for 32k vs 128k so one 128k is probably better than two 32ks.
Going off on some other tangents, old school dynamic rams use 18 lines. But they are very cheap. ? 5V only. Constant refresh so need a dedicated cog. Overall, probably not a good solution.
I found this intriguing solution: http://www.zlgmcu.com/luminary/download/LM3SAPP_SSI_32KB_SRAM_en.pdf
Serial SRAM. 4 lines, 3V supply, one chip. But unlike flash and eeprom, unlimited rewrites.
Throughput of 250k per second. Is that going to be fast enough?
It's a pain to handle (not DIP), but there's already an object and
doesn't require a ton of data-lines.
obex.parallax.com/objects/346/
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
You will need data level translation in there, but leaving that aside for the moment, I'm looking at my working N8VEM board and seeing what all the chips do:
EPROM - for the bootloader and CP/M. That can go off into the SD card.
UART - that can go off into the propeller
8255 - that is mainly being used to control the keyboard and LCD display - replaced by the PS/2 keyboard and the VGA.
2 HC273, 3 HC32, HC10, HC04, HC139 - all glue logic that can be in software in the propeller
UART clock and Z80 clock - that can be from the propeller
Big 512k ram chip - a combo of working ram and a disk drive. That can be a cheaper 128k.
DS1210 ram backup chip - replaced with SD card.
The ram can be filled up and the Z80 can be given a reset and go off and happily run the program in ram. Z80 chip is $1.70 to $2.90 at futurlec.
When the Z80 wants some more data, ie a "disk" read, the BDOS could be modified so this sends/receives an IORQ line in combination with a known address.
Similarly, an IORQ In or OUT (eg to send a byte to the display) would be trapped by the propeller.
The hard bit would be writing the custom disk I/O. That is the bit that takes time.
I'm not sure how level translation works, especially on bidirectional lines?
OBC - that chip looks great. The thread was last year - has the price come down? (there was mention on the thread of a minimum of 100).
Post Edited (Dr_Acula (James Moxham)) : 1/3/2009 1:23:05 AM GMT
A couple of reasons for the way SD card is handled:
1. What I want is a CP/M file system not an MSDOS file system.
2. Code space, all that FAT code has to live some where and the current implementation needs all the HUB RAM it can get.
3. Speed, all that FAT stuff must take time.
OK that's three reasons [noparse]:)[/noparse] I know it's a pain for anyone who just wants to quickly try it out but there we go.
I haven't found a small editor yet, not that I've been looking very hard.
Sadly mbasic bombs out with "bad load" with only 24K.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The simplest bidirectional Level shifter is just a 1k Ohm resistor between the Prop and every line of the Databus. These 8 resistors also protect the Z80 and the Propeller if they try to write accidentally at the same time.
I think heaters emulation must still have a way to use the SD card as disk. I can't say if this is easy to adapt, because my knowledge about CP/M is nearly zero.
Andy
The emulation uses an SD card as CP/M disks.
What it does is to simply put eight CP/M floppy disk images consecutively on the SD card. Eventually I'll get round to adding the hard disk images. There is no FAT layer used, just writing CP/M disk sectors to blocks on the SD card.
For the floppies each sector, slightly over 130 bytes, is written to the beginning of a 512 byte SD card block. Wastes a bit of space. For hard drives 512 byte sectors would be used.
Now I think what your post is getting at is reading/Writing that mess as single file from a PC. I have not tried it but under Linux it should be possible to use the "dd" command to read raw data off the card and dump it into a file or vice versa. Under Windows I have no idea.
So it should be possible to format CP/M and load up disk images under the SIMH emulator. Concatenate the resulting files, with appropriate padding of the sectors and dd them onto an SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 1/3/2009 2:31:03 AM GMT
PM'd you but not sure if you saw it. Any chance you've already done a version
of your propaltair for FullDuplexSerial?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I also looked at Leons Prop-CPLD board and I think we can combine the two projects or at least have only one board.
The prop-cpld signals would consist of an 8 bit bidirectional data bus, a command/I/O signal, a read strobe, and a write strobe.
The command signal would read/write the command register when true. When false it would perform the I/O command specified by the command register.
The functions of the command register are below.
Let me know what you think.
Command register
Bit 0-1 - 00 Address register 0/CPLD I/O1-I/O6
01 Address register 1/CPLD I/O15-I/O21
10 Address register 2
11 Address register 3
2-3 00 Address register byte 0
01 Address register byte 1
10 Address register byte 2
11 CPLD I/O
Bit 4-5 00 No change
01 Post increment * Increments selected Address register or bits 2-3 of command register
10 Post decrement * Decrements selected Address register or bits 2-3 of command register
11 No change
Bit 6-7 unused
THANK YOU!· THAT·IS A GREAT IDEA!
Andrew Lynch
http://rocky.digikey.com/WebLib/Texas%20Instruments/Web%20data/SN74LVC4245A.pdf
Thanks!· Have a nice day!
Andrew Lynch
http://n8vem.googlegroups.com/web/rac_stack1.jpg
http://n8vem.googlegroups.com/web/rac_ecb_done2.jpg
Blinkenlights!
Thanks and have a nice day!
Andrew Lynch
What the CPLD solution needs is ways to minimize the amount instructions needed in the Prop to do the reads/writes especially instruction fetches. So for example there should be an auto-incrementing program counter out there for which strobing a single I/O line will cause it to increment and fetch the next instruction byte. This reduces the opcode fetch sequence to three Prop instructions: set strobe true, set strobe false, read the data.
Possibly there should also be a stack pointer out there with increment/decrement strobes....
Ariba's proposal for using a real Z80 with the Prop is something I'd like to pursue myself but I can't see that I have the time for it. If any one is actually going to go that way it really deserves a thread of it's own. It's no longer CP/M on a Prop after all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just got Propaltair loaded on my Double Stack Prop board..
2 Protoboards stacked one on top of the other. [noparse]:)[/noparse] [noparse]:)[/noparse]
-Bottom board: Running Propaltair {Full Duplex Serial}
SD connections routed to a connector on the top board.
TX/RX 8,9
-Top board: Running VT100 terminal {PropCOMM}
Video connections
Keyboard
TX/RX 9,8
It works awesome! [noparse]:)[/noparse] I'm gonna have a good time
playing with this over the weekend.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Post Edited (Oldbitcollector) : 1/3/2009 4:09:02 AM GMT
In pseudo code setting up a 24 bit address register would be:
out command ' 8 data bits cmd=1 write=1 ' set command register to access register
out command ' 8 data bits cmd=0 write=0
out addr1 ' 8 data bits cmd=0 write=1
out addr1 ' 8 data bits cmd=0 write=0
out addr2 ' 8 data bits cmd=0 write=1
out addr2 ' 8 data bits cmd=0 write=0
out addr3 ' 8 data bits cmd=0 write=1
out addr3 ' 8 data bits cmd=0 write=0
Now that the address register has been set up we set up the command register and read or write data
out command ' 8 data bits cmd=1 write=1 ' set command register to access RAM with auto increment
out command ' 8 data bits cmd=0 write=0
input data ' read data from memory location address register points to cmd=0 read=1
input data ' cmd=0 read=0
input data ' read next byte of data from memory location address register points to cmd=0 read=1
input data ' cmd=0 read=0
How about an optimized bytecode interpeter running on the prop for:
An industrial automation system.
A robotic system.
A process control system.
Emulating the first computer I worked on professionally (a Collins 8400 emulating an IBM 1401).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.