Yes, close, but not yet there.. MP/M hangs on the DracBlade after displaying the user segments :-(
It may be waiting for a status port. I'll add some debug code to io.spin to see if that's the case.
Edit: No, it's running away after enabling interrupts. I probably have one of the SIMH commands wrong: set interrupt address or set timer interval.
For the disk images: I think we should have one system disk including both, CP/M and MP/M, with MP/M startable as a command. You probably won't use it all the time, or not every user would use it all the time. For the other hard disks I would suggest to put e.g. your own MAC/BAS/C files on the 2nd drive, perhaps together with the compilers and Wordstar. 8MB is a lot of space for that.
That sounds fine with disks. I've spent some hours this afternoon working on packet processing code ready to put this in the serial port2 user. Working with vb.net but I'll translate to C or Basic once it is working. How are you going with that MPM bug?
Dr_Acula said...
That sounds fine with disks. I've spent some hours this afternoon working on packet processing code ready to put this in the serial port2 user. Working with vb.net but I'll translate to C or Basic once it is working. How are you going with that MPM bug?
I tried several things and also found a couple of bugs, but it still isn't running. One major bug was that interrupts in qz80 would not exit a HALTed CPU. The status quo still is: mpm hangs after the hello message, but not always. Sometimes it shows the prompt and a BDOS error on a file $0$.SUP on console #0, $1$.SUP on console #1... Since it all works on SIMH, it still has to be a subtle bug on my side in either io or the Z80 emulation itself. When I traced the io activity, the last thing the code does is reset the hdsk (write 1 to port $fd) many times and then stops doing anything at all, as if it was running in a tight loop with interrupts disabled. Since some games on the TRS80 also don't work and seem to hang, e.g. Robert's Chopper, there definitely _is_ a bug lurking in qz80.
The bug that was in the previous core was some 8 or 16 bit register overflowing to 32 bits and afterwards causing loops to take forever. IIRC it was DJNZ, where B could underflow. This bug isn't in the new core, but it may be a similar kind of bug elsewhere.
Umm.. it just came to me: DracBlade_spin_warp.spin doesn't handle memory access beyond $ffff at all! The address used is just the low and middle part, so my read/write sector and DMA code can't work. D'OH! That is when I read a sector and want to store it in bank #1, it really goes to bank #0 somewhere, destroying the code that lives there.
Dr_Acula said...
So you have to address the high latch somehow? More coffee required?
Yes, exactly. I was under the impression that since the XMM address is full 32 bits that the code would do the A16-A18 lines, too, but it doesn't. I now have an extra "H" command to set the high latch. This doesn't make MP/M work, though.
Can you post a copy of DracBlade_spin_warp.spin - I don't seem to have that one.
All the code in Zicog etc treats the Low and Middle latches together, but the High latch is seperate as it is used a lot less often.
BTW pullmoll if you would like yourself as the screensaver, attached is a tiny text file. With a camera shot from a long way away so it is a bit blurry, suddenly the image comes to life. We could do the Zicog image and all sorts of pictures.
That picture was on my second propeller and was downloaded from the PC using xmodem, then transferred wirelessly to the second board and then the second board was told to TYPE it wirelessly. This all works well, but the system cannot handle multiple boards talking at once. I think that can only be done with packets, so the MP/M work is extremely exciting.
Dr_Acula said...
Can you post a copy of DracBlade_spin_warp.spin - I don't seem to have that one.
All the code in Zicog etc treats the Low and Middle latches together, but the High latch is seperate as it is used a lot less often.
It is in the ./lib directory in the qz80-0.9.12.zip archive.
If banking is enabled, I always set the high latch in read/write byte functions. Checking for a change there would be longer and slower than just setting it.
I'm taking a break now, as I ran out of ideas what to try to get this darn MP/M going.
Ahh, this is what I was asking about last week when you started looking at banked code.
It is less simple than that. The default behaviour of the RAM code is to leave the high latch unaltered. I was suggestung that it could be re-coded to include the high latch to support banked ops.
However I was under the impression you were using a common area buffer, and switching to bank 0 first, that should work because the high address latch should be set to 0 in the I/O handler when you select bank 0. In which case the common area is directly addressable by the 16 bit address
Need to be careful about some of the parameters being passed as longs because most of them get truncated at various points.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
pullmoll, it sounds like you need a break. How long have you been coding for?
My files are now a few days old and you probably have changed the code since then. Any chance you could post the latest code - maybe someone will spot something?
I've been coding for a couple of days now. The last two days searching for bugs in qz80.
The qZ80 thread has my latest files and the disk image I'm using.
@hairymnstr I overlooked that when you asked. I fixed it now by issuing a "H" command with the high bits of the address. This was a bug, but not _the_ bug that causes MP/M to hang.
Right, I haven't looked at the _warp version since the start of last week, I'm trying to remember how it works, I'll try and take a look tonight and see if I spot anything. I take it CVS is up to date?
How does it work on MP/M with respect to the top address bits in a DMA request? I know there is a bank select I/O port so does the disk DMA respect this? Or does it provide a longer address to the hard disk controller port?
It's possible there is still a bug with the bank select wrapper in spin, I didn't have anything to test it with when Dr A spotted the first bug last week.
Thinking about it I don't know if an 'H' command will work, I really need to look at how your code works.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr said...
Right, I haven't looked at the _warp version since the start of last week, I'm trying to remember how it works, I'll try and take a look tonight and see if I spot anything. I take it CVS is up to date?
How does it work on MP/M with respect to the top address bits in a DMA request? I know there is a bank select I/O port so does the disk DMA respect this? Or does it provide a longer address to the hard disk controller port?
The DMA request will have an address from the entire 512KB range. If the incoming DMA address is below the banked memory limit (currently $b000), the current bank base address is added. The 512 byte sector I/O is always going to a fixed buffer in hub RAM and from there to the external RAM (or from external RAM to there). I now have code in io.spin (function hdsk_setup_dma) that sets the address bits 16-18 using the "H" command first, then the "R" or "W" command is sent with the lower 16 bits of the address.
The code in qz80 deals with the high latch bits on its own. It just splits each address in three parts and sets the latches prior to any external memory access. There would possibly be room for improvement if I knew that an address change was only in the lower 8 bits. I have no idea for a quick test for this condition... xor new address with old address and see if any bits but $ff changed. I may give that a try. Three instructions could help avoiding ~15-20 instructions in about 90% of the memory accesses (assuming a sequentially incrementing PC).
pullmoll's complete rewrite of the code is now so much better that it is time to change the 'official' operating system from my code to pullmoll's code. See the first thread. I'm leaving my old code as it was in mid April, but since that date I've been using the pullmoll code. Rather than host his code (which is improving all the time) there is a link to the active 'qZ80' thread. Advantages are:
1) a complete rewrite of the system, most of it in assembly rather than spin
2) faster upload and download speeds - at least 4x faster for xmodem file transfers
3) neater code which is much easier to understand
4) a bigger drive - 32mb for drive A, but also the ability to support standard 8mb SIMH drivers for easy file transfer
5) code boots into CP/M, but you can run MP/M from the CP/M prompt which turns the dracblade into three computers, each with 64k of memory
6) Faster bootup
7) Full Z80 opcodes (the old code only ran 8080).
I'm currently working on networking using packets. There are several different ways to handle packets in the background - you can write drivers in pasm, or spin, or modify CP/M. The disadvantage of the first two is that there is no space left (!) and the disadvantage of changing CP/M as it is no longer SIMH compatable. The new pullmoll code enables MP/M users to talk to each other via virtual ports (you can even write a little 'terminal' program to talk to hidden users). So the current project is to write some network packet handling software (in C or Basic) and have this running in the background on one of the MP/M users. This does a 'store and forward' for packets that are not for this board, and for packets that are for this board, it decodes the data bytes and sends them to user 0 as if that user had typed them locally. Ultimately, the aim is to log into a remote board and talk to it transparently, with packets going via multiple paths. This should work like the internet works, with the routing all happening behind the scenes.
Boards are available, $10 for 1, $15 for 2 and $20 for 3 (shipping cost included). These boards can also be used to run the new NASCOM code which should lead to Games. (and Games are what it is all about, much more interesting that boring old CP/M running spreadsheets and word processing and stock control and accounting programs!)
Yes, it is stable enough for me to put "MPM" in the autoexec file. (If you change your mind, download a new AUTOEXEC).
I'm now working on the networking code. Sbasic is a little slow for debugging so I've discovered an easier way is to use vb.net and write procedures using only sbasic keywords (ie no references to buttons, text boxes, radio boxes). Avoid += and a few other shortcuts. Keep the array processing in one procedure and put 'array to textbox' translation in another procedure. Then things can be copied over with the same keywords. sbasic is amazingly similar to vb.net. Network coding is 10% coding and 90% endless testing, trying to send combinations of bytes that 'break' the software.
That is a great link on hackaday. I'd be interested in the speed specs. Toby might like to comment on the single dram.
Dr_Acula said...
BTW pullmoll if you would like yourself as the screensaver, attached is a tiny text file. With a camera shot from a long way away so it is a bit blurry, suddenly the image comes to life. We could do the Zicog image and all sorts of pictures.
Bwahhh! I just now saw that. No, I'm fed with looking at myself in the mirror in the morning
@hairymnstr: I just actually looked into the "slow" SD SPI + XMM object and realized that it uses a completely different layout of command + parameters. Well, this is fine as long as you access only the PUB methods in Spin, but almost impossible to handle in PASM. Is there a chance to also unify the parameter passing and commands? I guess we could either use the binary commands and packed parameters for both objects, or go with the ASCII command and separate longs for XMM address and count + hub address as in the _warp object.
If you don't have time or interest to change this, then I'd try myself rather than cluttering up the io.spin objects with two kinds of XMM and SD-SPI addressing.
That was my plan, I've been a bit busy recently and at a Linux event this weekend so probably won't be able to look at it until next week. I think standardising on the _warp syntax will be better for everyone. The two objects are very closely based on the SPI module I adapted to make them, hence the differences. I didn't think there was too much hurry as the _warp variety seemed to be mainly working for people once you'd moved it to an early cog.
I also generally favour the ASCII commands, it saves having to have all the commands declared in CON in other modules that access the command buffer directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr said...
That was my plan, I've been a bit busy recently and at a Linux event this weekend so probably won't be able to look at it until next week. I think standardising on the _warp syntax will be better for everyone. The two objects are very closely based on the SPI module I adapted to make them, hence the differences. I didn't think there was too much hurry as the _warp variety seemed to be mainly working for people once you'd moved it to an early cog.
I also generally favour the ASCII commands, it saves having to have all the commands declared in CON in other modules that access the command buffer directly.
It isn't something we would need in a hurry, no, but for cases where the new code seems to fail it would be a nice-to-have. Toby is the first to report problems with the _warp object. I don't know how many people tested any of the projects containing the _warp code, though.
Here it is then. I've converted it to use the same letterbox format so it is now compatible at the PASM level. Seems to be working with the latest qz80 release running MPM okay. I've also updated the code to support HCSD cards so this is capable of FAT32/HCSD with Juergen's fatfs.spin. I've tidied the code up a bit while I was at it, still not very pretty, much shorter though.
So if you have issues with DracBlade_spi_warp.spin just replace it with DracBlade_spi.spin in fatfs.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr said...
Here it is then. I've converted it to use the same letterbox format so it is now compatible at the PASM level.
Thank you very much!
I'm still undecided whether I should copy the code for e.g. TriBlade_spi.spin and replace the DracBlade specific code, or join the TriBlade specific code into one spi/xmm object and conditionally compile one or the other. I think in the long term the latter would be easier to handle, since the memory access code won't change, but the spi/xmm code may see bugfixes or improvements.
FWIW I looked through the code and there seem to be a lot of leftover longs that aren't used. Since we're always tight on hub RAM, it would make sense to get rid of them.
I can see I really have some catching up to do. Been busy with other things.
I am wondering if there is any way to trick the TV into using color in code (like white on blue or something besides B&W) for the 1pinTV. I have NTSC 64*28 and PAL 60/64*32 running fine at 5MHz (no inverse).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The slower version is 522 longs currently (and as Pullmoll mentioned has potential for a good tidy up). The faster _warp version is currently 643 longs, and would be hard to shrink much without some serious re-coding.
I can clean out some of the SPIN methods too if we are agreed that they aren't needed e.g. the set LED on/off SPIN code isn't really needed as this can be done with a set high latch command.
I'll try and go through tidying the code in the next week.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Recently I saw a post (but I cannot find it) which was illuding to which VT100 codes are required for Wordstar to run. I have some space in my 1pinTV code so I was thinking about seeing if these would fit.
Can anyone point me in the right direction?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Recently I saw a post (but I cannot find it) which was illuding to which VT100 codes are required for Wordstar to run. I have some space in my 1pinTV code so I was thinking about seeing if these would fit.
Can anyone point me in the right direction?
I don't know the post, but I can tell which codes are used:
<esc>[noparse][[/noparse]{row};{column}H to position the cursor. row and column are 2 digit decimals in case of Wordstar.
<esc>[noparse][[/noparse]2J to clear the entire screen
<esc>[noparse][[/noparse]1M to delete the line at the cursor (scrolls up the lines below)
<esc>[noparse][[/noparse]1L to insert a line at the cursor (scrolls down the lines below)
<esc>[noparse][[/noparse]0m to reset attributes
<esc>[noparse][[/noparse]1m to set the high lite mode attribute
<esc>[noparse][[/noparse]7m to set the inverse mode attribute
<esc>[noparse][[/noparse]27m to reset the inverse mode attribute
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.
Comments
Yes, close, but not yet there.. MP/M hangs on the DracBlade after displaying the user segments :-(
It may be waiting for a status port. I'll add some debug code to io.spin to see if that's the case.
Edit: No, it's running away after enabling interrupts. I probably have one of the SIMH commands wrong: set interrupt address or set timer interval.
For the disk images: I think we should have one system disk including both, CP/M and MP/M, with MP/M startable as a command. You probably won't use it all the time, or not every user would use it all the time. For the other hard disks I would suggest to put e.g. your own MAC/BAS/C files on the 2nd drive, perhaps together with the compilers and Wordstar. 8MB is a lot of space for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/17/2010 2:45:14 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I tried several things and also found a couple of bugs, but it still isn't running. One major bug was that interrupts in qz80 would not exit a HALTed CPU. The status quo still is: mpm hangs after the hello message, but not always. Sometimes it shows the prompt and a BDOS error on a file $0$.SUP on console #0, $1$.SUP on console #1... Since it all works on SIMH, it still has to be a subtle bug on my side in either io or the Z80 emulation itself. When I traced the io activity, the last thing the code does is reset the hdsk (write 1 to port $fd) many times and then stops doing anything at all, as if it was running in a tight loop with interrupts disabled. Since some games on the TRS80 also don't work and seem to hang, e.g. Robert's Chopper, there definitely _is_ a bug lurking in qz80.
The bug that was in the previous core was some 8 or 16 bit register overflowing to 32 bits and afterwards causing loops to take forever. IIRC it was DJNZ, where B could underflow. This bug isn't in the new core, but it may be a similar kind of bug elsewhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/18/2010 9:58:14 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
All the code in Zicog etc treats the Low and Middle latches together, but the High latch is seperate as it is used a lot less often.
BTW pullmoll if you would like yourself as the screensaver, attached is a tiny text file. With a camera shot from a long way away so it is a bit blurry, suddenly the image comes to life. We could do the Zicog image and all sorts of pictures.
That picture was on my second propeller and was downloaded from the PC using xmodem, then transferred wirelessly to the second board and then the second board was told to TYPE it wirelessly. This all works well, but the system cannot handle multiple boards talking at once. I think that can only be done with packets, so the MP/M work is extremely exciting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/18/2010 1:19:22 PM GMT
It is in the ./lib directory in the qz80-0.9.12.zip archive.
If banking is enabled, I always set the high latch in read/write byte functions. Checking for a change there would be longer and slower than just setting it.
I'm taking a break now, as I ran out of ideas what to try to get this darn MP/M going.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
It is less simple than that. The default behaviour of the RAM code is to leave the high latch unaltered. I was suggestung that it could be re-coded to include the high latch to support banked ops.
However I was under the impression you were using a common area buffer, and switching to bank 0 first, that should work because the high address latch should be set to 0 in the I/O handler when you select bank 0. In which case the common area is directly addressable by the 16 bit address
Need to be careful about some of the parameters being passed as longs because most of them get truncated at various points.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
My files are now a few days old and you probably have changed the code since then. Any chance you could post the latest code - maybe someone will spot something?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The qZ80 thread has my latest files and the disk image I'm using.
@hairymnstr I overlooked that when you asked. I fixed it now by issuing a "H" command with the high bits of the address. This was a bug, but not _the_ bug that causes MP/M to hang.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
How does it work on MP/M with respect to the top address bits in a DMA request? I know there is a bank select I/O port so does the disk DMA respect this? Or does it provide a longer address to the hard disk controller port?
It's possible there is still a bug with the bank select wrapper in spin, I didn't have anything to test it with when Dr A spotted the first bug last week.
Thinking about it I don't know if an 'H' command will work, I really need to look at how your code works.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
The DMA request will have an address from the entire 512KB range. If the incoming DMA address is below the banked memory limit (currently $b000), the current bank base address is added. The 512 byte sector I/O is always going to a fixed buffer in hub RAM and from there to the external RAM (or from external RAM to there). I now have code in io.spin (function hdsk_setup_dma) that sets the address bits 16-18 using the "H" command first, then the "R" or "W" command is sent with the lower 16 bits of the address.
The code in qz80 deals with the high latch bits on its own. It just splits each address in three parts and sets the latches prior to any external memory access. There would possibly be room for improvement if I knew that an address change was only in the lower 8 bits. I have no idea for a quick test for this condition... xor new address with old address and see if any bits but $ff changed. I may give that a try. Three instructions could help avoiding ~15-20 instructions in about 90% of the memory accesses (assuming a sequentially incrementing PC).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/18/2010 8:07:15 PM GMT
pullmoll's complete rewrite of the code is now so much better that it is time to change the 'official' operating system from my code to pullmoll's code. See the first thread. I'm leaving my old code as it was in mid April, but since that date I've been using the pullmoll code. Rather than host his code (which is improving all the time) there is a link to the active 'qZ80' thread. Advantages are:
1) a complete rewrite of the system, most of it in assembly rather than spin
2) faster upload and download speeds - at least 4x faster for xmodem file transfers
3) neater code which is much easier to understand
4) a bigger drive - 32mb for drive A, but also the ability to support standard 8mb SIMH drivers for easy file transfer
5) code boots into CP/M, but you can run MP/M from the CP/M prompt which turns the dracblade into three computers, each with 64k of memory
6) Faster bootup
7) Full Z80 opcodes (the old code only ran 8080).
I'm currently working on networking using packets. There are several different ways to handle packets in the background - you can write drivers in pasm, or spin, or modify CP/M. The disadvantage of the first two is that there is no space left (!) and the disadvantage of changing CP/M as it is no longer SIMH compatable. The new pullmoll code enables MP/M users to talk to each other via virtual ports (you can even write a little 'terminal' program to talk to hidden users). So the current project is to write some network packet handling software (in C or Basic) and have this running in the background on one of the MP/M users. This does a 'store and forward' for packets that are not for this board, and for packets that are for this board, it decodes the data bytes and sends them to user 0 as if that user had typed them locally. Ultimately, the aim is to log into a remote board and talk to it transparently, with packets going via multiple paths. This should work like the internet works, with the routing all happening behind the scenes.
Boards are available, $10 for 1, $15 for 2 and $20 for 3 (shipping cost included). These boards can also be used to run the new NASCOM code which should lead to Games. (and Games are what it is all about, much more interesting that boring old CP/M running spreadsheets and word processing and stock control and accounting programs!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Dr_A: Did you notice that your site got a link off Hackaday yesterday hackaday.com/2010/04/27/emulating-a-z80-computer-with-an-avr-chip/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I'm now working on the networking code. Sbasic is a little slow for debugging so I've discovered an easier way is to use vb.net and write procedures using only sbasic keywords (ie no references to buttons, text boxes, radio boxes). Avoid += and a few other shortcuts. Keep the array processing in one procedure and put 'array to textbox' translation in another procedure. Then things can be copied over with the same keywords. sbasic is amazingly similar to vb.net. Network coding is 10% coding and 90% endless testing, trying to send combinations of bytes that 'break' the software.
That is a great link on hackaday. I'd be interested in the speed specs. Toby might like to comment on the single dram.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Me too!11!1! Wouldn't it be fun to emulate an ATmega88 to run their Z80 emulation? ... just kidding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Bwahhh! I just now saw that. No, I'm fed with looking at myself in the mirror in the morning
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
And you would probably make it run faster than the original too!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
If you don't have time or interest to change this, then I'd try myself rather than cluttering up the io.spin objects with two kinds of XMM and SD-SPI addressing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I also generally favour the ASCII commands, it saves having to have all the commands declared in CON in other modules that access the command buffer directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
It isn't something we would need in a hurry, no, but for cases where the new code seems to fail it would be a nice-to-have. Toby is the first to report problems with the _warp object. I don't know how many people tested any of the projects containing the _warp code, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
So if you have issues with DracBlade_spi_warp.spin just replace it with DracBlade_spi.spin in fatfs.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Thank you very much!
I'm still undecided whether I should copy the code for e.g. TriBlade_spi.spin and replace the DracBlade specific code, or join the TriBlade specific code into one spi/xmm object and conditionally compile one or the other. I think in the long term the latter would be easier to handle, since the memory access code won't change, but the spi/xmm code may see bugfixes or improvements.
FWIW I looked through the code and there seem to be a lot of leftover longs that aren't used. Since we're always tight on hub RAM, it would make sense to get rid of them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/5/2010 12:37:43 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I am wondering if there is any way to trick the TV into using color in code (like white on blue or something besides B&W) for the 1pinTV. I have NTSC 64*28 and PAL 60/64*32 running fine at 5MHz (no inverse).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I can clean out some of the SPIN methods too if we are agreed that they aren't needed e.g. the set LED on/off SPIN code isn't really needed as this can be done with a set high latch command.
I'll try and go through tidying the code in the next week.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Can anyone point me in the right direction?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I don't know the post, but I can tell which codes are used:
<esc>[noparse][[/noparse]{row};{column}H to position the cursor. row and column are 2 digit decimals in case of Wordstar.
<esc>[noparse][[/noparse]2J to clear the entire screen
<esc>[noparse][[/noparse]1M to delete the line at the cursor (scrolls up the lines below)
<esc>[noparse][[/noparse]1L to insert a line at the cursor (scrolls down the lines below)
<esc>[noparse][[/noparse]0m to reset attributes
<esc>[noparse][[/noparse]1m to set the high lite mode attribute
<esc>[noparse][[/noparse]7m to set the inverse mode attribute
<esc>[noparse][[/noparse]27m to reset the inverse mode attribute
With this subset, Wordstar should run.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller