6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Sep 25, 2024 3:22 am

All times are UTC




Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Tue Aug 24, 2021 7:28 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
Charlie has an enlightening and entertaining SWEET16 article here.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 24, 2021 7:41 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
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!


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 24, 2021 9:41 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
Do the variables for acc xreg and yreg need to go in RAM?

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 24, 2021 11:16 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
If you want them to act like variables (and not constants or random number generators), then they should definitely be in RAM ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 12:17 am 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 12:56 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
In case it's helpful, that new thread is here: Woz Sweet16 Redux. Can anyone get this working?.

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 3:45 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
Jmstein7 wrote:
BigDumbDinosaur wrote:
...and if all else fails and you are desperate for 16-bit operations, you could consider the 65C816... :D

Lol - and what fun would that be? :lol:

All depends on how you define "fun." :D

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 4:11 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
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.)

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 9:29 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1467
Location: Scotland
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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 9:39 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
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.

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 10:07 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1467
Location: Scotland
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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 12:04 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
cjs wrote:
In case it's helpful, that new thread is here: Woz Sweet16 Redux. Can anyone get this working?.

Whoops. Thanks, cjs.


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 6:04 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
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. :D 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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 8:53 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 25, 2021 10:45 pm 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
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.)

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 42 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: