Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. It's not the color that gets me. It's not the features like the expansion slots, VGA out, IEC interface, or the SNES adapters. Apologies to Frank, but it's not VERA either (although it is supercool). It's not even the sockets. It's that there's a 65C02 there, and a straightforward but clever banked memory map, on no-fuss static RAM, and it's going to run an ancient (albeit upgraded) Commodore KERNAL. That's what gets me. That, and maybe the SD slot. But I like all the other stuff too of course.
  2. Thank you for your effort! I'm thrilled to see all of your KERNAL extensions, and looking forward to using them.
  3. I've started (and stopped) writing a bytecode-interpreted small language for a few years now. I call the language "Cargo Cult" mainly because it's a cool-sounding name. But... its specs are kind of hazy. The bytecode interpreter is bog-standard, but the language it compiles to is fluid: it changes based largely on my whims. So, what better way to start again than to target an 8 bit architecture, says I. Forces me into constraints. Here's kind of what I'm aiming for in CargoCult 1.0. I *think* the key difference between it and a structured BASIC is the array notation and use, which is more or less borrowed from Perl. That, and the importance of the newline character in block declarations and endings. fn int buildZones totalSectors, startTrack, @zones for |index| 0..@zones.length my track = 1 + GLOBAL.totalTracks + startTrack; my sectorCount = @zones[index][1]; my endTrack = 1 + GLOBAL.totalTracks + @zones[index][0]; GLOBAL.totalTracks += @zones[index][0]; for |jdex| track..endTrack GLOBAL.@trackOffset[ jdex ] = totalSectors * 0x100; GLOBAL.@sectorOffset[ jdex ] = totalSectors; GLOBAL.@sectorsInTrack[ jdex ] = sectorCount; totalSectors += sectorCount; endfor endfor return totalSectors; endfn
  4. However, I like the idea of loading the asm at $8000... the monitor can introspect those locations, and doesn't know how to deal with the banks.
  5. You're right, and you're right. By the way, that was my problem -- load "blah",8,1,$a200 did the trick. Then I caught my code error (have to inx or else the thing never increments). Duh.
  6. A couple of thoughts. +1 for the jump table idea. Assembly as a set of utilities really fits a bottom-up approach to software engineering, and that’s a good thing. It also puts the complex bits into unit testable pieces of code. For passing parameters, note that the CX16’s extended ABI uses sixteen 16-bit pseudo-registers in zero page; these might make good candidates for a parameter reference list. C and cc65 is my preference. However, that doesn’t stop me from using BASIC, if only for prototyping. Cc65 also lets me toy with writing by own mini interpreters and APIs, and so on. Finally: as I learn how to use cc65, I’ll make notes, and put them here or somewhere.
  7. Thanks for that, Matt. I also realized, just now, that I was not loading the program correctly. So even if I set the bank correctly, if it ain’t loaded there, ain’t gonna be where I think it is. Now about putting ML in main RAM... I figure Furball Space Program will have a lot of BASIC as well. So I have to make sure ML doesn’t stomp on it, or vice versa.
  8. Getting "Hello World" to work using cl65 requires knowledge buried in the docs somewhere. It compiles. I load it and invoke with a "sys $a200". I'm obviously missing something. OH! Do I need to worry about BANK ZERO? => Answered my own question: yes, but that's not the problem, it still doesn't run. ; ; cl65 -o saludo.prg -t cx16 -C cx16-asm.cfg saludo. ; chrout = $ffd2 .org $A200 .export LOADADDR = * Main: ldx #0 loop: lda hello,x jsr chrout inx cpx #<(hellodone-hello) bcc loop exit: rts hello: .byte "--- HOLA MUNDO! ---" hellodone: .byte 0
  9. There's XCPL for the X16. However, even its inventor isn't using it. https://github.com/paulscottrobson/xcpl
  10. Thanks for these answers. I didn't know the rationale behind these changes... and though I've seen documentation for r38, I scratched my head wondering if it's a typo.
  11. Everything will be driven by your requirements and the hardware's abilities (limitations). Then, your success will probably depend on how to break down the project into milestones. And as much as you dislike interpreters, your first milestone *could* be implementing a bytecode that Base Camp will then be built on top of. (In other words, I think Lua could add some inspiration here.) Milestone two: your parser generates that bytecode, and your bytecode interpreter runs it for development purposes. Your third milestone could then be writing a compiler that turns those bytecodes into machine language. Note that it might be handy to have both a compiler and an interpreter. * * * Anyway, a modern BASIC with Pythonesque qualities is possible. I've seen BASICs out there which have modern flow control (functions) and no line numbers. Base Camp would be an order of magnitude better than BASIC2.0 if it only had that.
  12. I suppose I can answer my own questions by calling the KERNAL routine on the X16 emulator, checking the result, clearing the registers, then calling these routines, and checking the result...
  13. I wrote these from scratch. I want to write them without ever seeing the actual kernal. Easy-sounding ones first. How close are these routines to being correct? I'm a kernal virgin. Michael's pagetable site has the commentaries. I might be misusing opcodes. Error and boundary conditions might need handling. MEMBOT is virtually identical to MEMTOP. SETTIM and RDTIM. I think I'm going off the rails here with the indirect loading. Now I'm thinking these are all direct, which would greatly shrink the code... In for a penny, in for a pound. Here's UPTIM, and I suspect there's edge cases here I'm not seeing. And SCREEN and PLOT.
  14. Like your show, Mr. Pub! You have significant geek cred; I am envious. Ah, and your brother sometimes has some okay stuff too.
  15. Well done, except for your Californian accent. What's that? English accent you say? Meh, England, California, whatever.
  16. It's not the 8-bit computer I want, but I followed Mike's blog for some time, and thought it's a pretty good effort. The result is quite powerful for an 8-bit machine. It's also nice that it descends from the C65 ROMs... that makes the C65 essentially attainable, which is a laudable goal.
  17. I was just thinking about the GPIO bit-banging, and yet again I started thinking about using a Raspberry Pi (e.g. Zero W) as an infowebs gateway to talk to... Theoretically, a $5 solution (well, plus SD card), and it gives me an excuse to write Perl (because I love it) and Python (because I need the practice).
  18. It's not that I don't like writing games and stuff for the X16. It's that I haven't used sprites in my games yet. So what I have are BASIC programs that are *almost* compatible with other Commodore computers. Okay I've started using the RAM banks, so that's relatively irreconcilable. But I still feel the "pressure" to use more of the unique benefits of the X16. Plus, a plain-jane BASIC program just isn't that sexy. Gotta have graphics. There just aren't enough hours in the day...
  19. I've seen posts about networking, including the defunct UART emulation in X16emu r36. So from the FAQ I see these expansion areas: Four expansion slots with access to CPU databus, each with 32 bytes of mapped RAM. 8 GPIO lines (user port) Is this the likely way to connect to the Interwebs, via a network card that connects to a slot or the user port?
  20. Welcome Kevin. I hope you like Austin - I think it would be a great place to live! (I'm up in Dallas).
  21. Commodore's website in 1982 was primitive, to say the least. It was the kind of internet that was spiral-bound (mine was plastic, which starts to break down after 20 years). At least it was indexed.
  22. Welcome Mike. I've been watching your YouTube updates; the AESM looks slick!
  23. ^ What he said: thank you for your work here. I don't know how I can help, but I'll try to figure out something.
  • Create New...

Important Information

Please review our Terms of Use