S-100 Propeller project
lynchaj
Posts: 87
Hi!
Has there been any work done on S-100 Propeller projects? I did a quick search on the forum and nothing in particular turned up although there were a few references to S-100 mostly in passing.
Us hobbyists from S100computers.com and N8VEM project are working on an S-100 Propeller board. We have a prototype and are busily working on it. We've also got an idea for a follow on board. I was wondering if this topic has come up before and what peoples thought of the subject.
Thoughts? Ideas? Comments?
Thanks and have a nice day!
Andrew Lynch
Has there been any work done on S-100 Propeller projects? I did a quick search on the forum and nothing in particular turned up although there were a few references to S-100 mostly in passing.
Us hobbyists from S100computers.com and N8VEM project are working on an S-100 Propeller board. We have a prototype and are busily working on it. We've also got an idea for a follow on board. I was wondering if this topic has come up before and what peoples thought of the subject.
Thoughts? Ideas? Comments?
Thanks and have a nice day!
Andrew Lynch
Comments
Console IO has been a weak spot for S-100 computers since the beginning. You can have terminals, serial ports, video boards, parallel ASCII keyboards, etc. There are many solutions but each has strengths and weaknesses. That's where our S-100 Console IO board comes in. Basically it uses the strength of the Propeller's IO capabilities to act as a built in terminal board for the S-100 machine. It feeds VGA display and PS/2 keyboard as a terminal plus several other functions. We have a prototype PCB and are building and testing it now. I don't know when it will be done but several design changes are necessary so it will probably be a while. Also Propeller has such wonderful prototyping possibilities we are considering an S-100 Propeller prototyping board.
My intent here is to see what if anything has been done with S-100 and Propeller together. I don't recall seeing anything previously but you never know. Something could have happened in the recesses here I hadn't heard about.
Thanks and have a nice day!
Andrew Lynch
Even though this is common today, it was a novel idea for the 80's.
Having the regulators on board also allowed the boards to work well in high noise industrial environments.
Phew, for a year I worked on PropAltair as an 80805 emulator on the Prop for an ALTAIR box emulation, which morphed into he ZiCog Z80 emulator. And then there was PullMoll's Z80 emulator. All that time we never heard of Briel's Altair project.
Mind you my PropAltair was never intended to have an S100 bus. I have no such old cards to use and any functionality they might provide is more easily achieved with more Propellers:)
Hi! Is there anyone who would like to help us on the S-100 Console IO board? We are still working on the S-100 Console IO project and it is getting close to final. We had to redesign the board to dramatically simplify it so now it is a single Propeller based board. It's main function is a terminal replacement board where the builder plugs in the board, adds a VGA monitor and PS/2 keyboard and it acts basically like a VT-100 terminal.
Originally the Propeller acted like an IO device although we've since made substantial hardware modifications to decouple the Propeller from the S-100 bus. Now there are a set of latches between the Propeller and the S-100 bus to act as intermediaries and reduce timing constraints and wait states. Using the latches also dramatically simplified the Propeller software.
However the S-100 Console IO board is still experiencing some dropped characters at high data rates. I suspect this is due to timing issues involved with using Spin based software to communicate with the latches rather than PASM although there could be a hardware related issue hidden somewhere. We found on the PropIO that the Spin code tends to be not as responsive to timing sensitive as PASM which is reasonable.
Our original team had a Propeller expert but unfortunately he has since been overwhelmed by real life events and can't help as much as planned. We could really use a Propeller expert to help in the debugging so if you are an S-100 enthusiast and a Propeller expert with some experience in real time interfacing we would certainly like to hear from you. I *think* what we need is some PASM code to handle the timing sensitive routines but that is just a theory at the moment. We can set you up with a prototype board and get going.
Please consider. Thanks and have a nice day!
Andrew Lynch
Hi! Maybe I should clarify what we are actually doing with the S-100 Console IO board. From the S-100 bus CPU board perspective, the S-100 Console IO looks just like any UART or ACIA based serial console. The CPU polls or uses interrupt IO to communicate with the UART-like interface of the S-100 Console IO. The S-100 Console IO takes the data and displays it on the VGA monitor and passes along the PS/2 keyboard data.
We are not using the Propeller for any sort of general purpose processor on the S-100 bus. It is used as a microcontroller to easily and cheaply provide a VGA display and PS/2 keyboard. The S-100 CPU, whatever kind it is Z80, 68K, 6502, 8086, etc never actually communicates *directly* with the Propeller. The Propeller and S-100 CPU board communicate via latches to decouple them from the S-100 bus. This is supposed to relieve a lot of the hard realtime requirements of the Propeller meeting chip select, read, write, and other signals.
You could use a S-100 serial board as a UART and feed a Propeller based terminal board like PockeTerm or skip that and just a plain serial terminal or PC. However, the purpose of the S-100 Console IO board is to simplify the hardware of an S-100 system. With S-100 Console IO, a VGA monitor and PS/2 keyboard simply and cheaply can be used directly without any intermediate pieces requiring configuration. The theory being this would be a "drop in" component to replace legacy terminals and could be tweaked to emulate various protocols like VT-100 and others.
It probably is silly overkill to use a Propeller but its rich IO abilities is one of its most appealing features -- especially at low cost. Rather than a board full of glue logic, UART, and/or CRTC chips we can drop in this relatively simple and low cost board. It will just eliminate all the hassles of terminal configuration, maintenance, getting the connection parameters right, etc and just use essentially free scrap junk VGA monitors and PS/2 keyboard to reliably communicate with a legacy S-100 system.
For those with experience on restoring vintage S-100 systems, you'll recall the hassles associated with serial IO boards, terminals, or even more bizzare S-100 video boards, parallel ASCII keyboards, and all the other whacky devices prior to the IBM PC imposing their "de facto" standardization of hardware.
If there is someone who would like to help out please contact me. You'll need a *working* S-100 system and familarity with PASM and some electronics construction and debugging skills. We'll set you up with a PCB and help get you going on the project. Here is a link to the S100computers.com webpage with additional information:
http://s100computers.com/My%20System%20Pages/Console%20IO%20Board/Console%20IO%20Board.htm
Thanks and have a nice day!
Andrew Lynch
That's a great project! I've hacked around some success at controlling both floppies and IDE hard drives from a microcontroller, so I can appreciate the effort this project must have been.
You may not need PASM as much as you need a second cog.
It looks like during the main program loop, the code listens for an incoming character, then processes the character, including issuing a waitcnt. During this character processing, nothing is listening on the bus.
The propeller could launch a cog to listen on the S-100 bus for incoming characters and push them to a shared global queue. Then it could go back to listening probably within not too many microseconds, even in spin.
The main program loop would monitor the shared queue for new contents and would process characters as they appeared in the queue.
This sort of multiprocessing is exactly what the propeller excels at.
I don't have an S-100 system and can't help, but have you considered making a pass at it yourself? There's plenty of expertise here that could help out.
David
What's next is wrapping up the PCB and making them available to the S-100 community. Also some extra software for emulation of different terminal types and serial interfaces. That's important since no one really wants to change their legacy BIOS's. The goal here is to change the S-100 Console IO to match the legacy hardware not the other way around.
So if anyone is interested in S-100 application of the Propeller please stop on by S100computers.com or the N8VEM S-100 announcements mailing list.
http://groups.google.com/group/n8vem-s100
http://www.s100computers.com
Thanks and have a nice day!
Andrew Lynch
PS, Later this year John and I are planning another S-100 Propeller based board as an advanced prototyping board and different one to supply networking and microSD storage. More to come!
David, there was a time when I felt the same way. I hated having a uP that used a tiny fraction of its capacity. I got over it when I started to consider how much of what we own is under utilized. Our computers are off more than they are on, and even when they are on they spend more time waiting for a key press or mouse click than doing useful work. Our vehicles spend more time parked than being driven, and almost everything in our homes is idle more often than not.
Yes this is true. My point was that it does not make much since to use a processor that is many times more powerful than the system, to which it is no more than a peripheral. And with things like a PC, the processing power can be used in full when needed, with this IO board it is just wasted (even if the clock source is RCFAST [it can not be RCSLOW due to needing to drive VGA]). My feeling is that if you are going to provide something like this with all the extra processing power provided, add some extra registers to allow code to be sent to the Propeller, so it can be used as a coprocessor. This would NOT interfere with the stated goals, it can still provide the same registers for simulating a Serial IO terminal, while having the extra address space for a Prop Coprocessor.
Have to agree with that. If I were to build an S100 (or other retro computer) I would use the prop for as much as possible. Video, keyboard, serial & parallel ports, and floppy/hard disk emulator using sd cards. Doing video will not leave much if any hub ram but there might be enough cog ram left for some I/O buffers. Using cogs as co-processors could also be done but the original code would need to be modified so I am not sure how practical that is.
Exactly.
When I thought about using a Prop as a peripheral for the Z80 system I was about to build it eventually occurred to me that I don't need the actual Z80 chip. I could just emulate the Z80 and the entire CP/M computer with a Prop, some RAM and an SD card.
Dr_Acula's "Drac Blade" board is one of the results of this train of thought.
Yes, this approach is much more to my taste as well, and if I were to build a bus based system I would use a 96 pin eurocard connector or 2 rows of 50 pin headers rather than the 100 pin card edge connector. My answer was aimed at the diehard nostalgics among us who want to use the original cpu chips and bus.
Hi! The point of the S-100 Console IO project is to make a drop in board that can replace all sorts of legacy serial board and terminal combination *without* changing the legacy BIOS. The S-100 Console IO literally appears like the old serial board and terminal using the scrap VGA and PS/2 keyboard with *no* changes to legacy hardware or software. While the Propeller is probably under utilized it is doing exactly what we want it to do.
I think it would be trivial to add Propeller software and CP/M applications to off load processing jobs to the Propeller if anyone wanted to do that. As you mentioned the Propeller is mostly sitting around waiting for the legacy CPU data to transfer and certainly has cog capacity available. However, on vintage S-100 systems generally speaking most hobbyists using them are not seeking fast processors rather to access legacy data or restore a vintage system to working order. In this respect, using the high performance processor is a secondary concern. As you said, it would not interfere with the stated design goals if you or anyone else wanted to do that.
Our original S-100 Console IO was to include two Propellers for microSD, the PropNIC network interface, and a variety of other IO devices. However it proved to be overly complex for the project and we split the project into two parts; the S-100 Console IO board and an S-100 Propeller IO board for the microSD, PropNIC, and some spare pins for builder expansion. We've found the key to success with S-100 boards is to keep a single function per board to allow for easy debug and test. Overly complex boards lead to a lot of bugs and make it difficult to isolate problems.
Some of the ideas for the S-100 Console IO came from the N8VEM ECB PropIO board which does VGA display, PS/2 keyboard, microSD storage, and another Propeller with prototyping area and even an expansion mezzanine. It works well on an ECB Eurocard (160x100mm) and 96 pin DIN 41612 connector. It works well as a complement to the Z80 based SBC and overall I am pretty happy with it. However the PASM for the Propellers to emulate a IO port device turned out to be *much* more complex than we anticipated, is very timing sensitive, and used 12-14 pins per Propeller. I think the S-100 Console IO approach of using latches to decouple the Propeller from system bus is probably a lot more robust and certainly easier from a Propeller software perspective.
You and others are certainly welcome to join us on the N8VEM project. There is plenty of room for alternative view points and what is "best" is highly subjective. Thanks and have a nice day!
Andrew Lynch
Hi! The intended audience for the S-100 Console IO is definitely the "diehard nostalgics" of the vintage computer world. It is a pretty specific group with specific interests. When restoring ancient microcomputers often the hardware and software are undocumented so being able to replace broken pieces without reverse engineering the legacy BIOS is a really enormous advantage. Reverse engineering the contents of a 35 year old one-of-a-kind 1K 2708 or even worse an 256 byte 1702 EPROM can get really hairy. If you destroy it, the data is gone forever!
On the other hand, you could also use the board along with the backplane, Z80 CPU board (or 68K, 6502, 8086, etc), and 4MB SRAM board to make an entirely home brew S-100 system. In that case it may be appealing to access the extra capability of the Propeller for special functions since you'd have access to the design information. Ultimately, it is up to the builder and how they intend to apply the technology. I don't judge what is right or wrong, only provide the home brew boards to make it possible whatever their goal actually is.
Thanks and have a nice day!
Andrew Lynch
What seems to be the problem? I am still here and have been watching both groups. If you are just using the prop, for console I/O, why did you not just replicate my design for propIO to the S100 card. The latches actually make the software much more complicated, as it was just a simple state machine without the latches. If you want me to look at the code, just let me know - I did not know there were any problems with the board. I don't have a S100 setup but I can debug the code if you want - would have been better to go with a working design than to invent a new one - but that is passed now I guess.
Ancient microcomputers? Hey, I resemble that remark ;-) FYI, I built my first computer by buying the bare boards (8080 cpu board, Vector Graphics preset and go board, a 16x64 character display board, and an 8 slot motherboard), sockets, and chips. After adding a 16K memory board, 2 5.25” floppies controller board, and CPM I used that system to run a small business.
I do have to agree with Yoda's comments regarding the prop being fast enough to connect directly to the bus for I/O use. It is even fast enough to emulate ram/rom memory, at least for the early 8 bit cpu's like 8080, Z80, 65xx, 68xx, and 1802. To provide any more functions would require a second prop due to the use of almost all of the I/O pins on chip 1. There would still be idle cogs left on chip 1 for the creative folks to use. The second prop could handle the video, sd, serial, and parallel I/O.
Hi! Thanks! Yes, my basement is full of ancient microcomputers. I have a Vector Graphic machine with Z80 CPU board, 64K DRAM, FlashWriter II, the whole works!
You can still assemble your own S-100 based system. We have all the bare PCBs for an entire system from S-100 backplane, S-100 Z80 CPU board (68K, 6502, 8086 all on the way), S-100 4MB SRAM board, S-100 Serial IO board, etc. Even an S-100 System Monitor Board which is similar to the Jade Bus Probe if you'll remember that awesome board!
Yes, for sure the Propeller is fast enough to connect to the S-100 bus directly which is what the PropIO does now on the ECB. In fact, the S-100 Console IO started as sort of a derivative of the PropIO for the S-100 bus. However, John really did not like the wait states on the bus for synchronization and also wanted to simplify the Propeller software enough that it could be easily reprogrammed in Spin. So we redesigned it to use the latches for synchronization instead. I think Dave may have actually made the suggestion to use latches at one point but I don't recall the specifics.
Removing the CPU wait states is important on an IEEE-696 bus machine since it can be have multiple CPU boards. If one peripheral board generates wait states the whole bus slows down so it is necessary to decouple the Propeller from the S-100 bus. On ECB this was less of an issue because there is only a single CPU master at any given time.
The S-100 Console IO board has gone through several revisions and changes and ended up as a basic terminal on an S-100 board. Apparently the last prototype board is insanely fast since there is nothing holding the Propeller back and it can spew the data sent to it at absurdly fast rates to the screen. As I recall the PropIO is able to do that as well but is it a bit of a shock to watch the trusty bus slow S-100 system go from 2400 bps to like a 1Mbps terminal in one leap. I don't know what the final speed actually is but it is so fast the text is just blur as it goes by.
Here is a picture of the board. We are getting ready to take this board to get some PCBs made. Hopefully it will be the first of many Propeller based S-100 boards.
Thanks and have a nice day!
Andrew Lynch
PS, there is still one spare Propeller pin left. Any ideas as to what to use it for? An indicator LED is the most obvious but how about some more creative uses?
Hi Dave! Thanks! I will send you a copy of the board information and software. Thanks and have a nice day!
Andrew Lynch
Comments have been made about not using Props "because they are too good for that", I have to step back from that thought sometimes. I found myself day dreaming about AVR and a Z80 emu when of course that has been done so well already with the Prop (and I have several examples made already)
I have a couple of Z84c0010s getting dusty.
More information here
http://s100computers.com/My%20System%20Pages/Console%20IO%20Board/Console%20IO%20Board.htm
Thanks and have a nice day!
Andrew Lynch
PS, if any one is interested in other Propeller S-100 projects please let me know.