Jump to content

Yazwho

Members
  • Posts

    81
  • Joined

  • Last visited

Everything posted by Yazwho

  1. If you're developing I guess you'll mostly be using the emulator, as the debugging experience is going to be better. That said eventually there are all sorts of possibilities. RMC's latest video gives some good examples of connectivity via an old (well new) Amstrad CPC.
  2. If you install 'ca65 Macro Language Support' you'll get syntax colouring and the like. The extension can add tasks to compile and link, but I prefer to do it all on f5 so I used the ps1 file. (Unless I'm missing something, its my first VSC project as well!) https://marketplace.visualstudio.com/items?itemName=tlgkccampbell.code-ca65
  3. I've uploaded the source. You'll need Visual Studio Code, cc65 and obviously the emulator. To build you'll need to edit build.ps1 to set your paths correctly. There's a C# Visual Studio project that calculates and creates the data tables for the background.
  4. Even simpler, its passive so takes no cpu. The palette offset for the background tiles is set at startup, and the 'pixels' themselves are a tile of solid colour from 1-8. (not zero!) So by only drawing the 'pixels' we get the transparent colour for free. (Set the Vera to step on by 2 bytes per write.) Below is a grab without the foreground layer which makes it more obvious. So all you need to do is create a overlay that lines up to the 8x8 tiles.
  5. Yazwho

    Spinning Intro

    Version 1.0.0

    51 downloads

    Another small intro. Sadly still no audio. If only it wasn't so painful to debug audio and if I had any sort of musical talent... Thanks for looking! Spinner.zip
  6. Spinning Intro View File Another small intro. Sadly still no audio. If only it wasn't so painful to debug audio and if I had any sort of musical talent... Thanks for looking! Spinner.zip Submitter Yazwho Submitted 04/15/21 Category Demos  
  7. Not sure that's what 8 bit hardware could do. Of the top of my head I'm pretty sure the best NES games like Mario Bros 3 had maybe 4 on screen? All of the above really came to the fore when machines moved to 16 bits. That said, there are all sorts of optimisations you can do to achieve some of your goals. You just have to figure out how to do it. Clever use of the sprite flipping and the colour pallette index will get you a long way there. What makes developing on systems like the X16 fun is overcoming the hardware limitations, memory being one!
  8. Deleted. The first post being at the top of page two caught me out.
  9. You should be able to read back the values once you've set them. That's the caveat though, you can't read them unless you've set them. Ie, you can't read the default palette. (Imho this should be set on startup by the kernel on startup...) Just checked, and the following does return $0f for both 'lda's. lda #$11 sta ADDRx_H lda #$fa sta ADDRx_M stz ADDRx_L lda #$0f sta DATA0 sta DATA0 lda #$11 sta ADDRx_H lda #$fa sta ADDRx_M stz ADDRx_L stp lda DATA0 lda DATA0
  10. cos is just sin offset by 90 degrees, or 64 if you use a 256 byte table. So you can save yourself some ram at the expense of an add. Depending on what you're trying to do, if it's possible to match the amplitude to what you need (so no multiplication is required) you'll obviously get better performance.
  11. If it is, you might want to post on /r/MechanicalKeyboards as they might be all over them!
  12. Yazwho

    PSG

    Thanks all, Is that the same for only setting\changing one of the 4? -abufs16 is good to know, but unfortunately didn't fix the issue, although it does sound a bit better. using 32 or more doesn't do much though. My machine isn't CPU throttled, so I dont think its that. I'll rewrite the code to do it all in the vsync, maybe that will help...
  13. Yazwho

    PSG

    Ok, I'm starting to hate writing audio code! So annoying to debug as you can't just stop and have a look at what's going on... Ahem, anyway.. Is there an order that the PSG data should be written to the channels? I've got some very rare crackling and am wondering if its because the data is being used before its properly loaded, or some other sequencing problem. Should I prepare the data and just copy it in over during the vsync or similar? Is there a specific time when the channels are read?
  14. It is amazing. Imagine, in the next 10 years, maybe we'll be able to get our own chips printed for a similar cost!
  15. Nice trick! I don't know much about audio and the composition of it, but how bad would it sound by using the vsync? The reason I ask is that having an interrupt fire at 'random' time during the could break code that highly relies on line based interrupts.
  16. Ah ok, that would make sense, so you can make changes to the wave for periods lower than the vsync provides?
  17. Wow, that's very impressive! I've only been able to get basic sounds from the PSG.
  18. Looks awesome! It's all PCM right? Do you have a feel for how much CPU the playback takes? I'm going to guess quite a lot?
  19. @StephenHorn Theres no specific mention of what VScroll does in bitmap mode. You can see why HScroll wouldn't work, but VScroll could. (ie shift the screen up/down by 320/640/xx bytes) It's just one of those bits of the docs that is a little unclear. I'm not complaining; I mean for a machine that isn't even real, things are pretty good!
  20. It means for anything you do, say plot a cube, you have to essentially draw it twice every frame as you need to blank out the previous render. Really expensive. I guess it's pretty limited given the size of vram, but still. I still have hope though, even if the code is frozen for release (which makes total sense), the 'P' part of FPGA means it can be changed in the future, so maybe post release some functionality will be added.
  21. Ah well, worth an ask. Bit of a shame to have to mostly stick to tile modes.
  22. That table of notes is so useful! Thanks!
  23. I know you're very far along when it comes to the design and implementation of the VERA sub-system. However I figure I'd throw this out just in case. Is there any chance block clear\fill functionality could be included so we can clear out blocks of VRAM? Right now the bitmap mode has considerable limitations as we can't just clear the previous frame without resorting to a pixel by pixel approach. It will sadly mean this mode is left to mostly showing static images. One possibility would be to add a bit to the CTRL register, so if set when we write to DATA0 it could fill the 256 bytes at ADDR_H, ADDR_M with the value. (As a programmer, obv I'd prefer something even quicker! It would open up the possibility to do something a little inventive with the mode.
×
×
  • Create New...

Important Information

Please review our Terms of Use