nfg.forums

Quote from: kona333 on March 10, 2025, 09:13:42 PMHello.
Is it possible to play 04 correctly in Akumajou Dracura sound mode using MT-32?
It seems that there is noise mixed in with this song only.
Thank you in advance.

Sorry.
It seems to be working fine.

Hello.
Is it possible to play 04 correctly in Akumajou Dracura sound mode using MT-32?
It seems that there is noise mixed in with this song only.
Thank you in advance.

So I'm neck deep in this thing and I've got a photo of the bottom of the main board.  This is the relevant part, showing the HD connector and pin 12.  The red line shows where it goes, but all of this transistor voodoo is way above my skill level.

As near as I can tell this is connected, after several hops, to pin 47 of the uPC1880AC.  I've found exactly one Japanese datasheet online, but it's so poor quality it's borderline useless.  Google translate barely managed to describe pin 47 as 'direct sync input'.  So, that makes sense so far. 



But short of pulling every component in the path of that signal and seeing if it still tests fine, I'm not sure what my next plan of attack is.

I'd really like to find a better datasheet for this chip, at the very least.

1	Sample Hold ??	25
2		26
3	Mode Output 1	27
4	Mode Output 2	28
5	Mode Output 3	29
6	Mode Output 4	30
7	Mute ??	31
8	Mute Pulse Output	32
9	?? F/V ??	33
10	FBP Input	34
11	Horizontal Pos Adj	35
12		36
13		37
14		38
15	AFC Output	39
16	AFC Output	40
17		41	H Sync Input
18		42
19	H Sync	43	Composite Vid In
20		44
21	Pulse ??	45
22	High Pressure Protect	46	Separated Sync Out
23		47	Sirect Sync Input
24		48

The NEC PC-TV454 is a 14 inch-class shadow mask monitor that was manufactured c.1989.  It's one of the most versatile monitors around, with RF/TV, two composite video and one s-video inputs, as well as digital RGB, 15/24/31kHz analogue RGB from three inputs (9- and 15-pin RGB, and 21pin RGB).

I've had mine since about 2003, but a few years back I wasn't paying attention and I put 5V through the V-sync input, frying the monitor's ability to work with RGB.  It still works fine with video and s-video.

I recently started working on this again, when I started thinking the problem through: 

Normally, when RGB mode is selected, the screen shuts switches to RGB mode and displays "RGB" as an overlay.  But currently it just blanks the OSD and doesn't switch away from whatever mode it's in before the mode is changed.  So instead of going from S-Video with 's-video' on the screen, the OSD just disappears and the s-video signal remains.

This led me to believe it was maybe one of the 4053 or 4066 analogue switching chips which had blown some inputs, or maybe whatever signalled those to switch had failed.  If they're not switching to the correct input...

But which one? 

The first thing I did was follow the sync line that I put 5V through.  It went through a couple of 4053 switching ICs, which were rated for more than 5V, and then it disappeared into the depths of the CRT where it was much more difficult to follow.

So I focused on what I could reach.  The next thing I tried was the cluster of four 4066 chips that do a lot of the signal switching.  In order to understand what they did, I mapped out the control pins while cycling through each of the RF/vid/RGB modes.



It's pretty straightforward, but there's an outlier.  Normally the switching voltages are either ~8V or 0.04V, but when I select RGB mode one of the pins only goes from 0.04 to 0.2.  That's below the 1V threshold required for switching between B1 or B2.

But B1 and B2 are audio, one from the RGB21 input and the other from the depths of the TV - probably from the tuner.  So I backburnered this for now, but if I need to get back to it, this pin seems to be driven by Q6812.

Then I started tracing the whole input board, to try and get an understanding of what it was doing.  It was not only taking the signals from the input panel, it was handling all the input and output controls too.  This monitor has audio and video passthrough, and optional RGB output through RGB21, so not just inputs. 

So I spent a few days making this:



It's not done and I'm sure there are still errors.  I've been making corrections as I find them, often one signal leads to the same cluster of parts as another, and the errors from the first pass are pretty easily picked up.

And then I focused on the AN5352 chip. The JP/EN PDF is attached.  It's a more complete version than the English one, and includes several testing circuits.  Matsushita-AN5352N-2.pdf  I also found the NEC µPC1397C, which is a drop-in replacement:  NEC-uPC1397C_(AN5352).PDF

The AN5352 is a video overlay chip from Matsushita designed to overlay teletext on a TV video signal.  It takes the TV (R-Y, B-Y, G-Y) lines and puts the RGB lines on top.  In this monitor it's primarily used for switching between TV/Video and RGB mode.  Interestingly it has a dimmer control to dim the TV and leave the RGB at full brightness, and this is tied to Ym on the RGB21 - so if the connected device says 'dim the screen' it will do that.

Since the monitor was not displaying anything different when asked to go into RGB mode, I figured the AN5352 wasn't getting a signal on pin 12, which controls TV/TX.  Sure enough, this didn't change when I probed it (it flickered, but nothing more).

But while tracing the circuit, I found that RGB21 pin 16 (Ys) was tied directly to this pin, and would force the AN5352 into RGB mode if it was high.  I checked my stockpile of RGB cables and found that the official Playstation RGB cable used this pin, so I tried it.  Sure enough, the monitor switched into RGB mode! 

