Assembly Environment V0.8 released

mjallison42 · Post by **mjallison42** » Mon Oct 05, 2020 9:43 pm

The Assembly Environment (V0.8) is released, you can get the beta here: https://sites.google.com/view/x16asmenv/home

I've also got a video about this release: https://youtu.be/adohtDGGPbE

This release is now the first to be considered "beta", since I believe it to be feature complete (based on original plans). From here on out I'll be fixing bugs and making it rom enabled.

Comments and bugs welcome!

mjallison42 · Post by **mjallison42** » Tue Oct 13, 2020 8:09 pm

V 0.81 has been updated to fix bugs in 0.80. Available at the google site.

vii · Post by **vii** » Sat Nov 14, 2020 1:11 pm

Hi! Great job so far. I started writing a program directly in the environment and realized I can insert, edit and delete lines of code, but I can't find a way to append a new line at the end of the code. Is there a key for that?

mjallison42 · Post by **mjallison42** » Sat Nov 14, 2020 4:54 pm

That is a UI limitation right now. While in ASSY mode, select the address you want to insert at, then insert instruction.

This is useful whenever you are attempting an edit outside of the program region.

I need to think about append some more.

BruceMcF · Post by **BruceMcF** » Sat Dec 05, 2020 7:08 am

On 11/15/2020 at 12:54 AM, mjallison42 said:

That is a UI limitation right now. While in ASSY mode, select the address you want to insert at, then insert instruction.

This is useful whenever you are attempting an edit outside of the program region.

I need to think about append some more.

I had a C64 editor that handled insert by opening up 256 bytes of space and when you were done, you had another command to close it up again. It filled the space with nulls That approach was faster while typing than autoinsert because it was always in overwrite mode.

It seems like a block insert space operation could be designed that also automatically acts as a program region extender, since a block insert would have to grow the program region in any event, to make room for the block insert ... so as long as it works for a "trailing region" of code of zero bytes, it would do double duty for adding space to the end of the program region.

TomXP411 · Post by **TomXP411** » Sat Dec 05, 2020 6:25 pm

11 hours ago, BruceMcF said:

I had a C64 editor that handled insert by opening up 256 bytes of space and when you were done, you had another command to close it up again. It filled the space with nulls That approach was faster while typing than autoinsert because it was always in overwrite mode.

It seems like a block insert space operation could be designed that also automatically acts as a program region extender, since a block insert would have to grow the program region in any event, to make room for the block insert ... so as long as it works for a "trailing region" of code of zero bytes, it would do double duty for adding space to the end of the program region.

This makes a lot of sense for assembly code, especially since the 6502 is so page-sensitive. Although filling the space with NOPs would make more sense than nulls.

For a standard text editor, the better choice is to copy the text from the main document to a line buffer. In the line buffer, your edit is never more than one line of text allows (let's just say 255 characters). The 8Mhz 6502 is plenty fast for inserting text in a 255 character block.

Then, when you press return, press an arrow key, or exit edit mode, the current line is copied back to the main text, with adjustments made for the length of the line, compared to the original.

TomXP411 · Post by **TomXP411** » Sat Dec 05, 2020 6:42 pm

On 10/5/2020 at 2:43 PM, mjallison42 said:

The Assembly Environment (V0.8) is released, you can get the beta here: https://sites.google.com/view/x16asmenv/home

I've also got a video about this release: https://youtu.be/adohtDGGPbE

This release is now the first to be considered "beta", since I believe it to be feature complete (based on original plans). From here on out I'll be fixing bugs and making it rom enabled.

Comments and bugs welcome!

Hi, Mike.

I've already run into problems trying to run the emulator... if you look at the attached file below (for some reason, I can't paste images into the forum now), the filenames are using graphic symbols. When I try to load them with the LOAD command, I get a file not found.

The interesting thing is that it actually loads if I type in the load command manually, typing the keys that match the graphic characters. (ie: LOAD "X16SA")

I fixed my local copy, but it would help if future versions of the IMG have the filenames in upper-case only format.

TomXP411 · Post by **TomXP411** » Sat Dec 05, 2020 6:54 pm

Also, in assembly mode, if I cursor down to the end of a screenful of text, the text doesn't scroll when I hit the bottom. Instead, the highlight disappears off the bottom of the screen.

I would expect the screen to scroll, perhaps when I'm 5 or so rows above the bottom, so I can "look ahead" of where the edit cursor is currently positioned.

It might also be nice to have a data mode as a part of the labeling system. When I move to zero page to look at the psuedo-registers, the system tries to disassemble the data there. It gets really confusing as I scroll through those values. Maybe when creating a label, you can offer a way to designate the label as a code, data space, with a couple of type settings (PETSCII and HEX at the very least).

I see you do have a .CSTR directive, which seems to work well enough when inside the program area... but not all (or even most) labels will be inside the user-created program. Many will be elsewhere in the system: KERNAL calls, I/O addresses, and zero-page address. Being able to inspect them as the proper data type would really help.

mjallison42 · Post by **mjallison42** » Sat Dec 19, 2020 6:45 pm

Use the "view mode" to examine defined labels. This shows all defined labels , even outside of the program region. It is missing the ability to define a label outside of the program region.

As for examining the 16 bit registers, the debug display shows those. You can not use assembly mode to look at those locations, you should use "view mode, memory" if you want to see the raw dump.

John Federico · Post by **John Federico** » Sat Feb 20, 2021 11:21 pm

The Assembly Environment looks great! I don't know if this is a bug, but I loaded x16skel.prg and then Watch->CStr. I ended up leaving it blank (because I wanted to back out of the prompt) and hit return, and then it starts running and eventually returns an "ERROR: 65C02 CPU REQUIRED!"

I wasn't doing anything serious. Just poking around. BTW, your video on this was great! Easy to follow the example. Worked fine!