Denial

Posted: **Sun Jan 28, 2024 7:49 am**

https://sleepingelephant.com/ipw-web/bu ... 6&start=20

in another thread, Wilson wrote:I've been working on my own assembler [...]

That seems to be MONster, which Bryce hosts on github:

Wilson wrote:MONster is an all-in-one editor/assembler/debugger for the Commodore Vic-20. The design philosophy is uncompromising maximalism. This is the polar opposite of most existing Vic-20 assemblers, which, though impressive in their own right, are mostly designed with memory efficiency in mind. Virtually any feature that I deem valuable in an editor/assembler is included.

[...]

For now MONster requires a Final Expansion to function. It could easily be modified for other 512k+ carts. Much of this RAM is used to store the multiple source code buffers (up to eight), but it is also used to store debug info and some code.

The banked memory allows the user program to execute in almost complete isolation. This means that, although this environment consumes a vast amount of memory itself, everything except address $9c02 (the bank select register) is preserved when control moves between the editor and the user program. Moreso even than small monitor cartridges, the program itself is virtually unaware of the resident tooling.

I just happened to stumble across that project a few days ago and already spent considerable time on one evening to do my first steps in it (with the FE3 emulated in VICE). I could successfully assemble the "Hello World" program and run it.

Bryce, any chance you want to comment on this?

I already have a question regarding the keyboard layout of the text editor: as the text you process seems to be encoded as 7-bit ASCII, is it possible you support the keyboard layout I devised some time ago for MG TEXT EDIT?