Sort of.  The previous mode switched off but I still didn't get a display from the RGB input.  The AN5352 was doing its job but it wasn't getting anything to show.

I'm pretty confident that the AN5352 works properly now, at least.  But that was the last hope for finding a fault in the easily accessible board.  The problem lies deeper in the monitor.

To be continued...

I went the other route for this and modded the x68000.

I have a CZ-500    and a CZ-600C, and the newer CZ-500 uses LS04 for sync, while the older one uses LS06 for sync (which as mentioned is open collector).

I just went ahead and swapped the LS06 for a LS04 (actually a HC04 which was what I had at home), and removed the pullups (R26, R27). Now it syncs perfectly with the Extron, and has less sync interference on my Sharp monitor (previously it had a tiny bit).

Can recommend that mod for CZ-600C.

Not sure if this is helpful but I am pretty sure a BlueSCSI 2 worked on the external port of my 40H, which is pretty similar to a 20F. My SillyTinySCSI-Centronics50 had some issues. Never really found out what the problem was but my conclusion was it's the physical connection with the plug.
I am now using an internal ZuluSCSI (RP2040-based, with CDDA addon, SD extension and custom bracket for the extension, button and audio jack) in the 40H and a CX20.
The ZuluSCSI is again very similar to BlueSCSI 2.

I recently purchased a pre-built BlueSCSI v2 kit in hopes of using it as an external SCSI HDD with my 20F. However, nothing I try is working.

I have tried multiple SCSI IDs and have been using proper naming conventions (e.g., HD1.HDA, HD10_512.HDA, etc). I updated my BlueSCSI v2 unit to the latest firmware and have tried multiple INI settings, such as the ones seen below.

[SCSI]
System=Generic
Quirks=0
EnableSCSI2=0
Debug=1
DisableROMDrive=1

Below is a log sample, which also looks good.

Platform: BlueSCSI
FW Version: 2024.12.08-rel Dec  8 2024 22:19:03
Flash chip size: 2048 kB
 
=== SD Card Info ===
SD card detected, exFAT volume size: 121888 MB
SD Name: SD128, MID: 0x03, OID: 0x53 0x44
[131ms] 
[132ms] === Global Config ===
[135ms] Reading configuration from bluescsi.ini
[139ms] Active configuration (using system preset "Generic"):
[144ms] -- EnableSCSI2 is off
[147ms] -- Debug is enabled
[149ms] DBG -- Parity is enabled
[152ms] DBG -- ReinsertCDOnInquiry is disabled
[209ms] 
[209ms] === Finding images in / ===
[211ms] == Opening /HD10_512.hda for ID: 1 LUN: 0
[216ms] DBG ---- Read prefetch enabled: 8192 bytes
[219ms] ---- Image ready
[222ms]
[222ms] === ROM Drive ===
[224ms] Platform supports ROM drive up to 1692 kB
[229ms] ---- ROM drive image not detected
[232ms] 
[233ms] === Configured SCSI Devices ===
[237ms] * ID: 1, BlockSize: 512, Type: Fixed, Quirks: None, Size: 1363148kB
[993ms] 
[993ms] Initialization complete!
[1025ms] INFO: Pico Voltage: 3.276V.

I've also taken this to the BlueSCSI Discord where a mod there shared an experimental firmware for me to try, but with no luck.

I have tried Cyo's image, as well as using CaptainYS bootloader to map drive letters. I cannot boot the HDD, nor browse it in TownsOS. In fact, Cyo spent some time attempting to troubleshoot this with me, but to no avail.

I also tried creating an empty file and placing it on the BlueSCSI's microSD card in hopes of formatting and partitioning it in TownsOS. My plan was to simple install TownsOS myself, along with creating extra partitions. However, I see the same generic error messages as I did when trying Cyo's image. Meanwhile, this same method works fine in Tsugaru.

I can only assume one of the following things is true...

• BlueSCSI v2 is incompatible with the 20F, though a user on the FMT Discord showed me that it does work with their UX20.
• BlueSCSI v2 requires special configuration options for the 20F, though I've yet to uncover them.
• My 20F is broken in some way.
• I am being an idiot and doing something terribly wrong.

All of that being said, I figured I'd make this post in the hopes that someone out there with a v2 unit has been down this road and knows what I need to remedy my problem. It appears the v1 units work perfectly fine with the 20F, though they're no longer being sold as pre-built kits (though of course one can make one themself). However, before exploring alternative devices, I wanted to ensure I did every ounce of due diligence on this v2 unit.

Thank you in advance to all who read this!

Just published the source files on my github repo, for who want to build himself the emulator:
https://github.com/aotta/X68KFDPi2W

Still missing write to floppy support, but maybe in future...

Further progress... added HFE support and confirmed front buttons and leds are working:


Now the board is pending aside the drive case, but i'll add a 3D printed socket to fix it into the metal shield.


buttons and led are replicated in the board for external use, or can be connected to the original X68K connector for best result when mounted internally

I don' know why i got a "missing keyboard" error in First Queen, may be my arduino adapter is not supported..

I think it's almost finished, i had encountered several trouble in adding writing support to floppy images so i'm not sure i'll go further. Now i'm completing the feature for having a "default" floppies inserted at boot.

Ha, thanks. Now I'm wondering what I even tested there.