Jump to content


Popular Content

Showing content with the highest reputation since 06/29/21 in Posts

  1. 29 points
    Hello Everyone! I received the parts for the third Prototype on Tuesday evening and spent a good chunk of that night and a bit of yesterday morning getting it worked out. I had to get my code moved over to the ATTiny861 before the board would even power on. This turned out to be pretty easy now that the I2C header will also work as an Atmel ISP programming header. Of course, I'm pretty much going to make a mistake somewhere on a board of this size, and this time is no exception! Fortunately, they were easy to spot and the actual logic is working as it should. Or at least as I designed it. Two of my mistakes are visible in the pic, see if you can find them. One is just cosmetic, and the other is a bodge job on a chip which I will admit, is next to impossible to see in this photo. The less easy to spot issue is that I used the stand-by power to power the microcontroller, but I put pull-up resistors on the I2C lines (and SPI programming lines) to the system voltage and not the VSB. I did this on purpose as I didn't want to pull these lines high while programming the microcontroller, but need to pull them high for I2C. The net result is that leakage was happening backwards through these resistors when the data/clock lines were high. Enough to power on the LED on the motherboard with no other ICs plugged in. Took me a minute to figure that one out, but I think I will just throw a few more diodes in to protect this from happening. I suspect issues like this are sometimes why you may see a lone crusty resistor on an old PCB after years of use. Easy fixes all around! One last issue is that the parts sourcing scourge which has been affecting the world is also affecting TexElec! Yes, we can't get parts in for some of our products, and as time goes on, it seems like it may get worse before it gets better. And now, it has hit the X16 project! I am unable to get the FPGA and the DAC for the new Version 4 VERA, so we're still running V3. The main difference has to do with hardware deadlocks on the SD card, so functionally, it's fine. However, the lead times are a bit concerning. I'm looking into some other suppliers now, and hoping for the best. For now, here's a pic of the new machine, with no wires all over it! Take care! -Kevin
  2. 11 points
    Paging @Kevin Williams! Heya! Sorry to be that guy, but not all of us use FB for whatever reason. I heard the 3rd prototype board has been announced over on the FB discussion board. Any chance the passionate and devoted fan base here can get some info on it as well? I've only heard about it second hand but would love to get the deets from the source!
  3. 10 points
    Hey Everyone, Sorry for the delay on an update. It's been a hectic year once again and there never seem to be enough hours in the day. I'm not a huge FB fan either, but the reality is with our business, it's pretty key I keep on top of FB & the even more dreaded Twitter. I meant to post the same day, but for the brief second I tried, the site wouldn't let me login, and I just forgot to come back. However, I just posted a video of Attack of the Petscii robots on the X16. It's still the second proto, but I have it wired as the third board is designed. I did this for testing the new design before running it of-course, and David just wanted to make sure the game was still running ok. I am catching up on the thread and I will answer some questions here in a second. For the moment, the PCBs are 100% complete and should be shipping tomorrow. This means probably Friday or Monday they will be here and I should have all of the parts in-hand too. We're still not done with the Kernal, so this is not the end of the story by any stretch, but it should be pretty close to the end of the HW specs. Attack of the PETSCII Robots on the Commander X16 Prototype 3 - YouTube Thanks, -Kevin
  4. 8 points
    Just bringing over some related fun from a Discord channel:
  5. 7 points
    The reason it hasn’t been pushed is there are some hardware things having to do with keyboard and mouse handling which haven’t been tested on real hardware yet. However the R39 is there and can be compiled, and so long as you are using Kernal routines it should work. Personally I think R39 should be pushed and if it turns out we need to make some hardware changes we can push out an R40 release. Sent from my iPhone using Tapatalk
  6. 6 points
    (someone had to do it)
  7. 5 points
    Kevin posted this on Facebook (to which 66 comments were added; combination of smartest-people-in-the-room and snark); see images which I pasted below: He said: Hey everyone, Prototype #3 PCBs have been ordered! This board incorporates all of the fixes made to the second board, with some circuitry simplification, and the other changes I dicussed in past posts. I had been holding off for awhile as we may yet use a microcontroller for PS/2 Mouse and Keyboard control if using the 6522 doesn't pan out. I had already added an ATTiny84 to control power on/off & reset, so I moved to an ATTINY861 on this board to add enough legs for the PS/2 ports. I then added jumpers so we can select either one for testing. This will be removed from the final board, but I did try to get the layout closer to what I feel the final will look like. Other changes include: I moved from a 50 pin edge connector to a 60 pin! I was not a fan of using a 50 pin port as I was afraid folks might confuse it for an Apple II slot. Likewise, the 62 pin port is the same as an ISA card. Now, little to nothing that makes any sense will fit and I was able to add a few more pins from the CPU to the bus. This PCB is 4-Layer. I did this for a few reasons, but the primary was hoping to keep the noise level IE, RF emissions as low as possible. It now has a proper ground-plane and while the PCB cost does go up a bit in low quantity, it's not actually too bad once you start looking at 100+ PCBs. Took a wild stab at adding some EMI protection on the PS/2 and IEC port. Also added resettable fuses to main PCB to limit current flow.
  8. 5 points
    Yeah, I second that. Shouldn't this board really be the primary source of info about the X16, and Facebook secondary? Facebook doesn't like me, and the feeling is very mutual.
  9. 5 points
    Just to add a little more detail, in David’s first video he set the goal at under $99 but hopefully $50. While $50 may not be doable, don’t rule out us coming true on the first video’s mention of $99, for Phase 3 (X16E). Stranger things have happened…
  10. 4 points
    Scott! Wowzers! That's amazing to think about! Of course, there's already a lot of this sort of thing in 'the other direction' in the retro computer community. I have to take great care not to be a jerk when I see someone post on REDDIT about how their brand new VIC20 game blows away anything that ever existed at the time the machine was 'in general use' and how the original programmers must not have been any good etc., etc. Of course their new VIC20 program was put together using a cross development environment running on a modern machine with more than half a million TIMES more transistors; repeatedly (and instantly) compiled right into VICE or whatever emulator of choice for testing. The graphics were prepared using photoshop and illustrator and other utilities (having a combined code size equal to many thousands of 1541 disks); and thanks to the internet, with the benefit of having access to code libraries and disassembled code from virtually every 6502 based game app demo etc ever made! And don't get me wrong I don't begrudge folks from using those 'best available tools' for the job. But its the smug and self righteous comparisons in which they credit themselves as better programmers than the folks from 'back in the day' that tends grind my gears. I wonder what their game would have looked like if they HAD used only the same tools as the people who were programming on the old machines in the 1980s, using simple assemblers, graph paper and colored pencils for the drawings, and (on the VIC20 at least) saving their work on cassette tapes (where just the 'save' gave you time to go out and get a cup of coffee). Geez. See what I mean? I can be a real "get off my lawn" old coot when it comes to that topic!
  11. 4 points
    The bus pins may be a little misleading as some of them have the 65C816 names labeled. I am debating on exactly how to label the board, or whether or not I should at all. Even though the system is designed to be a 65C02 based machine, I designed it such that a 65C816 will work electrically in the board. The Kernal isn't a fan of the 816, so it would have to be running a different OS, but we wanted to make sure people had the option to do what they wanted with the system. When I moved to the 60 pin slot, I had enough room to move nearly all of the CPU lines over. So long story short, I should probably label the board based on the 02 names, but I've been focused on making sure you can still plug in a 816 with no HW mods needed other than swapping the chip, and the code of course. The Audio lines are inputs which are sent to the audio mixer, left & right channel. I know it's unlikely there will be a need for more sound chips with the VERA and the YM2151, but I thought someone might want to add a SID, or maybe put the SAA1099 back on later, etc. It will just allow you to pump audio in from an expansion card. I moved the pins to line up with the actual layout of the CPU to simplify routing. It's the beauty of nothing being carved in-stone.... Yet.
  12. 4 points
  13. 4 points
    I use Gimp, and that works just fine on any desktop platform.
  14. 3 points
    https://blog.davetcode.co.uk/post/21st-century-emulator/ My favorite / most horrifying part: (just to be clear, they're not serious)
  15. 3 points
    But popping a 65816 into the CPU socket won't add the "one extra chip", because it has to be in the motherboard. Popping a 65816 into the CPU socket in effect gives you a 65802 with slight bus incompatibilities (SYNC is replaced by VDA/VPA and IIRC the clock outputs are DNC and a reset input). And a bus mastering 65816 card would be pretty much the same thing, though more room for circuitry to bridge the bus incompatibilities ... including masking out the bank address from the data lines. I would be entirely unsurprised if the problem in writing VERA is the bank on the data bus followed by the data confusing Vera in a way that is not an issue with the 65C02 write cycle. Nor would I be surprised if the bus cycles for some of the chips "work" with the 6502 but just make it, and small variations in actual read or write delays associated with the transition between bank mode and data mode make the timing too tight to work. But if you can get a bus mastering card to work, you get the pcode interpreter with the accumulator in 8bit mode and indexes in 16bit mode, with ops ending with JMP NEXTOP or an eight byte NEXTOP macro: NEXTOP: INY : LDA 0,Y : TAX : JMP (OP1,X) The thing is: since it can run 6502 assembly code, can run the same pcode as the 6502, except faster, and can host a compatible ROMBASIC interpreter, except faster, and since assembly code can test whether it is running on a 6502 or 65816, it might actually work as a 3rd party enhancement. Then it would only breaks running CX16 code if people use any of the four individual-bit-addressed operations in their assembled code, so it just needs "enough" of an install base so people shy away from doing that.
  16. 3 points
    16-bit rotations are easily doable without loops because the bit that rotates “off” the register rotates into the carry flag, and the carry flag rotates into the register. so say you have a 16bit unsigned variable held at myword, and you want to multiply by 4. ASL myword ROL myword+1 ASL myword ROL myword+1 Do it a third time for myword * 8. ASL always shifts a zero into the LSB. ROL shifts the carry bit into the LSB. (that’s why it’s ASL on the low-order byte) so to finish your formula, after the three shifts: LDA #$10 CLC ADC myword STA myword LDA myword+1 ADC #$FC STA myword + 1 This can be done more efficiently but I wanted to use the most straightforward methodology as the example.
  17. 3 points
    Though it doesn't have to be future proof ... it's only a bridge until R39 becomes the baseline release. That's the part that has me in suspended animation ... I am not interested in putting code into a version test that I am going to want to strip out again once R39 is the public release.
  18. 3 points
  19. 3 points
  20. 3 points
    I couldn't agree more.
  21. 3 points
    Thank you. The change to the bank registers alone is more than enough reason to publish R39. We all know and accept that the hardware will not perfectly match the emulator, but I think it's still important to stay up to date with the latest ROM changes and hardware changes we do know about. Combined with the other changes, it's more important at this point to have the latest code than the "best" code, IMO.
  22. 3 points
  23. 3 points
    I've played with my new The C64. It's not bad. Either the lag on the USB joystick makes games I used to play harder, or my age. But I don't feel older most of the time, so it must be the hardware.
  24. 3 points
    When I look at the latest board just posted a few hours ago: We can find a socket labeled "YM2151" at the bottom right. So I'm pretty sure the YM2151 will be in the final design - as is the VERA PSG/PCM. Personally I'm pretty pleased with that .
  25. 3 points
    The last prototype had a YM2151 and both PSG and PCM in the VERA, just like the emulator. The SAA1099 is no longer on it, and was never emulated, anyway. Kevin made no mention of any changes to the sound for the third prototype, so it looks pretty set right now. The FAQ is a bit ambiguous, mostly due to staleness, just like the 8BG videos are very old now, the last coming out right after the first prototype was up and running. The only difference in the sound since the R38 emulator is a change to the addresses for using the YM2151, which is reflected in the most recent commit to the repo, which will eventually R39.
  26. 3 points
    Seen these and thought they were funny.
  27. 3 points
    I believe we're talking about "The Bard's Tale". At least I hope so, or it's going to be a Picard Facepalm moment for me. Excellent game series! I'm currently replaying it, the remastered trilogy version. I had wanted it for some time now and it just went on sale in the 2021 Steam Summer Sale, discounted to $3.74. Totally worth it!
  28. 3 points
    I did this for Dungeon Master, Dungeon Master 2, Eye of the Beholder 1,2 and 3, and Black Crypt. The spinner tiles were HELL.
  29. 2 points
    This is the fastest routine I can quickly think of: LDA semitone ; not counting this as this has to happen no matter what alg is used CMP #9 ; 2 cycles BCS @add3 ; 2 | 3 cycles CMP #6 ; 2 BCS @add2 ; 2 | 3 CMP #3 ; 2 BCS @add1 ; 2 | 3 BRA @add0 ; 3 @add3: INC ; 2 @add2: INC ; 2 @add1: INC ; 2 @add0: ORA octave ; 4 ; assume octave is stored pre-shifted into 4 msb STA keycode ; same as LDA semitone So the number of cycles is: 2 + (9|11|13|13) + 4 --> average of 17.5 cycles - so let's call it 18 cycles. a lookup would be something more like: LDX semitone LDA kc_lut,X ; 4+ ORA octave ; 4 STA keycode So twice as fast, requiring 12 bytes of RAM. Given that this operation doesn't happen super-often (pretty much only up to 8 times per frame?) I'd call this "pitayta-pitatta" / "six in one hand, half a dozen in the other" / pick your idiom. In the end, 12 bytes of RAM ain't much to sacrifice, plus the code's a lot easier to read, too.
  30. 2 points
    Yes, the sprite data should already be in VRAM. The sprite attribute table at 1FC00 will point to the start location of the sprite data in VRAM. I found @SlithyMatt's sprite tutorial on YouTube very helpful.
  31. 2 points
    So, the Opening Ceremonies for the Tokyo Olympics aired this morning (in my region) and is about to be repeated. If you hadn't heard, the "Parade of Nations" sections where all the athletes enter the stadium in groups behind their respective flags, was entirely underscored with (arranged) video game music. At first I recognized Dragon Quest (Dragon Warrior in N.A.), Final Fantasy, and two tunes from Chrono Trigger, and two others that sounded familiar but I wasn't sure where they came from. I thought they had worked some video game tunes in with other music. But, later I was able to read that all the music in this section was from video games (all by Japanese composers, of course). The two I couldn't place turned out to be from more recent games, Monster Hunter (which admittedly does have a nice theme) and Kingdom Hearts. I haven't played those but I must have heard the music somewhere. The Japanese seem to have responded very positively to this. Japanese twitter was full of people declaring that the main Dragon Quest theme is Japan's "Second National Anthem." This isn't surprising: when Enix first started to make Dragon Quest, they hired mostly young up-and-coming professionals (like character designer Akira Toriyama whose "Dragon Ball" manga had only been in publication for about a year when he was hired by Enix). But the composer, Sugiyama Kouichi, was already considered an elder statesman of commercial music and was well-known for television music in Japan. Getting an older, established name attached to this project in a new media by a new company of mostly young people was quite a coup for Enix. The popularity of the DQ theme in Japan went on to far surpass any of his previous works. For me personally, hearing video game music in general, and some of these compositions specifically, as a kid was a big part of what inspired me to become a musician. I felt like video games were still 'nerd culture' back then and that my friends and I who spent hours playing them were living in a different world from the other kids who were involved in sports. So, hearing these tunes at a sporting event (the Olympics) actually felt really good; our worlds of interest are relevant to each other. It's also just nice to see Japan recognize that their video games are an important part of their cultural identity and of the way they present themselves to the world. This link has a list of all the game used (in Japanese): hochi news And, here's my best, quick attempt at a translation of the list. However, there are some character names I don't know, from the games I haven't played. Dragon Quest [Dragon Warrior]: Loto's [Erdrick's] theme Final Fantasy: Victory Fanfare "Tales of..." series: Sorey's theme Monster Hunter: "Mark of the Hero" Kingdom Hearts: Olympus Coliseum Chrono Trigger: Frog's Theme Ace Combat: First Flight "Tales of..." Series: The Royal Capital Monster Hunter: "Wind of Departure" Chrono Trigger: Robo's Theme Sonic the Hedgehog: Starlight Zone Winning Eleven: eFootball Walk-on theme Final Fantasy: Main Theme Phantasy Star Universe: "Guardians" Kingdom Hearts: "Hero's Fanfare" Gradius Nemesis: Act I-1 NieR: Song of Initiation[?] "SaGa" series: "Song of the Demon Bard" [??] (SaGa series medley, 2016 Orchestral arrangement) Soul Caliber: "The Brave New Stage of History" EDIT: Notice, none of the games included were made by Nintendo (though some were for Nintendo systems). So my prediction is, there will probably be a Nintendo-themed segment in the closing ceremonies.
  32. 2 points
    Exactly! I once computed the number of disks that would be required to emulate a Windows 10 system on a C= 64 with 1541. Let's see, the computer I'm using right now, assuming we could even fit a CPU emulation in a C= 64 without having to swap programs in and out of the address space, would need 16 GiB for RAM and 951 GB for the SSD. So let's call that 902 GiB. I can store 166 KiB on a 1541 based on 664 blocks free (I'll just assume I read and write individual blocks rather than use files which would consume two extra bytes per block, and any overhead I can squeeze into otherwise unused directory sectors). So I'll need almost 5.7 million floppies just to emulate the RAM and SSD. Undoubtedly I'd need more to emulate other aspects of the system such as video RAM, CPU cache, etc. I wonder where I can find 5.7 M new old stock floppies? Or we could go really old school and use tapes!
  33. 2 points
    Hi, I was struggling a bit with reading the Kernal version number in an assembly program that is to support both R38 and R39. As is apparent from the PRG, the Kernal version is stored in ROM bank 0/$ff80. The problem I had was that you are not in ROM bank 0 when starting an assembly program from BASIC. Reading $ff80 in the BASIC ROM bank does not give you the version number. And to change ROM bank you need to know what version is used. Almost like "catch 22". I found a solution using the Kernal function FETVEC ($ff74) that is callable from the BASIC ROM bank, getting the version number like this: lda #$80 sta $22 lda #$ff sta $23 ldx #$00 lda #$22 jsr $ff74 And then you have the version number in A.
  34. 2 points
    Google presented nice retro game as a doodle: https://g.co/doodle/99dkzef
  35. 2 points
    Your mindset seems really sensible. Even if further tweaks are necessary, a release would take the community off 'pause' (avoiding any potential fall off of enthusiasm), and also acknowledge the value/importance of the work by the team members who have put so much time into the updates from r38 to r39.
  36. 2 points
    Alas, the best I could come up on my own with were 1990s games or later. To supplement your list: Dragon Quest V (1992), the game protagonist marries one of three different women (the player chooses which). Super Mario RPG (1996), an antagonist named Booster attempts to marry Princess Toadstool. The ceremony is broken up at the last second. Final Fantasy X (2001), Summoner Yuna agrees to marry Seymour Guado, but it turns out to be a ruse that goes wrong and she is forced to flee from the ceremony at the last second. And the closest a quick internet search could get me was Phantasy Star III (1990), where the main character can marry one of two women in the game.
  37. 2 points
    Email sent. Also, first post!
  38. 2 points
    I never felt that the YM was in question ever since the successful demonstration of 8MHz bus compatibility. The SAA and AY PSGs were always on the bubble, so to speak, and as soon as VERA PSG was announced, I knew those chips were goners.
  39. 2 points
    I would still like to know why this isn't the primary location for X16 info. Facebook is Draconian in their account rules and fast and loose with that data once they have it. I refuse. But if it's just me, so be it, but pretty disappointing.
  40. 2 points
    Welcome! Yeah, the ROM is flashable. But... first, the FAQ is probably the right place to start... at least to get a level-set on some of the assumptions.
  41. 2 points
    The biggest problem I think would be memory access time. Modern CPUs have complex fetching and caching schemes to pull lots of memory into the CPU at one time, and lots of units running in parallel to keep the CPU busy at all times. Whenever an x86 CPU has to access RAM it has to slow down potentially to wait for the memory request to be fulfilled. This is the primary reason why a 1 MHz 6502 was comparable to a 4.77 MHz 8088 for certain types of processing. If you could keep an 8088 busy with data already loaded into registers, it would potentially be a lot faster than a 6502 (depending on the instructions), but any time it had to go to memory it took 4 cycles, and since it was a 16 bit CPU with an 8 bit bus, it took 8 cycles to load a word. I would love to see a super fast 6502, but since the model requires a memory access (or more) with most instructions, it will always be limited to the speed of RAM access. Now, modern RAM can be accessed very quickly compared to the Good Old Days, but each access is (as I understand it) accessing 64 bits at one time. So the interface between the CPU and RAM has to be able to deal with the bits per access. A 6502 is built around 8 bit bytes, so either the CPU has to be rearchitected to deal with more bits per memory access, or a shim interface would have to be inserted between the CPU and RAM to mask out just the bits of interest, which would slow things down. http://forum.6502.org/viewtopic.php?f=1&t=6049 is a forum post that talks about theory and practice of what 6502 architecture speeds have done. Most notably is the quote (if accurate): So it isn't thought impossible by experts, but someone has to want to do it to make it happen. Clearly the market for it isn't there or else it would have been done already (most likely).
  42. 2 points
    Yep. Sort of. I can set custom colors for the background of cells, set a Style to that color, and then use that Style by reference, i.e.: J30=T(STYLE("C4"&J14)) Whatever value is in J14 (a hex digit from 0 to F) becomes the color displayed in J30 (so if J14 contains 3, the style displayed will be style C43). This is actually much better than graph paper, because I can make all sorts of changes, no problem. I even have the spreadsheet set up to generate a BASIC program, so once I make all my changes I just copy one sheet to the clipboard and paste it into the Commander X16 emulator. edited to add: the world's most popular Functional Programming language isn't Haskell, it's Excel.
  43. 2 points
    One simple approach is to use the secondary address as a generic index to a protocol string, and send the protocol string along with the secondary address it is associated with on the command channel. Supposing the device is device #14: OPEN15,14,15 PRINT#15,"SA2:P80" CLOSE15
  44. 2 points
    Hello, I'm not old enough to have owned a C64/Amiga/Apple II, the first computer family was MS-DOS. But trying to learn (S)NES programming and watching David's or Ben Eater's videos made me *fall in love* for the 6502. Can't wait to dev my first game on the X16 emulator. Regards
  45. 2 points
    Okay, time to shift gears a little bit - this game is multi-platform, originating from the arcade. The original arcade version features colorful 4bpp graphics, multi-layer parallax scrolling, and FM+PCM audio. The arcade version is a fast paced side-scrolling hack-n-slash, quarter muncher. It is single player only (2 player alternating) gameplay, and is set in a swords and sorcery style game world. It was ported to a wide variety of systems, ranging from the C64, ZX Spectrum, NES, Sega Master System, and Atari Lynx, all the way up to machines with nearly arcade-perfect quality ports such as the Amiga, Megadrive, and the Sharp X68000. In western markets, the game's title is 'simply' the eponymous hero's name, but this was actually a mistake. It was actually the villain's name. The game's Japanese title does refer to the hero, but not by name, so perhaps this is why the western title was assumed to be the hero's name. The hero was actually un-named in Japan, simply known as "The Hero of Argus." Since the western title was commonly mistaken as the hero's name, it did officially become the hero's name. The villain's name was then modified - but only by changing the first letter from R to L. (which is funny because they're basically the same letter in Japanese) The NES port is unique from the others. Like many NES ports, it was heavily modified from its original form, making it into more of an action adventure format than a pure arcade-style experience. One final hint: The NES version is well-regarded, but one of the main complaints is that it lacks any kind of save-and-continue system such as a battery backup or password system, so it must be beaten in one sitting.
  46. 2 points
  47. 2 points
    Welcome back ...
  48. 2 points
    Yeah, it's an odd mod that's for sure, and does look like it was hobbled together from available materials when it was done. The reason I thought industrial was from past experience. I used to work for Coca Cola, many moons ago, and we had to use long extension cables to connect keyboards/displays/etc. to computers that were located outside the production room. Mainly for "add-on" or temporary equipment. The environment in the filler rooms was too humid and generally damp, even though they were air conditioned, for any hardware not sealed inside an environmentally controlled case, or otherwise designed for that environment. In some cases, we had to make our own cables or rig something up to solve a temporary problem. For a home user, I could totally see someone wanting to hide or move the spaghetti cable monster away from their desktop. All good ideas and observations.
  49. 2 points
    TL/DR: the analog outputs are just hooked together with at most some discrete components that make sure the audio is clean. Nothing software controllable. For VERA, we already know how the PSG and PCM are being mixed prior to analog output: Per-channel volumes on PSG and a PCM volume setting in the PCM ctrl register. I.e. no master volume for PSG and no master volume or mixer controls. As to how it actually does the final mix internally, I couldn't say. Ideally, the outputs of PSG and PCM are mixed by just adding them together with enough headroom to avoid clipping or needing to do any kind of dynamic range compression stuff. Finally, we know it's being output to the system as an analog signal. The YM has its own DAC and amplifier. Watch Adrrian's Digital Basement episode where he helped troubleshoot the Prototype 2 board - he does briefly mention the op-amp ICs on the YM. From this video; from some conversations I've had with Kevin; and from other posts that I've seen the past couple of years, I'm pretty confident to say that the two analog outputs are just hooked together on the board and the combined signal is sent to the audio out jack. There's no mixer circuitry, at least none that can be interacted with to give master volume + level controls for YM and VERA. Essentially, if you want to mess with volume, you have to do it on each and every channel of input. Don't take this as "word of God" as I'm not involved with the actual hardware design in any way, shape, or form. But I'm quite certain this is how it's going to be. The most I would expect to see as far as level adjustment between the VERA and YM outputs would be a pair of pots on the board, but I don't think we saw anything like that in pictures of the latest board.
  50. 2 points
    Okay here's one: This RPG series started on the Apple ][ and was ported to many other systems at the time. This game's presentation is almost entirely in 1st person 3d as shown in a small window at the top-left, which is also used to display the portraits of NPCs you meet, and monsters that you encounter. Most of the screen is taken up by the message log and party's stats. The series introduced a fairly unique character class for which the series is named. This class enabled a newer mechanic which is similar to party buffs in modern MMORPGs. While the first installment took place entirely within the walls of a single city, this installment sees the party travel to several towns, each hosting one of the dungeons that must be completed in order to win the game. The game's creator is a devout Christian, and the towns were named after 1st century cities notable from the New Testament as locations of early church congregations. Interestingly, these were initially supposed to just be place holder names but the names were never changed. (Personally, this is the RPG series that I preferred to play rather than Ultima.)
  • Create New...

Important Information

Please review our Terms of Use