Sorry for bumping but... who said there's not enough prototyping space on the ProtoBoard?!?
Here's a "MiniDrac" with 2x 32KB SRAM chips salvaged from an old scrapped motherboard:
Inserted in the multiboard Parallax case:
There's no "good" and "bad" without "the ugly":
The wiring could have been done much more easily, I only realized at 60% of wiring that my fixation for "almost equal length wire trunks" was not only difficult to manage, but also not much needed or useful for timing.
Thanks to Dr_Acula for the original design, and also Toby Seckshund for his inspiring work on DracBlade variations.
If anyone is interested in the minor mods from the standard DracBlade, just let me know.
Have you run the retro computers and big Catalina programs yet?
Also what where the modifications you made?
Thanks Doc!
All PullMoll's emus are running fine, but some 20%-30% of the images for the emulators won't start or behave erratically.
Does all of them (i.e. the ColorGenie images) run on the real board?
Spectrum emulator starts, but Manic Miner freezes after a few seconds.
At first it seemed that it was the upper 32KB, but then larger stuff it's loading and running.
So I'll better use Catalina as soon as possible for an extensive memory test.
The mods are really minor (some not yet shown in the pics):
- A15 goes to two the LS86 gates, one inverting and the other not, and then to the CS pins of the SRAMs. Again, not necessary (a simple inverter would have been ok) but I wanted symmetric propagation delay!
- With only 64KB we have 4 "free" outputs from the LS138, I intend to put LEDs on Y4 and Y5 (to eventually detect apps accessing >64K, and for debug) and a buzzer on Y6, Y7 (a bridge driver of sorts to get a louder output).
- The five pin connector on the corner will be wired to the I2C bus, and has the pinout of the DS1307 module from SparkFun (unfortunately I got a defective one, so no hurry to connect it).
Not really mods, construction details:
- 100nF caps will fit nicely in the sockets, one per IC!
- The "bridge" connection for the DIY uSD has the role of getting near P12..P15, allow most of the hacked adapter to slide in, and hosting the pullup resistors:
Also, I originally intended to power all the 5V section from the servo supply, so the 3 pos switch could be used to select Proto/Drac mode, but then I discovered that (with this exact layout) an huge number of supply pins would fall right on VCC/GND or very near, so I gave up that option.
A simpler mod is possible by replacing the decoder with an HC139, so the second half can be used for A15 decoding and P11 would be free for something else. This saves one TTL IC.
More to come on the external VGA-to-TV&Audio adapter! :cool:
A memory test with Catalina would be useful. There is a small chance that you might need to add one more NOP deep inside the memory driver code where it actually reads and writes a byte. Catalina will show if that is a problem.
Some of the games never did work properly so it may not be your board. Pullmoll got some working but not all.
I'm interested in your I2C buss idea. I have an idea of taking this whole board and getting it running in a Gadget Gangster format and an I2C RTC is on the drawing board. Also maybe borrow some of the C3 SPI analog I/O ideas, but perhaps select them using the latches from the spare 138 outputs. I think with a modular design like the GG board these sorts of addons will be easier to do.
I'm interested in your I2C buss idea. I have an idea of taking this whole board and getting it running in a Gadget Gangster format and an I2C RTC is on the drawing board. Also maybe borrow some of the C3 SPI analog I/O ideas, but perhaps select them using the latches from the spare 138 outputs. I think with a modular design like the GG board these sorts of addons will be easier to do.
I think it's great to converge to the new official standard, and to gain access to at least some of the expansion boards! But I wonder if all the logic from the DracBlade will fit... wouldn't it be easier using the CPLD that Toby developed? Or all SMT?
I alwasys wondered why he didn't produce a batch of that simplified (but full featured) DracBlades, it's a waste!
The clock module from SparkFun it's nothing more than the chip, a 32KHz crystal, a battery, and a small capacitor: http://www.sparkfun.com/products/99
So nothing fancy, just power and SCL and SDA to the same pins of the EEPROM, pullups are already there. Sure it would be good to read back the SQW output from DS1307, but this requires another pin. If not possible, still makes for a nice cosmetic hearbeat LED on its own
I've read controversial reports on the ability of the DS1307 to work at 3.3V (mine is faulty so I can't testify ), but there are many other I2C options.
Regarding a multiplexed SPI bus: the ABC pins of another HC138 could be driven from latches, but IMHO it's fundamental to have the master enable of the decoder controlled from the former SPI CS (i.e. P15), differently from the C3. I think it's similar to how it's done on the PropCade.
This has the advantage that once a device is selected, you can use it without any changes to the standard drivers.
Here's schematic for the external TV adapter, I was amid of building the full "active" version when I noticed that the simplified one seems to work flawlessy with my TV (have to try a few more screens tough):
When I saw that the DracBlade could be used to get something like my beloved Nascom back I started to limit myself to the 64KB and save one latch just to get started using bits I had already, even if it did leave 87% of the ram unused. Then that fixation got me wondering about getting rid of a few more.
The CPLDs were really just me tying to prove, to myself, that I could get to grips with what is now anchient technology. I am one stage further than Heater, for me the past hasn't happened yet.
Due to HER requests I have lost the almost total control ( the house bunny always ranked higher than me) over the small spare room and I am now banished to the use of a cupboard (I checked first to make sure that there wasn't any lions etc at the back of it, but then all that space would be useful ...). So now I will have to concentrate less on constructing this and that (usually before this is half finished) and get some practice in in the sofware side. I still haven't got around to making the KBD on the Pullmoll emulations an English layout.
The lash up that I tried to use a SDRAM, from an old DIMM, using Jazzed's software didn't go too well. I could get 8MB testing ok but not the 16MB. This meant that I never got the chance to go bank swiching for the rest of the 64MB. Trying other SDRAMs, from the same DIMM, gave different faults, and then the homemade PCB started to give up.
I still have a desire to plant an old EDO DRAM onto a "DracBlade" and see if I could get rid of all the latch and decoder chips. Not for any good reason, just playing.
Regarding a multiplexed SPI bus: the ABC pins of another HC138 could be driven from latches, but IMHO it's fundamental to have the master enable of the decoder controlled from the former SPI CS (i.e. P15), differently from the C3. I think it's similar to how it's done on the PropCade.
This has the advantage that once a device is selected, you can use it without any changes to the standard drivers.
Due to HER requests I have lost the almost total control ( the house bunny always ranked higher than me) over the small spare room and I am now banished to the use of a cupboard (I checked first to make sure that there wasn't any lions etc at the back of it, but then all that space would be useful ...). So now I will have to concentrate less on constructing this and that (usually before this is half finished) and get some practice in in the sofware side. I still haven't got around to making the KBD on the Pullmoll emulations an English layout.
Ehrm, this sounds familiar...
To the question "You say you're building an old computer, but why you smell all that solder fumes for that? Will be really useful when you finish? Why don't you just go out and buy a new one, and get rid of all this old Smile?!?"
I saw only one way out... "Yeah, and why some people keeps on smelling all that glue, only to build an old galleon made out of matches? They can't even sail for real when they finish!"
I still have a desire to plant an old EDO DRAM onto a "DracBlade" and see if I could get rid of all the latch and decoder chips. Not for any good reason, just playing.
I still have that plan too.
Recently it came to my mind the (obvious) conclusion that "all SBCs that can be made to have external RAM in 12 pins or less should be DracBlade-ish", so only the memory subsystem would change.
This "standard" of sorts could include the original DracBlade, DRAM solutions with shared address and data, the HX512 connected on lower pins, and most of the recently proposed SPI SRAM stuff (single or multibit).
My last towel plan is for another ProtoBoard, two 256Kx4 chips (from a 256KB 30pin SIMM), AD0..AD7 plus A8 on P0..P8. Then a 74HC00 should save one pin, and generate nCAS, nWE, and nOE out of P10,P11, while keeping nRAS separate on P9 (or it was the other way around with separate nCAS, have to check). Total of 12 pins.
If we think about a generic 12 pin ram driver, there must be many solutions. 12 pins is a good compromise between speed and not using up too many precious pins on the chip.
Regarding a multiplexed SPI bus: the ABC pins of another HC138 could be driven from latches, but IMHO it's fundamental to have the master enable of the decoder controlled from the former SPI CS (i.e. P15), differently from the C3. I think it's similar to how it's done on the PropCade.
This has the advantage that once a device is selected, you can use it without any changes to the standard drivers.
Now that has me thinking about a Gadget Gangster design. Motherboard has the propeller, power supply and eeprom, but not much else. Then think about a memory board - ram, 3 latches, 138 or a variety of ram boards that you describe, and we can then mix and match all sorts of ram designs using the same GG platform.
Next - the SPI. This can be on another board if it won't all fit on the ram board. First SPI thing is the SD card.
But your comment about not changing code has me thinking. Say we have an "SPI board". It could have a separate 138 to the ram board but still decode the remaining addresses. Send that out to a latch and then as many multiplexers as needed you can then select up to 256 SPI devices. The code is simple - at bootup select the SD as the default device which would probably be address zero. If you want to select something else, send out its address, talk to it (maybe even load and unload its driver cog) then default back to the SD card.
Then all the existing code stays unchanged.
This leads to three boards - motherboard, ram and SPI board.
Attached is an early version of a Gadget Gangster motherboard. Some design considerations:
1) Switch mode power supplies (just a personal preference of mine)
2) VGA and TV on the motherboard to minimise signal path length
3) Prop plug or serial D9 download (can reuse the D9 as a serial port once programmed)
4) Mouse and Keyboard on the motherboard as mechanically stronger than on a shield
5) All tall components are on the left or right side so that the shield will fit on top. This includes capacitors, regulator, inductors and external sockets. Xtal will need to be a low profile type.
6) All DIP components - because a) I have these, b) they are easier to solder and c) most importantly, socketed DIP components can be recycled to and from other boards.
Components can be left out if not needed eg keyboard, mouse, max232 and assoc reset components, leds, VGA and TV.
SD and external ram will be on a shield - this enables various different types of external ram to be added as needed.
Looking good! :thumb:
I expecially like the placement because area is uniformly used.
Personally I really like the DB9 serial on board, but maybe in this case I would give a thought on removing it (and the MAX232) to try matching the GG Propeller Platform footprint (the non-USB kit version).
For the SPI bus, I had this plan for the I/O propeller on a tri-prop platform (now frozen due to lack of spare time), but some of the concept might be useful here as well:
- a single HC138 decoder, 8 devices should be enough!
- device #0 assigned to SD card, onboard on the SPI shield
- device #7 assigned to RTC clock, onboard on the SPI shield
- devices #1..6 to six 2x6pin PMod connectors, with the following pinout:
CS -1 7- SCL \_ I2C bus from P28,P29
MOSI -2 8- SDA / used for module autoconfiguration, if supported
MISO -3 9- AUX <- optional spare pin (or maybe nRESET??)
SCK -4 10- nINT <- open collector output from device, collected as a single line to Propeller
GND -5 11- GND
VCC -6 12- VCC
INT is supposed to be a common line from all modules, bringing the total count on the propeller side (when not using latches) to a round 8: MISO, SCK, MOSI, CS, A0, A1, A2, INT.
This way some Digilent modules could be used right away, new designed modules could use the autoconfig feature, which is similar but not identical to the recent proposal from Tubular.
In essence, we put a small I2C smt eeprom onto every SPI module, set A1,A2 pins to fixed high, and drive A0 from SPI CS.
So normally all ID-eeprom will be at address 7 (which we will avoid to scan), while the one associated with the selected module will temporary move to address 6, and there we can read it, for identification or to get its cogjet driver, or config, etc.
This also still leaves free addresses 1..5 for expanding the boot EEPROM, if required.
Some 28pin components, also available in DIP package, which could be used for SPI expansion modules:
- ENC28J60 - 10base2 ethernet
- MC23S17 - 16 bit expander with IOC feature (Bill Henning used it extensively in his products)
- MAX3110 - SPI UART with integrated RS232 tranceiver
and last but not least, the good old SX28AC/DP programmed to some specific function!
I'm finally ready to start building my Dracblade (had to wait to get access to a place to do the work), but I ran into a snag right away: The parts list (v5) and the schematics (v5) list R15 as 2k7 and R16 as 1k (I had decided to start with the power regulator part), so I soldered the 2k7 resistor into R15 (where R15 is marked on the silk screening on the PCB).
But then I took another look at a 200% photocopy I had made of the PCB.. on the PCB it says R15 is 1k, and R16 is 2k7. The other way around!
What's correct? The PCB silkscreen, or the parts list and schematic? I'm hoping for the latter as I already soldered the resistor in..
-Tor
p.s. It's been years since I did this kind of work. What a difference a couple of decades makes for the eyesight! I've had to rig a totally different setup than I used in the old times or I won't see what or where I'm doing anything. Large zoomed copies of PCB, rigs with lights and a diverse range of magnifiying equipment. Which is difficult because the stereo vision goes away. In the distant past I just used to grab the PCB and the components, put it down somewhere and solder away! That's totally out of the question now.
The good news is that it does not matter - if you have soldered these in then leave them as they are.
They are the current limiting resistors for the power supply leds. The 2k7 is for the 5V and the 1k is for the 3V, so if they are round the other way, one led will be a bit brighter than the other but that will not matter. There is often a variability in led brightness anyway.
So just leave things as they are. (They are both much higher values than they need to be as modern leds are much more efficient. Back in the olden days a 220 ohm resistor was standard for 5V).
BTW I know what you are saying about the vision getting worse as you get older!
Thanks, that's a relief. I'll continue soldering after work today. I then conclude (after taking another look at the PCB and the schematics) that the schematics is right and the PCB is wrong: the PCB has R15 close to the 5V LED, but it's marked 1K. So R15 is right but 1k is wrong. R16 is close to the 3V3 LED (near the MAX232 section) on the PCB but is marked 2k7 and should have been marked 1k. Which means that I actually soldered the 2k7 resistor in the right place then.
Hello,
I have just finished soldering up a DracBlade v10 board. It passes the psu test without blowing up :-)
I now wonder how to test it.
First I downloaded bst (I'm using Linux - Ubuntu, BTW), but found out that the Linux binaries are for 32-bit Linux, while I'm running 64-bit. I'll need to figure out a solution for that, or find another tool.
Anyway, I'm not sure about the "startup procedure" so to speak.
physical connections:
- psu
- usb-to-serial adapter connected to the serial port closest to the edge of the DracBlade board (the one with the female connector - port 1?)
- do I need av VGA monitor connected?
- do I need a keyboard?
software:
- I use bst to load something into the Propeller (emulation code?), right?
- what file should I load? if I look at the files in the archive "CPM_MPM-archive-19-Sept-2010.zip", there are many files. Is cpm.binary the file I should load?
sd card:
- will it support fat32 now?
- I just put all the *.dsk files onto it, right?
Next thing would be to test each part. First thing would be to connect the USB to serial plug into the female D9 and start up the Propeller tool software. Press F7 and it should find the propeller chip.
You don't need a keyboard or mouse or display or an SD card if you just want to write simple propeller programs - eg something that prints "hello world" back up the programming serial line once it has been downloaded.
If that works you could try something that tests everything out all at once. Kyedos is a good place to start as that will test the SD card and the keyboard and the display. There are two versions of kyedos - one for TV and one for VGA - which display will you be using?
Kyedos supports fat32.
Then from within Kyedos you could test some other programs, eg the CP/M emulation. That will test the external ram. I can send you a file if you like.
Or you could try Catalina and write your own large C programs.
Hello,
First I downloaded bst (I'm using Linux - Ubuntu, BTW), but found out that the Linux binaries are for 32-bit Linux, while I'm running 64-bit. I'll need to figure out a solution for that, or find another tool.
That should not be a problem - I run the same BST tools on 64-bit Linux as well as 32-bit Linux. My 64-bit Linux platform is Debian, and Ubuntu must for sure have the same solution for running 32-bit applications: apt-get install ia32-libs
That'll install what's needed for almost all 32-bit applications. I hope and believe that this is one of the things Ubuntu chose to inherit from Debian.
That should not be a problem - I run the same BST tools on 64-bit Linux as well as 32-bit Linux. My 64-bit Linux platform is Debian, and Ubuntu must for sure have the same solution for running 32-bit applications: apt-get install ia32-libs
That'll install what's needed for almost all 32-bit applications. I hope and believe that this is one of the things Ubuntu chose to inherit from Debian.
Well, it seems like ia32-libs is installed already:
tingo@kg-u35jc:~$ dpkg-query -l ia32-libs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-=======================-=======================-==============================================================
ii ia32-libs 20090808ubuntu9.1 ia32 shared libraries for use on amd64 and ia64 systems
I get these messages when starting bst.linux from the shell:
tingo@kg-u35jc:~/work/drac/bst$ ./bst.linux
[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF
(bst.linux:8641): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so: wrong ELF class: ELFCLASS64
(bst.linux:8641): Gtk-WARNING **: Loading IM context type 'ibus' failed
I don't know if they are harmless or not. The GTK warnings come when I press "Configure ports" in IDE preferences, or F7. The program (or GUI) hangs, and I have to kill it.
The usb to serial adapter is detected as ttyUSB0:
tingo@kg-u35jc:~$ id
uid=1000(tingo) gid=1000(tingo) groups=1000(tingo),4(adm),20(dialout),24(cdrom),46(plugdev),105(lpadmin),118(admin),121(sambashare),127(vboxusers)
First thing would be to connect the USB to serial plug into the female D9 and start up the Propeller tool software. Press F7 and it should find the propeller chip.
I tried with bst (since I'm on Linux - I have no windows machines here), but when I press F7, bst just hangs and has to be killed.
You don't need a keyboard or mouse or display or an SD card if you just want to write simple propeller programs - eg something that prints "hello world" back up the programming serial line once it has been downloaded.
If that works you could try something that tests everything out all at once. Kyedos is a good place to start as that will test the SD card and the keyboard and the display.
I can't use the keyboard just yet - I'm missing R3 and R4 so I'll have to find a couple of 100R resistors first.
The wiki mentions a Python tool for loading code into the Propeller - that script might work on Linux Unfortunately the forum link is broken. Does anyone know how to locate that tool?
. Good news there - Kyedos does work with a serial console as well. The program accepts input from either a keyboard or a serial port, and output is to both the serial port, and to either vga or tv, plus output also goes to the 20x4 LCD display if you have installed those components.
But first step is to get the proptool to recognise a prop is connected. (or you could try downloading any spin program, just to see if it downloads). That will test out the propeller and the max232 and the reset transistor circuit. If that works you can try an F11 download which will test out the eeprom.
If BST hangs with F7, maybe we need to go back one step, and just check that Linux has recognised the USB to serial plug and installed the appropriate drivers. Windows does that automatically but I am not sure about Linux.
In windows, Control Panel/System/Hardware/Device Manager and check on Com Ports. I hope we have a Linux expert who can describe the equivalent in Linux.
tingo: Broken links were caused when the forum software was changed. I know there is a converter somewhere, but if you just insert "inc" after "parallax" in the link url you will e sent to the old forum. Once you know the thread title you can search for it here using the advanced search.
tingo: Broken links were caused when the forum software was changed. I know there is a converter somewhere, but if you just insert "inc" after "parallax" in the link url you will e sent to the old forum. Once you know the thread title you can search for it here using the advanced search.
. Good news there - Kyedos does work with a serial console as well. The program accepts input from either a keyboard or a serial port, and output is to both the serial port, and to either vga or tv, plus output also goes to the 20x4 LCD display if you have installed those components.
But first step is to get the proptool to recognise a prop is connected. (or you could try downloading any spin program, just to see if it downloads). That will test out the propeller and the max232 and the reset transistor circuit. If that works you can try an F11 download which will test out the eeprom.
I will try scrounge up a Windows machine to test with.
If BST hangs with F7, maybe we need to go back one step, and just check that Linux has recognised the USB to serial plug and installed the appropriate drivers. Windows does that automatically but I am not sure about Linux.
Linux does too. I have already verified that the adapter is correctly seen, and that my user has neccessary rights to it, see post 801.
While you are testing, any chance you could take a couple of photos, one of the top side and one of the solder side of the board. I might be able to see something wrong. Thx.
Latest update: I found a few minutes today to test with a Windows machine, and the Propeller Tool. F7 didn't detect the DracBlade (which was connected on COM7, and that port was scanned). The only reaction I saw on the board was that the green LED on the serial port blinked.
It seems I have some debugging to do. Will be back later.
Well, it seems like ia32-libs is installed already:
I get these messages when starting bst.linux from the shell:
tingo@kg-u35jc:~/work/drac/bst$ ./bst.linux
[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF
(bst.linux:8641): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so: wrong ELF class: ELFCLASS64
(bst.linux:8641): Gtk-WARNING **: Loading IM context type 'ibus' failed
The ELFCLASS64 is unexpected. 'ldd bst.linux|grep -v lib32' should only show
However, I just did an OS upgrade and now suddenly BST hangs, after one of those VK warnings. I don't recall if I got those one the 32 bit system. I will do more checks at a later stage.
Comments
Here's a "MiniDrac" with 2x 32KB SRAM chips salvaged from an old scrapped motherboard:
Inserted in the multiboard Parallax case:
There's no "good" and "bad" without "the ugly":
The wiring could have been done much more easily, I only realized at 60% of wiring that my fixation for "almost equal length wire trunks" was not only difficult to manage, but also not much needed or useful for timing.
Thanks to Dr_Acula for the original design, and also Toby Seckshund for his inspiring work on DracBlade variations.
If anyone is interested in the minor mods from the standard DracBlade, just let me know.
Have you run the retro computers and big Catalina programs yet?
Also what where the modifications you made?
Thanks Doc!
All PullMoll's emus are running fine, but some 20%-30% of the images for the emulators won't start or behave erratically.
Does all of them (i.e. the ColorGenie images) run on the real board?
Spectrum emulator starts, but Manic Miner freezes after a few seconds.
At first it seemed that it was the upper 32KB, but then larger stuff it's loading and running.
So I'll better use Catalina as soon as possible for an extensive memory test.
The mods are really minor (some not yet shown in the pics):
- A15 goes to two the LS86 gates, one inverting and the other not, and then to the CS pins of the SRAMs. Again, not necessary (a simple inverter would have been ok) but I wanted symmetric propagation delay!
- With only 64KB we have 4 "free" outputs from the LS138, I intend to put LEDs on Y4 and Y5 (to eventually detect apps accessing >64K, and for debug) and a buzzer on Y6, Y7 (a bridge driver of sorts to get a louder output).
- The five pin connector on the corner will be wired to the I2C bus, and has the pinout of the DS1307 module from SparkFun (unfortunately I got a defective one, so no hurry to connect it).
Not really mods, construction details:
- 100nF caps will fit nicely in the sockets, one per IC!
- The "bridge" connection for the DIY uSD has the role of getting near P12..P15, allow most of the hacked adapter to slide in, and hosting the pullup resistors:
Also, I originally intended to power all the 5V section from the servo supply, so the 3 pos switch could be used to select Proto/Drac mode, but then I discovered that (with this exact layout) an huge number of supply pins would fall right on VCC/GND or very near, so I gave up that option.
A simpler mod is possible by replacing the decoder with an HC139, so the second half can be used for A15 decoding and P11 would be free for something else. This saves one TTL IC.
More to come on the external VGA-to-TV&Audio adapter! :cool:
Alessandro
A memory test with Catalina would be useful. There is a small chance that you might need to add one more NOP deep inside the memory driver code where it actually reads and writes a byte. Catalina will show if that is a problem.
Some of the games never did work properly so it may not be your board. Pullmoll got some working but not all.
I'm interested in your I2C buss idea. I have an idea of taking this whole board and getting it running in a Gadget Gangster format and an I2C RTC is on the drawing board. Also maybe borrow some of the C3 SPI analog I/O ideas, but perhaps select them using the latches from the spare 138 outputs. I think with a modular design like the GG board these sorts of addons will be easier to do.
I think it's great to converge to the new official standard, and to gain access to at least some of the expansion boards! But I wonder if all the logic from the DracBlade will fit... wouldn't it be easier using the CPLD that Toby developed? Or all SMT?
I alwasys wondered why he didn't produce a batch of that simplified (but full featured) DracBlades, it's a waste!
The clock module from SparkFun it's nothing more than the chip, a 32KHz crystal, a battery, and a small capacitor: http://www.sparkfun.com/products/99
So nothing fancy, just power and SCL and SDA to the same pins of the EEPROM, pullups are already there. Sure it would be good to read back the SQW output from DS1307, but this requires another pin. If not possible, still makes for a nice cosmetic hearbeat LED on its own
I've read controversial reports on the ability of the DS1307 to work at 3.3V (mine is faulty so I can't testify
Regarding a multiplexed SPI bus: the ABC pins of another HC138 could be driven from latches, but IMHO it's fundamental to have the master enable of the decoder controlled from the former SPI CS (i.e. P15), differently from the C3. I think it's similar to how it's done on the PropCade.
This has the advantage that once a device is selected, you can use it without any changes to the standard drivers.
Here's schematic for the external TV adapter, I was amid of building the full "active" version when I noticed that the simplified one seems to work flawlessy with my TV (have to try a few more screens tough):
The CPLDs were really just me tying to prove, to myself, that I could get to grips with what is now anchient technology. I am one stage further than Heater, for me the past hasn't happened yet.
Due to HER requests I have lost the almost total control ( the house bunny always ranked higher than me) over the small spare room and I am now banished to the use of a cupboard (I checked first to make sure that there wasn't any lions etc at the back of it, but then all that space would be useful ...). So now I will have to concentrate less on constructing this and that (usually before this is half finished) and get some practice in in the sofware side. I still haven't got around to making the KBD on the Pullmoll emulations an English layout.
The lash up that I tried to use a SDRAM, from an old DIMM, using Jazzed's software didn't go too well. I could get 8MB testing ok but not the 16MB. This meant that I never got the chance to go bank swiching for the rest of the 64MB. Trying other SDRAMs, from the same DIMM, gave different faults, and then the homemade PCB started to give up.
I still have a desire to plant an old EDO DRAM onto a "DracBlade" and see if I could get rid of all the latch and decoder chips. Not for any good reason, just playing.
Alan
Ehrm, this sounds familiar...
To the question "You say you're building an old computer, but why you smell all that solder fumes for that? Will be really useful when you finish? Why don't you just go out and buy a new one, and get rid of all this old Smile?!?"
I saw only one way out... "Yeah, and why some people keeps on smelling all that glue, only to build an old galleon made out of matches? They can't even sail for real when they finish!"
I still have that plan too.
Recently it came to my mind the (obvious) conclusion that "all SBCs that can be made to have external RAM in 12 pins or less should be DracBlade-ish", so only the memory subsystem would change.
This "standard" of sorts could include the original DracBlade, DRAM solutions with shared address and data, the HX512 connected on lower pins, and most of the recently proposed SPI SRAM stuff (single or multibit).
My last towel plan is for another ProtoBoard, two 256Kx4 chips (from a 256KB 30pin SIMM), AD0..AD7 plus A8 on P0..P8. Then a 74HC00 should save one pin, and generate nCAS, nWE, and nOE out of P10,P11, while keeping nRAS separate on P9 (or it was the other way around with separate nCAS, have to check). Total of 12 pins.
If we think about a generic 12 pin ram driver, there must be many solutions. 12 pins is a good compromise between speed and not using up too many precious pins on the chip.
Now that has me thinking about a Gadget Gangster design. Motherboard has the propeller, power supply and eeprom, but not much else. Then think about a memory board - ram, 3 latches, 138 or a variety of ram boards that you describe, and we can then mix and match all sorts of ram designs using the same GG platform.
Next - the SPI. This can be on another board if it won't all fit on the ram board. First SPI thing is the SD card.
But your comment about not changing code has me thinking. Say we have an "SPI board". It could have a separate 138 to the ram board but still decode the remaining addresses. Send that out to a latch and then as many multiplexers as needed you can then select up to 256 SPI devices. The code is simple - at bootup select the SD as the default device which would probably be address zero. If you want to select something else, send out its address, talk to it (maybe even load and unload its driver cog) then default back to the SD card.
Then all the existing code stays unchanged.
This leads to three boards - motherboard, ram and SPI board.
This GG standard could be very useful.
1) Switch mode power supplies (just a personal preference of mine)
2) VGA and TV on the motherboard to minimise signal path length
3) Prop plug or serial D9 download (can reuse the D9 as a serial port once programmed)
4) Mouse and Keyboard on the motherboard as mechanically stronger than on a shield
5) All tall components are on the left or right side so that the shield will fit on top. This includes capacitors, regulator, inductors and external sockets. Xtal will need to be a low profile type.
6) All DIP components - because a) I have these, b) they are easier to solder and c) most importantly, socketed DIP components can be recycled to and from other boards.
Components can be left out if not needed eg keyboard, mouse, max232 and assoc reset components, leds, VGA and TV.
SD and external ram will be on a shield - this enables various different types of external ram to be added as needed.
I expecially like the placement because area is uniformly used.
Personally I really like the DB9 serial on board, but maybe in this case I would give a thought on removing it (and the MAX232) to try matching the GG Propeller Platform footprint (the non-USB kit version).
For the SPI bus, I had this plan for the I/O propeller on a tri-prop platform (now frozen due to lack of spare time), but some of the concept might be useful here as well:
- a single HC138 decoder, 8 devices should be enough!
- device #0 assigned to SD card, onboard on the SPI shield
- device #7 assigned to RTC clock, onboard on the SPI shield
- devices #1..6 to six 2x6pin PMod connectors, with the following pinout:
INT is supposed to be a common line from all modules, bringing the total count on the propeller side (when not using latches) to a round 8: MISO, SCK, MOSI, CS, A0, A1, A2, INT.
This way some Digilent modules could be used right away, new designed modules could use the autoconfig feature, which is similar but not identical to the recent proposal from Tubular.
In essence, we put a small I2C smt eeprom onto every SPI module, set A1,A2 pins to fixed high, and drive A0 from SPI CS.
So normally all ID-eeprom will be at address 7 (which we will avoid to scan), while the one associated with the selected module will temporary move to address 6, and there we can read it, for identification or to get its cogjet driver, or config, etc.
This also still leaves free addresses 1..5 for expanding the boot EEPROM, if required.
Some 28pin components, also available in DIP package, which could be used for SPI expansion modules:
- ENC28J60 - 10base2 ethernet
- MC23S17 - 16 bit expander with IOC feature (Bill Henning used it extensively in his products)
- MAX3110 - SPI UART with integrated RS232 tranceiver
and last but not least, the good old SX28AC/DP programmed to some specific function!
But then I took another look at a 200% photocopy I had made of the PCB.. on the PCB it says R15 is 1k, and R16 is 2k7. The other way around!
What's correct? The PCB silkscreen, or the parts list and schematic? I'm hoping for the latter as I already soldered the resistor in..
-Tor
p.s. It's been years since I did this kind of work. What a difference a couple of decades makes for the eyesight! I've had to rig a totally different setup than I used in the old times or I won't see what or where I'm doing anything. Large zoomed copies of PCB, rigs with lights and a diverse range of magnifiying equipment. Which is difficult because the stereo vision goes away. In the distant past I just used to grab the PCB and the components, put it down somewhere and solder away! That's totally out of the question now.
They are the current limiting resistors for the power supply leds. The 2k7 is for the 5V and the 1k is for the 3V, so if they are round the other way, one led will be a bit brighter than the other but that will not matter. There is often a variability in led brightness anyway.
So just leave things as they are. (They are both much higher values than they need to be as modern leds are much more efficient. Back in the olden days a 220 ohm resistor was standard for 5V).
BTW I know what you are saying about the vision getting worse as you get older!
-Tor
I have just finished soldering up a DracBlade v10 board. It passes the psu test without blowing up :-)
I now wonder how to test it.
First I downloaded bst (I'm using Linux - Ubuntu, BTW), but found out that the Linux binaries are for 32-bit Linux, while I'm running 64-bit. I'll need to figure out a solution for that, or find another tool.
Anyway, I'm not sure about the "startup procedure" so to speak.
physical connections:
- psu
- usb-to-serial adapter connected to the serial port closest to the edge of the DracBlade board (the one with the female connector - port 1?)
- do I need av VGA monitor connected?
- do I need a keyboard?
software:
- I use bst to load something into the Propeller (emulation code?), right?
- what file should I load? if I look at the files in the archive "CPM_MPM-archive-19-Sept-2010.zip", there are many files. Is cpm.binary the file I should load?
sd card:
- will it support fat32 now?
- I just put all the *.dsk files onto it, right?
BTW, I'm not Tor.
Next thing would be to test each part. First thing would be to connect the USB to serial plug into the female D9 and start up the Propeller tool software. Press F7 and it should find the propeller chip.
You don't need a keyboard or mouse or display or an SD card if you just want to write simple propeller programs - eg something that prints "hello world" back up the programming serial line once it has been downloaded.
If that works you could try something that tests everything out all at once. Kyedos is a good place to start as that will test the SD card and the keyboard and the display. There are two versions of kyedos - one for TV and one for VGA - which display will you be using?
Kyedos supports fat32.
Then from within Kyedos you could test some other programs, eg the CP/M emulation. That will test the external ram. I can send you a file if you like.
Or you could try Catalina and write your own large C programs.
That'll install what's needed for almost all 32-bit applications. I hope and believe that this is one of the things Ubuntu chose to inherit from Debian.
-Tor
The usb to serial adapter is detected as ttyUSB0: and my user has access to it: I don't know what the problem is.
I tried with bst (since I'm on Linux - I have no windows machines here), but when I press F7, bst just hangs and has to be killed.
Good.
I can't use the keyboard just yet - I'm missing R3 and R4 so I'll have to find a couple of 100R resistors first. So no KyeDOS version for a serial console?
But first step is to get the proptool to recognise a prop is connected. (or you could try downloading any spin program, just to see if it downloads). That will test out the propeller and the max232 and the reset transistor circuit. If that works you can try an F11 download which will test out the eeprom.
If BST hangs with F7, maybe we need to go back one step, and just check that Linux has recognised the USB to serial plug and installed the appropriate drivers. Windows does that automatically but I am not sure about Linux.
In windows, Control Panel/System/Hardware/Device Manager and check on Com Ports. I hope we have a Linux expert who can describe the equivalent in Linux.
That little trick is useful - thanks!
Cool - thanks!
I will try scrounge up a Windows machine to test with.
Linux does too. I have already verified that the adapter is correctly seen, and that my user has neccessary rights to it, see post 801.
It seems I have some debugging to do. Will be back later.
linux-gate.so.1 => (0xf76e8000)
/lib/ld-linux.so.2 (0xf76e9000)
However, I just did an OS upgrade and now suddenly BST hangs, after one of those VK warnings. I don't recall if I got those one the 32 bit system. I will do more checks at a later stage.
-Tor