michaelcmartin / ophis Goto Github PK

When building a program out of partially machine-generated components, it would be nice to not need a "master program" that includes the rest. The command line should let us build this up with a series of arguments.

Making this workable requires at least:

• A -e argument for including specific lines on the command line
• A -o argument for specifying the output

.advance currently always fills with zeroes. This isn't universal amongst assemblers; if we're trying to match output, we should let it be specified. This should allow any legal expression within range.

Let's say, for the sake of argument, that I want to download a recent stable version of Ophis. I notice the Ophis home page has source and Windows distributions for version 1.0, but I can't find any for 2.0 or 2.1. (Maybe they've been created, but haven't been linked or I just haven't been able to find them?)

Even better would be to have 1.0, 2.0, and 2.1 tags in the git repo on Github. I found 2.1 at rev 42f01f7cd6a3a456743895f3259cbbb04bb6628e, I think. So I could download that with

https://github.com/michaelcmartin/Ophis/archive/42f01f7cd6a3a456743895f3259cbbb04bb6628e.zip

but it would be much easier to read/type/remember

https://github.com/michaelcmartin/Ophis/archive/2.1.zip

I'm not sure you can actually add tags from a fork to an origin repo via a pull request on Github, but if you like, I can attempt to do so...

I'm running ophis ver 2.1 on XP.

It seems a listing is only produced if there are no errors in the assembly?

Is this by design ?

Output to the console from Ophis is currently dictated by a single "verbosity" scale. Other options are available for enabling some features (alternate chipsets). We should have individual options to control each kind of output, and to turn on or off each optional optimization pass.

When debugging code on real hardware it is nice to be able to see where in the source an address correlates to.

One way to achieve this is a label dump showing the assembled address of each label.

Another nice way is to have the disassembly output (which Ophis already produces) to be annotated with labels.

Bug regarding the BBRx/BBSx opcodes.

For those sixteen opcodes you assume the addressing mode "relative" just like the regular 6502 branch instructions. But it should rather be "zeropage, relative" mode as this is a new mode introduced by the Rockwell 65C02, so it's a three byte command taking two arguments.

Hi,
Could you be persuaded to make a new release of the current HEAD - in order to get python3 support out ?

The latest release is 2.1.1 - and that is a python2 release

That would make the work for distribution packagers easier

Thanks in advance :-)

If there's an opcode description that gensets.py fails to parse, it just doesn't incorporate that opcode into the generated Python tables. This situation should fail loudly, not silently.

X:\GIT\Ophis\src>python win_setup.py
running py2exe
running build_py
creating build
creating build\lib
creating build\lib\Ophis
copying Ophis\CmdLine.py -> build\lib\Ophis
copying Ophis\CorePragmas.py -> build\lib\Ophis
copying Ophis\Environment.py -> build\lib\Ophis
copying Ophis\Errors.py -> build\lib\Ophis
copying Ophis\Frontend.py -> build\lib\Ophis
copying Ophis\IR.py -> build\lib\Ophis
copying Ophis\Listing.py -> build\lib\Ophis
copying Ophis\Macro.py -> build\lib\Ophis
copying Ophis\Main.py -> build\lib\Ophis
copying Ophis\Opcodes.py -> build\lib\Ophis
copying Ophis\Passes.py -> build\lib\Ophis
copying Ophis_init_.py -> build\lib\Ophis
Traceback (most recent call last):
File "win_setup.py", line 10, in
console=[{'script': "scripts/ophis"}])
File "C:\Python37\lib\distutils\core.py", line 148, in setup
dist.run_commands()
File "C:\Python37\lib\distutils\dist.py", line 966, in run_commands
self.run_command(cmd)
File "C:\Python37\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
File "C:\Python37\lib\site-packages\py2exe\distutils_buildexe.py", line 188, in run
self._run()
File "C:\Python37\lib\site-packages\py2exe\distutils_buildexe.py", line 267, in _run
builder.analyze()
File "C:\Python37\lib\site-packages\py2exe\runtime.py", line 160, in analyze
self.mf.import_hook(modname)
File "C:\Python37\lib\site-packages\py2exe\mf3.py", line 120, in import_hook
module = self._gcd_import(name)
File "C:\Python37\lib\site-packages\py2exe\mf3.py", line 274, in _gcd_import
return self._find_and_load(name)
File "C:\Python37\lib\site-packages\py2exe\mf3.py", line 357, in _find_and_load
self._scan_code(module.code, module)
File "C:\Python37\lib\site-packages\py2exe\mf3.py", line 388, in _scan_code
for what, args in self._scan_opcodes(code):
File "C:\Python37\lib\site-packages\py2exe\mf3.py", line 417, in _scan_opcodes
yield "store", (names[oparg],)
IndexError: tuple index out of range

