6502.org

I'm finally getting around to some additional coding on my C02Monitor. I'm adding a simple assembler to compliment the disassembler. It will support all instructions and addressing modes of the WDC W65C02S CPU, so stuff like WAI, STP, SMBx, RMBx, BBSx, BBRx will also be in there. BTW - I don't have any set time frame for completing this.... but it's at least a work in progress.

However, I also wanted/needed to free up some additional ROM space as I'm trying to ensure that the Monitor stays within 6KB (6144 bytes). So... some minor changes to my CMOS version of Enhanced Basic was needed. The attached version requires a minimum of two BIOS functions; character in and character out. Beyond these, everything to Cold/Warm Start and run EhBasic is contained in the single source file. Additional ROM routines can be declared for LOAD, SAVE and EXIT. The LOAD and SAVE routines use the Xmodem-CRC support in my C02Monitor code. The code in Basic sets up all of the variables for the Xmodem transfer, then calls the Monitor code to transfer the data. EXIT simply calls the warm start vector for the Monitor. The required ROM routines are declared starting at line 529 in the source file.

There's a few extra updates in the code that shave some execution time from the previous version. The assembled and linked code is 10,126 bytes, so it's still less than 10KB (10240 bytes). I don't see me needing to add anything else to this code drop, unless Klaus finds and fixes some additional bugs in his maintained 2.22p5 version. Be aware however, that this version does use several of the newer CMOS instructions and address modes. These include instructions like SMBx, RMBx, BBSx, BBRx, so this will NOT run on a W65C816 in emulation mode.

For anyone using my recent CMOS version, I would recommend switching to this one. For anyone else interested in getting EhBasic working on their system, this version is likely going to be easier to integrate into any existing working system, as the separate monitor from the original is not required. Of course, this implies that you're using a 65C02 from WDC or Rockwell. Note that I've not tested on a Rockwell R65C02, only on the WDC CPU.

The Rockwell extensions' syntax comes in two flavors, and to date, I've yet to see either one declared as "standard." From the perspective of an assembler, separating the bit number from the mnemonic makes the instruction easier to parse and is in keeping with the three-letter mnemonics traditionally used with the 65C02.

Thirty years ago, I had a programming assignment of developing firmware for a terminal server powered by a 65C02. As part of the project, I scratch-wrote a machine language monitor to facilitate debugging. After considering both styles of encoding BBR, BBS, RMB and SMB, I decided to consider the bit as an operand, not part of the mnemonic. This decision came out of deciding how to use the instructions in symbolic assembly language.

I did the firmware development on a Commodore 128D interfaced to a Lt. Kernal hard drive subsystem. The assembler I used was the HCD65 assembler included with Commodore's DEVPAK-128. I was able to wangle a copy of the HDC65 source code from Fred Bowen at Commodore, so I modded the assembler to recognize 65C02 instructions and new addressing modes as valid. Due to the manner in which HCD65 parsed a line of code, it was necessary to make the bit number of a BBR/BBS/RMB/SMB instruction part of the operand. Hence BBR7 Imode,LAB_1913 would be written as BBR 7,Imode,LAB_1913. Otherwise, the assembler would choke on a four-character mnemonic. Aside from making it work, treating the bit number as a field in the operand allowed a symbol to be used in place of a hard-coded bit number.

Now, the funny thing was after I went through all that trouble to get the HCD65 assembler to digest the Rockwell extensions I never found any use for them. I found the TRB and TSB instructions more generally useful. Evidently, WDC though the same way, since they eliminated BBR, BBS, RMB and SMB from the 65C816.

For syntax on the various bit instructions, my current plan is to mimic how the WDC assembler handles them, e.g., BBR7 $01,$1002. Not sure how that will work out... as I'm just getting started on this and haven't fully figured out the initial parsing yet, but at least there's a plan. The Disassembler in my Monitor also displays them as show above, so hopefully I can keep the consistency with the assembler.

I've found the Rockwell (bit) extensions to be quite useful however. Both my Monitor and BIOS use them quite a bit and they can save memory and execution time as well. They make it easier to use a single page zero location for multiple flag bits where setting/resetting individual bits and conditional branching on them is simple. The TSB/TRB instructions are different, but I've not found a good use for them yet... but as I continue with my projects, I likely will... time will tell.

As for not including them on the 65C816, there just aren't enough opcodes to keep them when extending the instruction set for 16-bits. Then again, when WDC added WAI and STP (to the W65C02) it would have been nice to also add TXY, TYX instructions. Also on the wish list would have been JSR (addr,X) and perhaps another addressing mode or two for STZ. But alas... they didn't.

