Jump to content

x16tial

Members
  • Posts

    148
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by x16tial

  1. In the monitor use oxx, and make sure it 's not a Shift-O (like if you're in lower case mode), and make sure you use BOTH digits, so bank 0 would be 'o00', 255 would be 'off' (use hex) For inspecting vera memory use ov0 and ov1. o by itself will reset back to main memory bank 0 to summarize for the monitor banks: o00 to off (switches both ram and rom banks) vera: ov0 and ov1 o by itself: same as o00 (then use m to display whatever part of memory you're after) pro tip: do a quick m 9f60, and the first two numbers will tell you what banks you're looking at (rom, ram) (the rom bank is 0-7 and wraps around) For the debugger: the b command doesn't seem to work but if you do m bbaaaa, it does, for example: m 01a000 m 04c000 I haven't yet discovered how to display VERA memory in the debugger derp, you guys already figured out the debugger above
  2. Which pixel was Frodo? I keed! Looks awesome.
  3. If you need 4 buffers, that would still only take 80k (aligning each buffer with 2k boundaries) then just change the tilebase bits 2 and 3 accordingly. But why would you need more than 2? (draw on 1 while displaying the other) edit: I see what you mean, you'd have to include logic to avoid "bleeding" into the other buffers, but even if scrolling worked, that would still be true
  4. quick sort demo View File Kind of a fun demo of Quick Sort on the CX16, using the random "static" of the startup VERA memory and using the 640x480 bitmap screen. Tap any key to progress from: Initial static Slow sort, so you can see what's going on, kind of satisfying to watch Re-randomize Full speed sort, this is 37.5k, which the CX16 sorts in a couple seconds Back to Basic Written in assembly Submitter x16tial Submitted 03/09/21 Category Demos  
  5. Version 1.0.0

    20 downloads

    Kind of a fun demo of Quick Sort on the CX16, using the random "static" of the startup VERA memory and using the 640x480 bitmap screen. Tap any key to progress from: Initial static Slow sort, so you can see what's going on, kind of satisfying to watch Re-randomize Full speed sort, this is 37.5k, which the CX16 sorts in a couple seconds Back to Basic Written in assembly
  6. Not a bad idea, who all are working on something like this, besides me and you?
  7. You're right, it has just worked well for me, but we're talking about 2 bytes and 2 cycles, so yeah, it's not much savings to not do it.
  8. I happen to be working on that very thing. I think I’ve got all the pieces pretty much worked out, now I just need to stitch them together. Here’s the vision: in the editor, no line numbers, just labels. You’ll be editing the code in place, no separate file, no compilation translation or transpilation. The editor will just abstract away the line numbering, but will still leave a native V2 basic file that can be run, saved, and distributed without requiring the editor. Also: long variable names, again, abstracting away the actual implementation that will still use the 1 or 2 character variables. What it’ll do is have a dictionary of labels and variable names in rem statements that the editor will use to map the “friendly” to the actual. I’m a fan of “less is more” in interface design, so will have minimal interface real estate. I’m working on the assumption that V2 basic is pretty much set for the X16. Somebody please correct me if there’s a chance that a different Basic might actually make it in.
  9. Couple tips: The CMP #0 after the JSR GETIN isn't necessary. The BEQ will behave correctly if there's a 0 in the accumulator. Instead of CMP #4, you could use CMP #3 which will detect STOP (Esc in the emulator).
  10. I calculate that it would take 150k to double buffer 640x480x2bpp... am I missing something? But I'm also wondering how helpful it is to say "just get a Raspberry Pi", when of course that's always an option, along with myriad other platforms, including PC's, when what I'm thinking the purpose of this discussion is to figure things out on *this* platform, the X16.
  11. I'll fully admit to not being an expert here. But I think the VERA has enough memory to double buffer the 1bpp 640x480 bmp mode. Does that still not work for the frame rate you're trying to achieve?
  12. Edited: I just realized you did that cool demo, you're obviously not developing in BASIC. But yeah, Screen RAM can be pretty efficiently filled/cleared in assembly, let me know if you need any tips. But yeah, perhaps that even isn't fast enough for what you want to do. But with 2 channels and auto incrementing, there might be possibilities.
  13. You might be talking about the 65XE debugger: https://sourceforge.net/projects/c64-debugger/ But also, if you run the emulator with the -debug option, you can then use the debug commands detailed at https://github.com/commanderx16/x16-emulator#debugger
  14. Actually, you could replace 51 with: 51 VPOKE1,$F9C1,I And it'll print the numbers as it goes.
  15. If you do want to do it that way, take out the PRINT statement (line 52). your output to $9f23 is colliding with PRINT which is using the VERA channel(s) as well. Or use VPOKEs, as @DusanStrakl mentioned.
  16. x16tial renumber View File Version 0.1.1: renumber your BASIC programs! BUT, for now, GOTOs, GOSUBs, THENs, and ONs will have to be manually fixed with the aid of the cross reference that prints when you execute the renumber. (Copy the cross reference list from the shell window and paste it somewhere handy. Make sure you have -echo on when you start your emulator!) To activate: LOAD "XREN.PRG",8,1 SYS 1300 NEW (this resets BASIC's memory pointers) and load your basic program, then type: REN <starting line number>, <increment> The old line number, an arrow, and the new line number will then print, giving you a cross reference for fixing gotos and such. Currently, <increment> needs to be 1-255 HIGHLY RECOMMENDED: Download and activate XMA (x16tial mouse aid) from the Dev Tools area as well, which is very handy for getting around your program to make those changes. FUTURE VERSION(s) will incorporate making the changes to the references, but for now, this should save some work in renumbering your program(s). This is good for R38, future revisions of ROMs will probably break this. But I will try to supply updates as quickly as possible. Note: It *is* possible to get illegal line numbers (> 63999). What you do after this, you do so at your own risk! Submitter x16tial Submitted 03/02/21 Category Dev Tools  
  17. Version 0.1.1

    26 downloads

    Version 0.1.1: renumber your BASIC programs! BUT, for now, GOTOs, GOSUBs, THENs, and ONs will have to be manually fixed with the aid of the cross reference that prints when you execute the renumber. (Copy the cross reference list from the shell window and paste it somewhere handy. Make sure you have -echo on when you start your emulator!) To activate: LOAD "XREN.PRG",8,1 SYS 1300 NEW (this resets BASIC's memory pointers) and load your basic program, then type: REN <starting line number>, <increment> The old line number, an arrow, and the new line number will then print, giving you a cross reference for fixing gotos and such. Currently, <increment> needs to be 1-255 HIGHLY RECOMMENDED: Download and activate XMA (x16tial mouse aid) from the Dev Tools area as well, which is very handy for getting around your program to make those changes. FUTURE VERSION(s) will incorporate making the changes to the references, but for now, this should save some work in renumbering your program(s). This is good for R38, future revisions of ROMs will probably break this. But I will try to supply updates as quickly as possible. Note: It *is* possible to get illegal line numbers (> 63999). What you do after this, you do so at your own risk!
  18. I agree to a point, but if the lower price comes at a cost of complexity, it's probably not worth it, in the long run. Personally, I'd rather it not be obtainable to some, if the choice ends up being it not being produced at all. Which would happen if there's low market uptake.
  19. I just want to throw out there, while it may be terribly obvious, that simpler is going to beat more complex. You're already dealing with a small-ish market, how many people under age, say 30, are even going to be remotely interested in retro stuff? Some yes, but your largest market is going to be older-ish folks yes? This market is probably going to have a fair amount of discretionary income, therefore drop any options that save on the initial purchase price, I'm mainly talking about RAM here, just fix it at the 2MB and go. (The optional keyboard is fine, I'm talking about internal specs) This market is going to have more money than time, don't make the consumers or the developers that will exist in this market spend time trying to sort out permutations of all kinds of configurations, set the specs and then in higher Phases, just reduce form factor. A handheld CX16 sounds awesome. I'm even starting to think a speed boost may not be a good idea in higher phases, since it might break existing software's timing (unless the speed is configurable, easily) The most successful portion of the C64 market (all the games, then and now, and all the demos then and now) relied on stock hardware (I said *most* successful portion of the market). Having all kinds of configurations, while sounding nice on paper, is more likely than not going to muddy the waters, causing fragmentation and confusion, and hurting your market penetration, in my opinion. My 2 cents. Thanks.
  20. Well, for most of us the emulator is the ONLY choice at the moment. I can see myself, especially with the upgrade keyboard, doing a fair amount of development on the actual hardware. Especially if there's any "pain" to transferring files, which I kind of foresee, until some kind of networking is available. Even a direct serial link would be nice.
  21. Oh my. That. Sounds. Awesome. I love and hate you right now.
  22. And a bit of other info. My program above is pretty inefficient on space, by doing one statement per line. Every BASIC line has 5 bytes of "overhead", so each additional statement on one BASIC line saves 5 bytes per statement, by not having it on its own line. I might play with how many PRINTA$;'s I could get by packing in the statements, and I could do it two ways. One way, by using the 80 character limit per line that you get when entering lines in the screen editor and a 2nd way that allows you to get 250 bytes per line, when building the BASIC lines from Assembly. Possibly more "Fun" to come!
  23. Yeah, all basic keywords (and operators) are tokenized whether you input the full keyword, or use the shortcut. PRINT's token is $99, for example. So all *V2* keywords and operators use only one byte. They also are all $80 and greater (bit 7 set). The new keywords introduced in the X16 ROM take two bytes, one for the "escape" code $CE, and another for a token, again $80 and greater. There are 68 V2 keywords, and 8 operators, making 76 tokens ($80 through $CB), and X16 includes 22 new keywords ($80 through $95).
×
×
  • Create New...

Important Information

Please review our Terms of Use