Видео

Oh, I'm sorry! :( I've not encountered it myself yet with the DualShock 2, but I can see how it could happen if the plastic was getting brittle with age.

The serial pinout is at the top of Serial.asm (pin numbers are given for DE-9 ports on the Master System, pin numbers at the other end will depend on what serial device you're connecting to). Pins are described from the context of a DTE (so TxD and RTS are outputs from the Master System, RxD and CTS are inputs to the Master System).

I should probably also mention that if you're going to connect the Master System to anything that uses RS-232 you'd also need an interface circuit to adapt the voltages (e.g. MAX232 chip or equivalent) - I don't think the Master System would be very happy to have -12V dumped onto its controller ports!

Thank you! The microcontroller here is an ATmega324P which is related to the chips found in some Arduino boards. The Arduino system tends to involve a bootloader preloaded onto that chip, a USB to serial interface to load a program onto the chip via the bootloader and a bunch of libraries to ease development in C, whereas here I'm just using the plain chip with no bootloader and no USB interface (I program it via the ICSP pins and an USBtinyISP) and I don't use the Arduino libraries, I write the code in plain C using avr-gcc as a compiler (the AVR datasheets are very clear on how to access on-chip peripherals like the ADC via their registers with plenty of sample code). In this case as I wanted to be a USB MIDI device I used the V-USB library which implements USB in software, if you search the web for "V-USB MIDI expression pedal with capacitive sensor" you should be able to find a good sample project that gives you an idea of how a USB-MIDI device using a cheaper AVR might look.

@@benryves Thanks so much! This is great info, I can imagine actually making some viable professional-seeming products this way. And I've found the github project by that name, I think I can go from here. Thanks again :)

I'm not sure how well they'd scale up to larger sizes - you might have a smaller change in resistance so you might need to press harder or have a more sensitive circuit to measure them; alternatively you could try dividing the larger pad into a few smaller pads underneath. Could certainly be interesting to experiment with, at the time I was playing around with this I was trying to replicate the small pads on MIDI controllers so never tried anything bigger than what you see here.

Thank you! Personally I use a VGA cable, but I make sure that when I buy a TV it has a VGA connection on the back. Not all games are VGA-compatible so sometimes I swap to other cables (RGB SCART, S-Video, composite...) depending on the need. If your TV lacks any sort of analogue inputs (so it's just HDMI, for example) then there's a whole array of different products out there that can convert from analogue signals to HDMI - I use a GBS-8200 board with the gbs-control modifications for some of those, but there are commercial products like the OSSC or RetroTINK series. You've also got cheap cables specific to the Dreamcast that contain a VGA to HDMI converter (these unfortunately squish the picture horizontally, but at least they're cheaper and less involved than a dedicated scaler that would handle the picture properly) and if you want to go all-out there's the DCDigital mod that natively outputs a clean digital HDMI signal directly from the Dreamcast. Getting the best picture from old consoles is a complete science in itself, so maybe take a look at the RetroRGB channel here on RUclips for example as they cover things in much more detail than I could in a comment here!

I can't share links on here but put "bbc basic z80" into your favourite search engine and you should find it quite easily. The original author R. T. Russell hosts a generic CP/M version on his website and source code for it is also available on GitHub should you wish to port it to a different Z80 machine (i.e. not one running CP/M).

@@benryves Tks

How i Can compile this? Have you comand line, Pls?

@@diego123cruz Assuming you mean BBC BASIC (Z80) that you've downloaded from GitHub, there's a Makefile so "make" should assemble the project, but that's the easy part. As well as development tools (like "make") you'll need z88dk. As I'm predominantly a Windows user I use Debian running inside WSL as my build environment as it tends to be rather easier to get working under Linux. The z88dk page has instructions on how to download and build it under Linux, though this is rather outside the scope of a RUclips comment and I don't know how much you already know about setting up development tools under Linux.

Thank you! The light gun contains a light sensor (and amplifier) and sends a pulse to the console when it "sees" light (any light) via the controller port's TH pin. The program on the console can poll whether the gun currently see any light, and when it does it can read the VDP's free-running vertical counter register to determine which scanline the VDP is currently outputting to the TV to determine the vertical position. It can also read the horizontal counter register to determine the horizontal position, but as this would count up too quickly for the software running on the console to accurately keep up with this is automatically latched by the hardware when the TH line goes low rather than being free-running. This works on a CRT because the CRT isn't constantly illuminated, only a small extremely bright dot is illuminated at once (the position of which corresponding to the horizontal and vertical counters in the VDP) and it's our persistence of vision that makes it appear as a solid single image (albeit a slightly flickery one, at least here in 50Hz PAL-land). On a modern LCD TV the entire picture is constantly illuminated by a solid backlight which means there's no way to determine the aimed position on when the gun "sees" light as it will constantly see the same light, regardless of where it's aimed (though in practice the spot that you aim at on a modern LCD is a constant much lower brightness, rather than a sudden very bright spot on a CRT when the sweeping beam passes under the point you're aiming at, so it may not have enough brightness to trigger the light sensor in the gun in the first place).

No, as the TI-84 Plus CE doesn't have the traditional link port (only USB) and isn't compatible with TI-83 Plus programs. You'd need a USB version of the "modem" and a TI-84 Plus CE-supporting client.

What about “TI-84 Plus”? Older copies of that one have a 2.5mm jack.

@@S-VideoYes, that should be fine, as the TI-84 Plus is backwards-compatible with the TI-83 Plus. The "modem" part should work on any calculator with the old-style 2.5mm link port, but you may need to search for suitable terminal software for the calculator.

It's a raster timing-based light gun (like most other light guns) so will only work with a CRT.

If the issue is the same then a fix using the same principle should indeed do the trick. If you mean this specific circuit and code then probably not, though, as it's designed to cater to the hardware and firmware of the Sega wheel so will likely need to be adjusted to whatever's going on inside the MadCatz MC2 wheel. Sorry that's a bit of a non-answer, but having never seen the MadCatz wheel I can't say for certain!

I don't see why not, you'd need some sort of terminal software on the Palm device (e.g. "Online" by Conklin Systems) and then a way to connect the modem to the Palm device. This project is based on RetroWiFiModem and just swaps out the serial UART code with code that uses the calculator's link protocol, the original RetroWiFiModem is likely a better starting point.

If it was USB host compatible, I don't see why not. This was just hooked up to my PC as I don't have any standalone MIDI modules. You'd probably be better off picking up something like an LPD8 instead of rolling your own, though!

Hi, sorry for the delay in getting back to you! I'm using the ADMUX built into the microcontroller rather than any external multiplexer (one of the performance limitations is only being able to sample one pad at a time). I never got around to saving the calibration data for pads so don't know how stable it would be in the long term. Never had any issues with cross-talk, though! The LPD8 is fine... once you insert some plastic shims between each rubber pad and the conductive membrane (I cut mine from a plastic sandwich wrapper). By default you need to hit the pads pretty hard to register, I guess they erred on the side of caution to avoid false triggers. Quite a few videos on RUclips show similar mods (e.g. putting electrical tape in as a shim) so it's not specific to my unit. Not sure about hackability, but as the device speaks class-compliant USB-MIDI I'd be tempted to just use a USB host microcontroller rather than start cutting PCB traces.

Not currently, no. It's still a work in progress.

Cheers! For the light gun I use an input capture module which can store the value of a timer when triggered, so I use it to capture the value of the timer that generates each scanline when it receives the pulse from the light gun and that gives you the X coordinate. At the end of each scanline I check to see if the input capture was triggered and if so use it to track the minimum and maximum Y coordinates (the gun will trigger on multiple scanlines). As the dsPIC33E is already running a bunch of timers and counters to generate the video signal it makes it quite easy to check those when the gun "sees" the light on the screen. :)

@@benryves Very cool! Scanlines are cool :)