Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. I'm wanting my Pirate Kingdoms thing to be some unholy cross between 7 Cities of Gold, Anno 1602, Civilization, and Pirates. But, I've been using a top-down view rather than a perspective view. I figure that it's going to be a challenge just to finish. I can always rewrite the view code once the thing actually works. Or someone can show me how to do perspective. ** A sound envelope engine would be a welcome addition. I tried out the Sprite Editor in the Downloads section, and I think it is only missing a native binary file load-and-save feature. And we have PETDRAW.
  2. Of course, Mr. Steil already has a good battery of KERNAL tests at https://github.com/commanderx16/x16-rom/tree/master/test
  3. Welcome, Charles! I'm basically in the same nostalgic boat as you.
  4. rje

    KERNAL Test

    Version 0.1.2


    This is a small, proof-of-concept C program which tests KERNAL functions on the X16. Routines currently tested: chrout memtop, both read and write membot, both read and write setnam setlfs load to RAM load to VERA (well, sort of) set time and read time It uses CC65's library to set registers and invoke routines. The source code is here: https://github.com/bobbyjim/x16-kernal-test
  5. KERNAL Test View File This is a small, proof-of-concept C program which tests KERNAL functions on the X16. Routines currently tested: chrout memtop, both read and write membot, both read and write setnam setlfs load to RAM load to VERA (well, sort of) It uses CC65's library to set registers and invoke routines. The source code is here: https://github.com/bobbyjim/x16-kernal-test Submitter rje Submitted 10/19/21 Category Dev Tools  
  6. Actually what I was thinking of is testing the Open ROM. I guess there’s no piecewise way of doing that.
  7. THAT topic is worth hijacking this thread for. The emulator has a debug console. So... potentially... you might be able to use it to debug the ROM. In fact I betcha that's what was used to debug the emulator as it was being written, so to speak. So for instance, I could monkey with the ROM -- say, replace a KERNAL routine with one of the open source ones -- then fire up the emulator. I *think* I would be able to TEST that KERNAL routine by inspecting memory with the debugger after that routine is called -- some of them are called when the system starts up, and some I'd have to set up and trigger myself (probably with a little C program). In fact one might could write a little C program that can run a test suite on the KERNAL. Maybe?
    First, thank you for writing this. It's going to help me. I think what would benefit this application is to compress your instructions onto a one-page reminder screen, perhaps with bullet points instead of text. Also, I believe LOAD and SAVE work now, so being able to save as a binary file would be ... well, excellent. Thank you!
  8. It was extremely important that the open ROMs be developed separate from influence from the original source. However, the KERNAL part is essentially done. That means anyone can debug it. As long as we don't replace the code with the original, that is.
  9. Aha, that's interesting. I had thought that it would bootstrap from one of those supercheap slow-ROM thingies. Rats, I forgot the name. Well anyway. Booting from SD is certainly more modern, and very flexible!
  10. Tom mentioned in a now-locked thread: All true. There are a lot of experienced assembly coders / kernal hackers here. ==> My assumption is that "it's harder than it looks." *** So has anyone sat down and actually counted the cost? That is, figured out the complexity of the task, broken down the requirements into workable units, and then estimated the level of effort to do it? I mean, assuming this is not simply a project someone hacks out over a weekend. Because if it were that sort of project, it'd've been done... as Hillary said, "because it's there". Someone would've taken the MEGA65 Open KERNAL project and carried it to completion. Because it's there. *** Consider the KERNAL. Let's go to Michael's own pagetable.com to checkitout. "done" (KEYLOG) "done" CINT "done" IOINIT "done" RAMTAS "done" RESTOR "done" VECTOR "done" SETMSG "done" SECOND "done" TKSA "done" MEMTOP "done" MEMBOT "done" SCNKEY "done" SETTMO "done" ACPTR "done" CIOUT "done" UNTLK "done" UNLSN "done" LISTEN "done" TALK "done" READST "done" SETLFS "done" SETNAM "done" OPEN "done" CLOSE "done" CHKIN "done" CHKOUT "done" CLRCHN CHRIN -- partial -- no screen device support "done" CHROUT "done" LOAD "done" SAVE "done" SETTIM "done" RDTIM "done" STOP GETIN -- partial -- no screen device support "done" CLALL "done" UDTIM "done" SCREEN "done" PLOT "done" IOBASE "partial" NMI vec "done" Reset vec "done" IRQ/BRK vec ...Plus over half of the "unofficial" KERNAL routines. I suspect they didn't need to implement all of them. "done" means the work is nominally complete on the MEGA65 ROM, with the caveat that they don't support features specifically described as "missing" in the project as a whole. Plus whatever changes we'd have to do to get THAT to work on the X16. We get all the extra goodies that Michael (already) added "for free". How long does it take an assembly programmer to code 39 subroutines? 39 weeks?
  11. I've started learning how time is measured on the X16. In particular, I've been playing with clock_gettime() from <time.h>. It includes a timespec structure that looks like this: /* Structure for seconds and nanoseconds */ struct timespec { time_t tv_sec; // <-- that's an unsigned long long tv_nsec; }; I've been fetching the time like this: struct timespec tp; clock_gettime(CLOCK_REALTIME, &tp); And, if I read the results correctly, the response is probably measuring to milliseconds. I think this, because when I print tv_nsec, there's three digits of precision followed by six zeros. I also tried shifting tv_nsec right by 10 bits, which results in what APPEARS to be six digits of precision -- but that would imply that the clock can measure microseconds. And, upon reflection, I doubt it. I think shifting bits results in a false reading because it's dividing by a non-decimal value. So, I think the call is measuring to milliseconds. Assume it's not accurate to THE millisecond, either. I haven't checked that yet.
  12. I lack the hardware as well; otherwise, I'd be trolling the yard sales. I gave my Commodore system to a friend 17 years ago -- and it was a good choice to make. But I understand the draw of rescuing those old floppies. A generous hacker digitized the contents of three of my C64 diskettes a decade ago, and I am grateful for his kindness and consideration.
  13. It's not (noticeably) slower or faster, and technically it's a demonstration of the autoincrement, so I'm keeping it.
  14. I've made a couple of small updates and brought the version up to "1.1". First, I re-enabled Dusan's small PSG library. By adding proper timers, the PSG works ok. I'm also only using sound when interesting events happen -- i.e. finding things or monster hits. That makes the pauses permissable. I tested this version out by running several games in a row. I did poorly on a few, but then I got some momentum and cleared the field, got the amulet, and escaped with a score in the 600s. If only I had captured a screen shot of that!
  15. You're right. For now, though, I'm seeing what it can do when I stay in BASIC, to serve as a demo of what you can do with BASIC. Ah, but I am currently using that tiny interrupt-driven sound library by Dusan. Even as simple as it is, it's adding a great bit of "color" to the game!
  16. Thanks for that. Managing the bitfields (and understanding what they do) is the full problem. It looks to me like I was POKEing above $10000, so the OR is probably needed.
  17. Thanks. It's not exactly correct, so I have to hunt around for the right way. In particular, the initial VPOKE has something wrong with it.
  18. Today I opened up the old "Rogue Forest" game I wrote a year ago, and I thought that this snippet could be sped up: if y>8 and y<40 then ff=int(rnd(1)*3) vpoke 1,P,fo(ff) :rem character index vpoke 1,P+1,cl :rem bg/fg color nybbles if y>8 and y<40 then ff=int(rnd(1)*3) vpoke 1,P+2,fo(ff) vpoke 1,P+3,cl if y>8 and y<40 then ff=int(rnd(1)*3) vpoke 1,P+4,fo(ff) vpoke 1,P+5,cl if y>8 and y<40 then ff=int(rnd(1)*3) vpoke 1,P+6,fo(ff) vpoke 1,P+7,cl P, P+1, P+2, P+3... P+7. I mean, that sounds like a shoo-in for using the auto-increment with Port 0, for example. Anyone think that sounds reasonable? I THINK I should be able to do something like this: vpoke %10000, P, 0 :rem set up autoincrement if y>8 and y<40 then ff=int(rnd(1)*3) poke $9f23, fo(ff) :rem character index poke $9f23,cl :rem bg/fg color nybbles if y>8 and y<40 then ff=int(rnd(1)*3) poke $9f23, fo(ff) poke $9f23, cl if y>8 and y<40 then ff=int(rnd(1)*3) poke $9f23, fo(ff) poke $9f23, cl if y>8 and y<40 then ff=int(rnd(1)*3) poke $9f23, fo(ff) poke $9f23, cl
  19. I don't know. If you've watched his videos, you know how he works, and this seems to be the way he does it. Seems like a hill-climbing algorithm to me. Certainly is not a top-down style. If you know what I mean. Has 8BG ever given you the impression that he works in the manner you suggest?
  20. I'm doing something wrong. I've got a PET font, and a VIC-20 font, both 2K and apparently representing similar PETSCII sets. I can load either one into the X16, like this: cbm_k_setnam("chargen-font.bin"); cbm_k_setlfs(0,8,0); cbm_k_load(2, 0x0f800); So far, so good. Now when I load them, lowercase is uppercase, and uppercase are those graphic chars. I solve that by printing the control code to switch cases: cbm_k_bsout(14); // to upper+lower case HOWEVER, what that does is switch the X16 back to its built-in Commodore 64 PETSCII font. It does not get me the PET PETSCII (or the VIC-20 PETSCII if I use that binary instead). I'm obviously doing something wrong in a simple way. Can someone tell me what that is? Thanks!
  21. So reading his webpage a bit, it seems that CPLDs are most useful for all the glue hardware -- logic gates, for instance, that do some address decoding. He uses a 65816 of course for the CPU. Meanwhile, Frank shows us how FPGAs are suited for the raw capability of processor design, be it graphics, sound, or CPU. That leaves RAM, ROM, and I/O.
  22. No, that's reasonable. I worry about the heap requirements, as well as the size of the codebase -- AWK is not small. V7 AWK is here: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/awk And now it's here: https://github.com/bobbyjim/AWK-7 My question is: what would you use it for, if it were running on the X16? Catting files is useful, but is filtering them also useful? Splitting records, and displaying columns? Counting strings? Selecting records?
  • Create New...

Important Information

Please review our Terms of Use