Jump to content

rje

Members
  • Posts

    1216
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by rje

  1. Yes, no doubt about that. And the group has enough energy to talk about technical details.
  2. 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.
  3. 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?
  4. And I am woefully inadequate at testing ML. Hopefully working on SweeterX16 will improve my meager skills there.
  5. But something goes wrong, and I don't know what it is
  6. 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?
  7. My attempt to modify your source for cc65. Yes, I know I should FORK your repo and push an update to it and do a merge request... blah blah blah. My brain is reeling from even considering trying this out in the first place. Excuses excuses. I've probably broken it too. I'll load it and try to poke at it (no pun intended) with the debugger and see what I can try to do. SweetCX16.s SWEETCX16.PRG build
  8. SweetCX16.asm line 72 should be $0400, not $04000, yes?
  9. Wow, I just read your repo README, and I'm impressed. Totally going to check out your implementation.
  10. Bruce, I'm going to check out your repo. I just spent an evening porting in SWEET16 to the cc65 assembler, but I haven't tested it out. I juggled the memory load address so that it loads at $0443 -- that makes sure the last 250 bytes begin right on $0500. For your amusement. https://github.com/bobbyjim/x16-sweet16
  11. Just yesterday, I watched 8 Bit Show-And-Tell's video on the "Atari 64". It's a demo of tweaked KERNAL + BASIC ROM images that were adjusted to load into and run on the Atari 800XL and 1200XL. The ROM images essentially turned this Atari 800XL into a new type of Commodore 8-bit machine. The hardware is all Atari, so it's NOT a Commodore 64. There's no I/O, so you can't load or save. You can use the keyboard and the non-color screen RAM works, as well as the Atari-style sprites (which are strange to me). Atari's graphics registers are of course different. But then, I understand that that's what just about all Commodore machines are like: every model has different hardware, so the compatibility layer is KERNAL + BASIC. Everything else is completely up for grabs. So in my mind this is not much different than having Yet Another Commodore 8 Bit Machine.
  12. Found hints of this on the infowebs... But I may be very wrong. clc Lda #01 adc >my-address adc <my-address Its probably really slow, right? 4 clocks each for the ADC $$$$. Or there’s a fundamental flaw in my logic.
  13. Thank you Stefan — I didn’t know that. I had the ADC in mind, if I stored 1 in A, then I’d be incrementing with carry. Then I’d have to BCS or whatever that’s called, which is still messy I suppose.
  14. Merry Christmas all! Those pictures from Sweden are beautiful.
  15. THANK YOU! Now some more questions. lda #<$8000 ldx #>$8000 Are the < and > operators how we split a word into low and high bytes? Second question. Can I just directly increment a memory location, and use the carry bit to increment the high byte? That might look messier than nested loops...
  16. I have a two-parter question. 1. How might I dump a screen of PETSCII to a binary file? I print splash screens and similar, storing the content char arrays in C, or sometimes programmatically printing it out. I’d like to store that data in a binary. I’m not sure how to do that from the X16. 2. Then of course I want to write a short asm that prints that to the screen. The only way I think of this is by using FFD2, but maybe there are better ways? Also note problems with my code here! entry: lda clear-screen-code jsr $ffd2 ldx #0 printloop: lda $8000,x cmp $ff or whatever makes sense here beq done jsr $ffd2 inx Uh oh that won’t work because x is only 8 bits.... can I increment A indirectly? jmp printloop. But I know there’s a better way to do that. done: rts
  17. My really cheap proof of concept ADSR code is here: https://github.com/bobbyjim/x16-c-tools/blob/main/PSG.c Note that the code that "runs the envelope" is not an interrupt. So it's a POC, not a real usable thing really. Envelopes use: typedef struct { long phase; // along the ADSR envelope int attack :16; int decay :16; int sustain :16; int release :16; } Envelope; They're linear timeouts. So, not as versatile as the C64's envelopes. Still, 2^16 jiffies is... uh, I think it's 18 minutes. 65536 jiffies x 1 second / 60 jiffies x 1 minute / 60 seconds = 65536/3600 = 18 min.
  18. So back to Zero's talking about library files. Looks like the rule is: 1. If the very-common pattern is to USE all of the functions, then gang them together. 2. If someone might just want to use ONE function, then split them apart. 3. And make the common data its own library as well! This could make for a very leggy set of libraries!
  19. I think we have a quorum on not emulating a drive. I also think that we can agree on SD2IEC as a place to start. Regarding pi1581 mode... I seem to think that pi1581, unlike the 1541 mode, does not run in hardware emulation mode. Can someone confirm or deny?
  20. If it were a labor of love, and you had the means (skills and component access), the motive, and opportunity, then targeting one particular game makes sense. FPGA and CPLD (etc) makes your job easier, again assuming you have the materials and the skill. In other words, you have to have a goal in mind that hasn't already been done. "Because I haven't done it" can be a valid reason.... but it really does have to be your goal.
  21. Back to your original post, in particular: Would the pi1581 give a reasonable data transfer rate? Assuming the x16 could do fast serial? If so, then it seems “easier”(?) to modify the pi1541 project to include a piIEC mass-storage option that uses the 1581 fast serial? Makes me wonder what a nice base image size would be. 4 megabytes? 16? Or am I off by three orders of magnitude?
  22. Would the pi1581 give a reasonable data transfer rate? Assuming the x16 could do fast serial?
×
×
  • Create New...

Important Information

Please review our Terms of Use