Jump to content

Ed Minchau

Members
  • Posts

    376
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by Ed Minchau

  1. You can find the numbers for the default palette here: https://www.8bitcoding.com/2019/12/default-palette.html?m=1
  2. For me, I not only need to load code into banks above 10, I also need to save data from banked RAM into files. And of course the kernal uses bank 00 while it is saving, so saving directly from a bank to disk is out. What I've been doing instead is creating a temporary file TEMP.TMP and saving $7000..8FFF in that file. Then for loading I load my 8kb file at 7000 and copy to banked RAM. For saving I copy from banked RAM to 7000 and save the file from there. After the loading or saving, I load TEMP.TMP back at 7000.
  3. CHR$(34) is the quotation mark. Anything following that is assumed to be within the quote mark, until the end of the line (in this case, the PRINT in line 40). If you start X at 35 instead it will look fine.
  4. Your code works great if it's in low RAM. However if you've got code in banked RAM, calling a routine in one bank from code in another bank needs JSRFAR. I used it a hell of a lot in the META/L editor, which is spread out over 16 banks of RAM.
  5. With SD storage, is compression even necessary?
  6. The banks are switched by setting the bank value in location 0000 for the RAM bank and 0001 for the ROM bank. The STA command for zero page takes three cycles, and loading the accumulator with a byte in immediate mode is two cycles, so around five cycles total. Way more in BASIC, of course.
  7. SETNAM requires the length of the filename to be in the accumulator. You're trying to save the file here? Don't use OPEN. Use the kernal SAVE routine instead; that requires two zero page bytes to point to the file start address, then the accumulator points to that address, and the X and Y registers are the low byte/high byte of the ending address, plus one. Also, in SETLFS, for saving use A,X,Y = 1,8,1. That works for me. So, supposing the filename is 13 characters long (for example) and supposing that you want to save from $0801 to $4080: LDA# 01 LDX# 08 LDY# 01 JSR SETLFS LDA #0D LDX#<Filename LDY#>Filename JSR SETNAM LDA#01 STA 7E LDA#08 STA 7F LDA#7E LDX#81; low byte ending address plus 1 LDY#40 JMP SAVE
  8. I like this idea. Ideally there would be a jump table in page BF so the OS knows where to look for the code. If that's standardized across apps it makes a lot of things easier. Low RAM would have space for data shared across apps.
  9. 80 characters is the maximum that the BASIC interpreter can handle, yes.
  10. In BASIC: 10 PRINT"PRESS ANY KEY TO CONTINUE" 20 GET A$: IF A$="" THEN 20
  11. I want one of those first 50 boards. I've put thousands of hours into programming for this machine, and I'm dying to try stuff on the actual hardware. My video demo worked on the emulator but not the actual hardware, so I need it to debug the code.
  12. There's a lot of symmetry in this image. You could get away with using four sprites, two pairs of images with mirror horizontal and vertical to get the other two. 32x32x4bpp is 512 bytes, so it would only be 1kb of data being sent to VERA, plus 4x8 bytes for the sprite attribute tables. Or maybe 3 of the 32x32x4bpp images, so 1.5 kb. Still close to the 1152 bytes needed for 48x48x4bpp.
  13. That dynamic heap manager makes things easier from the programmer's perspective, but it adds a lot of computational overhead at run time. It might be that one of the tradeoffs of having the dynamic heap manager is slightly more complicated sprite management code. And really it's all about tradeoffs. The current sprite dimensions make a lot of sense if speed is the goal, and 48 or 40 make sense from an ease-of-programming goal. Hard call. Breaking a 48x48 into 2 or 4 or 9 sprites is probably the best option here. Combining smaller sprites into a single image actually sounds like something the heap manager should be good at. Addendum: maybe dividing up into several heaps, one of 16x16, one of 32x32, one of 8x16 etc. Each heap just one size of sprite, perhaps all of them controlled by a master heap manager? It's just one more layer of abstraction. I definitely want to keep the 8x8. The stars in Asteroid Commander are 8x8 4bpp sprites, and really only one pixel in the center has color. Anything more than 32 bytes and I'd have to cut the number of stars in half. Getting rid of 8x8 also means getting rid of 8x16 and 16x8 and 32x8 (which I also use) and 8x32 and 64x8 and 8x64.
  14. I've been a busy boy this summer working on something for the X16 that has gotten really out of hand - a Duke Nukem style 3d first person shooter game engine. Yes, it's possible. This computer is going to have a ton of software available right out of the gate.
  15. A couple years ago someone made a joke video about this project, and it showed a breadboard sticking up out of the case. Now you're telling us: this is actually possible, as a daughter board. It's a little late for design changes here, but if this makes sense to @Michael Steil and @Frank van den Hoef the applications of this little machine expand from teaching programming to also teaching electronics.
  16. With the change to IRQLINE coming in the next version of VERA, it should be easy to incorporate PCM audio snippets into Zsound; well, relatively easily. I am working on something to demonstrate FASTMATH (boy, that escalated quickly. I mean that really got out of hand fast), and if I can just drop in Zsound and have triggered sound effects and background music then great. I'd sure like a link to Furnace and your code in this thread, please.
  17. So, we should poll IRQLINE(8) and then write to IEN?
  18. I've only used the PCM audio so far, so it's nice to see what can be done with the PSG and YM.
  19. Well, you could rewrite them yourself....
  20. Yeah, it's probably better to have a separate website to have the store and official documentation. This fan-run site is really good the way it is, we're sharing code and showing off what the system can do.
  21. Now it just needs the sound. Under 90 seconds though, that's fantastic.
  22. I suppose I should share the code I used to make this. No, it doesn't depend on anything being set to zero, except for the one tile that is used in the top two and bottom two rows on the screen (it's 8 rows by 20 columns). Are you using an actual VERA?
  23. I'm going to try again soon, using @ZeroByte's suggestion of using MACPTR. That will get the number of files down to 3 - a PRG and two SEQs - and perhaps I'll also lower the video frame rate to 12 fps. The sound seems to work, except loading the audio into low RAM and then pushing it to VERA is taking too long and it occasionally runs our of PCM data, hence the pops. Hopefully MACPTR fixes that too.
  24. Another possibility is that the hardware is still slightly slower than the emulator, and perhaps only 12 fps is possible. But then that would show just the left side of the image changing...
  25. Ok, that helps narrow it down, then, it wasn't a problem with the upload. @Wavicle is the BOND folder and BOND.PRG in the root directory of the SD card?
×
×
  • Create New...

Important Information

Please review our Terms of Use