Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by wierd_w

  1. That is like a tarot card's The Tower... Both imply it will hurt a LOT when it falls on you.
  2. I have done some initial testing, and I can get the arch package for that minimalist GTK based graphic default sound device selection app shoehorned in. (it's basically just a gzipped tar, containing a python script and some support libs) The issue I have, is that my chromebook has....... "Nonstandard" ..... audio hardware, that needs a special firmware blob. I am thinking I will need to integrate audio firmware in the image as well. A dirty kludge could be to use TTY2 as another GUI panel, with the sound picker running. Then use TTY3 for the root console.
  3. The intent with the large number of latches was more to catch the returns of many connected devices after switching focus. The idea was to get the most bang out of the slow speed of the bus, by not requiring focus to catch the last written byte. You can fire off a transaction then switch focus to the next device, and the buffer will catch the device's response, while you work with the next device on the chain. The intent was more like with HomeAutomation's love for talking with sensors. He could fire off a queue of "Give me the temperatures in all the rooms" outputs, the sensors all respond, then he can collect and handle the returns sequentially, by moving the focus over the latched returns. Otherwise, he has to do a full transaction sequence with each sensor.
  4. (reminded of the damage in shipping my PBox suffered.)
  5. But you would have to add a great big pin header to the ubergrom, and route it out of the shell! Otherwise you wouldn't be able to connect the 2-wire interfaces for the SPI devices. Does the UberGrom's micro have that much GPIO free? A GROM has 256 positions in its address stack, so the device would be able to specify and then work with 256 connected devices. That is a lot of GPIO to expose. At the absolute minimum, you would need a breakout that expands out to 512 pins; that means it has 10pins of GPIO, with 8 bits of "Select logic" wires, then 2 bits of SPI pass-through in the ubergrom's micro. You would need an additional 2 bits to get "SPI bus status bits passthrough" as well, if you bother to implement it. IDEALLY, there would be latch buffers for ALL 256 devices, all independent from each other, so that the SPI devices can communicate with the interface multiplexer, and have their messages caught, without having to have focus. I do not think the uberGROM could do that. (The cartridge would be rather large. Thankfully, the "coffee warmer" area is rather large, so a very long, and tall cart is doable.)
  6. Ok... A cartridge that: Exposes a GROM address, as a GRAM, that is in actuality an SPI array, running at a slow speed, with a latch buffer. Each byte location on the GROM represents a different SPI device, and its control wire values. The cartridge contains some GPL handler code that can be either called by assembler programs or from the built in BASIC. The latch circuits catch bursts from the much faster spi devices and hold them for later manipulation by the TI. General Idea: each GROM address stack position returns 1 byte to the TI, like expected. That byte should be treated like a bitfield, with bits set to "select high/low nibble", "transmit latched byte", and then SPI control wire statuses on the other two, followed by the 4bits of nibble. Each byte location on the GRAM is a distinct SPI device. The cart contains TTL logic that translates serial SPI into parallel bytes and back again. This would allow the TI to interface with a rather large number of devices, and do so in an out of the way manner. It would be slow as hell, but sufficient for serial consoles, small LCD indicators, low bandwidth sensors, etc.
  7. Just try the -jar option anyway. The worst that will happen is it says unknown argument or something. If push comes to shove, you can extract the .jar into a folder, read the manifest file for the main class file, then invoke on that class file on the extracted archive.
  8. With windows running: Click the start button. Choose run Type "command.com" in the run box. This will spawn a dos shell window. This is distinct from an actual dos session because WOW is running, and various services can be called from the virtual dos shell environment that cannot be called in real dos. This ancient version of JAVA makes use of those services, so it can get access to virtual memory and pals. Use it to invoke the executable. It will let your command line switches stay in the window for you to read. Normally, you call the runtime interpreter with the -jar switch, and pass it the name of the java jar file you want to run.
  9. I would be of the suspicion that MAME is just not capturing a mouse input device.
  10. That is handy. It was getting irritating wading through the sea of PulseAudio posts. This section is potentially useful: After calling alsacfg -init, I can get output from amixer or aplay -L, grep it for "speaker", "analog", etc... then set the variable with an export notation. However, they also have a very appealing looking "Hyper minimal" gui program... It just has python and GTK+ as dependencies (which as far as I can tell, MAME shares anyway). I could pull the source and compile it as an installable .deb, and install it with dpkg. I would need a way to invoke it from the root console though...
  11. Not really. That how-to uses pulse-audio, which is ANOTHER audio framework on Linux. (Others being OSS, and Jack) Pulse provides what it calls "Sinks", which are actually pseudo-devices, that grab hold of an ALSA device back end. It is basically a broker, but can also do filtering and such. It is very useful for a full desktop linux. However, the minimalist debian I am using does not configure pulse, and configuring pulse without a graphical tool is not pleasant or fun. It would simply be easier to just tell ALSA which card and device to use as the default audio device for PCM output, and call it a day. Throwing an endless litany of more and more layers of obfuscation on is not how you make something SIMPLER. As is, I just need to walk through some verbose text output from amixer, filter it with grep for "analog" and 'headphone', notate which card and device ID that is, then instruct alsacfg to init that as the default. I can accomplish that with a shell script. Adding all kinds of bloat for a GUI, when one of the design goals for the project is "No GUI other than MAME!!", is counter-intuitive.
  12. It's been a whole day, I should give an update. I am disappointed. ALSA initializes, but it always wants to init the WRONG CARD as the default sound source. (Specifically, it ALWAYS wants to init the hdmi audio output, instead of the internal analog speakers or headphones) This is on 100% of systems I have tested. (though the sample size *IS* limited.. I am not made of money yo.) I am going to have to invest in some smart initialization voodoo to make this work as intended, where I use amixer to get a return of all detected devices, pass it through some fancy grep and awk voodoo to select the device for analog output, set that as default, init AGAIN, and **THEN** test. That is here I am currently at. It will take me awhile to write and test a robust init shell mini program, and shoehorn that into my "runmame.sh" invoke script. Unless of course, you want to just pass the buck off to the user, tell them to use the OSD, and select the sound device there somehow. (have not checked if MAME lets you do that.)
  13. Are there any games or programs on that mdos hard disk image that produce sound? I want to properly test MAME audio output with real hardware.
  14. Success! I have, since making this vid, found that ALSA was not initializing correctly, and have added some instructions to reset alsa, set volume 100%, unmute, then test sound playback with a sample wav file before starting MAME.
  15. I have made an x64 (EFI) version now. Testing on real iron. (the hacked chromebook only supports 64bit, with uefi)
  16. OK, I don't know if it fixes the race condition completely, but echoing a silly limerick to /dev/null one line at a time seems to introduce sufficient delay to have it not happen in my VM anymore. Waiting a full second before starting the window manager is heavy handed, so I want to avoid that if possible.
  17. Note, to get to tty2, press ctrl + alt + F2 That will switch to virtual terminal 2, which should be waiting at a login prompt. You can log in as root there. password is 'genevian' Mame can keep running in tty1. To get back to tty1, do the same sequence, but with F1 instead. This is useful for making changes.
  18. I have noticed that sometimes it burps like that, and sometimes it does not. I am thinking I should put a "sleep 1" in the .xinitrc file before exec twm. It is not consistent; usually it just starts.
  19. No, trust me, it is not. Did you tell rufus "all files"? If you REALLY think it is needed though.... Genevian_Build_2.vmdk
  20. Well.. My i5 laptop is (and always has been) picky about what USB devices it will boot from. Refuses to start the stick I just made. (had to drive to town to get some, and not driving back again just because this computer is picky) SO, I decided "Hey, lets go SUPER OLD!", and dug out my Fujitsu Lifebook E2000. It's an old "Windows XP era" laptop. It is laughably old. Specs: Pentium 4, single core, ~2ghz, netburst arch 1gb RAM ATI m340 video SigmaTel integrated ac97 audio ALI pci chipset, IDE disk controller (ata 100) cardbus slots USB2.0 rear panel connector. Broadcom B43xx based wifi (wireless G) (bonus)-- Hardware RS232 and LPT ports on rear panel Now; It TOO has issues booting from USB (because it is old as hell), but since it has a dvd drive baked in, I can start it with plopboot, and then boot it from USB that way. So I did. Since the USB controller is ancient, it has "issues", and has to be put in 1.1 mode to boot from plopboot... So, initial loading of the initrd is painfully slow. BUT, then the system starts, and linux mounts volumes with its native USB2.0 drivers. X loads and then so does MAME. It runs like it has a concrete enema. Switching to tty2 with the key combo, I log in as root, and see how loaded the system is. Sure enough, the CPU is beating itself to death at 100% saturation. I try to run tetris from mdos, in the mdosgames folder. I laugh and cry, as I watch it slowly draw the splash screen. Gameplay is laughably poor. (I note that necessary firmware to enable gpu acceleration is not present, but meh) HOWEVER, IT BOOTED, and technically "Works". I switch back to tty2, and gracefully down the system. Now, as hilarious as this is, other people SURELY have something that is both newer, AND stronger in the knees than this lifebook that they can test this image with. Remember, this was built specifically for "Older" laptops, that have a normal BIOS (not UEFI), and is a 32bit flavor OS. I am thinking "windows 7 era" laptops here, with dual or quad core processors. It will not work on a "UEFI ONLY" modern system. I will have to build a UEFI bootable version for newer units. If/when I do that, I will use a 64bit base system. I am zipping up the image now. Since it is a full base debian system, it will be about 600mb in size zipped. You will need a 16gb or so sized flash drive, and rufus. For completeness, the root password is 'genevian' DO NOT reformat the fat32 volume. There is an important reason for this: Linux can either mount a filesystem based on its hardware node ("/dev/sda1" for example), or by the GUID of the filesystem (which is generated at format). Since this is meant to run "God only knows where", and get booted "God only knows how", I have the /etc/fstab entries all calling file systems by GUID entries. If you reformat the FAT32 volume, it will no longer mount on boot. I will provide instructions on how to grow the FAT32 volume to fill the rest of a thumbdrive later. Just remember, DO NOT FORMAT IT. Genevian_Build_2-flat.7z To write it to a USB device: On windows, use rufus. Select the vmdk file (after changing type to all files), and write it to the drive. When it is done, it should work as a bootable device. Windows successfully mounts the FAT32 volume, and ignores the 2.5gb EXT4 volume linux lives on. This should let people easily get at the disk images. On linux, use dd to copy the flat image over. While the extension is vmdk, it is really just a flat, boring image inside. It is partitioned with a 2.5gb EXT4 bootable volume, then a ~6gb FAT32 volume. The fat32 volume should be capable of being extended to fill whatever medium you write the image onto. Quality of life, totally optional things to do: Configure GRUB to display a fancy splash screen or something until X starts.
  21. OK. I have rebuilt it again, this time with the FAT32 partition mounted, to contain the disk images. It now autoboots as the genevian user, and autostarts genmod on TTY1. The image is ~8gb in size, but is mostly empty space. I will begin testing on real iron using a RUFUS burned usb stick.
  22. I ham-fisted some ubuntu .deb files (yes, this is not recommended) in to get a recent mame. (.226) Had to give a few ubuntu support file .debs along with it to make it install via dpkg. (libjpeg8, libjpeg8-turbo, multiarch-support) Seems to work though. Seems to not make my laptop's fans blare instantly to life in the VM also. Must be some quality/performance fixes in the later version. Since this is not a recommended course of action, I will NOT detail how to do that here. Onward and upward-- time to get rid of the grub timer.
  23. OK. First, I am using oracle virtualbox, because it does virtualization, is free, and can produce flat vmdk files. (I can use qemu tools package to convert the resulting disk image into a flat image suitable for use with RUFUS, for writing to a USB stick and using on real iron.) Steps to reproduce: 1) Install virtualbox 2) Download the latest stable debian net-install cd image. (i386 iso, amd64 iso) 3) Create a new virtual machine, and specify that it is debian, and what flavor. (i386 or x64) 4) Configure the VM to use the downloaded net install CD iso as the boot device. 5) Boot the ISO, use text mode installation, go through the install process, DO NOT install a GUI. Allow it to install GRUB2 on the virtual disk drive. 6) VM will reboot, and boot from the hard disk. Log in as the root user. (the limited user will not have sudoers access yet!) 7) Install some necessary packages. apt-get install xorg sudo twm mame zram-tools cifs-utils 8 ) Set your limited user (created during installation wizard process) up for sudo access. /sbin/usermod -aG sudo {LimitedUserName} 9) Configure sudo so that permitted users dont have to use a password to issue the poweroff command. Edit the following file with nano (or whatever editor you like most) nano /etc/sudoers Look for this area, and add the highlighted line. 10) Create an invocation shell script that will start mame, then do a poweroff. This is what we will have .xinitrc run before twm, with forked invocation. I put it in the limited user's home directory, in a folder called .scripts, and named it runmame.sh . It looks like this inside, (since it contains all your special invocation voodoo) #!/bin/bash mame genmod -skip_gameinfo -peb:slot4 speech -peb:slot6 tirs232 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 /home/genevian/.shared/mame/disks/BOOTDISK3.hd sudo poweroff 11) Make the script executable and readable/editable by everyone. chmod 777 runmame.sh 12) Edit the limited user's .xinitrc file, so that it looks like this inside. 13) Edit the limited user's .bashrc file, go to the VEEEEEEERY bottom, and add this line: startx so that it looks like this inside. 14) copy the rom files into the correct location at /usr/local/share/games/mame/roms I accomplished this using a CIFS (windows file share) mount. I did this by mounting my NAS. To do that, you need a place to mount the file system ON first. Historically, this is done on /mnt. mkdir /mnt/cifs Then you mount it. mount -t cifs // /mnt/cifs It will ask for the windows share password. Give it, press enter. Boom, you now have that network device mounted and can copy files to/from it. cp -r /mnt/cifs/geneve/roms/*.* /usr/local/share/games/mame/roms get an ls -ll on that location, so you are sure they copied. 15) Copy the disk images over similarly, but put them in an appropriate place in the limited user's home directory, then give the limited user ownership of them with chown. 16) TEST!! Exit out of the root user account with exit. exit Then log in as the limited user. It should IMMEDIATELY start xwindows, and the geneve emulation. (and that is where I am at right now.)
  24. Yes. It is running on the distro's stock version of MAME. The stock version lacked the rom data needed for doing this, but hloberg posted a different set of archives for windows, that contain the rom zip files. I put them in the correct location (/usr/local/share/games/mame/roms), and things seem to just work.
  25. OK, it makes my crappy i5 laptop hum quite bad running in the VM, but the VM starts the genmod emulation and boots mdos now. I enabled support for mounting windows file shares. (was how I got the data into the vm's disk image) Created a folder in /mnt called cifs. (legacy name for windows file share tech) For those with NAS boxes, this could be used to mount their NAS. The utility of this should be clearly apparent. Disk images are stored in /home/genevian/.shared/mame/disks ini folder, with copied ti99 config ini files, located in /home/genevian/.shared/mame/ini (has subfolders for games and cart; How to tell mame to use this location is another matter however.) I have never messed with setting up MAME this way before, I just lifted all the invocation from hloberg's archive, and did unix style path translations and corrections where appropriate. Observe For utility reasons, it might be beneficial to create a FAT32 partition, move disk images there, and have the system automatically mount that partition in the ~/.shared/mame location, then move all the disk images and config files THERE. That way windows loving kids can put the stick in a windows machine, and use the tools there on the images.
  • Create New...