Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. Welcome Sisko. Archaeology and computers belong together!
  2. That's a good suggestion, Calculon.
  3. You need a Linux, with GIT, GCC, GNU make, and libpng development libraries (libpng-devel package on Debian, if I'm not mistaken). If you only have Windows - you can use Windows Subsystem for Linux, it should work. I'm not sure about Mac OS - I don't have a Mac. Maybe this is why. I have OSX. Maybe I'll have to try this on a Raspberry Pi running its Debian-ish thing. Or... or a container.
  4. Meh, still produces errors. Setting it on the back-burner and letting my hind brain think about it for awhile. I suspect the flags aren't getting picked up. Or something. On the other hand, ACME builds just fine.
  5. 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
  6. My first roadblock: running the right compiler. I suspect it's trying to use clang, when it should really be using acme.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. How about a Diablo-type engine, then? That would make a decent interface for an Ultima-like game and map.
  14. 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.
  15. Of course, Mr. Steil already has a good battery of KERNAL tests at https://github.com/commanderx16/x16-rom/tree/master/test
  16. Welcome, Charles! I'm basically in the same nostalgic boat as you.
  17. 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
  18. 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  
  19. Actually what I was thinking of is testing the Open ROM. I guess there’s no piecewise way of doing that.
  20. 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!
  21. 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.
  22. 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!
  23. 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?
  • Create New...

Important Information

Please review our Terms of Use