One last thing.... generating a .BIN file. I did this as well and it's quite large. If you examine the actual file, it starts at address $0000 and goes to the end of linked code. As it's a pure binary file, there's no information that defines it's start address in ROM, so logically it starts at address $0000. In other words, there's no specified offset in a pure binary file that would define that you start loading code at address $8000 (as an example). You should probably look at supporting a common file format for your emulator, like S-Record S19 format.

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

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

I added my Routines to the very end of the source file, assembling it generates a 64k large .BIN file, everything until 0x8000 is just 0's. (my code start at 0xF000 in the BIN file, there is like 18k of empty space between BASIC and my routines/startup code)
here's the Dropbox Download, it includes the .BIN file i generated, the .BAT file i used to do it, and the source .ASM file.


if you don't define the starting address then yes it will do that. but that shouldn't be impossible to fix, it's such a basic feature, there's gotta be some commandline thing that can move it to the start of the file. and if not i can just delete the first 32k manually and it will work perfectly fine.


that is somewhat correct but mostly wrong.
it's true that a pure binary file cannot define where it's supposed to sit in memory, but that's because it's your job to know where the code is supposed to be located.
like it doesn't need to "know" the starting address for the code in the ROM because address 0x0000 in the file will already be translated to whatever the starting address of the ROM is (in this case 0x8000) when you program the file into it, so it all lines up in the end.

0x0000 (starting address in the file) + 0x8000 (where ROM is located on hardware/emulator) = 0x8000 (where code will be located and executed after programming the ROM)

i'm sorry, but honestly your arguments asgaist binary files don't make much sense...

another example if you have an IntelHEX file and inside it starts at address 0x1000, and you load that into a ROM... it would start loading into address 0x1000 in the ROM so most programmer software automatically relocates that data to 0x0000 inside the ROM no matter what the starting address in your file is, which is exactly the same thing i want the assembler to do for me here.

I've been using raw binary files for atleast 2 years now to program EEPROMs/FLASH chips/etc and it works perfectly fine like any other format, plus it's a lot smaller than other formats
so yea, im sorry but i'll stick with binary files. it's a lot less hassle than other formats

and lastly Logisim doesn't even support IntelHEX or S19 so it's not like i have any other choice.

eyyy, i got it working, just had to cut off the first 32k from the binary file to load it.

well it works somewhat atleast

i got the Cold/Warm start screen and after it counted Memory it brought me to the ready promt. but that is basically it, i can enter commands but they never get executed.
i think it's because BASIC expects either both LF and CR or just CR from the keyboard to count something as a new line but Logisim's keyboard only outputs LF (like Linux7Unix systems) so in BASIC thinks i'm putting everything into a single line.

now i gotta modfy the code to only use LF instead of LF/CR.

oh boy... i think i'll pass on that for now until tomorrow.

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

but you can do exactly the same with a binary file. i'd say neither standard is better than the other, unless you have software that only work with a specific one.
like Logisim in this case.

and the manual for WDCTools seems to indicate that it does have the option to move the code to the start of (or anywhere in) the file, i just can't fiquire out how to use it....

.

on a different note i got it accepting "returns" now, as a botch i just make it so that when the keyboard outputs 0x0A (LF) it converts it into 0x0D (CR) and that aprently works.
but no matter what command i enter i just get a Sytax Error. except for assigning variables, that seems to work.

oh well i'll take care of that tomorrow... or rather today but in a few hours of sleep.

Well, I guess we'll have to disagree... I've only been creating BIN files, S-Record Files, etc., for over 35 years... and using Programmers/Burners for the same. If you create a "pure" binary file, the only thing you can do is understand the memory size it was created for, which in this case is the 64KB range of the 65(C)02. Anything you do (to the file) to provide a load address changes the file, so it's no longer a "pure" binary file. This is why there are different file formats for code images. Do it your way, but I think I've been doing this stuff much longer than you, so do whatever works for you.

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

As EhBasic was patterned after Microsoft Basic, it only recognizes commands in UPPER CASE. Klaus put a User Manual together for EhBasic some time ago, probably worth grabbing that and reading through it.

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

and i know a lot of people here have been working with these things for much longer than i have been alive for...
but still...

