Jump to content

rje

Members
  • Posts

    1028
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by rje

  1. Maybe it's not that -- it's that clang complains about the syntax. For example, with nested templates, it errors out when the end-brackets aren't space-delimited. It errors out on these: >>> But is okay when I edit them to this: > > > It is also erroring on C++11 extensions. I'll have to enable that in the makefile, I think. I'm weak on Make. Found this on Stack Overflow, and will try it out: CXXFLAGS = -std=c++11
  2. My first roadblock: running the right compiler. I suspect it's trying to use clang, when it should really be using acme.
  3. Here, I'm going to walk through the CX16 configuration. ;; #CONFIG# PLATFORM_COMMANDER_X16 YES Well, yes. ;; #CONFIG# MEMORY_MODEL_38K YES Again, yes. ;; #CONFIG# PANIC_SCREEN NO ;; #CONFIG# DOS_WEDGE NO ;; #CONFIG# TAPE_WEDGE NO ;; #CONFIG# TAPE_HEAD_ALIGN NO ;; #CONFIG# BCD_SAFE_INTERRUPTS YES Okay. ;; #CONFIG# COLORS_BRAND NO ;; #CONFIG# BANNER_SIMPLE NO ;; #CONFIG# BANNER_FANCY YES ;; #CONFIG# SHOW_FEATURES NO Okay. Not much, really.
  4. I have the DESIRE to try to make a working fork of the Open ROMs for the X16. It will be a learning experience. I've got to start somewhere, so I'll start with what's there. (1) Repo forked and cloned. (2) Re-reading the README (3) Reading the CONFIG options for a custom build. In particular, I'm going to first look at the config for the CX16, of course.
  5. I'm with Tom here. I know how to solder, and I enjoy soldering (to a point), but that means very little. There's a big gap between "I can solder a header onto a Raspberry Pi Zero" and "I can properly and correctly solder" kits like the Mini PET, the Gigatron, the PE6502, or the X16.
  6. I was thinking exactly your first point this morning. Existing stuff is one source of inspiration, though, and I suggest that cloning has value, especially for those who want to port. The exercise is good for the developer. In short, no reason to artificially limit anything; the platform provides its own boundaries. But that said, when I was a teen I worked on a number of my own games in BASIC (and two with some ML). They were in known genres but were not clones. The efforts paid off even though none of them were ever completed. Those are the games I'd like to create on the X16. But some people may not have ever went through that. For them, doing a clone of a known game is FINE.
  7. Watching his videos, his target is clearly an 8 bit Commodore with better graphics and sound. So... as (I think) he mentions, things that 286 machines were capable of.
  8. Updated with some more vision statementy things. I. A PRETTY MAP Rounded coastlines, no overlapping sprites. II. AN ECOLOGY (1602) Terrain squares have their own characteristics, which define what can be grown on them. (1602, 7 Cities of Gold) Settlements produce people, supplies, ships, trade goods. Some are better at self-defense. They can be owned, and can rebel. (7 Cities of Gold) A "soft empire" model, based on relationships between settlements. (1602, 7 Cities of Gold) Establish and dismantle settlements. (Pirates, 7 Cities of Gold) Barter with or plunder settlements. (7 Cities of Gold) Explore.
  9. How about a Diablo-type engine, then? That would make a decent interface for an Ultima-like game and map.
  10. 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.
  11. Of course, Mr. Steil already has a good battery of KERNAL tests at https://github.com/commanderx16/x16-rom/tree/master/test
  12. Welcome, Charles! I'm basically in the same nostalgic boat as you.
  13. 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  
  14. rje

    KERNAL Test

    Version 0.1.0

    18 downloads

    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
  15. Actually what I was thinking of is testing the Open ROM. I guess there’s no piecewise way of doing that.
  16. 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!
  17. 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.
  18. 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!
  19. 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?
  20. 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.
  21. 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.
  22. It's not (noticeably) slower or faster, and technically it's a demonstration of the autoincrement, so I'm keeping it.
  23. 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!
  24. 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!
×
×
  • Create New...

Important Information

Please review our Terms of Use