6502.org

Posted: **Thu Jun 11, 2020 3:02 am**

Well, decades ago I used tabs in my source code... and it generally worked out okay. This was using the old IBM Macro Assembler Package and an (IBM) internal editor back in the 80's. I got back into the 65(C)02 about 7 years ago and was also using tabs, but the listing file could look a bit wonky. About 2 years ago I started reformatting ALL of my code back to spaces. It's helped a lot for listing files and even source. It also helps when I used the code brackets here on the forum. It did take some time to change it all, but I'm happy I did.

Posted: **Thu Jun 11, 2020 4:24 am**

thedrip wrote:

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.

the main problem is that CustomASM uses colons to indicate labels. so i need to go through the whole file manually... i could probably detect labels and add a colon with regex but that's black magic to me.

GARTHWILSON wrote:

Now that we have loads more memory and disc space, I set my programmers' text editor to put in spaces when I hit the tab key, because tabs get really messed up when I copy and paste into forum posts.

that's because tabs are broken on the forum, they are converted to exactly 3 spaces when posting, which is not how tabs are supposed to work.... also tabs are supposed to be 4 spaces

Code: Select all

	b
a	b
aa	b
aaa	b

all of the b's should be in one row, it even shows that when i type it, but the preview and actual post messes it up.

floobydust wrote:

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.

but if it's too long how was it able to add itself to path successfully? because that is exactly what happend, it added itself to PATH like it should and then just stopped...

Code: Select all

C:\Program Files (x86)\Common Files\Oracle\Java\javapath;
C:\Windows\system32;
C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\Windows\System32\OpenSSH\;
C:\WINDOWS\system32;
C:\WINDOWS;
C:\WINDOWS\System32\Wbem;
C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
C:\WINDOWS\System32\OpenSSH\;
C:\Program Files\Oracle\VirtualBox;
C:\Program Files (x86)\ZeroTier\One\;
C:\WINDOWS\system32;
C:\WINDOWS;
C:\WINDOWS\System32\Wbem;
C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
C:\WINDOWS\System32\OpenSSH\;
C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\WDC\Tools\LIB;
C:\WDC\Tools\INCLUDE;C:\Users\nnnnn\AppData\Local\Microsoft\WindowsApps;F:\FPGA Stuff\Quartus\modelsim_ase\win32aloem;
Z:\WinCUPL\WINCUPL\EXE;
Z:\WinCUPL\WINCUPL\FITTERS;
Z:\MinGW\bin;

you can see it near the end of my PATH variable. right after "PhysX".

floobydust wrote:

As per my previous post... look at line 525. I declare the routine addresses there:

Code: Select all

; stuff

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.

what exactly do you mean with "the address in my terminal" though? what should i swap it with? do you mean the IO Address of the keyboard and Terminal?
as said before there are no existing functions that i could call. there is no Monitor or BIOS program on it.
I could add a second ROM with the IO Functions but I thought it would be easier to just add them to BASIC directly and avoid having to use 2 separate ROMs

floobydust wrote:

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??

ouch that first sentence hurt a bit. :p
the format is a simple .BIN file. the same you could program onto an EEPROM or FLASH chip.
the only thing i modifed were the functions i showed in the picture, i didn't touch anything else.
though it might also be because of the commands i gave to the assembler? there was no BAT file to assemble the whole thing so i just copied the one from the "8LED_CCAH" thing that is included by WDC by default and modifed it to use the basic.ASM file instead.
this is what is inside the .BAT file:

Code: Select all

del *.bin
del *.obj
del *.lst

WDC02AS -g -l -DUSING_02 basic.asm
WDCLN -g -HB basic
pause

i checked with the cmd to see there were options to tell it where ROM begins but i was unable to get that working

floobydust wrote:

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.

Neubrandenburg, basically near the top right corner of Germany.

Posted: **Thu Jun 11, 2020 7:12 am**

Proxy wrote:

that's because tabs are broken on the forum, they are converted to exactly 3 spaces when posting, which is not how tabs are supposed to work.... also tabs are supposed to be 4 spaces