Code: Select all

          backslash  \   92  Pound
              caret  ^   94  Arrow Up
         underscore  _   95  Shift Minus
       grave accent  `   96  Arrow Left
 curly bracket open  {  123  Shift @
       vertical bar  |  124  Shift Pound
curly bracket close  }  125  Shift *
              tilde  ~  126  Shift Arrow Left

(you seem to use Arrow-Left as ESC key ... perhaps the STOP key could serve the same purpose instead?)

I wrote a driver that does this keyboard mapping and already does upper/lower-case letters right, here:

https://sleepingelephant.com/ipw-web/bu ... 91&start=4

When working with VICE VDrive (TDE off, Virtual Device traps on) in a PC directory, I encountered some problems when trying to save texts, an empty file is opened but the editor just writes "SAVING..." and then locks. I'll try to understand what is the issue here to give you a more qualified bug report.

Greetings,

Michael

Posted: **Tue Jan 30, 2024 8:40 pm**

Aha, I've been found!

Yes, this has been a "little" project of mine for quite a while. The veritable embodiment of scope creep. As its name implies, this project originated as a symbolic monitor, then a TASM (or VASM) like editor/assembler. The RAM requirements kept growing, and when I broke the 32K barrier, I guess it felt like I had to find a use for it all hehe

At this point, I'm mostly done adding features and primarily working on stability and bugfixes. To be honest, there's a lot of work left to do there. There are also a quite a few things that do work, but which I'd like to reimplement a little better.
Assembly was probably a bold choice for this, in hindsight, but making it has been for my own joy as much as anything

Mike wrote:I already have a question regarding the keyboard layout of the text editor: as the text you process seems to be encoded as 7-bit ASCII, is it possible you support the keyboard layout I devised some time ago for MG TEXT EDIT?

Ah, definitely! Should be easy to support those characters.

Mike wrote:When working with VICE VDrive (TDE off, Virtual Device traps on) in a PC directory, I encountered some problems when trying to save texts, an empty file is opened but the editor just writes "SAVING..." and then locks. I'll try to understand what is the issue here to give you a more qualified bug report.

Very believable. I haven't made any effort to test VDrive yet. I use a SD2IEC for testing on real hardware and try to test with TDE to make sure its 1541 compatible. But I'm just using the KERNAL I/O routines (maybe a little jankily), so it should be attainable.

Thanks for the spotlight- I might as well post some updates now that the cat is out of the bag

Posted: **Mon Jan 20, 2025 8:15 am**

I posted a couple video updates on Youtube of this project. A few people, surprisingly, found one or two of them, but they've more or less been logs for my own sake. Here's the latest one; I may as well share.
Video

It's been fun making the videos, but forgive my nonexistent skills in that medium...it's a little rough

I've made a ton of progress on this since almost a year ago when this thread was started. The video goes over some of the highlights: visual mode (copy/paste), the new monitor TUI, the ability to step through ROM code, and a UDG editor for defining character sets. The video ends with a demo of a more substantial program than I've shown yet. I admit I was pretty surprised myself that I was able to assemble it without any issues as I hadn't tested anything near that scale before.

I also made an installer, so if you have a FE3 you can install this program onto it (in place of the stock firmware) and boot right into it. I don't recommend this yet, because version 1.0 is still very much in development.

There's a lot more to show off. The README is reasonably up to date with features, but I will try to make more posts/videos to highlight some of the big changes.

I already have a question regarding the keyboard layout of the text editor: as the text you process seems to be encoded as 7-bit ASCII, is it possible you support the keyboard layout I devised some time ago for MG TEXT EDIT?

I implemented all of these except '~'. After using a custom keyboard routine for some time, I ended up switching back to the KERNAL one, which doesn't seem to support SHIFT-left arrow?

I'm doing some kind of weird things with the keyboard logic (like injecting keys into the KERNAL's key list at times), so switching back to a custom key routine is slightly more work than using a drop-in-replacement. Definitely open to that though!

(you seem to use Arrow-Left as ESC key ... perhaps the STOP key could serve the same purpose instead?)

This is done!

When working with VICE VDrive (TDE off, Virtual Device traps on) in a PC directory, I encountered some problems when trying to save texts, an empty file is opened but the editor just writes "SAVING..." and then locks. I'll try to understand what is the issue here to give you a more qualified bug report.

Shockingly I've been unable to get the virtual drive working with even the stock KERNAL and the most basic test cases you can imagine.

I used it years back so not sure what I'm doing wrong...would like to support it in this project, but it is low priority so long as real devices work.

Posted: **Mon Jan 20, 2025 8:47 am**

Mike wrote:I already have a question regarding the keyboard layout of the text editor: as the text you process seems to be encoded as 7-bit ASCII, is it possible you support the keyboard layout I devised some time ago for MG TEXT EDIT?

Wilson wrote:I implemented all of these except '~'. After using a custom keyboard routine for some time, I ended up switching back to the KERNAL one, which doesn't seem to support SHIFT-left arrow?

This is the wedge I hook into the keyboard decode vector at $028F to redefine the keys for a true ASCII keyboard:

Code: Select all

REM>KeyboardSrc
:
DIM code 256
:
FOR pass=4 TO 7 STEP 3
P%=&3F00-2:O%=code
[OPT pass
 EQUW P%+2

 LDA #Keyboard MOD 256:STA &028F
 LDA #Keyboard DIV 256:STA &0290
 RTS

.Keyboard
 LDA &028D:ASL A:CMP #&08:BCC Keyboard_00:LDA #&06
.Keyboard_00
 TAX
 LDA Keyboard_01,X  :STA &F5
 LDA Keyboard_01+1,X:STA &F6
 JMP &EB74
.Keyboard_01
 EQUW Keyboard_02
 EQUW Keyboard_03
 EQUW &ECE0
 EQUW &EDA3
.Keyboard_02
 EQUB &31:EQUB &33:EQUB &35:EQUB &37:EQUB &39:EQUB &2B:EQUB &5C:EQUB &14
 EQUB &60:EQUB &77:EQUB &72:EQUB &79:EQUB &69:EQUB &70:EQUB &2A:EQUB &0D
 EQUB &04:EQUB &61:EQUB &64:EQUB &67:EQUB &6A:EQUB &6C:EQUB &3B:EQUB &1D
 EQUB &03:EQUB &01:EQUB &78:EQUB &76:EQUB &6E:EQUB &2C:EQUB &2F:EQUB &11
 EQUB &20:EQUB &7A:EQUB &63:EQUB &62:EQUB &6D:EQUB &2E:EQUB &01:EQUB &85
 EQUB &02:EQUB &73:EQUB &66:EQUB &68:EQUB &6B:EQUB &3A:EQUB &3D:EQUB &86
 EQUB &71:EQUB &65:EQUB &74:EQUB &75:EQUB &6F:EQUB &40:EQUB &5E:EQUB &87
 EQUB &32:EQUB &34:EQUB &36:EQUB &38:EQUB &30:EQUB &2D:EQUB &13:EQUB &88
 EQUB &FF
.Keyboard_03
 EQUB &21:EQUB &23:EQUB &25:EQUB &27:EQUB &29:EQUB &2B:EQUB &7C:EQUB &94
 EQUB &7E:EQUB &57:EQUB &52:EQUB &59:EQUB &49:EQUB &50:EQUB &7D:EQUB &8D
 EQUB &04:EQUB &41:EQUB &44:EQUB &47:EQUB &4A:EQUB &4C:EQUB &5D:EQUB &9D
 EQUB &83:EQUB &01:EQUB &58:EQUB &56:EQUB &4E:EQUB &3C:EQUB &3F:EQUB &91
 EQUB &20:EQUB &5A:EQUB &43:EQUB &42:EQUB &4D:EQUB &3E:EQUB &01:EQUB &89
 EQUB &02:EQUB &53:EQUB &46:EQUB &48:EQUB &4B:EQUB &5B:EQUB &3D:EQUB &8A
 EQUB &51:EQUB &45:EQUB &54:EQUB &55:EQUB &4F:EQUB &7B:EQUB &5E:EQUB &8B
 EQUB &22:EQUB &24:EQUB &26:EQUB &28:EQUB &30:EQUB &5F:EQUB &93:EQUB &8C
 EQUB &FF
]
NEXT
:
OSCLI "Save driver &"+STR$~code+" &"+STR$~O%

It uses the original keyboard scanner in the KERNAL, however the decode tables for the unshifted and shifted keys have been changed to directly deliver ASCII values - no further conversion is necessary. The tables also provide the necessary differentiation between '<-' and Shift-'<-', which then return the ASCII codes 96 (for the grave accent `) and 126 (for the tilde ~), respectively.