when i say "pure" binary file i just mean that the file contains pure binary data, it has nothing to do with the size of the actual file.
by your logic a "pure" intelHEX/S19 file should also start at address 0x0000 instead of the start of the program (in this case 0x8000).

binary files just work identical to any other format where the start of the program is located at the start of the file.
the only difference between them is how the store the actual data.
Binary files just store it as "pure" binary data while other formats store it as text (ASCII).

if it helps, just drop the "pure", let's just say it's a "binary file".
it's just an alternative to other formats.
maybe that's not how they worked back then but that's how they work now.

so let's just drop this here, and go back to BASIC.


i didn't think about that... well that was not smart.
anyways i made a small test program

and it works fine. though it's kinda slow due to the slow speed of the simulator (~2.5kHz).

speaking of speed, at the start when it's counting memory is it actually counting each byte?
couldn't it count in larger parts (like 256 or 1024 bytes) and once it reaches the end it goes back one "part" and counts that last one in bytes, afterwards you multiply whatever you counted by the size and add the final bytes to that.

but besides that i think i'll now try to make the ROM Smaller and fit the whole code into 16kB. shouldn't be too hard.
also i'm still kinda trying to convert the whole thing to CustomASM so i can write with it on Win10 without a VM, but when it starts counting memory it just gets stuck in a BRK loop so i still got a lot of work to do.


overall thanks for the help to get this running at all, even though it got a bit ranty at the end...

i assume if i need more help with this i should just make a new thread, since this one has been kinda tainted or overrun by me... sorry for that btw.

Something I like to do, when I think of it, is spotting a side-discussion and starting a new thread about it. It's easy enough to link back to the previous thread and indeed to link forward to the new thread. It then helps everyone, now and in the future, to see threads which are on some topic. In this case, one might have had side-topics on assembly syntax, on loader formats, on memory size detection. And it would still be possible.

As a tip, though, this isn't usually an argumentative place, but a place for discussion and sharing experiences. It's quite possible that two points of view are quite valid, because they reflect different preferences or different situations. Or different states of knowledge. So, rather than say that something is wrong, or something else is right, better to say that you prefer it, or you don't see the merit, or whatever.

yea i've seen that happen on here quite a few times, and it's a good thing. keeps current threads on track and moves the side discussion to it's own thread.
I'll maybe do that for the conversion, though I'm not sure how many would be interested since CustomASM isn't a common assembler on here, it just has the benifit of being modern (ie running reliably on Win10) and customizable to fit any (most) CPUs/Syntaxes.


i know that works for anything subjective. Tabs vs Spaces, Assembler of choice, $00 vs 0x00, IntelHEX vs S19 vs BIN, etc.
I don't really know if it applies to this, if someone says a format works one way while someone else says it works differently. or i just have been misunderstanding the whole conversation.

Proxy, Ed, et al,

First, I agree that in general, we're a very friendly and helpful bunch... I guess it's mostly our nature. However, differences will arise from time to time, just that simple. We all have our views and insights based on our experience, which for many of us, goes back 40+ years.

So, I'll address Proxy's last post on files and we can move on... no harm, but I prefer not to be mis-quoted. When I refer to a pure binary file, it has nothing to do with an Intel Hex file or a S-record format, etc.. A pure binary file would be an image which can be directly loaded to (or read from) a ROM chip. As a result, it has NO ability to define any loaded address or offset. Every other format used for loading ROMs has a specific format which are documented.

WDC Tools (plain) BIN option simply generates a pure binary file (maybe just my terminology) and as a result, it starts at address $0000 for the 65(C)02 and goes to the end of assembled/linked code. It then becomes up to the end user to determine how to use it going forward. This is why I default to Motorola S-Record S19 format. My Dataman programmer can use quite a few different formats, but even with S-Record formats, you still need to define an offset for the ROM, i.e., the 32KB EEPROM which is addressed at $8000 in my SBC. Otherwise, the programmer defaults the address of the EEPROM at $0000 and it wouldn't be able to program it, as the code to be loaded defines the address locations in the EEPROM.

On the current status of Proxy's project... of course, happy to help out. Too bad the clock speed of the emulator is that low. There's another thread I started a while back on Basic test programs, and there's quite a good number of them shared there by others. See it here: viewtopic.php?f=5&t=5184