You may find that half the planet disagrees with you there and will insist on tabs being 8 spaces. Then the other half will say to never use tabs and always use spaces (e.g. the Pythonistas) Then the Makefile and old C enthusiasts will violently disagree with you. When I learned to type (1975 ish) we moved little mechanical stops on the bar on the typewriter but they were invariably set to every 8th column.

I'm going to go with Postel's law, c1981. Be conservative in what you do, be liberal in what you accept from others

-Gordon

Posted: **Thu Jun 11, 2020 7:28 am**

drogon wrote:

Proxy wrote:

that's because tabs are broken on the forum, they are converted to exactly 3 spaces when posting, which is not how tabs are supposed to work.... also tabs are supposed to be 4 spaces

You may find that half the planet disagrees with you there and will insist on tabs being 8 spaces. Then the other half will say to never use tabs and always use spaces (e.g. the Pythonistas) Then the Makefile and old C enthusiasts will violently disagree with you. When I learned to type (1975 ish) we moved little mechanical stops on the bar on the typewriter but they were invariably set to every 8th column.

I'm going to go with Postel's law, c1981. Be conservative in what you do, be liberal in what you accept from others

-Gordon

Huh I didn't know that historically it was/is 8. Personally that seems excessive, I wouldn't go over 4... plus that's the default in NP++.
But yea i see the problem. With spaces it's atleast somewhat universal.
But even then people can still disagree on how many to use for indentation.
Personally I would go for 4 again.

Posted: **Thu Jun 11, 2020 7:32 am**

Yeah, the commercial text editors I've used tabbed to every 8th column, so multiples of 8, plus 1 (since the first column is column 1, not column 0), so you get 1, 9, 17, 25, 33, 41, etc.. When I wrote a rather full-featured text editor for my HP-71 hand-held computer, I made it so the first line of the file (commented-out if for programming) to optionally hold a list of tabs, so you could do it like the typewriters. In the second year of high-school typing, we'd set the tabs for the appropriate columns for when we were typing up spread-sheet kind of stuff. This was when most of us had never seen a computer. Some columns would be wider than others, for example,

Code: Select all

Qty | Description                  | mfr   | part nr   | due date | price each
----+------------------------------+-------+-----------+----------+-----------
  2 | upsie-downsie gizmo, short   | ACME  | 123456    | 10/4/76  | $  15.49
  7 | pink frappus                 | Hokie | 789       | 10/8/76  | $   9.70

(Pardon the made-up names.) The tabs could be set according to what went in the various columns, not needing to be at regular intervals. When the mass of the spring-loaded typewriter carriage would hit one of the tabs, which were literal tabs of metal that you'd raise or lower, it seemed like something would eventually break! (It never did though.) I didn't like typing this stuff. It was easier when we were doing things like business letters that were just prose.

Posted: **Thu Jun 11, 2020 9:11 am**

Proxy wrote:

Personally I would go for 4 again.

It's nice to have choice.

I know of 2 programming languages that insist not only on spaces, but also ones that make indentation significant. The first is OCCAM (late 1980s) where an indentation level refers to a group of instructions that are to be performed sequentially rather than concurrently/in parallel and the other is Python where they substitute indentation for begin/end, { & } type block constructs. (and insist on spaces, ASCII 32 rather than TAB ASCII 9).

Makefiles insist on a hard TAB (ASCII 9) and a very common "mistake" newcomers to Make make is copy & past when the terminal they copy from has 8 spaces rather than a single TAB. It looks right, but doesn't work.

So these examples all break the be liberal in what you accept rule and "holy wars" have been (and will be) fought over their ideals of right and wrong. C doesn't care - all TABs are spaces.

"Classic" C is all 8-space/TAB indented and the Linux kernel has maintained this standard (although they have just relaxed the 80column rule AIUI!) Here is an example:

https://github.com/torvalds/linux/blob/ ... -example.c

In a way it encourages a more modular approach - as you introduce more and more TABs, then your available code writing space gets smaller and smaller, so it then makes sense to break that out into a separate function.

