Jump to content

desertfish

Members
  • Posts

    693
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by desertfish

  1. I've moved the image viewer program into its own github repository (it used to be an example in the prog8 compiler repository): https://github.com/irmen/cx16imageviewer
  2. You could also have a vector or even a single JMP instruction at $C000 that jumps to the actual entry point, followed by the name and version info and perhaps other data, followed by the program itself which it jumps to. That way you can have the layout however you want; the start is always at $c000
  3. Clifford Stoll !! I know him because of the Klein bottle episodes on Numberphile!
  4. I don't know this game. Does it have all of the map in memory? Or does it load stuff from the disk during play? There could be a lot of procedural generation going -- which in theory allows for infinite maps...
  5. Yay glad you found the solution. I don't understand though how limiting the display frame rate is of any consequence to the speed the application runs, but hey
  6. "YouTuber Marc Verdiell, a.k.a. CuriousMarc, has turned a 1930s teletype machine into a Linux terminal. To do that, he had to make circuitry and programming that translates five-bit Baudot code into eight-bit ASCII code." https://interestingengineering.com/video/computer-whiz-uses-1930-model-15-teletype-as-a-terminal-for-linux here's a picture of this spiffy terminal interface:
  7. Silly question perhaps but does the "try-it-out" in-browser emulator work for you? Second question: what happens when you dial back the desktop resolution to what you had before? (as opposed to just running the emulator with the same window size) (asking this because I think your cpu should be fast enough to run the native emulator just fine...)
  8. I love the way the little 'tab's work with the petscii lines.
  9. Hmm, that's not how I now understand the banked roms to be working in the memory map from the documentation https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#memory-map and the discussion in the file i/o performance topic. I read that as "basic is in a different banked rom, namely 4, as the kernal, which is in bank 0" and the rom banks are 16 kb each....
  10. You're on to something here That's very nice of you I hope they can appreciate it for what it is. I don't know their age but it may be difficult for young people to grasp the magic let alone nostalgic aspects of these computers, if they grew up with the whole internet in their pockets (smartphone) Anyway welcome!
  11. slithymatt micro-optimizing a t shirt/desktop picture Then again Jimmy's version is compatible with 6502 systems so there's that!
  12. Something i was wondering - isn't the basic ROM bank size on the cx16, 16 kilobyte? ($c000-$ffff, the kernal rom is in another bank from what I now understand) Why is it then that we already had trouble to find rom space to add those hex$ and bin$ functions? (at least I remember we ran into that) because the basic v2 rom on the c64 was just 10 kilobyte or so. The few extra existing commands that were added can't account for the other 5-6 kilobyte surely? I may be way off course here in my estimations but I suddenly was curious
  13. I started programming seriously on the Amiga and my source control consisted of a stack of floppies (and later a set of numbered directories on the hard disk drive). It sortof kinda worked mostly because I was the sole programmer, and because the tool support (editor, compilers) on the Amiga itself was extremely good for the time. While it's impossible to obtain that same level on the commander x16 I still think Stefan has some valid points - being able to create nontrivial programs on the target system itself is an important selling point. And I dont think basic v2 can fill that spot because it is very lackluster (in my opinion).
  14. The file-based assembler project can now be found in its own github repo: https://github.com/irmen/cx16assem
  15. That’s a nice description I think I’m starting to understand now what’s going on. Will try it in the assembler tomorrow. Not a big fan of disabling the Irq though, I wonder if we can leave that on default. edit: it works - selecting rom bank 0 for the kernal rom, saves a couple of seconds in the assembler, the large file now takes 9.1 seconds to assemble where previously it took 11.5 seconds. I think we have to load the file at least two times soon (when substituting symbols) so this time saving is going to add up. This nice little hack is staying for now
  16. I think I'll make a separate github repo for the assembler. It's now "an example" in the prog8 repository but I feel it is growing way beyond that. Also I don't think I have the time to implement everything myself and I much rather would like to see this as a joint effort! It's meant to be open-source after all Great tips though Stefan. I am quite confused still though by the "select kernal ROM" -- isn't it there by default? How else could we call CHRIN() and its brethren?
  17. This sounds like a fantastic hack. I am deeply intrigued!
  18. Yeah, the floating point routines are on different addresses in the X16 rom. Also I think not all "internal" basic routines of the C64 basic rom can be used or are even available. I stuck with the exposed routines listed here: https://github.com/commanderx16/x16-rom/blob/master/fplib/fplib.inc (translated into Prog8 here with a little bit of description added for each routine) Unfortunately FIN is listed as ";fin = $fe7b ; XXX TODO" and the routine is not implemented. So converting a string to a floating point value is "Left As An Exercise For The Reader" I think..... I haven't had to do this myself so far--- all I ever needed was the user inputting an integer . This can be converted to float using GIVAYF for instance. For floating point constant values in the program, the Prog8 compiler itself is doing the conversion to the 5-byte binary format so the program never sees the string...
  19. I went through (parts of) the same exploration when trying to figure out how to add floating point support to Prog8. Don't hesitate to ask if you have additional questions!
  20. In the file assembler topic we had some peculiar findings regarding i/o speed as well . To me, it seems that there is something going on in the emulator that skews the results
  21. You could also try to use the basic/kernal floating point routines such as FOUT $fe81 to print the floating point values
  22. 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
×
×
  • Create New...

Important Information

Please review our Terms of Use