Jump to content

rje

Members
  • Posts

    1216
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by rje

  1. OK, replaced the BASIC version with the C version. It's more responsive, but the scrolling is terrible. Also I don't like the way I did the map. I have to rethink things and use fewer sprites if possible. For example, I use sprites to tile the ocean. I shouldn't have to do that -- surely I can just use characters to represent the ocean. Like a reverse period, or something. Then, the land sprites themselves are memory hungry. Each one is 64 x 64 and 8 bit pixels -- 4K! Oink! I think I need to go back to using "coastline" sprites for the edges. 8 x 64 and 64 x 8 sprites. We'll see. And even after all that, there does appear to be an obvious redraw going on when the ship moves: the sprites appear to stagger. In other words, C is not fast enough.
  2. Sounds like he just needs a coin flip.
  3. I can see that. And that's a good simplification for an interrupt-driven envelope manager. Thanks.
  4. Here's the functions I coded up in my proof-of-concept. void runVoice( unsigned voiceNumber, Voice* voice ); void runVoiceWithEnvelope( unsigned voiceNumber, Voice* voice ); int getTunedNote( unsigned index ); void bang(unsigned frequency); Each voice has a dedicated envelope, so runVoiceWithEnvelope() can figure out the envelope's address.
  5. Using a PSG noise register thingy might be a good idea. I think the emulator doesn't have one source of randomness. That said, my "Blinkenlights" demo displays several memory locations that change state while the program runs. They include a chunk of the CPU stack ($01D5 - $01E4), which is of course NOT random, the time registers (TM_SC, TM_MI, etc etc), which are of course NOT random, and the addresses from $9F64 through $9F69 and $9FB8 through $9FBB ("external devices"), which ... well they surely can't be random.
  6. I've worked a bit more with VERA Sprites and the PSG both, and I have an update. (1) The sprite bitfields are not as big a problem as I originally thought. They are PAINFUL when programming in BASIC, but I suggest a thoughtful extension command would resolve that. When using C, the bitfields are no problem at all. (2) The PSG has one major drawback, and that is the lack of ADSR envelopes. The solution would have to be something like an interrupt-driven software ADSR system in assembly language, with a small bit of RAM set aside to manage state. The 16 bit ABI can be used to pass parameters. Now I haven't used the synthesizer chip on the X16. Maybe it's easier to use.
  7. I wrestled with the code a bit, and am feeling tired over it. I feel like it's all going in wrong directions. But that's no reason to throw it out. That just requires some careful UX thought. That's what it needs: an old-school but effective common user interface. It has a lot of menus. And I'm sorry to say they don't all work the same way. This implies that I need a common menu method that the various drivers call on to draw the user's input properly.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. I bought an SN76477 from Radio Shack in the 80s. I wasn't up to the challenge. But it was cool.
  14. 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.
  15. 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
  16. Ahhh because ADC is ADD WITH CARRY. 13 bytes in ZP, 19 otherwise. Thank you!
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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?
  22. I see exactly where I went wrong. The start address should be loaded into the accumulator, shouldn't it? Duh! My brain.
  23. 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.
  24. LOL, well that's absolutely true. People gravitate towards what they like to do, and there's a wide spectrum of stuff here.
×
×
  • Create New...

Important Information

Please review our Terms of Use