Jump to content

Wavicle

Members
  • Posts

    195
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by Wavicle

  1. Hello again, everyone. As we've had a chance to test this change out on more software, I think that I underestimated the impact of the "trap" above. @ZeroByte suggested moving bit 8 of the SCANLINE from IEN[7] to IEN[6] which will re-enable read-modify-write operations to IEN. (E.g. you can enable a single interrupt by doing IEN |= 0x20 without knowing what bit 8 of the line IRQ should be). Let me know of any problem/issue you see with this modification to the new (and as yet unsupported in the emulator) scanline feature.
  2. The assumption is that if you are enabling interrupts, you already know what IRQLINE should be. You need to mask off bit 7 and set it to whatever it should be before writing it back out.
  3. Hello Everyone, I've another update on the VERA design, and this one is important if you are working with VERA interrupts. Please read if you write games, demos, or any program that uses line interrupts. The IRQLINE register now has different read and write semantics. Writing the IRQLINE register (IRQLINE_L / $9F28 and IEN / $9F26 bit 7) still works the same, however reading the IRQLINE register now returns the new SCANLINE register. This is a 9 bit raster line counter that starts at 0 and counts up 511. It will sit at 511 for scan lines 511-524. 511-524 are "scan lines" that happen during VSYNC. In progressive scan mode, 479 is the last visible line. In interlace mode, SCANLINE counts even numbers on even fields and odd numbers on odd fields. This means that bit 0 of the SCANLINE register reports nearly the same thing as bit 7 of the DC_VIDEO register. There is one "trap" here that developers need to be on the lookout for here: it is not safe to set bits in the IEN register using a read-modify-write. Performing a code sequence such as LDA $9F26 / ORA $02 / STA $9F26 or using the W65C02 bit set/clear opcodes has a chance to flip the value of IRQLINE bit 8 depending on the line being drawn when that code executes. Any code writing the IEN register will need to know what the value of IRQLINE[8] should be because it is no longer accessible through the register interface. This was discussed at some length on Discord and the feedback from those present was that the drawbacks from having to take a few extra steps when writing the IEN register was outweighed by the benefits to some types of software being able to poll for a particular line. If anyone feels that we reached the wrong conclusion, please make your case (constructively and with civility!) in this thread so that we know where to find it. More details can be found in the PR implementing this change here: https://github.com/fvdhoef/vera-module/pull/21 Here is sample output from a demo program written by @MooingLemur that changes the background color every scanline.
  4. Kevin posted an update to Facebook on the topic of 6522s and user port: Commander X16™ Prototype | Facebook
  5. It's under consideration. Nothing definitive yet, but if removed from the base design, there will be a dedicated header for those who would like to add it back in. Its location in IO space will not change.
  6. I should also add that both Kevin and I are leaning towards making VIA2 optional using a header on our respective boards. There may be enough pins on VIA1 now to do SPI there. I briefly mentioned this to Kevin, but he is generally cautious about adding new functionality.
  7. Just wanted to clear up the I2C speed question - using nearly every trick available, I2C is running stable at 150-175KHz. It might be possible to run it faster, but not by much. It does support clock stretching so slower I2C devices that can't go over 100KHz shouldn't have a problem (as long as they apply back-pressure by stretching the clock).
  8. Frank accepted my pull request that implements a feature request from @ZeroByte in which bit 6 of AUDIO_CTRL ($9F3B) will read as 1 if the PCM FIFO is empty. The idea behind this is that if software is waiting for the FIFO to drain to reconfigure the PCM state machine for playback at a different sample rate or sample size, that software can now poll this bit to minimize latency where previously it had to be guessed at.
  9. The kiosk demo at VCF Midwest was almost entirely SD-based (the kiosk code lived in the ROM, but all the demo software was loaded from the SD card). Zero read failures all weekend. Seems pretty stable.
  10. More HW savvy readers may ask the obvious question of why I needed to add capacitance to VERA when Kevin's PCB did not. The most likely answer (to me, anyway) comes from a size comparison of the two PCBs: Kevin's board is micro-ATX and mine is mini-ITX. The trace length of the address and data lines on the official board are 2.5-3 times longer than mine. Those longer wires necessarily have more stray capacitance, and one doesn't need a great deal of additional capacitance to get it working. Considering all of the wires on the official board have to cross nearly the full width of the micro ATX board *twice* and then some, it seems to make sense. The reason I had to dig down on this timing issue and not continue using a 30pF cap on A2 is that on my latest board (the green one in the first post) I tightened up my trace lengths even more and now VERA was missing A4 and occasionally A0. While pondering the exact cause and solution to the problem, my brain wandered back to the discussion I had with the other retro hardware experts Sunday evening and then had my eureka moment: the issue causing my current board to misbehave worse than the previous one and the issue preventing 65816 from working on the board had the same underlying cause: /WE deassertion wasn't seen by VERA until we were right on the edge of missing the correct bus state. After getting the board to boot from 65C02 without adding more load caps, I swapped in a 65C816 to test the theory. After removing the 30pF load cap from A2, it worked!
  11. In this particular implementation, the upper 8 bits of the 24-bit address are always ignored. Fixing this while retaining X16 compatibility would require a CPLD and a major architecture change to the board. On my latest PCB, I ensured that it was electrically compatible with the 65C816, but nothing beyond that. The issue I fixed was a marginal timing condition on VERA where it snapped the address and data bus on writes at the rising edge of /WE. The precise reason this did not work is not clear to me, however the general reasons were: the datasheet specifies only 10ns from the falling edge of PHI2 when the write address and data are guaranteed to be held on the bus; the propagation delay of the NAND gate that drives /WE eats up most of that time; the stray capacitance of /WE on the board eats up a little more; the level shifter on VERA eats up a tiny bit more; I *think* that VERA sees /WE fall ~1-2ns before the end of the holding window. For some reason that 1-2ns isn't enough and VERA would occasionally catch some signals transitioning and end up with a corrupted write. On the 65C02, this pretty much always ended up being the correct data written to the wrong address. In particular, for reasons not at all clear to me, it was always, or almost always, A2. I worked around the issue on the boards I took to VCFMW last weekend by adding a 30pF cap on A2. This would slow A2 falling from logic 1 to logic 0 by about 1ns and VERA would always catch the correct value. The 65C02 write value was always correct because the CPU doesn't start slewing those until well after the falling edge of PHI2 (except when writing the return address on the stack following a JSR or interrupt, but hopefully nobody designs a computer where VERAs IO windows overlaps the 6502's stack page.) On the 65C816, the data lines switch to the address bank somewhere around 10.5-12ns after the falling edge of PHI2. I don't think VERA ever saw a write that wasn't $00 (the address bank of everything in emulation mode). The fix was to sample the address and data bus on every VERA clock edge (every 20ns). When /WE is deasserted, the snapped bus state is the one seen on the last clock edge. There's a voice in the back of my head saying that there may be a metastability in there if VERA's clock edge is very close to /WE deassertion, but I've yet to see anything over millions of read/write cycles. I tried to avoid this by using the second-most-recent bus state, but that did not work. I'm not sure why.
  12. It's the full(er) part number of the 65816. The "16-bit"* successor to the 6502 that was in machines like SNES and Apple IIgs. David mentions the reasons for not using it in his dream computer #2 video. The biggest problem with the '816 wasn't so much demultiplexing the AD bus as getting the CPU and VERA to talk at all. * not really 16-bit but did have a 16bit ALU and most registers were widened to 16 or 24 bits (I think the PC was widened to 24 bits, I could be wrong on that).
  13. Tracking an issue in my latest PCB gave me a brain tickle back to a conversation I had with Adrian Black (who famously has a Digital Basement) and Tech Man Dan Retro Tech Dan at VCFMW this past weekend. The '816 wouldn't boot on X16 due to a VERA timing sensitivity. Fixing VERA's timing issue should, in theory, correct both problems. Presenting Commander X16 booted on a W65C816S at 8MHz:
  14. Yes. 6502 clocked at 10MHz. VERA is still 25MHz.
  15. My hope is that at some point I can figure out how to tweak VERA timing and have a fully working system at 10MHz. In theory the ROM should not be able to keep up, but it hasn't hit the wall yet.
  16. Hey everybody, I've been playing with my newly built 2MB memory expansion and on a whim thought I'd check how well STNICCC does at 10MHz (STNICCC requires 2MHz to run). Check it out!
  17. Yep, I have a real VERA. The rest of my hardware is compatible of my own design, but my VERA is a VERA.
  18. One other thing that I forgot to mention and just tested - the demo appears to depend on memory being cleared to zero, which it isn't on hardware. @MooingLemur wrote me a raminit program that clears memory and when I run it before bond.prg, the audio is a little bit better (the video is still stuck though).
  19. Bond_SD_Root.mp4 Looks like moving the files to the root was one thing that needed to get fixed. Now it only updates the left side of the display as you'd mentioned it would do if it couldn't keep up.
  20. Plays great on my hardware w/ SNES controller. The sound is a little on the quite side. I bumped the audio gain quite a bit here when transcoding the raw capture: Petaxian_Crop_Fix.mp4
  21. I have not tried on the emulator. A video might do a better explanation than I could hope to do myself (warning: loud pops): Bond_Hanging.mp4
  22. Unfortunately, the demo video hangs on the first frame on real hardware. There's an upcoming event where something like this playing maybe an excerpt from the "Building my Dream Computer" video would probably be very well received. Any idea on what the hang on hardware is or how difficult getting it to play a 1 minute bit of that YT video is?
  23. I created a diagram of the current pin commitment on the 861 in the SMC source code here: x16-smc/smc_pins.h at main · commanderx16/x16-smc (github.com). The next step up from ATTINY861 is pretty much the ATmega328p (the Arduino microcontroller). I don't particularly like the ATmega328p for aesthetic reasons, but Kevin seems ready to make the switch. If I can plan strategy with him prior to his doing proto 4 design, I could pitch the idea of placing footprints on the PCB for both. Not sure how that will go over though - Kevin and David both want the HW finalized post haste; nobody wants there to be a proto 5.
  24. Unfortunately, at this instant in time there isn't much of an active core team. @Michael Steil was pretty active this past spring, but other obligations consumed his available time just before summer started. Since then, @Kevin Williams has been pretty active but in the past couple of weeks he has been busy filling orders for his paying gig and is now spending what free time he has prepping for VCF Midwest. I've exchanged maybe 3 emails with David in the last 6 months, and he had neither spare time nor X16 hardware of his own. He's been happy to hear about the progress but hasn't been able to get much involved. To the best of my knowledge there are two functional proto 3 boards (Michael has one and Kevin has the other); a third for David started getting built just this past week. I've sent Kevin three of my clock-stretching modules which I hope will make it into all three of those boards; the proto 4 boards will hopefully contain the clock stretching circuit and have no need for the module. It is also my understanding that the biggest blocker preventing more proto 3 boards from being built is the lack of a working keyboard. There is no hardware for anyone to prototype such an MCU solution - but there is a fully functional I2C-based keyboard solution which has been tested and works on my hardware and Kevin's proto 3 board. If nothing else, the new functionality here should unblock X16 development. For comparison, I have three functional X16-compatible computers of my own design on my bench: "Antares" and "Canopus" that are fully functional on manufactured PCBs; and "Breadboard16" which was fully functional at one time, but now exists only for nostalgia.
  25. I've done the clock stretching circuit that works with the clock divider and delivers an unstretched clock to the VIAs. It was needed to enable reading from the YM2151 at 8MHz. At max stretch, it slows the high phase of PHI2 to an effective speed of 2MHz. I had designed a circuit for interfacing a microcontroller to the 6502 bus. It doesn't assert RDY but does have the ATTN/ACK signals in bits 6 and 7. It's a bit out of date, but the principal is still valid. It required 6 ICs. That would be a big architectural change. The design for it is up on GitHub here: jburks/X16-Simple-Intf: A very simple X16 to microcontroller interface. (github.com). With any change at this point the biggest questions become: Is the architectural risk justified by what it returns? How much does it increase complexity / the ability of the average enthusiast to understand the overall design (the "VIC-20" standard)? We have a working keyboard and mouse solution; what does the change proposed get us? Querying SMC over I2C every VSYNC has a performance hit of ~3% (30ms spent performing I2C transactions per second). There are some protocol tricks that could shave a little bit of time off of that (e.g. have a combined keyboard + mouse transaction instead of a transaction for each), but if we ignore those and just consider the 3% number - what will we gain from throwing more hardware at the problem? A 3% hit to an 8MHz 8-bit retro system still leaves us with a screaming fast retro system.
×
×
  • Create New...

Important Information

Please review our Terms of Use