Jump to content

Ed Minchau

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

13 Good

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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. Yes it is very peculiar. The program I was writing was very peculiar. It is meant for reading and editing code that would otherwise be considered compiled code. I had to really dig in to my bag of tricks to make this all work, and I've been working with 6502 for forty years. I had to keep track of all of the labels and other metadata and store it in a very specific way. There are 16 sheets (starting at EDIT, MLedit, LB1 etc) that have the majority of the code, entered in columns C, D, and E (commands, parameters, comments). So if you just wanted to extract the code you could go to those 16 sheets and copy columns B (the address) through E and paste them into Notepad or some other text editor or spreadsheet and manipulate the code that way. Most of the rest of each of those sheets is converting the assembly language code into BASIC DATA statements and extracting the metadata from columns C, D, and E. The metadata gets stored in the sheets labeled Comments, LoBy, HiBy etc near the start of the spreadsheet in ascending order by address and bank number. Those sheets are also where all that data is converted to lines of BASIC. The last 30 sheets (starting with make-) assemble all of those BASIC lines together into something I could copy and paste into Notepad, and then copy into the emulator. These included short sections of code to save each file. I'd just copy and paste them into the emulator and they'd automatically run, storing and saving each file for me. Some of the code is wedged into the last available space on each bank. Out of the 121 kb I had budgeted for the program there is less than 300 bytes left so I had to cram kludges into some gaps in the lookup tables and wherever I could find space. A compiler program might have made it easier but there is no way it could make code as compact as I did, working with 16 files simultaneously. Those bits of kludged-in code were first programmed with the spreadsheet, the digital values recorded, and then those plugged back in wherever I needed to put them, and the code erased. So those chunks of code aren't immediately visible. There is no source code available for the file META/LIST.DAT. That file was written and saved from within the META/L editor. If you really want to look at it too, load it up ,8,1 and its starting location is 7000. However, everything is visible from within the editor itself. All of the subroutines appear in the editor exactly as they appear on the spreadsheet. The stuff in kludge space is readable too, but there's no commenting (or any other metadata) in any of those subroutines. They are all fairly short subroutines though, and their location is marked in the spreadsheet in the Labels sheet in the first several columns between rows 180 and 225, which is in pages B9-BC in bank FE, crammed in between default label names and function names. There are a few others scattered around on the first several sheets of the spreadsheet, added near the end of programming on an ad-hoc basis and crammed into whatever space I had available. The Labels sheet contains all of the labels I had set as default and the ones I had just used to write the editor itself, starting in row 380. But those are also all visible from within the editor, just load up the editor's metadata with META and then use LIST. I think in two of the videos I'm making for the playlist I'll go over some of the subroutines in low RAM.
  3. Some people have been asking for the source code. I didn't use a typical compiler to write this; it's a 15 Mb Libre Office spreadsheet. Here it is: https://github.com/edrobotguy/cx16/blob/master/MLeditor664final.ods
  4. Now live on GitHub, version 1.2.38.0664 of the META/L assembly language editor. https://github.com/edrobotguy/cx16/blob/master/METAL1_2_38_0664.zip If you down'oad the zip file, extract it into the same folder as your X16 rev 38 emulator. Then you'll find thorough documentation in docs/edit.html the video playlist is here:
  5. Now available on Github, version 1.2 of my assembly language editor. This is the native assembler you are looking for. Write your programs directly on the x16, save them, write programs in banked RAM too. https://github.com/edrobotguy/cx16/blob/master/METAL1_2_38_0664.zip This editor is a little different than most - it's an interpreter, in the same way that BASIC is an interpreter, rather than a compiler. That means there's no source code stored anywhere in RAM. The only source code is in VERA as it is being displayed. Your code is interpreted as you type it and stored in machine language and metadata, which is things like labels and comments and so on. The metadata is stored separately from your program. So when you're executing your code, it's the actual code. There's no stepping or breakpoints. This also means that you can load in already-compiled programs and read them - and add your own labels and comments to make it more understandable. I'm thinking of doing precisely that with David Murray's PETDRAW, converting it for the X16. There is also a non-standard program notation: every command has a unique four-character code. The first three are the same as the standard notation, and the fourth character indicates addressing mode. It might irk veteran 6502 programmers, but it doesn't take long to get the hang of it. I put every single "wouldn't it be nice if" that I could think of into this program. Have fun. Edited to add: Here's the video playlist; only two so far but more to come.
  6. I tried mounting the image file; Windows gave me an error message: "The disk image file is corrupted".
  7. This is a big problem I had when putting together my assembly language editor. The standard notation is ambiguous, you need to also look at the parameters to figure out what the command itself is. I''ve been using 4-character codes for the commands instead, so each one is unique. LSR doesn't just operate on the accumulator, it can also operate on an absolute memory address or absolute address indexed by X or zero page address or zero page address indexed by X. On my editor those commands are LSRI (the I is for Implied when operating on the accumulator), LSRA, LSRX, LSR0, and LSRZ respectively. After having used it for a while, I'm convinced the four character codes are a better notation.
  8. Have you considered replacing all of the decoding logic with a single small FPGA?
  9. Well, what I've come up with is 18 subroutines that handle 16 bit operations much like a Kernal call. I have set it up so that any two consecutive bytes in zero page can be a 16 bit register. So, for instance, to add the 16 bit value stored in 3C,3D to the 16 bit value stored in 1A,1B, the syntax would be: LDX# 3C LDY# 1A CLC JSR ADXY This adds the values and returns the low byte in X and high byte in Y, and affects the Z,C,N, and V flags the same way that ADC does. One can also use a sort of immediate mode. For instance, subtracting the hex value $4C1E from the 16 bit value stored in zero page addresses 4E,4F: LDA# 4E LDX# 1E LDY# 4C SEC JSRA SBA# Results stored in X= lo byte Y=high byte, and the Z,C,N, and V flags are affected the same way as with SBC. These subroutines are stored in Golden RAM as part of my upcoming update to my CX16 assembly language editor, but if people want I can post it here too, it's only 350 bytes.
  10. Hi I'm Ed Minchau. I started programming in 1981 on the Apple II and quickly bought myself a Commodore Vic-20. Due to financial difficulties, I ended up using that Vic20 until 1999 or so. As a result, I got a lot of practice programming in 6502 assembler. Oftentimes while I was in school taking FORTRAN77 or Pascal or C courses, I'd write the program first on the Vic in BASIC just to get the logic right and then translate it into whatever language I was studying! I've been spending the last ten months or so writing an assembly language editor for the Commander X16. Version 1.0 came out in January, version 1.1 came out in April, and the new and much bigger and vastly improved version 1.2 is nearly done.
×
×
  • Create New...

Important Information

Please review our Terms of Use