Reworking the board for TV out shouldn't be too hard. I do have an NTSC monitor I can use with this. I suppose I should ask what pins you used and how you connected the sound for the TRS80 emulator. That is also something I'd like to add. I built a pair of these boards and one of them is set aside to modify as needed to support the TRS80 emulator.
RobotWorkshop said...
Reworking the board for TV out shouldn't be too hard. I do have an NTSC monitor I can use with this. I suppose I should ask what pins you used and how you connected the sound for the TRS80 emulator. That is also something I'd like to add. I built a pair of these boards and one of them is set aside to modify as needed to support the TRS80 emulator.
You can of course define the pin. The default is pin #18, as the resistor for TV on that pin is the best(?) for 1pin TV as well.
I don't know if this thread is okay to file a complaint...
The new SPI/XMM code of hairymnstr doesn't work together with the VGA driver for me. Did anyone try this combination? VGA_HiRes_Text together with mb_small_spi?
The combination with my own TV80 object works fine. I'm going to continue to write the VT100 code with TV until someone verified that the problem has to be on my side. I wouldn't know why.. overall program size? With VGA I'm at 6975 longs, with TV at 6477 longs and a free cog.
Both the spi/xmm and vga code work ok on my board. But the memory is around 6100. Is the problem that it won't compile? Or that it will compile but won't run?
I'm not sure how it behaves as the memory fills up and ?overflows. Does it compile objects in the order they are listed, and in which case, if the last one is the vga object then this would be the one that wouldn't work?
As an aside, I got two versions of CP/M working concurrently last night. It is very close to working. I can change from version 1 to version 2 then back to version 1, though it crashes when going back to version 2 the second time. Just one little bug to squish! But this does show the general concept that it is possible to run several virtual machines on the propeller. Instead of 8 cogs running 2k of code, I've got two CP/M machines running 64k of code. And once it is working it ought to be possible to run up to 8 CP/M machines each with 64k of code.
Eight C programs all running in parallel? Or a mix of languages all running in parallel?
Dr_Acula said...
Both the spi/xmm and vga code work ok on my board. But the memory is around 6100. Is the problem that it won't compile? Or that it will compile but won't run?
The problem is the SPI read command returns an error. I haven't looked at the error code yet, if there is any... the result value in the command long is < 0.
It halts in the boot code at $ff54, which is hit when the hdisk read returns an error - which I do when either the SPI read or the memory move from hub to XMM return an error.
Dr_Acula said...
I'm not sure how it behaves as the memory fills up and ?overflows. Does it compile objects in the order they are listed, and in which case, if the last one is the vga object then this would be the one that wouldn't work?
I tried moving objects up and down a bit without any effect. I can't change the ordering too much. At least the SPI/XMM object has to be the first or I would be running into the known problems with the fsrw2.6 object again. I'm really clueless where to look for a bug. This is too bad, because my VT100 PASM LMM code is working pretty fine with the TV object already. You can attach it to any video frame buffer with given width and height.
Dr_Acula said...
As an aside, I got two versions of CP/M working concurrently last night. It is very close to working. I can change from version 1 to version 2 then back to version 1, though it crashes when going back to version 2 the second time. Just one little bug to squish! But this does show the general concept that it is possible to run several virtual machines on the propeller. Instead of 8 cogs running 2k of code, I've got two CP/M machines running 64k of code. And once it is working it ought to be possible to run up to 8 CP/M machines each with 64k of code.
Eight C programs all running in parallel? Or a mix of languages all running in parallel?
You need at least one cog doing the interfacing to the outside world, though Perhaps 5 CP/Ms would be possible with just the serial driver, the Z80 core and the SPI/XMM object for the hard disk I/O.
Toby: Can you post some of your modified code to see if I can spot the problem. I didn't realise there were variants even within the DracBlade platform so the code I wrote was not very flexible on hardware, it's possible there's a bus conflict somewhere.
Pullmoll: I have no idea what the problem you're seeing is. Any chance you could point me at the top-level code (I assume it's in a revision controlled repo somewhere?). As far as having to run it in cog 1 or 2 is concerned my code launches it in cog 5 and I've seen no difference when I moved to cog 2. The only time I saw that kind of error while requesting a block was when I had some block numbers wrong and it was copying the wrong code to RAM. Don't think that's what's going on here though. It's possible I forgot to do the flags properly on one of the RAM operations so it's returning an error code by accident.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Dr_Acula said...
pullmoll, could you post the code that isn't working as a zip? warts_and_all. I'll see if I can replicate the fault.
I'll post an update to the qz80 thread.
@Nathan: No, the problem with the SPI code not running in a cog beyond 2 on my hardware has nothing to do with your code. It has been so with the original fsrw2.6 rr006 code, too. It may be that my DracBlade needs a capacitor in some place or perhaps a different pullup on the SD card ports? I think (please Dr_A confirm?) that my DracBlade is a rev 5 board. I did add the resistors and connector for the TV out, if that makes a difference (the pins are the same as some for VGA out).
Edit: Update! I found the (stupid) bug and it was of course me using the carry flag with rdlong to detect negative numbers. The carry, however, is the parity and not the sign bit for rdlong. DUH!
Now I get a picture with every odd character row missing!? See attachment.
Edit 2: Another stupid bug (will I ever produce intelligent bugs?) was in the color table (filled with longs, but it is an array of words) and in the scrolling (forgot to add the screen base address and was scrolling #0 ff.) Now the VGA looks reasonably well. It looks like my software cursor is showing through, which it is not supposed to do if a "hardware" cursor is available, like in the VGA driver case. No color changing yet, but that will come.
Apropos VGA and colors or other attributes: Isn't there an object to drive the VGA output that is capable of attributing every character of the display? Row colors are nice, but a terminal should be able to change the attributes for every character. The VT100 code evaluates the <ESC>[noparse][[/noparse]...m sequences and changes its internal attributes, only to not use them afterwards
Yours picture looks as 2-COG HI-Res VGA with only one cog functioning correctly.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Yours picture looks as 2-COG HI-Res VGA with only one cog functioning correctly.
Regards
Nope, it isn't. The issue is solved already. The color-per-row array is an array of words, while I used a longfill() to fill it. This leads to every other word being 0.
If it had been the 2nd cog, then it would have been 4 pixel lines intermittent display, because each cog does 4 scanrows before letting the other continue with the next 4 rows.
OK. I see now that.
Haven not reflected that on picture You have entire Chars displayed correctly
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Great news Juergen! I was just downloading the latest from the qZ80 thread when I noticed your release notes and found I'd somehow marked this thread as old without reading about the solution.
I'm beginning to get an idea about why the SD card cog might be significant, it's pretty far-fetched so I need to check some facts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
If you take a look at the propeller data sheet (not manual) there's a diagram at the bottom of page 29 that illustrates how the wired or is performed between the cogs and the I/O. Using a higher numbered cog will cause higher current consumption and increase gate delay to the output pin on the DracBlade which uses pins 12-15 for the SD card. If your power supply isn't sufficiently buffered, or the SD I/O pins are drawing more current than we expect for some reason, or you're right on the edge of SD performance, changing the cog may well affect the function of the SD card.
Is that plausible? I've only given the datasheet a fairly brief skim read, anyone else seen this kind of problem with high speed pin toggling?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Juergen's program works fine on my board. See photo.
So perhaps it is a power supply issue. I'm using switching regulators - is anyone else doing this?
Also I have a 22uF tantalum next to the sd card - for the homebrew boards is there something similar?
Re changing the color of each character, the problem is you need more ram to store those settings. I see you are over 7000 longs already, and that does not include the LCD20x4 code and a few other things (banked memory etc). Let's see - 3 bits per colour per character if we assume just the foreground changes, 80x40 characters = 3200 bytes and we can store two colour settings in a byte with 6 bits so 1600 bytes? I guess you could store that in the leftover space from a cog and not use up any extra space? I agree that it would be great to be able to do this. Also if there was an ascii character that was a simple rectangular block, and you had 16 colours per block, you could start to think about simple vga graphics.
I'm using switchers but I get Er1 on boot. What package are you using? Can you update page 1 with the latest? I will give it a try tonight when I get home from work.
See attached. Though if you are getting Er1 this may not work either. Er1 means the sd card is not working, and there can be many reasons for that. Fat16 vs Fat32, corrupted card, power supply issues. Has it ever worked in the past?
Yep, it work fine on previous versions. I'm using the Spin-files-mar-9 version without any problems using the same SD Card. Just seems to be the new spi code that is not working.
Dr_Acula said...
Let's see - 3 bits per colour per character if we assume just the foreground changes, 80x40 characters = 3200 bytes and we can store two colour settings in a byte with 6 bits so 1600 bytes?
Yes, that's a lot of hub RAM, but it just came to me: why not use external RAM for the text+attributes map? It would require locking for the memory access to prevent two cogs accessing XMM at the same time, but I think that burst reading a character row + its attributes from XMM to hub RAM could work. After all that is how many old computer designs worked: they put the CPU into a dormant state while accessing the video RAM. This is the source of the "additional wait states" for video refresh that was unavoidably impertinent back then... and it was the reason why you couldn't compare any two system's performances by their CPU clock alone.
The locking in rd_byte/wr_byte could fit in the CP/M qz80, while it would not fit in the cog for the TRS80. But the latter has just the fixed 1KB of video RAM anyway.
The question is if it will be possible to render a (number of) bitmap rows fast enough for a video driver cog - be it TV or VGA - to have its bitmap bits available in time.
Ok, what is the VGA refresh rate? 70hz I think. And say you want to read 80x40 characters and for each character the ascii value and also a byte that describes some colour attributes. At the moment 3200 bytes are stored in hub. Maybe another 3200 could be stored for colour by recycling old cog space? But if these are external ram - ok 3200 bytes 70 times a second = 224,000 times a second. How fast is external ram? Can we grab bytes from external ram at about 3Mhz or even faster? If so that is only a 10% performance decrease.
Is there a clever way to make this run faster? Let's say you create a list of the display colours first for all 3200 bytes:
yellow on blue
count 30 bytes
white on blue
count 1 byte
red on blue
count 40 bytes
For screens with few colour changes, eg a Wordstar screen with a few characters highlighted, that list is very small. Maybe only 20 bytes long. And easy to decode in pasm - just keep adding until get to the next change, then look it up.
Of course, for games graphics with many colour changes the list gets a lot longer. But at least speed is at a maximum when the entire screen is all one colour.
@MaxS - that is hairymnstrs code that isn't working. Though for me it works better than any other sd code I've seen. What do we suggest?
1) Go back to the March 9 version?
2) Ask Hairymnstr to see what is wrong with the code for your board/brand of sd card?
3) Use Juergen's latest code (it works on my board. But does it work on your board??)
If you can test Juergen's program attached a few posts above when you get home, then if that works we will use that. If not, then ? back to the old March versions.
Ok, attached is the code I'm using which is back to the old sd card code for the moment. I'm doing this partly because there seems to be something wrong with the sd code for some people (but not me).
Also a second reason. I've spent a day writing code to do banked CP/M and after exhaustive testing I found that it kept resetting back to bank 0 when some CP/M code was run. It took a lot of extra code to find that including dumping registers and dumping memory. Not easy to find either as both banks start off with identical code. Somewhere in the hairymnstr code something is overwriting the high latch value - I suspect there is a long that is not being AND or ORed properly. Possibly the ram driver code.
So I've gone back to the Cluso code as there is only one place that the high latch is changed and this means that once the latch is set to a different bank it stays there.
So if anyone wants to test this, what we have is some code that is the same as the March 28th version. If you look through the beginning of the Main code there is an #ifdef BankedCPM. If you enable this and recompile/download then you can test it in two ways. Either run mbasic and do an OUT &H7F,0 for bank 1 and an OUT &H7E,0 for bank 0. Or in the above zip are two little .COM programs that do this automatically when you run them, BANK0.COM and BANK1.COM.
When you run BANK1 the first time it starts CP/M in this bank. The screen color changes from white text to orange text, and I also blank the screen as it is confusing to have the other banks text on the screen in the current banks colour.
So we now have two instances of CP/M running at the same time.
I've done some experiments trying to trap F12 on the keyboard to switch banks but it still doesn't work properly as I need to trap that key before it gets into CP/M as CP/M gets very unhappy if it has been told there is a keypress, but if the other bank goes and gets that keypress!
In reality one would not use the keyboard. Instead there would be a timer running in the Main program that changes between each bank. So I need to add Juergen's code where each instruction tests for interrupts. Or alternatively, it swaps banks every n calls to the i/o code (this latter might be better as it prioritises things better, eg if one bank is just polling the keyboard, better to hand over to the other bank sooner so that other bank can do some maths etc).
But the main way to use this is the way MP/M runs, with various devices attached to each instance of CP/M. eg the keyboard and vga could attach to one bank, and the serial port1 could attach to another bank, and maybe serial port2 could attach to the third bank. Perhaps the LCD could be attached to any bank for diagnostic purposes?
What I really want to do is run some packet processing software in the background on port2. I think that is getting close. And values can be passed between banks using either in/out commands, or with the bigpoke and bigpeek routines that can put bytes anywhere in the 512k of ram.
I have just tried the same freezing trick, on getting up this morning.
At ambient, 20C-70F, it gave Er1. A short blast from the upside-down airduster so that the frost started to show on the Prop and the A: promt was had. Within a couple of mins the boot failed again.
The SD is right by the Prop pins used but they are extended to the upper memory board, via PCB traccks and then a couple of inches of IDE cable. I will try isolating that bit tonight.
ADDIT
I will also try some extra decouplers. At present there are a bunch of SM 0.1uF and 10uF.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 4/13/2010 6:34:02 AM GMT
Right, I'll try and post a debug version tonight if people can test and let me know, we might be able to start narrowing down the search for this bug.
I reckon it's being caused by the new FSRW code clocking the SD faster and the variable delays and power consumption on various versions of the board are causing different behaviour.
If my suspicions are correct, there are two possible solutions:
1. Slow the code down so everyone can use it on any hardware.
2. Tighten up the hardware specs a bit so everyone gets the fastest performance.
The only reasonable way the second one is going to work is if we can correct the fault with a minor component value change.
Are the people experiencing difficulties using a 22uF TANTALUM capacitor or an electrolytic on the power supply to the SD card? Tantalum caps have a lower effective series resistance and behave like larger value electrolytics. If you're using an electrolytic cap can you try swapping for a 100uF and see if that helps?
SD cards can "steal" power from the clock line if they aren't being supplied robustly enough, that may well be enough to be causing the prop I/O to cause all these problems.
I don't really want to go back to the sdpsiFemto code as that won't work with high capacity cards and I don't want to be paying a premium for "old fashioned" SD cards. It might be worth me tweaking the object for FSRW femto so that the interface is the same, that would mean the two objects can be swapped without changing the higher level files which will allow development on other features to continue while the new FSRW bugs are ironed out.
Dr_A: Re the high latch problem, is that in the latest version? I'll have a look at the code, I suspect the problem is being caused by the toggling of the LED on disk access not retaining the right value for the address latch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Re the high latch, yes it sounds like the led is the issue. Do you keep a local copy of the byte so you can AND / OR with that byte?
Re the sd card, I'd like to use the hairy sd card code too. There are two reasons, speed and the fact your code comes in 400 longs less and saves a cog. Speed is not so important. Maybe we are finding the limits for speed. There is a certain speed (? above 10mhz) where you have to start thinking and designing like an RF engineer with ground planes, short traces, ground shielding, matched lengths, transmission line termination etc. Or maybe it is a current draw problem?
Interesting that Juergen's code is working, perhaps it's the order the cogs are being started.
MaxS: Do you have a 22uF Tantalum cap on the SD power supply?
Dr_A: the high latch value is now supposed to be held in a long in the spin layer as the PASM only had room for a simple "write a byte to high latch" routine. Calling the Set/Clear LED spin routines is supposed to grab the local copy of the high latch value and perform the appropriate or/andn in spin before passing the byte. The bug is either that I'm not saving the latch value when it gets set, or that the LED set/reset routines aren't reading the current value back correctly. I'll take a look tonight when I get home.
I don't think we need to start worrying about RF issues yet, you can run up to 10MHz on wire-wrap stuff if you're tidy, and your board is pretty nicely laid out. I think it's probably just the current drain and card speed combinations that are causing the problems. I'll have to look at the mb_small_spi code and see how the clock speed for the SD clock signal is derived, I know it's using some of the counter functionality and I'm not too clear on how they work to be honest. The important thing is to keep the multi-block read/write routines as these unify the "old fashioned" SD and HCSD access, otherwise we need to start translating to byte addresses for the old fashioned cards and that's a whole load of extra code. (and a bit of extra time)
Nathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Dr_A: Found the latch bug, I wasn't saving the value of the latch locally properly. Haven't tested the code but I'm fairly confident that it should be working now. I'll upload it later.
Regarding SD card access;
I now have an understanding of the counter based SPI code (which is ingenious) but ironically is going to be tricky to slow down (mainly due to the lack of spare longs in the cog). I think the reason that some boards aren't keeping up is that the clock for the SD is running at 20MHz (which is pretty near the limit for SPI mode if I remember correctly technically I think 2MBps was the quoted raw speed which is 16MHz clock of course the free version of the specs doesn't include the SPI timing diagrams.) However to provide a longer settling time for the output the duty cycle is 25% which leaves only 12.5nS high pulse width. Combine that with a few gate delays in a busy prop and it looks more likely that it's just too fast for some cards. I'll see what I can do about slowing it down (probably have to halve it) should still be quicker than the old bit-banging code, and support HCSD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Have Counter driven Drivers not possibility to have programmable SPED settings ?
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I don't think so Sapieha, it seems as if they will only run off the system clock (80MHz). The total period was 4 system clocks which coincided with the instruction length for the rol/shr instructions used to shift data in and out. At a lower speed I think the counters would still be summing bits every clock tick.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Comments
Robert
You will need BST or BSTc to compile this, PropTool will spit out it's dummy at the #ifdefs. Even Brads IDE will req the options to allow them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
You can of course define the pin. The default is pin #18, as the resistor for TV on that pin is the best(?) for 1pin TV as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
The new SPI/XMM code of hairymnstr doesn't work together with the VGA driver for me. Did anyone try this combination? VGA_HiRes_Text together with mb_small_spi?
The combination with my own TV80 object works fine. I'm going to continue to write the VT100 code with TV until someone verified that the problem has to be on my side. I wouldn't know why.. overall program size? With VGA I'm at 6975 longs, with TV at 6477 longs and a free cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I'm not sure how it behaves as the memory fills up and ?overflows. Does it compile objects in the order they are listed, and in which case, if the last one is the vga object then this would be the one that wouldn't work?
As an aside, I got two versions of CP/M working concurrently last night. It is very close to working. I can change from version 1 to version 2 then back to version 1, though it crashes when going back to version 2 the second time. Just one little bug to squish! But this does show the general concept that it is possible to run several virtual machines on the propeller. Instead of 8 cogs running 2k of code, I've got two CP/M machines running 64k of code. And once it is working it ought to be possible to run up to 8 CP/M machines each with 64k of code.
Eight C programs all running in parallel? Or a mix of languages all running in parallel?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/12/2010 2:26:24 AM GMT
It halts in the boot code at $ff54, which is hit when the hdisk read returns an error - which I do when either the SPI read or the memory move from hub to XMM return an error.
I tried moving objects up and down a bit without any effect. I can't change the ordering too much. At least the SPI/XMM object has to be the first or I would be running into the known problems with the fsrw2.6 object again. I'm really clueless where to look for a bug. This is too bad, because my VT100 PASM LMM code is working pretty fine with the TV object already. You can attach it to any video frame buffer with given width and height.
You need at least one cog doing the interfacing to the outside world, though
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/12/2010 3:08:02 AM GMT
Pullmoll: I have no idea what the problem you're seeing is. Any chance you could point me at the top-level code (I assume it's in a revision controlled repo somewhere?). As far as having to run it in cog 1 or 2 is concerned my code launches it in cog 5 and I've seen no difference when I moved to cog 2. The only time I saw that kind of error while requesting a block was when I had some block numbers wrong and it was copying the wrong code to RAM. Don't think that's what's going on here though. It's possible I forgot to do the flags properly on one of the RAM operations so it's returning an error code by accident.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'll post an update to the qz80 thread.
@Nathan: No, the problem with the SPI code not running in a cog beyond 2 on my hardware has nothing to do with your code. It has been so with the original fsrw2.6 rr006 code, too. It may be that my DracBlade needs a capacitor in some place or perhaps a different pullup on the SD card ports? I think (please Dr_A confirm?) that my DracBlade is a rev 5 board. I did add the resistors and connector for the TV out, if that makes a difference (the pins are the same as some for VGA out).
Edit: Update! I found the (stupid) bug and it was of course me using the carry flag with rdlong to detect negative numbers. The carry, however, is the parity and not the sign bit for rdlong. DUH!
Now I get a picture with every odd character row missing!? See attachment.
Edit 2: Another stupid bug (will I ever produce intelligent bugs?) was in the color table (filled with longs, but it is an array of words) and in the scrolling (forgot to add the screen base address and was scrolling #0 ff.) Now the VGA looks reasonably well. It looks like my software cursor is showing through, which it is not supposed to do if a "hardware" cursor is available, like in the VGA driver case. No color changing yet, but that will come.
Apropos VGA and colors or other attributes: Isn't there an object to drive the VGA output that is capable of attributing every character of the display? Row colors are nice, but a terminal should be able to change the attributes for every character. The VT100 code evaluates the <ESC>[noparse][[/noparse]...m sequences and changes its internal attributes, only to not use them afterwards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/12/2010 12:27:11 PM GMT
Yours picture looks as 2-COG HI-Res VGA with only one cog functioning correctly.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Nope, it isn't. The issue is solved already. The color-per-row array is an array of words, while I used a longfill() to fill it. This leads to every other word being 0.
If it had been the 2nd cog, then it would have been 4 pixel lines intermittent display, because each cog does 4 scanrows before letting the other continue with the next 4 rows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
OK. I see now that.
Haven not reflected that on picture You have entire Chars displayed correctly
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I'm beginning to get an idea about why the SD card cog might be significant, it's pretty far-fetched so I need to check some facts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
If you take a look at the propeller data sheet (not manual) there's a diagram at the bottom of page 29 that illustrates how the wired or is performed between the cogs and the I/O. Using a higher numbered cog will cause higher current consumption and increase gate delay to the output pin on the DracBlade which uses pins 12-15 for the SD card. If your power supply isn't sufficiently buffered, or the SD I/O pins are drawing more current than we expect for some reason, or you're right on the edge of SD performance, changing the cog may well affect the function of the SD card.
Is that plausible? I've only given the datasheet a fairly brief skim read, anyone else seen this kind of problem with high speed pin toggling?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I just saw your theory. To test it in a brutal way I froze the Prop. It fires up! When it warmed up again it failed to the Er1.
There was a double A>; AUTO ..... line, once, but all the A-R drives run.
(This is on the "bent" board that I have shifted the pins up to the top end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
So perhaps it is a power supply issue. I'm using switching regulators - is anyone else doing this?
Also I have a 22uF tantalum next to the sd card - for the homebrew boards is there something similar?
Re changing the color of each character, the problem is you need more ram to store those settings. I see you are over 7000 longs already, and that does not include the LCD20x4 code and a few other things (banked memory etc). Let's see - 3 bits per colour per character if we assume just the foreground changes, 80x40 characters = 3200 bytes and we can store two colour settings in a byte with 6 bits so 1600 bytes? I guess you could store that in the leftover space from a cog and not use up any extra space? I agree that it would be great to be able to do this. Also if there was an ascii character that was a simple rectangular block, and you had 16 colours per block, you could start to think about simple vga graphics.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/13/2010 12:52:53 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/13/2010 1:19:58 AM GMT
Yes, that's a lot of hub RAM, but it just came to me: why not use external RAM for the text+attributes map? It would require locking for the memory access to prevent two cogs accessing XMM at the same time, but I think that burst reading a character row + its attributes from XMM to hub RAM could work. After all that is how many old computer designs worked: they put the CPU into a dormant state while accessing the video RAM. This is the source of the "additional wait states" for video refresh that was unavoidably impertinent back then... and it was the reason why you couldn't compare any two system's performances by their CPU clock alone.
The locking in rd_byte/wr_byte could fit in the CP/M qz80, while it would not fit in the cog for the TRS80. But the latter has just the fixed 1KB of video RAM anyway.
The question is if it will be possible to render a (number of) bitmap rows fast enough for a video driver cog - be it TV or VGA - to have its bitmap bits available in time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/13/2010 2:18:43 AM GMT
Ok, what is the VGA refresh rate? 70hz I think. And say you want to read 80x40 characters and for each character the ascii value and also a byte that describes some colour attributes. At the moment 3200 bytes are stored in hub. Maybe another 3200 could be stored for colour by recycling old cog space? But if these are external ram - ok 3200 bytes 70 times a second = 224,000 times a second. How fast is external ram? Can we grab bytes from external ram at about 3Mhz or even faster? If so that is only a 10% performance decrease.
Is there a clever way to make this run faster? Let's say you create a list of the display colours first for all 3200 bytes:
yellow on blue
count 30 bytes
white on blue
count 1 byte
red on blue
count 40 bytes
For screens with few colour changes, eg a Wordstar screen with a few characters highlighted, that list is very small. Maybe only 20 bytes long. And easy to decode in pasm - just keep adding until get to the next change, then look it up.
Of course, for games graphics with many colour changes the list gets a lot longer. But at least speed is at a maximum when the entire screen is all one colour.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
1) Go back to the March 9 version?
2) Ask Hairymnstr to see what is wrong with the code for your board/brand of sd card?
3) Use Juergen's latest code (it works on my board. But does it work on your board??)
If you can test Juergen's program attached a few posts above when you get home, then if that works we will use that. If not, then ? back to the old March versions.
Ok, attached is the code I'm using which is back to the old sd card code for the moment. I'm doing this partly because there seems to be something wrong with the sd code for some people (but not me).
Also a second reason. I've spent a day writing code to do banked CP/M and after exhaustive testing I found that it kept resetting back to bank 0 when some CP/M code was run. It took a lot of extra code to find that including dumping registers and dumping memory. Not easy to find either as both banks start off with identical code. Somewhere in the hairymnstr code something is overwriting the high latch value - I suspect there is a long that is not being AND or ORed properly. Possibly the ram driver code.
So I've gone back to the Cluso code as there is only one place that the high latch is changed and this means that once the latch is set to a different bank it stays there.
So if anyone wants to test this, what we have is some code that is the same as the March 28th version. If you look through the beginning of the Main code there is an #ifdef BankedCPM. If you enable this and recompile/download then you can test it in two ways. Either run mbasic and do an OUT &H7F,0 for bank 1 and an OUT &H7E,0 for bank 0. Or in the above zip are two little .COM programs that do this automatically when you run them, BANK0.COM and BANK1.COM.
When you run BANK1 the first time it starts CP/M in this bank. The screen color changes from white text to orange text, and I also blank the screen as it is confusing to have the other banks text on the screen in the current banks colour.
So we now have two instances of CP/M running at the same time.
I've done some experiments trying to trap F12 on the keyboard to switch banks but it still doesn't work properly as I need to trap that key before it gets into CP/M as CP/M gets very unhappy if it has been told there is a keypress, but if the other bank goes and gets that keypress!
In reality one would not use the keyboard. Instead there would be a timer running in the Main program that changes between each bank. So I need to add Juergen's code where each instruction tests for interrupts. Or alternatively, it swaps banks every n calls to the i/o code (this latter might be better as it prioritises things better, eg if one bank is just polling the keyboard, better to hand over to the other bank sooner so that other bank can do some maths etc).
But the main way to use this is the way MP/M runs, with various devices attached to each instance of CP/M. eg the keyboard and vga could attach to one bank, and the serial port1 could attach to another bank, and maybe serial port2 could attach to the third bank. Perhaps the LCD could be attached to any bank for diagnostic purposes?
What I really want to do is run some packet processing software in the background on port2. I think that is getting close. And values can be passed between banks using either in/out commands, or with the bigpoke and bigpeek routines that can put bytes anywhere in the 512k of ram.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/13/2010 6:27:37 AM GMT
At ambient, 20C-70F, it gave Er1. A short blast from the upside-down airduster so that the frost started to show on the Prop and the A: promt was had. Within a couple of mins the boot failed again.
The SD is right by the Prop pins used but they are extended to the upper memory board, via PCB traccks and then a couple of inches of IDE cable. I will try isolating that bit tonight.
ADDIT
I will also try some extra decouplers. At present there are a bunch of SM 0.1uF and 10uF.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 4/13/2010 6:34:02 AM GMT
I reckon it's being caused by the new FSRW code clocking the SD faster and the variable delays and power consumption on various versions of the board are causing different behaviour.
If my suspicions are correct, there are two possible solutions:
1. Slow the code down so everyone can use it on any hardware.
2. Tighten up the hardware specs a bit so everyone gets the fastest performance.
The only reasonable way the second one is going to work is if we can correct the fault with a minor component value change.
Are the people experiencing difficulties using a 22uF TANTALUM capacitor or an electrolytic on the power supply to the SD card? Tantalum caps have a lower effective series resistance and behave like larger value electrolytics. If you're using an electrolytic cap can you try swapping for a 100uF and see if that helps?
SD cards can "steal" power from the clock line if they aren't being supplied robustly enough, that may well be enough to be causing the prop I/O to cause all these problems.
I don't really want to go back to the sdpsiFemto code as that won't work with high capacity cards and I don't want to be paying a premium for "old fashioned" SD cards. It might be worth me tweaking the object for FSRW femto so that the interface is the same, that would mean the two objects can be swapped without changing the higher level files which will allow development on other features to continue while the new FSRW bugs are ironed out.
Dr_A: Re the high latch problem, is that in the latest version? I'll have a look at the code, I suspect the problem is being caused by the toggling of the LED on disk access not retaining the right value for the address latch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
No hint of Er1
Re the high latch, yes it sounds like the led is the issue. Do you keep a local copy of the byte so you can AND / OR with that byte?
Re the sd card, I'd like to use the hairy sd card code too. There are two reasons, speed and the fact your code comes in 400 longs less and saves a cog. Speed is not so important. Maybe we are finding the limits for speed. There is a certain speed (? above 10mhz) where you have to start thinking and designing like an RF engineer with ground planes, short traces, ground shielding, matched lengths, transmission line termination etc. Or maybe it is a current draw problem?
Is it possible to drop the speed back a bit?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
MaxS: Do you have a 22uF Tantalum cap on the SD power supply?
Dr_A: the high latch value is now supposed to be held in a long in the spin layer as the PASM only had room for a simple "write a byte to high latch" routine. Calling the Set/Clear LED spin routines is supposed to grab the local copy of the high latch value and perform the appropriate or/andn in spin before passing the byte. The bug is either that I'm not saving the latch value when it gets set, or that the LED set/reset routines aren't reading the current value back correctly. I'll take a look tonight when I get home.
I don't think we need to start worrying about RF issues yet, you can run up to 10MHz on wire-wrap stuff if you're tidy, and your board is pretty nicely laid out. I think it's probably just the current drain and card speed combinations that are causing the problems. I'll have to look at the mb_small_spi code and see how the clock speed for the SD clock signal is derived, I know it's using some of the counter functionality and I'm not too clear on how they work to be honest. The important thing is to keep the multi-block read/write routines as these unify the "old fashioned" SD and HCSD access, otherwise we need to start translating to byte addresses for the old fashioned cards and that's a whole load of extra code. (and a bit of extra time)
Nathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Dr_A: Found the latch bug, I wasn't saving the value of the latch locally properly. Haven't tested the code but I'm fairly confident that it should be working now. I'll upload it later.
Regarding SD card access;
I now have an understanding of the counter based SPI code (which is ingenious) but ironically is going to be tricky to slow down (mainly due to the lack of spare longs in the cog). I think the reason that some boards aren't keeping up is that the clock for the SD is running at 20MHz (which is pretty near the limit for SPI mode if I remember correctly technically I think 2MBps was the quoted raw speed which is 16MHz clock of course the free version of the specs doesn't include the SPI timing diagrams.) However to provide a longer settling time for the output the duty cycle is 25% which leaves only 12.5nS high pulse width. Combine that with a few gate delays in a busy prop and it looks more likely that it's just too fast for some cards. I'll see what I can do about slowing it down (probably have to halve it) should still be quicker than the old bit-banging code, and support HCSD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Have Counter driven Drivers not possibility to have programmable SPED settings ?
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."