That can be extremely frustrating. [Off-topic but slightly-related] I have been working as an auto technician in poor neighborhoods for my entire career, and I have learned to dread seeing the word "sometimes" noted anywhere on the incoming diagnostic work orders.

Mike B.

http://exifpro.com/downloads/6502_1.2.12.zip

Checking my notes actually there is a bug with BIT immediate. It sets NV flags but it shouldn't. TRB and TSB should be O.K. however.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I KNEW IT
Anyway, just wrote a small 3 command shell for the JudyOS. It allows to shutdown the system safely with the "down" (shutdown) command, and execute with "exec" (execute). If a task doesn't start with BRK, it will show up under "tlst" (tasklist).
Note: all things in parentheses aren't the actual commands, just how they're supposed to be pronounced.

I doubt that this causes your problem unless you are actually relying on keeping N & V flags from a previous instruction. Usually nobody does that as the BIT abs and BIT zp do alter NV based on the operand. In BIT immediate the operand is known at assembly time and it makes no sense to set NV according to bit 7 & 6 of the immediate operand. NV would always be the same after a BIT immediate with a predefined operand.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Go here.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I would agree 100% if there was an SEV instruction.

Mike B.

Really? Probably just my version then.

Thanks!

Okay, so I would love to see a text-editor in the near future along with a macroassembler, both for operation on JudyOS. That would be awesome to see such a routine collection so the user can write his/her own tasks! Does anyone know the best way to do this? Do I just write my own code to store a source code buffer into $1000-$1FFF, then make an assembler in another task space? OR, is it possible to fit a text editor AND an assembler in the same task (aka: has someone done this before without kernel calls that I can port it to JudyOS within 4K of program space?)

It would be interesting to hear of another, more compact, example of a native code editor and macro assembler, but as an existence proof I can tell you that Acorn's BBC Micro can do this: the Basic is 16k and contains an assembler, and I believe there's an EDIT application for a 16k ROM slot. Not sure if it uses all 16k, but just possibly we're talking about a total of 32k of program space! (There's also a Basic Editor which might or might not be the same thing. See here.)

Yeah, that's terribly large. My macro assembler will actually support 6K of a text file now, but no text comments! This should make it SUPER small....
Hopefully.
Anyway, when it assembles the text, it will store it into task 7, in hopes that it can run it immediately.

You might want to look into Forth, which from its beginning, normally did its own editing, file operations, assembling, compiling, etc., in a very small memory footprint. I use it regularly, although I have not been using an editor written in it. The standard book to get started in it is "Starting Forth" by Leo Brodie who's kind of a comedian. It's entertaining, and was very easy for me to understand. I picked it up and just flew with it. You can read it free at https://www.forth.com/starting-forth/ which has a few updates but still has the original cartoons. Forth originally used 1KB blocks for source code but I think normal text files (which I use) are much more common today for Forth source code. I wrote my own assembler in Forth, and in its original, simple form took me one evening to write. I later realized that macro capabilities were innate, since the Forth system was already there and you could take advantage of its capabilities to make decisions, write its own code per your direction, etc..

Regardless of language though, I think 4K will be too limiting for some tasks. You could split a program into multiple tasks, but it would just add complexity. Perhaps you could leave the option for a task to take multiple 4K sections without splitting it up.

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

In the original Apple ][ ROMs, Mr. Wozniak provided us with a no-frills disassembler and a no-label mini-assembler, all in less than 850 bytes of machine code and data. It would take a bit of talent to enhance it to suit your needs, but it's certainly doable, and might be a fun starting point as it is.

I was thinking of encouraging you to experiment with VTL02 as a task, but it is a bit of a resource hog, needing half of page zero and up to about half of page one for its run-time.

Mike B.

Actually mine is probably going to still have labels to make it easy to deal with, but still within 2K of space so far!
I don't have it working yet, because it isn't complete.

Edit: No more labels! It was too much for the code's walk-through for me.

The problem with the 4K isn't the code so much (though certainly a factor), it's the data.

But if you had one task dedicated to the editor (and it's data), one task dedicated to the assembler, and one task as the target for the assembler, you could probably do quite a bit.

The editor would share it's work space with the file to be edited. If it's dedicated to assembly, then you can tokenize stuff and thus reduce the memory footprint. That would also simplify the assembler (since the need for a parser is reduced, though, honestly it's mostly just been moved to the editor). I think you could do an assembler in 4K, including support for labels, you just make it a single pass assembler. Any work data for the assembler is done in the targeted tasks space (rather than within the assemblers task space). Since it's quite unlikely that 4K of source code is going to render down to 4K of machine code, there is space available in the destination for work data structures used by the assembler. And if you run out of space? Well, life in the big city.