When a character replacement map is defined with the .charmap directive or similar, only the first argument in a .byte directive will actually be properly updated. All other arguments will be incorporated as strict ASCII.

Ideally, pip and poetry should be able to install and run it, and the packaged windows executables could use updates as well.

That way, "ophis whatever.oph" can produce whatever.nes or whatever.prg without any fuss.

We need a script that can handle our test suite and which will check for discrepancies.

A basic one would just check correctness of output - as the test suite evolves these should also involve ensuring errors and warnings happen exactly when they are desired.

Hello, I've wondered if someone can add 65816 (16-bit) support in the future as it has great stuff!

Otherwise, Seems Complete!

There are two issues with our current opcode/addressing mode unit tests:

• The current tests use the conceit of having each opcode repeat its opcode as an operand, which isn't sufficient to test endianness of output on its own.
• The unit tests are hand-generated instead of machine generated from the opcode specs.

gensets.py should get a companion script gentests.py to generate the test cases, and the test instructions' arguments should produce predictable bytes distinct from the opcodes themselves and from each other.

The original Ophis distribution included Windows installers and automatically generated web pages and PDFs from Docbook. Some of the basics are present in the github edition but this isn't back up to speed. While doing so, it should also be brought up to speed with the latest versions of py2exe.

What it says on the tin. Outputting to "-" should put the binary to stdout, letting ophis be used in pipes.

In order for this to not be a terrible idea we also need to ensure that all other output is to stderr.

When trying to interweave different .text segments, the Ophis object file output doesn't seem quite right, in contrast what the map file states. The latter sticks to the given source code. Example:

Code:

.text zp
.org $0000
A0:         .word $1122
A1:         .byte $05       
.checkpc $00ac

.text 
.advance $0200
B0:         .byte $91           
B1:         .byte $D7           

.text zp
testword:   .word $3344
testbyte:   .byte $AA

.text 
TESTARRAY:  .word A0, testword
TESTARRAY2: .byte A1, testbyte

LDA <testword
LDX >testword
LDY testbyte
NOP
NOP

Mapfile:

$0000 | a0         | test_V0.1.6502:3
$0002 | a1         | test_V0.1.6502:4
$0003 | testword   | test_V0.1.6502:15
$0005 | testbyte   | test_V0.1.6502:16
$0200 | b0         | test_V0.1.6502:10
$0201 | b1         | test_V0.1.6502:11
$0202 | testarray  | test_V0.1.6502:19
$0206 | testarray2 | test_V0.1.6502:20

Ophis output:

0000: 22 11 05 00 00 00 00 00 00 00 00 00 00 00 00 00 
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
...
...
01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
0200: 00 00 00 91 D7 44 33 AA 00 00 03 00 02 05 A5 03   
0210: A6 00 A4 05 EA EA  

Is there an explanation for this behaviour, for I would have expected this binary output:

0000: 22 11 05 44 33 AA 00 00 00 00 00 00 00 00 00 00 
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
...
...
01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
0200: 91 D7 00 00 03 00 02 05 A5 03 A6 00 A4 05 EA EA 

Thank you.

Ophis already includes an instruction selection pass that will map between Zero Page and Absolute addressing modes as appropriate, shifting to whatever is legal as necessary.

However, if you try to branch more than 127 bytes (or 128 backwards), you instead get an assemble-time error. The instruction selector should notice that the code is trying to do this and generate multiple instructions (a reversed branch and a jump) to make sure it's legal. This might be a warning at verbosities above 1.

We need a test suite that covers all the features Ophis provides, and ideally some ugly corner cases too, like instruction-collapse oscillation and recursive macros.

A short relative branch shows an incorrect argument, like so:

 0831  F0 DB     BEQ  $000E

We also need formal test cases for these and addressing modes unique to the 65C02 and 4502.

The 4502's Zero Page version of ASR, at a minimum, is missing from both Opcodes.py and the test cases. This is a consequence of issue #37. Other similar problems may lurk.

Firm up the opcode lists to match Mist64's documentation, cross-check with ca65, and make sure that long-form specifiers are present for all opcodes that support both ZP and Absolute documents.

Trying to setup Swift on PC to do some BBC assembler - Swift guide says use p65.py but it's not in latest archive, or if it is I can't find it?

Swift reference points to http://hkn.berkeley.edu/~mcmartin/P65 which is now dead.

I tried http://hkn.berkeley.edu/~mcmartin/P65 in the internet archive but that only let me get my hands on ophis 1.0 and even that didnt have p65.py in.

The Swift reference is pointing to P65-Ophis-0.7.2

Thanks

The -d option: "Deprecated Pragmas" - is designed for compatibility with an ancient prototype of Ophis that to my knowledge is no longer used by anyone anywhere. The design would be cleaner with these removed.