6502.org

(Just in case you didn't see it, there's a collection of Apple 1 tape images here
https://www.scullinsteel.com/apple1/tapes/
)

My best reason for checking out those tape images would be to ensure that my modifications don't interfere with the operation of any of the programs therein. In addition to expunging all the useless A2 screen code, I'm working on eliminating all the A2 cassette interface code and just hooking into the Apple 1 routines, since I have a feeling that the formats may be similar but not 100% compatible (the Apple 1 cassette interface appears to have 256 bytes of ROM at $C1xx that I should be able to utilize).

[Edit: Yeah, the tape formats are somewhat different: aside from slight timing differences, the A2 has a primitive 8-bit checksum for error detection and the A1 has no error detection at all. The A1 ROM routines can't be called in situ (because they don't RTS), but I replaced the A2 subroutines with slightly-modified A1 routines. After I get all of my modifications debugged as well as I can, I'm going to try squishing everything into 2 (or possibly 1.75)KB.]

I'll wait to see what you cook up! Would you announce in case you stall, because then I will take over. Having said that, for my purpose (="running the mini-assembler in the Gigatron's Apple-1 emulation"), I don't necessarily need to integrate the rest of the Apple-2 monitor. Actually, I will likely strip that because of ROM space pressure, which is part of the reason I'm less interested in KRUSADER. So for me that would be a relatively small project of 2 to 3 evenings. Being able to type lines of mnemonics and getting them translated to memory is icing on the Gigatron's 6502 emulation cake.

You know we too well, sir! I will do you the courtesy of sharing my attempt before this weekend, ready or not.
Understood. Woz made some interesting choices when he coded that monitor ROM, and I can't help but feel that he was going so fast that he didn't have time to pause and reflect on some of those choices. Anyway, I already eliminated "ctrl-K", "ctrl-P", "N" and "I" because !APPLE1, but you are interested in mini-assemble, "L", ".", ":", and "G", and you're not interested in "S", "T", "R", "W", "ctrl-Y", "ctrl-E", "ctrl-B", "ctrl-C", "M", "V", "+" and "-", correct?

Indeed. Mini-assembler is disjoint from the rest of the monitor. '!$' feels so weird.
Even less . WozMon itself already does examine and deposit with its own '.' and ':'.

I plan to catch Ctrl-C and map it to a jump to $ff00, by means of a virtual interrupt outside v6502 land. That means that it is easy to drop back into WozMon.

'!addr:' (colon!) for assemble and '!space' for assembling the next one are central for the experience.

'*addrL' for disassemble is a bit nicer than the DrDobbs method, which is setting an address in ZP and then jumping to the disassembler. But it may be the only interesting *-command, and that becomes weird as well. Perhaps we should change it to '!addrL' for this purpose.

'*addrG' is only nice if code can return with RTS. WozMon-R doesn't do that. If 'G' also doesn't have that, there's no point. But like L, it might make more sense to bring this under the !-prompt as '!addrG'

Summarising, I'm looking for no more than this:

I had a similar idea. My uart service routine checks for ctrl-c and ctrl-z. If it matches the uart buffers are cleared and it jumps to warm boot or cold boot respectively.

Okay, got it. I'll set it up so that something like FEEER (or 0EEER) from WOZMON drops you to the "!" prompt, and you can assemble and do "L" and "G" from there, but you "CTRL-C" or F800G back to WOZMON for deposit and examine. I'm thinking that I may be able to fit the code and tables inside 768 bytes, but I won't know for sure until I try.

[Edit: well, "G" is gone, replaced with "Q" (or whatever other char you prefer). I have ":", " ", "L" and "Q" ... ":" must be preceded by an address, " " and "Q" must be at the head of the input, and "L" can go either way.]

After 44 years, the mini-assembler is still under active development!

Will the disassembly automatically go to the next bunch of instructions when repeating the 'L' command without address? Both the Apple II version and the DrDobbs version do this. The latter with WozMon-R of course.

Yes. 'L's won't be able to string together on one command line like the Apple ][, but each successive naked 'L' will disassemble the next 20 instructions, in the same way that ' ' assembles the next instruction.

[Edit: well, 768 bytes is off the table, but my first raw translation attempt is complete and weighs in at a not-so-heavy 900 bytes total for everything, including all the mnemonic and address mode tables for the NMOS instruction set. Getting ready to throw some tests their way ... I'm going to use AppleWin on "original Apple ][" setting for debugging ...]

[Edit 2: ':' and ' ' are now synonyms, and an empty line exits to WozMon. It's down to 874 bytes, but still needs debugging ... I'm done for the night ...]

Well, it was a rewarding journey! I'll fill in the details of the levels of my insanity later, and you all are invited to laugh at me for the ridiculously obtuse manner in which I did it, BUT I DID IT!

The .txt file is actually a manually-created .lst file that has been hand-crafted so that it can be copied and pasted directly into an original Apple ][ monitor (if you don't use the original you may wind up with some zero-page conflicts). Please ignore the many beeps while pasting (I was on AppleWin, so I cranked up the speed to where it was just a light high-frequency buzz). From the Apple ][ monitor, 3F00G into WozMon, and play around with it for a minute. When you're ready for extended fun, 3DDDR into the extended '!' prompt. An empty line returns you to WozMon, but before you go, try a 300L or a 3000:LDA 9876,Y to see how it goes!
Cheers! It's past my bedtime again ...

[Edit: my second upload was slightly corrupted for some unknown reason. I repaired it and re-uploaded. My apologies.]
[Edit2: I replaced my upload above with another updated (and smaller) version.]

> I DID IT!
Splendid, and well done! I'm not in a position to test it right now...

Hurray! This will be no more than 1 evening to transpose to the Gigatron for testing.

P.S: I would certainly not forget to include Allen Baum in the credits. It is originally his code. Woz made it smaller.

Ah, will do, Marcel. I'm at work right now, but I'll take care of the credits tonight and re-submit. I am pretty sure that there are a few more bytes to shave, and the zero-page variables can be overlapped a little better, but that's a future endeavor ... along with including 'c02 functionality!

Did you or anyone else find any bugs yet? I was dead tired when I got it going late last night, and I couldn't check it out thoroughly.

[Edit: the file is updated. Work is a bit slow today.]

First I have to transcribe and relocate ZP for the TTL computer. Of course, I already have the disassembler and wozmon done from previous efforts, so it's only 250 extra bytes to be added. It doesn't help it's tax season over here. Still I expect results well before the end of coming week...

I trimmed 25 more bytes of fat from the code, so it now weighs in at 625 bytes of instructions for the mini-assembler, disassembler and "mini-shell" (plus 222 bytes of tables and 28 bytes of WozMon code). I will test it a bit more carefully before I upload it.

Something is itching in the back of my head, and maybe you all can help me decide how to freely share my effort with the rest of the world. I obviously shouldn't try to license the code in its entirety because I didn't invent the internal algorithms ... any ideas?

[Edit: my trimmed code still has a bug or two, but I'll try to get it ironed out and upload it to replace the xwoz.txt file above.]