Jump to content

Michael Parson

Members
  • Posts

    50
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Michael Parson

  1. Didn't realize it started out on DG systems. Neat. WP 5.1 is the word processor I have used the most. By the time Windows started getting steam, I was working as a sysadmin and had little need/use for a word processor, and when I did need fancy formatted documents, I used traditional Unix tools (dabbled with TeX, but settled on troff, now groff), or HTML for displaying in a browser. These days, most of my documentation is in Markdown, edited with vim, though my resume is troff/groff with -me macros. I've written the odd document in various releases of MS-Word over the years, but since leaving school, I've not really had a need for a word processor, and if I'd had a Unix system when I was in school, I probably would have used troff back then too. :-) Thanks for the pointer to the ebook history of WP, added to my reading list. It having started on a Data General system, it will go nicely with my copy of The Soul of a New Machine.
  2. I don't remember ever seeing WordPerfect for CP/M. I think the big-name word processor for CP/M was probably WordStar.
  3. Which version of WP for the Amiga are you having problems with? I've got WP 4.1 running on Amiga OS 3.1 and 3.9 without any problems, under FS-UAE/Linux and on my MiSTer. Not entirely relevant to this thread, we can take it offline if you want to continue discussion.
  4. Unfortunately, none. Anything that requires floats and/or math.h hasn't been implemented yet. It seems to be due to how the 6502 does floating point vs the 'traditional' C implementation using IEEE 754. There were discussions on the cc65 dev list a few years ago about it, and one guy seemed to be making progress, but nothing seems to have been committed to the master branch as of yet.
  5. Not everything is documented in funcref.html, but most of it is. Sometimes it will say "incomplete", others functions are simply missing from the documentation, but the headers do at least show the function prototype, sometimes with some additional documentation about the function in the comments.
  6. curses is the general UNIX terminal control library, ncurses is the SysV ('new' curses) version, which is mostly backwards compatible and offers more features, and is the default on (most?) Linux distros. S-lang is a semi-popular alternative.
  7. I used the X-16 as an excuse to take another run at C. The results so far? A PETSCII game: https://github.com/mparson/gridgame (slightly older version available in the X-16 downloads section). I started with the X-16 as the target, but now it compiles and runs on the C-64 and 128 as well.
  8. It's actually closer to running on metal than running software emulation, since it's implementing (most) all the chips of the original hardware on the FPGA. You'll get more speed (turbo modes, etc) with emulators, FS-UAE gives me a ridiculously fast Amiga, where the MiSTer's MiniMig is more like a slightly souped up A1200, but it's a lot closer to cycle accurate than any of the UAE implementations. I'm enjoying the MiSTer and am looking forward to the MiSTix board which will be an adapter board for mounting the DE-10 Nano in a Mini ATX case, with the ports coming out the back. I plan on using it to put my MiSTer setup in the Checkmate A1500 plus case to finish off the Amiga look & feel.
  9. Renumber is useful, but it can get hairy. Do you also have renumber scan the code looking for GOTO and GOSUB and fix those? I've seen some that did, most didn't. It's gets better when the implementation has labeled subroutines. That would be interesting to unwind. As I understand it, and I'm far from any expert on the matter, Commodore licensed BASIC for the 6502 from Microsoft for the original PET and basically (heh) just kept porting/extending it for new 8-bit C= systems. I imagine that ownership is somehow split between whoever now owns that part of the IP (Cloanto?) and Microsoft. In any case, no one seems to have taken down the 'cbmbasic' github page, which is the C-64 BASIC ROM dissembled and run through a tool that converted it to C, with some cleanups and patches to make it usable as a scripting language on UNIX/Linux/macOS/Windows. They did the same thing with the original Apple I BASIC. #!/usr/local/bin/cbmbasic 10 PRINT "HELLO WORLD
  10. Maybe it's a minimal 6502 + VERA implemented in FPGA that he used when originally designing the VERA before there were real X-16 dev boards?
  11. It's a hold-over from the C-64 BASIC that they started with. With all the C= 8-bit BASICs, while variable names could be longer than 2 characters, they were only unique for the first two characters of the variable name, so if you tried to set up variables BOB, BOTTLE, & BOING, they'd all be (internally to BASIC) "BO". There are a few reserved variables for system use. TIme, TIme$, STatus, and now with the X-16, DAte$ 10 BOB=10 20 BOTTLE=20 30 BOING=30 40 PRINT BOB,BOTTLE,BOING RUN 30 30 30 In any case, yeah, our variable namespace has shrunk by one with the X-16 from what we had on the C-64.
  12. Thanks. My mom taught at the local community college/University of Texas satellite campus and was in the Education department, teaching future elementary teachers how to teach reading. Her department was right next to the CS department and was friends with the professors in that department as well as hers. While she wasn't in CS herself, she was often an early adopter of technology, even had an email address before I did ( I didn't get access to email until I went off to college in the early 90s). While I did spend a bit of my early days on UNIX doing minor edits to code to make it compile on different UNIX flavors, I never really got into C programming until very recently. Two of my contributions to the X-16 downloads are my first real projects in C, still learning and wrapping my head around the C way of doing things. Most of my UNIX programming has been scripting in bash and perl. My only formal programming training has been in BASIC (took a college semester of BASIC programming over a summer back in the 80s, Waterloo BASIC on an what wikipedia tells me was probably an IBM mini or mainframe of some sort), plus a few years of PASCAL programming in highschool. Still like playing with BASIC from time to time, but my PASCAL knowledge has all faded with non-use. The 2 week course in Java IBM sent me to didn't stick, seems my brain is more wired for procedural programming than OO and I've never stuck with any OO language long enough for it to sink in.
  13. Along with all the manuals that came with all the C= gear I've owned over the years, and the Commodore 64 Programmer's Reference Guide, I also have physical copies of: Machine Language for the Commodore 64, 128, and Other Commodore Computers, Revised & Expanded Edition (Jim Butterfield, 1986) - Brady Prentice Hall Press Commodore 64 Graphics and Sounds (Timothy Orr Knight, 1984) - SAMS Publishing Compute!'s First Book of Commodore 64 Sound and Graphics (Greg Keizer, C. REgena, Paul F. Schatz, et. al, 1983) - COMPUTE! Publications Commodore 64 Games for Kids (Clark and Kathy H. Kidd, 1984) - COMPUTE! Publications Computers and End-User Software with BASIC (Thomas H. Athey, John C. Day, Robert W. Zmud, 1987) - Scott, Foresman and Company Programming in BASIC - Problem Solving with Structure and Style (Stewart M. Venit, 1987) - West Publishing Company Perfect Pascal Programs (Edited by Robert Platt, 1985) - Washington Apple Pi PASCAL (Nell Dale, David Orshalick, 1983) - D. C. Heath and Company Those last 4 look to be textbooks, probably stuff my mom got when she was a university professor and brought home surplus or evaluation copies for me. And, since my profession and daily-work has been in UNIX and UNIX-like systems for nearly 30 years, and given when it was published, I think this still qualifies: The C Programming Language (Brian W. Kernighan, Dennis M. Ritchie, 1978) - Prentice-Hall (also have the 1988 ANSI C Second Edition)
  14. The 'lynx' text-mode web browser still works with gopher:// URLs.
  15. New version upload, v0.9.5 - replayable boards. New "REPLAY" button resets the game to the last generated/edited/loaded board so you can try for a higher score on the same board. Unrelated to gameplay, I also broke the source code into modules from a single monolithic file.
  16. Find a local C-64 group, a city the size of Ottawa probably still has one. I'm sure it's full of people that could help you with that.
  17. New version upload, v0.9.1 - Board Edit Edition Click on the 'EDIT' button and you can edit the board. Congratulations, you are now in the most frustrating and feature limited PETSCII drawing program ever. The boarder changes to '*' from the line-drawing characters. You can now click on a piece to rotate it without triggering a chain reaction. If you click on one of the '*' on the boarder, it will change the entire row or column to match the adjacent piece. When you 'SAVE' a board, it will not check for a previous file, it will silently overwrite it. Similarly, attempting to 'LOAD' a non-existent board will silently not load a board and return you to the editor. Click on 'RESET' under the HIGH SCORE and your HIGH SCORE will be reset to '0' and saved. Click on 'DONE' to play the board. None of the stuff around saving/loading works unless it is run from an sdcard.
  18. That is a valid point. And while I'm a HUGE fan of this project, and will probably buy one, honestly, I'm not sure how much I'll actually use it. I've never been a huge video game player. Over the years, I've built a collection of lots of games for most of the systems I've owned over the years, but only a handful of them ever got played repeatedly, and a small subset of them got any regular play. My Steam library has close to 300 games in it, mostly stuff I bought as part of HumbleBundle "Support the independent developers bundles," a few I bought individually from the Steam store directly, but I have only played less than a dozen of them, and maybe half of them repeatedly. As it is, I'll have to do some re-arranging of stuff on my desk to even make room for a new system. This is one of the reasons I like the MiSTer setup, it's small and doesn't take up a lot of room on my desk. If it didn't have networking and required that I pull the SDdard out to change the contents, it would probably get less use than it does. If they ever get tun/tap or even SLiRP networking working to the point that we can use the networking from the running cores, I might use it even more. Similarly, If the X-16 winds up with some sort of networking, or even a usable rs232 serial port that I can hang off the back of my Linux box, and can use a terminal emulator to connect to remote systems and do file transfers with, it will improve the odds of me using it more. Even before I saw his channel, I had often fantasised about having a mini retro-computing museum in my house similar to Perifractic's. Maybe once all the kids are grown and have moved out I can set it up in one of their rooms, though I'm not sure my wife would be as understanding as Ladyfractic. :)
  19. To quote the great philosopher, The Dude, "That's just like, your opinion, man." Cross-dev has been a thing for a long time. Lots of MS-DOS dev work was reportedly done on UNIX until DOS was self hosting (was it *ever* self hosting?). Quite often, initial development of new systems is done on the previous generation using simulators of the new components until the design is ready to be sent off for the next level of prototyping. Yeah, a lot of dev work was done on the real hardware, but a lot of it was done on bigger/other systems and maybe only the fit, finish, and polish done closer to it being ready to release. In any case, I see this transpiler being a modern & updated version of how I wrote stuff on the C-64 back in the 80s, start on paper with a general design/flow, maybe a few lines of hand-written code in a notebook, maybe even whole programs written out in long hand while away from the keyboard, surrounded by reference books. Type it in, some parts work, some parts don't. Looking at the code on the screen, we only had 40 columns and 25 lines, the program was probably longer than that, possibly much longer, and if it was in BASIC, no back-scroll, so, either LIST and hold down CTRL to slow down the output until you see what you're looking for and try and hit RUN/STOP before it scrolls past, or look at in chunks with LIST 100-200, nope, not there, LIST 200-300, ad nauseam. Oh it might be in this chunk, or the chunk it calls, or somewhere inbetween. Print it out on the tractor feed dot-matrix, back to working with a pile of paper, your pencil, and the reference material. Ah, the good ole days. Here, instead of a bunch of paper and a pencil, you're getting closer to the code in a text-editor. Working like this, your transpiled code might get you close enough to done that you do your final work on the end system and possibly back-port those fixes to the transpiler format for future versions/improvements. Writing a transpiler/compiler is cool, and not a small task. It requires knowledge of not only the target language and all of its idiosyncrasies, but of the language(s) you're writing the transpiler in. Cross-dev doesn't magically make the target system do things it can't otherwise do, we're still dealing with the limitations of the target (hell, even the limitations of the system you're doing the dev work on, compilers/transpilers/etc aren't perfect either). The only wrong way to do it is the way that doesn't work.
  20. Oh nice. I'll update my source and use that in the next version of Gridgame (and anything else I do that needs PETSCII). Thanks!
  21. New version uploaded, v0.6. Only feature change is saving high scores to disk. The save is triggered at the end of a run if there is a new high score. Happens very quickly, all you'll really see is a blink of the drive activity indicator in the top-right corner, if you're watching for it. For giggles, I tried compiling it with '-tc64' Under vice, once I figured out how to make the mouse work, it was surprisingly fast. The mouse movement was all wobbly and jumpy, but, for the most part, it worked. Saving the highscore file takes a few seconds, but not terribly long. Tried it on my MiSTer's C-64 core and the mouse was nice and smooth. Both environments (vice & MiSTer) did weird things though. There were strange character artifacts that popped up in a few places during game play, and I'm pretty sure something was going goofy with the processing of the queue of which pieces to rotate, as I was getting WAY higher scores on the C64 version, probably due to the queue filling up and wrapping. I've not spent any time trying to debug it, just thought it was interesting. I'm guessing the character artifacts are due to screen memory getting overwritten, might be able to solve that by digging into the cc65 best practices on variable handling and seeing if I can tune that up a bit. Next feature to work on: Board editing (with saving & loading). I worked on the high score stuff first since I figured it would be a good way to learn how to open,read/write or remove, and close files. That turned into an adventure of its own.
  22. Not sure why the "try it now" isn't working... Same file loads fine in the native emulator. [edit] Re-uploaded as 'GRIDGAME.PRG' and edited the name of the file to be run, now it works in the web emu.
  23. Version 0.9.5

    128 downloads

    (full source available https://github.com/mparson/gridgame) GridGame A game for the Commander X-16! A 'C' implementation of a Flash game I used to play a lot of back in the days of Flash games. Read about the original game here: https://jayisgames.com/review/gridgame.php I'd say this game is ~95% faithful to that original game. Some of the limitations are due to my use of the so-called PETSCII character set for the graphics instead of custom graphics, which means there is no smooth animation of the pieces as they are activated. I've also not included any sounds, but that might come in a future version. This is original code that implements the gameplay, I did not port the embedded ActionScript of the original SWF game. New feature in v0.9.5: Replayable boards, the "REPLAY" button will reset the board to where it was after the last "RESET", "EDIT" or "LOAD". Try it again, see if you can get a better score from the same starting board. New feature in v0.9. Click on the 'EDIT' button and you can edit the board. Congratulations, you are now in the most frustrating and feature limited PETSCII drawing program ever. The boarder changes to '*' from the line-drawing characters. You can now click on a piece to rotate it without triggering a chain reaction. If you click on one of the '*' on the boarder, it will change the entire row or column to match the adjacent piece. When you 'SAVE' a board, it will not check for a previous file, it will silently overwrite it. Similarly, attempting to 'LOAD' a non-existent board will silently not load a board and return you to the editor. Click on 'DONE' to play the board. Why? Why write this game? Well, two basic reasons. First, I decided to take another run at picking up the C programming language, and like learning any new language, it helps if you have a project in mind that you want to implement. Why write for this platform? Being a fan of the Commodore 8-bit computers and following the development of the Commander-X16, I thought it would be a fun platform to target. Compiling the code This was developed with the cc65 compiler, so, you'll need it installed. I tend to work with the latest version out of git rather than one of the binary packages, so, YMMV with getting it compile if you use a potentially older version of the compiler suite. Edit the `Makefile` and fix the paths to the various binaries at the top. A simple `make` should give you a `GRIDGAME` that you can now load up on an X-16. It should be a minimal effort to make a C-64 and C-128 version as well, probably coming soon. Notes on the kwalitee of my code Yeah, very intentional bad spelling there. I make no claims to my skills as a C programmer. This is probably not "good" C code and most definitely not optimized in the suggested ways you should when writing for `cc65` compiler and the 6502 CPU. Potential features for future versions: * Versions for the C-64 & C-128 * Sound - I'll need to read up on how to make cc65 generate sounds. It's documented, but I've not tried that yet. Step 1 was to get the basic game working. * See if it will compile with KickC, then all dev work could even be done on the system it is played on!
  24. GRIDGAME View File (full source available https://github.com/mparson/gridgame) GridGame A game for the Commander X-16! A 'C' implementation of a Flash game I used to play a lot of back in the days of Flash games. Read about the original game here: https://jayisgames.com/review/gridgame.php I'd say this game is ~95% faithful to that original game. Some of the limitations are due to my use of the so-called PETSCII character set for the graphics instead of custom graphics, which means there is no smooth animation of the pieces as they are activated. I've also not included any sounds, but that might come in a future version. This is original code that implements the gameplay, I did not port the embedded ActionScript of the original SWF game. New feature in v0.9.5: Replayable boards, the "REPLAY" button will reset the board to where it was after the last "RESET", "EDIT" or "LOAD". Try it again, see if you can get a better score from the same starting board. New feature in v0.9. Click on the 'EDIT' button and you can edit the board. Congratulations, you are now in the most frustrating and feature limited PETSCII drawing program ever. The boarder changes to '*' from the line-drawing characters. You can now click on a piece to rotate it without triggering a chain reaction. If you click on one of the '*' on the boarder, it will change the entire row or column to match the adjacent piece. When you 'SAVE' a board, it will not check for a previous file, it will silently overwrite it. Similarly, attempting to 'LOAD' a non-existent board will silently not load a board and return you to the editor. Click on 'DONE' to play the board. Why? Why write this game? Well, two basic reasons. First, I decided to take another run at picking up the C programming language, and like learning any new language, it helps if you have a project in mind that you want to implement. Why write for this platform? Being a fan of the Commodore 8-bit computers and following the development of the Commander-X16, I thought it would be a fun platform to target. Compiling the code This was developed with the cc65 compiler, so, you'll need it installed. I tend to work with the latest version out of git rather than one of the binary packages, so, YMMV with getting it compile if you use a potentially older version of the compiler suite. Edit the `Makefile` and fix the paths to the various binaries at the top. A simple `make` should give you a `GRIDGAME` that you can now load up on an X-16. It should be a minimal effort to make a C-64 and C-128 version as well, probably coming soon. Notes on the kwalitee of my code Yeah, very intentional bad spelling there. I make no claims to my skills as a C programmer. This is probably not "good" C code and most definitely not optimized in the suggested ways you should when writing for `cc65` compiler and the 6502 CPU. Potential features for future versions: * Versions for the C-64 & C-128 * Sound - I'll need to read up on how to make cc65 generate sounds. It's documented, but I've not tried that yet. Step 1 was to get the basic game working. * See if it will compile with KickC, then all dev work could even be done on the system it is played on! Submitter Michael Parson Submitted 02/08/21 Category Games  
  25. I've not been through all the stuff in the downloads section, so, this hasn't been an issue for me, but seems to me that distributing stuff on sdcard images isn't the best way to distribute files at all. Even if you zip the card image, we still have a minimum of a 32 meg (uncompressed) file for the sdcard image. Seems that a zip-type archive would be best for stuff that needs multiple files. Semi-related question: Does/will the X-16 DOS support subdirectories? If so, hopefully with an easier way to deal with them than on an un-expanded C-128/1581.
×
×
  • Create New...

Important Information

Please review our Terms of Use