In .Keyboard_01, the entries for C= and Ctrl qualified keys still point to the ROM originals (C= keys ^= $ECE0, Ctrl keys ^= $EDA3)

Posted: **Mon Jan 20, 2025 8:51 am**

It uses the original keyboard scanner in the KERNAL, however the decode tables for the unshifted and shifted keys have been changed to directly deliver ASCII values - no further conversion is necessary. The tables also provide the necessary differentiation between '<-' and Shift-'<-', which then return the ASCII codes 96 and 126, respectively.

Ahh, very cool! I will check this out. At this point, memory is very tight (even with 512k haha), but I'll experiment with squeezing this in.
At the moment, I'm using a wrapped version of the get-key routine that does a few conversions, which is lightweight if a bit limited.

Posted: **Tue Apr 08, 2025 3:01 pm**

I've done a lot more work on this since the last update. Most notably, the debugger has been almost entirely rewritten.

Instead of relying on a combination of software interrupts (BRK) and 1-cycle timer based NMIs, steps are now simply performed by copying the instruction to an execution buffer (in the "user" bank) where it is executed safely before control jumps back to the debugger.

This technique is similar to what Woz's Apple II monitor does. Because the user has a full dedicated bank for their program, memory values in that bank are untouched by the debugger. However, the "internal" memory, $00-$400, $1000-$2000, and I/O + color memory (approximately everything in $9000-$9600), needs to be saved/restored before/after each step.

Since I was already simulating much of the 6502's operation, the effective address was readily available, so it was easy to check if it is within one of these internal ranges and save/restore it if so. The indirect addressing modes complicate this. One option for these would have been to save/restore both the base address and effective address, but since the effective address is already known, I chose to simply rewrite these instructions with their absolute counterparts instead.

For example, if the value of the .Y register is $00 and the contents of memory locations $00,$01 are $10,$20. We look up the effective address at ($00)+$00, which is $2010

Code: Select all

LDA ($00),Y -> LDA $2010

As with Woz's monitor, the control flow instructions are simply emulated. Even relative branches are emulated (unlike in the Apple II emulation), again because the debugger already has enough info to know if the branch will or won't be taken.

Beyond the debugger, I fixed a ton of bugs. I was able to assemble and debug some fairly large programs I wrote some years back, which was cool and somewhat surprising.

A lot more work remains of course. I've pretty much finished all the features planned for v1, but I am continuing to test and bugfix.

--

Last weekend I hosted a combination birthday party / release party to celebrate the first alpha release. I had a lot of friends show up in support, which was very sweet of them considering none of them had any idea what the hell this is other than it being important to me.

Here are some pics from the night

Posted: **Sat Apr 12, 2025 7:13 pm**

OUTSTANDING, Wilson! Keep on doing what you love, and it is great you have friends who support you, even if they aren't "VIC-o-maniacs" such as we!

(I'll DM you next time I am in The City, and maybe I can buy you a cup of joe.

) -OGM

Posted: **Sun Apr 13, 2025 8:26 am**

Thanks for that, Orangeman! Will definitely keep it up!

I've begun adding binaries to the releases (as of writing v0.1.3a is the latest), so the barrier to entry should be low for anyone that wants to play around with it. Just be warned that you will encounter bugs!

Just download the monster.bin file and run:

Code: Select all

xvic -ntsc -cartfe monster.bin

to start it.

The PAL release is slightly broken right now; I'll have that fixed very soon. If you're wondering how a program like this could possibly be so timing sensitive as to require separate PAL/NTSC versions: raster splits are used for per-line coloring. The reversed lines in the screenshot above are actually accomplished with $900f writes.

Mike wrote:When working with VICE VDrive (TDE off, Virtual Device traps on) in a PC directory, I encountered some problems when trying to save texts, an empty file is opened but the editor just writes "SAVING..." and then locks. I'll try to understand what is the issue here to give you a more qualified bug report.

Finally, some good news on this front, VDrive seems to be working for me again.

So hopefully I can get it working soon!

Denial

MONster 6502 full IDE and Debugger on FE3

MONster 6502 full IDE and Debugger on FE3

Re: MONster 6502 full IDE and Debugger on FE3

Re: MONster 6502 full IDE and Debugger on FE3

Re: MONster 6502 full IDE and Debugger on FE3

Re: MONster 6502 full IDE and Debugger on FE3

Re: MONster 6502 full IDE and Debugger on FE3

Re: MONster 6502 full IDE and Debugger on FE3

Re: MONster 6502 full IDE and Debugger on FE3