Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 09/30/22 in Posts

  1. VERA scaling is done for the whole display, not just for a layer or sprite. The current sprite dimensions go up to 64x64, so if you want something bigger, use more sprites. You have 128! And if you want 16x48, you can make the sprite 16x64 and have empty space on the vertical margins. Sprite asset addresses must be aligned to 32-byte blocks, but you can use some of this margin area to have overlapping sprites. A 4bpp 16x48 sprite means you have a total margin of 256 bytes within a 16x64 bitmap. Split that in half, and you can have 128 byte margins between each sprite, which means 8 rows of transparent pixels at 4bpp. The alignment still works because 128 % 32 == 0. So you're only "wasting" half of the VRAM that you're fearing, and it's only 128 bytes per sprite for 4bpp.
    4 points
  2. Hi Everyone, sorry I haven't responded in a bit. I've been letting this gel in my brain a bit. If this were to become part of VERA, the extra sprite height/width bits would need to go in byte 5 of the sprite attribute structure. Making the VERA change to have this feature doesn't look like it will be difficult. For this to have a chance of getting seriously considered however, I need some sort of demo program that sets the new bits and renders 24- and 48-pixel wide/tall sprites in 4 and 8 bpp color. For practical reasons, the best place for this speculative feature development to happen is on Discord. I don't mind discussing the results here, but the development cycle when prototyping new candidate features needs a collaboration environment with lower latency. Ping me over on the Hardware / Video channel and we can discuss what a demo/proof of concept for this should look like. (Standard disclaimer: I haven't promised anybody a pony; I'm not saying this definitely will be a thing, just that we will have to establish the risk is low and it doesn't burn too many of our remaining gates.)
    3 points
  3. honestly, the correct solution is to use multiple sprites for one object. This is how it was done on classic systems. Take this sprite of Samus from Super Metroid: It requires 36px to cover the full width of the character on screen. However, most of that extra 4px of width is blank, with only 10px height for back foot. This can be contained in an 8x16 sprite placed correctly in relation to the main 32x32 sprite. If I were to make a demo/game using artwork of this sort, I would simply make the actor/object control these sprites and define animation frames for each one. In cases where the "extra bits" (like Samus's foot) move around relative to the main sprite, the engine would also need an x/y offsets table. In the Samus animation, the back foot is near the bottom of the sprite for one frame, and closer to the top on the next frame. This "foot sprite" would just be drawn at different relative locations to the main sprite during each frame of the animation cycle. My Sonic demo faced a similar issue on the Sonic sprite, which is 40px tall. I used one 32x32 sprite for the main part of Sonic: and I use a separate sprite for the ears: Interestingly, the ears only require 2 frames of animation (frames 3 and 4 are duplicates of 1 and 2). I didn't bother deleting frames 3 and 4 from the resource, as I've got plenty of VRAM for this simple demo, but the engine never uses those frames. I set up an animation frames table with the VRAM locations of the frames, and the engine cycles through these tables. So the main body's data is the VRAM address equivalents of: 0, 1, 2, 3 and the ear's data is 0, 1, 0, 1. This is also useful for "pingpong" animations where you only need pixel data for 3 frames of a walk/run cycle and you just display them as 0,1,2,1,0,1,2,1... no need to have frame 1 in VRAM twice. This is part of the challenge of programming retro. It's nice when HW just does the work for you, but when it doesn't, that doesn't mean you're stuck. You just have to code a solution. This stuff I've explained here actually saves more memory too, as you only need exactly the pixel data for exactly the parts that go out-of-bounds. The lazy alternative would've been to use a 64x64 sprite, but yes, that would gobble up VRAM needlessly. Hope this makes sense.
    3 points
  4. I suggest to model it that the high resolution 640 width supports 16, 32, 48, 64 resolutions. And the lower resolution 320 supporting 8, 16, 32, 48? lol
    2 points
  5. I will think on this. I think calculating row address with 48 pixels isn't too bad. E.g.: row = y_counter - sprite_y_start; if (mode) begin // 8bpp line_addr = sprite_offset + (row << 6) - (row << 4); // row * 64 - row * 16 end else begin // 4bpp line_addr = sprite_offset + (row << 5) - (row << 3); // row * 32 - row * 8 end Something along those lines should work. I probably need to wake up a bit more and reality check this against the Verilog. Another concern is breaking any existing software that uses 64x64 sprites.
    2 points
  6. Someone with more knowledge can correct me: The sizes are so vera can pull data quickly, as it can mask or shift the address to look up the sprite data. At 48bits the maths become more complicated as it would have to calculate the offset first which would reduce the number of sprites per line.
    2 points
  7. Hi, I'm Michael/Mike Losh AKA Sohl. I'm interested in this project and hope to write some code for X16 sooner or later! (Although to be honest my current hobby project is for Atari 2600... at least it's 6502-family, right?) I got started with Commodore in 1983/84 when my parents upgraded from a CoCo 1 to a C64. I was very into BASIC programming and learning as much as possible about computers and digital electronics. It must have worked because I'm a lead software engineer in a major auto company R&D department now. Just before going to college in `85 my dad found some C64s, disk drive and monitors being sold as factory refurbished, if I remember correctly. So I got my own C64 setup to take to college. I later got a REU and geos, but by that point, I was starting to use the college VAX to type and laser-print my papers and whatnot. By graduation, IBM PCs and clones were pretty much taking over everywhere. My biggest regret with the C64 is not getting a decent assembler for it and learning assembler coding better back then. I just dabbled with hand-assembling a few short routines or using a really crude monitor and not getting very far with it. But with a good assembler in a cart/disk (or maybe even Forth!), I think I would have done even more with that C64. But I kept that college C64 setup. I get it out once in a while to dabble again and have some fun. I'd like to at least get a SD2IEC device to make using a lot easier. But I'd also like to get a X16 now after seeing the really cool 8-Bit Guy videos and supporting ones from Perifractic, Adrian Black, TexElec, Matt Heffernan, and others! Best wishes to everyone and hoping for you all great success with the Commander X-16! -- Mike
    2 points
  8. Late November is when I officially released Zsound. That was at the ultimate nadir of Commander X16's community enthusiasm level. Things had stalled out. R38 was a year and a half old. It had serious broken things about it. The community was having to build everything for R38 and for the potential R39 that never would seem to come to pass. Then in March, @Michael Steil started merging pull requests to the repo, and we suddenly shot up to version r41 in a matter of mere weeks. Furthermore, @Wavicle got his Breadboard16 up and running and was very involved with the community members who wanted to see their projects run on real hardware. This led to the discovery and correction of a few bugs in the VERA code, read/write timing fixes for the YM2151 (quite a finnicky chip to deal with on the bus!) and most importantly of all - spearheading the efforts to resolve the long standing problems of PS/2 and SD card stability at 4MHz / 8MHz. For once, we started making real headway! You can see how much stuff I started working on in the spring. This new synergy led to renewed excitement and progress on the parts of Kevin and Dave, and now we really are able to feel excited - like there really will be a Commander X16 on people's desktops in the not-too-distant future! Many others have been making amazing contributions to these efforts over the summer, especially @Stefan and @Jeffrey who worked tirelessly with Wavicle on getting the new PS/2 functionality ironed out in the Kernal and in the ATTiny SMC code. The code in September was me helping David get Zsound working in PETSCII Robots for a great upgrade to the X16 version's audio aspect, and then on to my latest project, Calliope. I would probably not have ended up making Calliope were it not for the reinvigoration that's taken place this year. Thanks, everyone!
    2 points
  9. Darn gnomes, just stick to socks! I agree 100%, accessing it via serial on a modern PC is fine, but I want the full retro experience, and the uTerm is about as close as I'm going to get. I also like the fact he designed a stand-alone uTerm, the uTerm-S (https://hackaday.io/project/176716-uterm-s) You could use it as a dumb-terminal for other retro CP/M builds. He also has one last version, the uTerm2-S (https://hackaday.io/project/181583-uterm2-s-a-multi-emulation-color-rs232-terminal). I do like options! Edit: This is what I am thinking about cramming it all into this once I'm done. https://amzn.to/3V32qyM Move all the lights and buttons to the front panel, along with the keyboard connection and a proper power switch. Power input, serial, and VGA out the back.
    1 point
  10. It's a little known fact that the same gnomes that steal socks from the sock drawer sometimes steal small two-lead electronic parts just to make mischief. Especially looking forward to the U-term build, since so many minimalist retro Z80 boards I have seen around are accessed by plugging a USB-TTLserial cable into a SIL pin header, and the U-term seems like such a promising replacement for that ...that is, given that part of the appeal of tinkering around in CP/M on a retro board is to get away from the ever-present-distractions of the Internet.
    1 point
  11. My most recent retro collection purchase was the beat-em-up collection from Capcom. It's fun to pop that in with the kids and start trashing bozos. My most recent "HD remake" title was Secret of Mana II. It was interesting how they made it play a lot more like the action-RPG titles of today (like Xenoblade)
    1 point
  12. The existence of space in the register mapping doesn't automatically mean there are the on-chip resources to populate those resources ... but on the other hand the design seems to be I/O pin constrained, so here's hoping. A similar saving to the 48x48 square sprites could be achieved with options of 32x64 and 64x32 rectangular sprites. 48x48 is 2,304 pixels, and 32x64 is 2,048 pixels.
    1 point
  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.
    1 point
  14. My $0.02's worth - I understand about the intermediate 48px size, but I really can't honestly say one of the other sizes that should be discarded in favor of 48px. 8 and 16 - no way. Those are tile-sized aspects and there are far too many uses for such, and furthermore, there are far too many "little" things that would become bloated in VRAM if 8x8 were dropped as a sprite size, especially. I've already done many programs where I used free slots in the tilemap as sprite slots or else used letters/numbers from the tilemap as digits, e.g. the score counter in Flappy Bird.... 64 - useful for bosses / making panels for things like radar / HUD overlays / popup dialogs, etc. (for instance, in games like StarFox where a character's portrait pops up along with their dialog/voice clip, having a 64x64 sprite for this is perfect) 32 is probably the only one I'd say is "up for discussion" as an atomic size that could be considered expendable in favor of 48. Both are "middle" sizes, and maybe 40 or 48 offer more utility than 32, but the extremes are both quite valuable and dare I say, indispensable?
    1 point
  15. Did you have a chance to look more into this afrer waking up? If the calculations aren’t too complicated, I think 48 pixels sprites is a good suggestion. Breaking existing software is not a problem as I see it. We all know we write software for a prototype.
    1 point
  16. FWIW, using multiple sprites is pretty low overhead in the way I did it for Sonic Demo: .struct SPRITEREG addr .word 1 xpos .word 1 ypos .word 1 orient .byte 1 attr .byte 1 .endstruct sonic_spriteregs: ; shadow registers for Sonic sprites (initial values) ;sonic's body .byte $10, $08, <sonic_x, >sonic_x, <(sonic_y+8), >(sonic_y+8), $0c, $a0 ;sonic's ears .byte $00, $08, <sonic_x, >sonic_x, <sonic_y, >sonic_y, $0c, $20 sonic_frames: ; VRAM locations for frames of Sonic's animation (SPREG format) .word $0810, $0820, $0830, $0840 .word $0800, $0804, $0800 $0804 animate_sonic: lda sonicframe inc and #3 ; sonic frame = 0..3 sta sonicframe asl ; use frame as X index (*2 because data stored as words, not separate HiByte / LoByte tables) tax lda sonic_frames,x ; sonic body address LoByte sta sonic_spriteregs + SPRITEREG::addr lda sonic_frames + 8,x ; sonic ears address LoByte sta sonic_spriteregs + 8 + SPRITEREG::addr lda sonic_frames+1,x ; sonic body address HiByte sta sonic_spriteregs + 1 + SPRITEREG::addr lda sonic_frames+9,x ; sonic ears address HiByte sta sonic_spriteregs + 9 + SPRITEREG::addr lda dirty ora #DIRTY_SPRITE sta dirty ; flag sprite address as dirty so VBLANK IRQ will update VERA rts A similar approach in C would use something akin to this: uint16_t sonic_frames[2][4] = { {0x810, 0x820, 0x830, 0x840} , {0x800, 0x804, 0x800, 0x804} }; Again, not saying "do this, n00b" - just sharing what I've done in case anyone else finds it useful or informative.
    1 point
  17. I think the main issue at hand is that the engine uses a heap management approach to allocating VRAM which comes with benefits and drawbacks, as with all design decisions. That's what makes this an engaging hobby.
    1 point
  18. I can see where you are coming from, however: I use that size and it solved a VRAM shortage in Invaderz. I could squeeze just about everything in by using 8x8 for the phasers etc. Having to use 16x16 instead would be too much... Ok, maybe I could make it by analysing carefully again, but 8x8 has it's advantages. Especially if using 320x240 resolution. You would never use 64x64 there I think... I would argue to drop 64x64 in favor of 48x48... but then maybe someone else already has a reasonable use case for that? Or drop 8x8 if in 640x400 resolution? Or use one of the unused bits in byte 1 to switch to a different size scheme?
    1 point
  19. Tragic news, he wasn't much older than I am. Hoping his family can find as much comfort as possible in a trying time. I interacted with him a bit about a year ago, seemed like a good dude. Just read his obit, it states he was "collaborating with other programmers with projects such as the Penske Robots Game for the Commodore 360." Penske Robots? And a search reveals the Commodore 360 is a boat. I think he'd get a kick out of that. Mark
    1 point
  20. Well now you can peruse my code for the inverse functions you need and see how to convert them to using degrees if you need that. The angle mode (degrees or radians) is controlled by the strings "DEG" or "RAD" in A$ The inverse functions are in line numbers 5150 to 5172
    1 point
  21. I had taken the inner parens out thinking the rule says do power before multiply before addition... Going to go check - watch this space.
    1 point
  22. I seen that video the other day and thought it was a really cool idea. I agree that there are ways you could expand on it if you really wanted to do so. Adding I/O and storage, both (RAM and ROM?) on the cart being the most obvious. However one of the comments on the video expressed one thing I was thinking the entire time, for the FamiCom, you could use the FamiCom Disk System to load and store information as well. In tandem with a cart you could probably create a pretty cool little era appropriate "Family Computer". Of course, I'm not 100% sure the FamiCom can use the FDS and a cart at the same time, but if it can, that seems like a great way to max out a potential design. Either way, I really like that video.
    1 point
  23. A big advantage of doing it all in a cartridge is you have the natural location for all of the I/O parts right there on the cartridge board, on the opposite edge from the cartridge port. AFAIU, on NES powerup/reset, you'd have: $0000-$07FF: NESRAM $2000-$3FFF: PPU I/O ports $4000-$5FFF: APU/Controller I/O ports $6000-$7FFF: Work RAM if installed on CART $8000-$FFF9: Cartridge ROM $FFFA-$FFFF: NMI/IRQ/RESET vectors If you have a clever enough banking scheme, you only need one RAM and one FlashROM chip. But "clever" here means setting things up so you can get from the start-up state to the normal memory map with the smallest possible boot-up code. Suppose it's 128KB each: The $8000-$FFFF decode circuitry splits between the 16KB HighRAM window in $8000-$BFFF and the 16KB ROM window in $C000-$FFFF The bottom half of RAMBank 0 appears in the WRAM space in $6000-$7FFF The banking latch has its reset pin hooked up, so on powerup/reset, the banking latch has is in its $00 state The banking latch is: bit0-bit2 = ROM A14-A16; bit3-bit5 = RAM A14-A16, bit7=RAM/ROM, bit In $00 state, ROMBank 0 is selected in $8000-$BFFF, with Bit7 of the latch selecting between ROM and RAM /OE in that space In RAMBank $00 state, RAMBank 0 is selected for $8000-$BFFF With RAM selected in $8000-$BFFF whether or not it's output is enabled, you can have the transition routine at the top of ROMBank 0 which copies itself to the top of RAMBank 0, toggles out the ROM, then calls code in the normal ROM window. Only JMP COLDSTART / ... / COLDSTART: ... / ENDROM is assembled for the ROM appearing at $8000, everything else is assembled for ROM appearing at $C000. You have eight ROM segments and eight HighRAM segments, 2KB NES RAM and 8KB "LowRAM" that also appears in $8000-$9FFF when RAMBank 0 is selected. While you can mask out RAM when setting ROM (and visa versa): "STA CALLROM : LDA BANK : AND #%1111100 : ORA CALLROM", you can also design code that allocates a ROM bank together with its own dedicated RAM bank, so, eg, "SYSCALL" executing in NESRam or WRAM is: "LDA THISBANK : PHA : LDA #SYSBANKS : STA THISBANK : STA BANK : JSR + : PLA : STA THISBANK : STA BANK : RTS : + JMP DOSYS,X".
    1 point
  24. When you want a real thing, then you want a real thing, and nothing else will substitute. ) But if you want same outer look and feel, you can go for replicas. I did not check if there are many Commodore mouse replicas out there, but, for example, Amiga 500 Mini has good looking replica of original Amiga mouse (not sure if you can buy one separately).
    1 point
  25. Hello again, everyone. As we've had a chance to test this change out on more software, I think that I underestimated the impact of the "trap" above. @ZeroByte suggested moving bit 8 of the SCANLINE from IEN[7] to IEN[6] which will re-enable read-modify-write operations to IEN. (E.g. you can enable a single interrupt by doing IEN |= 0x20 without knowing what bit 8 of the line IRQ should be). Let me know of any problem/issue you see with this modification to the new (and as yet unsupported in the emulator) scanline feature.
    1 point
  26. So, we should poll IRQLINE(8) and then write to IEN?
    1 point
  27. We don't actually know, yet. The assumption at the time was that he's going to launch some sort of crowdfunding campaign, but he could choose to just open up orders on his web site, https://www.the8bitguy.com/ I'm also sure that you'll get plenty notice when the time comes. There will be an announcement on his YouTube channel, his Facebook presence, and here (of course.)
    1 point
  28. I was looking on the interwebz(tm) for an 8x8 4bpp font to use in a project, and came across this page. https://www.8bitcoding.com/p/tiles-in-assembly-i-basics.html It's one of the better explanations I've seen for anyone new to this. Unfortunately, the VRAM addresses in the explanation and accompanying code are out-of-date for R41, but if you can just imagine the MAPBASE being $1:B000 and the TILEBASE of the default font being $1:F000 instead of the values used in the tutorial, it should be most helpful to anyone wanting to get their feet wet in VERA programming.
    1 point
  29. I'm officially losing my marbles... I could have sworn I had several 100nF capacitors on hand.... got well into building the uTerm today, only to discover I have ... two. I need six. I was hoping to get it up and running today. Oh well, now I guess I have to wait a bit longer.
    0 points
  30. Hello, everyone. I have a bit of sad news to relay. https://www.mcdougalfuneralhomes.com/obituaries/scott-robison Scott Robison passed away suddenly last month, on August 16. (We just found out tonight - apparently, Scott's wife didn't have the passcode to his phone.) Scott was an invaluable contributor to the Retro community. He made some major contributions to Attack Of The PETSCII robots, was a frequent poster on the forum, and was a fun guy to talk to. We are all going to miss him.
    0 points
×
×
  • Create New...

Important Information

Please review our Terms of Use