Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by StinkerB06

  1. Do you not know how to code your own double-precision min/max functions?
  2. INA and DEA are alternative mnemonics for "INC A" and "DEC A", to be consistent with the X and Y equivalents.
  3. Yeah, especially with LDX, STX, LDY, and STY. You'd normally use the accumulator when doing memory transfers (i.e. with LDA & STA'ing), but you can indeed do the same with the X and Y, just with less addressing modes. For example, the standard 6502 has increment/decrement instructions that can only be performed on index registers or directly on memory contents (i.e. RMW), but not the accumulator. If I want to do a "dest=src+1", then I'd use an LDX/INX/STX triplet. Changing the X's to Y's will work just fine as well. However, changing them to A's won't work (needs ADC with relevant CLC/SEC), but thankfully, the 65C02 in the CX16 added INA and DEA, so I can be able to use the accumulator for this operation.
  4. I know. I'm pretty sure that (by contrast) the SAA1099 would run at the CPU's 8 MHz frequency, as that's what the datasheet suggests.
  5. Actually, it's necessary to have a 10-bit Y value, at least for sprites that are 64 pixels tall. The sprite would be pushed into the bottom of the screen at Y position 480, but at the same time, would also represent a position of 480 - 512 = -32. This would not be suitable if you want to push the whole sprite off the top or bottom edge of the screen, and at 32 pixels cut off, the sprite would appear on the opposite side when you probably don't want it to.
  6. Oh, I didn't know the VERA actually exposes the NTSC color clock to the system board! But the main gripe for me is, how would an 8 MHz CPU communicate with a 3.58 MHz peripheral? I'm pretty sure the exact wait-cycle counts would slightly vary depending on the phase of both clocks.
  7. I think 4 MHz would work better on the hardware, since it can be easily divided from the CPU's 8 MHz speed.
  8. I'm pretty sure those 4 waveforms are for the YM's low-frequency oscillator (LFO) that modulates either amplitude or phase.
  9. @StephenHorn I don't think you should use a character that's reflected on both the left and right sides. People won't know if the VERA stores the left-most pixel in the LSB or MSB, since the "X" in the PETSCII font is stored the same way in memory regardless of which order. The VERA Programmer's Reference doesn't mention this, but I'd want it to be mentioned (particularly for people who screwed up and accidentally reversed the bits in their graphics).
  10. And if the sequence length is very short, it actually produces an audible tone, hence the "periodic" noise mode found in some sound chips.
  11. You can't just place all 128 sprites everywhere you want. The VERA has a limited amount of time per scanline to read from the sprite attributes and place them in the buffer. This is known as the "sprite tearing" effect, and exists in older game consoles as well. Those consoles mainly are limited in number of sprites per line, but the VERA sprites instead have a certain number of "work units" that they cost. If the sprite renderer caps out at ~801 work units on a given line, then nothing else will be rendered, hence the missing sprites there.
  12. Actually, it's possible to get some decent-sounding chiptune music out of the VERA PSG alone. You get 16 channels each with 67 waveforms (64 selectable pulse-wave duties, sawtooth, triangle and noise), 64 logarithmic-scaled volume levels, and simple stereo panning. This sounds like the C64 SID chip but in an alternate universe where it was designed differently. Here's a demo of what you could do with just 3 of the 16 channels (which was made shortly after the PSG was implemented in the emulator).
  13. VERA + YM2151 + SAA1099 is perhaps what the final design of the X16P is going to have. I have a feeling this sound hardware in question is way too overkill for an 8-bit system, by essentially having 16+1+8+6=31 channels. This kind of reminds me of the 16-bit C256 Foenix with its cluster of sound chips (FPGA SID + SN76489 + YM2612 + YM2151 + OPL3 + 192KHz 24-bit stereo DAC + 3KHz piezo beeper). Even the ZX Spectrum Next has a more-plausible sound hardware, with three AY-3-8912 chips for a total of 9 channels (or 10 if the ZXS 1-bit beeper is included). One of my suggestions for the X16 is to remove the SAA chip entirely, as the VERA PSG makes it redundant, which brings the channel count down to 25. Having a native tracker program work with 31 channels seems pretty hard, meanwhile it's far easier for the C64's 3.
  14. Yeah, it's because 6502 instructions are faster than equivalent GB CPU instructions. A standard 6502 takes 2 to 7 cycles, whereas the GB takes multiples of 4 cycles (known as M-cycles) into account. Also note that the GB has neither a Z80 nor an Intel 8080, instead it has a SHARP LR35902. Its register set is identical to the 8080 except for the status register. Some of its bits were lost to make it cheaper to produce, and requires ported code to be reworked for the lack of a negative or overflow flag.
  15. GBC: 4K of fixed RAM 28K of banked RAM (7 banks of 4K each) 127 bytes of "fast" RAM present near the end of the memory map (similar to 6502's zero-page registers) 16K of banked VRAM (dual 8K banks) directly exposed to CPU, character data and tilemaps have fixed locations CPU has 16-bit stack pointer, meaning the stack can grow as large as the entire memory map CPU has slower execution speeds than CX16, when running in double-speed 8MHz mode CX16: 40K of fixed RAM (minus 258 bytes used for bank latches and I/O page) Up to 2M of banked RAM (each bank 8K) 128K of VRAM separate from CPU (not quite since VERA 0.9 changed to store PSG/palette/sprites near the end of VRAM), character data and tilemaps have remappable locations Also has 4K of PCM sample buffer memory and 114 bytes of NVRAM in the RTC chip. CPU only has 8-bit stack pointer, meaning you only have 256 bytes to work with, and it may be problematic for complex code that relies on deeply-nested subroutine calls. CPU has faster execution speeds at 8MHz Maybe some GBC-to-X16 conversions could happen, considering the latter system is technically-superior in a lot of areas than the former.
  16. Is it possible to manually (not from software) re-program the VERA's on-board FPGA to perform different kinds of tasks? This can perhaps allow the video modes to be changed, or even allow a virtual 2nd CPU to be created if there's enough spare logic blocks. I might as well replace the default PSG/PCM audio with my own Amiga-like sampler, to be paired with the otherwise hard-coded YM2151 and SAA1099 audio. I know users will be able to re-program the X16's flash ROM with their own software, to be paired with their custom VHDL/Verilog code if only @Frank van den Hoef makes this possible.
  17. Can you give me all the steps on how you load this in the emulator R37?
  18. @Frank van den Hoef What would happen if a DC START register is greater or equal to its matching STOP register? Will it flip the image or not render it at all? Flipping would make the VERA's logic design a bit more complicated, so I assume it's the latter. Does a sprite with a lower Z-depth value and lower position in memory actually render behind a sprite with higher Z-depth and position, or will it display garbage like the GBA? (E.g. sprite 0 has Z=2, sprite 1 has Z=3) Note that lower positions mean higher-priority sprites if their Z-depth is the same. Will the PSG's noise wave use a predefined sequence? The emulator's PSG code doesn't seem to implement one, and just takes a random number from 0 to 63. Maybe it uses a true-random supply from somewhere in your FPGA?
  19. You can set both HSCALE and VSCALE to 64 to get a nice little 320×240 screen resolution. Those values are 128 by default to make it 640×480. EDIT: Here's the formulas: HRES = 640 × (HSCALE ÷ 128) VRES = 480 × (VSCALE ÷ 128)
  20. Doesn't turning off $A000 to $BFFF result in a "257th" high-RAM bank though? I don't think it's necessary as there's already plenty of high-RAM, therefore we can have a bit to disable $E000 onwards. This is useful if you want to override the kernal's IRQ/NMI handlers with your own, however it'd be quite problematic with the reset vector. I think you'll need it to jump to a low-RAM location with your code that resets both zero-page latches, and does a BRK to soft-reset the machine back to its READY prompt.
  21. I believe multi-channel samples would be possible on the CX16, using the VERA's PCM channel. However, the VERA uses a 4KiB buffer for sample storage (similar to modern sound cards), instead of direct register-writes that the Genesis' YM2612 uses. The method from back when the X16 had 2×AY in it used the chips' GPIO pins to drive two 8-bit DAC channels (I'm not quite sure if it was true, but I watched The 8-Bit Guy's video and he showed the AY chips). But the VERA PCM adds popping at AFLOW intervals as the new samples are computed by the CPU. Perhaps one could work around this by setting a VERA PSG channel to its max frequency ($FFFF) and its waveform to 50% duty square ($3F). The square wave is pitched above our max-frequency cap of 20KHz, so we hear the low and high phases "blend" together to form an amplitude above zero-level. This allows 6-bit logarithmic-scaled PCM to be pushed by manipulating the channel's volume register. There are perhaps other PCM exploits for the YM2151 and SAA1099 (which are in the X16), but I'll not look into them.
  22. I have some optimizations: You don't need CLC and CMP. LDA already sets the Z flag if the byte is zero. You can have the color byte stored in the Y register, using an STY instead of an LDA/STA pair. The JMP can be replaced with a BRA to save one byte. Also note that in 6502 ASM, parentheses are used for indirect addressing. The "LDA Label,X" instruction uses the "absolute,X" mode, and the two store instructions use the "absolute" mode to affect $9F23/$9F24 (VERA data port 0/1).
  • Create New...

Important Information

Please review our Terms of Use