DR_A your awesome Clusso thanks I am actually using a regulated adjustable power supply to my board 7.2 volts rock steady at this point I am not 100% sure of what is really going on ,, after more testing my board will be working just fine
then for no apparent reason it will display"""Space Bar for next instruction""" I was positive it was thermal shutdown but now I am not so sure. When I get the error usually after 2-5 minutes of running the board I put 2 DMM on each out of the regulator outputs including my scope
the 5 volt and 3 volt supplies are rock steady ,, no amount of resetting both cold and warm will get the board running again , the only thing that works is letting it sit off for 5 minutes then when I power back up she boots up "CPM" and I can run programs with no problem until it shuts down again, Wouldn't you agree this sounds like the regs going into shut down ? The only problem like I said is they are not they both are supplying the correct voltage I am going crazy trying to debug this..
If I hit reset I get
""Passed loading Zicog" Space Bar for next instruction ....
DR_A if you are out there or anyone how can I address the Diag LED on the board I see its connected to pin 9 of the 74HC374 but how can I address it from the prop???? dira[noparse][[/noparse]?] outa[noparse][[/noparse]?] ?? Thanks guys.
Clusso I was just going to use separate external power supply but now I need to find out what is really going on
@Toby - no need to add more latches if you are not going to use the memory. I guess it depends on the application - is 50k enough?
@mike spacebar is the generic crash, ie it went to get the next byte of an instruction and the byte didn't match with one of the options so it crashes. The cause sounds very much like a power supply issue. Bigger heatsinks or move the supply off board. Regs should be warm but not too hot to touch. I'd be building a seperate supply in another box with big heatsinks. A 3V and 5V supply in one box will come in handy for other projects too.
Re the led, the code is in PASM as it is not just a matter of setting a prop pin high or low, but it is pretty easy to add the on/off for diagnostic purposes
RamLatches.DoCmd("N",0,0,0) ' led on
RamLatches.DoCmd("F",0,0,0) ' led off
Yikes I am bit challenged when it comes to pasm, My board is actually running now for the last 20 minutes . I am starting to believe I made so many mistakes with soldering and un soldering my board I am thinking it just might be to damaged
I would agree with power supply but I am now using a separate regulated external supply and I am having the same problems , it seems if I wiggle the board a certain way and don't touch it while its running I am ok for a while
To be perfectly honest Dr I was in such a hurry to get my board built I used some pretty crappy parts the wire wrap sockets are over 14 years old REALLY so everything is entirely my fault. I am just going to start over clean and use all new parts
I did replace the 74hc138 and re soldered the socket I still think I have an intermittent problem in that part of the cricuit.
Ah some clues there 1) "it seems if I wiggle the board a certain way..." and 2) "the wire wrap sockets are over 14 years old"
I'd be thinking about a dry joint somewhere, as there is going to be oxide after 14 years and solder won't stick to oxide. It can be sneaky and look like there is a join. I've found with brand new boards and brand new sockets that things are very easy. But I have a lot of old components too - eg the bypass caps are 20 years old. There are a few little tricks, like cutting the leads before soldering them in, and then there is the shiny new metal where the cut is and even if it doesn't stick to the outside of the wire it at least sticks to the cut end. So I make sure solder flows over the cut end. Sometimes the wet&dry sandpaper comes out just to shine up a bit of metal. Old chips going into sockets are ok as the oxide scrapes off as the chip goes in.
It can't do any harm putting a bit of extra solder on a few pins. The underside photo is blurry and the pins might be fine on the underside, but looking at the topside photos, I'd be thinking possible dry joints on prop pins 4,8,14, possibly 19, 28 and 31.
The proper way to debug this is with a can of freezer spray but it is a bit expensive so I've never bought a can. Quicker just to mindlessly resolder joints.
After soldering for over 20 years, I just learned the wonders of adding flux with a syringe. Additional flux makes for nicer joints, easier unsoldering, and can probably be used to tin those old leads.
I have been modifying 13 year old SGI computer boards for a medical computer applications, and it goes sooo much better with my flux syringe handy.
I have had some "new" IC bases that look a bit "goldy" colour on the pins, when the were soldered in they seemed to tin properly and the cone shape was the clasic, even and total. The joint was still O/C though as the outside "goldy" bit was insulated from the actual shaft of the real pin, it was a nightmare. The trick of trimming off the end and the resoldering had the effect of curing this problem and also rounding off a load of spiky things that scratched the bench. I read, decades ago, of a faulty batch of BC107s (ish) that has the gold plating in the leads with the same problems. My habit of reclaimation usually give a few problems, so now anything that isn't in very good condition gets chucked away.
The BOE and /RST is a possibillity, keep meaning to try it the other way, with a pullup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The proper way to debug this is with a can of freezer spray but it is a bit expensive so I've never bought a can. Quicker just to mindlessly resolder joints.
Careful use of a butane lighter refill can will achieve what you desire. It's cheap, incredibly toxic and bad for the environment. At least I don't drive a V8 [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I think Mike has already tried an antiphase soldering iron, ie a Peltier.
Freezer is useful sometimes but I have never been a convert to it. I read that CMOS gets faster when cooled and slower when warmed, so I will have to see if the "Spacebar ..." can be invoked. I have always known that it is a memory access thing as I had an unsoldered top conection on the original double sided, non-plated-through-hole, one. That kept a "Yippee" at bay for a few hours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I found the problem with the HiRes VGA driver, and have posted a new patch (first post in the Catalina thread) with the fixed driver and updated DracBlade support (still no XMM drivers yet).
The problem was entirely mine - in the "NO_MOUSE" version of my HiRes VGA driver I appear to have accidentally deleted a line of code at some point.
Try running the othello program:
catalina othello.c -lc -D DRACBLADE
Or turn your DracBlade into a glorified digital clock:
catalina test_time.c -lc -DCLOCK -D DRACBLADE
I'll get to work on the XMM drivers next.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Can you walk me through that one again, maybe a bit more slowly?
Ok, I downloaded the patch from the catalina thread. I presume this automatically installs over the old files.
Ran use_catalina from a dos window.
Now for some reason I can't compile programs from that window. I have to manually copy a .c program from the c:\program files\catalina\demos to the folder c:\program files\catalina I presume that doesn't mean anything bad though.
and it still gives a green screen with a flashing cursor, but after about 1 minute it says "Press any key to continue ..." so some slight change there.
but
catalina othello.c -lc
will compile ok but downloading it and running it doesn't do anything.
however,
catalina -D DRACBLADE othello.c -lc -D LORES_VGA
does run ok.
So I think I'm still missing something with the vga driver.
a printout of the non working compilation so you can see which vga driver it is actually using
There was a problem with the directory names in the zip file - unzipping it over your exisitng Catalina installation would have simply created a 'Catalina_Patch_28_Jan_10" folder. I just updated it, so you can either download the zip file again, or manually copy everything out of that folder up one level (i.e. into the main Catalina directory).
Sorry about that!
I also forgot to include the '-D DRACBLADE' in my example commands.
Ross.
I'm a bit concerned that you can't compile programs from the window in which you said 'use_catalina' - what does it say when you try?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The SD card support works. I have attached a trivial program to test it. Finding a non-zero sector can be a bit of hit and miss, since it depends on your SD card size and formatting. Secotr zero always has at least a couple of non-zero bytes near the end, but on my SD card sector 135 is my actual boot sector.
To compile this program, use the command:
catalina test_sd.c -lcx -T..\target -D DRACBLADE
Note the use of the '-lcx' - this is the version of the library with full file system support - I use it here because it also forces the inlcusion of the SD card driver. However, without XMM RAM you cannot use the normal C library file system functions because the program ends up too large. This test program just uses low level sector I/O commands.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm stuck as the whole patch has gone crazy. Extracting it doesn't seem to overwrite the file. Deleting catalina_vga_hires_text.spin in the target folder still allows it to compile using this program (is it now using another copy somewhere else?). Deleting this file then re-extracting it and winzip says do you want to overwrite it (but it has been deleted). Using windows search to find the file and it says there are two copies - one in c:\program files\catalina\target - even after I've deleted it. And even more strangely, it says there is a copy in a folder c:\program files\catalina\catalina_patch_28_jan_10\target but this folder does not even seem to exist when browsing windows.
I think the patch process isn't working properly. I'm wondering - is it possible to package this up as a single package rather than a package plus patch?
Thanks guys, I just can't let this go as soon as I get home I come right up here to my lab and start debugging on my Dr_A board lol,, I fear you are correct about the dry lead I had a lot of trouble soldering the sockets I did use flux and even a pencil eraser becuase I could see the solder piling up and not flowing ,, if anyone wants you can look at some of the pictures I posted I have re soldered so many times I think the problem my actually be in the socket itself not making contact with the IC chip
Clusso to be honest I just soldered up the board the way it was but now that the prop chips had been raised as soon as I am done type this I will try a 100K on the reset line I have never heard of that before
So I hope I am correct in assuming the 100K goes to the 3 volt line to pull up reset?? I will wait until you guys respond to make sure. I can without failure come home boot my board and run CPM and Mbasic for a few minutes until I get the space bar error
some time I can reset the SD card and hit reset and it will boot up CPM again for a few more minutes but I don't think the SD card has anything to do with it ,,,, Doc I can always wiggle the board to get it to work its so frustrating I could be programing
At this point I am pretty sure its not my power supplies and I have been over everyhting so many times last night I replaced every single chip including prop but same thing, It acts so much like a thermal overload I would swear to it, but the regs are rock steady
+5 +3.3 I downloaded DR_A's new files but that was no help ,, I have also noted that when it gives me the space bar error I can no longer talk to the board via RS-232 so while somehting is running since I get the space bar error the prop will no longer talk with the serial port
Toby I run Mbasic with a little program 10print "hello testing"; 20 got0 10 run of course this makes hello testing continuously print across the screen and scrolls down , right before I get the space bar error it will print garbage on the screen as it fails
%#^&%#$^*$@&$@$*@ then space bar instruction error so somehting is crapping out anyone have any thoughts where I should look next? I have scopes and logic analyzers but I am running out of ideas on what to look at Thanks guys
To debug this I think you need two boards so you can swap parts back and forth. I'm pondering a solution, but I think that given you already seem to have all the chips, what I might do is take one of my earlier working boards and pull out the latches, propeller and eeprom, but leave in the regulator and all the other components and then send that to you.
Hmmm - this is not good. I think you may have a problem with your disk. The patchfiles are nothing more than zipped source files - there aren't even any binary files in them. I've just downloaded the whole set of Catalina zip files again (including patches) and reinstalled them on another machine - no issues.
I'm sorry if I have caused you to trash your disk - if I were you I'd reboot ASAP and then run chkdsk (or in Windows Explorer, right click on the disk icon and use Properties->Tools->Check Now).
After you have checked your machine I suggest you delete everything in your existing "C:\Program Files\Catalina" directory, then download each of the zip files below, then right-click each one and use the built-in Windows 'Extract All' command to extract the files - note that you have to manually specify the directory in each case to be "C:\Program Files\Catalina" - don't let Windows use the suggested name, which is nearly always wrong.
Files to downloaded (this is for a binary release only - you can also include the source files if you want but it is not necessary):
All the "Spacebar ... " errors I have had are always right at power up, hot or cold. If youy PCB has suffered one ignomy too many then the hairline crack in one one track may be haunting you, hence the wiggling bit. A long time ago we had a VTR clock that would not run unless a eraser was jammed under the PCB, right in the middle. Many people looked for tha fault, including me, it was scrapped still with the lump of rubber (20 years ago now).
Like you I should be playing with what I have, but then I go and get other ideas. There is a good basis, in the DracBlade (64k) for my beloved, lamented,Nascom. The thought of learning about SDRAM is also a time drag.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Thanks guys I meant to say by the way "I can not always wiggle the board and get it to work" so I wanted to clear that up I wish it was that easy so I think the wiggling of the board is meaningless at this point since I can not duplicate it
Toby I was meaning to ask SDRAM static ram or dynamic ram or some kind of in between??? Didn't you post a while back someone took a 30 pin Dimm and interfaced it to a prop or SX chip it was an awesome job I wish they included schematics and code.
Yes Antoine posted some code for the old 30 pin SIMMs, but I haven't got any of them, so then I got interested in the self refreshing possibilities of SyncronousDynamicRAMs rather than the FastPage stuff.
I am slowly loosing the faith and will get back to reality.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby LOL,, Toby if you are interested I have quite a few of the below Drams I can throw a few in an envelope and mail them to you if you want to experiment I believe they are 64Meg X 32 I do not have any sockets but I do have some Dell mother boards these go in so you could always desolder a few each board has a total of 4 sockets they are working so it would be ashamed to rip them apart for sockets but feel free.
Oh I also have a bunch of the 30 pin SIMMs you used in that post if you want any of them , To be honest I probably have just about every kind of PC clone Dram Simms for all the older PC clone boards. I have a hard enough time with the Sram
I never really played with Dram becuase of the constant refresh and loosing everything when you power them down, I posted way back that I had a bought a lot off ebay of 2Mb 32 pin Flash Rams I wish we could do somehting with those I have the data sheet they look like they are quite a bit slower than regular Srams but maybe use them for assets or somehting ,, Well DR_A if your out there I am more than willing to try any configuration board you suggest I think the consensus is my board is probably to far gone, of course my fault entirely but you have to admit it looks good lol
Oh I don't know if this means anything at this point but I forgot to mention that sometimes when I powered up my Dr_A board the diag LED would be lite would have to cycle a few times before it would go out
I spent some time this morning making you a board. I got it all working then removed the sd card, the ram chip, the eeprom and the propeller. So it should be easy to swap the chips you have into the board. I can send that board and two blank boards if you like for $40. It should make things a lot easier if you have something that is working out of the box. I'll get it in the post Monday.
[noparse][[/noparse]quote]
"I know you have answered the question of Amstrad's policy on the use of the Spectrum ROMs before but the debate has come up
again on comp.sys.sinclair and as much as I tell people what I believe it is, they want a definitive answer. So when you have time here
are the questions. Thanks!
1) What exactly do you have to do to use Sinclair ROMs in an emulator, such as acknowledgements etc?"
Amstrad are happy for emulator writers to include images of our copyrighted code as long as the (c)opyright messages are not altered
and we appreciate it if the program/manual includes a note to the effect that "Amstrad have kindly given their permission for the
redistribution of their copyrighted material but retain that copyright".
Those modules look like RIMMs from Rambus days. I will start to wire the second SDRAM I have on to the sawn off "Big Z80 Experiment Board". I built it as an Arduino look-a-like so that it was a DemoBoard with it's "shield" on but also it is a sort of naked Blade2 without it, so that the max number of pins are available. (the mouse 6pin socket was knicked for the "spread out DracBlade")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
@Toby, maybe you might become our resident "large memory" expert?
The ones I'm most familiar with are round the 32Mb,64Mb size, eg PC100 and PC133. I've got lots and they are pretty cheap on ebay $5-$10.
I gather they are SDRAM so presumably static. But could you get the sockets for them? And what could you store in all that memory? Would you have to invent some bloatware to justify having it??
I'm starting to pull together some networking protocols - I have two boards working and now have added a third. So the airwaves will get a little crowded and I think I need to invent some sort of packet routing system. The thing that is confusing me is where to put it. Am starting to get close to filling up hub memory. Could I load some of the PASM blocks into cogs then does that free up space in hub once they are loaded up? Or - how about running two CP/M emulations concurrently by swapping the ram bank? Just need a temp store of the registers before flipping betweeen them. Or do I patch CP/M on the fly and poke a capture program into high memory?
The issue is a remote board that sends out some bytes (eg in response to a DIR request). I want to wrap those bytes in a packet so I want to capture them as the come out of CP/M's CONOUT.
Specifically, a packet might come in with a list of all the routers it went through, so I want to grab that list, reverse it, and add it to the bytes going back out.
I wish I had more hub ram. So - when you have some PASM code, if you load it into a cog is there now a redundant copy of that code in hub? Maybe I could load the VGA font data for instance off the sd card. But I am very confused about cog and hub ram at the moment. Help would be most appreciated!
Dr_Acula said...
So - when you have some PASM code, if you load it into a cog is there now a redundant copy of that code in hub?
Correct. Up to the point where you shut down the cog and you want to restart it [noparse]:)[/noparse] So stuff which you know will run forever can have it's hub area re-used.
Or you could load the cog code directly from SDCard, i.e. up to 2K at a time.
Post Edited (kuroneko) : 1/30/2010 12:42:48 PM GMT
Ah, ok, well shutting down and restarting cogs is not an issue as they only ever get started once and then keep going forever - eg the VGA ones, and the keyboard one and the serial port one, so that simplifies things.
The bit I don't quite understand is transferring data between hub and cog. If it is compiled as one big program, I presume the compiler then puts links in so when you read and write bytes from within PASM code it reads from the right place. eg a rdlong.
But if you (say) compiled that PASM DAT section as a seperate module, and then had a rdlong instruction, how would it know to get the long from the right place? Especially as the hub code might change over time. Would you have to rewrite the code to transfer data via a fixed location eg some longs at the top of memory?
Dr_Acula said...
The bit I don't quite understand is transferring data between hub and cog. If it is compiled as one big program, I presume the compiler then puts links in so when you read and write bytes from within PASM code it reads from the right place. eg a rdlong.
But if you (say) compiled that PASM DAT section as a seperate module, and then had a rdlong instruction, how would it know to get the long from the right place? Especially as the hub code might change over time. Would you have to rewrite the code to transfer data via a fixed location eg some longs at the top of memory?
Well, you can certainly hardwire references to e.g. VAR locations into the cog code before you invoke cognew/coginit. Some objects transfer certain values (which may require arithmetic which is not freely available in PASM, e.g. _clkfreq/100) into the DAT section before starting the cog. That would be out of the question for dynamic code loading (with some exceptions).
The other way is to entirely rely on the parameter value passed into cognew/coginit which then appears in the read-only par register. The PASM code will treat this as its parameter/communication area. So whatever the launch code sets up (could be top of memory, could be somewhere in the middle) that's where the cog gets its data from. It only has to be a single long as you could have a command which sets an internal value for a hub communication area (e.g. a bit like a setBaseAddress() function). Another approach is to have one long for the command and a few more for the parameters (usually located after the command). Take your pick [noparse]:)[/noparse]
I have not got one good purpose for any large memory. It was a thought of the latches being contained within the mem chip that interested me, allowing the chip count of RamBlade with the ins and outs of the DracBlade. SDRAM is still dynamic ram, just with the actions being clocked and so becoming SYNCRONOUS (not static) with the bus actions. The refresh stuff is contained within the chip, and so is faster, but I don't think the /RAS, /CAS latches work as the old original stuff did. This won't allow the ADDR low(/RAS), ADDR high (/CAS) and DATA to be multiplexed onto the same pins. I might go back to the original plans of CPLD + SRAM.
OR ....
Just accept reality and get on with what I have already, after all there are loads of spare latched pins available for bigger memory should it ever be needed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 1/30/2010 10:19:16 PM GMT
Comments
then for no apparent reason it will display"""Space Bar for next instruction""" I was positive it was thermal shutdown but now I am not so sure. When I get the error usually after 2-5 minutes of running the board I put 2 DMM on each out of the regulator outputs including my scope
the 5 volt and 3 volt supplies are rock steady ,, no amount of resetting both cold and warm will get the board running again , the only thing that works is letting it sit off for 5 minutes then when I power back up she boots up "CPM" and I can run programs with no problem until it shuts down again, Wouldn't you agree this sounds like the regs going into shut down ? The only problem like I said is they are not they both are supplying the correct voltage I am going crazy trying to debug this..
If I hit reset I get
""Passed loading Zicog" Space Bar for next instruction ....
DR_A if you are out there or anyone how can I address the Diag LED on the board I see its connected to pin 9 of the 74HC374 but how can I address it from the prop???? dira[noparse][[/noparse]?] outa[noparse][[/noparse]?] ?? Thanks guys.
Clusso I was just going to use separate external power supply but now I need to find out what is really going on
@mike spacebar is the generic crash, ie it went to get the next byte of an instruction and the byte didn't match with one of the options so it crashes. The cause sounds very much like a power supply issue. Bigger heatsinks or move the supply off board. Regs should be warm but not too hot to touch. I'd be building a seperate supply in another box with big heatsinks. A 3V and 5V supply in one box will come in handy for other projects too.
Re the led, the code is in PASM as it is not just a matter of setting a prop pin high or low, but it is pretty easy to add the on/off for diagnostic purposes
RamLatches.DoCmd("N",0,0,0) ' led on RamLatches.DoCmd("F",0,0,0) ' led off▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I would agree with power supply but I am now using a separate regulated external supply and I am having the same problems , it seems if I wiggle the board a certain way and don't touch it while its running I am ok for a while
To be perfectly honest Dr I was in such a hurry to get my board built I used some pretty crappy parts the wire wrap sockets are over 14 years old REALLY so everything is entirely my fault. I am just going to start over clean and use all new parts
I did replace the 74hc138 and re soldered the socket I still think I have an intermittent problem in that part of the cricuit.
I'd be thinking about a dry joint somewhere, as there is going to be oxide after 14 years and solder won't stick to oxide. It can be sneaky and look like there is a join. I've found with brand new boards and brand new sockets that things are very easy. But I have a lot of old components too - eg the bypass caps are 20 years old. There are a few little tricks, like cutting the leads before soldering them in, and then there is the shiny new metal where the cut is and even if it doesn't stick to the outside of the wire it at least sticks to the cut end. So I make sure solder flows over the cut end. Sometimes the wet&dry sandpaper comes out just to shine up a bit of metal. Old chips going into sockets are ok as the oxide scrapes off as the chip goes in.
It can't do any harm putting a bit of extra solder on a few pins. The underside photo is blurry and the pins might be fine on the underside, but looking at the topside photos, I'd be thinking possible dry joints on prop pins 4,8,14, possibly 19, 28 and 31.
The proper way to debug this is with a can of freezer spray but it is a bit expensive so I've never bought a can. Quicker just to mindlessly resolder joints.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/28/2010 1:46:53 AM GMT
I have been modifying 13 year old SGI computer boards for a medical computer applications, and it goes sooo much better with my flux syringe handy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The BOE and /RST is a possibillity, keep meaning to try it the other way, with a pullup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Careful use of a butane lighter refill can will achieve what you desire. It's cheap, incredibly toxic and bad for the environment. At least I don't drive a V8 [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Freezer is useful sometimes but I have never been a convert to it. I read that CMOS gets faster when cooled and slower when warmed, so I will have to see if the "Spacebar ..." can be invoked. I have always known that it is a memory access thing as I had an unsoldered top conection on the original double sided, non-plated-through-hole, one. That kept a "Yippee" at bay for a few hours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I found the problem with the HiRes VGA driver, and have posted a new patch (first post in the Catalina thread) with the fixed driver and updated DracBlade support (still no XMM drivers yet).
The problem was entirely mine - in the "NO_MOUSE" version of my HiRes VGA driver I appear to have accidentally deleted a line of code at some point.
Try running the othello program:
Or turn your DracBlade into a glorified digital clock:
I'll get to work on the XMM drivers next.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 1/28/2010 8:48:25 PM GMT
Can you walk me through that one again, maybe a bit more slowly?
Ok, I downloaded the patch from the catalina thread. I presume this automatically installs over the old files.
Ran use_catalina from a dos window.
Now for some reason I can't compile programs from that window. I have to manually copy a .c program from the c:\program files\catalina\demos to the folder c:\program files\catalina I presume that doesn't mean anything bad though.
Tried this one again
catalina -D DRACBLADE test_suite.c -lc -D LORES_VGA
and it still works
tried
catalina -D DRACBLADE test_suite.c -lc
and it still gives a green screen with a flashing cursor, but after about 1 minute it says "Press any key to continue ..." so some slight change there.
but
catalina othello.c -lc
will compile ok but downloading it and running it doesn't do anything.
however,
catalina -D DRACBLADE othello.c -lc -D LORES_VGA
does run ok.
So I think I'm still missing something with the vga driver.
a printout of the non working compilation so you can see which vga driver it is actually using
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
There was a problem with the directory names in the zip file - unzipping it over your exisitng Catalina installation would have simply created a 'Catalina_Patch_28_Jan_10" folder. I just updated it, so you can either download the zip file again, or manually copy everything out of that folder up one level (i.e. into the main Catalina directory).
Sorry about that!
I also forgot to include the '-D DRACBLADE' in my example commands.
Ross.
I'm a bit concerned that you can't compile programs from the window in which you said 'use_catalina' - what does it say when you try?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The SD card support works. I have attached a trivial program to test it. Finding a non-zero sector can be a bit of hit and miss, since it depends on your SD card size and formatting. Secotr zero always has at least a couple of non-zero bytes near the end, but on my SD card sector 135 is my actual boot sector.
To compile this program, use the command:
Note the use of the '-lcx' - this is the version of the library with full file system support - I use it here because it also forces the inlcusion of the SD card driver. However, without XMM RAM you cannot use the normal C library file system functions because the program ends up too large. This test program just uses low level sector I/O commands.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm stuck as the whole patch has gone crazy. Extracting it doesn't seem to overwrite the file. Deleting catalina_vga_hires_text.spin in the target folder still allows it to compile using this program (is it now using another copy somewhere else?). Deleting this file then re-extracting it and winzip says do you want to overwrite it (but it has been deleted). Using windows search to find the file and it says there are two copies - one in c:\program files\catalina\target - even after I've deleted it. And even more strangely, it says there is a copy in a folder c:\program files\catalina\catalina_patch_28_jan_10\target but this folder does not even seem to exist when browsing windows.
I think the patch process isn't working properly. I'm wondering - is it possible to package this up as a single package rather than a package plus patch?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Clusso to be honest I just soldered up the board the way it was but now that the prop chips had been raised as soon as I am done type this I will try a 100K on the reset line I have never heard of that before
So I hope I am correct in assuming the 100K goes to the 3 volt line to pull up reset?? I will wait until you guys respond to make sure. I can without failure come home boot my board and run CPM and Mbasic for a few minutes until I get the space bar error
some time I can reset the SD card and hit reset and it will boot up CPM again for a few more minutes but I don't think the SD card has anything to do with it ,,,, Doc I can always wiggle the board to get it to work its so frustrating I could be programing
At this point I am pretty sure its not my power supplies and I have been over everyhting so many times last night I replaced every single chip including prop but same thing, It acts so much like a thermal overload I would swear to it, but the regs are rock steady
+5 +3.3 I downloaded DR_A's new files but that was no help ,, I have also noted that when it gives me the space bar error I can no longer talk to the board via RS-232 so while somehting is running since I get the space bar error the prop will no longer talk with the serial port
Toby I run Mbasic with a little program 10print "hello testing"; 20 got0 10 run of course this makes hello testing continuously print across the screen and scrolls down , right before I get the space bar error it will print garbage on the screen as it fails
%#^&%#$^*$@&$@$*@ then space bar instruction error so somehting is crapping out anyone have any thoughts where I should look next? I have scopes and logic analyzers but I am running out of ideas on what to look at Thanks guys
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hmmm - this is not good. I think you may have a problem with your disk. The patchfiles are nothing more than zipped source files - there aren't even any binary files in them. I've just downloaded the whole set of Catalina zip files again (including patches) and reinstalled them on another machine - no issues.
I'm sorry if I have caused you to trash your disk - if I were you I'd reboot ASAP and then run chkdsk (or in Windows Explorer, right click on the disk icon and use Properties->Tools->Check Now).
After you have checked your machine I suggest you delete everything in your existing "C:\Program Files\Catalina" directory, then download each of the zip files below, then right-click each one and use the built-in Windows 'Extract All' command to extract the files - note that you have to manually specify the directory in each case to be "C:\Program Files\Catalina" - don't let Windows use the suggested name, which is nearly always wrong.
Files to downloaded (this is for a binary release only - you can also include the source files if you want but it is not necessary):
Catalina_documents.zip
Catalina_demos_utilities.zip
Catalina_win32_binary_1.zip
Catalina_win32_binary_2.zip
Catalina_win32_binary_3.zip
Catalina_Patch_22_Jan_10.zip
Catalina_Patch_28_Jan_10.zip
The only ones where the order is important are the two patch files - unzip these last, in the order given above.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
All the "Spacebar ... " errors I have had are always right at power up, hot or cold. If youy PCB has suffered one ignomy too many then the hairline crack in one one track may be haunting you, hence the wiggling bit. A long time ago we had a VTR clock that would not run unless a eraser was jammed under the PCB, right in the middle. Many people looked for tha fault, including me, it was scrapped still with the lump of rubber (20 years ago now).
Like you I should be playing with what I have, but then I go and get other ideas. There is a good basis, in the DracBlade (64k) for my beloved, lamented,Nascom. The thought of learning about SDRAM is also a time drag.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby I was meaning to ask SDRAM static ram or dynamic ram or some kind of in between??? Didn't you post a while back someone took a 30 pin Dimm and interfaced it to a prop or SX chip it was an awesome job I wish they included schematics and code.
Post Edited (mikediv) : 1/29/2010 4:54:24 PM GMT
Yes Antoine posted some code for the old 30 pin SIMMs, but I haven't got any of them, so then I got interested in the self refreshing possibilities of SyncronousDynamicRAMs rather than the FastPage stuff.
I am slowly loosing the faith and will get back to reality.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Oh I also have a bunch of the 30 pin SIMMs you used in that post if you want any of them , To be honest I probably have just about every kind of PC clone Dram Simms for all the older PC clone boards. I have a hard enough time with the Sram
I never really played with Dram becuase of the constant refresh and loosing everything when you power them down, I posted way back that I had a bought a lot off ebay of 2Mb 32 pin Flash Rams I wish we could do somehting with those I have the data sheet they look like they are quite a bit slower than regular Srams but maybe use them for assets or somehting ,, Well DR_A if your out there I am more than willing to try any configuration board you suggest I think the consensus is my board is probably to far gone, of course my fault entirely but you have to admit it looks good lol
Oh I don't know if this means anything at this point but I forgot to mention that sometimes when I powered up my Dr_A board the diag LED would be lite would have to cycle a few times before it would go out
I spent some time this morning making you a board. I got it all working then removed the sd card, the ram chip, the eeprom and the propeller. So it should be easy to swap the chips you have into the board. I can send that board and two blank boards if you like for $40. It should make things a lot easier if you have something that is working out of the box. I'll get it in the post Monday.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
[noparse][[/noparse]quote]
"I know you have answered the question of Amstrad's policy on the use of the Spectrum ROMs before but the debate has come up
again on comp.sys.sinclair and as much as I tell people what I believe it is, they want a definitive answer. So when you have time here
are the questions. Thanks!
1) What exactly do you have to do to use Sinclair ROMs in an emulator, such as acknowledgements etc?"
Amstrad are happy for emulator writers to include images of our copyrighted code as long as the (c)opyright messages are not altered
and we appreciate it if the program/manual includes a note to the effect that "Amstrad have kindly given their permission for the
redistribution of their copyrighted material but retain that copyright".
www.worldofspectrum.org/permits/amstrad-roms.txt
The site http://www.worldofspectrum.org/archive.html seems to have a ridiculous amount of Spectrum software on it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 1/30/2010 4:22:10 AM GMT
Those modules look like RIMMs from Rambus days. I will start to wire the second SDRAM I have on to the sawn off "Big Z80 Experiment Board". I built it as an Arduino look-a-like so that it was a DemoBoard with it's "shield" on but also it is a sort of naked Blade2 without it, so that the max number of pins are available. (the mouse 6pin socket was knicked for the "spread out DracBlade")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The ones I'm most familiar with are round the 32Mb,64Mb size, eg PC100 and PC133. I've got lots and they are pretty cheap on ebay $5-$10.
I gather they are SDRAM so presumably static. But could you get the sockets for them? And what could you store in all that memory? Would you have to invent some bloatware to justify having it??
I'm starting to pull together some networking protocols - I have two boards working and now have added a third. So the airwaves will get a little crowded and I think I need to invent some sort of packet routing system. The thing that is confusing me is where to put it. Am starting to get close to filling up hub memory. Could I load some of the PASM blocks into cogs then does that free up space in hub once they are loaded up? Or - how about running two CP/M emulations concurrently by swapping the ram bank? Just need a temp store of the registers before flipping betweeen them. Or do I patch CP/M on the fly and poke a capture program into high memory?
The issue is a remote board that sends out some bytes (eg in response to a DIR request). I want to wrap those bytes in a packet so I want to capture them as the come out of CP/M's CONOUT.
Specifically, a packet might come in with a list of all the routers it went through, so I want to grab that list, reverse it, and add it to the bytes going back out.
I wish I had more hub ram. So - when you have some PASM code, if you load it into a cog is there now a redundant copy of that code in hub? Maybe I could load the VGA font data for instance off the sd card. But I am very confused about cog and hub ram at the moment. Help would be most appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Or you could load the cog code directly from SDCard, i.e. up to 2K at a time.
Post Edited (kuroneko) : 1/30/2010 12:42:48 PM GMT
The bit I don't quite understand is transferring data between hub and cog. If it is compiled as one big program, I presume the compiler then puts links in so when you read and write bytes from within PASM code it reads from the right place. eg a rdlong.
But if you (say) compiled that PASM DAT section as a seperate module, and then had a rdlong instruction, how would it know to get the long from the right place? Especially as the hub code might change over time. Would you have to rewrite the code to transfer data via a fixed location eg some longs at the top of memory?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The other way is to entirely rely on the parameter value passed into cognew/coginit which then appears in the read-only par register. The PASM code will treat this as its parameter/communication area. So whatever the launch code sets up (could be top of memory, could be somewhere in the middle) that's where the cog gets its data from. It only has to be a single long as you could have a command which sets an internal value for a hub communication area (e.g. a bit like a setBaseAddress() function). Another approach is to have one long for the command and a few more for the parameters (usually located after the command). Take your pick [noparse]:)[/noparse]
So there are enough ways to avoid rewrites.
I have not got one good purpose for any large memory. It was a thought of the latches being contained within the mem chip that interested me, allowing the chip count of RamBlade with the ins and outs of the DracBlade. SDRAM is still dynamic ram, just with the actions being clocked and so becoming SYNCRONOUS (not static) with the bus actions. The refresh stuff is contained within the chip, and so is faster, but I don't think the /RAS, /CAS latches work as the old original stuff did. This won't allow the ADDR low(/RAS), ADDR high (/CAS) and DATA to be multiplexed onto the same pins. I might go back to the original plans of CPLD + SRAM.
OR ....
Just accept reality and get on with what I have already, after all there are loads of spare latched pins available for bigger memory should it ever be needed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 1/30/2010 10:19:16 PM GMT