Looking for Baum's tiny assembler on Apple-1

[BigEd]

Maybe this tactic for licensing: be free with any aspect you might have created or added. You waive all rights you have, and say nothing about anyone else's rights.

Quote:

Copyright by Mike and other original contributors.
To the extent possible under law, Mike has waived all copyright and related or neighboring rights to this work. See the CC0 Public Domain Declaration.

[barrym95838]

Thanks, Ed. I will feel slightly less uneasy when (and if) I add the 65c02 functionality, but until then I will add "MODIFICATIONS MADE IN 2020 ARE FREE TO USE WITH ATTRIBUTION" at the minimum and carry on.

[Edit: it looks like adding BRA, TSB, PHX and PLX should be pretty easy, because there's room for them in the existing table. TRB, PHY, PLY and STZ are going to require much more effort, so I think I'll slide this to the back burner for now ...]

[mvk]

I guess there won't be many Apple-1's with a CMOS processor, and software that uses it.

[barrym95838]

mvk wrote:

I guess there won't be many Apple-1's with a CMOS processor, and software that uses it.

I don't have a count, but I have been led to believe that there are a significant number of 'c02 powered A1 clones. Software would certainly be better served by playing to the lowest common denominator (mine even purposely avoids ROR), but I was thinking that other hobbyists might find interest in porting the work to their own 'c02 machines.

[cjs]

barrym95838 wrote:

I don't have a count, but I have been led to believe that there are a significant number of 'c02 powered A1 clones.

I would not be surprised. My RC6502 Apple 1 Replica (the SBC version, anyway) specifically has pin 36 pulled high (for BE on W65C02) and a jumper to allow disconnecting pin 1 from Vss (for vector pull output), both to support the ultra-modern WDC processors. And let's face it, not only are the CMOS parts easier to source, but the Apple 1 in any form is generally at least moderately hacked anyway if someone's making serious use of it.

Quote:

Software would certainly be better served by playing to the lowest common denominator (mine even purposely avoids ROR)....

That's dedication! Not even I go that far, and I still have to put up with seemingly everybody telling me I should be writing for 65C02, if not 65816. So many kids these days only willing to use the modern stuff....

[barrym95838]

"Ultra-modern" and "serious use" gave me the two biggest smiles of the day. Thank you.

[mvk]

I started to transcribe your work. There's nice material in there for code archaeologists. For example, this snippet which you faithfully glued together from two scattered pieces on the Gayler tape:

Code: Select all

3CDB:A8       \   TAY            ;
3CDC:4A       \   LSR            ; EVEN/ODD TEST
3CDD:90 0B    \   BCC   IEVEN    ;
3CDF:4A       \   LSR            ; BIT 1 TEST
3CE0:09 80    \   ORA   #$80     ;   (BECAUSE ROR BUG)
3CE2:B0 15    \   BCS   INVLD    ; XXXXXX11 INVALID OP
3CE4:C9 A2    \   CMP   #$A2     ;
3CE6:F0 11    \   BEQ   INVLD    ; OPCODE $89 INVALID
3CE8:29 87    \   AND   #$87     ; MASK BITS

Compare that to how it appeared in DrDobbs:

[barrym95838]

I think I know what happened there. Woz had a sharp eye for size optimization, and Apple ][s no longer had to avoid the ROR bug, so he modified the earlier DrDobbs code to eliminate the ORA #$80 and save two bytes in the Apple ][ monitor. Back-porting the ROR code to the Apple 1 required putting the ORA #$80 back in, but it ended up in a slightly different spot.

[mvk]

I transcribed it to the Gigatron and for as far as I can see, it works now.

There are some small mods I messaged you about. And there are some small open issues mentioned in the comments. Mine is now a mix between the DrDobbs version and your work. More things are slightly different. Most notably the nibble order in some of the tables. Luckily the assembler doesn't access those directly.

This version won't run on a real Apple-1 (yet), because I don't have good-enough $D010/$D011 emulation. So for input it calls a Gigatron-specific routine. But I do have some ideas on how to restore compatibility.

https://github.com/kervinck/gigatron-ro ... 8e9b25b0f3

[mvk]

I now settled on $EEE as the mini-assembler's entry address. I mapped the code from $C8A..$FDD to do this, and moved the PCADJ routine to free up this nice address without creating a gap.

So the whole package is just 852 bytes, fantastic!

I also added software-based PIA chip emulation. The Gigatron kernel now has a vertical blank interrupt that can be used to emulate the PIA chip. The interrupt capability was added with this "application" in mind . PIA emulation isn't 100.00% accurate, but good enough to fool most A1 programs. You can read and write to KBD/KBDCR/DSP and (almost) get what you would expect.

[Edit: typo TIA -> PIA]

[BigEd]

(Hmm, TIA is from the world of Atari - what's the glue which connects the Apple-I application with the TIA output?)

[Chromatix]

Right, there's no TIA in an Apple 1. The keyboard and display hardware are both interfaced to the CPU bus through a 6820 PIA, which has no timer hardware. (The 6821, 6520 and 6521 are all software and pin compatible with this, with minor differences in electrical properties; WDC still makes a 65C21.)

The Apple 1 display is a little weird in that it is essentially a glass TTY; as far as I know it supports only a 6-bit version of ASCII plus carriage-return. Due to its implementation using a (relatively) big FIFO to store the displayed characters, it has to wait for the scanout position to reach the cursor before the character latched in the PIA port can be transferred to it. Only then is an acknowledge signal sent back to the PIA, allowing the CPU to latch another character. This effectively reduces the display throughput to about 600 baud (one character per refresh).

[mvk]

BigEd wrote:

(Hmm, TIA is from the world of Atari - what's the glue which connects the Apple-I application with the TIA output?)

That was a typo, already fixed it.

Chromatix wrote:

This effectively reduces the display throughput to about 600 baud (one character per refresh).

Indeed, by emulating the PIA our terminal output went down to the original 60 chars/second. I like it.

[BigEd]

Ah, that makes sense! I was thinking of racing the beam on an Apple 1 but that didn't mesh with the idea of existing software...

[mvk]

BigEd wrote:

Ah, that makes sense! I was thinking of racing the beam on an Apple 1 but that didn't mesh with the idea of existing software...

[offtopic] Atari 2600 programmers had it easy with their TIA chip. It took care of an entire scan line while their software could do something else. They even didn't have to bother with getting the horizontal sync pulse out on time. Gigatron programmers don't have any such luxury if they want to write native code. The video chip has memory for 1 pixel, and all syncs must come from software. Now that is racing the beam! [/offtopic]