Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


TomXP411 last won the day on January 16

TomXP411 had the most liked content!

Community Reputation

214 Excellent


Recent Profile Visitors

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

  1. Ugh. I started looking at cc65 the other day and kind of got overwhelmed. It's like starting over, with completely different code for project management than I'm used to. I'm starting to feel like that's where I need to go, however, since I'm coming up short with other tools, and cc65 is what the ROMs are being developed in, after all...
  2. Yes, it would really help if the Commander DOS functions were backed up by BASIC commands. MKDIR, CHDIR, RMDIR, COPY, DELTE, and SEEK. I'd also like to see some more numeric conversion and math functions. Specifically, we need HEX$ and BIN$ functions and the MOD operator. Right now, it takes about 10 lines of code to display a number to hex, when it really should just be something like PRINT HEX$(A) There are also still open feature requests for banked memory management and a few other things, as well... so there's still a long way to go on these kinds of things. Maybe if you have the skills, you can jump in and lend a hand. Now that I'm starting to get a handle on assembly for the Commander, I may step in and add some of my own commands (specifically, the ones I just mentioned.)
  3. Yeah, I tried that... still no joy. The error I get is "unknown addressing mode". The compiler doesn't understand that STA (R0),Y should be an indirect , Y indexed instruction with the address of R0. The compiler does generate code for STA R0, which generates STA $02, but not for STA ($02),Y
  4. I am working on it now... part of the problem is I really don't understand your assembly/c interface very well, and your calling convention is not something I've seen before. For example, I wanted to fill a buffer in the data segment, with the pointer stored in RO (address 2 in zero page). I'd expect something like this to work... in my global section: __address($02) word R0; char* buffer ..... ... R0 = (word) buffer; asm { STA (R0),Y ... } } But the compiler just completely removed the assignment to R0, then failed to assemble the STA line because R0 didn't exist. I ended up using a really obtuse syntax with a double pointer that I pulled out of your LOAD example, but I don't understand why the code above doesn't work.
  5. For some reason, when i first tried it with CHR$(8), I got "no channel", and it worked when I put in "8". When I tried it again today, it worked both ways. So it looks like the DOS code clips the top 4 bits, so it seems like either way works.
  6. You might save some time by reading larger blocks - maybe copying your I/O code to low RAM when the editor starts.
  7. Thanks. Yes, the magic suffixes are exactly what I was looking for. I think half of my trouble is that the PDF included in the release appears to be incomplete. I actually searched all references of “string” and could not find the magic suffixes, nor could I find a list of #pragmas. I did find your Google Doc, but I didn’t find the magic suffixes in there, either. (Although I will look again.) I have plans to build an Orthodox File Manager (sort of Midnight Commander for the Commander X16), and I will need to build the conversion and output functions in question, so as I complete chunks of that, I’ll send over the more useful parts. Now that I have a working file reader, I’ve passed the biggest roadblock, so
  8. Okay, it looks like my wounds were self inflicted. I used the load example you suggested without realizing that it explicitly uses the free ZP locations on the Commodore 64, which happen to be in the space you're not supposed to use on the Commander. This was overwriting something that was causing a BRK every time I tried to run any BASIC command. Along the way, I discovered that the print routines use screen codes, rather than PETSCII codes, which was giving me a FILE NOT FOUND error. The filename "DEMO" was actually being encoded as 4,5,13,15. Now that I know that's an issue, I can work around it. If they're not already there, I'll add some PETSCII<>Screen code conversion routines, so that problem can be worked around in the future. Although it would be nice to have sigils or prefixes to encode strings as PETSCII/ASCII, instead of screen codes, so we could just write something like char* filename = "demo,r,s"p; // encode the filename as PETSCII text.
  9. Hmm... unfortunately, I'm hitting some roadblocks. I got my code with the assembly subroutines to compile, but I'm getting a disk error, but the DOS command resets the emulator. Looking at the generated assembly code, it looks like you're writing to zero page locations 0,1, and locations > $80. This is a problem, since BASIC and the KERNAL rely on $80 and up, and $00 and $01 are the bank switching addresses (or will be when the next version comes out.) I checked the target files, and I didn't see any way to constrain Zero Page addresses, so I'm going to put this to bed until I can investigate more later.
  10. It uses the same APIs as the Commodore 64. My current assembly file read code looks like this: lda #filename_len-filename ldx #<filename ldy #>filename jsr SETNAM lda #FILE_CHANNEL ldx #DEVICE_NUMBER ldy #SECONDARY_ADDRSS_DIR jsr SETLFS jsr OPEN To actually read from the file, you need to call CHKIN with the file channel in A: ldx #FILE_CHANNEL jsr CHKIN And then you use GETIN to read a byte from the channel: jsr GETIN ; reads a byte to A To check for EOF: jsr READST or LDA $0286 Reading from $286 is much faster, sine READST has some other overhead that's unnecessary for an EOF check. I plan to resolve that issue by actually reading into the READST routine and grabbing the operand of the LDA instruction. Closing a channel is very simple: jsr CLRCHN lda #FILE_CHANNEL jsr CLOSE I'm looking at this right now, but I won't be able to spend too much more time on it today, I have to head out to work in about an hour. The problem I'm currently having is that this code is optimizing "ret" as a constant, and it's not allocating memory for the return variable: char fgetc(byte channel) { char ret=0; asm { ldx channel jsr CHKIN jsr GETIN sta ret jsr CLRCHN } return ret; } looks like this in the ASM file: // fgetc(byte zp($13) channel) fgetc: { .label ret = 0 .label channel = $13 ldx channel jsr CHKIN jsr GETIN sta ret jsr CLRCHN rts } I think the problem is that the optimizer isn't seeing RET being used anywhere, so it's optimizing out the storage for ret and treating it as a constant. If I do something like "ret=ret+1" above the asm block, then it gets storage... but there are other issues I'm still working out.
  11. Yep, that worked! There are a couple of other minor nags, but they are not deal breakers: I'd like to be able to include -scale 2 in the command line to start the emulator, but when I tried to add that to the platform files, the emulator just didn't start at all... printf seems to use conio.h, which appears to talk directly to VERA. This works fine when you need performance, but it loses a lot of CHROUT's functinality. No console sequences (ie: cursor movement, etc) and text can't be redirected to an output channel for saving to disk, printing, or RS-232. It might be nice if printf() used CHROUT to write to the screen, and cprintf used memory I/O to talk to the screen. This would let printf work as expected with PETSCII console sequences, and it would keep the BASIC screen in sync with the text from a C program. This is also, more or less, the standard behavior on PC compilers, and would make the transition easier for people used to that method of doing things. So my thought was to change the existing printf() definitions, with the VERA functions, to "cprintf" and introduce a new version of the printf functions that uses CHROUT. While this is slower, it will allow printf to be re-directed to a printer, to RS-232, or to a file - all things you can't do with cprintf(). I'd be happy to do the work; I need to brush up on my C, anyway - it's been a while since I've done any real work in ANSI C. Also... dumb question, but I can't find any file I/O commands. Am I missing something, or do I need to implement the basic file I/O functions?
  12. Hi, @Jesper Gravgaard I'm trying out Kick C (I appreciate it doesn't require CygWin just to compile some c code), but I can't get the examples to compile for the Commander X16. I'm getting this: I tried adding veralib.c to the command line, and I get Redefinition of variable: vera_layer_config The error on the initial compile is telling me there's a library or object file missing, but I can't figure out how to add it on the command line. Do I need to compile something else first to create the Commander X16 library file? What am I missing? (On another note: the program compiled and ran perfectly on VICE without any errors. Thanks!) ** edit: figured it out. I had to add #include <cx16.h> #include <veralib.h> To the program. Once I did that, everything started up. Now I just have to remember my old school C and console commands. Thanks! This works great!
  13. So the thing you’re missing about the keyboard is that the keyboard generates the clock. And since PS/2 is an event driven protocol (messages are sent when a key is pressed or released), the system requires interrupts. So the keyboard and mouse ports will be hooked to the IRQ line, because they have to be. So the process would be that when you press a key, the keyboard will cycle the clock line, triggering an interrupt, and the computer will then start reading the clock and data lines. Once the data has been read from the port, the character will be placed in the keyboard buffer. I haven’t looked at the keyboard code in the emulator yet, but it’s possible that the emulator is injecting values directly into the system; that’s the approach I took when I first started my own virtual computer project.
  14. The problem being that this ReadMe is not included in the emulator package, so I had no idea it existed until earlier today (when I was looking at the block I/O API.) Yes, the P command works great. I've already written a small demo program to test it. Also, it's worth noting there is an error in the ReadMe. The ReadMe says: POSITION P channel p0 p1 p2 p3 Set position within file (like sd2iec); all args binary "all args binary" is not correct. The channel number needs to be passed in ASCII, so the correct syntax to seek to position 128 on channel 1 is.... DOS"P1"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0) Channels 10-15 need to be entered as the ASCII characters after 9 (:;<=>?) here's an example: 20 OPEN 1,8,8,"@:DEMO,S,W" 40 FOR L=0 TO 255 50 PRINT#1,CHR$(L); 60 NEXT 90 CLOSE 1 100 OPEN 10,8,8,"DEMO,?,M" 110 DOS"P:"+CHR$(128)+CHR$(0)+CHR$(0)+CHR$(0) 115 DOS 120 FOR I=1 TO 4 130 L=0:GET#10,L$:IFL$<>""THEN L=ASC(L$) 150 PRINT L; 160 NEXT I 170 PRINT 999 CLOSE 10 When you run this, it will create a 256 byte file. Then it will re-open the file for random access and seek to position 128. It will then print 4 bytes byte at that position. That should be 128-131.
  15. There are already solutions for the C64 that load data into RAM over the User port. It would be trivial to implement a similar solution on the Commander. And, again, don't forget that I've already put together a basic spec for communicating in parallel over the User port. All we need to do is implement that in code (which we can't reliably do until we have hardware.)
  • Create New...

Important Information

Please review our Terms of Use