It's been a few years since I played with that circuit, but I recall if the RTC is not working correctly (e.g. it has been reset due to dead battery) then what you'll see when you plug in the computer is the system will turn on its own (instead of stay off and give you the red power LED)
While not a big deal, some people might want to connect peripherals, external drives, etc before powering on the computer.
SRAM replaced by FRAM is a good idea, and I would take it one step further. Install a battery holder with a zenor diode + 1K resistor. This will disable the charging circuit and allow you to use CR2032 batteries. CR2032 in this circuit will last for years to keep the RTC happy and system behaviour the same as before.
Last post by lucaspam - February 22, 2023, 11:30:25 AM
Hello There Everyone,
I've just picked up a PC 9821-V12, with almost 50MB of RAM and a soundcard that is identified as a YM-2203.
The computer came with an CF to IDE board, a 4GB card and I am assuming that a version of YAHDI (yet another hard disk image) is already installed on the CF.
The problem is, from the list of games that came already installed, only Rude Breaker seems to work fine. The other games crash and burn heavily upon loading. Rusty works roughly 30% of the all the times I've tried and stops working soon enough into the first stage. Flame Zapper doesn't produce any sound and Garudius is just a blurred mess on the screen - other games just run too fast.
The BIOS doesn't feature the option to lower CPU speed. Some games run very fast, then stop working with a terrible sound from the soundboard. I believe the CPU is just too fast. Is there any way to slow down the CPU? Some command perhaps?
I know this is a noob question, but I've searched the forum and found no user with a similar issue. Any help is appreciated. Thank you dearly for your attention!
Last post by claw - February 22, 2023, 10:01:57 AM
Another note on ZuluSCSI RP2040 with SASI machines - if you're using firmware v1.2.0 you'll probably find you cannot write anything to the HDD image. Any attempt to write yields a white box saying "write error". If you enable the ZuluSCSI debug log and try again you'll find a lot of parity check fails and CHECK_CONDITION "sense 0x00004700" errors on writes when you check the log file.
This happens because the ZuluSCSI expects to see a parity signal that SASI x68ks don't produce. They don't have a pin for it on their 20-pin HDD connectors, and without this signal the ZuluSCSI will constantly complain about parity errors. It'll ignore those errors on reads, but will fail on writes.
It can be fixed, though, if you're prepared to make a small change to the ZuluSCSI firmware and recompile it. All you need to do is change the line in scsi_accel_rp2040.cpp that reads:
if (0) (it's line 687 at time of writing) or comment out that whole condition. This disables the parity checking and allows writes to occur.
I've mentioned this to the ZuluSCSI devs so maybe we'll get a config option to turn off parity checking in a future release. If you found this post years later, you might wanna check if they already introduced a config option before modifying the code.
Last post by ymos16 - February 17, 2023, 08:13:02 AM
I'm using Zuluscsi V1.1 with FW 1.2.0 on a ACEHD and was getting Address & Bus errors but it was related to my 1mb ram expansion not making good contact with the motherboard. Gave both connectors a good clean, reseated and it's rock solid. I'm running V4 image with SP1 & SP2.
I would highly suggest you check your RAM also because of the address errors.