Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/03/21 in all areas

  1. Yeah, I tend to create a load of macros, as well. By the time I’m done, my programs are more macro than assembly. Essentially, what this means is I’m making up my own programming language. And I’m fine with that.
    3 points
  2. Bringing clarity to code by lots of comments is not the Clean Code way of doing things, apparently. Comments have the disadvantage of being ignored by the assembler or compiler. Keeping them up to date is a manual process. And all manual processes will fail Good labels are a better option. The advantage of extracting small functions into macros is that you get better abstraction in higher level functions. In my example above, the function "clear_screen" contains mostly macro calls. It's possible to understand what they will do without looking at the macro. You get the big picture very quickly. And if you are interested in the details, you may look at the macro definition. That said, I've never tried to program anything in this fashion. It would be interesting to do that.
    2 points
  3. Well, I personally don't like (yet) to extract things that are used only once. It feels messy to me. But the example above makes the code very easy to understand. It took me only a few seconds to understand what you are doing. I wonder what's better: commenting code (e.g. giving headlines to sections of code) or writing macros with explanatory names Edit: or even use descriptive names for labels
    2 points
  4. Continuing on the topic of clean code, even though its not X16 Edit specific, I have some thoughts on how to apply to assembly programming. In the lesson linked above, Uncle Bob is talking a lot about the design of functions: Names of functions (and variables) should be carefully chosen, so that reading code is like reading (good?) prose Function names should contain verbs, as they are doing something A function should do only one thing; the process of cleaning code entails breaking a function into the smaller and smaller parts, and you know you're done when no more functions can reasonably be extracted A function should be short (most often 5 lines) In a modern cross assembler, such as ca65, there's nothing stopping you from naming things properly. But what about functions doing only one thing, and functions being short like 5 lines? Any high level language examines functions at compile time, and decides wether the resulting machine code is inlined or made into an actual machine language subroutine. Even if you are writing a lot of really small functions in a high level language, the binary code will probably be efficient. In 6502 assembly, if you do a lot of subroutine calls with JSR+RTS, they will all stay in the final binary code making it inefficient. I have never seen 6502 assembly code trying to be clean code in the way Uncle Bob describes. Would it even be possible without loosing performance? I think it might be, if you use extensive use of macros for code that you want to break out into a separate "function" where the resulting machine code is inlined. A simple example. Is this a good idea? .macro goto_topleft stz VERA_L stz VERA_M lda #(2<<4) sta VERA_H .endmacro .macro clear_line ldx #80 lda #32 : sta VERA_D0 dex bne :- .endmacro .macro goto_nextline stz VERA_L inc VERA_M .endmacro .macro is_finished lda VERA_M cmp #60 .endmacro .proc clear_screen goto_topleft loop: clear_line goto_nextline is_finished bne loop rts .endproc VERA_L = $9f20 VERA_M = $9f21 VERA_H = $9f22 VERA_D0 = $9f23
    2 points
  5. Hi, I'm David. No, not that David (i.e., definitely not the 8-bit Guy). So, why am I here? It's because I'm interested in the X16 project, and I've always been interested in computer programming. Never got into Commodore (had a ZX-81 an Actrix DS, and a CoCo 2 back in the day). I'm an A+, a navy veteran, electronics and instrument technician, a BASIC programmer, and am learning to program the RetroMax (Maximite II clone) in MMBasic. I also have a working SC126 CP/M machine (a z180) running MBASIC that I built from a kit. I'm not an assembly language coder. Maybe getting involved here might change that? As I head toward retirement I'm hoping I will have time to keep learning and growing, and maybe amount to an actual programmer someday. Oh, and the Linux version of the emulator can now be confirmed to run on PCLinuxOS with kernel 5.14.6 (64-bit). The readme said I'd have to build it, but the x16emu file showed up as an executable file, so I ran it from the command line and it ran. Anyhoo, glad to be here, and hope I can contribute in some meaningful way to the project. If I had to state a wish, it would be to develop a laptop/luggable version of the X16. (How cool would that be?)
    1 point
  6. Version 0.7.1

    762 downloads

    This is a space invaders inspired game. Use the mouse or joystick to control the player ship. The shield segments can take 2 hits each. If enemies get too close you retreat back to the last level. You lose when all your lives are gone or you fall back to earth level again. Now with 7 playable levels Requires emulator R38! Roadmap: more diverse enemy formations enemy attack raids over the sides power ups (shields, double cannon, disruptors etc.) boss enemy joystick control done music done Different enemy sprites. done Sprite animations. done for player sprite and enemies fade in/out of palettes and backgrounds. done more levels with more backgrounds (all planets of the solar system), done sound effects basics done title screen How to use with the local emulator: Unpack ZIP file into the same directory as the emulator. Start the emulator, then enter LOAD"INVADERZ.PRG" RUN
    1 point
  7. Probably everybody but me knew about this (3 days ago) but maybe some of you are not on FaceBook so also. missed this 'news'... David himself said:
    1 point
  8. I think the key to programming / software engineering is making that judgement call on a case by case basis. Sometimes one will be preferable to the other. One thing I haven't done yet, but really need to do, is create alternative mnemonics macros for the various branch instructions. CMP #value BEQ label Is pretty clear. I think it becomes far less clear when it is something like: AND #mask BEQ label To me, reading that, my brain wants to go to the place where "if the relevant bits in A are equal to the mask then branch". But it really is saying the opposite. In a case like this a simple alternative like BZ/BNZ as alternatives to BEQ/BNE makes a world of difference to the way I read the code. Also, my OCD flares up whenever I see BPL. BMI isn't bad, I can read that as "branch negative". BPL though intuitively (even though I know better) means "branch positive" and zero isn't positive in my mind. I mean, I know how to use it, but the official mnemonics selected for 6502 leave me wanting at times.
    1 point
  9. I do like using asm macros to abstract away clutter. Something simple like: LDA #whatever STA wherever I think looks much more readable personally behind a STI macro, which I've used recently with Acme on some code that already existed for that assembler: !macro STI .addr, .value { LDA #.value STA .addr } It's such a simple thing, but even as tiny as it is, it so much better represents the intent. Now, the name in this case isn't necessarily ideal unless you're trying to keep your asm continuing to look like asm. And for me, if I can take a bunch of these sorts of 2 or 3 or more line "routines", I'm able to have twice as much code on screen in context, which makes comprehension easier (for me). !macro ADD .dst, .src { CLC LDA .dst ADC .src STA .dst } I like that when it fits the pattern much more than the equivalent four lines. And I can have ADDI, or ADDW, or ADDWI. I think those are good naming conventions for commonly used snippets that can themselves be used to create larger even better named routines. I like some things about acme. In some ways it is a lot simpler. It's macro facilities aren't as good IMO as ca65, for example, but they are much better than nothing.
    1 point
  10. Spurred to action by the Mini-PET. He uses a 65816 as the CPU, and a CPLD to do a lot of the dirty work on the board. https://github.com/fachat/MicroPET Commodore 3032 / 4032 / 8032 / 8296 with options menu to select at boot Boot-menu to select different PET versions to run 40 col character display 80 col character display 8296 memory map emulation IEEE488 interface (card edge) Tape connector (card edge) PET graphics keyboard, or alternatively a C64 keyboard Improved system design: 512k video RAM, 512k fast RAM accessible using banks on the W65816 CPU boot from an SPI Flash ROM up to 12.5 MHz mode (via configuration register) VGA b/w video output Write protection for the PET ROMs once copied to RAM lower 32k RAM mappable from all of the 512k fast RAM Improved Video output: Hires graphics mode (using a configuration register) modifyable character set 40/80 column display switchable 25/50 rows display switch multiple video pages mappable to $8000 video mem address
    1 point
  11. I've done some code cleaning the last couple of days. Very rewarding when the code becomes more compact, more readable, and more stringent. So far I've reduced the binary by almost 200 bytes. Some time ago, I watched a few lectures on Clean Code by "Uncle Bob". Very inspiring, even though not all paradigms may be used in assembly, if you want things to fly fast. A nice weekend to all of you!
    1 point
  12. As promised, here is a quite a big update to Concerto. The most notable changes are: Concerto is now licensed under the BSD-2-clause license: You can use it in your own open AND closed source projects! The YM2151 is now integrated into Concerto. Freely combine VERA-PSG and YM2151 to create your sounds! You can even modulate the pitch of the YM2151! Reduced number of PSG oscillators per timbre from 6 down to 4 for lighter memory usage. Load/Save named single timbres and banks (a bank is the entirety of all 32 timbres that can be loaded at the same time). Filename editing made possible by adapting code from the awesome VTUI library made by @JimmyDansbo Factory sounds are included (load bank "FACTORY" from SD card to view them). Internal optimizations, the PSG sound slightly changed compared to previous versions. Cleaned up UI from unused stuff I have NOT added support for the YM2151's internal LFO. For the time being, Concerto's own LFO can at least do vibrato, even though it doesn't sound as nice as the native LFO (I guess), but let's keep things simple for now. The last things I want to add before going v1.0 are automation of volume and vibrato (similar to the already implemented pitchbend). Unfortunately, I haven't gotten loading of FACTORY.COB (the sounds that come with concerto) in the "Try it now" section to work. It works flawlessly locally with an SD card image loaded. I have read that the filename extension must be whitelisted in order for it to work. I read that ".SEQ" and ".PRG" are okay. I have also seen ".BIN" being used successfully in the Web emulator. I have tried using ".BIN" earlier today, but with no success. I am using the Kernal routines to load and save. Maybe I am doing something wrong there? Do I need to set the secondary address to a specific value for it to work? If you have an SD card image loaded into your emulator, and the FACTORY.COB file is on there, you can enter the file name "FACTORY" in Concerto (no extension needed, Concerto adds that for you) and click "LOAD BANK". Then you can view all the sounds that I made so far.
    1 point
  13. Quick note here that I am making good progress towards integrating the YM2151 into Concerto. In fact, it is already working and it is just a bunch of these pesky little details that need sorting out. Expect an update in the next couple of weeks.
    1 point
  14. Stopping the channels before repeating a song is a good idea. I will change this in the next release together with the possibility to stop/pause the music. Indeed more effects have to be implemented as a lot of mods sounds ugly without them. I'm planning a code clean up and some documentation to put the code on Github so the community can help to improve the player.
    1 point
  15. I want a development system. Shut up and take my money. PM me as soon as you have one available to ship.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use