I'm sorry if this is the wrong thread for this, but i just wanted to ask how to actually use this...
please excuse my ignorance but i've never used any software made by someone else that wasn't already compiled or assembled...
especially since i never used an assembler similar to this.

I got a 65C02 in a logic simulator and wanted to try some actual software on it.
because it's simulated i can easily change the memory map and IO addresses for a keyboard and Terminal to whatever is needed by the software (if it's not easily changeable).

Hi Proxy,

So, the CMOS version I did is really a lot of changes and some streamlining of Lee's EnHanced Basic, which seems to be derived partly from MS Basic. The source code will need to be assembled and linked. I use WDC Tools, which is a free download and will run on Windows... I use Win7 in a VM, but XP should work as well... likely Win 10 as well.

If you look at the source, there are some monitor routines that need to be declared before assembling the aource. In short, you need two routines define at a minimum: one for character out and one for character in. If your Simulator has these input/output routines, just replace the ones that are there and you should be set.

Second, look at the page zero usage as well as the buffer and vector space. These are declared in the source along with the memory (RAM) start and end addresses. For my config, I use $0400 for vectors and input buffer, a RAM start address of $0800 and and a RAM end address of $8000.

Hopefully the above helps.... if not, please post details on your simulator, i.e., memory map, existing routines, page zero usage, etc. and I can probably modify the source and assemble/link a version that could work with your simulator. Cheers!

I tried to install the WDC Tools but it always gets stuck at "Target was appended to PATH", at the second try it says "Target is already in PATH. it will be removed and appended to PATH". i checked the path variable and it did add itself, but the string it added pointed to the wrong drive...? i told the program to install into "F:\HDD\wdc" but the path variable is "C:\WDC\tools\INCLUDE". that folder doesn't exist by the way...
even changing the installation directory to be in C:\WDC doesn't change anything, it still gets stuck.

i'm on Win10 and i got programs like WinCUPL and ATMISP running on this machine as well so i don't see why this one doesn't work.
where exactly do i replace those in the file? i did find "B_CHRIN_NW" and "B_CHROUT" but they just seem to be constants not actual functions. can i just delete those 2 lines and put my functions directly there? or do it via an external file?
i mean i assume it would as long as they have the same label, right?
it confuses me because it often mentions a BIOS/Monitor being located in ROM as well, probably because it expects a specific code being at those locations because it was made for that.
any specific reason it's at 0x0400? i think i saw it being the lowest thing in memory to be used (besides the stack and ZP), so why not put it directly after the stack at 0x0200? and then User RAM could also start earlier.
thanks, though i think there was a small misunderstanding, i literally just have the CPU (65C02), a variable Memory map, and a Terminal (ASCII input/output). there is absolutely no software running on the simulated system (which is why i wanted to try running EhBASIC in the first place), there is nothing else, no BIOS, Monitor, etc. so literally 100% of the memory can be used by BASIC.

plus as said i can change the memory map to whatever is needed, so i'll likely just have enough ROM to fit BASIC and make everything else RAM.

also why does BASIC start at 0xB000 when 0x8000 is said to be the start of the ROM? is it because of constants and strings that are stored before the code? that seems like a lot of space for some error messages...
overall i'm just a bit confused by the complexity of the file. i'm sorry for the constant confusion/questions the comments are helpful and i can understand parts of it
i know how the IO functions should look like but not where to place them. or how to assemble the whole thing for example.

Hi Proxy,

So, on the WDC Tools install. As this is a pretty old installer, it likely defaults to the C: drive only for appending the path information. As it's a pretty small app set, I would recommend you just install it and use all of the defaults. Otherwise, you'll have to modify the path information manually.

For the basic code itself. Note that the code is nothing but the basic interpreter itself. You need to provide the character in and character out routines for it to work. This means you need some callable routines that allow keyboard input to EhBasic and output to a display from EhBasic. The B_CHRIN_NW and B_CHROUT are routines that are provided by the BIOS on my C02 Pocket SBC. You need to replace these with the addresses of the equivalent routines for your terminal routines. These are in the Basic source starting at line 525. Just change the first two, as you don't have functions for Xmodem load and save or a Monitor to enter.

The memory map for my C02 Pocket SBC is what dictates where things are for my config. My C02 Pocket SBC has Page zero usage from $B0 - $FF in use for the BIOS and Monitor. Page $01 is the CPU stack. Page $02 is the FIFO buffers for the SCC2691 UART which is used for console input/output. Page $03 is used for vectors and buffers. As a result, the first open page on my memory map is $04. I also have pages $05 - $07 as reserved for future I/O expansion. This is why I start Basic RAM at $0800. I also have EEPROM that starts at $8000, so that's the top of available RAM for my config as well. If you have the ability to change the above parameters as your running an emulator, go ahead... just make sure you don't overwrite anything in Page $0 or anywhere else you have memory allocated.