I did download Proxy's code. I'll make a few updates and re-post it. Granted, I can't test it directly, but it should be fairly clear on getting it to work in his emulator. Cheers!

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

Proxy,

I made a few updates to your Basic.asm file. I changed the top of Ram memory address and the start of assembled code to $C000. The startup routine is also changed and it will fit into a 16KB ROM size. The clear memory routine now checks for top of Ram and stops clearing when it's reached. I also changed your CHRIN_NW code... you don't need to set or clear the carry flag as that's done by the LSR A of the status byte. It also checks for a linefeed character and replaces it with a carriage return, as this seemed to be a problem with the emulator.

Note: the Basic initialization does a simple memory test from ram start to the top address and clears it out. So, doing the same in the startup routine is sorta pre-redundant , Have fun.

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

yes, a binary file that has code at the very start of the file could actually be located at 0x8000 or something but there is no way to indicate that.
but as said there is no problem with that as your hardware handles the offset. since your ROM on the board starts at 0x8000 anything loaded to the start of the ROM (0x0000 in the programmer) will also start at 0x8000 once the ROM is in the board.

my point was just that it would save you a tiny bit of time. for example my Xgpro programmer software asks from what address in the file it's supposed to start load from and where into.
if i take the raw output from WDCTools i would need to tell it to load from 0x8000 since that's where the actual code starts, but if the assembler relocated the code to the start of the file beforehand i could save myself that step when loading it into the program.
there is functionally no other difference, it just saves you typing in a number.


i'm confused what you mean with the second part, why do you need to set an offset when loading into a ROM (with S19)? shouldn't it always default to the start of the ROM, ie 0x0000?

anyways... yea this has being going on for too long.
different people have different ways of doing the exact same thing, i use .BIN files because it's what the Logic simulator i use supports, and because i'm not familiar with other formats like S19 or IntelHEX.


yea i really should convert my Logisim circuit to "Digital", which is a similar logic simulator but can run much faster and also export circuits as Verilog.
I've just been procrastinating that because it's a lot of work.
technically i'm "only" missing the ALU and Control Unit... but both are rather complex so i always pushed it back.



thanks for that, and yea i didn't think about the fact that i can just change the LF to CR in the actual routine without modifying my simulator circuit....
also something about this part:

i originally did it like this:

because i thought it's faster...
as "INY" (2 cycles) takes less time than "INC $00" (5 cycles) while being functionally identical (in this case atleast).
is that somehow wrong?

Hi Proxy,

I use a 32KB EEPROM for my C02 Pocket SBC which is addressed starting at $8000. The programmer wouldn't know where (in a memory map) that I would have it configured. So, logically, the programmer starts it at $0000, so it has an addressable range from $0000 - $7FFF. Meanwhile, the S19 record does have load address for locating the data in the EEPROM, which are in the $8000 - $FFFF range. Hence, you tell the programmer that the EEPROM has an addressable offset of $8000, so it addresses the 32KB EEPROM from $8000 - $FFFF. Hope this is clear.

Code changes.... well, as I like to say, "you can't argue with success". Filling memory... sure, the INY is quicker, but you also need to load the Y reg first, so the code may be larger, depending on register contents on entry. Not using the Y register also implies you don't disturb it's contents. It's all trade-offs. For certain routines it's advantageous to code for speed, others better to code for smaller size. For a startup routine, I generally go for smaller size as it's a one-time execute. The character input routine which is used a lot with EhBasic... you're better off optimizing for speed. Not having to set or clear the carry flag explicitly saves time as the ASL A already set it. Adding the CMP for a linefeed is just a convenience, but if your emulator used a C/R instead, it would save some additional cycles as well.

In short, there's usually multiple ways to code anything on the 6502 and the later CMOS versions with additional instructions and address modes are helpful. I tend to use the newer instructions/address modes quite a bit. I would certainly recommend putting together a small 65C02 based system at some point. My current SBC runs at 6MHz, although I have one SCC2691 that survives an 8MHz clock. My next SBC will use a newer NXP DUART and will hopefully run beyond 14MHz.

As always, enjoy the project and learn from everything you do.

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