Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/07/20 in all areas

  1. Hello there, Very interested in this project... I grew up on TRS 80 BASIC, Apple II LOGO, TI 99/4a BASIC, IBM PC BASICA, etc. There was something different about the design philosophy of those old machines. They were inviting you to come and play around with them down to the bare metal of the hardware itself. Totally different design philosophy than what happens today - except maybe in the Arduino/Raspberry Pi world. Man its been a while since i wrote anything in BASIC....attached is Yet Another Mandlebrot Set program translated from Python to BASIC for Commander X16 emulator. Most of the lines ended up being REM comments. ... i tried to emulate functions in BASIC which was kind of funny. The user can pixelate easily by changing "SP' variable, for speed. and change the exploration point pretty easy too. I guess i had a realization... BASIC was easy, for computers of that era... but.. maybe not as easy as some things nowdays. I grew up with BASIC (Donkey.bas, startrek.bas, all the BBS hits), but programming with it now, it feels like an interpreted assembly language, For example there is no "IF.. ELSE' control structure, functions can only have one argument... GOSUB cannot return a value... variable names have two letters only and it won't warn you on longer ones, GOTO is a pretty normal way to break a for loop, number lines are required...and to be honest I never really learned how to do things like arrays of data. wow. Just really different after using all these modern languages. Even QBASIC from the early 90s is very different than C64 Basic. On the other hand, I do like the general lack of parenthesis, brackets, curly braces, back ticks, hash marks, dollar signs, exclamation points, massive dependency libraries, and so forth. There is still something nice about it's simplicity and small size and directness. And the fact the whole thing can be documented in a pretty small manual. It also neatly hides an impressive amount of mathematics floating point functions under a deceptively simple cover. As for the slowness... i had forgotten how it can be interesting to have something going so slow that you can actually see what it's doing. That can be kind of cool sometimes. Everything seems a bit more on the human scale. It kind of reminds me of the Mandelbrot set itself... something that comes from a very simple foundation, but if you explore it there is a whole world of interesting things. I feel like maybe there is still some progress to be made on BASIC on an 8bit machine but I just don't know what it would look like exactly. Maybe something even easier than Basic while also maintaining the simplicity and immediacy of it, but also the low resource usage. I know some people like "Scratch".. not sure if thats ever been done with a tiny CPU though. Then there is MicroPython and Circuit Python. The PROG8 language looks very interesting but the compiler cannot be run inside the machine itself if i understand correctly. anyways thanks. m.bas
    2 points
  2. Very small update for you guys. First prototype PS/2 mini keyboard is in. Note: This is not representative of our colour scheme or keycap artwork. They used a default artwork but we'll be able to get more specific once the crowdfunding starts. But the goal of this prototype is to test the new more ergonomic raised up keycaps and overall feel and design. You may remember our early prototype keys were flatter, more laptop like, and less nice to type on. This feels REALLY good to type on, especially for a good value non-microswitch keyboard. Can't wait for you guys to be able to hold it in your hands. Well... under your fingers... You know what I mean. (And of course the deluxe microswitch keyboard made and sold by WASD remains an option for the most selective of keyboard connoisseurs: http://commanderx16.com/deluxekeyboard ) More updates soon! Your friend in retro, Perifractic
    1 point
  3. Hi Stefan, Great stuff! Regarding learning Forth: Yes, that is quite a step. It doesn't actually really have to be hard, but it's very different in a number of respects from many other programming languages, so quite some concepts to wrap your mind around, esp. the distinction of compile time and run time which, as opposed to most other languages, in Forth you have explicit control of - and want to use, at times. There are 2 books by Leo Brodie I would recommend, btw. The generally agreed best book for learning Forth is "Starting Forth" which is e.g. available online at Forth, Inc. The other book is even more remarkable, imho, and it is "Thinking Forth" which even has its own web site now, and it contains a lot of really insightful design advice and principles when using Forth; at least some of it should be relevant beyond Forth, too; I at least consider it one of the top influential books on my own programming and design style. Really good that you have leeway wrt zero page usage. But I also just saw that I could likely let VolksForth use the area $00A9-$00FF; in the Commander X16 Programmer's Reference Guide it says "In a machine language application that only uses KERNAL (no BASIC or floating point), the following zero page locations are also available:" - that should apply easily to VolksForth; when exiting it I'm invoking a BASIC cold start so overwriting BASIC's zero page addresses should not be a problem. Anyway, clearly something we can get figured out and synced on going forward. As for the $0400-$07FF area - VolksForth doesn't use any of that (methinks, at least); it is based on and follows the C64 VolksForth very much. VolksForth also doesn't use any banked RAM right now; when a time comes where that might be desirable, e.g. to back the Forth virtual memory manager for reading disk blocks (which the x16 implementation doesn't do at all yet), I'm sure we could also arrange some (possibly configurable) split of the RAM banks between the different usages. Cheers /Philip
    1 point
  4. Hi, Thanks, I'll try including those files. Learning Forth is a struggle, and I don't feel like the smartest of people when reading tutorials about it... Good idea to coordinate memory usage. At this stage, the program uses 57 bytes of zero page ($22-$5B). Of these, 10 bytes must be in zero page, as they are used for indirect addressing. The program uses $0400-04DA for variables and temorary storage. $0500-05FF is the buffer used when prompting the user for input to commands. $0600-06FF is the current file name buffer. $0700-077F is a buffer holding the result of last disk status read. $0780-07FF is bridge code needed to handle ROM banking. All of banks 1-255 in the banked RAM are also used. Bank 1 for the program's memory map (1 kB) and clipboard buffer (3 kB) and banks 2-255 for the actual text buffer. I could easily use less zero page addresses. I could probably also use a lot less space in the $0400 page. There are a lot of temporary backups of values that could be moved to the stack instead. And it is of coarse possible to backup the zero page on starting X16 Edit, and to restore it on exit. I have got 4 kB of unused space in banked RAM, bank 1, that could be used for this purpose.
    1 point
    excellent. brings back good memories. thanks.
    1 point
  5. Christmas 2020 Demo View File A sequel to my demo from Christmas 2019, but refactored to work with the R38 emulator and using new music and graphics. You can play it here, on your emulator, or just watch it on YouTube: Also available on GitHub: https://github.com/SlithyMatt/x16-xmas/releases/tag/2020.0 Submitter SlithyMatt Submitted 12/03/20 Category Demos  
    1 point
  6. oh nevermind i had to download all ten BIN files into the same folder as PRG then load and run it. ok
    1 point
  7. i tried to start the x16emu emulator on linux then i typed LOAD"XMAS2020.PRG .... it flashed some merry xmas words on the screen but then froze and went black... not sure if i did something wrong. anyways its a great demo video on youtube, brings me back to the old days. impressive how much you can fit in such a little amount of space.
    1 point
  8. Hi Stefan, in case you want to do inline assembly, you would indeed want to add 6502asm.fth and possibly trns6502asm.fth from https://github.com/forth-ev/VolksForth/tree/master/6502/C64/src to the sdcard, but to start and learn the language I would actually advise to leave out assembly at first. Of course, to call your editor, you need assembler, that's true. I may also take a stab at that integration over the Christmas break. I'm currently working on porting my C compiler cc64 (written in VolksForth) to the x16 - there your editor would of course also come in extremely handy. But basically I would say you don't need any other files to do something interesting. You may want to add tracer.fth from the same location above, if you want to do single-step debugging. But that should be it. cc64 is really based on just core v4th and the 6502asm.fth files from the VolksForth sources. One thing we should figure out to make the two tools easy to integrate with each other is zero page usage: Maybe we could make it so that we keep away from under each others' feet, so to speak, that we use different zero page areas. What is X16Edit using? VolksForth currently starts to use ZP from $30, and I would have to look closer how long exactly the used zero page segment is, but it seems to be ~50 bytes; among others the inner interpreter lives there, much like charget in C64 BASIC. Cheers /Philip
    1 point
  9. You mean Perifractic's Periboard by Perixx? [emoji6] We've worked with them on some ergonomic improvements but it was based on that model. And of course it's PS/2 with no USB hub at the back.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use