Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


StephenHorn last won the day on November 4 2020

StephenHorn had the most liked content!

Community Reputation

292 Excellent


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. My guess is that Frank made a mistake and accidentally made those repos public without meaning to, only fixing the error upon seeing they were forked. In addition, I would venture to guess that those projects are all stripped-down, minimalist implementations of the X16 features that Frank would have needed to develop the VERA and write test software that could be easily created in his minimalist environment and run directly on the prototype boards when and as they arrived. It's unfortunate to me that these are being publicized, doubtlessly against the wishes of the rest of the team, who do not want to see the X16 cloned or FPGA'd until they've had a first bite at sales and production. And if that's the case, then this is the kind of leak that could be quite damaging, depending on what, in all, is included in all the leaked materials.
  2. Additionally, the X16 team was targeting 8MHz because that was the fastest they'd been able to clock the chip on the board. So - just from a technical standpoint - it will probably go about as fast as they ship it.
  3. No, the VERA cannot just do any signal that was ever put on a VGA cable. No, it is not just a matter of memory. Want to change the resolution? That means changing the pixel clock speed. It also means implementing additional smarts in the video processing to deal with rasterizing lines of multiple widths (and not at a convenient power of 2, either). This likely means having to put the VERA onto a more expensive FPGA to support the additional sophistication. Even if it were just a matter of memory, the VERA's memory is built in with the same FPGA used to implement the video processing. This kind of memory is not cheap. The cheap kind of memory would mean redesigning the entire daughter board for the FPGA chip to use external memory, and this still represents increasing the cost of the VERA due to the added components needed to deal with the external memory source.
  4. There is no news to share, and Michael Steil has been very busy.
  5. Well, the nice part about the emulator's design is that it's really easy to move around memory-mapped I/O. There's no reason someone couldn't work on cycle-accurate VIA emulation for the current addresses, and then move it to the proper addresses later.
  6. As far as anyone seems to know, Michael Steil is still part of the team, but may simply be busy with their day job and simply hasn't been able to keep up with the Github. This comes, in part, from Mike Allison, who responded to a ping about this on the unofficial Discord a few days ago. So... "patience, grasshopper". Though I'll say I sure would love to help catch up the emulator on pull requests and features, and maybe catch up on some of the bugs from the actual emulator (and not the ROM). Of course, anyone can fork the emulator in GitHub, and the magic of Git is that (once you've learned how to do it, anyways), you can pull changelists from almost anywhere. Just keep in mind that there is only one official emulator repo, and it is the only repo that has been granted permission to host the X16's modified ROM files that are necessary for the emulator to do anything useful.
  7. The only exception that might spring to mind is clothing, where "retro" seems to mean "new but out-of-fashion by about 20 years", and "vintage" seems to mean "new but out-of-fashion by about 80 years".
  8. The team have been fairly sparse in detailing the hardware that has been actively in flux, or with details that are completely irrelevant to programming the system, with the exception of the VERA. They've been highly forthcoming with the VERA, with all the information one could ever need to program for it. The only reason the VERA emulation isn't a reference-quality, 1-for-1 representation of the final hardware is because it is quite weighty to emulate its behavior at a pixel-perfect level, plus a small handful of bugs in certain unusual edge cases found their way in during the optimization process. The VERA emulation should still be very, very good, and to improve it further would require either rolling back some of the more important optimizations that were made, or else a total brain-dump from Frank (or the equivalent of that), or else having a final production VERA daughterboard so that the behavior can be studied in-depth.
  9. Ah, I was wondering if you were referring to single-layer parallax effects. The VERA actually supports up to two background layers, so it's possible to achieve a great deal of parallax with careful programming and technical design.
  10. I play Genshin Impact, and wish they'd make more animated episodes of Dragon Ball Super. Those are my big anime-related things these days, though I'm re-starting my Japanese studies, hopefully a bit more earnestly than before, and maybe I'll branch out into manga to practice and maintain my reading skills. Although, somehow I consistently find time to rewatch various Ghost in the Shell-related material. I have a hankering to go back and rewatch Gasaraki, as well. I'd like to find new mecha-based material, but I've really lost the appeal for Gundam that I had as a youth. I want my mecha to be heavy, metal, and industrial, and to me the mecha designs in Gundam have gotten to where they all look like they're impractical as anything but plastic toys.
  11. I swear I'm trying to avoid becoming Retro Game Mechanics Explained personal marketing rep, but this is what I was referring to... In particular, note time index 6:25 (software polling), 7:48 (NES wire compatibility), and 8:36 (SNES auto-joypad read). As for games that behave badly, I guess I'd need more specific citations than "you will still find games that work 100%, and others that have major issues". But since the controllers returned low 1s, and low voltage was the shift register's output once it ran out of bits, NES controllers would show A, X, L, and R as being "pressed", so unless games checked the controller signatures, they could potentially interpret the controller data incorrectly for NES controllers.
  12. Well, they have the kernal code, and they're making the modifications necessary. Also, if I remember correctly, SNES games were not required to poll the shift registers, the console could be set to do that for them on a periodic basis. But NES games might've had to do their own polling.
  13. Tiles are like text. Actually, strike that; text is just another type of tile. You can point the VERA's graphics layers to a blob of memory where you've put a bunch of graphics together. It treats the first graphics thing at that location as "tile 0", then expects "tile 1" to follow right after that, then "tile 2", "tile 3", and so on. You don't have to fill all the memory, which is good because most graphics layer settings can use up to 1024 tiles, and that quickly turns into a lot of memory! As well as pointing the VERA layer to a blob of tiles, you separately point it to a blob of tile indices to draw. For the most part, this is just a long list of all the tiles to display, starting from the top-left corner, then going left-to-right, for each row top-to-bottom. This is an excellent way to represent repeating patterns of pixels, such as the playfield of a game where the same image is expected to be stamped over and over into different places. Instead of trying to cram a bunch of sprites into a row and dealing with their positions and stuff, just use tiles and a tilemap. This is also a great way to represent a text console, which is why this is exactly how the VERA does that. The only trick is that since text is generally 1bpp, and there's only a small handful of symbols to define, it changes what data is expects in blob of tile indices, so that it can squeeze a little bit of color data into there. But otherwise, it's exactly the same thing.
  14. Yeah, that's been pointed out to me on the unofficial Discord group, and I'd wondered if I'd end up describing something like the 68000. Goes to show that my actual experience and knowledge of programming for older hardware is pretty slim. But then, my only other experiences with assembly programming were a tiny bit of trying to learn x86 assembly and VGA programming from the Michael Abrash Black Book a few years back, and before that was just some MIPS assembly for a computer architecture class at uni back in either '02 or '03. 65C02 has been fun to learn. Just wishing to ease the edges where it ends up feeling clumsy. After all, if I wanted to adc stack,4, that's at least a tsx; adc $0104, x; which is going to cost 6 cycles when it really should cost 3, and trashes the x register besides. If I need to preserve x, that's another 7 cycles (phx, and later plx to restore it), and needing to account for the x register being pushed onto the stack, so the stack offset ends up feeling counterintuitive.
  15. I want to contribute to this thread, but my idea of a personal "dream computer" is also very much "Retro++" and not constrained to existing tech. For instance, as much as I like programming for the 65C02, and would want to use the 65816 as a starting point, I would also want to expand the native word size to 16 bits and the native address size to 32 bits. Reason being to expand the instruction set such that all the registers are general-purpose and can be used for indexing, as well as adding a stack-relative addressing mode to ops. It just needs more than 8 bits for the opcodes by that point. Other niceties, though I guess these could be seen as memory-mapped hardware peripherals, would be a 16x16=32 bit hardware multiplier/math co-processor, and a DMA controller. On the video side, I'd be very much inspired by a mix between the VERA and the SNES' PPU. Ditto the audio, between the VERA and YM chip, but with a dedicated sound CPU acting on its own memory. And, granted, this isn't so much seventies/eighties as very-late eighties, definitely fist-bumping the nineties.
  • Create New...

Important Information

Please review our Terms of Use