Jump to content


Popular Content

Showing content with the highest reputation on 07/18/20 in all areas

  1. 5 points
    Update : I rewrote the parser in assembly (I admit it was way harder than with Millfork) but it's not only that. On my way to learn how the X16 works, I found out I didn't though about IRQs as a possible solution to my previous question. So what I did is write a custom IRQ routine that runs before the Kernal's own subroutine. What this routine do is find out when the cursor has changed its line and parses the potential code found in the cursor's old position. It ignores the line if it's not starting by a number. With that, the program is even lighter than the previous one, from around 200 bytes ! Internally, the program insert the classic BASIC program SYS command but also a second command "NEW" so that you can start writing your basic code directly after running the program. The main code is located at address $8000 so you have some space to write your basic program. Here's the prg file : highlight.prg The source code consist of few files so I will post a zip file containing them. don't mind the weird tree it's mainly because my programs shares the same libraries. basic_highlight_src.zip I didn't have tested everything so maybe there are bugs that I don't have found yet. Feel free to report anything you found while testing Again, thanks for reading !
  2. 5 points
    Hi all, I'm going to have to come up with a title for this project sooner rather than later.... Made good headway on coding up the different hex graphics on layer 1. I've done 8 different terrain types so far (sea, lake, beach, scrubs, meadow, pasture, orchard and cave) - there'll be 32 different types in the finished game. Pixel graphics is not one of my strong points, but hopefully it should be obvious which is which! I've finished the hex terrain text descriptions and written and debugged the scrolling routine that scrolls the message window as you move from tile to tile. It counts lines scrolled and if there's more than a window's worth of text to scroll all at once, it brings up a "Scroll..." prompt and waits for the user to press the enter key before continuing to scroll. The assembly for it runs so blinking fast, I had to write a delay subroutine that gets called inbetween each character being drawn so you can actually see the text scrolling, otherwise it looks like all the text just appears on the screen at the same time. (ignore the drawing glitch going on at the far left hand edge of the hex window, next thing on my list of things to fix!) Suddenly it's beginning to look more like an actual game now! ta ta for now
  3. 2 points
    I am sure there are good reasons for all decisions concerning the memory map. But to be curious, I am wondering about two things: 1. Zeropage $00 and $01 will be used for memory bank settings and $03-$7f will be available for the user. Why not locate the memory bank settings to $7e and $7f and leave $00-$7d to the user? It seems like a cleaner layout to me. 2. The I/O area is located to $9f00-$9fff, then banked ram starts at $a000. Why not locate the I/O area to $0400 giving the user approcimately extra 8K of continous memory (if bank 0 is used)?
  4. 1 point
    Hello all, My name is Frank van den Hoef and I am responsible for the design of the VERA module (the audio, video and storage hardware module), which is part of the Commander X16.
  5. 1 point
    Yes, that's correct. Whoops! My bad, it seems that I completely forgot about that. Edit: I've gone ahead and fixed the wiki entry.
  6. 1 point
    Ok, my mistake, but i write it down here for others, who also don't know. If you want to tell the asm compiler to take a label's low and high byte, and compile it into your code you have to do this:
  7. 1 point
    My project, of course! I had copied and pasted a SETNAM/LOAD pair from another part of code that was loading to banked RAM and did a clear of the bank in between. The address containing the bank number was initialized to zero, so when the bank was cleared unnecessarily when I was loading other data to VRAM, bank 0 was blown away. Oddly enough, this did not cause any other errors in the code execution, as apparently the kernal can handle everything but the key mappings getting zeroed out.
  8. 1 point
    Thanks everybody for your help! I found the errant code that was blowing away bank 0, a copy and paste error that had no other side effect.
  9. 1 point
    I've been using ACME for a project of mine, but I agree that I'm starting to outgrow it. As was said above, it is dead simple, so for getting started it's a great option. I plan on diving into ca65 at some point too, but I haven't had a good reason to just yet. I think the main hold-up is having to rewrite my macros.
  10. 1 point
    Making the filenames A-based work as well as hex, and while it might be easier for the X16, hex filenames are a little more human friendly, splitting the difference
  11. 1 point
    Yeah, that depends on your needs (of course). It's likely to be perfect for emulation, at least up to PS1, but hopefully it could cope with PSP, and of course browsing and certainly basic stuff is possible. I'll likely use it in lieu of my laptop most of the time as it's more portable and pretty equivalent in power, and I might also dispense with my smartphone, as it optionally includes 4G. The high price is also not some small part down to the development costs, and over the 5ish years there has been a roller-coaster to say the least of development progress, hiccups and problems (now sorted). If you're on the fence, I'd recommend waiting for reviews, and I'd also say that production costs are likely to drop a little, so the price may go down a little when it's finally in full production. In a news update - the first completed production unit has been sent out, and apparently expected to be received by a developer in the UK - he's helped sort out some software issues, but I'm hoping over the next couple of weeks there will be quite a bit more information as units start to trickle out to early pre-order customers. Oh, and the DS is a very neat design. I think the Pyra's size is probably equivalent to the New 3DS XL.
  12. 1 point
    I've been doing some research on the User port, and it looks like it will have 14 addressable lines. This is enough to run software serial at up to 9600bps without any trouble, and with an external device like an Arduino, it could go much faster - at least 115,200. If I can get buy-in from Lorin and Mike, I'll start working on a Fast Serial library that uses an external Arduino as a UART and communicate with it through the User port.
  13. 1 point
    Sure. I've gone ahead and updated my builds at https://github.com/indigodarkwolf/x16-bin/. x16emu_Release.exe was built with compiler and linker optimizations enabled, x16emu_Debug.exe was not. The original r37 exe is included as x16emu.exe. Keep in mind that this is extremely unofficial, not all of the fixes/changes in my branch are necessarily going to make it into r38. And also, it should go without saying that I'm not the author of all the changes, this build rolls up everything that's been accepted into the main branch of the emulator since r37, plus a few extras I've submitted. That all said, here's a rundown of the differences from r37: Fixed VERA line IRQ configuration and triggering. Added VERA sprite collision IRQ. VERA emulation optimizations Built-in emulator debugger changes (`-debug` command-line option, then toggled with F12) Debugger now displays the 16-bit zeropage registers r0-r15 when showing system RAM (Corresponding to $0002-$0021). See also: Commander X16 Programmer's Reference Guide. This also displays an additional 4 registers past the X16 API's registers ($0022-$0029), labeled x16-x19. Debugger can now show a dump of VRAM in place of the system memory dump. `v <addr>` where <addr> is the start address of VRAM you want to inspect. (Accepted, but a merge error introduced a bug and the fix isn't accepted yet) Debugger can now fill memory, either system RAM or VRAM depending on what's presently being dumped. `f <addr> <value> [count] [addr_incr]`, where <addr> is the address to modify, <value> is hexadecimal value to fill at that address, [count] is an optional number of times to write the value, and [addr_incr] is an optional number to increment the target address by between writes ('1' to fill a contiguous region, '2' to fill every other byte, '3' for every third byte, etc). Debugger VRAM dump is colorized to indicate whether the portion of memory has special meaning to the VERA: (Not accepted yet) Cyan is tilemap/textmap data Green is potential tile/glyph data (determined by the start of the layer's tile data, ending after 256 or 1024 tiles' worth of bytes, depending on tilemap settings) Red is the portion of VRAM mapped to internal features (palette, sprite data, PSG). Grey is none of the above/potentially unused (Edit) Debugger can now take a "snapshot" of system RAM, with `snap`. It can then perform a diff on that snapshot, with `diff`. (Not accepted, not planning to submit for r38 at this time.) Added a "warp" mode. Launch the emulator with `-warp` command line option to reduce VERA framerate (sprites will still be considered, but only 1/64 frames will actually be drawn to the screen) and uncap the emulator's speed to 64X. Warp factor can be scaled by powers of 2, using `Ctrl -` and `Ctrl +` key combinations. (Not accepted yet) I/O registers $9FB8-$9FBB expose a 32-bit clock tick count for the CPU. It appears this is emulator-specific behavior, so do not depend on this for anything running on final hardware. The emulator environment can be detected by testing $9FBE for the value $31 and $9FBF for the value $36 (these are the ASCII values for '1' and '6', respectively). Added a variety of instructions from the 65C02 that were missing: (Not accepted yet) BBR0-BBR7 (branch if bit reset) BBS0-BBS7 (branch if bit set) RMB0-RMB7 (reset memory bit) SMB0-SMB7 (set memory bit) WAI (wait for interrupt) Moved the "debug" opcode from $FF to $DB. The emulator doesn't implement STP (stop), which would be at $DB, and the debug opcode's previous location conflicts with BBS7.
  14. 1 point
    Oh, oh! I can answer this, in fact, I did some while ago! https://github.com/commanderx16/x16-emulator/wiki/(ASM-Programming)-Interrupts-and-interrupt-handling
  15. 1 point
    Y'all know PCB stands for Potentially Could Be Blue. Or is it? PCBWAAAAAAYYYYYY Sorry, had to do it. In any case, it looks pretty cool
  16. 1 point
    Agreed! In future we'll try to only make announcement posts here, then paste the link into FB (which will generate a preview of the post anyway). The website will be the go-to #1 source.
  • Create New...

Important Information

Please review our Terms of Use