As for the start of BASIC in ROM.... that's my choice. For the design and memory map of my C02 Pocket SBC, I use ROM from the top down and RAM from the bottom up. The Monitor has allocated space from $E000 - $F7FF (6KB) and the BIOS has allocated space from $F800 - $FFFF (2KB), but there are 5- I/O selects starting at $FE00 which are 32-bytes wide each. I used an ATF22V10 CPLD for glue logic. You might want to take a look at my github and take a closer look at C02 Pocket SBC.

One last thing to mention... the character input for EnHanced Basic needs to be non-waiting. In short, when the routine is called, it doesn't wait for a character to be entered... the carry flag is used on return for character entry, carry flag clear means no character entered, carry flag set means a character was entered. For ease of getting it working, I'd suggest leaving everything as it is. Just change the character input and output routines for equivalents in your terminal and jump to $B000 to enter Basic.

i did try that and it just gets stuck at PATH again. i don't understand why, it added it to path successfully, i can see it when i open the cmd and type in "echo %PATH%". even adding it manually in the system settings and running it again doesn't work.

i was able to get it to work on a Win7 VM. so i guess i'll just use that for now.
i wish i have the patience to convert the whole source code to use something like CustomASM instead so software like this doesn't have to rely on incredibly outdated assemblers.
then again i doubt anyone here would be willing to switch assemblers....
i knew that i had to my own functions, but what i don't know is where exactly to put them in the file... can i just literally write it where those 2 constants are? like this: that is my actual code, the B_CHROUT routine looks a bit too simple but that's just literally it.
i'm kinda tempted to just replace all "JSR B_CHROUT" instructions with "STA TERM" since that would be much faster.
anyways i was actually able to assemble it. though i had to add a TAB before the RTS instructions because the assembler thought it was supposed to be a label... *sigh*
the actual assembled file is 54k in size and i have no idea how that is supposed to fit into a ROM. there is like 44k of just empty space in there. i must be doing something wrong.
hmm i see, i thought it would be more universal, like you define your rough memory map at the start of the file, add your IO functions and then assemble it.
and i guess it still is like that but a bit more complex as it's pre-configured to a specific system so i don't exactly know what i can change without breaking stuff.
btw how much ROM does it even require when it's not set to leave empty space? would 16k be enough? the more ROM i can replace with RAM the better so i'd like to get rid of any unnecessary empty space in the ROM.
ye, the comments were useful in this one.
plus i looked at some other threads on here...

That is an easy one to fix, you need to space in the RTS to match the line above in the code. Anything hard to the left will be interpreted as a label rather than code. The assembler is seeing RTS as a label, used 3 times to match the 3 times you added it to your I/O routines.

yes i'm sorry, i found that out as well after a while and edited my comment.
personally i don't like that it defines a label by it's position rather than some special character like a colon.
also what's up with all of the indentation being made out of spaces instead of tabs? it makes it kinda hard to line stuff up properly.

You can translate the code to use another assembler you prefer.

Most of the work can be done with simple text replacements.

I have converted this same code to work with the ACME cross assembler for my project.

Hallo Proxy, Guten Abend!

So, installing WDC Tools. I also use Win7 in a VM under OSX. Chances are you're getting an error as the existing path length in Win10 is too long. I think there was a change in the absolute length of the PATH in later windows versions, making it longer. I think the installer grabs the PATH then attempts to append to and set it. Chances are it's too long which is causing the error.

As per my previous post... look at line 525. I declare the routine addresses there: So, swap out $FF36 for the address in your terminal, the same for $FF3C. Leave EVERYTHING else alone in the rest of the code. When assembling, the linker will create the output file, but if you're using my basic.wdc file, it creates a Motorola S-Record file, which will be about 28KB. Not sure what file you're looking at... can you share your modified .asm file and generated output files? Also note that my basic.wdc file shows file paths to a Z: drive, which is shared from my OSX system via VMware Fusion, so you'll probably have to modify this file for your system paths.

Beyond the above, it shouldn't too difficult to get this working. Can you post your modified files here? I can always do a quick assemble/link for you. Also, exactly what file format do you need to upload to your emulator??

PS- Where in Germany are you? I lived in Reutlingen for a couple years... and have been traveling to Germany and all of Europe for decades.

I hope you aren't trying to reignite an old war ... https://www.youtube.com/watch?v=SsoOG6ZeyUI ... BTW, I'm usually a spacer, but try to adapt to the environment

The most annoying thing is that the assembler doesn't expand tabs into spaces in the listing so tabbed source ends up all wonky. It also indents normal lines and directives one space differently so even spaced source is wonky in the listing.

You can't win.