What do the operands and symbols mean? Anyone?

[barrym95838]

Charlie has an enlightening and entertaining SWEET16 article here.

[Jmstein7]

cjs wrote:

After a wrong turn with the sweet16.txt source, I dropped the SW16RB.TXT source into the src/woz/ subdir of my 8bitdev repo, tweaked it to build with Macroassembler AS, and set up a couple of unit tests. One test just sets up a Sweet 16 RTN and runs the interpreter on it, mainly to make sure that it's correctly built and loaded into the simulator. The second test is the memory copy example given in the Sedgewick article.

Assuming the overall 8bitdev framework is working for you, it's pretty simple to add a new test or modify an existing text to run whatever Sweet 16 code you care to and examine the results on registers or memory. If anybody's playing with this (or wanting to play with it) and having difficulty, drop me a PM and I'll help you out with any problems you're having.

Great repo!!! I just checked it out!

[Jmstein7]

Do the variables for acc xreg and yreg need to go in RAM?

Code: Select all

 ;-------------------------------
 ACC    .BYTE 0
 XREG   .BYTE 0
 YREG   .BYTE 0
 STATUS .BYTE 0

[barrym95838]

If you want them to act like variables (and not constants or random number generators), then they should definitely be in RAM ...

[Jmstein7]

barrym95838 wrote:

If you want them to act like variables (and not constants or random number generators), then they should definitely be in RAM ...

I think it's time for a new thread.

[cjs]

In case it's helpful, that new thread is here: Woz Sweet16 Redux. Can anyone get this working?.

[BigDumbDinosaur]

Jmstein7 wrote:

BigDumbDinosaur wrote:

...and if all else fails and you are desperate for 16-bit operations, you could consider the 65C816...

Lol - and what fun would that be?

All depends on how you define "fun."

Way back in the day, I tried to implement Sweet16 on the Commodore 128. It was a battle of trying to find enough zero page to handle the "registers." Not helping was Sweet16 was Apple-centric, which complicated things more. I finally concluded that Sweet16 was a solution in search of a problem, especially when considered against what could be accomplished with judicious use of assembler macros, even on an eight-bit processor.

[cjs]

BigDumbDinosaur wrote:

Way back in the day, I tried to implement Sweet16 on the Commodore 128. It was a battle of trying to find enough zero page to handle the "registers."

Well, there's a ton of room in the cassette buffer, though of course there's always competition for that. Did you consider just halving the number of registers?

Quote:

Not helping was Sweet16 was Apple-centric, which complicated things more.

I'm definitely interested to hear what problems you found in this area, since if I use Sweet 16 or anything similar it would probably not be on an Apple.

Quote:

I finally concluded that Sweet16 was a solution in search of a problem, especially when considered against what could be accomplished with judicious use of assembler macros, even on an eight-bit processor.

Well, for you perhaps. But it actually seems to have worked pretty well for a good number of utilities related to Apple's Integer BASIC. (It might well have done so for Applesoft, too, but it was not put in the Applesoft ROM.) Also, I think it may have helped that back in the day when this was used (late '70s) macro assemblers were not widely available to microcomputer users and memory was considerably tighter than it was even just a couple of years later. (Not so many people now seem to consider a 4K system a reasonable target, and an 8K system to be fairly expansive.)

[drogon]

cjs wrote:

BigDumbDinosaur wrote:

Way back in the day, I tried to implement Sweet16 on the Commodore 128. It was a battle of trying to find enough zero page to handle the "registers."

Well, there's a ton of room in the cassette buffer, though of course there's always competition for that. Did you consider just halving the number of registers?

Quote:

Not helping was Sweet16 was Apple-centric, which complicated things more.

I'm definitely interested to hear what problems you found in this area, since if I use Sweet 16 or anything similar it would probably not be on an Apple.

Quote:

I finally concluded that Sweet16 was a solution in search of a problem, especially when considered against what could be accomplished with judicious use of assembler macros, even on an eight-bit processor.

Well, for you perhaps. But it actually seems to have worked pretty well for a good number of utilities related to Apple's Integer BASIC. (It might well have done so for Applesoft, too, but it was not put in the Applesoft ROM.) Also, I think it may have helped that back in the day when this was used (late '70s) macro assemblers were not widely available to microcomputer users and memory was considerably tighter than it was even just a couple of years later. (Not so many people now seem to consider a 4K system a reasonable target, and an 8K system to be fairly expansive.)

Many reasons for it not being in Applesoft - ROM space was one, the other is that Applesoft uses Zero page seemingly at random... I know there was work to sanitise EhBASIC's Zero page usage - which is good in that it's now in one well-defined block, but Applesoft? It's evaded me so-far (however it's not a terribly high priority) Sw16 needs 32 bytes of consecutive ZP RAM - by default at 0.

-Gordon

[cjs]

drogon wrote:

...that Applesoft uses Zero page seemingly at random... I know there was work to sanitise EhBASIC's Zero page usage - which is good in that it's now in one well-defined block, but Applesoft? It's evaded me so-far....

