bsnes-libretro/nall/array.hpp
Tim Allen ffd150735b Update to v101r07 release.
byuu says:

Added VDP sprite rendering. Can't get any games far enough in to see if
it actually works. So in other words, it doesn't work at all and is 100%
completely broken.

Also added 68K exceptions and interrupts. So far only the VDP interrupt
is present. It definitely seems to be firing in commercial games, so
that's promising. But the implementation is almost certainly completely
wrong. There is fuck all of nothing for documentation on how interrupts
actually work. I had to find out the interrupt vector numbers from
reading the comments from the Sonic the Hedgehog disassembly. I have
literally no fucking clue what I0-I2 (3-bit integer priority value in
the status register) is supposed to do. I know that Vblank=6, Hblank=4,
Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm
supposed to block interrupts when I is >, >=, <, <= to the interrupt
level. I don't know what level CPU exceptions are supposed to be.

Also implemented VDP regular DMA. No idea if it works correctly since
none of the commercial games run far enough to use it. So again, it's
horribly broken for usre.

Also improved VDP fill mode. But I don't understand how it takes
byte-lengths when the bus is 16-bit. The transfer times indicate it's
actually transferring at the same speed as the 68K->VDP copy, strongly
suggesting it's actually doing 16-bit transfers at a time. In which case,
what happens when you set an odd transfer length?

Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's
all kinds of weird shit going on when you target VSRAM, CRAM with VDP
fill/copy modes, but whatever. Get to that later.

Also implemented a very lazy preliminary wait mechanism to to stall out
a processor while another processor exerts control over the bus. This
one's going to be a major work in progress. For one, it totally breaks
the model I use to do save states with libco. For another, I don't
know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could
actually keep running if it was executing out of RAM when it started
the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip
stall.) That'll greatly change how I handle the waiting.

Also, the OSS driver now supports Audio::Latency. Sound should be
even lower latency now. On FreeBSD when set to 0ms, it's absolutely
incredible. Cannot detect latency whatsoever. The Mario jump sound seems
to happen at the very instant I hear my cherry blue keyswitch activate.
2016-08-15 14:56:38 +10:00

54 lines
978 B
C++

#pragma once
#include <nall/range.hpp>
namespace nall {
template<typename T, uint Capacity>
struct array {
auto capacity() const -> uint { return Capacity; }
auto size() const -> uint { return _size; }
auto reset() -> void {
for(uint n : range(_size)) _pool.t[n].~T();
_size = 0;
}
auto operator[](uint index) -> T& {
return _pool.t[index];
}
auto operator[](uint index) const -> const T& {
return _pool.t[index];
}
auto append() -> T& {
new(_pool.t + _size) T;
return _pool.t[_size++];
}
auto append(const T& value) -> void {
new(_pool.t + _size++) T(value);
}
auto append(T&& value) -> void {
new(_pool.t + _size++) T(move(value));
}
auto begin() { return &_pool.t[0]; }
auto end() { return &_pool.t[_size]; }
auto begin() const { return &_pool.t[0]; }
auto end() const { return &_pool.t[_size]; }
private:
union U {
U() {}
~U() {}
T t[Capacity];
} _pool;
uint _size = 0;
};
}