I just realized, while working on the Google doc, that CLKSET is going to need to change to HUBSET, because it now handles five different things:
1) It sets the clock mode, like it always has.
2) It write-protects/enables the last 16KB of hub RAM.
3) It sets the four digital filtering modes that the smart pins use.
4) It seeds the Xoroshiro128+ PRNG in the hub.
5) Hardware reset.
Because this is a whole device config, why not P2CFG, or even CONFIG, as there is just one of them, and clearly it applies to P2....
If the digital filtering is global on all pins, when will anyone set a value slower than the fastest filtering choice ?
Or just as aliases for each group, just as was done on P1...
Okay. I agree about AND/ANDN and TEST/TESTN. I also just realized that SETPIV/SETPIX should be ordered as such. I think your MODCZ proposal is half-way, only. Are there some D-only instructions elsewhere that we could exploit? There's got to be a better way, yet. And the SCL/SCLU situation is difficult. These fixes are purely cosmetic, but I agree.
AND/ANDN and TEST/TESTN:
Thanks for agreeing, Chip.
MODCZ:
RCZR & RCZL are the sole D-only {WC/WZ/WCZ} instructions that involve C & Z directly, hence my suggestion. I'll try to think of a better alternative, but there might not be one.
I just realized, while working on the Google doc, that CLKSET is going to need to change to HUBSET, because it now handles five different things:
1) It sets the clock mode, like it always has.
2) It write-protects/enables the last 16KB of hub RAM.
3) It sets the four digital filtering modes that the smart pins use.
4) It seeds the Xoroshiro128+ PRNG in the hub.
5) Hardware reset.
COGID follows immediately after CLKSET/HUBSET, then there is a gap before COGSTOP. Was a cog instruction deleted at some point? This is an anomaly I omitted to mention before.
I can look some more at the instruction set on the 26th. Merry Xmas everyone!
EDIT:
If CLKSET/HUBSET and COGID were moved up one position, MODCZ could have its own slot as a D/# instruction.
Is anyone still thinking about Prop2? I'm feeling especially exuberant about it right now. OnSemi is set to do a very thorough job of bringing it through to production and I feel like the design is nicely refined now.
I talked to Kye yesterday who's been using fancy ARM chips for his camera products. He said they're just impossible to control timing with via software and that it takes a day to write proper Verilog for a simple UART in an FPGA. I think the Prop2 is heading beautifully into the gap between ARMs and FPGAs, where we'll have a software mode of programming with the steady timing of hard logic. We're easy to accommodate on a PCB and easy to program. Our tool system should have only 1% of the internal complexity of either an ARM or FPGA development system. This is going to be nice, I think.
It's the summer hols down under. The 4 days of stats (xmas/newyear) means many take 3 to 4 weeks vacation and vanish to favourite camping spots.
I generally go visit the old haunts and catch up with siblings and a couple of old school friends. Currently staying at my brother's, and today helped with trimming a few branches from the end of a windbreak to get some firewood. Managed to break the top 3 wires of the cockie's fence! There's another trailer load in the trimmings so I think we're going back tomorrow.
Since the P2 is quickly reaching reality, I thought I would end the year with a Crazy Idea !
Some of you may have heard that the original source for the Lisa OS and all its applications have been recovered and all of it will be openly posted online.
The Lisa hardware had 16KB of ROM, 512MB of RAM and ran on a single 5MHz 68000.
Hmmm… some of that sounds familiar.
With source code available and plenty of OS reference guides available, a “work-a-like” of Lisa OS could be made to run on the resources available on the P2. I don’t think a “port” makes sense. Rather, adapt what is useful.
Obviously, Tachyon is in ROM. I could see Tachyon being used as the “core” of the “work-a-like” Lisa OS providing (in ROM) much of what the “core” of Lisa OS originally provided. Some things could be left out. Some things could be enhanced.
But why bother moving an old OS to the P2?
1. It has APPS (Lisa Office 7/7) !!! Source code available soon
2. It’s already been fully designed and tested. Plenty of documentation available too.
3. It fits the resources available on the P2. Tachyon could make it even more compact.
4. Provides a layer for a mixture of graphical apps for use in Education, Experimentation, Control Systems, Custom Applications, Touch screens, etc
Thank you, Chip, Christmas was great: received the Prop123-Board and got it running with the latest Prop2-Image.
Wow! The Prop2 definitively deserves a Book like „2001 Tips, Tricks & Tasks“.
As a newby in this community, please allow me to tell the insights I had related to this chip:
for every single asm-command I got the impression that someone had at least two or more special tasks to solve in mind. Tasks you would normaly solve with more commands (i.e. less efficiently) or by means if a higher level programming language. Thus I got the feeling that you are encouraged to use Asm when working with Prop2. Hence it would be a wonderful thing if the currently already great documentation could be supplemented with one or two example lines of code per asm command. Examples were the initial „Genius“ behind each specific command is made clear (sorry, I know it is easy to ask for, but huge loads of work to do so).
Another insight for me is based on my experience in automotive industry:
On a professional base I worked with other multicore chips and their IDEs for a while. The intention of especially one of the investigated chips was quite similar to what I experience with Prop chips:
having a world between classical uC’s and FPGAs, combinig the benefits from both sides (versatile + precise timing).
We tried to use them as a replacement for our Communication Gateways in our semiautonomously driving development vehicles. The current solution - based on standard uC‘s with dedicated communication blocks, programmed in C or CAPL - got to its limits due to increasing demands.
However, after some pretty expensive evaluation time - guess what - we decided to stay with the existing solutions. Instead we would simply buy much more expensive boxes with much more calculation power.
The reason for not switching to a „more progressive“ system was simple:
1. Development environment,
2. Abstraction Layers, and
3. Maintenance.
Development Environment: No one wanted to run another Eclipse(-like) Environment only for changing a couple of bits in a CAN message or to adapt a simple translation algorithm. Especially when sitting cramped in an overheated tiny box relying blindly on your tools. People like their simple robust editors with quick integrated debuggers. Download of a change? More than a couple of seconds is pure pain. Abstraction layer: People would want to keep at least one high level abstraction layer - best CAPL, second best plain C. A layer were they would not have to cope with the underlying concurrently working nuts and bolts. Callbacks and Events are well accepted friends on this level. Maintenance: For each layer there is an expert. Special concepts require special knowledge and more expertise. People simply would want to use (= understand) code bases from colleagues even when they are absent or absent minded. Becoming an expert off topic due to an upgraded box? ok, but only if there is enough time and benefits. Otherwise: „couldn‘t we stick to what we know already?“.
What is the mentioned insight related to Prop2?
Prop2 has the clear potential to cope successfully with all of the described topics!
Development environment: A simple PNut based environment with an integrated debugger syntax highlighting (configurable for different programming languages), terminal shell, simple file management would be stunning. Small & simple.
Abstraction layer: You made Prop2 the perfect base for higher level languages! Spin is great. I think even CAPL or a bytecode C could be implemented easily. Let’s see how I could be supportive in this case.
Maintenance: see Abstraction Layer )
As mentioned I know that I am a newby in this community. But I hope being able to provide some useful input. Prop2 is simply surprisingly great.
My wife gave me this for Christmas: https://www.critterandguitari.com/collections/instruments/products/organelle
It's actually quite cool but it has an ARM inside. I was wondering if it might be possible to implement a sound synthesis path inside of a P2 and use an ARM for the graphical programming language. As it is, the sound synthesis is done by the ARM in this device and it's only a single core processor.
I'm betting that the Lisa ROM code was written in 68000 assembler. Have the source available may not help creating a work a like much.
Thing to do is write a 68000 emulator for the P2 and just run the code.
When it came out my friend bought a Lisa. It cost nearly as much as my entire salary for the year!
It turned out to be terrible unreliable, Apple fixed and swapped it out three times then my friend insisted on getting his money back.
Which turned out to be lucky as the Lisa was a short lived product.
Is anyone still thinking about Prop2? I'm feeling especially exuberant about it right now. OnSemi is set to do a very thorough job of bringing it through to production and I feel like the design is nicely refined now.
I talked to Kye yesterday who's been using fancy ARM chips for his camera products. He said they're just impossible to control timing with via software and that it takes a day to write proper Verilog for a simple UART in an FPGA. I think the Prop2 is heading beautifully into the gap between ARMs and FPGAs, where we'll have a software mode of programming with the steady timing of hard logic. We're easy to accommodate on a PCB and easy to program. Our tool system should have only 1% of the internal complexity of either an ARM or FPGA development system. This is going to be nice, I think.
I hope everyone had a great Christmas.
As Evan said, it's the big holidays, and it's summer, and hot here just north of Sydney Oz. Lots of days in the mid to high 30's and a couple in the low 40's !
Our daughter and family have been holidaying here for the past 4 weeks. Just put them on the plane home to the UK tonight. They had snow at their home yesterday.
I keep looking at the code I posted for the USB receiver, but I cannot find a good instruction that will reduce the tight loop, and be generic as well. Best I have thought of is a pin pair read instruction of 2 adjacent pins and copying the pin states to the C and Z flags. If the PIN number is even, the lower pin goes into Z and upper pin to C. If the PIN number is odd, then copy to C and Z. If there were to be a [#]D operand then perhaps the pin pair states could be placed into b30 & b31 of D ???
I will keep trying as to be useful, the loop must be shortened so that at least we can insert the CRCBIT instruction.
BTW I have code working for SD booting. Need to add the find file with FAT32 in PASM so we can boot from MBR (if checksum is OK), else search for a FAT32 file name, and then load and boot from it. Then need to chat with Peter.
...I've been hammering out a new, minimalist design that should be along the lines of a Prop1 in cog complexity, with a few things taken away and a few things added...
...was interesting. But then people started putting in their 'feature' requests and the design started down the road to bloat and obesity. And, yet again, it all came crashing down and in an attempt to salvage something the number of COGs was slashed in half.
Is anyone still thinking about Prop2? I'm feeling especially exuberant about it right now. OnSemi is set to do a very thorough job of bringing it through to production and I feel like the design is nicely refined now.
I'm quietly optimizing/adding/trimming TAQOZ and adding hardware support features to it such as making it easy to operate the smartpins etc.
For instance if you want PWM then it is as simple as typing "34 PIN" to select the pin we want to use and then something like "1000 4000 1 PWM" to setup 25% PWM. The same goes for all the other DUTY/NCO and SERIAL modes etc that we can try out at present. Typing 32 PIN 1 MHZ will do what it says.
Likewise I can test serial transmission with a quick setup "20 M BAUD 8 BIT 35 PIN TXD" and then divert all output to that "port" with:
35 SERIAL 10 FOR PRINT" Hello World" CR NEXT
There's some special stuff I'm testing out with a compressed dictionary so that I can fit 6 character mixed names into a long including attributes and so a header record is a fixed 6 bytes for name, attributes, and code pointer. Longer names could be used but only up to 6 characters (i.e. RCSLOW) can be stored and listed with WORDS and besides most words fit into that very nicely. A lot of those traditional names like VARIABLE and CONSTANT aren't used in Tachyon anyway as I find it easier to use operator symbols or words such as byte/word/long/timer etc to describe what kind of variable storage I'm after anyway.
However to make this a little "friendlier" to test out I am building all the high level EXTEND and FAT32 operations back into the "spin2" file so that rather than being metacompiled, it can be simply be compiled and run with one keystroke from PNut. A small routine will convert the dictionary at startup. Then there's the documentation.....
Look forward to a dedicated TAQOZ thread shortly where we can discuss features that we would like and that would prove useful as firmware.
Is there a build of TAQOZ that we can play with? Any chance Chip could make an FPGA image with TAQOZ in ROM?
There is the "stripped down" version for ROM that I am building on and testing that you can load in and start using. It still needs FAT32 added back to it and there will be naming and dictionary changes but you can start playing with I/O and Smartpins easily. I'm testing on a CVA9.
Use this dropbox link or grab the file as it is right now (without all the extras).
I probably could do a version that ran on a small DE0 FPGA but it probably wouldn't be worth it much since I'm testing for final ROM. In doing so the serial receive would have to be run under interrupts and a smartpin maybe, but it is do'able.
Is there a build of TAQOZ that we can play with? Any chance Chip could make an FPGA image with TAQOZ in ROM?
There is the "stripped down" version for ROM that I am building on and testing that you can load in and start using. It still needs FAT32 added back to it and there will be naming and dictionary changes but you can start playing with I/O and Smartpins easily. I'm testing on a CVA9.
Use this dropbox link or grab the file as it is right now (without all the extras).
I probably could do a version that ran on a small DE0 FPGA but it probably wouldn't be worth it much since I'm testing for final ROM. In doing so the serial receive would have to be run under interrupts and a smartpin maybe, but it is do'able.
Thanks! I have the Prop123A9 board so I don't need an DE0 version.
Scrub that zip file, it was in the middle of a change, but I will post a dropbox link to a stable tested version or use the link supplied as it has just been updated. I need to provide two links, one to the current testing file, and one to the stable release.
Scrub that zip file, it was in the middle of a change, but I will post a dropbox link to a stable tested version or use the link supplied as it has just been updated. I need to provide two links, one to the current testing file, and one to the stable release.
No problem. I'll wait for you to say there is a stable version available. Thanks.
It is mostly stable and working just as it is now so in fact I wouldn't worry about waiting, just test it and it should be fine. If not, try it again later or just keep the file synched. I just added some asynch stuff to it and the actual (incomplete) syntax is like it is show here:
TAQOZ# 34 PIN 8 BIT 115200 TXD ok
TAQOZ# $55 WYPIN ok
TAQOZ# $41 WYPIN ok
TAQOZ# @NAMES 4 TXDAT ok
TAQOZ# ok
TAQOZ# @NAMES $80 TXDAT ok
I can see it would be useful to have it change the standard EMIT transmit to redirect output since that uses a smartpin too.
BTW, here's a capture of a 20M baud transmission with 10-bit data (as a test)
TAQOZ# 34 PIN 10 BIT 20 M TXD ok
TAQOZ# @NAMES $10 DUMP
00.D000: 03 44 55 50 80 6B 00 04 32 44 55 50 80 6D 00 04 .DUP.k..2DUP.m.. ok
TAQOZ# @NAMES $10 TXDAT ok
I just tried loading the version of TAQOZ off of DropBox and I got an error "expecting a constant, unary operator or '('". Do I need to use something other than PNut to load this? I'm using the tools that came with the 30a release.
TonyB_, the 4-bit code for COGID is %0010. It uses 2 or 3 operands, though, so it's not a pure D/# instruction. That's why you see a gap.
SCA/SCAS means 'scale'.
How about splitting COGID into separate COGID and COGSTAT? Then there'd be no gaps.
I prefer SCL/SCLS to SCA/SCAS. There are other mnemonics with no vowels. The 'L' in SCL/SCLS is in same position as MUL/MULS and is a hint that multiplication is involved. Also I find it easiest to pronounce SCL and SCLS as "SCuL" and "SCuLS".
I've been studying the instruction set very studiously and here are a few more suggestions.
1. GETRND
Should be a CZL instruction in the instructions.txt file to match spreadsheet:
2. POLLxxx, WAITxxx, ALLOWI/STALLI, TRGINTx, NIXINTx
These are D# only instructions but the CZL opcode bits [20:18] are CZ0 or 000, indicating registered D only. Shouldn't these be CZ1 or 001?
3. Simplified encoding/decoding
Self-explanatory, I hope.
Some of you may have heard that the original source for the Lisa OS and all its applications have been recovered and all of it will be openly posted online.
I can understand the Computer History Nerds getting excited about this, but the wider market ?
The Lisa hardware had 16KB of ROM, 512MB of RAM and ran on a single 5MHz 68000.
Hmmm… some of that sounds familiar.
With source code available and plenty of OS reference guides available, a “work-a-like” of Lisa OS could be made to run on the resources available on the P2. I don’t think a “port” makes sense. Rather, adapt what is useful.
Easily said, but you missed the bits implicit in Lisa, but NOT 'available on the P2' like keyboard/mouse/display.
It also sounds like Lisa had a great many bugs/gotchas, which is part of why it never took off.
You could run a 68000 emulator, and start booting Lisa, but you need to duplicate the hardware exactly, if you want to see a working system.
Once you start trying to slice and dice the software/hardware, you are probably better putting the effort elsewhere...
See the Embedded Project Oberon info I added to another thread.
Neatly avoids the keyboard/mouse/display conundrum... - and will fit comfortably in a P2 (and fits in FPGA emulation memory too).
How about splitting COGID into separate COGID and COGSTAT? Then there'd be no gaps.
They are the same hub instruction code %0010. The differentiation only comes from WC. There's no means (without big reorganization) to break them apart. I think they are fine.
I prefer SCL/SCLS to SCA/SCAS. There are other mnemonics with no vowels. The 'L' in SCL/SCLS is in same position as MUL/MULS and is a hint that multiplication is involved. Also I find it easiest to pronounce SCL and SCLS as "SCuL" and "SCuLS".
I kind of like SCA/SCAS, since I changed them. They cannot be confused with the old names (SCL switching meaning).
I've been studying the instruction set very studiously and here are a few more suggestions.
1. GETRND
Should be a CZL instruction in the instructions.txt file to match spreadsheet:
2. POLLxxx, WAITxxx, ALLOWI/STALLI, TRGINTx, NIXINTx
These are D# only instructions but the CZL opcode bits [20:18] are CZ0 or 000, indicating registered D only. Shouldn't these be CZ1 or 001?
No. These cause harmless register reads. To set that L bit to '1' would trigger AUGD, which is not wanted. It's the actual instruction bits that are used, anyway, not D.
3. Simplified encoding/decoding
Self-explanatory, I hope.
I just grabbed the copy of TAQOZ from DropBox. I'll try that version. By the way, are you committed to that name? It's hard to type. :-)
I double checked that taqoz-rom.spin2 from the Dropbox this morning on another PC and it is fine. Make sure you use PNut_v30.exe from the V30 folder.
I must admit that I find the name TAQOZ a little awkward as I much prefer just the plain simple TACOS rather than the modern garnished version.
I just grabbed the copy of TAQOZ from DropBox. I'll try that version. By the way, are you committed to that name? It's hard to type. :-)
I double checked that taqoz-rom.spin2 from the Dropbox this morning on another PC and it is fine. Make sure you use PNut_v30.exe from the V30 folder.
I must admit that I find the name TAQOZ a little awkward as I much prefer just the plain simple TACOS rather than the modern garnished version.
Comments
Or just as aliases for each group, just as was done on P1...
No FPGA board and far too late now, I can wait for the real thing.
AND/ANDN and TEST/TESTN:
Thanks for agreeing, Chip.
MODCZ:
RCZR & RCZL are the sole D-only {WC/WZ/WCZ} instructions that involve C & Z directly, hence my suggestion. I'll try to think of a better alternative, but there might not be one.
The signed version ending in S is good. What do C and A mean in this context?
COGID follows immediately after CLKSET/HUBSET, then there is a gap before COGSTOP. Was a cog instruction deleted at some point? This is an anomaly I omitted to mention before.
I can look some more at the instruction set on the 26th. Merry Xmas everyone!
EDIT:
If CLKSET/HUBSET and COGID were moved up one position, MODCZ could have its own slot as a D/# instruction.
TonyB_, the 4-bit code for COGID is %0010. It uses 2 or 3 operands, though, so it's not a pure D/# instruction. That's why you see a gap.
SCA/SCAS means 'scale'.
Please take some time off to spend with family over this special time of the year!
Is anyone still thinking about Prop2? I'm feeling especially exuberant about it right now. OnSemi is set to do a very thorough job of bringing it through to production and I feel like the design is nicely refined now.
I talked to Kye yesterday who's been using fancy ARM chips for his camera products. He said they're just impossible to control timing with via software and that it takes a day to write proper Verilog for a simple UART in an FPGA. I think the Prop2 is heading beautifully into the gap between ARMs and FPGAs, where we'll have a software mode of programming with the steady timing of hard logic. We're easy to accommodate on a PCB and easy to program. Our tool system should have only 1% of the internal complexity of either an ARM or FPGA development system. This is going to be nice, I think.
I hope everyone had a great Christmas.
I generally go visit the old haunts and catch up with siblings and a couple of old school friends. Currently staying at my brother's, and today helped with trimming a few branches from the end of a windbreak to get some firewood. Managed to break the top 3 wires of the cockie's fence! There's another trailer load in the trimmings so I think we're going back tomorrow.
Since the P2 is quickly reaching reality, I thought I would end the year with a Crazy Idea !
Some of you may have heard that the original source for the Lisa OS and all its applications have been recovered and all of it will be openly posted online.
The Lisa hardware had 16KB of ROM, 512MB of RAM and ran on a single 5MHz 68000.
Hmmm… some of that sounds familiar.
With source code available and plenty of OS reference guides available, a “work-a-like” of Lisa OS could be made to run on the resources available on the P2. I don’t think a “port” makes sense. Rather, adapt what is useful.
Obviously, Tachyon is in ROM. I could see Tachyon being used as the “core” of the “work-a-like” Lisa OS providing (in ROM) much of what the “core” of Lisa OS originally provided. Some things could be left out. Some things could be enhanced.
But why bother moving an old OS to the P2?
1. It has APPS (Lisa Office 7/7) !!! Source code available soon
2. It’s already been fully designed and tested. Plenty of documentation available too.
3. It fits the resources available on the P2. Tachyon could make it even more compact.
4. Provides a layer for a mixture of graphical apps for use in Education, Experimentation, Control Systems, Custom Applications, Touch screens, etc
Here are a few links to check it out:
The original Announcement
https://mobile.twitter.com/6502lane/status/944965691710496769
Lisa OS Demo
Lisa Documentation
http://lisaem.sunder.net/books.html
Well, I said it was crazy!
But it isn’t like the idea of implementing old OSes on the Propeller is new!
J
Wow! The Prop2 definitively deserves a Book like „2001 Tips, Tricks & Tasks“.
As a newby in this community, please allow me to tell the insights I had related to this chip:
for every single asm-command I got the impression that someone had at least two or more special tasks to solve in mind. Tasks you would normaly solve with more commands (i.e. less efficiently) or by means if a higher level programming language. Thus I got the feeling that you are encouraged to use Asm when working with Prop2. Hence it would be a wonderful thing if the currently already great documentation could be supplemented with one or two example lines of code per asm command. Examples were the initial „Genius“ behind each specific command is made clear (sorry, I know it is easy to ask for, but huge loads of work to do so).
Another insight for me is based on my experience in automotive industry:
On a professional base I worked with other multicore chips and their IDEs for a while. The intention of especially one of the investigated chips was quite similar to what I experience with Prop chips:
having a world between classical uC’s and FPGAs, combinig the benefits from both sides (versatile + precise timing).
We tried to use them as a replacement for our Communication Gateways in our semiautonomously driving development vehicles. The current solution - based on standard uC‘s with dedicated communication blocks, programmed in C or CAPL - got to its limits due to increasing demands.
However, after some pretty expensive evaluation time - guess what - we decided to stay with the existing solutions. Instead we would simply buy much more expensive boxes with much more calculation power.
The reason for not switching to a „more progressive“ system was simple:
1. Development environment,
2. Abstraction Layers, and
3. Maintenance.
Development Environment: No one wanted to run another Eclipse(-like) Environment only for changing a couple of bits in a CAN message or to adapt a simple translation algorithm. Especially when sitting cramped in an overheated tiny box relying blindly on your tools. People like their simple robust editors with quick integrated debuggers. Download of a change? More than a couple of seconds is pure pain.
Abstraction layer: People would want to keep at least one high level abstraction layer - best CAPL, second best plain C. A layer were they would not have to cope with the underlying concurrently working nuts and bolts. Callbacks and Events are well accepted friends on this level.
Maintenance: For each layer there is an expert. Special concepts require special knowledge and more expertise. People simply would want to use (= understand) code bases from colleagues even when they are absent or absent minded. Becoming an expert off topic due to an upgraded box? ok, but only if there is enough time and benefits. Otherwise: „couldn‘t we stick to what we know already?“.
What is the mentioned insight related to Prop2?
Prop2 has the clear potential to cope successfully with all of the described topics!
Development environment: A simple PNut based environment with an integrated debugger syntax highlighting (configurable for different programming languages), terminal shell, simple file management would be stunning. Small & simple.
Abstraction layer: You made Prop2 the perfect base for higher level languages! Spin is great. I think even CAPL or a bytecode C could be implemented easily. Let’s see how I could be supportive in this case.
Maintenance: see Abstraction Layer
As mentioned I know that I am a newby in this community. But I hope being able to provide some useful input. Prop2 is simply surprisingly great.
It's actually quite cool but it has an ARM inside. I was wondering if it might be possible to implement a sound synthesis path inside of a P2 and use an ARM for the graphical programming language. As it is, the sound synthesis is done by the ARM in this device and it's only a single core processor. Same here!
Yes that is a crazy idea.
I'm betting that the Lisa ROM code was written in 68000 assembler. Have the source available may not help creating a work a like much.
Thing to do is write a 68000 emulator for the P2 and just run the code.
When it came out my friend bought a Lisa. It cost nearly as much as my entire salary for the year!
It turned out to be terrible unreliable, Apple fixed and swapped it out three times then my friend insisted on getting his money back.
Which turned out to be lucky as the Lisa was a short lived product.
As Evan said, it's the big holidays, and it's summer, and hot here just north of Sydney Oz. Lots of days in the mid to high 30's and a couple in the low 40's !
Our daughter and family have been holidaying here for the past 4 weeks. Just put them on the plane home to the UK tonight. They had snow at their home yesterday.
I keep looking at the code I posted for the USB receiver, but I cannot find a good instruction that will reduce the tight loop, and be generic as well. Best I have thought of is a pin pair read instruction of 2 adjacent pins and copying the pin states to the C and Z flags. If the PIN number is even, the lower pin goes into Z and upper pin to C. If the PIN number is odd, then copy to C and Z. If there were to be a [#]D operand then perhaps the pin pair states could be placed into b30 & b31 of D ???
I will keep trying as to be useful, the loop must be shortened so that at least we can insert the CRCBIT instruction.
BTW I have code working for SD booting. Need to add the find file with FAT32 in PASM so we can boot from MBR (if checksum is OK), else search for a FAT32 file name, and then load and boot from it. Then need to chat with Peter.
Not really. I pop in here from time to time to see what's happening but apart from that I have little interest in the direction the P2 is going.
The original idea...
...was interesting. But then people started putting in their 'feature' requests and the design started down the road to bloat and obesity. And, yet again, it all came crashing down and in an attempt to salvage something the number of COGs was slashed in half.
I'm quietly optimizing/adding/trimming TAQOZ and adding hardware support features to it such as making it easy to operate the smartpins etc.
For instance if you want PWM then it is as simple as typing "34 PIN" to select the pin we want to use and then something like "1000 4000 1 PWM" to setup 25% PWM. The same goes for all the other DUTY/NCO and SERIAL modes etc that we can try out at present. Typing 32 PIN 1 MHZ will do what it says.
Likewise I can test serial transmission with a quick setup "20 M BAUD 8 BIT 35 PIN TXD" and then divert all output to that "port" with:
35 SERIAL 10 FOR PRINT" Hello World" CR NEXT
There's some special stuff I'm testing out with a compressed dictionary so that I can fit 6 character mixed names into a long including attributes and so a header record is a fixed 6 bytes for name, attributes, and code pointer. Longer names could be used but only up to 6 characters (i.e. RCSLOW) can be stored and listed with WORDS and besides most words fit into that very nicely. A lot of those traditional names like VARIABLE and CONSTANT aren't used in Tachyon anyway as I find it easier to use operator symbols or words such as byte/word/long/timer etc to describe what kind of variable storage I'm after anyway.
However to make this a little "friendlier" to test out I am building all the high level EXTEND and FAT32 operations back into the "spin2" file so that rather than being metacompiled, it can be simply be compiled and run with one keystroke from PNut. A small routine will convert the dictionary at startup. Then there's the documentation.....
Look forward to a dedicated TAQOZ thread shortly where we can discuss features that we would like and that would prove useful as firmware.
There is the "stripped down" version for ROM that I am building on and testing that you can load in and start using. It still needs FAT32 added back to it and there will be naming and dictionary changes but you can start playing with I/O and Smartpins easily. I'm testing on a CVA9.
Use this dropbox link or grab the file as it is right now (without all the extras).
I probably could do a version that ran on a small DE0 FPGA but it probably wouldn't be worth it much since I'm testing for final ROM. In doing so the serial receive would have to be run under interrupts and a smartpin maybe, but it is do'able.
BTW, here's a capture of a 20M baud transmission with 10-bit data (as a test)
while you are right - hard to type - just tried it ;-)
I don't think you will need to type it very often.
And you can sure define a shortcut.
pub tq TAQOZ ;
How about splitting COGID into separate COGID and COGSTAT? Then there'd be no gaps.
I prefer SCL/SCLS to SCA/SCAS. There are other mnemonics with no vowels. The 'L' in SCL/SCLS is in same position as MUL/MULS and is a hint that multiplication is involved. Also I find it easiest to pronounce SCL and SCLS as "SCuL" and "SCuLS".
I've been studying the instruction set very studiously and here are a few more suggestions.
1. GETRND
Should be a CZL instruction in the instructions.txt file to match spreadsheet:
EEEE 1101011 CZL DDDDDDDDD 000011011 GETRND {D} {WC/WZ/WCZ}2. POLLxxx, WAITxxx, ALLOWI/STALLI, TRGINTx, NIXINTx
These are D# only instructions but the CZL opcode bits [20:18] are CZ0 or 000, indicating registered D only. Shouldn't these be CZ1 or 001?
3. Simplified encoding/decoding
Self-explanatory, I hope.
Currently:
EEEE 1101011 CZ0 DDDDDDDDD 000010000 RFBYTE D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010001 RFWORD D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010010 RFLONG D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010011 RFVAR D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010100 RFVARS D {WC/WZ/WCZ} EEEE 1101011 00L DDDDDDDDD 000010101 WFBYTE D/# EEEE 1101011 00L DDDDDDDDD 000010110 WFWORD D/# EEEE 1101011 00L DDDDDDDDD 000010111 WFLONG D/# EEEE 1101011 000 000100000 000100100 ALLOWI EEEE 1101011 000 000100001 000100100 STALLI EEEE 1101011 000 000100010 000100100 TRGINT1 EEEE 1101011 000 000100011 000100100 TRGINT2 EEEE 1101011 000 000100100 000100100 TRGINT3 EEEE 1101011 000 000100101 000100100 NIXINT1 EEEE 1101011 000 000100110 000100100 NIXINT2 EEEE 1101011 000 000100111 000100100 NIXINT3Proposed:EEEE 1101011 CZ0 DDDDDDDDD 000010000 * RFVAR D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010001 * RFBYTE D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010010 * RFWORD D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010011 * RFLONG D {WC/WZ/WCZ} EEEE 1101011 CZ0 DDDDDDDDD 000010100 RFVARS D {WC/WZ/WCZ} EEEE 1101011 00L DDDDDDDDD 000010101 WFBYTE D/# EEEE 1101011 00L DDDDDDDDD 000010110 WFWORD D/# EEEE 1101011 00L DDDDDDDDD 000010111 WFLONG D/# EEEE 1101011 001 000100000 000100100 ALLOWI EEEE 1101011 001 000100001 000100100 * TRGINT1 EEEE 1101011 001 000100010 000100100 * TRGINT2 EEEE 1101011 001 000100011 000100100 * TRGINT3 EEEE 1101011 001 000100100 000100100 * STALLI EEEE 1101011 001 000100101 000100100 NIXINT1 EEEE 1101011 001 000100110 000100100 NIXINT2 EEEE 1101011 001 000100111 000100100 NIXINT3More to come unless you want me to stop.
Turns out that there is almost no OS code in the ROM! Only POST and boot code (which can be completely replaced with Tachyon code).
J
I can understand the Computer History Nerds getting excited about this, but the wider market ?
Easily said, but you missed the bits implicit in Lisa, but NOT 'available on the P2' like keyboard/mouse/display.
It also sounds like Lisa had a great many bugs/gotchas, which is part of why it never took off.
You could run a 68000 emulator, and start booting Lisa, but you need to duplicate the hardware exactly, if you want to see a working system.
Once you start trying to slice and dice the software/hardware, you are probably better putting the effort elsewhere...
See the Embedded Project Oberon info I added to another thread.
Neatly avoids the keyboard/mouse/display conundrum... - and will fit comfortably in a P2 (and fits in FPGA emulation memory too).
I also see ultibo is ticking over nicely, - bare metal pi, that started with no graphics, but recently they added 'full support for the VideoCore IV GPU in all models of the Raspberry Pi.'
https://ultibo.org/news/
https://ultibo.org/make/
https://ultibo.org/wiki/Main_Page
They are the same hub instruction code %0010. The differentiation only comes from WC. There's no means (without big reorganization) to break them apart. I think they are fine.
I kind of like SCA/SCAS, since I changed them. They cannot be confused with the old names (SCL switching meaning).
Fixed it. Thanks.
No. These cause harmless register reads. To set that L bit to '1' would trigger AUGD, which is not wanted. It's the actual instruction bits that are used, anyway, not D.
Interesting. What is your rationale for moving RFVAR?
Keep thinking, please.
I double checked that taqoz-rom.spin2 from the Dropbox this morning on another PC and it is fine. Make sure you use PNut_v30.exe from the V30 folder.
I must admit that I find the name TAQOZ a little awkward as I much prefer just the plain simple TACOS rather than the modern garnished version.
dropbox folder link