Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/17/21 in all areas

  1. ux16vt (Unicode Terminal for X16) View File ux16vt is a UTF-8 and somewhat ANSI compatible terminal emulator for Commander X16. Currently the only useable "serial" port uses LOAD & SAVE to communicate between the X16 emulator and a glue process that moves data in and out of a POSIX pseudo-terminal. In the emulator LOAD "UX16VT.PRG" & RUN. On the host, compile and run emulator_glue.c. ## Unicode Support ux16vt supports up to 4096 1-bit 8x16 pixel glyphs selected at compile time from the Unicode Basic Multilingual Plane. Unknown characters are displayed as blank. Currently 672 of these glyphs are used covering 862 different code points. The following blocks are mapped: - Basic Latin (00-7f) - Latin-1 Supplement (80-ff) - Greek & Coptic (370-3ff) - Cyrillic (400-4ff) - Box Drawing (2500-257f) - Block Elements (2580-259f) Limitations: - no support for right-to-left text - characters are represented internally as 16-bit values, making any characters outside the basic multilingual plane complete inaccessible - completely mono-spaced text. full-width glyphs are not available ## ANSI Support Only sequences beginning with ^[[ are supported (Control Sequence Introducer). Only numeric parameters are read. A control sequence with more than four parameters will cause an unchecked buffer overflow. The following functions are available: A CUU Cursor Up B CUD Cursor Down C CUF Cursor Forward D CUB Cursor Back E CNL Cursor Next Line F CPL Cursor Previous Line G CHA Cursor Character Absolute [column] H CUP Cursor Position J ED Erase in Display K EL Erase in Line S SU Scroll Up T SD Scroll Down d VPA Vertical Position Absolute [row] f HVP Horizontal Vertical Position m SGR Select Graphics Rendition The only available modes for SGR are 31 to set foreground colour to red and 30,32-39 set the foreground colour to black. Submitter lamb-duh Submitted 01/15/21 Category Productivity Apps  
    3 points
  2. I wrote a series of blog posts/articles on Commander X16 architecture and coding. I have started with focus on beginners and then slowly moved to more advanced topics and techniques. First I tackle smaller chunks and use simple examples to show the topic in practice. After enough new knowledge is covered I write a complete game to utilize several of the techniques to illustrate how it all comes together so each new complete project is more complex than the one before. I do cover only Commander X16 specific so I recommend reading Commodore C64 BASIC tutorials and guides. Please note that the games and most examples are written with a goal to be as clearly readable and understandable so there is very little source code optimizations. Snake Game This game is written in very clean BASIC with very little trickery so not much special Commander X16 knowledge is required. We do VPOKE directly into video memory so only understanding of fundamentals is required. Recommended reading VERA Overview Topics Covered in Game Analyzing the game itself is a great way to learn basics like: How to structure source code (outer loops, game loop) What is Game loop Use of Data structure like multiple Arrays How to read Joystick, Keyboard How to use VPOKE to “talk to” VERA Video RAM organization and using colors Writing to certain location on the screen Using PETSCII control characters to display messages and title screen GOTO Crazy Snake Tutorial GOTO Download Tetris Clone This game introduces some more advanced features of Commander X16 and we have to take a bit more care of how to use data structures and optimize some parts of the game to make it playable. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Colors and Palettes Topics Covered in Game Tetris clone requires us to improve on pretty much all parts of the snake game structure: We have additional loops outside and inside game loop Advanced game collisions based on screen state Pre-calculate relative positions of four segments of each tetromino Customize color palette Customize tiles (characters) Speed increase per level Adding sound to the game GOTO Crazy Tetrominoes Tutorial GOTO Download Boulder Dash style game With this game we are using most of the Commander X16 hardware capabilities and we are getting close to squeezing most out of it for BASIC games. We have to pay close attention to timings, synchronizing scrolling and animation, take care of different types of collisions, etc. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Sprites in Basic I - Setup Sprites in Basic II - Animation Scrolling and Layers in BASIC Colors and Palettes Simplest Sound Effects Library for BASIC Font Library for Commander X16 Topics Covered in Game This game is taking advantage of hardware features of Commander X16 to the level it almost looks like 16bit game or something written in Assembly for 8 bit computer like: Two phase approach to development Full color mode Full screen scrolling Two layer graphics Scrollable playfield Static HUD Animated full color sprites 256 color title screen in graphics mode Advanced physics and game mechanics Loading assets to memory from binary files for: Tileset Sprite Sheet Fonts Sound effects library Title screen GOTO Crazy Boulders Tutorial GOTO Download Lunar Lander style game With this game we are using most of the Commander X16 hardware capabilities and we are getting close to squeezing most out of it for BASIC games. Due to pixel perfect collision detection requirement we had to use small machine code routine. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Sprites in Basic I - Setup Sprites in Basic II - Animation Scrolling and Layers in BASIC Colors and Palettes Music Player Library for BASIC Programs Font Library for Commander X16 Topics Covered in Game This game is taking advantage of hardware features of Commander X16 to the level it almost looks like 16bit game or something written in Assembly for 8 bit computer like: Integration of machine code, Assembly source code is available Full color mode 256 Color Title screen Two layer graphics Bitmap background Tile based HUD Full color sprites Advanced physics and game mechanics Loading assets to memory from binary files for: Tileset - fonts Sprite Sheet Background music Title screen GOTO Crazy Lander Tutorial GOTO Download
    2 points
  3. KickC is a C-compiler for 6502-based platforms creating optimized and readable assembler code. The newest version 0.8.5 adds support for developing for the Commander X16 platform. The compiler includes header-files and linker-files for the chipset of Commander X16. Also included is veralib.h and a conio.h implementation contributed by @svenvandevelde. It also includes some example-programs that work in the emulator (and hopefully on the real platform). Below you can see a bit of the included sprites.c example program. You can get it here: https://gitlab.com/camelot/kickc/-/releases PS. I am the author of KickC.
    2 points
  4. Yes, running the User port lines out to a breadboard to talk to microcontrollers or microcontroller petipherals. Bringing up a tethered Forth in a small microcontroller is one example. And before people jump in and say, "no, the way you do it is this way with these software tools", I'm going to point back to where I said, " not everyone will want to" ... a lot of people are happy with the tottering piles of tools on development environments that run on dlls from other development environments talking to proprietary drivers, but those who are not thrilled by that approach exist. Indeed, it's almost guaranteed that if there is a mainstream approach, there will be pockets of people who are not enamored with the mainstream.
    2 points
  5. I added a bunch of videos to the playlist already, and just added this one tonight. I think the topic covered might interest a few people: Reverse-Compiling PETDRAW.
    2 points
  6. No, VPOKE is not meant to take advantage of auto increment. VPOKE more fully takes advantage of direct access, but for speed once you set up auto increment you would just keep poking additional values. So if you are sending a sequence you would enable auto increment then VPOKE the first byte in the sequence and POKE the rest. Sent from my iPhone using Tapatalk
    2 points
  7. It's very straight forward, but I'm going to do a quick write up on it today or tomorrow. The relevant 6502 code is in src/emu_serial.s and the host-side code is in emulator_glue.c, if you want to see what it's doing in the meantime.
    2 points
  8. Version 0.5

    478 downloads

    A game where you have to visit all fields in a maze with your "block". For the latest version and to see the source, go to https://github.com/JimmyDansbo/cx16-maze
    1 point
  9. Version 1.2.1

    865 downloads

    This is a Breakout/Blockout/Arkanoid inspired game. . It is my very first try on the X16. You have to use a mouse or a joystick (cursor keys + enter on the emulator) It's only tested it on the emulator (R37, R38), so if anyone of the few with real hardware can give it a go, I'm eager to know the result. Available power ups (no keycodes, you have to catch the dropping badges): [L]: adds one live to player [M]: paddle is magnetic for 30 seconds. Can only hold one ball at a time. [C]: twin laser cannon for 15 seconds, 16 rounds in a row (if you are quick). [D]: Duplicates ball, so now you can have fun with 2... Keyboard commands: 's': sound on/off. 'p': pause game 'q': quit game. How to use with the local emulator: Unpack ZIP file into the same directory as the emulator. Start the emulator, then enter LOAD"BRIXX.PRG" RUN Or use the "Try now" button. Let me know what you think...
    1 point
  10. X16 Edit - a text editor View File X16 Edit is a text editor for the Commander X16 platform. Design goals: Use plain text files Store text buffer in banked RAM (512KB to 2 MB) Handle large texts efficiently Simple modeless user interface inspired by GNU Nano Implement basic editing functions well - refrain from making the program too feature-rich Support both ISO and PETSCII modes Tested with emulator version r38. Run with the following command: x16emu -sdcard sdcard.img -prg X16EDIT-x.x.x.PRG -run where x.x.x is the program version. You can also run the program with the "Try it now" button. There is, however, no attached disk in the online emulator, and consequently you cannot save or open files. Also, some of the Ctrl+key sequences are not working in the online emulator. To fully test the program you still need to download and run it locally. Please read the attached file romnotes.pdf if you want to try the ROM version. Source files available at https://github.com/stefan-b-jakobsson/x16-edit Released under GNU General Public License v 3 or later. manual.pdf romnotes.pdf Submitter Stefan Submitted 08/29/20 Category Productivity Apps  
    1 point
  11. If you've ever played 7 Cities of Gold, you remember that the map felt HUGE. It seemed to take forever, exploring an unknown continent, wondering if your men were going to starve. Rejoicing when you finally rounded the continental cape and began sailing north up the western coast. I took a glance at the map today, and it seems that it's not as memory intensive as it looks. I suspect this map renders each piece of topographic data, except for the rivers. The continental mass in this example is something on the order of 40 pixels wide, maybe 80 pixels tall, and only four colors. If that represents a third of the total height (240 pixels?) and maybe it's 100 pixels wide, and each pixel is 2 bits, then that's 240 x 100 x 2 = 48000 bits = 6K for the base map. (Looking closer, the map is actually more detailed than that, so it's larger than the measly 6K... looks like the Big Map has 1 block averaging out 4x4 actual map pixels, so total map size is 6 x 4 x 4 = 96K. Which is more like it, since that plus native data would take up most of a diskette.) It still astounds me.
    1 point
  12. Just a quick FYI: I just fired up rev 38 of the emulator on my M1 MacBook Air and it seems to be working.
    1 point
  13. @kktos Thank you for the kind words and the feedback. If you have more feedback or suggestions please let me know. Here are my short answers to your points I agree with you! In the start the language has more ASM-features mixed in - but over time the compiler has gradually been improved and moved close and closer the standard C. I believe it is important to have the feature of addressing individual bytes - and the current solution is not very readable when used on 16bit or 32bit data. Also as you point out it confuses IDEs. So I want to find a different solution along the line of your proposals. My TODO is here: https://gitlab.com/camelot/kickc/-/issues/221 That would be a fine way to add support for floats. I have added a description here https://gitlab.com/camelot/kickc/-/issues/619 There is a bunch of stuff in the pipeline, so for now it will be put into the pile of ideas. There are keywords for changing the calling convention on a single function. Currently there are two supported calling conventions: - __phicall - passes parameters through shared variables. - __stackcall - passes parameters on the stack. __phicall is the default and allows the optimizer to optimize parameter passing quite a lot. __stackcall works for the test programs I have created - but I have not done very extensive testing. There is also a pragma for changing it in the entire program #pragma calling(__stackcall) I am working on adding the more advanced stuff, like calling conventions, to the documentation. Thank you. It is extremely useful when loading images or generating tables. I have been steadily adding platforms. The last additions have been Atari XL/XE, MEGA65 and CX16. The next ones I am considering are C128, Acorn Electron and PC Engine. I prefer to have the actual hardware myself so I can test that the compiler produces programs that run on the hardware. I do not have an Apple II yet. However, the Apple II would be an obvious addition at some point.
    1 point
  14. You might save some time by reading larger blocks - maybe copying your I/O code to low RAM when the editor starts.
    1 point
  15. Thanks. Yes, the magic suffixes are exactly what I was looking for. I think half of my trouble is that the PDF included in the release appears to be incomplete. I actually searched all references of “string” and could not find the magic suffixes, nor could I find a list of #pragmas. I did find your Google Doc, but I didn’t find the magic suffixes in there, either. (Although I will look again.) I have plans to build an Orthodox File Manager (sort of Midnight Commander for the Commander X16), and I will need to build the conversion and output functions in question, so as I complete chunks of that, I’ll send over the more useful parts. Now that I have a working file reader, I’ve passed the biggest roadblock, so
    1 point
  16. Waoo ! That seems very very promising ! I'll give it a try. Meanwhile, I was a bit curious looking at the source code you showed in the first post so I went to read the doc Quick remarks: - The high low operator. Pretty obvious when you're in asm. In C, it looks really weird. Not to mention your highlighter didn't recognize it. I would rather go with the same kind of logic you're using for string with a postfix modifier. addr.H and addr.L or simply an explicit HIGH(addr) - The floating point type Could you have a placeholder type like float and some pre defined functions ? Therefore the compiler would be able to compile those. The only thing is to add the library for the target system - function calls Is there a way to tell how the parms have to be passed (thru registers, thru stack....)? I didn't see anything on that matter. - inline kickasm code: Absolutely brilliant !! Congratulations, Sir. ps: any chance we have at some point other targets.... like the apple // ?
    1 point
  17. Update: absolutely brilliant! Thanks for the pointers here. Managed to get my Julia Set demo working in assembler. Super chuffed! Finally feel like I've got my head round it.
    1 point
  18. I think he may have been referring to a complete X16 system-on-a-chip, not just the VERA.
    1 point
  19. If you add a volatile to ret it will not optimize it away. The compiler is not clever enough to recognize that you are modifying it inside the ASM. It might be possible to examine the ASM instructions being applied to variables used inside ASM to detect if they can modify the variable. I will add that as a TODO.
    1 point
  20. One thing to note though is you should from a good coding standpoint, never attempt to read the keyboard or mouse directly. You should use the KERNAL routines instead. If you try to write your own routines it will cause several bad side effects. One is that if the way the keyboard works changes, it will break your code every time. What if a future version used a USB keyboard or a direct matrix? If you use the KERNAL routines you will always work and it would be the KERNAL that would change to match the hardware. Also we have found some keyboards have different requirements. We are making our routine as robust as possible. Custom routines may not be as forgiving. Sent from my iPhone using Tapatalk
    1 point
  21. Hi @Stefan, I just tried out the ROM variant of your X16Edit 0.3.3, and it works like a charm! The directory listing view is super convenient, I love it. The only usability issue I noticed is that in x16emu I can't use ctrl-R for opening a file, because the emulator then issues a reset, so the only way is via F5. Not sure if that is worth changing ... Invoking the editor was also straightforward and worked at first attempt, thanks to your sample assembler snippets. Also, I realized that the r0/r1 parameters at $02/03 and $04 for the file name not only follow the X16 Kernal calling conventions, but are also easy to set from Forth - very handy. One thing I was pondering today: I could use the jmp opcodes $4c at $c000 and $c003 as signature for the X16Edit ROM being present, and not call X16Edit otherwise; this could likely prevent a crash in most cases where someone would type xed in cc64 on a machine without the X16Edit ROM. Should we do that? Cheers /Philip
    1 point
  22. We have new code in testing that the emulator doesn’t reflect. When then code passes and we know it works reliably we will update the emulator and documentation. How it works now is not how it will work down the road. Sent from my iPhone using Tapatalk
    1 point
  23. Version 0.1

    56 downloads

    ux16vt is a UTF-8 and somewhat ANSI compatible terminal emulator for Commander X16. Currently the only useable "serial" port uses LOAD & SAVE to communicate between the X16 emulator and a glue process that moves data in and out of a POSIX pseudo-terminal. In the emulator LOAD "UX16VT.PRG" & RUN. On the host, compile and run emulator_glue.c. ## Unicode Support ux16vt supports up to 4096 1-bit 8x16 pixel glyphs selected at compile time from the Unicode Basic Multilingual Plane. Unknown characters are displayed as blank. Currently 672 of these glyphs are used covering 862 different code points. The following blocks are mapped: - Basic Latin (00-7f) - Latin-1 Supplement (80-ff) - Greek & Coptic (370-3ff) - Cyrillic (400-4ff) - Box Drawing (2500-257f) - Block Elements (2580-259f) Limitations: - no support for right-to-left text - characters are represented internally as 16-bit values, making any characters outside the basic multilingual plane complete inaccessible - completely mono-spaced text. full-width glyphs are not available ## ANSI Support Only sequences beginning with ^[[ are supported (Control Sequence Introducer). Only numeric parameters are read. A control sequence with more than four parameters will cause an unchecked buffer overflow. The following functions are available: A CUU Cursor Up B CUD Cursor Down C CUF Cursor Forward D CUB Cursor Back E CNL Cursor Next Line F CPL Cursor Previous Line G CHA Cursor Character Absolute [column] H CUP Cursor Position J ED Erase in Display K EL Erase in Line S SU Scroll Up T SD Scroll Down d VPA Vertical Position Absolute [row] f HVP Horizontal Vertical Position m SGR Select Graphics Rendition The only available modes for SGR are 31 to set foreground colour to red and 30,32-39 set the foreground colour to black.
    1 point
  24. The problem being that this ReadMe is not included in the emulator package, so I had no idea it existed until earlier today (when I was looking at the block I/O API.) Yes, the P command works great. I've already written a small demo program to test it. Also, it's worth noting there is an error in the ReadMe. The ReadMe says: POSITION P channel p0 p1 p2 p3 Set position within file (like sd2iec); all args binary "all args binary" is not correct. The channel number needs to be passed in ASCII, so the correct syntax to seek to position 128 on channel 1 is.... DOS"P1"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0) Channels 10-15 need to be entered as the ASCII characters after 9 (:;<=>?) here's an example: 20 OPEN 1,8,8,"@:DEMO,S,W" 40 FOR L=0 TO 255 50 PRINT#1,CHR$(L); 60 NEXT 90 CLOSE 1 100 OPEN 10,8,8,"DEMO,?,M" 110 DOS"P:"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0) 115 DOS 120 FOR I=1 TO 4 130 L=0:GET#10,L$:IFL$<>""THEN L=ASC(L$) 150 PRINT L; 160 NEXT I 170 PRINT 999 CLOSE 10 When you run this, it will create a 256 byte file. Then it will re-open the file for random access and seek to position 128. It will then print 4 bytes byte at that position. That should be 128-131.
    1 point
  25. I created this image for converting a classic mechanical PC keyboard into an X16 keyboard. You can print it on inkjet-printable sticker paper, and cut out the stickers. It works with the "print then cut" mode on my wife's Cricut cutting plotter. BTW, Although the graphics are obviously inspired by Commodore's work, I created this image from scratch by hand-editing a PostScript file in a text editor, so there shouldn't be any copyright concerns. Edit: The image should be printed at 600dpi, with a size of 6.5" x 3.125"
    1 point
  26. I've attached the entire file, cleaned up nicely. But here's a small snippet, as requested: x16-keycap-stickers.ps
    1 point
  27. Here's a version of the assembler to play with. It doesn't support symbols yet so stick with basic assembly. It also only writes output directly to memory for now. The video shows it in action on a simple hello world program: cx16mf-2021-01-14_22.07.31.mp4 assem.prg
    1 point
  28. It's a random access construct (drive seeking) for fixed length 'records' with variable data held within with zero overhead required by the Commodore deivce. With one command (via a 15 command channel), you can instantiate file of [as example] 192 characters per record; once created, you can open and close a file via simple open command without describing the structure; then via command channel, seek to any 'record' between 1 and 65535 with an offset in the record from 1st to 192nd character. Each record can have a varied structure (like a MongoDB document) and once open and positioned, you use typical "input #2,a$,b$" in order to read data. Again, zero overhead to the computer, all done within the 1541 (as example) drive. Anybody know?
    1 point
  29. I think I am going to need a bigger desk ... and a newer one, this one is getting up there in years, but it's served me well. I just can't seem to fit all the things I want to play with and work on. :P I have a lot of stuff sitting on top of my second computer (my "server" on the floor between the wall and desk), just to get more space. I keep having to move things around for every "project", or setup a small tray next to my desk to work on. It works, but it's messy. Anyone else have this problem? haha
    1 point
  30. @Massyn I borrowed your gist and rewrote it to acme. I also created code to clear the screen and load all of the 64 characters defined. https://gist.github.com/JimmyDansbo/49ea401a0e5cc0b77c9acc45399ea416
    1 point
  31. I explain in quite detail and with BASIC examples how VRAM is structured in different tile (text) modes and explains the concept of Tile base and Map base. I suggest reading these three tutorials; https://www.8bitcoding.com/p/vera-overview.html https://www.8bitcoding.com/p/tiles.html https://www.8bitcoding.com/p/tile-modes-2-4let-us-continue-with.html And yes, by default the content of VRAM is (kind of) random and has to be initialized before use.
    1 point
  32. Version 1.0.0

    57 downloads

    LIFE.PRG is an implementation of Conway's Game of Life compatible with the Commander X16 Emulator R38 (see https://en.wikipedia.org/wiki/Conway's_Game_of_Life). Configuring the Grid Dimensions: D - Toggles the grid dimensions between 29x29 (which is the default), 30x30, 59x59, and 60x60 options. The cell grid is always configured as a perfect square to permit more degrees of symmetry. Odd and even dimensions are both supported since they have different symmetry. The dimension of the length and width is illustrated in the upper right corner of the display. The 29x29 and 30x30 grid dimensions utilize 40x30 text mode, whereas the 59x59 and 60x60 grid dimensions utilize 80x60 text mode. The grid is cleared when the cell grid dimensions are changed. Initializing the Cell Grid: C - Clears all of the grid cells. E - Enters edit mode to manually configure the grid cells. The cursor keys are used to move the cursor pointer, the space bar toggles the state of the cell at the current cursor position, and E key is used to exit edit mode. In edit mode the row and column coordinates of the cursor are displayed in the upper left corner in the format "row,column". The mouse cursor is reused as a cursor pointer but the mouse is not currently supported. R - Randomizes the grid cells. H - Randomizes the grid with horizontal symmetry. V - Randomizes the grid with vertical symmetry. B - Randomizes the grid with both horizontal and vertical symmetry. F - Randomizes the grid with full symmetry (horizontal, vertical, and both diagonals). The edit mode entered by pressing the E key can be used to configure different patterns such as still-lifes, oscillators, and space ships (some of which are described at https://en.wikipedia.org/wiki/Conway's_Game_of_Life#Examples_of_patterns). The H, V, B, and F symmetrical configuration options generally result in more visually appealing patterns than the R configuration option. Iterating the Grid: U - Updates the grid a single time. S - Starts repetitive update of the grid, press S a second time to stop. The number of iterations performed on the cell grid is displayed in the upper left corner except in cell grid edit mode described above. The iteration count is initialized to zero at startup and reset to zero when the grid dimensions are changed via the D key or any of the grid initialization commands are executed (via the C, E, R, H, V, B, or F keys). When iterating the grid the left and right sides of the cell grid are considered to be adjacent as well as the top and bottom resulting in a toroidal array. Potential Future Enhancements: There are several potential future enhancements under consideration such as optimization to speed up the iteration of the cell grid, context-sensitive help, support for user-configurable grid sizes, support for multiple colors (e.g. based on state of a cell and the number of live neighbors), and support for other life-like cellular automaton (see https://en.wikipedia.org/wiki/Life-like_cellular_automaton). Life Video
    1 point
  33. To answer your question about different key switch types, I would highly recommend taking your next move carefully lol. Once you feel mechanical switches under your fingers, you can't ever really go back and enjoy membrane keyboards . For somebody that types all day, I would actually recommend a switch that allows you to feel the tactile point of actuation such as Blues. It's much more satisfying in my opinion and they generally are regarded as the best to type with. Red switches don't have a tactile feel for the actuation point and so they just slide until they bottom out. A more silent version of the Blue switch would be Brown switches and are sort of a happy medium between the two as they aren't super clicky clacky, but still have that tactile feel when depressing the key. However, regardless of the switch type, if you are plunging the keys hard enough to bottom out with every stroke, no mechanical keyboard will be truly silent. When at home I use Blue switches as the sound makes my heart happy and the feel is the best out of any switch type I own. I personally use Brown switches when in an office environment and I have never gotten any complaints from co-workers. I know that this is a lot of words to not really answer your question, but I hope to give you some things to think about that videos sometimes don't convey about different keyboard types since mechanical keyboards aren't inexpensive. Hope this helps!
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use