Dr_Acula said...
Thinking of wordstar, this doesn't seem to fit in MP/M but I might see if I can find the setup program and see if it has a setting for running it with less memory available.
For me it works. At least a version with 80x25 screen size works. Perhaps your 80x40 uses more buffer and then fails to run? (Does it? Did you try to run it?)
Here's the latest version of the SPI code. Seem to have trimmed out 42 longs, now down to 480, identical functionality to the last one I posted. Also tidied up some calls/jumps and cleaned up some of the comments.
My system is running on VGA and I can't run Wordstar, I get a load of random strings on the screen when I try and run it, seems to be a selection of strings from io.spin (warnings about contiguity etc.) Other applications seem to be working okay. Oddly enough it doesn't seem to be working in CP/M either :-S not really sure what to do there and I don't really have time to debug it at the moment.
Edit: Further details
I was using the VGA as the primary monitor, however switching back to serial primary wordstar seems to be working, I was just using the terminal in BST that doesn't seem to do any VT codes. In this mode Wordstar starts in either CP/M or MP/M. Have there been any changes to the VT100 code that could be causing these problems?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Post Edited (hairymnstr) : 5/6/2010 8:29:21 PM GMT
Cluso99 said...
pullmoll: Thankyou, they are easy to implement and I have the space in cog for that.
Obviously I cannot do highlite & inverse together. So do I make both inverse or ignore one of them?
I think inverse is more important, as Wordstar uses it to show selected blocks of text.
Highlite is used for the command letters in the menu and you know them anyway after some time.
hairymnstr said...
Here's the latest version of the SPI code. Seem to have trimmed out 42 longs, now down to 480, identical functionality to the last one I posted. Also tidied up some calls/jumps and cleaned up some of the comments.
My system is running on VGA and I can't run Wordstar, I get a load of random strings on the screen when I try and run it, seems to be a selection of strings from io.spin (warnings about contiguity etc.) Other applications seem to be working okay. Oddly enough it doesn't seem to be working in CP/M either :-S not really sure what to do there and I don't really have time to debug it at the moment.
Edit: Further details
I was using the VGA as the primary monitor, however switching back to serial primary wordstar seems to be working, I was just using the terminal in BST that doesn't seem to do any VT codes. In this mode Wordstar starts in either CP/M or MP/M. Have there been any changes to the VT100 code that could be causing these problems?
Thanks for the updated DracBlade_spi. I'll include it in my lib directory.
No, the BST terminal is not emulating VT100. I have to try the primary VGA + keyboard mode to see if it makes any difference. It could be I missed swapping one of the functions accessing the ports for the console #0 I/O. The vt100 code is unchanged since several versions of qz80 now.
Edit: It seems vt100 dies when trying to change the highlite attribute to on, i.e. print chr$(27);"[noparse][[/noparse]1m". I'll investigate the cause for this and try to fix it.
Found: The color table was once for 64 rows, while it now is for as many rows as the video mode has, i.e. 40. There was a loop filling 64 words in vt100 still, now overwriting whatever was behind that color table in hub RAM.
Now I remembered that at some point I used wsu.com to create a new ws.com from. wsu.com is the unmodified, original version AFAIK, and I used it to change the terminal to ANSI (which is essentially VT100) and 25 screen rows with wschange.com.
The latest DracBlade runs ok (on Nascom test anyway)
The box has been many things before, hence too many plugs, sockets and holes. It has 2AH of batts (8.4V, 2x,cells) along with their charger and 5V and 3.3V regs.
I have included an input port, yet to impliment, to get some parallel I/O. There is a 25 pin on the back panel so I may as well use it.
The retro, clunky look/feel is intentional, of course
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/10/2010 7:16:52 PM GMT
Hey, that looks nifty. A homebrew computer. Can you put Space Invaders on the NASCOM software and take a picture of the whole thing - screen, keyboard, innards? I reckon that would be a cool picture. Probably worthy of Hackaday or Make?
I'm working on the wireless code today - hopefully will have something soon!
As an aside, I had an email today from someone in the Netherlands regarding the cost of the memory chip from Future Electronics. It is the same problem here in Australia: $30 shipping for a $4 chip. I bought a few more chips and the vga sockets which made the shipping less per part, but it is still a bit expensive.
So I did a search and Farnell seem to have these chips too. (and in a PDIP) Price is 7 Euro but on the other hand, Farnell have shops in many countries so the shipping ought to be less.
Fo a while Farnell would show thins in stock, and when ordered the would only point out that it was US stock and wanted £15 to tranfer it. They do seem to mention this a bit more now.
Farnell and RS carry it, here in the UK, I paid about £4-£5 for the ones play with. Perhaps there is a shortage on the continent, Heater couldn't get one, I seem to remember.
The beasty has the same touchiness to other bits and pieces being switched on or off, I will have to look into disabling the brownout bits.
As for the photos, does that mean that I have to tidy up the bench
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/11/2010 6:26:28 AM GMT
Re: Farnell I bought all the parts for my DracBlade from Farnell (in the UK). There is a minimum order of £20 if you are buying on card (I assume some similar limit in other countries) but shipping is free and normally next working day. On the UK site there is a checkbox in the part filter form at the top of the page which says "Exclude Extended Range Items" with this ticked none of the Newark (American) stock will be listed in the search results.
@Toby: The boxed up version looks good another "HackBlade" implementation on a custom board. Just wondering with the brownout problems how many caps you have, I can't see many in the photo (although it is low res and you may have them underneath). You really need a 0.1uF decoupler across the power next to each of the 74 series chips and a couple on the Prop
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
There are 0.1uF SM caps on every chip (2 for the Prop) underneath. There is a 220uF right by the Prop and a 10uf Tant hiding under the Prop, within its base. There is also a couple of 100uF elsewhere. The resets do not happen until there is a connection to a computer (even just the shell, not the DTR)·or a VGA screen so it must be an earth loop thing.
I had hoped that as the batteries are in effect an UPS that it would be a bit more resistant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I always get a reset when I power on my PC, and another one when I run my vb.net IDE. It is just the serial lines doing their thing. Standalone boards won't reset if the serial cable is not connected.
Disconnecting and reconnecting VGA should not cause resets.
The VGA itself doesn't cause any resets, when connected or disconnected, but if anything is connected even by it's shell then the resets happen when other things on the bench ('scope, iron, ... ) even if the Prop is running purely on the batteries (without the charger). I have seen it before on other Prop boards and kept meaning to experiment with the BoE pin to see if it has anything to do with it.
Keeps me off the streets; never a bad thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/12/2010 6:38:29 AM GMT
Yes, one little problem I'm having is resets not being perfect resets. If I cycle the power supply I get a perfect reset. But pushing the reset button sometimes doesn't reboot CP/M properly. It gets half way there and fails. Sometimes pushing the reset button for a longer time helps. Maybe the prop resets but the sd card doesn't?
Tonight I got something working on the network. I needed to simplify the debugging process so a lot of the code was written and debugged on the SIMH. Then I needed a way of downloading to the first serial port, and talking to the second serial port, all from within vb.net. So that involved working out how to keep two serial ports open at the same time in vb.net
And then I needed a little vb.net program to create data packets.
What happens is you start with a character A. Wrap it up into a 9 byte packet, with a source and a destination and send it off into the wireless aether. A prop board hears this on the serial port and processes it with the program below, which is running in User2 in MP/M. If the packet is not for this board, it is sent on. If it is for this board, it is checked for integrity, then decoded, and the byte A is passed to user0. Do this again with a carriage return $0D. User0 replies with "A?" The network program takes this reply and wraps it up into a new (bigger) packet and sends it back out into the aether.
There are some other commands too, eg
* route all further output from board x to board y. So you can log into a board and run programs etc.
* ping (replies with pong)
* WHO (replies with the board number). Useful for finding out which boards are in range
The great thing about data packets is that there are many copies that go via many different paths. So a wireless mesh becomes tolerant of individual nodes failing.
Next job - trying to break it! I need to see how the system responds as more nodes are added, and work out optimum delays between packets. But my brain hurts from intense coding. I think I might reprogram the board to run some games...
Having three computers on one Propeller is both confusing and powerful. I've not fully explored what it can do, but one thing I've been experimenting with is file transfer. The very latest version of qZ80 makes user 0 the VGA display, user 1 the serial port and user 2 the second serial port. This would be my preferred setup, because when it boots up you get something useful on the local VGA screen.
However, xmodem file transfers come through the serial port, and that is User 1. I have a program XMODEMF.COM which handles file transfers. So I copied it from USER 0 to USER 1 with
Then I downloaded a file from the PC using a terminal program. The only slightly strange thing is that the file ended up in USER 0.
I'm trying to work out why that would be. The relevant bit of code in xmodem is
MAKEFIL:XOR A ; SET EXT & REC # TO 0
LD (FCBEXT),A
LD (FCBSNO),A
LD DE,FCB ; POINT TO FCB
LD C,MAKE ; GET BDOS FNC
CALL BDOS ; TO THE MAKE
INC A ; FF=BAD?
RET NZ ; OPEN OK
where the variable MAKE is BDOS call 22
MAKE: .EQU 22 ; 0FFH=BAD
REN: .EQU 23 ; 0FFH=BAD
CURDRV: .EQU 25 ; GET CURRENT DRIVE
STDMA: .EQU 26 ; SET DMA
USER: .EQU 32 ; SET USER AREA TO RECEIVE FILE
Intriguingly, in that little list of BDOS calls is USER: .EQU 32 which implies that somewhere the user is being set. But a search for the word USER does not find anything in the rest of the program. Maybe there is a way to create a new version of xmodem that saves to USER 1
BUT - maybe I don't want to.
In trying to debug this, I fired up MBASIC in USER 1 and opened a file and saved some text and closed it. The file was in USER 1 as expected. So then I tried typing USER 1 from the local keyboard - ie USER 0. And here is the nifty thing - I was able to browse that users files, copy to that user, copy from that user etc. Yet, from the point of view of the terminal program running on USER 1, I was still running MBASIC. I'm thinking that MP/M allows you to run programs, but the file transfer operations happen in the background.
This is extremely useful, as it doesn't really matter where xmodem puts the files - it is possible to move them anywhere from any user. In practice, all that is needed is to get a copy of XMODEMF.COM into USER 1 and leave it there. The local screen is the VGA display which is USER 0 and the files appear there anyway.
This is the automated file download from the vb.net program. Click "Download" and the vb.net handles changing users, adding appropriate delays, erasing any old file(s) by the same name, xmodem transfer, and returning to user 1.
1A>
1A>USER 0
User Number = 0
0A>
0A>ERA MBASIC.COM
0A>XMODEMF R MBASIC.COM
^F
0A>
0A>USER 1
User Number = 1
1A>
1A>
Even more clever, pullmoll's code allows any user to really take control over another user using some OUT commands and the print spooler, so it should be possible to log into USER 1 running MBASIC and talk to that program.
My apologies if this is all boring housekeeping. It is, but where it is heading is being able to log into users on different boards, wirelessly.
A small note to pullmoll - occasionally MP/M won't boot to the command prompt and just hangs after the message "MP/M XIOS (qZ80 Propeller V1.11 3 HDs Banked, 15 Apr 10)
There is a similar error when a PIP does not return to the command prompt - even though it has successfully transferred the file. I'm not sure if these problems are related and whether there is a solution?
The two languages I've been using for this board have been Assembly and Sbasic. Both are great, but Assembly is in Z80 opcodes which hardly anyone in the world knows, and I think I might be the only person in the entire world programming in Sbasic. However, Sbasic is very similar to C and I came across some functions that didn't work in Sbasic.
So - this is a port of the 20x4 LCD driver code into C. It is not as fast as assembly, but it works just fine. Plus I'm on the steep part of the learning curve for a new language which is always a lot of fun!
addit: the forum is interpreting the [noparse][[/noparse] i ] array pointer as an italic pointer so a few bits of code are not displaying. A bit of Fortran coming through there, maybe I should use j as a variable?
/* 20x4 LCD display driver for the Propeller Dracblade */
#include <stdio.h>
/* global variables */
int lcdbuffer[noparse][[/noparse]80]; /* buffer for the display */
int column; /* column counter 0 to 19 */
char lcdstring[noparse][[/noparse]20]; /* string to print */
main()
{
int k; /* variable for keyboard input */
/* printf("LCD test program\n"); */
lcdstart(); /* start the display, clear etc */
strcpy(lcdstring,"Hello"); /* example string to print */
printlcd(); /* print it */
lcdcrlf(); /* new line */
strcpy(lcdstring,"World"); /* new line and new string */
printlcd();
lcdcrlf();
strcpy(lcdstring,"Hit any key to exit"); /* exit message */
printlcd();
k=0;
do
{
k=kbhit(); /* test for keypress */
}
while (k==0);
k=getchar(); /* gobble up the character */
lcdcrlf(); /* new line on display */
strcpy(lcdstring,"0A>"); /* prompt */
printlcd(); /* print it */
}
lcdstart() /* startup code */
{
int i;
for (i=0;i<80;i++)
{
lcdbuffer[i]=32; /* [/i]clear the buffer */
}
outp(0x30,1); /* clear the screen */
outp(0x30,13); /* cursor on */
outp(0x30,212); /* cursor to last line */
}
redraw() /* redraw the entire display */
{
int i;
outp(0x30,128); /* line 1 */
for (i=0;i<20;i++)
{
outp(0x31,lcdbuffer[i]); /* [/i] */
}
outp(0x30,192); /* line 2 */
for (i=20;i<40;i++)
{
outp(0x31,lcdbuffer[i]); /* [/i] */
}
outp(0x30,148); /* line 3 */
for (i=40;i<60;i++)
{
outp(0x31,lcdbuffer[i]); /* [/i] */
}
outp(0x30,212); /* line 4 */
for (i=60;i<80;i++)
{
outp(0x31,lcdbuffer[i]); /* [/i] */
}
outp(0x30,212); /* cursor to start of last line */
}
linefeed()
{
int i,j,n;
for (i=0;i<3;i++)
{
n=i*20;
for (j=0;j<20;j++)
{
lcdbuffer[noparse][[/noparse]n+j]=lcdbuffer[noparse][[/noparse]n+j+20]; /* move up one line */
}
}
for (j=60;j<80;j++)
{
lcdbuffer[noparse][[/noparse]j]=32; /* last line blank */
}
column=0;
redraw();
}
backspace()
{
int i;
outp(0x30,212); /* cursor to beginning of line 4 */
if (column >0);
{
lcdbuffer[noparse][[/noparse]column+60-1]=32; /* blank */
column=column-1;
outp(0x30,212); /* cursor to beginning of line 4 */
for (i=0;i<19;i++)
{
outp(0x31,32); /* clear last line */
}
outp(0x30,212); /* cursor to beginning of line 4 */
for (i=0;i<column;i++)
{
outp(0x31,lcdbuffer[noparse][[/noparse]60+i]); /* reprint line 4 */
}
}
}
lcdterminal(c)
int c;
{
outp(0x30,13); /* cursor on */
if (c==8) backspace(); /* backspace character ascii 8 */
if (c==10) linefeed(); /* linefeed character ascii 10 */
if (c>=32 && c<127)
{
if (column<=19)
{
if (column==19) outp(0x30,12); /* cursor off if last col*/
outp(0x31,c); /* print the character */
lcdbuffer[noparse][[/noparse]60+column]=c; /* store in the buffer */
column++; /* add 1 to column */
}
if (column >= 20) linefeed(); /* new line */
}
}
lcdcrlf() /* carriage return */
{
lcdterminal(10);
}
printlcd() /* prints lcdstring */
{
int i,c,n;
n=strlen(lcdstring);
for (i=0;i<n;i++)
{
c=lcdstring[i];
lcdterminal(c);
}
}
[/i]
I see that the '138 output you have chosen to access the '541 as an input is Pin8, I had just gone for the next available one, Pin9. I havn't got the LCD on "Clunky" so that has become the output.
If there ever gets to be a software difference a couple of air wires will sort it.
I have sorted another VGA monitor for "Clunky" this one is a good match. I will see if I can put some pics with it displaying, up for you if you wanted any for showing what people have acheived with your (along with everybody else's) design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??
Thanks to pullmoll there are at least five different emulations, maybe more. Keeping track of them can get very confusing, so the easy answer is to put every single file on one sd card, compile each emulation to a binary image and run a bootloader program.
Being curious, I Googled "Pulsar Little Big Board". Most of the replies come back with ironing board extentions. Quite apt for the way I make my copies of the DracBoards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??
Nice to see those photos. Do the regs need heatsinks? (I guess it would depend on the input volts)
I, too, am the owner of a Pulsar Little Big Board. The Dracblade can do all the LBB could do, and so much more thanks to all those that have contributed to this project.
I have done the simple transfer of the three address latches an the decoder into a XC9536XL.
This is all that the io/out pin amount will allow (PLCC44). At the present it fires up on the Nascom emulator but crashes out on the CPM with a register dump, a few lines of stuff and then an Er3. I lifted the EEPROM out of "Clunky" which runs ok, I think.
All those wires could be the problem even though I kept them as short as I dare yet allowing me to reach thing and work on it.
Almost the four chip Dracblade (with the "PropPlug" cheat)
The 95xx chips are their simplest ones, and the 9536 is the smallest of the simple. The logic was just drawn out as a schematic diagram using their supplies primitives, I used 5 sets of their FD4s (4 way D type latches, + edge) and the already done X74_138. There are 8 way latches (FD8) but they used busses and I just wanted to get on with it and used the simpler FD4s which have individual inputs. None of this is clever.
The software is free to download, with the later versions being registered, and the programming interface is a freely available cct using 2x 74hc125s on a parallel port. They provide the drivers so that the XP doesn't get in the way.
I feel confident to try a propper board for it now (after i confirm that i can get it to force the pin outs to what I want (constraints)). The board I made for the pin shifting could get used as the memory is on a separate level anyway.
That sounds great. The external ram has been a stable design now for almost a year, and is supported by all the Z80 emulations as well as Catalina (the latter has enormous potential that we have only just begun to exploit).
I have another board on the way, with the main little experiment being to add a single jumper so you can select between the second serial port or a mouse. That wouldn't affect your CPLD chip. So if that works, I think this could become a very flexible design.
now I have mastered the complexities of the CPLDs, I shall now go onto the full FPGA (right after I remember where I put my medication).
I have a SM Prop, EEPROM and memory here so a full SM version could be done. The connectors will still be big though. I would like to put a DracBlade into a keyboard, without making it any bigger, and then that could be the "LunchKBD"
Comments
For me it works. At least a version with 80x25 screen size works. Perhaps your 80x40 uses more buffer and then fails to run? (Does it? Did you try to run it?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Obviously I cannot do highlite & inverse together. So do I make both inverse or ignore one of them?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
My system is running on VGA and I can't run Wordstar, I get a load of random strings on the screen when I try and run it, seems to be a selection of strings from io.spin (warnings about contiguity etc.) Other applications seem to be working okay. Oddly enough it doesn't seem to be working in CP/M either :-S not really sure what to do there and I don't really have time to debug it at the moment.
Edit: Further details
I was using the VGA as the primary monitor, however switching back to serial primary wordstar seems to be working, I was just using the terminal in BST that doesn't seem to do any VT codes. In this mode Wordstar starts in either CP/M or MP/M. Have there been any changes to the VT100 code that could be causing these problems?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Post Edited (hairymnstr) : 5/6/2010 8:29:21 PM GMT
Highlite is used for the command letters in the menu and you know them anyway after some time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Thanks for the updated DracBlade_spi. I'll include it in my lib directory.
No, the BST terminal is not emulating VT100. I have to try the primary VGA + keyboard mode to see if it makes any difference. It could be I missed swapping one of the functions accessing the ports for the console #0 I/O. The vt100 code is unchanged since several versions of qz80 now.
Edit: It seems vt100 dies when trying to change the highlite attribute to on, i.e. print chr$(27);"[noparse][[/noparse]1m". I'll investigate the cause for this and try to fix it.
Found: The color table was once for 64 rows, while it now is for as many rows as the video mode has, i.e. 40. There was a loop filling 64 words in vt100 still, now overwriting whatever was behind that color table in hub RAM.
Now I remembered that at some point I used wsu.com to create a new ws.com from. wsu.com is the unmodified, original version AFAIK, and I used it to change the terminal to ANSI (which is essentially VT100) and 25 screen rows with wschange.com.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/7/2010 1:46:46 AM GMT
The box has been many things before, hence too many plugs, sockets and holes. It has 2AH of batts (8.4V, 2x,cells) along with their charger and 5V and 3.3V regs.
I have included an input port, yet to impliment, to get some parallel I/O. There is a 25 pin on the back panel so I may as well use it.
The retro, clunky look/feel is intentional, of course
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/10/2010 7:16:52 PM GMT
I'm working on the wireless code today - hopefully will have something soon!
As an aside, I had an email today from someone in the Netherlands regarding the cost of the memory chip from Future Electronics. It is the same problem here in Australia: $30 shipping for a $4 chip. I bought a few more chips and the vga sockets which made the shipping less per part, but it is still a bit expensive.
So I did a search and Farnell seem to have these chips too. (and in a PDIP) Price is 7 Euro but on the other hand, Farnell have shops in many countries so the shipping ought to be less.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
FutureElectronics also seem to pack in big boxes so sometimes the freight is > $70. I have been caught!!!
Drac: I think I have a couple of DIP srams. I have plenty of smt.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Farnell and RS carry it, here in the UK, I paid about £4-£5 for the ones play with. Perhaps there is a shortage on the continent, Heater couldn't get one, I seem to remember.
The beasty has the same touchiness to other bits and pieces being switched on or off, I will have to look into disabling the brownout bits.
As for the photos, does that mean that I have to tidy up the bench
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/11/2010 6:26:28 AM GMT
@Toby: The boxed up version looks good another "HackBlade" implementation on a custom board. Just wondering with the brownout problems how many caps you have, I can't see many in the photo (although it is low res and you may have them underneath). You really need a 0.1uF decoupler across the power next to each of the 74 series chips and a couple on the Prop
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
There are 0.1uF SM caps on every chip (2 for the Prop) underneath. There is a 220uF right by the Prop and a 10uf Tant hiding under the Prop, within its base. There is also a couple of 100uF elsewhere. The resets do not happen until there is a connection to a computer (even just the shell, not the DTR)·or a VGA screen so it must be an earth loop thing.
I had hoped that as the batteries are in effect an UPS that it would be a bit more resistant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I always get a reset when I power on my PC, and another one when I run my vb.net IDE. It is just the serial lines doing their thing. Standalone boards won't reset if the serial cable is not connected.
Disconnecting and reconnecting VGA should not cause resets.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Keeps me off the streets; never a bad thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/12/2010 6:38:29 AM GMT
Tonight I got something working on the network. I needed to simplify the debugging process so a lot of the code was written and debugged on the SIMH. Then I needed a way of downloading to the first serial port, and talking to the second serial port, all from within vb.net. So that involved working out how to keep two serial ports open at the same time in vb.net
And then I needed a little vb.net program to create data packets.
What happens is you start with a character A. Wrap it up into a 9 byte packet, with a source and a destination and send it off into the wireless aether. A prop board hears this on the serial port and processes it with the program below, which is running in User2 in MP/M. If the packet is not for this board, it is sent on. If it is for this board, it is checked for integrity, then decoded, and the byte A is passed to user0. Do this again with a carriage return $0D. User0 replies with "A?" The network program takes this reply and wraps it up into a new (bigger) packet and sends it back out into the aether.
There are some other commands too, eg
* route all further output from board x to board y. So you can log into a board and run programs etc.
* ping (replies with pong)
* WHO (replies with the board number). Useful for finding out which boards are in range
The great thing about data packets is that there are many copies that go via many different paths. So a wireless mesh becomes tolerant of individual nodes failing.
Next job - trying to break it! I need to see how the system responds as more nodes are added, and work out optimum delays between packets. But my brain hurts from intense coding. I think I might reprogram the board to run some games...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Having three computers on one Propeller is both confusing and powerful. I've not fully explored what it can do, but one thing I've been experimenting with is file transfer. The very latest version of qZ80 makes user 0 the VGA display, user 1 the serial port and user 2 the second serial port. This would be my preferred setup, because when it boots up you get something useful on the local VGA screen.
However, xmodem file transfers come through the serial port, and that is User 1. I have a program XMODEMF.COM which handles file transfers. So I copied it from USER 0 to USER 1 with
PIP XMODEMF.COM[noparse][[/noparse]G1]=XMODEMF.COM[noparse][[/noparse]G0]
Then I downloaded a file from the PC using a terminal program. The only slightly strange thing is that the file ended up in USER 0.
I'm trying to work out why that would be. The relevant bit of code in xmodem is
where the variable MAKE is BDOS call 22
Intriguingly, in that little list of BDOS calls is USER: .EQU 32 which implies that somewhere the user is being set. But a search for the word USER does not find anything in the rest of the program. Maybe there is a way to create a new version of xmodem that saves to USER 1
BUT - maybe I don't want to.
In trying to debug this, I fired up MBASIC in USER 1 and opened a file and saved some text and closed it. The file was in USER 1 as expected. So then I tried typing USER 1 from the local keyboard - ie USER 0. And here is the nifty thing - I was able to browse that users files, copy to that user, copy from that user etc. Yet, from the point of view of the terminal program running on USER 1, I was still running MBASIC. I'm thinking that MP/M allows you to run programs, but the file transfer operations happen in the background.
This is extremely useful, as it doesn't really matter where xmodem puts the files - it is possible to move them anywhere from any user. In practice, all that is needed is to get a copy of XMODEMF.COM into USER 1 and leave it there. The local screen is the VGA display which is USER 0 and the files appear there anyway.
This is the automated file download from the vb.net program. Click "Download" and the vb.net handles changing users, adding appropriate delays, erasing any old file(s) by the same name, xmodem transfer, and returning to user 1.
Even more clever, pullmoll's code allows any user to really take control over another user using some OUT commands and the print spooler, so it should be possible to log into USER 1 running MBASIC and talk to that program.
My apologies if this is all boring housekeeping. It is, but where it is heading is being able to log into users on different boards, wirelessly.
A small note to pullmoll - occasionally MP/M won't boot to the command prompt and just hangs after the message "MP/M XIOS (qZ80 Propeller V1.11 3 HDs Banked, 15 Apr 10)
There is a similar error when a PIP does not return to the command prompt - even though it has successfully transferred the file. I'm not sure if these problems are related and whether there is a solution?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/16/2010 8:20:47 AM GMT
So - this is a port of the 20x4 LCD driver code into C. It is not as fast as assembly, but it works just fine. Plus I'm on the steep part of the learning curve for a new language which is always a lot of fun!
addit: the forum is interpreting the [noparse][[/noparse] i ] array pointer as an italic pointer so a few bits of code are not displaying. A bit of Fortran coming through there, maybe I should use j as a variable?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/19/2010 1:27:26 PM GMT
I see that the '138 output you have chosen to access the '541 as an input is Pin8, I had just gone for the next available one, Pin9. I havn't got the LCD on "Clunky" so that has become the output.
If there ever gets to be a software difference a couple of air wires will sort it.
I have sorted another VGA monitor for "Clunky" this one is a good match. I will see if I can put some pics with it displaying, up for you if you wanted any for showing what people have acheived with your (along with everybody else's) design.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??
Run an emulation with
SPIN CPM.BIN
See attached and the more detailed discussion in this thread http://forums.parallax.com/showthread.php?p=912403
You can autorun your favourite with a one line change to the code.
See below for a download of KYEDOS.
Next project = getting a new board made with onboard audio and RS485 and extra input and output pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I just got my Dracblade working!
I ordered two boards, and a couple of chips a number of weeks ago, and have finally been able to spend some time to get one of the boards going.
This is a quick photo - you will notice the big fat linear regs - thats all I could get hold of - 7805 and a lm3940-3.3.
It works!!!
This board will replace my Pulsar Little Big Board system that I built in 1986.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??
I, too, am the owner of a Pulsar Little Big Board. The Dracblade can do all the LBB could do, and so much more thanks to all those that have contributed to this project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I have done the simple transfer of the three address latches an the decoder into a XC9536XL.
This is all that the io/out pin amount will allow (PLCC44). At the present it fires up on the Nascom emulator but crashes out on the CPM with a register dump, a few lines of stuff and then an Er3. I lifted the EEPROM out of "Clunky" which runs ok, I think.
All those wires could be the problem even though I kept them as short as I dare yet allowing me to reach thing and work on it.
Almost the four chip Dracblade (with the "PropPlug" cheat)
I was thinking of doing the same thing with as Altera chip I have laying around but with a wife and kids I never had the time.
The software is free to download, with the later versions being registered, and the programming interface is a freely available cct using 2x 74hc125s on a parallel port. They provide the drivers so that the XP doesn't get in the way.
I feel confident to try a propper board for it now (after i confirm that i can get it to force the pin outs to what I want (constraints)). The board I made for the pin shifting could get used as the memory is on a separate level anyway.
Couple it with an 'eye candy' operating system like on this thread http://forums.parallax.com/showthread.php?t=127123&page=4, and one could start to think about a smaller surface mount board with your chip.
I have another board on the way, with the main little experiment being to add a single jumper so you can select between the second serial port or a mouse. That wouldn't affect your CPLD chip. So if that works, I think this could become a very flexible design.
now I have mastered the complexities of the CPLDs, I shall now go onto the full FPGA (right after I remember where I put my medication).
I have a SM Prop, EEPROM and memory here so a full SM version could be done. The connectors will still be big though. I would like to put a DracBlade into a keyboard, without making it any bigger, and then that could be the "LunchKBD"
Rather than bending other units, to see if this idea has any merit, I have started to layout a new board that will be the test bed.
All this will be rendered useless by the P2, someday.