TwinBladeProp - Another SBC (single Board Computer) to run CP/M etc in a box

Cluso99

The TwinBladeProp is a 50mmx79mm (1.96"x3.11") pcb which may arguably be the smallest microcomputer (nanocomputer?) for hobbyists (excluding PDA's and phones). It can be housed in a box 53x82x31mm (translucent blue if I can source enough).

Features:

• Two propeller chips plus
  • Internal 5V and 3V3 regulators from user supplied power pack 6-9V
  • Built-in propplug circuit to miniUSB (unconfirmed - still trying to squeez it on)
• Second propeller chip (Blade #2) has
  • 512KB of static RAM (non-multiplexed)
  • microSD socket
  • 2 wire (ultra high speed serial) to Blade #1
  • No Eeprom (code loaded·from Blade #1)
  • Designed to run high speed RAM in applications such as CP/M emulation
  • Designed to run the future (PropDos/PropCmd) propeller operating system from microSD
• First propeller chip (Blade #1) has
  • Eeprom
  • PropPlug interface
  • VGA connector
  • PS2 connector with keyboard and mouse (or second keyboard)·on the one connector - requires splitter cable from eBay if both required
  • AV socket for TV and stereo out (as used in Apple (video) iPods) -requires 3.5mm 4pole cable to 3xRCA connectors from eBay
  • 2 wire (ultra high speed serial) to Blade #2
  • Loads code from Eeprom into Blade #2 (maybe boot code to microSD)
• Other info
  • All ICs are SMT (surface mount)
  • PCBs will be available as
    • Bare PCB
    • PCB with SMT parts assembled (most connectors and associated resistors are t/hole)
    • PCB fully assembled
  • Other variations
    • PCB can be built without Blade #2 in which case the microSD becomes part of Blade #1 (but not SRAM)
    • PCB can be built with just Blade #2 and alternative boot Eeprom (Note: not compatable with PropPlug for speed) This would be a self-contained CP/M machine or equivalent, just requiring the Terminal or PC.

If you already have a ProtoBoard (or similar), you can add just the self-contained Blade #2 to get your favorite emulation (such as ZiCog for the TriBladeProp) running.

I expect to send the PCB to manufacture Tuesday so I should have everything available in two weeks. For orders etc, please email me cluso@bluemagic.biz

Please do not ask for features (the design is done).

Over the next week I will post schematics, design reasoning, etc. It will be an open design. ··

Hopefully, this should answer some of·the memory questions that have been raging over the past few weeks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 5/10/2009 1:12:54 PM GMT

Cluso99

Reserved for the latest software

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Green

If you're not planning on it already, I do hope you plan to use a 128K x 8 EEPROM. Clearly 64K would be a minimum so you can hold the download for Blade #2. The extra 64K would allow for alternative programs for both Blades.

Tubular

Hmmm.... this might just be the missing link that makes a CP/M cellphone possible!...

Wait a minute, if it runs Wordstar and SuperCalc surely it would qualify as a Smartphone?

Put me down for a couple of blanks...

tubular

jazzed

Exciting stuff Ray! Can't wait to see your pics.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Cluso99

@Mike: I am only planning a 64KB Eeprom because the code loaded into BladE #2 will only be a minamilistic boot code to boot from microSD. The 64KB Eeproms are only marginally more expensive than the 32KB Eeproms. This is really not a commercial enterprise (hand assembled) so a 128KB can be fitted if required.

For the Blade #2 only version, I will be booting the prop using a small Freescale micro to load it, then booting from microSD.

So I guess what I am saying, I see this as a real computer with an operating system of some kind that will just have minimal boot code to get it started from microSD.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Huselton

cluso99,

This is the variation on the original SixBlade prop project that I've been waiting for.

Please consider this a request for a circuit board and Blade #2-only pre-mounted circuitry.
Just to be clear, I want to order a circuit board and fully assembled circuitry for Blade #2 only, since I have 6 unused ProtoBoards fresh and waiting for an application.
So, to start with, I'll try my hand with one of my ProtoBoards and your Blade #2 new stuff.

I will send you money as soon as your boards are returned from your PC fab vendor and you have a chance to build the prototypes and figure out costs.

3rd time is a charm, as my rule of thumb on protype variations and experience using the circuits, design principles and hard-won clarity of thought.
Fancy way of saying 3 times is a winner, usually.

You are truly a gentleman and scholar of leisure...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Dr_Acula

That looks brilliant! Especially the bit about * Bare PCB * PCB with SMT parts assembled (most connectors and associated resistors are t/hole) * PCB fully assembled

What would be the approx costings for the above options?

Cluso99

I have just posted the block diagram to the first post (without obviously the power supply, hopefully I can fit in the propplug circuit). No actual costings yet.

I do not see it as a replacement to the TriBlade, rather a simplified variant that solves issues for the less experienced hobbyists (smt issues). I did however, take the opportunity to refine the SRAM interface. Here's what I have done and why... (see top post for block diagram)

• Only one 512KB SRAM (all 29 pins connected directly to the prop)
  • SRAM Address A0-A18 to prop pins P0-P18 (no shift instruction required)
  • SRAM Data D0-D7 to prop pins P24-P31 (one 24 bit shift instruction clears all other bits which would otherwise need to be cleared)
  • SRAM -CE and -WE connected to dedicated prop pins (-OE tied to Gnd)
• One microSD card
  • microSD -CS connected to dedicated prop pin
  • microSD shares 3 SRAM data pins
• No latches or decoders (faster)
• 2 pins for ultra high speed external serial to a prop/terminal/pc

Advantages

• Speed targetted for Reads. Simply put, there are way more reads than writes. The following times exclude any call/return nd do not check for valid address limits.
  • TriBlade byte read takes 7 instructions·and can include an increment of the address free
  • TwinBlade byte read takes 4 instructions and can include an increment of the address free
  • TriBlade byte write takes 11 instructions. An extra instruction required to increment the address
  • TwinBlade byte write takes 8 instructions and can include an increment of the address free
• No latching which takes both instructions and code space

Disadvantages

• All propeller pins used (same as the TriBlade)
  • Use another prop - this is my concept and I still believe it is the correct one
• The TwinBlade does not use a conventional Eeprom because of conflicts
  • When connected to the other prop on the pcb, the other prop will load the program (boot) code, saving the Eeprom cost
  • When standalone, a small onboard micro is fitted to load the (boot) code from it's internal flash. It is a similar cost to the Eeprom.
• The TwinBlade cannot use the conventional Prop program loading mechanism because of conflicts
  • When connected to the other prop on the pcb, the other prop can download code via a a special download sequence (TBD)
  • When standalone, the onboard micro will load boot code that·will enable it to boot from the microSD card, or via a special download sequence (TBD) over the serial connection

Notes

• The TwinBlade pcb does not have the expansion capability of the TriBlade pcb
• If both PS2 ports are required then a splitter cable is required (from eBay)
• If composite video (TV) is required then an iPod video cable (3.5mm plug to 3 RCA connectors) is required (from eBay). Beware there are a number of various incompatable standards used. I have chosen the iPod standard as these are extremely popular. Stereo sound output is also available on this connector. A simple RC network is provided (see Ariba's thread Music Synthesizer object with General MIDI sound set·http://forums.parallax.com/showthread.php?p=797590).
• The·TwinBlade can be housed in a nice cheap·translucent blue plastic box. You will need to cut openings in the box for the connectors. Should there be sufficient volumes (large though)·I could organise to have them laser cut and maybe printed. I have done this previously for some commercial projects.
• It is possible to have two keyboards and two video (VGA & TV) displays connected concurrently.·MP/M anyone???

General

• Obviously this project has been inspired by the brilliant work done by heater in getting ZiCog to run on the prop. There are·many others also.
• It has been and remains my ambition to get the prop running it's own proper operating system which includes all the development tools. We are now very close to that being a reality. We now have
  • PropDos/PropCmd
  • FAT16 SD cards (up to 2GB)
  • PrEditor (well underway??)
  • FemtoBasic
  • Forth??
• We also have Z80/8080 and CP/M 2.2 running which has the following (but not tested)
  • Wordstar
  • SuperCalc
  • MBasic (working)
  • TurboPascal
  • C
  • Ada
  • Cobol
  • Fortran (if you are old enough!)
  • etc, etc, etc
• CPM 3 and bank switching is work-in-progress
• We now only require
  • Prop compiler
  • Prop IDE
  • C compiler

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 5/11/2009 7:08:02 AM GMT

heater

If the data is going out on P24 to P31 could we not make it P23 to P30 and use:

MOVI OUTA, DATA

for writes instead of what I presume might be:

SHL DATA, #24
OR OUTA, DATA

Or such. I'm sure you have thought about this....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

Heater: Yes, but then the read needs to have an extra instruction and the read needs to be the fastest.
One
SHR DATA,#24
and its done!

Sorry, posted the schematic block diagram to the top thread·instead of a bmp [noparse]:([/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater

Drats. OK.

Hope there is room for a blue LED in that translucent blue box[noparse]:)[/noparse]

Now about that Motorola 6809 emulator. Has anyone started on such a thing?

It's a very quite Sunday afternoon here and with a bit of a hangover and I just found myself idly creating a dispatch table for it in the ZiCog framework...

I just discovered that with that it place we could program the Prop using GCC which also has memory bank switching support[noparse]:)[/noparse] Not to mention use FLEX, SKDOS etc etc. AND Ale is busy getting his head around One Man Unix.

MoCog is probably coming...very slowly.

I was kind of wondering. ICC or Catalina for XMM on this board would be great and I'm sure it will happen very soon. They are somewhat hamstrung by having to deal with honking great 32 bit instructions and having to deal with 32 bit wide data all the time when 8 or 16 bits would do. All the while working through an 8 bit data bus. Is it possible that a C compiler producing code for Z80 or whatever 8 bit emulation could actually win in terms of code space and performance for smaller applications?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater

Hmmm... If a read can take only 4 instructions with a free increment we must be able to squeeze 16 bit fetches into ZiCog (If only in 8080 mode) to get a useful speed gain.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

Heater:
I like blue leds too I will squeeze a LED in somewhere.

M9Cog (pronounced m(y)'nineCog as in mine) because there is 6800, 68000 etc in motorola's line for operating systems including unix.

I should be catching up with Ross (Catalina) now I am back on the Central Coast.

We should definately use a better 16 bit access and I am sure there is other things we can do to improve performance. But first things first - I need to get CPM3 runing and then getting bank switching. Then we have all CPM things available.... Wordstar, SuperCalc, all sorts of compilers - the TurboPascal was extremely efficient so thats how they made a name for themselves. I don't know performance wise how it would compare to spin - could be a real alternative.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater

I thought about exactly that naming issue. Still not decided but MoCog kind of rolls nicely whereas M9Cog does not to me. MineCog sounds very Germanic. Anyway we have a precedent for it now as Zilog made/make other processors beside the Z80.

Motorola are going to get very snotty when I draw up the logo for this. At least Zilog no longer use that image I used for ZiCog[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Toby Seckshund

I don't know. My crappy internet service dies, and when it comes back on you lot have invented another system!

I like the idea of 512KB as it should be enough withot encouraging PC emulation, 8 bit stuff is great for the imagination ie getting around things and milking that last drop of optimization.
Having said that, I never gave the 16 bit instruction of the Z80 the credit they were due, untill I tried to do simular things on AVRs ( got draws full of them, lonely and unused, now the Porp bug has bitten)

jazzed

I really like this design where it appears that the peripheral Propeller is emulating the boot SEEPROM (or the Serial Downloader ... can't tell which one it is). Once the engine is booted all the pins are free for SRAM IO[noparse]:)[/noparse] The many connections are vague ... a detailed pin-out would be useful. Have you prototyped the boot yet?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

kwinn

Cluso, that sounds like exactly what I need if the eeprom can be 128KB or larger. I am looking to replace an old Z80 based board with 14 2732 eproms, 44 1Kx4 ram chips, 2 serial ports, and some wild address decoding and paging logic ( block I/O to access ram ). It's an embedded board so I need to store the firmware currently in the 2732's, ZiCog, and whatever else I may need in the eeprom for loading at power up.

heater

Kwin: Don't forget the 2G Bytes of SD card storage. Should be enough for what you want !

Bank switched memory gives plenty of working RAM space. But will it fit with RAM layout your programs in ROM are expecting? Do you have the source code to this machine?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

kwinn

Good point about the SD card. That should hold the eproms and whatever else I need. As long as one prop boots automatically on power up and can access the SD card to load the rest it should work. As for having the source code, I wish! I really don't want to try to disassemble 56K of machine code if I can avoid it.

The memory mapping is the hard part. The eprom is straight forward, residing from 0000 to DFFF, but for some reason the 8K of ram is addressed as 2 banks of 2K from E800 to EFFF and one 4K bank from F000 to FFFF.

That was the easy part, now there is an additional 14K of ram that is accessed in 256 Byte chunks by block I/O on I/O ports (addresses) 00 to 37. Unfortunately the Z80 puts the port address out on the low 8 bits of the address bus and the byte count on the high 8 bits. This results in the data being scattered through the memory address space. The first byte will be at an address equal to the port number, and each subsequent byte 256 locations higher than the previous one.

When I started I was hoping to use 1 Z80, 1 64K eeprom, 1 32K ram, and a prop to do the serial, clock, address decoding, and glue functions but it seems it is not possible without some additional chips. Not enough I/O pins.

I am hoping to be able to do it with the dual prop/ram and ZiCog. Have you implemented the block I/O instructions?

Mike Green

kwinn,
The SD card is attached to Blade #2 which has to be booted from Blade #1 before the SD card can be accessed. Blade #1 does not have direct access to the SD card ... another reason why it would be good to have some extra EEPROM attached to Blade #1, like using an AT24C1024B instead of a 24C512 or 24LC512.

kwinn

Thanks for pointing that out Mike. I think I can live with that as long as I can load the eprom code to ram first, then load ZiCog and whatever else I need for the weird address decoding. Really only one way to find out.

heater

Mike, look again at the block diagram. Blade #2 has a box labelled "Single Chip Prop boot loader (optional)" Blade #2 can boot up without any help from Blade #1.

kwinn: Having the RAM in non continuous lumps should not be a problem. Having extra RAM in the "holes" should not hurt. If it does we can puts tests for the "holes" in the emulation at the risk of a little slow down.

I'm interested in your next statements about how the Z80 "puts port the address out on the low 8 bits of the address bus and the byte count on the high 8 bits"

The Z80 hardware, as far as I can tell, does this during block I/O operations: The 16 bit HL register is the source/destination in memory space. The 8 bit C register is the port number in I/O space and the 8 bit B register is the current byte count value. Now HL goes out on the address bus for the memory read/write. C goes out on the low address pins as the port number during I/O read/write. B goes out on the hight address pins during read/write also. (This is undocumented behavior).

Now don't forget that during the I/O phase the bus is indicating an IO operation not a memory space operation. So it is possible hang up to 64K of RAM on the bus in I/O space not normal memory space.

What I suspect is happening is that during a block I/O your system is decoding the low address bits (from reg C) to select a particular 256 byte block of RAM in the I/O map. It then uses the high address bits (from the counter to access individual bytes in a block. I bet they have effectively swapped low 8 and high 8 address bits around and it's not as "hairy" as you think.

Of course it makes no difference if the low and high are not swapped. Just means the bytes are scrambled in their RAM positions but who cares.

I'm very sure we could tweak the ZiCog I/O and memory handling a little to do this trick.

Actually no, I have not implemented the block I/O yet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater

Kwinn: We already have ZiCog on the TriBlade loading its "PROM" space in external RAM prior to starting the emulation. Just need to change the definition of the PROM size.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Mike Green

heater,
I'm assuming (wrongly perhaps) that the optional "Single Chip Prop Bootloader" takes the place of Blade #1. It certain takes its place functionally.

heater

In a previous thread about this concept, when it had only one Prop. the "Single Chip Prop Boot loader" was a tiny $1 micro controller that took care of some decoding glue logic for the RAM and SD card whilst at the same time providing enough FLASH to act as as an initial boot loader for the Prop. Cheaper than an EEPROM. Device as yet unspecified. The initial boot then loads from SD or Blade #1

Not sure but I think the idea is that it can be used as such with Blade #1 is in place or not. Sounds kind of neat. Cluso will elaborate I'm sure.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dr_Acula

This is an absolutely fascinating minimalist approach. I think it could well come in as the cheapest option too. For a N8VEM you need a Z80, uart, ram and about 10 support chips. Then you need a propeller to do the vga and keyboard. So a N8VEM solution needs at least blade #1. But blade #2 replaces a large board and many chips.

I like the cunning way you are loading the data off blade #1's eeprom.

I'm thinking you would always need blade #1 in some way, even if you didn't have a keyboard and a vga display you still need some sort of input/output.

Re things we have and things we would like, you could add C to the list of things we have. BDS C is a proper structured language available about 3/4 the way down the page http://www.schorn.ch/cpm/intro.php and the manual etc is at http://www.bdsoft.com/resources/bdsc.html

Can you please put me down for an assembled board?

Post Edited (Dr_Acula (James Moxham)) : 5/11/2009 12:54:26 AM GMT

Cluso99

Kwinn: As heater said, because we can map anything inside the ZiCog code, we can do this providing it all fits in 512KB ram (I didnt do the maths). All can be preloaded into ram from microSD.

Mike etc: An AT24C1024 can be fitted instead of the AT24C512 on Blade #1.

Blade #1 actually can access the microSD but beware of conflicts - so Blade #1 can hold Blade #2 in reset. Alternately, the Single Chip bootloader can also be fitted. The TriBlade was designed to load Blades #1 & #3 from Blade #2 (just haven't had the time to do the code).

Nothing has been prototyped - After 40 years of designs, I don't do this. The TriBlade was built without prototyping. I designed the TriBlade while waiting for the SixBlade pcb so I never built the SixBlade. Almost all of my commercial designs have been first revision (A) boards.

This is still a hobby for me, but who knows..

Here is a photo of the box and one of my previous designs showing how the box was laser cut and printed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 5/11/2009 2:53:28 AM GMT

heater

Kwinn seems to be looking at max 64K in normal RAM/ROM space plus 14K of RAM accessed in I/O space in 256 byte chunks. All is well provided we can squeeze the code for various mappings into the COG. Alternatively we could hang the I/O mapped RAM into the Spin I/O routines with all the other I/Os but that would be awful slow.

That's an impressive record Cluso. Never seen anything like it in my dealings with hardware designs/designers.

I used that same box for an AVR project. About the neatest thing I ever made at home. I love it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater

Dr_A: BDSC is not a problem. It will "just run" when all our kinks are sorted out[noparse]:)[/noparse] Just drop the relevant disk image into the system.

I've already been running BDSC compiled programs on PropAltair.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed

Ray, I'm sure your h/w design will work because the Propeller is very forgiving barring some silly mistake. Knowing you somewhat, I believe your confidence. Hope you won't need cuts and jumps ... that would be somewhat embarassing now. The prototype in this case would consist mostly of software, but that was not very clear obviously. Good luck.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230