Shop Learn
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 115 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1112113115117118160

Comments

  • HUBSET makes good sense to me. "The device" is actually a HUB operation.
  • jmg wrote: »
    cgracey wrote: »
    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...
  • TonyB_TonyB_ Posts: 1,763
    edited 2017-12-24 23:37
    cgracey wrote: »
    TonyB_, why can't you do any physical testing? Is it lack of an FPGA board, or some other reason?

    No FPGA board and far too late now, I can wait for the real thing.
    cgracey wrote: »
    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.
    cgracey wrote: »
    SCA/SCAS instead of SCLU/SCL?

    The signed version ending in S is good. What do C and A mean in this context?
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 13,627
    edited 2017-12-25 03:27
    Merry Christmas, Everyone!

    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'.
  • Cluso99Cluso99 Posts: 17,970
    Merry Christmas Chip and co.

    Please take some time off to spend with family over this special time of the year!
  • cgraceycgracey Posts: 13,627
    edited 2017-12-28 07:00
    Boy, this forum has been quiet.

    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.
  • octettaoctetta Posts: 114
    edited 2017-12-28 07:16
    I’m super excited to use a Prop2, Chip! Happy New Year!
  • evanhevanh Posts: 11,842
    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.
  • A Crazy Idea

    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
  • 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 :o)

    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.

  • David BetzDavid Betz Posts: 14,388
    edited 2017-12-28 11:52
    cgracey wrote: »
    Boy, this forum has been quiet.

    Is anyone still thinking about Prop2?
    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 hope everyone had a great Christmas.
    Same here!
  • Heater.Heater. Posts: 21,233
    thej,

    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.


  • Cluso99Cluso99 Posts: 17,970
    edited 2017-12-28 12:39
    cgracey wrote: »
    Boy, this forum has been quiet.

    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.
  • cgracey wrote: »
    Is anyone still thinking about Prop2?

    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...
    cgracey wrote: »
    ...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.

  • cgracey wrote: »
    Boy, this forum has been quiet.

    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?
  • David Betz wrote: »
    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.



  • David Betz wrote: »
    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.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-28 14:44
    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
    
    TX%20DATA_2017-12-29_00.38.46.png
  • 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. :-)
  • MJBMJB Posts: 1,235
    David Betz wrote: »
    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. :-)

    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 ;

  • 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_TonyB_ Posts: 1,763
    edited 2017-12-28 19:09
    cgracey wrote: »
    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:
    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        NIXINT3
    
    Proposed:
    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        NIXINT3
    

    More to come unless you want me to stop.
  • thejthej Posts: 232
    edited 2017-12-28 19:25
    Heater. wrote: »
    thej,
    Yes that is a crazy idea.
    I'm betting that the Lisa ROM code was written in 68000 assembler.

    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
  • jmgjmg Posts: 14,820
    thej wrote: »
    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 ?

    thej wrote: »
    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).

    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

  • cgraceycgracey Posts: 13,627
    TonyB_ wrote: »
    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:
    EEEE 1101011 CZL DDDDDDDDD 000011011        GETRND  {D}         {WC/WZ/WCZ}
    

    Fixed it. Thanks.
    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.

    Proposed:
    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        NIXINT3
    
    

    Interesting. What is your rationale for moving RFVAR?
    More to come unless you want me to stop.

    Keep thinking, please.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-28 22:32
    David Betz wrote: »
    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.

    dropbox folder link

  • David Betz wrote: »
    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.

    dropbox folder link
    TACOS looks better to me as well. Are you saying that V30a doesn't work with TAQOZ, only v30? I never even downloaded v30. I went right to v30a.

Sign In or Register to comment.