An eZ80 with CP/M? Cool. Nice to see you can still buy an off the shelf computer running CP/M.
Re the external ram, my brain is starting to hurt.
I wonder about HC245s? You could use two to share 8 wires between the ram and the sd card. Or 4 to share 16 wires. or 6 to share 24 wires. However many are needed really. Reading the ram, you disable the SD card 245. Reading the SD card, disable the ram one. Outputs go high impendence when not being used.
I think it probably is better to have the mass storage close to this board - it will be much faster etc.
HC245s are 40c at futurlec. Technically you only need one way on the data when driving the address lines but HC244s are the same price. May as well use 245s and then all the chips are the same.
And would you use two 32ks or one 128k? 32ks seem to accumulate in the parts drawers quicker for some reason. Maybe they multiply, like wire hangers in the clothes cupboard?
Could it be done with one 128k and two HC245s? Or two 32ks and two HC245s?
I need to look at SD cards - I hope there are no bidirectional lines. If there are, you can even go to a 4066 if you have to.
None of these chips are expensive, and who knows, there might be other non CP/M uses for extra memory on a propeller?
Mike Green said...
Well, I ordered an eZ80 development board from Zilog.....
Hey, in the context of this thread that is cheating really badly! You are forgiven on the strength of your SPI RAM suggestion.
SPI RAM looks great if we can get up to the 20MHz speed which gives us 0.5us per byte fetch which compares with the approx 0.44us the current emulator code takes to read from HUB including ROM/RAM mapping and range checks etc.
SPI RAM looks great but 2us per access is a lot worse than the 0.44us the current emulator code takes to read from HUB including ROM/RAM mapping and range checks etc.
Currently the emulator memory read/write functions occupy 21 longs. The equivalent SPI RAM functions would have to be of this size else we end up moving more opcode emulation functions into LMM and speed is down again. Is this likely?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hi!· Don't force the Propeller to do in an unnatural act what the Z80 does naturally!· The real power is the synergy between the two chips!· Use the Z80 (or descendents) to access the parallel memories and IO as it can do it efficiently.· Use the Propeller as a uC where its intrinsic tremendous IO power dominates!·
Build a Z80/Propeller hybrid SBC!· Use some these units to separate the differing Vcc and Vdd requirements
Since the Propeller can do so much of the IO by itself, you can make an SBC with a full set of IO capabilities with a very low chip count compared to traditional solutions.
Trying to use the Propeller to drive parallel memories is possible but it hobbles it because it consumes so many of the IO pins driving address, control, and data lines.· Yes, you could mux and demux the pins but that just leads to unnecessary layers of complexity.
I think the answer is a high speed communications channel between the Z80 and the Propeller so each chip can do what it does best.
There is a tremendous synergy between the Propeller and classic CPU designs!· At least that's my thought on the subject.
lynchaj: That is totally correct, you have summed it up nicely and it brings me back to square one in my quest for an Altair.
However I now have all this emulator code lying around that I just can't put down. Of course it could just wait for the Prop II where it will live very nicely. You see the current Prop is very frustrating for this because it almost, nearly, just about, maybe does what us required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Mike, which kit did you get ? Some month ado I got a eZ80F920200ZCOG. The USB "smart" cable never worked under vmware, so I di not used t at all, the kit. This is an interesting project to do with that.
The last I saw was the sources of CP/M sort of working, did they improve in the last 6 months ?
I got the EZ80F917050SBCG. This also uses the USB "smart" cable. I also use VMware (with Windows XP Home). I hope it works with the cable. I do have a backup "true" Windows box that I can use if I have to.
Attached is the archive I got from a network search. I plan to go through it carefully before using it, but it looks like a good starting point.
Once I get this going, I plan to translate one of the Propeller downloaders to run under CP/M. Eventually it should be possible to do Propeller development under CP/M.
Post Edited (Mike Green) : 12/29/2008 6:41:59 PM GMT
Mike Green said...
I got the EZ80F917050SBCG. This also uses the USB "smart" cable. I also use VMware (with Windows XP Home). I hope it works with the cable. I do have a backup "true" Windows box that I can use if I have to.
Attached is the archive I got from a network search. I plan to go through it carefully before using it, but it looks like a good starting point.
Once I get this going, I plan to translate one of the Propeller downloaders to run under CP/M. Eventually it should be possible to do Propeller development under CP/M.
WOW!· Thanks!
This just gets better and better!· There are a couple of Propeller based terminal boards in development at the N8VEM project right now!
I coudn't make the cable work under vmware and xp. Maybe a driver issue. I can try with a clean install...
Those sources are the same I saw some time ago. I thought they were newer. If something works I'd be really pleased !. And putting that kit into working condition... I was thinking in selling it, together with a pair of ez80L92 or so that I bought for some other project, now I'd just keep all this and make it work.
As soon as I get again to the uni (where I have my kit) I'll let you know which one exactly I have (Now I'm in doubt if I have a F91 or F92!) and I'll try to run that code and report back.
Once I get this going, I plan to translate one of the Propeller downloaders to run under CP/M. Eventually it should be possible to do Propeller development under CP/M.
Unbelievable... Using a 1980's OS systems to program a state-of-the-art micro.
Mike, sounds like my dream of ditching PC-based Propeller development is coming true. [noparse]:)[/noparse]
The eZ80 is pretty much a state of the art micro itself with 512K of SRAM and 1M+ of flash, a system clock of 50MHz with roughly one instruction byte per clock cycle and instructions mostly in the 1 to 3 byte range in length. It has its own SPI interface, I2C interface plus 2 UARTs, one of which is for the console. There's an Ethernet interface and TCP/IP stack, etc.
Mike Gren said...
Eventually it should be possible to do Propeller development under CP/M.
That is a totally audacious and fantastic idea !. I love it.
Do you have any plan as to how this may be actually possible? I mean is there any Spin compiler/PASM assembler that can be compiled to work in such a small space (64K)? Can be done with overlays, but how ?
This leads to the concept of developing for the Prop under CP/M running under emulation on a Prop......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This leads to the concept of developing for the Prop under CP/M running under emulation on a Prop......
IIUC, At one time Apple used a Cray computer to aid in design of the next Apples,
while at the same time Cray was using Apple computers to aid in the design of the next Cray.
Re additional memory. I got an email from Nurve Networks and it remined me of the Hydra 512Kb memory card. 12 IO pins. Directly addressable lower 64K of SRAM. Upper 64-512K accessible thru block reads/writes. Programmable post increment/decrement after reads/writes allowing for high speed block access. Most operations can be performed in a few ASM instructions. SRAM can be accessed as fast as global (HUB) memory in many cases from within a COG.
There's no compiler or assembler for the Propeller that can be compiled for the 8080 or Z80 or work in a 64K memory space.
It could certainly be done in overlays or chained programs. That's in fact how it would need to be done. There would probably be a lexical pass, then a parsing pass, then a code generation pass.
Using CP/M has several advantages ...
1) There's a 64K memory space. The Prop I has only 32K and a hunk of that has to be used for I/O (code and buffers).
2) There's a well developed software base including editors and utilities. There are all sorts of existing compilers.
3) The CPUs used are fairly simple and have modest requirements these days for support circuitry.
4) A cheap 1GB micro SD card is a massive amount of storage and is easily interfaced to something like an eZ80.
5) The assumed display is text only and doesn't have to be huge to work. 80 x 24 is excellent.
So after all that I'm not sue what Mike is proposing. Seems unlikely that anyone is going to take the time to develop tools targeted at Prop PASM or SPIN running under CP/M. Although I guess a simple assembler would not be out of the question and Mike is creating a down loader.
All that talk of multiple passes and overlays etc reminds me of the time I used to compile our apps for a process control system in the early eighties using Intel's Intellec development systems. I would have three of those systems, each with three 8 inch floppy drives, compiling different parts of the apps simultaneously. Operating system on one disk, source on another, output on a third. Whir, Clunk, Whir, Clunk.....It would take most of the day to recompile everything!
As it stands I can and have used CP/M to develop for the Prop. I can write code in C or PL/M or Pascal or whatever, compile it on a CP/M machine and run it on the Prop using the emulator. If the program does not use files then leave out CP/M on the Prop and just use the 8080 emulator. Only dependence on a PC currently is the loader.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If I've been following Mike's posts correctly, it sounds like
he's been working on a multi-pass binary compiler, and I'm
guessing that he's planning to take advantage of the CP/M
stuff for the actual "editor" side. Mike, if I'm right are you
thinking that you may be able to connect the SD to both CPUs
much like Ray did with his juicebox project?
Using something like WS via a terminal from the Propeller
would give stability & ram required for code creation.
If he can mount the whole mess on a Protoboard what a neat machine.
OBC
Edit: It just hit me. There are some CP/M guys in this thread who
plan to use the Propeller to enhance their CP/M machines, and there
are some Propeller guys who plan to use the CP/M to enhance their
Propeller stuff. Love it!
>Edit: It just hit me. There are some CP/M guys in this thread who
>plan to use the Propeller to enhance their CP/M machines, and there
>some Propeller guys who plan to use the CP/M to enhance their
>Propeller stuff. Love it!
Indeed! I am in the former group. But who knows where the prop can go - it has boundless possibilities just like when home PCs had just been invented.
Working on terminal code at the moment, and simple data/file interface protocols, and wireless links...
Oh and Happy New Year from down in Australia where it is already 2009!
Oldbitcollector said...
... Edit: It just hit me. There are some CP/M guys in this thread who
plan to use the Propeller to enhance their CP/M machines, and there
are some Propeller guys who plan to use the CP/M to enhance their
Propeller stuff. Love it!
Hi OBC!·
Yes!· Classic CPUs like Z80·with the Propeller are two good·things that are great together.
Sort of like beer and pizza, peanut butter and jam, chocolate and peanut butter!· You get the idea...
Have a Happy 2009!· Thanks and have a nice day!
Andrew Lynch
PS, tonight I will test your PropCOMM2 VT100 terminal emulation software on my prototype board in the basement.· I just couldn't get to it last night before it was too late.· Are there specific things you want tested?· Thanks!
OBC - I wrote a terminal program in VB.NET to test out all the VT100 escape codes that Wordstar uses. Code example and the (rather brief) list of escape codes on the N8VEM google group. Source code on the wiki.
Test that wordstar looks the same as when running on a terminal program. Then test ^Z and ^W scrolling because that is where the special 'scroll from part way down the page' VT100 codes get a workout.
It would be great to see wordstar running as a complete emulation on a Propeller. It looks like there will be a board for the terminal from http://www.brielcomputers.com/wik/index.php?title=Main_Page, so if the terminal is a standalone item with keyboard, display and a serial port, then another propeller can concentrate on just being an emulator. And that only needs two wires for serial comms to the terminal, so that could free up a lot of pins. And so maybe it is possible to pair the propeller chip with a single 128k ram chip and get all the code space needed?
Well Mike, I have my kit in the hands, it says : eZ80F910200KITG (read: I said nonsense before). Yours is very similar to mine but it has the Flash (extra flash) mounted while mine has no flash mounted. Mine has also a RS232 port.They are similar enough , great !
DR_Acula: We are so close. The current 8080 emulator uses a serial console, I use PropTerminal for that at the moment so plugging into a a VT100 terminal is a doddle. As always the only show stopper for running WordStar etc is the RAM space.
Can any one tell me how the Hydra RAM card works? At least as far as the first 64K block. Would be nice to implement something that is some kind of standard in the Prop world.
I really do not want to spend $60 on a Hydra RAM card just for that 64K CP/M needs. That would be emulating the price of RAM in 1976!!! but I'm hoping that with the RAMS I have and a bit of glue logic it would be possible to create something compatible. Hydra owners would then be able to run CP/M on a whim. Also Leon has his Prop/CPLD/RAM board coming along which could also be compatible.
I'm about to embark on a major rewrite of the 8080 emulator using multiple COGS for speed but perhaps we should get the full up 64K system with VT100 working first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sounds interesting that there are other ram options in the wings.
IMHO 64k is quite a good size. Ok, maybe it was the size of ram when I got into computers, but there is a bit more of a reason than that. CP/M went for many years at that size. I feel for the earlier generation where 1k or 2k was considered generous (mind you, that is all you get on many modern PIC chips. Indeed, in terms of working ram, PIC chips like picaxes only give you about 100 bytes and only 14 of those are simple to access.
If you have a text file, then 64k will fit many pages. If you are writing code, 64k will fit enough to write a fairly complex program, and once it gets longer than that it gets confusing anyway and may well be better to write as several seperate programs.
(So much of windows is bloatware. I have a terminal program on the N8VEM talking to a terminal program on a WinXP. The N8VEM is running MBASIC and the windows program is running VB.NET. Both took a similar amount of time to write and both have similar complexity. One takes 10k and one takes 64Mb ?!)
The N8VEM uses a 512k ram chip as both system memory and a disk store, and because these chips are a bit unusual they are quite expensive for what they do.
2 32k chips would be great and may or may not need glue logic. A 128k chip hits a better price point than 512k. And 128k of ram on a propeller could go well with flash ram for storing 'programs' (I'm intrigued by the work being done on propeller operating systems).
As you say, it is so close. I'm wondering what you give up by dedicating many pins to driving an SRAM directly. And whether the things you give up could be on a seperate "terminal" propeller? And what the speed tradeoffs might be for, say, using 3 lines instead of 16 to send out an address via a couple of daisy chained HC595s?
Would extra ram be useful to other (non CP/M) applications for the propeller?
64K would be just fine for now. More is always better but I have yet to get my head around the bank switching that was implemented in some versions of CP/M. Was that ever commonly used? Is it worth the effort to implement nowadays?
The Hydra RAM card uses very few pins, I'll look into it now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ale: Is that a trick we can do with a hydra RAM card or do you mean with a custom solution. I was kind of fishing for a solution that people may already have in use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK that's what I'm going to do as soon as can get back to my soldering iron. I make that 19 pins, Data/Address, Write Enable, Output Enable and Address Latch Enable.
Should just be able to get the code to fit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Re the external ram, my brain is starting to hurt.
I wonder about HC245s? You could use two to share 8 wires between the ram and the sd card. Or 4 to share 16 wires. or 6 to share 24 wires. However many are needed really. Reading the ram, you disable the SD card 245. Reading the SD card, disable the ram one. Outputs go high impendence when not being used.
I think it probably is better to have the mass storage close to this board - it will be much faster etc.
HC245s are 40c at futurlec. Technically you only need one way on the data when driving the address lines but HC244s are the same price. May as well use 245s and then all the chips are the same.
And would you use two 32ks or one 128k? 32ks seem to accumulate in the parts drawers quicker for some reason. Maybe they multiply, like wire hangers in the clothes cupboard?
Could it be done with one 128k and two HC245s? Or two 32ks and two HC245s?
I need to look at SD cards - I hope there are no bidirectional lines. If there are, you can even go to a 4066 if you have to.
None of these chips are expensive, and who knows, there might be other non CP/M uses for extra memory on a propeller?
Hey, in the context of this thread that is cheating really badly! You are forgiven on the strength of your SPI RAM suggestion.
SPI RAM looks great if we can get up to the 20MHz speed which gives us 0.5us per byte fetch which compares with the approx 0.44us the current emulator code takes to read from HUB including ROM/RAM mapping and range checks etc.
SPI RAM looks great but 2us per access is a lot worse than the 0.44us the current emulator code takes to read from HUB including ROM/RAM mapping and range checks etc.
Currently the emulator memory read/write functions occupy 21 longs. The equivalent SPI RAM functions would have to be of this size else we end up moving more opcode emulation functions into LMM and speed is down again. Is this likely?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 12/29/2008 3:13:47 AM GMT
Build a Z80/Propeller hybrid SBC!· Use some these units to separate the differing Vcc and Vdd requirements
http://focus.ti.com/lit/ds/symlink/sn74lvc4245a-ep.pdf
Since the Propeller can do so much of the IO by itself, you can make an SBC with a full set of IO capabilities with a very low chip count compared to traditional solutions.
Trying to use the Propeller to drive parallel memories is possible but it hobbles it because it consumes so many of the IO pins driving address, control, and data lines.· Yes, you could mux and demux the pins but that just leads to unnecessary layers of complexity.
I think the answer is a high speed communications channel between the Z80 and the Propeller so each chip can do what it does best.
There is a tremendous synergy between the Propeller and classic CPU designs!· At least that's my thought on the subject.
Thanks and have a nice day!
Andrew Lynch
However I now have all this emulator code lying around that I just can't put down. Of course it could just wait for the Prop II where it will live very nicely. You see the current Prop is very frustrating for this because it almost, nearly, just about, maybe does what us required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The last I saw was the sources of CP/M sort of working, did they improve in the last 6 months ?
Attached is the archive I got from a network search. I plan to go through it carefully before using it, but it looks like a good starting point.
Once I get this going, I plan to translate one of the Propeller downloaders to run under CP/M. Eventually it should be possible to do Propeller development under CP/M.
Post Edited (Mike Green) : 12/29/2008 6:41:59 PM GMT
This just gets better and better!· There are a couple of Propeller based terminal boards in development at the N8VEM project right now!
Great!· This is really good news!
Thanks and have a nice day!
Andrew Lynch
Those sources are the same I saw some time ago. I thought they were newer. If something works I'd be really pleased !. And putting that kit into working condition... I was thinking in selling it, together with a pair of ez80L92 or so that I bought for some other project, now I'd just keep all this and make it work.
As soon as I get again to the uni (where I have my kit) I'll let you know which one exactly I have (Now I'm in doubt if I have a F91 or F92!) and I'll try to run that code and report back.
Unbelievable... Using a 1980's OS systems to program a state-of-the-art micro.
Mike, sounds like my dream of ditching PC-based Propeller development is coming true. [noparse]:)[/noparse]
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
It gets better - it's a 1970s OS :-)
http://en.wikipedia.org/wiki/CP/M
- Earl
That is a totally audacious and fantastic idea !. I love it.
Do you have any plan as to how this may be actually possible? I mean is there any Spin compiler/PASM assembler that can be compiled to work in such a small space (64K)? Can be done with overlays, but how ?
This leads to the concept of developing for the Prop under CP/M running under emulation on a Prop......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
IIUC, At one time Apple used a Cray computer to aid in design of the next Apples,
while at the same time Cray was using Apple computers to aid in the design of the next Cray.
Gotta love this business sometimes..
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
John Abshier
It could certainly be done in overlays or chained programs. That's in fact how it would need to be done. There would probably be a lexical pass, then a parsing pass, then a code generation pass.
Using CP/M has several advantages ...
1) There's a 64K memory space. The Prop I has only 32K and a hunk of that has to be used for I/O (code and buffers).
2) There's a well developed software base including editors and utilities. There are all sorts of existing compilers.
3) The CPUs used are fairly simple and have modest requirements these days for support circuitry.
4) A cheap 1GB micro SD card is a massive amount of storage and is easily interfaced to something like an eZ80.
5) The assumed display is text only and doesn't have to be huge to work. 80 x 24 is excellent.
All that talk of multiple passes and overlays etc reminds me of the time I used to compile our apps for a process control system in the early eighties using Intel's Intellec development systems. I would have three of those systems, each with three 8 inch floppy drives, compiling different parts of the apps simultaneously. Operating system on one disk, source on another, output on a third. Whir, Clunk, Whir, Clunk.....It would take most of the day to recompile everything!
As it stands I can and have used CP/M to develop for the Prop. I can write code in C or PL/M or Pascal or whatever, compile it on a CP/M machine and run it on the Prop using the emulator. If the program does not use files then leave out CP/M on the Prop and just use the 8080 emulator. Only dependence on a PC currently is the loader.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
he's been working on a multi-pass binary compiler, and I'm
guessing that he's planning to take advantage of the CP/M
stuff for the actual "editor" side. Mike, if I'm right are you
thinking that you may be able to connect the SD to both CPUs
much like Ray did with his juicebox project?
Using something like WS via a terminal from the Propeller
would give stability & ram required for code creation.
If he can mount the whole mess on a Protoboard what a neat machine.
OBC
Edit: It just hit me. There are some CP/M guys in this thread who
plan to use the Propeller to enhance their CP/M machines, and there
are some Propeller guys who plan to use the CP/M to enhance their
Propeller stuff. Love it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 12/31/2008 3:34:49 PM GMT
>plan to use the Propeller to enhance their CP/M machines, and there
>some Propeller guys who plan to use the CP/M to enhance their
>Propeller stuff. Love it!
Indeed! I am in the former group. But who knows where the prop can go - it has boundless possibilities just like when home PCs had just been invented.
Working on terminal code at the moment, and simple data/file interface protocols, and wireless links...
Oh and Happy New Year from down in Australia where it is already 2009!
Yes!· Classic CPUs like Z80·with the Propeller are two good·things that are great together.
Sort of like beer and pizza, peanut butter and jam, chocolate and peanut butter!· You get the idea...
Have a Happy 2009!· Thanks and have a nice day!
Andrew Lynch
PS, tonight I will test your PropCOMM2 VT100 terminal emulation software on my prototype board in the basement.· I just couldn't get to it last night before it was too late.· Are there specific things you want tested?· Thanks!
Test that wordstar looks the same as when running on a terminal program. Then test ^Z and ^W scrolling because that is where the special 'scroll from part way down the page' VT100 codes get a workout.
It would be great to see wordstar running as a complete emulation on a Propeller. It looks like there will be a board for the terminal from http://www.brielcomputers.com/wik/index.php?title=Main_Page, so if the terminal is a standalone item with keyboard, display and a serial port, then another propeller can concentrate on just being an emulator. And that only needs two wires for serial comms to the terminal, so that could free up a lot of pins. And so maybe it is possible to pair the propeller chip with a single 128k ram chip and get all the code space needed?
Can any one tell me how the Hydra RAM card works? At least as far as the first 64K block. Would be nice to implement something that is some kind of standard in the Prop world.
I really do not want to spend $60 on a Hydra RAM card just for that 64K CP/M needs. That would be emulating the price of RAM in 1976!!! but I'm hoping that with the RAMS I have and a bit of glue logic it would be possible to create something compatible. Hydra owners would then be able to run CP/M on a whim. Also Leon has his Prop/CPLD/RAM board coming along which could also be compatible.
I'm about to embark on a major rewrite of the 8080 emulator using multiple COGS for speed but perhaps we should get the full up 64K system with VT100 working first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The code for that card was released some time ago, but you'd almost have
to stumble over it to find it. Heres where it is.
Download the Hydra Teaser from Obex.
http://obex.parallax.com/objects/102/
Unzip the file labeled LocknChase, it contains a memory test program
for the Hydra ram card, if I'm reading the code correctly. (Not LocknChase)
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
IMHO 64k is quite a good size. Ok, maybe it was the size of ram when I got into computers, but there is a bit more of a reason than that. CP/M went for many years at that size. I feel for the earlier generation where 1k or 2k was considered generous (mind you, that is all you get on many modern PIC chips. Indeed, in terms of working ram, PIC chips like picaxes only give you about 100 bytes and only 14 of those are simple to access.
If you have a text file, then 64k will fit many pages. If you are writing code, 64k will fit enough to write a fairly complex program, and once it gets longer than that it gets confusing anyway and may well be better to write as several seperate programs.
(So much of windows is bloatware. I have a terminal program on the N8VEM talking to a terminal program on a WinXP. The N8VEM is running MBASIC and the windows program is running VB.NET. Both took a similar amount of time to write and both have similar complexity. One takes 10k and one takes 64Mb ?!)
The N8VEM uses a 512k ram chip as both system memory and a disk store, and because these chips are a bit unusual they are quite expensive for what they do.
2 32k chips would be great and may or may not need glue logic. A 128k chip hits a better price point than 512k. And 128k of ram on a propeller could go well with flash ram for storing 'programs' (I'm intrigued by the work being done on propeller operating systems).
As you say, it is so close. I'm wondering what you give up by dedicating many pins to driving an SRAM directly. And whether the things you give up could be on a seperate "terminal" propeller? And what the speed tradeoffs might be for, say, using 3 lines instead of 16 to send out an address via a couple of daisy chained HC595s?
Would extra ram be useful to other (non CP/M) applications for the propeller?
The Hydra RAM card uses very few pins, I'll look into it now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Trouble is it looks to be a tad on the slow side, 37 instructions for a byte read and 40 for the write. Only a few of which can be pruned out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK that's what I'm going to do as soon as can get back to my soldering iron. I make that 19 pins, Data/Address, Write Enable, Output Enable and Address Latch Enable.
Should just be able to get the code to fit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.