#SWEET16 WOZNIAK CODE#

New Instructions - first class extensions utilizing the 3 additional instruction slots remaining in the original specification.macro calls which simply chain Sweet16 calls to achieve a single outcome Macro Extensions - implemented as convenience.For this implementation I have added two different types of extensions:

I leave it to readers to explore further possibilities for SWEET16.'. (More information can be found in Carsten Strotmann article) detailing porting Sweet16.Īs Wozniak stated in the original article '. The registers themselves are located in zero page due to the addressing modes required.This way a jumptable can be used which only needs to specify a single byte as they all share a common high byte.

#SWEET16 WOZNIAK CODE#

In this implementation this was achieved by using Kick Assembler's !align $100 command to ensure the code was page aligned and then inserting a nop as the first address (see later). The code itself can contain subroutines outside of this however the initial jump table subroutine must sit within this page.

The implementation of all the instructions are located on the same 256 byte memory page.

One of the downsides of using the original Sweet16 implementation without convenience helpers is the fact that it is built on top of the existing 6502 mnemonics and has no native assembler support so using it requires the user to hand-roll conversion from Sweet16 to a byte sequence for use by the Sweet16 routines.Īn example of some 6502 generic code showing the equivalent Sweet16 operations in the comments:Īny implementation of Sweet16 requires a few key things. An assumption is made the reader underestands Sweet assembler. macro allowing Sweet16 programs to be more natively coded that better reflect the metaprocessor's original description. This project provides an implementation of Steve Wozniak's ' Sweet16' ported to the Commodore 64 using Kick Assembler which provides powerful scripting language features via. If a prior register operation result met a specified branch condition, the displacement was added to Sweet16's program counter, effecting a branch. The nonregister operations were primarily 6502 style branches with the second byte specifying a +/-127 byte displacement relative to the address of the following instruction. Except for the SET instruction, register operations only required one byte. The Sweet16 instructions fell into register and nonregister categories with the register operations specifying one of the 16 registers to be used as either a data element or a pointer to data in memory depending on the specific instruction. Some of the registers were dual purpose (e.g., R0 doubled as the Sweet16 accumulator). It defined sixteen 16-bit registers ( R0 to R15) which under the bonnet were implemented as 32 contiguous memory locations located in zero page. What he came up with was ' Sweet16' which he referred to ' as a 6502 enhancement package, not a stand alone processor'. In 1977, Steve Wozniak wrote an article for BYTE magazine about a 16-bit 'metaprocessor' that he had invented to deal with manipulating 16-bit values on an 8-bit CPU (6502) for the AppleBASIC he was writing at the time. Sweet16 was developed in Microsoft Studio Code using a forked Kick Assembler extension available here This project provides an implementation of a unit test style testing suite of the Sweet16 implementation which requires use of the separate fork Sweet16Core available here A Commodore 64 implementation of Steve Wozniak's Sweet16 16-bit metaprocessor processor using Kick Assembler Note ❗

Sweet16 wozniak