Commander X16

On 1/6/2022 at 9:20 PM, rje said:

So I was looking at the opcode set for SWEET16, and reading the descriptions, and thinking about SUB versus CPR.



SUB does a twos-complement add.  CPR does a binary subtract.  The code in fact overlaps significantly:



***



SUB:    LDY  $0             ;RESULT TO R0

CPR:    SEC                 ;NOTE Y REG = 13*2 FOR CPR

        LDA  R0L

        SBC  R0L,X

        STA  R0L,Y          ;R0-RX TO RY

        LDA  R0H

        SBC  R0H,X

SUB2:   STA  R0H,Y

        TYA                 ;LAST RESULT REG*2

        ADC  $0             ;CARRY TO LSB

        STA  R14H

        RTS



***



 



So my question is this:  maybe I can free up an opcode slot by not having SUB?  Especially if CPR puts its result in R13, and is therefore accessible as a difference value.



Haven't thought it through fully, but it seems that the two values are related enough.  Of course perhaps Woz did this because there wasn't another op that he wanted badly enough to get rid of SUB?

Because the purpose of Sweet16 is most often to write very compact "setup" type code ... you are not intended to use Sweet16 inside inner loops executed many times, but in one-off startup processes that would take much more space in 6502 binary code but since its only executed once, using Sweet16 doesn't have much runtime impact.

If you are USING the result of the subtraction, you will typically need the result in the accumulator ... even if you want the result somewhere else, you will need it in the accumulator before "putting it somewhere else", so will have to follow, eg, CPR R5 with LD R13, wasting a byte in your Sweet16 code for every subtract operation.

Plus, what other SINGLE "register" operation do you need? There are already three spare non-register ops, and any of those COULD be implemented with an operand that refers to one register ... or even two registers. For instance, you could SWAP two registers with the source register index in the low nybble of the operand byte and the destination register index in the high nybble, or multiply two registers with the 32bit result replacing the operands in a similar way. Or you could have shift left and shift right with the low nybble giving the register and the high nybble giving the number of shifts, from 0 to 15.

Edit: Actually, I may have convinced myself to substitute the extensions I have in the current source WITH those three ... a register swap and binary shift left and right.

On 1/9/2022 at 12:12 PM, BruceMcF said:

Edit: Actually, I may have convinced myself to substitute the extensions I have in the current source WITH those three ... a register swap and binary shift left and right.

There ya go. 

On 1/8/2022 at 6:19 PM, rje said:

Wait wait, this is an error?  This is the "source" of the source.  It's wrong?



http://www.6502.org/source/interpreters/sweet16.htm#Sweet_Sixteen_Source_sheldon



Ahhh, it IS a transcription error!



The original was LDY #$0.  Wow!



And here's Woz' article in Byte magazine... the source of that page on 6502.org.  The LDY $#0 is on page 152, about halfway down. 



https://archive.org/details/BYTE_Vol_02-11_1977-11_Sweet_16/page/n153/mode/1up



 



This listing has that line correct.  But, I suppose I have to check the remaining lines for errors!



http://www.easy68k.com/paulrsm/6502/SW16RB.TXT

Yeah, SUB in the SweetCX16.s file is very different from the other three sources listed.  It's using X and Y differently too.  There are significant differences throughout the code, presumably to take advantage of the 65c02 commands like BRA.

On 1/10/2022 at 1:45 AM, Ed Minchau said:

Yeah, SUB in the SweetCX16.s file is very different from the other three sources listed.  It's using X and Y differently too.  There are significant differences throughout the code, presumably to take advantage of the 65c02 commands like BRA.

I would expect that too.  Good!

 

Okay, I've visually checked Woz' article with this file http://www.easy68k.com/paulrsm/6502/SW16RB.TXT and they look the same, excepting context such as start address and the added copyright notice to the URL listing. 

Of course I can't guarantee that I didn't miss something.

 

On 1/10/2022 at 2:45 AM, Ed Minchau said:

Yeah, SUB in the SweetCX16.s file is very different from the other three sources listed.  It's using X and Y differently too.  There are significant differences throughout the code, presumably to take advantage of the 65c02 commands like BRA.

There ought to be differences throughout ... it is not attempting to be a port of Woz's code, it is attempting to be an open source VM that executes Sweet16 source, and beyond that is explicitly focusing on using a faster approach routine dispatch.

And in part it is explicitly pursuing a different speed / codesize tradeoff than Woz's Sweet16 because I doubt I could pursue Woz's specific goals and do any better than he did.

 

On 1/10/2022 at 5:50 PM, BruceMcF said:

There ought to be differences throughout ... it is not attempting to be a port of Woz's code, it is attempting to be an open source VM that executes Sweet16 source, and beyond that is explicitly focusing on using a faster approach routine dispatch.



And in part it is explicitly pursuing a different speed / codesize tradeoff than Woz's Sweet16 because I doubt I could pursue Woz's specific goals and do any better than he did.

Ed and I were comparing original source to original "source"... turns out SWEET16 itself either has variations or typos in the wild.

I get that yours is an open-source implementation of the API.  It's also more likely to work for me than the original.

On 1/10/2022 at 5:50 PM, BruceMcF said:

There ought to be differences throughout ... it is not attempting to be a port of Woz's code, it is attempting to be an open source VM that executes Sweet16 source, and beyond that is explicitly focusing on using a faster approach routine dispatch.



And in part it is explicitly pursuing a different speed / codesize tradeoff than Woz's Sweet16 because I doubt I could pursue Woz's specific goals and do any better than he did.

 

Given your suggestions about better use of SWEET16 -- i.e. as a setup rather than something for inner loops -- maybe there's not much benefit to using something like it to replace bits of the KERNAL.  Except for KERNAL routines used for system initialization, of course.

 

On 1/12/2022 at 10:01 AM, rje said:

Given your suggestions about better use of SWEET16 -- i.e. as a setup rather than something for inner loops -- maybe there's not much benefit to using something like it to replace bits of the KERNAL.  Except for KERNAL routines used for system initialization, of course.

Yes, that's the basic idea ... routines used for system initialization. The original Sweet16 saved more space in the Apple ROM(s?) than Sweet16 used, so it was in a "free" resource in a space consumption sense, at a time when ROM cost much more per KB than it does today.

In the context of the X16, the most appealing aspect may be the ability to conserve on relatively scarce Low RAM if a Sweet16 VM is available.

On 1/12/2022 at 3:23 PM, BruceMcF said:

Yes, that's the basic idea ... routines used for system initialization. The original Sweet16 saved more space in the Apple ROM(s?) than Sweet16 used, so it was in a "free" resource in a space consumption sense, at a time when ROM cost much more per KB than it does today.



In the context of the X16, the most appealing aspect may be the ability to conserve on relatively scarce Low RAM if a Sweet16 VM is available.

I'm still thinking that a 16K ROM bank could benefit from Sweet16... assuming that you only want to work with that 16K, and assuming you've got more stuff to put in that 16K than you would normally be able to squeeze into it.

If the 6809 sold at the same price or less than a 6502, would Sweet16 even exist?