Jump to content

rje

Members
  • Posts

    1262
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by rje

  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?
  15. I see exactly where I went wrong. The start address should be loaded into the accumulator, shouldn't it? Duh! My brain.
  16. I saw Bruce's SWEETER16, so I decided to sit down and write some assembly on the X16. First, I want to use the X16's pseudo-registers in zero page... and have some scratch space right above there, too. ; ; kungpao16.s ; seeing how far I can go to create a SWEET16 variant. ; R0L = $02 ; accumulator low R0H = $03 ; accumulator high R14H = $1f ; status high R15L = $20 ; PC low R15H = $21 ; PC high ; ; I'll set up a 16-bit short stack, just for fun. ; I've got from $22 to $7f ; XRL = $22 ; extended 16 bit stack, low bytes XRH = $52 ; extended 16 bit stack, high bytes Next, I want to use the full CPU. .pc02 ; enables 65C02 I'm using "golden RAM". $400 for my code, and $700 for data. So I'll put some data in place. ; ; Set up some test data. ; LDX #$11 ; $0700+ = $11 $41 $15 $00 STX $0700 LDX #$41 STX $0701 LDX #$15 STX $0702 LDX #$0 STX $0703 LDX #$7 ; R15 (PC) = $0700 STX $21 LDX #$0 ; ... and now X is zero (conveniently) STX $20 Now I can write a loop that checks each byte in the data stream, and quits when it finds a zero. ; ; The start address is in R15. ; ; Fetch the instruction (zp fetch!) ; FETCH: LDA (R15L) BEQ DONE ; 00 = PROGRAM END TAY ; stash it in Y AND #$0F STA XRH,X ; put the low nybble into RxH TYA ; bring it back from Y AND #$F0 STA XRL,X ; put the upper nybble into RxL INX ; ; Increment R15 (the PC) ; NEXT: INC R15L BNE FETCH INC R15H BRA FETCH DONE: RTS I use SYS $400 to run it, and here's what it does: it reads the bytes starting at $700 (and stops when it finds the zero at $703). It splits each byte into lower and upper nybbles, putting them into zero page at $22,X and $52,X respectively: $10, $40, and $10 starting at $0022, and $01, $01, $05 starting at $0052.
  17. LOL, well that's absolutely true. People gravitate towards what they like to do, and there's a wide spectrum of stuff here.
  18. Yes, no doubt about that. And the group has enough energy to talk about technical details.
  19. I've only ever worked with the SID, which had good Usability. I can tell it was usable because I was able to use it... and I don't know anything about anything except programming. What I found useful about it was (1) ADSR envelopes, (2) multiple voices, and (3) multiple waveforms, including noise of course. So anything that gets me those three features in reasonable registers is fine by me. *** If the PSG had envelopes I'd be content and productive. Frankly, it could be any chip(s) under the hood, as long as I could use it in a manner similar to the SID. It looks like the POKEY didn't have ADSR envelopes, so I can't vote for that.
  20. I don't mean to sound like Paul Scott Robson, so I'll try to dance around the issue a bit. At work, we periodically have to assess whether what we're doing is worth the effort we're putting into it. I understand that sometimes, business is driving the work, and there's nothing we can do about it. But it never hurts to let business know the issues and how much trouble they will cause. I hear that USB is more expensive than PS/2, which is cheap. But... I'm starting to wonder if PS/2 is not really cheap, but rather pushes time and expense and complexity back to the board. Do we really want home-brew complexity to drive a modern keyboard -- a solved problem? I would much rather that your efforts went into the KERNAL and toys for the banked ROM. "I have this awesome retro machine, but 50% of the build time and effort goes into the keyboard interface, which has nothing to do with the retro nature of the machine." And what's the QA effort around debugging keyboard routines? Or is this the kind of fun everyone signed up for?
  21. And I am woefully inadequate at testing ML. Hopefully working on SweeterX16 will improve my meager skills there.
  22. But something goes wrong, and I don't know what it is
  23. Okay I will start with a SET. It looks like R1 is safe for this, so I can do SET R1, and let's see, let's give it the value $1541. I'll use your binary, which loads to $4000, and I'll make sure to load in the data before I load the binary too. And I'll put the "program" in $0700. I think that would look something like this: $0700: $11 ; SET R1 $0701: $41 $0702: $15 $0703: $00 ; RTN $0704: $02 ; 6502 BRK Then I poke $00 $07 into R15: $0020: $00 $0021: $07 Then sys $4000. Then peek $02 and $03 and hope that $41 and $15 are there?
×
×
  • Create New...

Important Information

Please review our Terms of Use