codex

[Ed Minchau]

So I downloaded the R39 emulator and noticed that ROM bank 7 is now CODEX, a CodeX16 Interactive Assembly Environment / Monitor.  On a whim I typed CODEX in immediate mode in the r39 emulator, and was greeted with a blank blue screen.  The only key that seemed to work was the down arrow.  I tried this several times, and sometimes the down arrow would cause a single letter P to appear at the top left corner of the screen, and turned the bottom half of the screen black.  Other times, it would print the word VERIFYING on the second line from the top of the screen.  Nothing else happened.

Is there documentation for CODEX anywhere?

[mjallison42]

Hi all, 

I've been busy this last couple of weeks and renewed activity of the ROM caught me off guard. The Codex in ROM is from July of last year. I have another large pull request to submit, I need to square that all away with the current release. I'll update the docs too. There is some older stuff on Codex at: https://sites.google.com/view/x16asmenv/home

regards,

Mike A

[TomXP411]

On 3/30/2022 at 10:54 PM, Ed Minchau said:

So I downloaded the R39 emulator and noticed that ROM bank 7 is now CODEX, a CodeX16 Interactive Assembly Environment / Monitor.  On a whim I typed CODEX in immediate mode in the r39 emulator, and was greeted with a blank blue screen.  The only key that seemed to work was the down arrow.  I tried this several times, and sometimes the down arrow would cause a single letter P to appear at the top left corner of the screen, and turned the bottom half of the screen black.  Other times, it would print the word VERIFYING on the second line from the top of the screen.  Nothing else happened.

Is there documentation for CODEX anywhere?

According to the X-16 ROM Readme, this is the assembly environment written by @mjallison42

The latest version on his web site is from 2020 and possibly not compatible with the R39 hardware. Here's the web site:
https://sites.google.com/view/x16asmenv/v0-81-beta?authuser=0

For some reason, the ROM documentation doesn't get included with the emulator:

https://github.com/commanderx16/x16-rom

and 

https://github.com/commanderx16/x16-rom/tree/master/dos

Both those are useful documentation for developers and users alike

 

[Ed Minchau]

Unfortunately,  that ROM documentation appears to be the same as what's shown in the BASIC reference, at least for codex - just stating that it exists. If it's r38 only, then it really needs to be updated.

[TomXP411]

On 3/31/2022 at 6:09 AM, Ed Minchau said:

Unfortunately,  that ROM documentation appears to be the same as what's shown in the BASIC reference, at least for codex - just stating that it exists. If it's r38 only, then it really needs to be updated.

Yes, it does, and Mike is aware. I got a response from @mjallison42, and there are more changes coming:

Quote

I will be submitting a PR next week with a series of fixes.

Mike A

-- https://github.com/commanderx16/x16-rom/pull/202

[mjallison42]

The huge bug fix went in, although I have another to submit. Docs next. Things ought to be squared away for r40.

There are still some small items to be completed, and I'll hit those after the docs. BTW, I'll submit some docs to the official doc repo too. 

[Ender]

I'm seeing a bug at the newest commit where it freezes when I try to view the disassembly at $0801.  It also seems to make it crash if I try to view it at $0.

[G David T]

On 4/14/2022 at 10:06 AM, mjallison42 said:

The huge bug fix went in, although I have another to submit. Docs next. Things ought to be squared away for r40.

There are still some small items to be completed, and I'll hit those after the docs. BTW, I'll submit some docs to the official doc repo too. 

I'm looking forward to the documentation. I'd love to see what CodeX16 is capable of.

[rje]

It's an excellent name for the product, regardless.

 

[G David T]

I've been doing some experimentation on CodeX16 without any documentation and I've noticed a few frustrating bugs.

First, I can't get ABS,Y to assemble for the zero page, so, for example, LDA $0024,Y won't assemble, instead giving me a syntax error. If I put a zero page reference through ABS,Y in through the monitor, I can get it to disassemble in CodeX16, but I can't edit it to use a different zero page address, forcing me to go back to the monitor to make such changes.

Second, relative addressing is badly flawed, requiring that the offset be on the same page as the next instruction, but also requiring that I add 2 to the target address to get the correct address. This further complicates the effort required to get the correct address. Disassembly again shows everything correctly, both target offset and offset value, but the assembly is much more complicated than it needs to be.

