Jump to content

Stefan

Members
  • Posts

    251
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Stefan

  1. Hi. I've written some routines that read and write sequential disk files in my project X16 Edit. Basically, I've followed what's said about the relevant Kernal functions in the C64 PRG. At least when you access a file, there are two types of errors that may occur. I/O errors thrown by the Kernal, for instance error no 5 - Device not present Errors thrown by the "disk drive", for instance error no 62 - File not found The carry bit is set if the Kernal throws an I/O error at least when calling SETLFS - $ffba OPEN - $ffc0 CHKIN - $ffc6 CHKOUT - $ffc9 The error number returned in A register. The meaning of each error is available in the C64 PRG. In my edition (1 st ed, 9th printing, 1987, it's on page 306). The possible errors are: Too many files open File already open File not open File not found Device not present File is not an input file File is not an output file File name is missing Illegal device number You may get the other kind of error that is returned by the "disk drive" only by reading the status channel. In basic you would OPEN 15,8,15 and INPUT#15,E,M$. The last error code returned in E and the error message returned in M$. An assembly solution is a little more involved. You may look at my file handling functions here if it helps: https://github.com/stefan-b-jakobsson/x16-edit/blob/master/file.inc
  2. I wasn't aware of the -ram option. I don't think it's mentioned in the emulator docs. But I can see it's in the emulator -help. The emulator seems to accept any -ram value dividable by 8 between 8 K and 2048 K. However, as I understand, the hardware will have four memory IC slots of 512 K each, and the only possible values in real life would then be 512, 1024, 1536 and 2048 K. Maybe the best solution is to support all memory size options available in the emulator, even though only four of those options will be supported by the hardware.
  3. X16 Edit v 0.1.0 is released, and available in the downloads section. New features: - Copy, cut and paste - Search and replace - Go to line number - Auto indent - Tab key behavior improved - Memory usage function shows correct value, as returned by Kernal function MEMTOP - And of coarse, some minor bug fixes This version suppports almost all features I originally planned for. Roadmap to version 1.0: I will try to include a simplified automatic word wrap and support for PETSCII mode. Apart from that I will focus on cleaning up and making the code more efficient and beatiful, fixing bugs, and making the user interface nicer. If you try the program, please let me know if you encounter bugs. Please, also let me know if the user interface language could be made clearer or better. English is after all a foreign language to me. Have a great weekend!
  4. OK. I will use MEMTOP. It seems to work in emulator r38 on macOS. One more question though. That Kernal function returns the number of banks, for instance $40 (64) with banks 0-$3f populated. What will it return if all banks are populated? I suppose it might wrap around to zero.
  5. Hi, I'm working on X16 Edit, a text editor. There's a thread in Software Library Chat discussing the program in depth. My program uses banked RAM to store text that's edited. However, I have a general question regarding the hardware. It's said that the final product will have banked RAM of 512 KB expandable to 1 MB, 1.5 MB or 2 MB (by populating 1, 2 or 3 sockets). Is there a way for a program to determine what memory banks are actually available? If there is no other option, would it be possible to write a routine that tests certain memory addresses by first writing values and then reading them back? I guess that approach could work, but it depends on what the hardware does when you access an unpopulated address in banked RAM. A test routine would probably work if the data bus floats (returning a random value) or if it's tied high or low (returning ff or 00).
  6. @BruceMcFI experimented a little with automatic word wrap. As you said earlier, it's quite easy to monitor the length of a line as each char is typed in, and wrap at the previous word boundary by inserting a line feed marker. That will be very close to GNU Nano's long line wrapping feature, which you enable by pressing ESC and then L. It's at bit more complicated if you delete text in the middle of a line. Word processors recalculate the word wrap if this happens, and move words from the beginning of the line below to the end of the currently edited line as soon as each word will fit. GNU Nano's long line wrapping feature works in a more simple way, and it will not recalculate the word wrap when you delete text. If I do this, I'm thinking about going the GNU Nano way with word wrap. Would that be alright?
  7. Hi all. I have just published version 0.0.4 of my text editor. New in this version: More bug fixes. Most of memory handler redesigned. The program is now more stable. The program tracks if a document has been changed and asks you to save before any operation that would discard those changes (closing the program, opening a new document, creating a new document). Other general user interface improvements. Function to display memory usage implemented (press ESC and then m). Displayed as number of blocks free, inspired by the 1541. One block is 251 bytes of actual text data. I also made a short video demonstrating some of the features. Look carefully, and you may spot a mistake in my C programming. Have a nice weekend! x16edit 0.0.4.mov
  8. Sounds like a good idea. If I understand, you mean automatic word wrap that inserts an actual line feed marker in the buffer. That might actually be possible to do. In my first attempt I had word wrap that was calculated from the top of the paragraph without inserting any line feed markers. That became complicated. An alternative is to use some other control char to mark automatic word wrap. If I remember correctly, WordStar used such an internal marker. The advantage is that you can strip the word wrap marker when saving to file. Another thing. In my last post I said I had no know bugs. Naturally I found a couple right after saying that. On my bug severity scale, irritating - serious - deadly, I was closing up on deadly. When you inserted text above text that was already typed in, a few letters every now and then would be duplicated, effectively a memory corruption problem. Usually, you see right away what's causing such a problem. But in this case the corruption seemed random. I used a good 5 hours to isolate when the problem occurred. Finally I found an off by one error in the routine deleting a char from memory. It's a good feeling fixing such a bug ...
  9. I do not plan to have word wrap, at least not now. When I use text editors, I never have word wrap enabled. If you're editing source code or config files, word wrap is of limited value. This is actually my second attempt at creating a text editor for X16. My first try in 2019 had word wrap. The code became ugly and had a lot of hard to find bugs. I dropped word wrap to make things easier, but I might revisit it in the future. V. 0.0.3 is quite stable, and I have no known bugs (they are probably there anyway). I think I have a solid base to continue from. These are the things I'm working on now and in the near future: Memory defragmentation routine Search and replace Cut and paste
  10. If you're disciplined, no project is too large or complex for command line + Nano. I must look into Forth. Have never tried it.
  11. I just published a new version of X16 Edit to the downloads page. What's new? A lot of updates to the UI Some bug fixes It might soon even be usable.
  12. @BruceMcF I don't remember ever hearing about XOR linked lists. You couldn't easily come up with such a concept. I guess it's true that there's creativity in limitation. The downside is, of coarse, more complex code which might be a bit harder to debug.
  13. That's an interesting subject. The editor might not work as you think. It is essentially a model-view design. The memory module (=model) has no concept of screen or line. It is just text data. So there is no limit to the length of a line. If you like, the text can be one line, 2MB long. And there are no links to previous or next line or to the previous or next screen page (or any other element of the view module). When designing this, I calculated the memory usage. 16 bits are needed to represent the bank of the previous and the next memory page. 10 bits are needed to represent the previous and the next memory page high byte (range a0-bf is 1f wide = 5 bits). That is a total of 26 bits, not quite fitting in three bytes. I can't do any better, I think. The memory not used is 6 bits per memory page. 8,192 memory pages x 6 bits = 6,144 bytes lost of the total 2 MB. In the future I might come up with a use for those unused bits...
  14. Yes. However, I think you may call it a feature, and keep the emulator as is No problem, as long as you're aware.
  15. Hi, I've been testing to write sequential files to the sdcard image using the standard KERNAL routines (SETNAM, SETLFS, OPEN, CHKOUT and CHROUT) in emulator R38. I've noticed that files sometimes get corrupted. It seems to happen if the sdcard is mounted on the host computer's file system at the same time as it's attached to the emulator. However, writing to the sdcard seems stable if it's not mounted to the host system at the same time. I'm running macOS Catalina.
  16. A small video of the v. 0.0.2. Opening one of the editor's source files (file.inc). Skärminspelning 2020-08-30 kl. 10.58.51.mov
  17. I've published my second pre-release (v 0.0.2) of X16 Edit in the downloads section of this web page. Courtesy of emulator r38 (nice work!), I've implemented basic file handling. It is now possible to load and save text files to an attached sdcard. Use the -sdcard switch when launching the emulator. File handling will not work without an attached sdcard. This is a limitation of the emulator, as far as I can tell.
  18. 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  
  19. Version 0.4.0

    1456 downloads

    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
  20. Syntax highlighting would be nice. I'm worried about performance though. Multi-line highlighting would be especially hard to implement efficiently. For example multi-line comments in C. Highlighting not dependent on what's happening in the text above or below the current line would be simpler. However, it's a good idea, and I will have it in mind. A question: If the program should support highlighting, is there any reasonable way to make "plugins" for different file formats? I guess the program could load the selected highlighting code into RAM from the filesystem after startup. There could be a standardized jump table at the beginning of the code that exposes vectors to the needed subroutines. Or is there better way?
  21. There's a BAM of sorts. In the code it's called mem_map. It's situated in normal RAM at the end of the code. Banked RAM has 32 x 256 = 8,192 pages. The map has one bit per page, making it 1,024 bytes.
  22. You got it! And was able to describe it more clearly than me I think. Actually the 1541 disk format was my initial inspiration.
  23. @SlithyMatt Thank you for your tips. I will try them out. @rje Good idea to use function keys as alternatives. The program uses all of banked RAM, for now starting at bank 1 page $a0. Bank 0 may be used by the KERNAL if I understand the Programmer's Reference Guide correctly (emulator r37). Text entered by the user is, however, not organized as one continuous string. Instead each memory page is dealt with as a separate string. The memory pages are dynamically linked to each other. To make this possible each memory page also contains some metadata. Consequently, the program isn't suitable for directly creating raw data in banked RAM. For clarity, when I'm talking about memory pages, I mean for instance the address interval $a000-$a0ff or $bf00-$bfff, i.e. 256 bytes. I chose this memory model in order to be able to handle large texts. Otherwise you could end up in a situation where the text is 1 MB and the user inserts new text at the top. If the text was stored as a continuous string, such an operation would demand that the program copies/moves 1 MB of data one step forward in the memory before inserting the new text. I think that would be too slow. Every memory page used by the program contains the following fields: Offset Content 00 Previous memory page / Bank number 01 Previous memory page / AddressH 02 Next memory page / Bank number 03 Next memory page / AddressH 04 Length of text stored in this memory page (0-251) 05-ff Text data (max 251 bytes) It is a bit hard to describe the memory model in a short and easy way. You may run the program and hit restore. Inspect the memory usage with the built-in monitor. In the monitor you need to type the letter O01 to select RAM bank 1. The aim of the program is to store pure text files in the filesystem. It would be quite easy to write a tool that loads data from a file into banked RAM in the way I think you would like to do.
  24. Here is a small demo showing what the 0.0.1 version is capable of. Skärminspelning 2020-08-23 kl. 14.18.12.mov
  25. A couple of things I've been thinking about. How can you reliably determine if the CTRL key is pressed? For now the I'm reading the keyboard with the KERNAL routine GETIN. It mostly works fine, but there are some overlaps. For instance, CTRL+s is the same as HOME. Is there any way to determine the current character mode (PETSCII OR ISO)? And, is it somehow possible to get the screen width (in columns)?
×
×
  • Create New...

Important Information

Please review our Terms of Use