We each have our own personal standards and ideals though, and long may this continue - I prefer 2 spaces for higher level code (BASIC, C, BCPL), and the last editor I wrote I made the TAB key indent to the same as the line above and then to the next 2-space multiple after that. The other bit of laziness I coded in to that editor was that BACKSPACE immediately after a TAB would take me back to the previous 2-column boundary, so un-indenting became easy too.

The only time I use 8 spaces is in assembler. There are (probably) older brain cells in my noggin fused into that methodology than my newer 2-column ideal though!

Also, since we're in EhBASIC - one thing to note - the very early BASICs often did preserve spaces, but the early "micro" BASICs stripped them out at entry/tokenisation time (RAM was expensive), so trying to structure them was almost impossible. (I've seen people using colons to indent to overcome this - at the expense of execution speed!)

-Gordon

Posted: **Thu Jun 11, 2020 1:36 pm**

Proxy,

First, I was simply suggesting that you might have a path length problem. I don't use Win10... don't have a copy/license of it, nor do I have any future intention or need for it. For what little need I have for a Windows OS, Win7 works. If you've been able to get WDC Tools installed in a Win7 VM, then you should have a working environment.

It's becoming more clear that I don't know what you're attempting to run EhBasic on. Perhaps you can give me some detail on what it is and what hardware I/O it has. You mention a keyboard and terminal... exactly what do you mean by that??

Note that I referred you to look at my C02 Pocket SBC project. You can see what the hardware is, what routines are provided by the BIOS and Monitor code and how everything works... all hardware and software details are there... schematics, PCB layout, CPLD code, all source code, etc.

The standard version of EhBasic (which Klaus has been maintaining) also includes a simple console which supports a 6551 Async controller configured as a serial terminal. In short, you need to have a console to interact with. The CMOS version I worked on is more streamlined... uses several CMOS instructions, is smaller, uses less page zero space, etc., but it requires at a minimum two routines; one to get character input from a keyboard and a second one to send character output to a display.

Happy to help you get it running, but I need to know exactly what your hardware (physical or emulated) is.. and at a detailed level.

Posted: **Thu Jun 11, 2020 4:00 pm**

In my old typography manual that I inherited from my step-father—his career was in the printing industry—it is noted that a tabulation is eight spaces, regardless of character pitch. The copyright date on this manual is 1947.

The fact that a tab is eight characters has had an influence on assembly language source code structure. In the days of punch cards, the assembler expected the fields in each line of code to align with certain tab stops. The label or symbol had to start at position 1 on the line. The mnemonic had to align with the first tab stop, the operand with the second tab stop and the comment with the tab stop following the operand. If fields ended up on the wrong tab the line of code wouldn't assemble.

