Jump to content

StephenHorn

Members
  • Content Count

    339
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by StephenHorn

  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.
  16. Yeah, I'm a little confused by Lorin's response, because it seems kelli217 is asking for something like this: If there's a particular reason the team doesn't want SCREEN $80 to alter and truncate the display area to a 320x200 resolution, that's cool. Maybe they don't want to track down all the other places where they'd need to reset that for swaps to other screen modes. But adjusting the display area is totally within the VERA's capabilities. What the VERA can't do is adjust the native resolution. In that sense, it's locked to 640x480.
  17. I simply included my entire graphics library. But I should add that my demo is using effectively the entirety of my graphics library - that's initially why I wrote the lib, after all. Or rather, I did not implement functions in the lib on the basis of theoretical wants, I needed these functions first.
  18. You cannot query the current scanline anywhere. The best you can do is use the line IRQ settings from the VERA and, if you want to execute something every line, make absolutely damn sure you keep your execution down to less than the full scanline. It will help to make sure your program sets the ROM bank to 0, so that BASIC is not catching interrupts before the kernal can get to it, otherwise BASIC will spend a surprisingly large quantity of time in what effectively amounts to trampoline code.
  19. I think what's going on is that the ".ifref" is only being considered by the assembler, not the linker, and ".global" doesn't count as a reference. So when you call ca65 with vera.asm, it sees the ".ifref", observes that vera.asm hasn't actually used that procedure anywhere by that point in the file, and then discards it because of your ".ifref". The fix, then, is to remove the ".ifref" and just understand that your clearScreen function will always be included in your lib. Or, if you wanted to control whether clearScreen is included in a build, you can't do it automatically, you'd have to define and then use .ifdef or plain .if comparisons: vera.inc: .define INCLUDE_CLEARSCREEN 1 ... .if INCLUDE_CLEARSCREEN = 1 .global clearScreen .endif vera.asm .include "vera.inc" .if INCLUDE_CLEARSCREEN = 1 .proc clearScreen ... .endproc .endif main.asm .include "vera.inc" ... jsr clearScreen Unfortunately, from a quick look it does not appear that cl65 supports any link-time optimization, such as discarding unused segments of code.
  20. There's also an unofficial Discord server, which has a few active members, some of whom are actively learning, and a couple of others who like me and Matt Heffernan who'll answer questions (though I'm more likely to answer and then go off on a random tangent). https://discord.gg/nS2PqEC
  21. Their website doesn't say (translation from Chinese is "no information"). AliExpress has a seller that seems to be selling them for USD 12 for a pair. businesswire.com claims USD 3.85 each in 10,000 unit quantities. Or if you don't have an appropriate display, you might try one of these: https://www.amazon.com/uoeos-Adapter-Resolution-Computer-Projector/dp/B088699FJV
  22. For the most part, this is all correct. Technically, assembling math.asm yields math.o, which contains an intermediate representation of the ML + used symbols. This might be an academic difference, but I suppose the important thing to note is that it isn't necessarily the final machine language, even with annotations, because the assembler won't necessarily know a bunch of important details, such as the values of external symbols, or even the final location of the code that's been assembled. All of that information is reconciled by the linker, which is given all of the necessary modules (the .o files), in order to figure out all the symbols and organize them into their final locations.
  23. Most likely, the file you're loading is large enough to run all the way from the start address at $0801 into the I/O space at $9F00, and eventually past all the implemented I/O registers and into those invalid ones.
  24. That's exactly it, yes. To declare a symbol that needs to be exported, your use the `.export` statement. And similarly, to declare a symbol that needs to be imported from another module, you use the `.import` statement. ca65 also has the `.global` statement, which I find extremely convenient because it changes meaning based on whether or not a symbol is defined elsewhere within a module. So, for instance, I have a "math.inc" file that contains a bunch of .global statements for my math procedures, like so: .global math_init .global cos_8 .global sin_8 .global mul_8 These procedures are all implemented in "math.asm", so I make sure that math.asm includes that inc file, and I make sure any other source file that needs to use my math procedures also includes math.inc, such as my "splash.asm" that does my little demo splash screen intro. By including math.inc into math.asm, ca65 will see the symbols defined and interpret the globals to mean that those symbols need to be exported. By including math.inc into splash.asm, ca65 will see that the symbols were never defined and interpret the globals to mean that those symbols need to be imported. Then I compile the .asm files into .o files individually with ca65, then link them together into a final executable with cl65: ca65 --cpu 65C02 math.asm -o math.o ca65 --cpu 65C02 splash.asm -o splash.o cl65 --target cx16 math.o math.o -o SPLASH.PRG See also: https://www.cc65.org/doc/ca65-11.html
  25. My solution to this was to generally run all of my logic in the IRQ, starting with screen draws, while the non-interrupt code essentially spins on a tight loop checking on a single memory address. This way I don't have to worry about any of my routines being interrupted. An additional up-side to this is that I effectively have a thread that's not doing anything, and I'm thinking it would be ideal to place my streaming I/O logic into there, essentially spinning through banks and loading files as needed into them. In particular, I really like the VERA's dual access channels and auto-increment settings, and how they make it really easy to write columns and rows of 16-bit tile data.
×
×
  • Create New...

Important Information

Please review our Terms of Use