Jump to content

TomXP411

Super Administrators
  • Posts

    1021
  • Joined

  • Last visited

  • Days Won

    69

Everything posted by TomXP411

  1. So the reason for VPOKE is that VERA uses vectored communication. What that means is that to communicate with VERA, you have to set one set of registers with the address and another register with the data. VPOKE hides these details by setting the address registers for you. So what you're doing with that first VPOKE is three things: This sets the VERA bank register to 1 Sets the VERA address L and H registers to $F9C0 Sets the VERA data register to 255 The VERA address registers live at $9F20-9F21, and the bank/increment register lives at $9F22. So to set an address of $1:F9C0 (bank 1, addr $F9C0) in VERA, you would need to do this in BASIC: POKE $9F25,0 : REM always set the ADDRSEL register to make sure you are using the correct port POKE $9F22,1 : REM Sets the bank register to 1 POKE $9F21,$F9 :REM high byte of address POKE $9F20,$C0 :REM low byte of address and then set the data value with POKE $9F23, 255 So now that we see how you can directly address the registers, you can easily translate this to assembly code: STZ $9F25 LDA #1 STA $9F22 LDA #$F9 STA $9F21 LDA #$C0 STA $9F20 LDA #$FF STA $9F23 (Note the STZ is a 65C02 instruction. If STZ doesn't assemble, you may need to enable the extended 65C02 opcodes in your assembler or fall back to LDA #0 / STA $9F25). That's just to write one byte. You actually need to write at least 3 bytes to set the frequency and volume, so you'll want to set the Address Increment. This is the upper 4 bits of $9F22, and you can set the increment to 1 by writing $1x to that register. Since you're already writing a 1 there, you can instead write $11 to automatically increment the address register every time: STZ $9F25 LDA #11 STA $9F22 LDA #$F9 STA $9F21 LDA #$C0 STA $9F20 LDA #$FF STA $9F23 LDA #$05 STA $9F23 LDA #$FF STA $9F23 LDA #$80 STA $9F23 The sound will now be playing. To turn it off, STZ $9F25 LDA #1 STA $9F22 LDA #$F9 STA $9F21 LDA #$C2 STA $9F20 STZ $9F23 I should mention that these are "off the top of my head" instructions. I don't have access to the emulator to try this, so it may need tweaking. If you get this to work, maybe you can post the code (and let us know which assembler) you used. I have actually been considering writing a Morse trainer. Maybe it's time to write one. --... ...-- / --- -- / -.. . / - --- -- -..- .--. ....- .---- .----
  2. Don't worry, if it's in the wrong place, we'll move it for you. We'll also helpfully let you know where we put it, and why. This forum is a good place WIPs or "works-in-progress", regardless of platform. That includes stuff you are writing from scratch, things you are modifying (FOSS, PD, or by permission), and projects you're reverse engineering (again, same rules.) I pointed out AOTPR specifically, since that's a new game written for the X16 as well as the Commodore 64 and a bunch of other 8-bit and 16-bit platforms. There is a "Software Support" section as well, but that's a Q&A format and probably better for asking "How do I?" or getting help with bugs. In the new forum platform, we will be separating out "8-Bit Productions" forums from "Community" forums. You'll be able to tell the difference from the icon. This will be a "community" forum, for free discussion of anything retro - including the Commander X16 (and the MEGA 65 - both of which are new, but in the style of retro.)
  3. tl;dr: no. GeckOS is as close as you're likely to get. Long version: No. Modern Linux (or more correctly, modern POSIX) is far too complex to run on an 8-bit CPU like the 6502. Even the first version of Linux was designed for 386/486 PCs and uses the native multitasking features of those CPUs. So porting Linux itself in any meaningful sense is simply impossible. However, Linux is a clone of the UNIX operating system, developed by AT&T. If you extend that question to "can you port UNIX to the 6502", everyone will point at GeckOS. While GeckOS is not UNIX, either, it is designed to be as much like UNIX as you are likely to get on an 8-bit computer. https://en.wikipedia.org/wiki/GeckOS So the question becomes: can you port GeckOS to the Commander X16? Absolutely. One of of the bright points of the X16's design is the decision to stick with the Commodore style KERNAL, which allows software to be fairly easily ported between Commodore-like systems. Well designed software can even be ported to non-Commodore platforms, like BBC Micro, Atari, or Apple, by modifying the I/O routines to fit the BIOS of the platform in question.
  4. You're not that odd. It's what I use, too. It's not just a good assembler, but the easiest one to include in your projects, since it doesn't have any extra dependencies or really require "installation". You just toss the 64tass.exe in a directory with your project, and you're good to go.
  5. You appear to be running R41 of the emulator. You need R38. Over the last few releases, things have been moving around, and the graphics and memory bank registers aren't in the same place on R38 and R41. Here's how I got it to run on my system: 1. Install R38 of the CX16 emulator from https://github.com/commanderx16/x16-emulator/releases/tag/r38 2. Extract the Commodore Robots ZIP file to somewhere on your hard drive 3. Look in the extracted files and copy the contents of X16 into your emulator directory. level-a, level-b, and so on should go directly in the emulator directory. 4. start the emulator (double-click on the emulator icon) 5. LOAD "X16ROBOTS",8,1 6. RUN
  6. I like the layout... maybe you just need to reduce the number of "nearby" systems? One way you could present is as the "closest 5" and then a button that expands the list and lets you view all of the systems, sorted by distance (with systems that are unreachable with your current drive technology marked in red or something). If you provide a map along with the game, the user could then use the map to plot a route using just the systems close enough to travel to with one jump. (Basically the way you do it in Elite:Dangerous, but obviously with a simpler interface.) One cool feature might be a "route editor" that lets you plot a route, then the entries on the screen could be sorted according to how close to your route they are. This is the way you'd expect to see waypoints listed in an airplane's FMS, for example.
  7. I'm a big fan of these mini PCs. I have 5 or 6 of them, although I use them mostly for day to day tasks. I have a Hades Canyon NUC that I use for media and light gaming in my office, an i7 and i3 NUC that I use for media in other locations, an Alienware Steam Machine box that I use for light gaming and media on my home theater system, and a Skull Canyon NUC that I used as a video encoder. (That has since been replaced by an HP EliteDesk.) They're pricey, though... one trick is to buy them used. I can usually get systems on EBay for quite a bit less than the new price, and an 8th Gen i7 is plenty adequate for anything short of 3D gaming.
  8. Sorry... I looked this up on one of the Commodore 64 Wikis, which didn't spell it out very clearly, so I got the order wrong. I've fixed the Wiki entry and my examples above (with screen shots showing actual code and program runs). https://www.c64-wiki.com/wiki/SYS#Passing_parameters_via_registers
  9. Yes. @Michael Steil deserves a medal for his hard work, and @Frank van den Hoef single-handedly revitalized the project when he open-sourced VERA. The fact that we're seeing homebrew breadboard implementations is simply amazing!
  10. Hey @Scott Robison Turns out, someone beat us to the punch... there's a device that does much of what we're talking about. It's a drive emulator and network interface, named "Meatloaf." https://github.com/idolpx/meatloaf
  11. I liked it better than the other BBS software. I chose it specifically because it was written in QB and moddable. I built a threading mod for the forums that worked very well, if I do say so myself.
  12. Thanks for that. I'm a big believer in letting users do things with the fewest keystrokes, so I'll be using a combination of single-screen and cascading menus where possible. The colors actually come from my BBS days. I ran a WWIV BBS, and those were the colors I eventually settled on for the menu system.
  13. Thanks. Michael recently added the API to make it possible to do this. On the C64 (and prior to the API on the X16), you have to directly manipulate the keyboard buffer. That approach works fine when the buffer is in a known location, but the X16's ROM is still evolving, so the address of the keyboard buffer could change. On the 64, you'd do something like this: POKE 631,13 : POKE 632,13 : POKE 198,2 Locations 631-640 are the buffer itself (there's room for 10 keypresses), and the data at 192 is the length of the buffer. By setting that to 2, this causes the computer to process the first two values in the buffer. This technique would be basically the same on the X16, but since a bunch of things have changed locations, we can't count on the keyboard buffer being in one place. Hence the published API that pushes keys into the buffer. (I suspect the API was always there, just "unpublished".)
  14. It's the simplest way to build tooling, such as asset editors (tiles, sprites, levels, music), although it's not strictly necessary. Ultimately, all that is necessary is a BIOS with text and file I/O, plus a 5 command monitor program: Examine Memory, Modify Memory, Execute, Save, and Load. Everything else stems from that.
  15. It's theoretically possible - you can write a game cartridge that acts like a text UI, load a machine monitor and maybe even a BASIC interpreter on it. That's just all software. The only hard part would be getting keyboard input. You'd either have to put some sort of PIO chip, use the expansion connector (on an NES that has one), or hack a keyboard into one of the controller ports (probably with an Arduino.) I've also thought of doing this, but it would be pretty low resolution and probably look like a VIC-20 in terms of text size.
  16. A lot of the ML routines that we can access with the SYS command actually require the Accumulator, X, Y, or flags to be set to specific values. As it turns out, the BASIC SYS command actually has a way to pre-load these values into the CPU registers, as well as a way to read these back after the routine exits. These values are stored in $30C-30F, like this: 780/$30C: Accumulator 781/7$30D: X register 782/$30E: Y register 783/$30F: Status Register/Flags So if you wanted to call a routine like PLOT, which moves the cursor to column Y and row X, you'd set the registers like this: POKE 781, 10 POKE 782, 5 POKE 783, 0 : REM Clear the flags SYS 65520 This will place the cursor on row 10, column 5. Or, if you wanted to read the cursor position, you can set the carry flag: POKE 783,1 SYS 65520 X = PEEK(781) Y=PEEK(782) And yes - the X and Y are backward. The X register stores the row and Y stores the column. It probably has something to do with certain addressing modes only being available to the X register and others only being available to the Y register... Of course, the Commander has the LOCATE command, but if you're coding for BASIC 2 (C64, PET, etc), then this is the way to directly position the cursor. Another one that I find useful is the "stuff the keyboard" API: This will print the appropriate commands, then position the cursor so that two presses of the RETURN key loads and runs the next program. And since the keyboard buffer conveniently has two CRs in it, your next program will run. Here's the output (assuming F$(C) is TREK.PRG):
  17. VERA and the 65x CPUs use Little Endian. Least Significant Byte is first.
  18. The Atari 2600 VCS actually had a BASIC cartridge and keyboard. It was kind of horrible to use, though, since the VCS has a super-low resolution. There was also a keyboard + BASIC interpreter for the NES, called Family BASIC. https://en.wikipedia.org/wiki/Family_BASIC The Playstation 3 could boot to Linux in the first two major versions of the firmware, but Sony removed that ability later. Still, while it was available, it was possible to develop and play PS games in Linux on the console.
  19. I was going to suggest that, but I thought "Oh, I'm sure he already did that..."
  20. Thanks. It's basically just a menu screen and init code right now. I like these kinds of turn-based, casual games, and I want to finish this one, since I wasted hours on a version of this on the Palm Pilot back in 1998 or so. I know what I want to do with it, but it'll be a bit before I get back to it. I've just got too many irons in the fire, and Commander programming has been at the bottom of the list - but is rising, now that the emulator is moving forward. Michael has been knocking away a lot of rough edges in terms of usability, and I'm pretty excited about that.
  21. Wow I really like the look of the new 80x30 display mode. This is what I fondly remember from my Commodore 128 days.
  22. That's actually the Scroll Lock key, which would require special handling on Windows, which is probably why the emulator doesn't currently handle that well. You can't just read the key press directly, because Scroll Lock isn't actually registered as a keypress through all of the APIs. (I honestly don't remember if it triggers KeyDown, but I'm pretty sure it doesn't trigger KeyPress in the Windows event stack.) It is available through certain events, but there's still some work to do in order to handle that key specifically. The same goes for RESTORE (the Print Screen key) and RUN STOP (the Pause/Break key.) I expect that the 40/80 key will eventually work like the F4 key does now.
  23. Nobody was discussing the US English layout. This entire thread is about international layouts, and all of them, that I'm aware of, have dead keys.
  24. and it shouldn't... the way BASIC does GOTOs, the GOTO actually reads the address and line number of line 5, regardless, and then forwards to line 6. So since the NEXT:NEXT:GOTO get parsed and executed either way, the execution time for the two versions should be almost identical.
  25. Well, I'm just going to point out that they have the same dead keys already on their Windows, Macs, and Linux machines... so it should be no different on the CX16. I actually really appreciate that there will be an ASCII mode at all. The fact that it also incorporates international character sets is a nice bonus.
×
×
  • Create New...

Important Information

Please review our Terms of Use