I think everyone here as a good understanding of why I want this... I know I have my plate full already, (I will get back to the Irem M92/107, but that's when I've done what I've currently wanted to do on the SNES (which will probably never get finished...)) but I figured I'd at least want to do a little experimenting like I did with the M92. Anyway though, I looked up an assembler, and I found something called "MARS". I downloaded it and extracted the file and, to my delight, a billion files spewed out. Is a simple batch file not good enough? I guess I could figure out how to use that, but I'd rather not...
(Does anything even use MIPS anymore? It seems like everything is just x86 and ARM now a days, but I'm not very knowledgeable on new stuff. I'm not even sure what "hyper threading" and all that other stuff means.
)
Espozo wrote:
(Does anything even use MIPS anymore? It seems like everything is just x86 and ARM now a days, but I'm not very knowledgeable on new stuff.
In embedded applications like ASICs, I'm sure it is (and the 6502 also). Android supports MIPS, I've seen it in some tablets and I'm sure they're in some phones too. Microchip sells MCUs, that you can even buy in DIP package, with MIPS32 core.
Sometime later this year, I'll hopefully be porting some of my code over to this:
http://www.imgtec.com/downloads/factsheets/MD00939-2B-microAptivUP-DTS-01.00.pdfFor the assembler, it may depend on which chip you need to assemble it for. I know for MIPS32 and microAptiv I'll be using GCC and Gnu Assembler.
Memblers wrote:
For the assembler, it may depend on which chip you need to assemble it for. I know for MIPS32 and microAptiv I'll be using GCC and Gnu Assembler.
I though most assemblers had directives that you would say what processor you where programming for. Anyway, this is it: NEC VR4300 (MIPS R4300i). I guess NEC VR4300 is pretty much a copy of the R4300i? Did NEC make anything by itself? (The NEC V33 in the Irem M92 is pretty much a copy of the intel 80186.)
Edit: Not really related, but this looks really useful:
Attachment:
Reality Coprocessor.pdf [394.52 KiB]
Downloaded 123 times
(2KB of the total 4 are used just to hold the color palette for the texture?
How about
mips-elf-as?
As you've already noticed, MIPS is not a popular architecture nowadays. You'll have to work a bit if you want to use
as.
If you have Linux (or some other Unix-like OS with GCC installed), you can
compile it yourself pretty easily. On Windows, you need a working MinGW+MSYS or Cygwin environment, but the commands are the same.
There's a patch to add support for a certain SIMD instruction set, but it's only for a very old version of binutils.
I downloaded the assembler, and decompressed the file and this is what I got:
Attachment:
Ugh....png [ 86.81 KiB | Viewed 2097 times ]
What am I supposed to do here?
Espozo wrote:
What am I supposed to do here?
The next step is to compile it.
Since you're on Windows, you have three choices: Cygwin, MSYS+MinGW, or asking someone to compile it for you.
You have to rebuild binutils separately for each CPU architecture you want to target, so if you have a lot of those, you might want to check out the first two options.
Could you use the MIPS assembler from
devkitPro's devkitPSP?
Quote:
you have three choices: Cygwin, MSYS+MinGW, or asking someone to compile it for you.
How about the last option?
tepples wrote:
Could you use the MIPS assembler from devkitPro's devkitPSP?
I can't find whatever you're trying to show me. If it's a bunch of files I need to compile, then there's no point.
Download "devkitPro Updater" for Windows, run it, and have it install MSYS and devkitPSP. This "devkitPSP" consists of a Windows binary of GCC and a Windows binary of Binutils targeted to MIPS.
Is this right? I'm not sure if I downloaded the right thing.
Attachment:
Files.png [ 77.87 KiB | Viewed 2052 times ]
Espozo wrote:
(Does anything even use MIPS anymore? It seems like everything is just x86 and ARM now a days, but I'm not very knowledgeable on new stuff. I'm not even sure what "hyper threading" and all that other stuff means.
)
Modems and such usually use MIPS.
Sik wrote:
Modems and such usually use MIPS.
Hmm...
It seems like anything that isn't x86 or ARM is usually being used in things like coffee makers nowadays. (It appears that things like the 6502 and the Z80 are still being made for this. Did the 65xx family ever go past the 65816?
I'm just curious, but do x86 processors still have the weird 20 bit addressing?
Anyway, I'm totally lost on this. Would it be bad if someone just uploaded a file here? I've looked online and said stuff like "Windows MIPS assembler" and "MIPS assembler batch file" and I haven't found anything.
I seem to remember reading that the royalties to include a MIPS core in a specialized system-on-chip are lower than for ARM.
Espozo wrote:
Did the 65xx family ever go past the 65816?
Kinda. There was a proposed 65832 with 6502/65816 backward compatibility, but it seems they mostly just doubled the register width (though not the bus width...), and apparently there wasn't sufficient demand to justify manufacturing it.
93143 wrote:
Espozo wrote:
Did the 65xx family ever go past the 65816?
Kinda. There was a proposed 65832 with 6502/65816 backward compatibility, but it seems they mostly just doubled the register width (though not the bus width...), and apparently there wasn't sufficient demand to justify manufacturing it.
I don't know the feasibility of this, (or the purpose really) but there's nothing I'd love more than seeing some sort of modern 6502. I'm talking about 64 bit instructions, multiple GHz speed and other things. I know that would be ridiculous, but it would certainly be something I'd like to see.
Also though, 32 bit registers still with an 8 bit data bus? It looks like they had some mixed priorities.
Somewhat more recently , there have been rumours of a W65T32 "Terbium", which was supposed to have a 16-bit data bus and a 32-bit address bus (sounds much better balanced, no?) as well as backward compatibility. Nothing substantial appears to have come of the idea, if indeed it was ever real, and references to it are scarce (the name "Terbium" now appears to be used by an unrelated 65x-based dev board sold by WDC). At least the 65832 had a datasheet available to interested parties...
93143 wrote:
there have been rumours of a W65T32 "Terbium"
Seeing that the last time it was talked about was around 2006 it seems, I doubt it will ever materialize... I bet everyone would freak out that there are only about 3 registers and DP anyway. I personally find 16+ registers overwhelming, but I wouldn't mind something like a z register. Have more registers ever been added to newer processors in the same processor family?
Edit: I know this sounds ridiculous, but has anyone ever even emailed WDC to see if this is even still being worked on or if it was ever even true to begin with?
Edit 2:Is Western Design Center still manufacturing the 65816? It's got a spot on its website and it has a price tag.
http://www.westerndesigncenter.com/wdc/ ... s-chip.cfm
Espozo wrote:
Quote:
you have three choices: Cygwin, MSYS+MinGW, or asking someone to compile it for you.
How about the last option?
Sure. Does it need to run on 32-bit Windows, or is 64-bit okay?
Espozo wrote:
I'm just curious, but do x86 processors still have the weird 20 bit addressing?
They call it
real mode to tell it apart from the other modes that were introduced starting with the 286. It doesn't get a whole lot of use nowadays.
Joe wrote:
Espozo wrote:
Quote:
you have three choices: Cygwin, MSYS+MinGW, or asking someone to compile it for you.
How about the last option?
Sure. Does it need to run on 32-bit Windows, or is 64-bit okay?
You're a lifesaver!
64-bit is okay.
Joe wrote:
It doesn't get a whole lot of use nowadays.
I'd imagine so. (I still don't get why it was made the way it was, but I think I remember Koitsu saying that it was kind of a quick hack?)
Espozo wrote:
It seems like anything that isn't x86 or ARM is usually being used in things like coffee makers nowadays. (It appears that things like the 6502 and the Z80 are still being made for this. Did the 65xx family ever go past the 65816?
No idea about the 6502. As for the Z80, it had successors, although none were as successful (the closest was the R800 which was used on later MSX machines, but it died with the MSX).
Espozo wrote:
I'm just curious, but do x86 processors still have the weird 20 bit addressing?
It's called Real Mode and the BIOS
still boots in this mode (in fact, you can still run DOS on a modern system). The operating system has to switch to Protected Mode (32-bit) or Long Mode (64-bit). This may eventually go away if UEFI becomes spread enough, though (since UEFI sets it for you), although I don't expect that to happen in several years yet.
Espozo wrote:
Also though, 32 bit registers still with an 8 bit data bus? It looks like they had some mixed priorities.
Cheaper to manufacture, and less pins needed. For budget hardware that just needs some quick processing it makes perfect sense.
Sik wrote:
Cheaper to manufacture, and less pins needed.
If they're going to have a then pretty hefty processor, why would you put it in otherwise low budget hardware anyway?
Espozo wrote:
93143 wrote:
there have been rumours of a W65T32 "Terbium"
Seeing that the last time it was talked about was around 2006 it seems, I doubt it will ever materialize... I bet everyone would freak out that there are only about 3 registers and DP anyway. I personally find 16+ registers overwhelming, but I wouldn't mind something like a z register. Have more registers ever been added to newer processors in the same processor family?
The 65CE02 had a Z register that behaved the same as the Y register (and direct page, and 16-bit SP), but I don't know of anything notable that actually used it aside from the Commodore 65, which was never actually released.
Well, why the heck did that not carry over to the 65816? I know opcodes would have to be more than 8 bits, but oh well.
(Actually, now looking at it, it appears there are a couple of other minor things the 65816 didn't get from it. I would have thought the 65816 would have been based on the more advanced 65CE02 instead of the 6502.)
The 65816 (1984) is older than the 65CE02 (1988).
Oh, I got you. I guess it was 65CE02 was kind of like the "lower end" chip they were selling vs. the 65816, but they still gave it a few improvements.
Espozo wrote:
I still don't get why it was made the way it was, but I think I remember Koitsu saying that it was kind of a quick hack?
It was designed to be backwards-compatible with the 8080 and allow future expansion by changing how segment:offset pairs are translated to linear addresses.
The backwards compatibility was successful enough that DOS went out of its way to support programs that had been translated from 8080 code, but future expansion ended up going in the direction of the 286 instead.
Apparently attachments can't be bigger than 4 megabytes.
You'll have to download it from here, I guess.
Espozo wrote:
Oh, I got you. I guess it was 65CE02 was kind of like the "lower end" chip they were selling vs. the 65816, but they still gave it a few improvements.
They were actually manufactured by two different companies (one by WDC, the other by MOS/Commodore) so I don't know the extent to which one influenced the other; they're really more like two separate evolutions of the 65C02, which might have been seen as a better basis for the 65CE02 just because it was seeing a little more widespread use than the 65816 was.
Well Joe, I got the thing and I noticed that it had two sets of .exe files, like this:
Attachment:
Files.png [ 88.59 KiB | Viewed 1250 times ]
I didn't know which ones to use, so I've tried everything with both. I went to the "as" ones because you said that they are the assembler ones, and I ran both of them in the command line, and they said that "libz-1.dll" was missing from my computer, so I downloaded it from this website:
http://www.dllme.com/dll/files/libz_1_dll.html (I'm just making sure I got the right thing) and I tried both of the applications again and I got this:
Attachment:
Error.png [ 7.09 KiB | Viewed 1250 times ]
Don't forget about the 65802, by the way. Simple explanation of that chip: it's a 65816 but is limited to 64KB of memory and pin-compatible with the 6502/65c02, and also offers emulation mode (important for vectors). For details, refer to the
WDC 65816/6502/65C02/65802 PDF. (Sometimes I wonder if people even read what I tell them to read...)
P.S. -- It appears WDC has updated their PDF! It's no longer 1.7MBytes, but instead 54MBytes. Guess why? Instead of a bad/broken OCR "conversion" (not scan) rife with errors, they simply scanned the actual Lichty/Eyes book into PDF format using full images for each page (hence its huge size) -- however, they did do a text OCR scan, so some text is in fact searchable and copy-paste-able. I'll keep both PDFs on the nesdev site with a description of the differences. Bill Mensch kept his word. :-)
Espozo wrote:
they said that "libz-1.dll" was missing
Sorry about that, it pulled in a dependency without me noticing. I've attached the correct libz-1.dll to this post.
As you may have already noticed, the DLL file you got from that website does not work. DLL websites like that are a bad idea for two reasons: DLL files have multiple incompatible versions that all share the same name, and DLL files can contain viruses.
Yay, It works!
(Both sets of the .exe files appear to do the exact same thing, so I'm probably just going to use "as" because it's easier to type.)
Since it appears the 65CE02 and the 65816 both branched off the 6502, it would be cool if there was a combined version of them, like a "65CE816" that was like 65816 but had the z register and had the thing where it uses less clock cycles for some instructions. (One think I've always wondered is where the suffix "816" came from. Now that I think about it, where did "65" come from? Is it based on some sort of technical specification, or did they just come up with the name?)
The "816" is from the ability to alternate between 8-bit and 16-bit registers; the "65" may have come from MOS's original goal of creating a smaller and cheaper alternative to the 6800 (though where that name came from, I have no idea).
I guess a modern processor in the 65xx family could be called the "658163264".
Or just "ARM", though it isn't quite binary compatible.
tepples wrote:
Or just "ARM", though it isn't quite binary compatible.
I'm not following you on this one.
It doesn't support MIPS III, only MIPS I.
Espozo wrote:
tepples wrote:
Or just "ARM", though it isn't quite binary compatible.
I'm not following you on this one.
Look at the way subtract carry works on ARM, look at the way the Z-flag branches are named (
bne and
beq), look at the mnemonic for load, store, and bitwise OR and XOR (
ldr,
str,
orr, and
eor to parallel
lda,
sta,
ora, and
eor), and tell me it wasn't designed as the RISC spiritual successor to the 6502 family. Or is it more 68000-like than 6502-like?
Pretty much all processors have ld*, st*, or, and, xor instructions (named differently). The naming of ARM vaguely resembling 6502's is their only common point, they differ in absolutely everything else. I don't know the 68k good enough to know if ARM is 68k like.
I think the point was in how the instructions were named, though.
And yeah, 68000 has beq/bne too, in fact every processor not naming the flags directly pretty much has that or jeq/jne (yes, x86 too, although jz/jnz are aliases IIRC).
Bregalad wrote:
The naming of ARM vaguely resembling 6502's is their only common point, they differ in absolutely everything else.
They really don't feel anything alike, even though I only looked at ARM for about a week. I remember some annoying thing where you could only load general numbers like 256, and you had to add or subtract from that to get what you want. I wasn't a big fan. I liked 80816 x86 better, even though I've also only looked at it for about a week. (The 20 bit addressing was still a pain though.) I plan on going back to work using x86, as I plan to look at the Irem M92 and 107 when I've finished my first thing on the SNES. I'm not sure about ARM though. I unfortunately can't say MIPS looks like a blast.
There aren't that many instructions, even though some opcodes are 5 letters long. The "pseudo instructions" are things that most processors can do already. This probably does allow to get more creative in what way you want to do something though, in that I imagine it would be fairly easy to make your own "pseudo instructions".
Espozo wrote:
I remember some annoying thing where you could only load general numbers like 256, and you had to add or subtract from that to get what you want.
This is true of ARM. You can build a constant by ORing two shifted bytes together, the same way MIPS has the
lui/
ori pair. Or you can load a constant from a PC-relative "constant pool".
Quote:
The "pseudo instructions" [on MIPS] are things that most processors can do already. This probably does allow to get more creative in what way you want to do something though, in that I imagine it would be fairly easy to make your own "pseudo instructions".
Just as MIPS has
pseudoinstructions, 6502 has
its own pseudoinstructions.
Espozo wrote:
I unfortunately can't say MIPS looks like a blast.
It's designed as a target for high-level languages, so the instruction set is very straightforward. Every opcode is 32 bits, so you need pseudoinstructions to do anything that would require more bits in a single instruction. The abundance of GPRs makes it far easier to work with than x86 or any 65xx CPU, but you're right: it's not all that interesting.
N64 games were primarily written in C and C++. I wonder if GCC has gotten any better at generating code since then.
Quote:
I wonder if GCC has gotten any better at generating code since then.
Since the 90s? It has got tremendous improvements. Even since I use gcc (that is since about 2009, before I wasn't doing anything other than assembly), there is a lot of notable improvements that have been done, especially in error reporting, but I also believe in code generation.
Quote:
This is true of ARM. You can build a constant by ORing two shifted bytes together, the same way MIPS has the lui/ori pair. Or you can load a constant from a PC-relative "constant pool".
In ARM, using a constant pool "eats" 2 words so that's the technique you'd want to do. In THUMB, I'm not knowledgeable enough. gcc's code generator calls this "lanchor".
tepples wrote:
Espozo wrote:
tepples wrote:
Or just "ARM", though it isn't quite binary compatible.
I'm not following you on this one.
Look at the way subtract carry works on ARM, look at the way the Z-flag branches are named (
bne and
beq), look at the mnemonic for load, store, and bitwise OR and XOR (
ldr,
str,
orr, and
eor to parallel
lda,
sta,
ora, and
eor), and tell me it wasn't designed as the RISC spiritual successor to the 6502 family. Or is it more 68000-like than 6502-like?
Let's not forget that "true" literal values (i.e. not a pseudo-constant used with ldr Rd, =cst) are prefixed with "#" and that SVC is pretty much like BRK on the 6502 in
that you must access the constant by inspecting the instruction with the stacked PC. (SVC is basically like BRK, a synchronous software interrupt)