Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. 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
  2. SweetCX16.asm line 72 should be $0400, not $04000, yes?
  3. Wow, I just read your repo README, and I'm impressed. Totally going to check out your implementation.
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. Merry Christmas all! Those pictures from Sweden are beautiful.
  9. 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...
  10. 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
  11. 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.
  12. 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!
  13. 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?
  14. 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.
  15. 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?
  16. Would the pi1581 give a reasonable data transfer rate? Assuming the x16 could do fast serial?
  17. A: "It's not a bug, it's a feature." B: "But it's caught on fire..."
  18. The game relies on exploration and a slow buildup of capability; therefore one misstep shouldn't result in immediate destruction. In Tradewar 2002, if your ship encountered a superior opponent, it would auto-escape with some damage. Maybe I ought to do it that way.
  19. PRE-ALPHA VERSION The "pre-alpha" version is playable. I'll talk about (a) what it does now, and (b) what I WANT it to do. I'll attach the "user manual". WHAT IT DOES NOW You start in the "pilot" view, which does very little. Access the menu by hitting <return>, and you can see other things you can do. "ASTROG" lets you target a destination star system. "JUMP" takes you to your target destination star system. "WILDERNESS REFUEL" refuels your ship. "TRADE" needs work. "STARPORT" also needs work. "HIRING HALL" lets you hire and fire crew. "SHIPYARD" lets you trade your current ship for one available at the shipyards. When you Jump, you automatically take on passengers and freight. WHAT I WANT IT TO DO There are several additions and improvements I want to do. The most important to me are: SHIP DAMAGE. This means ship components can be damaged, and can be repaired at the PORT. COMBAT. Once ship damage is handled, then I can write combat. Amber and Red zone worlds are dangerous and should be avoided. The risk here is of being attacked by a pirate. I need to write a combat routine that takes your ship and crew into account. OTHER THINGS I WANT IT TO DO Ship upgrades. Random ship encounters. System survey.
  20. I think Commodore lost its vision and went nuts. Tramiel at least had a vision (and almost by definition a vision is an official business direction that other people will disagree with). Tramiel's vision again was the C16 to be that Sinclair competitor. It seems to me though that the C64 was already a Sinclair "suppressor" by the latter 80s. The C64 was the right system at the right time to "clean up" the 80s: to wipe out early competition and then mop up on the cheap computer market later. We all know the future wasn't eight bit. Even the market knew it in the 80s.
  21. I surfed around the YouTube "net" over the past week, and it struck me how like the SD2IEC this project is, except using a Pi.
  22. pi-IEC sounds reasonable. Especially on things like the X16, compatibility only needs to be at the IEC level, rather than being a 1541 etc.
  23. I'm interested -- do you discuss this somewhere on this site? And, regarding pure assembly (inline?) -- I'm also interested.
  • Create New...

Important Information

Please review our Terms of Use