Jump to content

rje

Members
  • Posts

    1079
  • Joined

  • Last visited

  • Days Won

    34

rje last won the day on January 5

rje had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

rje's Achievements

Collaborator

Collaborator (7/14)

Dedicated Rare Very Popular Rare Conversation Starter Rare Reacting Well Rare First Post Rare

Recent Badges

454

Reputation

  1. So far, my Kernal Test only tests these: 1. CHROUT 2. MEMTOP (read and write) 3. MEMBOT (read and write) 4. SETNAM, SETLFS, LOAD (implicitly though...) 5. IOBASE 6. SETTIM and RDTIM I'm looking for more easy KERNAL tests... I'm thinking the IEC Bus is not a trivial thing to test, so maybe I can test: Channel I/O calls? STOP, GETIN, SCREEN, PLOT? Any suggestions?
  2. Yep, I was messing with those opcodes, grouping them one way and another, thinking "surely a little decode can reduce size". I'm sure Woz didn't decode because 300 bytes was the golden compromise for him.
  3. 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.
  4. 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.
  5. 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.
  6. I bought an SN76477 from Radio Shack in the 80s. I wasn't up to the challenge. But it was cool.
  7. 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.
  8. 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
  9. Ahhh because ADC is ADD WITH CARRY. 13 bytes in ZP, 19 otherwise. Thank you!
  10. I've never really thought through what is required to do a 16 bit operation. Suppose you had two 16 bit values in zero page, say at $02-$03 and at $04-$05, and you wanted to add them together. How would I try to do this? I'd first add the low bytes together. ADD_LO: LDA $02 ADC $04 STA $02 ; I guess we put the result back into $02. I guess. BCC ADD_HI ; handle carry set CLC INC $03 ; add carry to hi byte of first number ; what if THAT causes the carry to get set? I dunno. ADD_HI: LDA $03 ADC $05 ; I don't know how I should handle carry in this case. STA $03 ; back into $03, I guess. DONE: RTS As far as I can tell, this'll add the lower two bytes, add the carry to one of the upper bytes, then add the two upper bytes together. It SEEMS to me like this would add two 16 bit numbers. It also seems to be quite expensive... I don't know, but it looks like it's AT LEAST 19 bytes long. I think if you had to do this beyond zero page, it would be like 26 bytes or more? If you had 16 different places that used somewhat leisurely 16 bit adds, subtractions, and compares in your 16K ROM, then something like SWEET16 is worth it.
  11. Hmmmmm possibilities. So I was thinking that the compact Woz-tiny version still has utility with the KERNAL or BASIC on the X16. Assuming there are enough* 16-bit ops in those ROMs in non-speed-critical places. * More than 300 bytes' worth... and where the space savings makes other things possible. But Acheron... I mean that could fit handily in a ROM bank, with room for whatever else would go there. Or... assume even more duties of the KERNAL, but I am deliberately ignorant of the KERNAL so I don't know.
  12. Isn't Acheron an entire operating system? Oh, wait, that's something else I'm remembering. But Acheron is ... well suffice to say it doesn't look like it's 300 bytes.
  13. Ideally, the opcodes would be organized in some rational way. Instead, Woz just has them however he likes and uses a table. But I was taught (if that's the word) that complex instruction codes ideally are organized rationally for decoding, rather than jumptabling. On the gripping hand, though, Woz' jump table is only 64 bytes? That's pretty small. Maybe I can decode 32 instructions in less than 64 bytes (and maybe not!), but I certainly can't dispatch fast with decoding logic.
  14. 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?
×
×
  • Create New...

Important Information

Please review our Terms of Use