Attached is a zip of version 10 of the board (Eagle source files). I have a number of version 9 boards, and version 9 has been soldered up and tested. Version 10 has some minor cosmetic changes - solder pads for the vga socket, bigger holes for the DC plug, and there is a 20 way header for 8 inputs and 8 outputs, as well as those same I/O pins going to a D25 parallel port. Version 10 is being made now. The changes to each version are becoming more cosmetic now.
So specifications are:
512k ram
Keyboard
Mouse
VGA display socket
TV display socket
Audio
Two serial ports
Parallel port
8 general input pins and 8 general output pins
Propplug socket
Onboard regulators (pads for 3 types of 3V and 3 types of 5V)
Prototyping area
16 way header for 20x4 LCD display
I have a number of version 5 boards available as well. (Versions 6 to 8 changed the layout of the board, and both the sd card and memory were unstable if they were not in the correct position, so version 9 goes back to the version 5 layout. Hence the mouse for instance is some distance from the propeller, but the sd card is much closer).
This design is open source, so anybody is free to take the attached Eagle files and make their own boards if they want to.
I had problems with stray capacitances etc, but only when the faster SD drivers were implimented. I had to cut the tracks that went 7-8cm and then into 5cm of IDC ribbon. To make things a bit more tricky for it that was an open cct then.
This is supposed to be retro, so it should be slowed down !
Still fighting the Xilinx ISE, just when I think I have got the hang of it ...
I went for the 8 INs and 8 OUTs as the general port. There are about another 11 or so pins that I didn't even bother about wiring up. The extra two on the LCD port are brought out onto some pads ( not that I have put a LCD onto it yet)
There is a shortage of decoder options for any more "ports"
A while ago I thought about putting a Dracblade into a PC keyboard, so that it was a bit more disguised on the work bench. Although I no longer work at the place that had all the nosey gits, I thought that with all the graveyard bits I should get the folly seen through.
As usual with me the keyboard had suffered other versions of projects and so I was obliged to use the same hole (mostly). As the SD card is a bit fussy about the lead lenths I was forced into making one, large one. The Auxcillary Rear Software Enclosure was the result. I will have to think up an acronym for it.
One more bit of irony, the KBD controller is a Z8 sort, so is probably more advanced than the thing is helping to emulate.
This looks like fun. I like the board layout. There seems to be plenty more space to add a longer board with serial ports etc. I'm not quite so sure about your Auxilliary Rear Software Enclosure acronym. I'm getting behind with what you are doing. I'll study it more to get to the bottom of it all.
This is just a 64KB limited '374 sort. The case did have a couple of old phone batteries in it so I put on a simple charging cct, but they had died so I stripped off those bits. Because of the height restrictions I had to solder the chips into the PCB, but that allowed easier double-sided layouts. The space to the right is where the KBD controller goes so only the LHS 2.5" are up for grabs. With SM bits there would be so much more space available, but that would break the "BIg Chips"" ethos.
(it hasn't been in there for 24 hours yet, and mod are being thought about)
A while ago you asked about the Z180 pin connections, I have found the cct diag for the old Panasonic DVC deck front panel but it really only uses the usual suspects of Addr, Data and controls, it doesn't do anything fancy such as DMAs.
If any of this could be of help then I could write down a list of pins used.
I have a board made that integrates a Z80 but both Z80 and Z180 are on the back burner at the moment, as the big program I am working on ran out of memory on a Z80. I guess that was always going to happen - first it ran out at 32k on a propeller then ran out at 50k on CP/M.
So I have become distracted and am now looking at Catalina and even the remote possibility of Big Spin.
Does the Dracblade allow C programs (or any other source program) > 32K using the additional memory on board, or is the memory strictly for data tables, etc?
Yes, it can run a C program up to 512k. You can start coding in Catalina and code for days and days and not have to worry about running out of memory. Catalina can be setup to run either in local memory, or fully in external memory. Both options are useful. Running in local memory, downloads are much quicker so debugging the code takes much less time. Running in external memory allows some clever things that can't be done in Spin, like wiping virtually the entire hub memory clean and then using it for a video buffer. You don't have to think about where to put data tables - Catalina sorts all that out for you. But if you really want a data table in a specific location, Catalina can do that too.
I see in another post you wanted a small display. The Dracblade has a 20x4 display with driver code.
I see also you posted on Cluso's triblade thread. I should mention that the Dracblade started off life as the Triblade. By sacrificing a little speed it is possible to get everything running in one propeller.
Catalina makes it much easier to port code between these different boards.
The board and design are all open source. You can make your own boards from the Eagle files if you want.
Ages ago I bought three v5 DracBlade PCBs from Dr_Acula but didn't get around to doing anything with them until recently. I stuffed one of the boards, verified that the power supplies were working correctly and powered it up with the USB2Serial cable that I got from Dr_Acula. Unfortunately, the Propeller Tool can't seem to find the Propeller chip. I've always used FTDI connections to my Propeller boards up until now. Is there some trick to getting a USB2Serial connection working? Unfortunately, I don't have the resistor pack that is used by the serial LEDs so I can't use those to verify that there is data coming from the PC. Does anyone know any trick for debugging this sort of problem? I've looked over the board and don't see any obvious assembly errors.
I did a little more testing of my board and if I measure the voltage between Vss and RESn it is about 1.2v and doesn't change even if I try to use the "Identify hardware..." option in the Propeller Tool. Shouldn't "Identify Hardware" attempt to reset the Propeller chip by pulling that pin low? Or would that be so short a pulse that I wouldn't be able to see it on a multimeter?
The reset pulse is pretty short - probably too short for a digital multimeter but you might see a kick of the needle on an analog meter.
The leds are quite helpful. The network is 4 resistors with a common on pin 1. I saw someone on another post build this with 4 resistors mounted vertically and then with the last one use that as the common along the top and then bend it down to the left most hole.
I assume windows has recognised the usb to serial device? And hopefully isn't confused between that driver and the one that is on the prop board?
Could you take a quick picture of both sides of the board and post that?
The reset pulse is pretty short - probably too short for a digital multimeter but you might see a kick of the needle on an analog meter.
Sorry, I have a digital meter.
The leds are quite helpful. The network is 4 resistors with a common on pin 1. I saw someone on another post build this with 4 resistors mounted vertically and then with the last one use that as the common along the top and then bend it down to the left most hole.
I guess I could do that but I'd rather not mess up my board. Maybe I'll order the resistor pack.
I assume windows has recognised the usb to serial device? And hopefully isn't confused between that driver and the one that is on the prop board?
Windows sees the USB2Serial device. I even tried a different USB2Serial device I have that I know works without an difference.
Could you take a quick picture of both sides of the board and post that?
They are attached. They aren't as clear as I'd like. If you can't make them out well enough I can try to take better pictures.
Ah, I think I know what it is. You got the board some months back, and I send you the parts more recently. In the meantime, Pullmoll did some experiments with the timing pulse of the reset line with the Proptool, BST and Homespun, and we concluded that it needed to reset on (I think) the leading rather than the trailing edge.
So... Can you check that transistor? I suspect you have a BC557 and for this older board you need a BC547.
If so, then you will need to unsolder that one (sorry!) and put in a new one. Any general purpose PNP switching transistor will do, but we will need to check the pinouts.
Ah, I think I know what it is. You got the board some months back, and I send you the parts more recently. In the meantime, Pullmoll did some experiments with the timing pulse of the reset line with the Proptool, BST and Homespun, and we concluded that it needed to reset on (I think) the leading rather than the trailing edge.
So... Can you check that transistor? I suspect you have a BC557 and for this older board you need a BC547.
If so, then you will need to unsolder that one (sorry!) and put in a new one. Any general purpose PNP switching transistor will do, but we will need to check the pinouts.
You're right that I have a BC557B and the stencil on the board calls for a BC549B.
Wow, you are working fast. Already unsoldered and resoldered.
Well if you can detect the propeller then a lot of things are working now. Have you got a test program? Kyedos is one place to start. Maybe then try the Z80 simulations?
Now that I have my DracBlade working I'd like to try using the SRAM chip. I'd like to try to use this as external memory for ZOG either by interfacing it directly using jazzed's JCACHE interface or maybe using VMCOG. Has anyone gotten ZOG to run on the DracBlade already? I looked at the ZOG sources and the VMCOG thread and it doesn't seem that either of these has been ported to the DracBlade yet. Also, where do I find a description of the DracBlade hardware? I know where to find the schematic but I was hoping for some description of how the SRAM interface works and maybe some sample code.
Now you are getting into the cutting edge stuff! It would be cool to see it running zog.
This is the sram driver. A few lines of spin for easy interface, and mostly pasm for speed. (There is a pure spin interface but it is so painfully slow it has been superseded by this one)
The data is grouped in blocks of 64k, so most of the time you are only changing two latches rather than three, and that increases the speed. A flat 512k driver would check if the 64k block is different from before and would issue an H command to change the high latch.
See attached spin file. This was some demo code I used to test this
PRI Peek_Ram | a ' read the value in a ram location
' pass address in DMA 80H=LSB, 81H=middle byte, 82H=MSB
PeekPokeSetup
a:=buff[1]<<8 | buff[0] ' 0 to 65535 combine two bytes
RamLatches.DoCmd("R", @buff, a, 1) ' value to buff[0] ' need to use buffcog with no @
io_data:=buff[0]
HighLatchZero
PRI Poke_Ram | a ' read the value in a ram location
' pass address in DMA 80H=LSB, 81H=middle byte, 82H=MSB
PeekPokeSetup
a:=buff[1]<<8 | buff[0] ' 0 to 65535 combine two bytes
buff[0]:=io_data ' put io_data in buff array ready to output
RamLatches.DoCmd("W", @buff, a, 1) ' write io_data which is in buff[0] ' need to use buffcog with no @
HighLatchZero
PRI PeekPokeSetup
RamLatches.DoCmd("R", @buff, $80, 3) ' read 3 bytes from DMA area to buff array ' need to use buffcog with no @
HighLatchByte :=buff[2] << 16 ' multiply by 65536 to get high byte
RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' setup high byte
}' ------------------------------------------------------------------
PUB HighLatchZero ' led off and bank 0
HighLatchByte :=%00000000_00000000_00000000_00000000 ' xxxxxxxx_nnnnnnnn_xxxxxxxx_xxxxxxxx where n is A16 to A23
RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' restore for CP/M
Comments
So specifications are:
512k ram
Keyboard
Mouse
VGA display socket
TV display socket
Audio
Two serial ports
Parallel port
8 general input pins and 8 general output pins
Propplug socket
Onboard regulators (pads for 3 types of 3V and 3 types of 5V)
Prototyping area
16 way header for 20x4 LCD display
I have a number of version 5 boards available as well. (Versions 6 to 8 changed the layout of the board, and both the sd card and memory were unstable if they were not in the correct position, so version 9 goes back to the version 5 layout. Hence the mouse for instance is some distance from the propeller, but the sd card is much closer).
This design is open source, so anybody is free to take the attached Eagle files and make their own boards if they want to.
This is supposed to be retro, so it should be slowed down !
Still fighting the Xilinx ISE, just when I think I have got the hang of it ...
The logic is programmed but I won't be able to test it untill tomorrow
Prop, Mem, Eep and Max = 42mA
" + VGA lead attatched = 55mA
" + SD card = 65mA
" + KBD = 75mA
" + XC9572 = 150mA
" + running CPM = 200mA pk, 180mA idle
(all at usual 5MHz)
So the CPLD is not so good on power take, although it is the 5 Volt non-low power version
This is *very* impressive. How many I/O pins does this give you now?
There is a shortage of decoder options for any more "ports"
((Pic failure))
A while ago I thought about putting a Dracblade into a PC keyboard, so that it was a bit more disguised on the work bench. Although I no longer work at the place that had all the nosey gits, I thought that with all the graveyard bits I should get the folly seen through.
As usual with me the keyboard had suffered other versions of projects and so I was obliged to use the same hole (mostly). As the SD card is a bit fussy about the lead lenths I was forced into making one, large one. The Auxcillary Rear Software Enclosure was the result. I will have to think up an acronym for it.
One more bit of irony, the KBD controller is a Z8 sort, so is probably more advanced than the thing is helping to emulate.
Is this a CPLD version?
(it hasn't been in there for 24 hours yet, and mod are being thought about)
A while ago you asked about the Z180 pin connections, I have found the cct diag for the old Panasonic DVC deck front panel but it really only uses the usual suspects of Addr, Data and controls, it doesn't do anything fancy such as DMAs.
If any of this could be of help then I could write down a list of pins used.
So I have become distracted and am now looking at Catalina and even the remote possibility of Big Spin.
Thanks.
I see in another post you wanted a small display. The Dracblade has a 20x4 display with driver code.
http://www.smarthome.viviti.com/propeller for some photos etc
I'm using this http://forums.parallax.com/showthread.php?128553-Better-than-sliced-bread!-SD3.01-FAT16-32-Driver-Updated! as an operating system.
I see also you posted on Cluso's triblade thread. I should mention that the Dracblade started off life as the Triblade. By sacrificing a little speed it is possible to get everything running in one propeller.
Catalina makes it much easier to port code between these different boards.
The board and design are all open source. You can make your own boards from the Eagle files if you want.
Thanks,
David
The leds are quite helpful. The network is 4 resistors with a common on pin 1. I saw someone on another post build this with 4 resistors mounted vertically and then with the last one use that as the common along the top and then bend it down to the left most hole.
I assume windows has recognised the usb to serial device? And hopefully isn't confused between that driver and the one that is on the prop board?
Could you take a quick picture of both sides of the board and post that?
Thanks,
David
So... Can you check that transistor? I suspect you have a BC557 and for this older board you need a BC547.
If so, then you will need to unsolder that one (sorry!) and put in a new one. Any general purpose PNP switching transistor will do, but we will need to check the pinouts.
You're right that I have a BC557B and the stencil on the board calls for a BC549B.
If not, I can put together a package of some more parts and post it asap.-
Have you got any 2N2222 transistors?
Looking at the TO92 pinout, I think it goes the other way ie EBC. So that one would go in with the writing facing the other way.
http://www.nxp.com/documents/data_sheet/BC549_550.pdf
http://www.fairchildsemi.com/ds/PN/PN2222A.pdf
Well if you can detect the propeller then a lot of things are working now. Have you got a test program? Kyedos is one place to start. Maybe then try the Z80 simulations?
Thanks,
David
This is the sram driver. A few lines of spin for easy interface, and mostly pasm for speed. (There is a pure spin interface but it is so painfully slow it has been superseded by this one)
The data is grouped in blocks of 64k, so most of the time you are only changing two latches rather than three, and that increases the speed. A flat 512k driver would check if the 64k block is different from before and would issue an H command to change the high latch.
See attached spin file. This was some demo code I used to test this
PRI Peek_Ram | a ' read the value in a ram location ' pass address in DMA 80H=LSB, 81H=middle byte, 82H=MSB PeekPokeSetup a:=buff[1]<<8 | buff[0] ' 0 to 65535 combine two bytes RamLatches.DoCmd("R", @buff, a, 1) ' value to buff[0] ' need to use buffcog with no @ io_data:=buff[0] HighLatchZero PRI Poke_Ram | a ' read the value in a ram location ' pass address in DMA 80H=LSB, 81H=middle byte, 82H=MSB PeekPokeSetup a:=buff[1]<<8 | buff[0] ' 0 to 65535 combine two bytes buff[0]:=io_data ' put io_data in buff array ready to output RamLatches.DoCmd("W", @buff, a, 1) ' write io_data which is in buff[0] ' need to use buffcog with no @ HighLatchZero PRI PeekPokeSetup RamLatches.DoCmd("R", @buff, $80, 3) ' read 3 bytes from DMA area to buff array ' need to use buffcog with no @ HighLatchByte :=buff[2] << 16 ' multiply by 65536 to get high byte RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' setup high byte }' ------------------------------------------------------------------ PUB HighLatchZero ' led off and bank 0 HighLatchByte :=%00000000_00000000_00000000_00000000 ' xxxxxxxx_nnnnnnnn_xxxxxxxx_xxxxxxxx where n is A16 to A23 RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' restore for CP/M