Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


JohnGill last won the day on July 18

JohnGill had the most liked content!

Community Reputation

51 Excellent

Recent Profile Visitors

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

  1. *facepalm* thanks so much. thought it would be something dumb!
  2. ... as usual! Hi all, I've got a piece of code that moves the "vera cursor" to the left four cells on screen: dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 dec $9f20 8 decs, tile byte and attribute byte x4. This works and is fine and does exactly what I expect it to. However, I then thought I'd be clever (HA!) and make a tidier bit of code, like this: version 2: lda $9f20 clc sbc #8 sta $9f20 Except this doesn't work. When I substitute version 2 for version 1 into my program, it screws up the cursor positioning on screen and I can't for the life of me see what the difference is between the above two bits of code. How could they possibly give two different answers? Thanks In Advance! John
  3. Thanks. For my game in particular, I'm using a mixture of basic and assembly as a learning exercise to teach myself assembly. I'm using the CBM Prg Studio development environment which was designed for the C64/C128, but it works well enough for the majority of the time for the CX16. I'm putting my text into RAM banks. I create each bank from within CBM Prg as an assembly page and then compile them individually as a .prg binary to be loaded into the game as and when needed. CBM Prg is especially good at handling text in this way, as the CX16 uses identical PETSCII screencodes to the C64/128, so as long as I mark text as "text" type in the assembler, then the upper/lower case characters get transferred to binary with the correct petscii screencodes for the CX16, so I can just type exactly what I want to appear on screen into the assembler. If that makes sense?!?! I'm on a learning curve on this one too, and it took me AGES to get my head round why my mixed upper/lower case text wasn't transferring correctly. I've not written a word-wrap routine, I know how wide my text display window is, so I just manually wrap the text as I'm writing it in the assembler, screenshot below from CBM Prg studio, showing an assembly tab for one of the RAM banks:
  4. Hi all, One step forward, two steps back. It seems very much that This Is The Way for software development. Either that or I'm just inept I got the save / load bank feature working, and added a creation tool so I can make maps within the software itself rather than handcoding with a hex-editor (which would be UGH!) BUT, having started to draw the first map, a bug has manifested itself in the code that draws the layer 1 16x16 graphics over the hex backgrounds so now I've gotta go fix that before I can carry on. *Sigh* at least the map creation tool works! Onwards and upwards...
  5. Yep cracked it - thanks all! Now I can make a save / load game routine for my hexes game! Good spot @Ender on that "filename" positioning. My 6502 assembly skills are coming in hops and crawls!
  6. I think you've cracked it Ender, thanks - I do indeed call the subroutine from basic with a sys call, so I'll try moving the filename to the end of the code, I bet that fixes it (and correct the filename length) on my phone at the mo so will try it in the morning
  7. Rummaging through the latest user guide on github, I found this: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#load-into-vram - which I thought I'd try. But it doesn't seem to work (see screenshots). VLOAD still works fine in R38 so I can still load stuff into vram, but I'm a bit puzzled why the new LOAD format isn't working for me in r38 - shouldn't it be defaulting to "8"...?
  8. Hmm one step forward - I tried switching over the order that I call SETNAM and SETLFS so that SETNAM is called first, and that now makes the subroutine complete normally in r38 - it now RTSes back to basic properly which it didn't before. But there's no file written in the emulator directory. I'm running the emulator "manually" from its own folder, not from the emulator launcher within CBM Prg studio. I even did a search on my entire hard disk for "bankxx.prg" in case it was being written somewhere I wasn't expecting it - but nothing there. I tried switching over the a / y, still no file written. I tried removing the y as suggested by Greg, still no file written. I copied and pasted the exact same .prg file into my r37 folder and ran it using the r37 emulator, and bankxx.prg is written into the r37 directory fine - all 8Kb + 2 header bytes of it. I don't get it... there's obviously something else at play here since it's working fine for you and @Greg King - any ideas what I could check next?
  9. this is what SHOULD have been in the original post! It saves a block of normal low-memory (non-banked) onto the file system, same folder as where the emulator is run from. worked fine in r37, doesn't work in r38...
  10. Ugh, sorry, I've only just noticed the block of code I thought I'd copied and pasted in the past above has mysteriously disappeared. I'm on my phone at the mo, I'll update once I'm back in front of my pc.
  11. A much neater solution, thanks Greg!
  12. Hi all, I've got a bit of code that saves a specified block of memory to a file. It works fine in r37, but it doesn't work in r38, I'm guessing the implementation of the kernal save has been affected with the SD card management additions in r38. What do I need to change to get it working again in r38? Hoping someone can shed some light on this, thanks in advance!
  13. Hi all, I've been wading through the dullest of dull bits of coding in the ongoing saga of my first ever game dev. I've just finished getting the player's stat bar "blobs" to function correctly. The routine reads the appropriate byte from the player's stats stored in one of the memory banks (health, gold, fatigue etc...) and draws the correct number of blobs, in the correct colour, in the correct place on screen, including splitting over 2 rows if necessary, including quarter / half / 3-quarter blobs. I wrote a simple version of the mod (%) function to do the fractional blobs which worked first time (OH JOY OF JOY!). Then wasted about 2 hours bashing my head against the desk trying to fix a bug which boiled down to me putting "0" where I should have put "#0". (NO JOY! REALLY NO JOY!) Unfortunately the game looks no different to how it did a month ago, but now I can get on with some more creative aspects of the game! Oh, and I've now got a working title for the game - "THE MYSTERY OF THE QUIET ISLE" which kinda sums it well I think Onwards and upwards!
  14. Thanks, I made the notes in Corel draw, which is a graphics package I use in my day job so I'm very familiar with it. Use whatever you're familiar with! Good luck with getting your own game going
  15. Hi all, Been on family holidays/vacation last month so not much coding done recently. The terrain count now stands at 21 of the final 32 terrain types. To witness my legendary pixel graphic skills (ahem ahem) see below. The terrain types currently are: wild scrubs ; forest ; desert ; rocky outcroppings ; marsh lake ; cliffs ; high mountains ; lowland fells beach ; orchard ; cave ; meadow ; pasture lumber yard ; wheat field ; cleared ground ; ploughed field farmstead ; watermill; ocean I've still got a drawing glitch on the layer 1 terrain graphic overprints, down the right hand side of the hex window - I need to print only the left half the graphic if it's at the end of an odd numbered hex_y row. Finding an odd number in assembly is ABSURDLY easy: LDA hex_y AND #1 this leaves 1 in the accumulator if hex_y is odd, 0 if it's even. that's all for now!
  • Create New...

Important Information

Please review our Terms of Use