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.

_________________
Regards, KM
https://github.com/floobydust

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.



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

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.


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

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

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


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:

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


Neubrandenburg, basically near the top right corner of Germany.

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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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.

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,
(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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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.

_________________
Regards, KM
https://github.com/floobydust

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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].


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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.


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.



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?

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:



For the B_CHRIN_NW routine it might look like:



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.

_________________
Regards, KM
https://github.com/floobydust

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


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.


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?


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.

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.

Hi Proxy,

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



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



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.

_________________
Regards, KM
https://github.com/floobydust

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.


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)


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)


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!".

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.

_________________
Regards, KM
https://github.com/floobydust