For example, if I'm at address $0BA7, for example, and I need to branch on equal to $0C04, I must type BEQ $0B06 to get BEQ $0C04 in the disassembly. If I'm at address $0C07 and need to get to address $0BF4 with a branch with carry clear, I must type BCC $0CF6 to get BCC $0BF4 in my actual code. And if I am at address $0B70 and need to branch positive to $0B90, I must type BPL $0B92 to get BPL $0B90 in my code.

Hope both of these issues are addressed soon. CodeX is an interesting environment and I'd like to see it improve, but I don't believe it's ready for mainstream use yet.

[TomXP411]

On 5/4/2022 at 11:56 AM, G David T said:

First, I can't get ABS,Y to assemble for the zero page, so, for example, LDA $0024,Y won't assemble,

Usually, the correct syntax for zero page address mode is just two hex digits: LDA $24,Y.

So LDA $0024,Y should actually assemble to B9 24 00. There is no LDA Zero Page, Y. 

If LDA $0024,Y is not assembling at all, this definitely sounds like a bug, because Absolute,Y is a valid address mode. 

Reference: http://www.6502.org/tutorials/6502opcodes.html#LDA

[Ed Minchau]

A5 is LDA zero page; the Y isn't involved with that command.  LDA absolute,Y is B9. LDA $0024,Y should assemble to B9 24 00.

Edited May 6 by Ed Minchau

[Ed Minchau]

On 5/4/2022 at 12:56 PM, G David T said:

I've been doing some experimentation on CodeX16 without any documentation and I've noticed a few frustrating bugs.

First, I can't get ABS,Y to assemble for the zero page, so, for example, LDA $0024,Y won't assemble, instead giving me a syntax error. If I put a zero page reference through ABS,Y in through the monitor, I can get it to disassemble in CodeX16, but I can't edit it to use a different zero page address, forcing me to go back to the monitor to make such changes.

Second, relative addressing is badly flawed, requiring that the offset be on the same page as the next instruction, but also requiring that I add 2 to the target address to get the correct address. This further complicates the effort required to get the correct address. Disassembly again shows everything correctly, both target offset and offset value, but the assembly is much more complicated than it needs to be.

For example, if I'm at address $0BA7, for example, and I need to branch on equal to $0C04, I must type BEQ $0B06 to get BEQ $0C04 in the disassembly. If I'm at address $0C07 and need to get to address $0BF4 with a branch with carry clear, I must type BCC $0CF6 to get BCC $0BF4 in my actual code. And if I am at address $0B70 and need to branch positive to $0B90, I must type BPL $0B92 to get BPL $0B90 in my code.

Hope both of these issues are addressed soon. CodeX is an interesting environment and I'd like to see it improve, but I don't believe it's ready for mainstream use yet.

That looks like the branches are being calculated from the address containing the branch command rather than the next command after the branch. Have you tried it with the BBR/BBS commands? My prediction is they'll be off by three.

[TomXP411]

On 5/5/2022 at 5:15 PM, Ed Minchau said:

A5 is LDA zero page; the Y isn't involved with that command.  LDA absolute,Y is B9. LDA $0024,Y should assemble to B9 24 00.

You're right. I misread that when I looked at it yesterday. There is no Zero Page Y-Indexed address mode for LDA. I was looking at the X-Indexed instructions.

Regardless, if LDA $0024,Y won't assemble, that is clearly a bug. Likewise, if LDA $0024,X produces a zero-page mode rather than the absolute indexed mode, that is also an error. While it's a fine point, there are reasons to produce the absolute vs zero page instruction from time time to time. The biggest reason being that if the code is intended to ever be run on a 65816, there is no Zero Page. The '816 has "Direct Page" which can actually be relocated, so $24 and $0024 are not actually the same address! So when writing an assembler, it's critical that address mode hints (two vs four digits) be followed correctly.

[G David T]

On 5/5/2022 at 7:32 PM, Ed Minchau said:

That looks like the branches are being calculated from the address containing the branch command rather than the next command after the branch. Have you tried it with the BBR/BBS commands? My prediction is they'll be off by three.

I haven't tried BBR or BBS because I'm not trying to modify bits, I'm just trying to branch on flag states. After some further research, if I'm inserting an instruction, Bxx instructions assemble fine, but if I'm editing an existing line, the bug I'm reporting always occurs.

Oddly, something appears to have happened to the ROM file, despite my not touching it, and CodeX now locks the emulator completely if I attempt to jump to access an address directly. Don't know what happened, but I'm not sure it is a problem with CodeX directly, just something that may be wrong with the emulator. Whatever the case, Monitor is not causing problems and is working fine.