Well, Applesoft was built from the same source as several other versions of 6502 BASIC (including KIM, OSI and PET; lots of ifdefs and the like there), and 6502 MS BASIC itself was the third port of MS BASIC and the second port to use a zero page (after 6800), and by this time work started on Applesoft there had no doubt been at least a half dozen people who had done major work on various parts of the code. So it's no surprise that the ZP usage is a bit of a mess. And without good test systems for the various platforms, I very much doubt anybody was wanting to touch anything they didn't have to.

[drogon]

cjs wrote:

drogon wrote:

...that Applesoft uses Zero page seemingly at random... I know there was work to sanitise EhBASIC's Zero page usage - which is good in that it's now in one well-defined block, but Applesoft? It's evaded me so-far....

Well, Applesoft was built from the same source as several other versions of 6502 BASIC (including KIM, OSI and PET; lots of ifdefs and the like there), and 6502 MS BASIC itself was the third port of MS BASIC and the second port to use a zero page (after 6800), and by this time work started on Applesoft there had no doubt been at least a half dozen people who had done major work on various parts of the code. So it's no surprise that the ZP usage is a bit of a mess. And without good test systems for the various platforms, I very much doubt anybody was wanting to touch anything they didn't have to.

I have all the published sources, etc. and I'm keen to get Applesoft running on my own Ruby systems for personal/historical reasons - I have had it running but some of it's use above $90 clash with bits of RubyOS that make it a little unstable. (RubyOS leaves $00 through $8F free for applications in the same way the Acorn MOS does). I'll get there one day, unless someone does it first.

-Gordon

[Jmstein7]

cjs wrote:

In case it's helpful, that new thread is here: Woz Sweet16 Redux. Can anyone get this working?.

Whoops. Thanks, cjs.

[BigDumbDinosaur]

cjs wrote:

BigDumbDinosaur wrote:

Way back in the day, I tried to implement Sweet16 on the Commodore 128. It was a battle of trying to find enough zero page to handle the "registers."

Well, there's a ton of room in the cassette buffer, though of course there's always competition for that. Did you consider just halving the number of registers?

As I (somewhat dimly) recall, Sweet16 expected its "registers" to be on zero page. Also, I usually had an M/L keyboard input routine running in the cassette buffer, so it was seldom unoccupied space.

Quote:

Quote:

Not helping was Sweet16 was Apple-centric, which complicated things more.

I'm definitely interested to hear what problems you found in this area, since if I use Sweet 16 or anything similar it would probably not be on an Apple.

I no longer recall the details (after all, it was some 35 years ago), but I think there was some sort of Apple ROM dependency that was getting in the way.

Quote:

Quote:

I finally concluded that Sweet16 was a solution in search of a problem, especially when considered against what could be accomplished with judicious use of assembler macros, even on an eight-bit processor.

Well, for you perhaps.

Well, my software development activity is mostly for my benefit. My conclusion was based upon what I wanted to achieve. Try not to be so combative...

Quote:

But it actually seems to have worked pretty well for a good number of utilities related to Apple's Integer BASIC.

I'm sure it did, else Wozniak wouldn't have expended the effort to write it. I thought it would be useful to me when I started doing Lt. Kernal development, since there was a lot of 16-bit arithmetic involved. However, it was around that time that I acquired the HCD65 assembler for the C-128, which had good macro facilities. I was able to use macros to assist with the 16-bit stuff, eliminating the need for Sweet16.

Quote:

Also, I think it may have helped that back in the day when this was used (late '70s) macro assemblers were not widely available to microcomputer users and memory was considerably tighter than it was even just a couple of years later. (Not so many people now seem to consider a 4K system a reasonable target, and an 8K system to be fairly expansive.)

Yes, I recall those days, as I have been writing 6502 code since 1977. The crossassembler that I used back then was quite limited compared to what was later available...no macro language, in particular. It wasn't interactive as well...it ran on the IBM S370 mainframe and input was via punch card. More than once I had a deck of cards mangled by the card reader...I was elated when I finally got a terminal and could actually edit my code in real time.

[Dr Jefyll]

BigDumbDinosaur wrote:

I finally concluded that Sweet16 was a solution in search of a problem, especially when considered against what could be accomplished with judicious use of assembler macros

Assembler macros are a valid solution and so is Sweet16, but they have different sets of strengths and weaknesses. Hence, the choice of one or the other will and should vary according to prevailing circumstances. Calling Sweet16 "a solution in search of a problem" has potential to sound dismissive (unless you qualify by saying, "a solution in search of a problem where my own needs are concerned").

-- Jeff

[cjs]

BigDumbDinosaur wrote:

I no longer recall the details (after all, it was some 35 years ago), but I think there was some sort of Apple ROM dependency that was getting in the way.

That sounds like it was the SAVE and RESTORE routines, which are the only things external to Sweet 16 that get called. Those are pretty simple, and also quite safely replaced with RTSs or the calls removed completely if you need not preserve registers, but of course this isn't exactly obvious if you don't happen to have Apple's ROM Monitor source code listing lying around.

Quote:

Well, my software development activity is mostly for my benefit. :D My conclusion was based upon what I wanted to achieve. Try not to be so combative...

I wasn't trying to be combative; I was simply pointing out that Sweet 16 is indeed useful to some people. You didn't say, "for my purposes," or anything like that, so your statement could easily be interpreted as a general statement about Sweet 16, which itself could be interpreted as combative. (Not to mention, directly accusing someone of being combative is not exactly a de-escalation.)