I've converted all the macro's I have to use param, and the code looks much better without all the .BYTE's. Now param is good for byte size. What would I use for word size (double byte) parameter?

Some macro's need to define a new opcode, say LDBax (LDB $xxxxxxxx,x), and the paramater has to fit a 32-bit address. Is this possible?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Ah, I got it.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Hello,

sorry for interfering. Hope you don't mind. While looking for some information about the 6502, I stumbled across this interesting forum and found your threads about the 65org16 and other related topics. I was truly amazed by the knowledge and experience of the people here and hence their ideas, and I digged through the depth of the threads to gather as much information as possible. And finally at the weekend I sat down and wrote a little experimental 65org16 emulator and assembler to fool around with the opcodes (*) and to get a feeling what programs and programming would be like. As expected a few problems arose, and now I wonder if it were possible to ask you some questions concerning the 65org16/65org32. Well, actually, I would have plenty of questions, so I didn't even know where to post this since the questions include things like emulation as well as programming or ISA design. Feel free, please, to move this post around to another thread if you like. Oh, and this is my first post here. Have mercy on me, please...

Miles

(* right now only the old 65c02 instructions extended to 16 bit without the additional registers)

Hi Miles! -- and welcome! Nice to hear about your emulator and assembler. Did you have an actual question? I'm sure someone will be glad to try to answer.

cheers,

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks! I've got a lot of questions, indeed, but I really don't want to cause any trouble. So, here are just a few:
1) A simple question just to make sure: is the behaviour of the stack instructions PHA, PLA etc and JSR, RTS the same as on the 6502 (PHA = write value then decrement S, PLA = increment S then read value, JSR = increment PC, write high word, decrement S, write low word, decrement S)?
2) How many cycles do the instructions use (relative in comparison to each other)? Just a rough estimate, so that I can adjust the emulator and watch out for bottlenecks in the program.
3) Is the stack placed at $0001 0000 .. $0001 ffff? The IRQ vectors are found at $ffff fffa etc? Is there an additional COP vector ($ffff fff4) or something similar that can be used for system calls?
4) Does a dev. board exist with an attached video generator? If so, how is it organized and what is the resolution? (So I can perhaps emulate some kind of display output.)
5) Would it be possible to add the instruction 'JSR (zp, x)'? This may seem very odd at first, but there's a reason. When I write larger programs I use object oriented programming a lot. In x86 assembly you would likely use something like 'mov eax, [esi + offset]' for loading an object attribute value. On a 68000 there is 'MOVE.L offset(A5), D0'. Unfortunately an addressing mode like 'LDA (zp), #offset' does not exist, and addressing attributes using 'LDY #offset : LDA (zp), y' would result in very long code. So I decided to place the objects into the zero page, load the X register with the address of the object and use the zp value as the constant offset of the attribute. This will give me 'LDA offset, x' for loading the attribute value of an object pointed to by X. So far so good. The problem is: how do you call an object method? The x86 has 'call [esi + offset]' for this. The 68000 at least got 'JSR offset(A5)' in combination with an additional ' JMP abs.L'. All members of the 6502 family lack a short and quick way to perform this call, although it is really very useful and may speed up programs drastically. Now even a zp as the offset would be enough, as the objects reside in zero page anyway. Hence 'JSR (zp, x)' would be fine. What do you think: would it be possible/make sense to add such an instruction?
6) Are there still plans to include instructions for multiplication and division? (I personally would prefer a simple unsigned 'MUL' that multiplies A * Y with the result in Y (low) and A (high) but that's a matter of taste really.)
Now I could go on endlessly, but I rather not get on your nerves if I haven't done so already. Thanks for your patience.

Miles

( reply reposted in new thread; see viewtopic.php?f=10&t=2211&p=20209#p20209 )

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Welcome Miles - I reposted your query in a new thread because it looked like it could spark a wide-ranging discussion.

Good to see a new face on the forum - especially someone interested in joining the 65Org16/32 party!

Please consider posting something in the Introduce Yourself thread.

See you over in the new thread.

Cheers
Ed

With any luck, attached is a file containing a first pass at creating a complete set of instruction macros for the 65Org16b which are compatible with the HXA_Tx assemblers.

The instruction file is "i65org16b.a". Generally the macros supplement the normal 6502 instruction macros by accepting accumulator names where approriate:



But there are new instructions as well:



The only real deviation is in the shift/rotate instructions. After some thought it seemed best to incorporate the shift count into the "mnemonics" themselves.

The file is heavily commented but still only about 30K (it doesn't even use every trick HXA knows!). The size is a reflection of a design that relies on nested macros. Only the "lowest" levels actually generate data; "higher" levels are concerned with identifying what the arguments are so the appropriate data can be generated.

The trade off is that these will generally run slower than macros tailored to generate one specific address mode. The test files (which do not cover all instructions but generally only the first of each "family" of related instructions) take about seven seconds to assemble on a roughly 2.5GHz quad core machine. Of that, about five seconds is spent on the 2700+ variants of ADC; this family is the most deeply nested of all.

The largest file is "testorg16.lst", about 580K of output created after running all tests. This shows that to produce about 10K of output from 3600 or so source lines, 170K or so macro lines were examined at about 30K lines/sec. Speed could be increased by making a "native" 65org16b version of HXA.

Awesome, thanks for doing this TT! I'll be sure to check it out.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

As I have never used your HXA assembler, can you explain some files present in the .zip you posted and how to use them in conjunction with HXA?
I took a snapshot for anyone else interested...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

dotest.bat - just a batch file to save some typing. Executes HXA_TW with TESTORG16.A as the file to assemble

gentest.awk - a quick-and-dirty AWK program to generate test files, generally one particular family at a time. I wasn't about to try to write 2700+ variants of ADC by hand and it was simple enough to hack it to produce most of the other tests (all the ones over 1K, anyway - the others were short enough to do by hand). It's by no means a polished effort.

i65org16b.a - implements all 65Org16b instructions using nested macros. The top-level "mnemonics" are all capitalized and in alphabetical order. The nested macros have names that embed a number (eg., "_3_") which reflects their nesting level (so I could keep them straight. Also they come out nicely in the listing). There are a couple that start "_9_", not because they're that deep but because they're called from so many different levels it seemed the easiest way to make sure every caller is at a higher level. They're also a bit different in that their definitions themselves are nested.

test_*.a - test files, usually one particular family each (the name is supposed to be a clue which one), usually created by
GENTEST.AWK. I didn't test instructions that amount to just one BYTE (eg, CLC, PHX), only ones that required some degree of argument examination to make sure the logic worked properly.

testorg16.a - a test harness, I65ORG16B.A and one or more TEST_*.A files are included by it for assembly. A modular approach so I could deal just with whatever family I was working on without having to worry about extraneous output.

testorg16.lst - the output of TESTORG16.A when all TEST_*.A test files are included in one assembly run

You can look at I65ORG16B.A to see what the macros are and TESTORG16.LST to see what they produce.

A question for Bitwise:
Yesterday I started receiving an error when trying to run NMAKE through no fault of my own. Any clues on what I can do to fix this problem?
I'm using Version 7 update 51 of Java.

EDIT: I should have googled first, sorry. Since I couldn't delete this post I figured I should complete the post. It's weird because this all of a sudden started happening last night for no good reason...
I found the answer on wiki.answers, followed the directions (similar to XP) and it's working again:

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502