[G David T]

On 5/6/2022 at 10:19 AM, TomXP411 said:

You're right. I misread that when I looked at it yesterday. There is no Zero Page Y-Indexed address mode for LDA. I was looking at the X-Indexed instructions.

Regardless, if LDA $0024,Y won't assemble, that is clearly a bug. Likewise, if LDA $0024,X produces a zero-page mode rather than the absolute indexed mode, that is also an error. While it's a fine point, there are reasons to produce the absolute vs zero page instruction from time time to time. The biggest reason being that if the code is intended to ever be run on a 65816, there is no Zero Page. The '816 has "Direct Page" which can actually be relocated, so $24 and $0024 are not actually the same address! So when writing an assembler, it's critical that address mode hints (two vs four digits) be followed correctly.

Good point. If I were writing 65816 code, I'd keep that in mind, but I'm just working specifically on x16 code, so the 'direct page' issue isn't really relevant. The main reason I'm using ABS,Y on the zero page is I'm performing a direct transfer to the zero page from indirect addresses.  My code therefore operates as thus:

     LDY #$00

    *LDA (src),Y

     STA dest,Y

     INY

     CPY #limit

     BCC -

It is being used specifically for screen blanked video tile loading or file access, so speed isn't quite as important as code density (besides which, adding an LDX #$00 before the loop and an INX inside the loop would take longer, even replacing STA dest,Y with STA dest,X).

Edited May 9 by G David T
removing a typo

[TomXP411]

On 5/8/2022 at 11:53 PM, G David T said:

Good point. If I were writing 65816 code, I'd keep that in mind, but I'm just working specifically on x16 code, so the 'direct page' issue isn't really relevant

Right... you can do it whichever way you like, but the assembler had better be doing exactly what you tell it. 

Going back to your earlier comment, you said "First, I can't get ABS,Y to assemble for the zero page, so, for example, LDA $0024,Y won't assemble,"

If LDA $0024,Y is not assembling to $B9 24 00 (or at all), that's an error. 

If LDA $0024,X is not assembling to $BD 24 00, that's an error. 

If it's going to follow correct 6502 conventions, there should be no situation where CodeX generates a zero page address with a 4-digit operand.

It's worth following up with @mjallison42 to see what CodeX is supposed to be doing and see if maybe there's a UI bug.

 

 

[desertfish]

On 5/9/2022 at 9:19 AM, TomXP411 said:

If LDA $0024,Y is not assembling to $89 24 00 (or at all), that's an error.

That should be opcode $B9 instead.

[TomXP411]

On 5/9/2022 at 2:26 AM, desertfish said:

That should be opcode $B9 instead.

89...B9... what's a digit or two among friends?

[desertfish]

The discussion above prompted me to check the behavior of my File based Assembler and yup, it failed to assemble LDA $0024,Y as well thinking it is LDA $24,Y which is an unexisting addressing mode.   This has now been fixed, but was an interesting case!

[Ed Minchau]

On 5/10/2022 at 8:05 AM, desertfish said:

The discussion above prompted me to check the behavior of my File based Assembler and yup, it failed to assemble LDA $0024,Y as well thinking it is LDA $24,Y which is an unexisting addressing mode.   This has now been fixed, but was an interesting case!

The discussion above is precisely why the META/L editor uses unique 4 character codes for each command, with the fourth character indicating the addressing mode.  No ambiguity and no need to parse the parameter to figure out what the command is.

And it's through my update to that editor that I was searching through ROM bank 08 and found some code that isn't in any of the documentation.  Is that code an extension of CODEX?

[Ender]

On 5/21/2022 at 3:14 AM, Ed Minchau said:

The discussion above is precisely why the META/L editor uses unique 4 character codes for each command, with the fourth character indicating the addressing mode.  No ambiguity and no need to parse the parameter to figure out what the command is.

And it's through my update to that editor that I was searching through ROM bank 08 and found some code that isn't in any of the documentation.  Is that code an extension of CODEX?

A while ago Michael moved the code for the "TEST" command there, which tests various BASIC commands used in SCREEN 128 mode.

[G David T]

Just installed v41 and immediately attempted to access CODEX. I got to ASM and changed memory addresses, but as soon as I attempted to move the cursor, the emulator crashed with the attached data dumped. Not sure what caused the issue, or if this is where the error report needs to go, but considering CODEX was in use, I thought it might be best to report here. I'll also send this report to the emulation crash report thread for version 41.

dump-2.bin