Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

13 Good

Recent Profile Visitors

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

  1. Thank you very much! Yes that sounds very probable. Something concrete for me to work on.
  2. I've not done that deliberately - I'm the only one writing this so the screw ups are all mine it is definitely something to do with how the character sets are being handled, so I'm going to dig a little deeper down that tunnel. Perhaps the kernel calls from print do something clever to make the correct characters appear on screen that my hard-coded vera calls ain't doing.
  3. pff. exactly the same. ah well. although here's a weird thing - I quit out of the program, and typed in the line 'In a wild and rough scrubland' with the shift key held down - and I got exactly the same string of characters as the assembly is displaying (apart from the capital I which didn't appear reversed out). Question is, why is the text displaying correctly when called with print chr$() in basic? Curiouser and curiouser....
  4. if I'm switching to use vera port 1, I'd also need to change line 120 (sta vera_data0) also to sta vera_data1. I've set up all the variables at the top of the assembly to the appropriate register values to I don't have to keep remembering them I can't see how it'll affect it, but I'll try anything at this stage I'll give it a go...
  5. Hi Stephen, thanks for the reply. I did sign up with github a couple of years ago but couldn't make any sense of how to use it. You seem to be confusing me with an actual programmer . In the screenshots below, I've shown how I've coded the bank 1 data in my assembler - this compiles to a prg and loads up fine into the emulator. I've also shown the basic program where it calls the 'print' assembly routine (sys $2a90) and then the assembly code section where it writes the ram bank section onto the screen. (startHi should really be called startLo - I got my endians muddled up - as pointed out by togster510 above! I switched them round but didn't change the variable names). jsr scroll is a subroutine I've written already and tested, that works perfectly - just moves all the message window up one line, leaving the bottom line blank for the next line of text to be written up. I've also attached a screen shot of it running to show how the assembly displays the message from the bank (yellow section at the bottom of the message window), and then at the top of the window, I've put some basic code in that loads exactly the same bit of memory and writes up the first line perfectly. The assembly is definitely reading the right bit of memory, the spaces in the top row line up perfectly with the spaces in the basic printed line. It seems to be something to do with how print chr$() interprets the character set but I can't work it out. Any ideas?
  6. I'm using the 'text' type in my assembler and compiling the ram bank as a .prg . It's strange, because when I print chr$(peek($A134)) from basic, the characters come up on screen correctly. I'm obviously doing something dumb with the assembly but I don't know what yet...
  7. it's supposed to say : the spaces are all in the correct places, and the capital letters are all there (I, T and F), just reversed out. I've replaced some of the upper-case characters to make the hex-construction graphics, and the resource blobs as well. I'm going to re-organise my character set map but the untampered-with- lower case characters should still display correctly shouldn't they? I'm still a bit of a noob at petscii and how the character sets are handled so it could just be that I'm being a bit dim. *edit - don't know what happened to the text I copied and pasted above - it should have said "In a wild and rough scrubland. Thick grasses and heathers make the going slow, and gorse bushes pick at your clothes. From unseen heights, the cries of distant birds catch on the wind from time to time.%"
  8. curiouser and curiouser.... I've switched startLo and startHi around into proper little endian order, and now I get this (see attachment). It seems to be the correct text, but all the lower case characters have turned into graphics and the upper case characters have been reversed out. And now the BASIC bit that prints the first line of the message doesn't print anything at all! coding in assembly for me just feels like one step forward two steps back every time!
  9. ah! that makes perfect sense. yep, thought it might be some noobish error like that. Many thanks, I'll switch them up and see what happens... (!!!)
  10. Hi all, I'm working away furiously at writing a routine in assembly that will scroll text within a window on screen for my hexes adventure game, loading text from a memory bank and adding it at the bottom line by line. This is really stretching my assembly skills but I'm enjoying the challenge. I've got my head round using both vera's data0 and data1 to read and write the screen to shuffle up the whole window a line at a time, but I've come across a blip that I can't get my head round, and I'm wondering if someone can please point me in the right direction: I'm copying a string of characters from somewhere in the ram bank space ($A000 upwards), which is referenced by two ZP vars that I've assigned to variables thus: startHi=$14 startLo=$15 I've written the maths routines to calculate the start position of the required string, which sets startHi to say, $A1, and startLo to say, $34. The maths routines I've tested and know are working, they give the correct values in startHi and startLo for the base position of the text within the ram bank. My problem seems to be actually copying those bytes to the screen. I'm feeling exceptionally clever for working out how to use the y register in indirect indexed addressing mode to step through the memory thus: loop: lda (startHi),y ..... do stuff But it ain't working (yet ). If I've understood things correctly, this is supposed to look at the byte at memory address startHi ($14 for me) *and* the byte at memory address startHi+1 ($15, startLo) and use that as a two-byte base address, and then add on the value of y. Is that right? When I run the routine, it just writes a ton of "@" to the screen. I've set the break point at the start of the loop with the debugger monitor thing (very useful), and it steps through y from $00 > $FF fine, and sure enough, its just loading zeros into the accumulator at the lda (startHi), y line every time. I can see the ZP vars in the debugger, and $14 and $15 are indeed pointing to $A1 and $34 (or whatever), but I don't understand the debugger well enough to work out if I can look at the actual $A134 while I'm stepping through the assembly. When I print chr$(peek($A134... $A135... $A136 etc)) from basic, then it shows that the characters are indeed present in the ram bank page (see below). So why does my assembly just find zeros? Any tips very gratefully received!!! thanks
  11. I'm using a combination of basic and assembly. Taking the CX16 as an opportunity to learn and write games in assembly. I'm using the CBM PRG Studio package - It's designed for Vic20/C64/C128 but it still works with the CM16 emulator. I can write basic and assembly in a nicely laid out IDE, and it compiles assembly, and combines it with basic to make a single PRG you can load directly on the emulator. Although from the conversations I've had with *proper* programmers on here (I don't consider myself proper!), this isn't ideal, and I should really move onto a better compiler!
  12. Thanks for this Andy, I'll investigate...
  13. Hi all, I'm having a problem with loading completely full ram banks from disk in BASIC. I've got a file that's 8194 bytes (2 location header bytes + 8192 data bytes) and when I try and load it up with: POKE $9F61,1: load"bank1.prg",8,1,$a000 then it just loads memory with a bank full of zeros, seemingly ignoring the file completely. If I trim 2 bytes off the "bank1.prg" file size, to exactly 8192 bytes (2 location header bytes +8190 data bytes) then it loads into the bank fine, leaving two empty bytes at the end of the bank. Am I doing something wrong, or is this an emulator "feature" that needs addressing? thanks
  14. thanks again for this Stephen - I think cc65 is a bit beyond me for the time being. I've made it this far with CBM Prg studio so I'll stick with what I know. Using the hex editor and -debug tricks, I've worked out how to get the routine into the emulator and working. Only issue now is that it's displaying all the character 1 set characters...! I don't suppose you know how to switch to the secondary character set with the lower case letters?
  • Create New...

Important Information

Please review our Terms of Use