Old Computer Appreciation Thread

TPR

@Folly I'll try all this tonight. Thank you guys. And I think you might be right about having to scrap all my old MESS stuff and re-build with your newer one. I've just been reluctant to do that only because everything else seems to work, and you know what they say... if it ain't broke! lol

But now something broke!

I'll see what I can do!

Folly

@TPR

Any luck ?

TPR

@Folly @mitu So I have an update on this ADAM thing that I absolutely do not understand, and I'm hoping you guys could make some sense of it...

So I was testing out a new Retroflag case... popped a different Pi board into it... was testing some things... and all of a sudden I noticed... my DDP files are working!

WTF!?!?!

So I took my build out of that case, put it back into my other Pi board...

CRASHED! Back to ES again.

So now I had to further investigate...

Only things I have connected are my controller and hard drive that my ROMs are on.

Turns out, the board it keeps crashing on is a 1gb RAM board. I tested with all my other boards:

8gb board - Works.
4gb board - works
2gb board - works
1gb board - crashed
1gb board #2 - crashed (just to make sure)
1gb board #3 - Crashed (just to make REALLY sure!)

All the 1gb boards I have are newer... bought within the last year.

I have never heard of something not loading up with the 1gb board??? I mean, I'm full on running PSP games at amazing frame rates on the 1gb board but I can't get a Coleco ADAM game to run?

And why is it ONLY the .ddp data pack files?

Any idea how to fix this other than "don't use a 1gb board?" :P

Folly

@TPR

Very strange indeed.
Could it be the assigned memory in the /boot/config.txt ?

If I get a good idea about it I will post it to you.

TPR

@Folly Here is what is in my current config.txt

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=0

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
overscan_left=-50
overscan_right=-50
overscan_top=-35
overscan_bottom=-35

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=1
hdmi_mode=16

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
overscan_scale=1
dtoverlay=RetroFlag_pw_io.dtbo
enable_uart=1

Folly

@TPR

Looking at this doc, memory-split isn't used anymore by the pi4.
So that isn't something we can try and test.

If I have some time I will try adam on my pi3 which also has 1gb.
Perhaps that can give us an idea on where to look for the problem.

TPR

@Folly Awesome! Thank you!

Folly

@TPR

Seems my hunch is correct.

The pi3 suffers with the same problem.
Although the .ddp game will work sometimes probably due to the fact that sometimes it just has enough memory left.

I reduced the gpu memory in the raspi-config from 64mb to 32mb.
Tested the pitfall.ddp again and now it works.

The problem is that the pi4 seems to use a different approach with using the memory although you could give raspi-config a shot but that probably won't solve the problem.

Another solution I can think of is to add some swap memory or use zram.sh.

I still have an old script called zram.sh that I once found, you can try that on you own risk :

#!/bin/bash
cores=$(nproc --all)
modprobe zram num_devices=$cores

swapoff -a

totalmem=`free | grep -e "^Mem:" | awk '{print $2}'`
mem=$(( ($totalmem / $cores)* 1024 ))

core=0
while [ $core -lt $cores ]; do
  echo $mem > /sys/block/zram$core/disksize
  mkswap /dev/zram$core
  swapon -p 5 /dev/zram$core
  let core=core+1
done

Just run it with sudo bash zram.sh

With the command free you can see how much memory and swap-memory you have before and after running the script.

Notice that when you reboot your system zram isn't there anymore.
So if this solution works you have to run it every time after a bootup or you have to make it stick so every time it boots zram.sh is loaded.

I tested pitfall.ddp a couple of times (with zram enabled) and it seems to load every time now.

TPR

@Folly Wow! That is very interesting indeed! So is this the first thing on the RetroPie that doesn't run on a 1gb board? I've yet to find any other console that has an issue.

I'll try that script to see what it does, but I'm afraid it might break other things? So maybe I'll only use that when running ADAM .ddp files.

Folly

@TPR

Did it work ?