Since the first tab stop was eight characters in from the start of the line, the label/symbol could be no more than six characters to avoid running into the mnemonic. That six-character limitation was present in many early 6502 assemblers (Commodore's MADS for the C-64 was one such assembler) and made for some interesting label and symbol name choices.

Posted: **Thu Jun 11, 2020 4:24 pm**

drogon wrote:

Makefiles insist on a hard TAB (ASCII 9) and a very common "mistake" newcomers to Make make is copy & past when the terminal they copy from has 8 spaces rather than a single TAB. It looks right, but doesn't work.

What makes it even more interesting is that the standard ASCII control character set includes <FS> ($1C), which means "field separator." On a real ASCII keyboard (not the standard PC keyboard), <FS> would be entered by typing [Ctrl-\], which is much less convenient to type than [Tab].

Quote:

So these examples all break the be liberal in what you accept rule and "holy wars" have been (and will be) fought over their ideals of right and wrong. C doesn't care - all TABs are spaces.

I've always opined "be liberal in what you accept" was a somewhat flawed concept, as it is in contradiction with the notion of establishing a standard. If one is being liberal in accepting most anything as input then there is no incentive to adhere to a published standard. Imagine if the "be liberal in what you accept" philosophy were applied to ASCII...

Posted: **Thu Jun 11, 2020 4:55 pm**

floobydust wrote:

Proxy,

First, I was simply suggesting that you might have a path length problem. I don't use Win10... don't have a copy/license of it, nor do I have any future intention or need for it. For what little need I have for a Windows OS, Win7 works. If you've been able to get WDC Tools installed in a Win7 VM, then you should have a working environment.

looking into the registry the PATH variable is 622 characters long. 659 with the "C:\WDC\Tools\LIB;C:\WDC\Tools\INCLUDE" that WDCtools Adds. so it's not a PATH length problem. there must be some other strange incompatibility.
ohg whatever, atleast i got it working on a VM to assemble anything at all... even if it's slow.

floobydust wrote:

It's becoming more clear that I don't know what you're attempting to run EhBasic on. Perhaps you can give me some detail on what it is and what hardware I/O it has. You mention a keyboard and terminal... exactly what do you mean by that??

yes i'm sorry, lets just get this straight.

this right here is the whole circuit.
it also has the Memory Map and IO Devices explained in the bottom left.
some more detail about the 2 IO Devices, the Terminal and Keyboard.

The Terminal is located at 0xDF00 and when writing to it it simply takes the byte (hopefully ASCII) and puts it on the screen from left to right.
it accepts special characters like Backspace, LF (Line Feed) and CR (Carriage Return), though sending both will make it go down 2 rows. so it's recommended go with just either and not both. sincet he Keyboard uses LF it's best to also just use a single LF character. it's in line with most Terminal software as well (if you use this on an actual 65C02 and use a Serial connection i mean)
also it's Amber colored because if you got a Monochrome display you might as well make it the best possible color!

The Keyboard is also rather simple, it's located at 0xDF00 as well and reading from it will just put the an ASCII character from the Buffer into the CPU and remove it from the Buffer, it also handles special characters like Backspace, or Return (which always turns into a single LF character like most Linux and UNIX systems).

0xDF01 is just connected to the "available" pin on the keyboard, which just indicates that anything was typed into it.

the actual Memory map and locations of the IO Devices depend on the 16 bit constants you can see on the screenshot. so it's completely arbitrary and i can change it to whatever is needed.
the current setup you see is identical in function to my 65C02 SBC.

floobydust wrote:

Note that I referred you to look at my C02 Pocket SBC project. You can see what the hardware is, what routines are provided by the BIOS and Monitor code and how everything works... all hardware and software details are there... schematics, PCB layout, CPLD code, all source code, etc.

The standard version of EhBasic (which Klaus has been maintaining) also includes a simple console which supports a 6551 Async controller configured as a serial terminal. In short, you need to have a console to interact with. The CMOS version I worked on is more streamlined... uses several CMOS instructions, is smaller, uses less page zero space, etc., but it requires at a minimum two routines; one to get character input from a keyboard and a second one to send character output to a display.

Happy to help you get it running, but I need to know exactly what your hardware (physical or emulated) is.. and at a detailed level.

again sorry for being vague with everything. i hope the explaination above shows a bit more how the system works.

.

now, i need to know how to exactly assemble this. the ROM will end at 0xFFFF and start at whatever is needed to fit all of BASIC and the IO Functions.
so what should go into the .BAT file for this?
or is there another step i'm missing here?

Posted: **Fri Jun 12, 2020 4:15 am**

Hi Proxy,

Regarding WDC Tools running in a Win7 VM... not sure what you mean by slow... the Enhanced Basic code assembles and links in under 2 seconds on my Win7 VM. I would question anything that takes over 4-5 seconds, but I don't know any details on your VM environment.

The 65C02 environment you're running this on: Okay, that tends to make some sense now. You basically have a single address acting as an I/O port for read and write. To use this for anything useful, you'll need to write a couple simple routines. One routine will simply take the contents of the A reg (accumulator) and write it to the I/O port, then return. The other routine would need to load the keyboard status port, check for bit 0 and then either set or clear the carry flag and optionally load the A reg with the character from the I/O port, then return.

For the B_CHROUT routine it might look like:

Code: Select all

        STA    $DF00    ;Send the character to the terminal
        RTS             ;Return

For the B_CHRIN_NW routine it might look like:

Code: Select all

         LDA    $DF01    ;Get keyboard status
         LSR    A        ;Shift into the Carry flag
         BCC    EXIT     ;If clear, just exit
         LDA    $DF00    ;Else, get the character from the keyboard
EXIT     RTS             ;Return

The assembled/linked code is about 9KB, so your memory map should probably change to accommodate the required space. It's possible to run the code from RAM, but if something goes wrong, the code could get overwritten. You also need to define the processor startup vector to a routine that initializes the system before jumping to the start of the Basic code. The init would include setting the stack, possibly clearing decimal mode, zeroing out some variables perhaps, etc.

As for what to put in a batch file... you should reference the assembler and linker documentation. I still use TIDE to kick all of that off. Granted, it's on the buggy side, but I have a .WDC file that contains the parameters for TIDE to assemble and link the code and outputs a listing file, object file and a S-record (S19) file for the code I either load into my EEPROM burner or can download to my SBC using Xmodem-CRC.

Posted: **Fri Jun 12, 2020 3:43 pm**

floobydust wrote:

Hi Proxy,

Regarding WDC Tools running in a Win7 VM... not sure what you mean by slow... the Enhanced Basic code assembles and links in under 2 seconds on my Win7 VM. I would question anything that takes over 4-5 seconds, but I don't know any details on your VM environment.

i meant that my Windows 7 VM is slow, not WDCTools.

floobydust wrote:

The 65C02 environment you're running this on: Okay, that tends to make some sense now. You basically have a single address acting as an I/O port for read and write. To use this for anything useful, you'll need to write a couple simple routines. One routine will simply take the contents of the A reg (accumulator) and write it to the I/O port, then return. The other routine would need to load the keyboard status port, check for bit 0 and then either set or clear the carry flag and optionally load the A reg with the character from the I/O port, then return.

For the B_CHROUT routine it might look like:

Code: Select all

        STA    $DF00    ;Send the character to the terminal
        RTS             ;Return

For the B_CHRIN_NW routine it might look like:

Code: Select all

         LDA    $DF01    ;Get keyboard status
         LSR    A        ;Shift into the Carry flag
         BCC    EXIT     ;If clear, just exit
         LDA    $DF00    ;Else, get the character from the keyboard
EXIT     RTS             ;Return

thank you but i did already write some functions, on page 2 in this thread near the middle.
though i used a BIT instruction instead of just shifting bit 0 into the Carry. that's clever.

floobydust wrote:

The assembled/linked code is about 9KB, so your memory map should probably change to accommodate the required space. It's possible to run the code from RAM, but if something goes wrong, the code could get overwritten. You also need to define the processor startup vector to a routine that initializes the system before jumping to the start of the Basic code. The init would include setting the stack, possibly clearing decimal mode, zeroing out some variables perhaps, etc.

yea i'll just expand the ROM to 16kB from 0xC000 to 0xFFFF.
for the startup code my idea was that i could just have a second ASM file that gets assembled together with the BASIC code into a single 16k large .BIN file.
would that work?

floobydust wrote:

As for what to put in a batch file... you should reference the assembler and linker documentation. I still use TIDE to kick all of that off. Granted, it's on the buggy side, but I have a .WDC file that contains the parameters for TIDE to assemble and link the code and outputs a listing file, object file and a S-record (S19) file for the code I either load into my EEPROM burner or can download to my SBC using Xmodem-CRC.

I never worked with this before and i'm having quite a hard time getting this working.
i tried looking into the command line parameters via the manual from WDC but didn't get really far.
also how should BASIC + startup code fit into 16k (ie 0xC000 to 0xFFFF) when BASIC is said to start at 0xB000?
i changed that .ORG to be 0xC000 and at the start also changed the end of User RAM to be at 0xC000 as well.
but that gives me some errors.

Code: Select all

C:\Users\N\Desktop\EhBasic222p5C02>WDC02AS -g -l basic.asm
WDC 65C02 Assembler  Version 3.49.1 Feb  6 2006 17:25:36
       Copyright (C) 1992-2006 by The Western Design Center, Inc.
      BBS7  OPXMDM, DO_RDY    ; test to see if LOAD was executed
                  ^
Pass 1:File basic.asm; Line 984 # ERROR - Illegal addressing mode!
      RMB7  OPXMDM            ; reset flag bit to zero
                  ^
Pass 1:File basic.asm; Line 987 # ERROR - Illegal addressing mode!
     SMB7    OPXMDM           ; set upper bit in flag (print Ready msg)
                   ^
Pass 1:File basic.asm; Line 7561 # ERROR - Illegal addressing mode!
3 errors!

so yea i current cannot really fiquire out this assembler... i need to look at some demo/example code or something (or rather example BAT files)...
plus i still need to somehow put the startup code into that and then somehow get it into a 16k file.

Posted: **Fri Jun 12, 2020 4:30 pm**

Hi Proxy,

If you're only getting three errors, make sure you have all of the variables defined from the original source as:

Code: Select all

; Note: C02BIOS uses Page Zero locations from $E0 - $FF
; C02Monitor uses Page Zero locations from $B0 - $DF

; add page zero variables for Xmodem transfer using the C02 Monitor routines

PGZERO_ST       .EQU $B0               ; Start of Page Zero usage (C02 Monitor)

PROMPTL         .EQU PGZERO_ST+22      ; Prompt string address
PROMPTH         .EQU PGZERO_ST+23
SRCL            .EQU PGZERO_ST+24      ; Source address for memory operations
SRCH            .EQU PGZERO_ST+25
TGTL            .EQU PGZERO_ST+26      ; Target address for memory operations
TGTH            .EQU PGZERO_ST+27
LENL            .EQU PGZERO_ST+28      ; Length address for memory operations
LENH            .EQU PGZERO_ST+29

OPXMDM          .EQU PGZERO_ST+38      ; Saved Opcode/Xmodem Flag variable
PTRL            .EQU PGZERO_ST+42      ; Data pointer lo byte
PTRH            .EQU PGZERO_ST+43      ; Data pointer hi byte
BLKNO           .EQU PGZERO_ST+44      ; Block number

Second, make sure you have the correct processor selected as well from the original source as:

Code: Select all

;       Assembler/Linker directives for WDC Tools
;
        PL      66      ;Page Length
        PW      132     ;Page Width (# of char/line)
        CHIP    W65C02S ;Enable WDC 65C02 instructions/addressing modes
        INCLIST ON      ;Include listing file
        PASS1   OFF     ;Set ON when used for debug
;

Also note that your emulator needs to support the extended CMOS instructions that were originally from Rockwell, which are the SMBx, RMBx, BBRx, BBSx, otherwise the code won't execute correctly. You can likely remove some of this, as most of it was added when I added LOAD and SAVE to the basic code, which uses the Xmodem-CRC support in my C02 Monitor.

You can easily relocate the Basic code by changing the .ORG at the front. Note that starting it at $C000 will have it ending at $E78E. This means it will over-run your I/O ports at $DF00-$DF01. I think it's best to keep things as they are. If you just change your emulator to have 32KB of ROM and 32KB of RAM, you should be better off for now. Once you get things working, you can then start moving things around and make additional changes for what you want.

You can make a single source and BIN file of course.... just add your existing code to the end of the basic.asm file and use another .ORG statement to declare the start address of your code for starting up the CPU and have the routines that read the keyboard and write to the terminal.

For examples on some of this stuff, grab my BIOS and Monitor source from the C02 Pocket SBC on my github page. I make multiple .ORG statements in the BIOS source code.

Posted: **Fri Jun 12, 2020 7:25 pm**

floobydust wrote:

Hi Proxy,

If you're only getting three errors, make sure you have all of the variables defined from the original source as:

Code: Select all

; Note: C02BIOS uses Page Zero locations from $E0 - $FF
; C02Monitor uses Page Zero locations from $B0 - $DF

; add page zero variables for Xmodem transfer using the C02 Monitor routines

PGZERO_ST       .EQU $B0               ; Start of Page Zero usage (C02 Monitor)

PROMPTL         .EQU PGZERO_ST+22      ; Prompt string address
PROMPTH         .EQU PGZERO_ST+23
SRCL            .EQU PGZERO_ST+24      ; Source address for memory operations
SRCH            .EQU PGZERO_ST+25
TGTL            .EQU PGZERO_ST+26      ; Target address for memory operations
TGTH            .EQU PGZERO_ST+27
LENL            .EQU PGZERO_ST+28      ; Length address for memory operations
LENH            .EQU PGZERO_ST+29

OPXMDM          .EQU PGZERO_ST+38      ; Saved Opcode/Xmodem Flag variable
PTRL            .EQU PGZERO_ST+42      ; Data pointer lo byte
PTRH            .EQU PGZERO_ST+43      ; Data pointer hi byte
BLKNO           .EQU PGZERO_ST+44      ; Block number

Second, make sure you have the correct processor selected as well from the original source as:

Code: Select all

;       Assembler/Linker directives for WDC Tools
;
        PL      66      ;Page Length
        PW      132     ;Page Width (# of char/line)
        CHIP    W65C02S ;Enable WDC 65C02 instructions/addressing modes
        INCLIST ON      ;Include listing file
        PASS1   OFF     ;Set ON when used for debug
;

yea i screwed up and changed PGZERO_ST to 0xFF because i thought it would mean more ZP for BASIC...
that wasn't the smartest move.

floobydust wrote:

Also note that your emulator needs to support the extended CMOS instructions that were originally from Rockwell, which are the SMBx, RMBx, BBRx, BBSx, otherwise the code won't execute correctly. You can likely remove some of this, as most of it was added when I added LOAD and SAVE to the basic code, which uses the Xmodem-CRC support in my C02 Monitor.

As far as i tested, it's completely compatible with the WDC65C02. since that is the most common type of 65C02 (i think so atleast, since it's still being made)

floobydust wrote:

You can easily relocate the Basic code by changing the .ORG at the front. Note that starting it at $C000 will have it ending at $E78E. This means it will over-run your I/O ports at $DF00-$DF01. I think it's best to keep things as they are. If you just change your emulator to have 32KB of ROM and 32KB of RAM, you should be better off for now. Once you get things working, you can then start moving things around and make additional changes for what you want.

yea i'll try that 32k ROM thing for now.
and once i got that done and i can start to shrink the ROM and the IO space will also move back into RAM (maybe at like 0x0200 and 0x0201 since that seems unused by BASIC)

floobydust wrote:

You can make a single source and BIN file of course.... just add your existing code to the end of the basic.asm file and use another .ORG statement to declare the start address of your code for starting up the CPU and have the routines that read the keyboard and write to the terminal.

For examples on some of this stuff, grab my BIOS and Monitor source from the C02 Pocket SBC on my github page. I make multiple .ORG statements in the BIOS source code.

well you already gave example routines, and clearing the registers, setting the SP, and clearning Memory shouldn't be that hard to do.
I'll still look at your BIOS Code though. thank you.

.

ok so i changed the ORG to be 0x8000, same with the RAM_TOP constant. and while the assembler/linker says the code is ~10k in size (0x278E bytes large) the generated BIN file is still around 42k large...
why is that? it's literally just empty from 0x0000 to 0x7FFF. i must be missing a commandline parameter that makes it move the whole thing to 0x0000 while still assembling it like it's at 0x8000. i tried the -C parameter to relocate the CODE section (which is the only one present) to 0x0000 like the manual says, but i'm just getting an error saying: "Attempt to locate section CODE more than once!".

Posted: **Fri Jun 12, 2020 8:07 pm**

Again, I use TIDE and the .wdc file to assemble/link and create the required files to burn an EEPROM or download to my SBC. I don't generate .bin files and I don't use a .bat file or command line entries. Best I can do is examine the source code you're using. If you attach it here or PM me with it, I'll take a look. Also, you'll need to include the rest of your code that is managing the reset vector, startup, etc.

6502.org

65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic

Re: 65C02 Version of EhBasic