Jump to content

EricBall

Members
  • Content Count

    2,379
  • Joined

  • Last visited

Everything posted by EricBall

  1. This past Christmas I bought an N64 for my son (and me) to enjoy my collection of games. (Although the problem turned out to be dirty cartridges rather than a dead N64.) He's been having a blast playing Super Mario 64 and the Mario Party games. This nostalgia rekindled my interest in what is under the hood of both it and the original PlayStation. It turns out there's a lot of similarities between the two, more than I would have expected. Both used a MIPS CPU (PSX: 32bit R3051 @ 33.8688 MHz, N64: 64bit R4300 @ 93.75MHz), both have a vector coprocessor (PSX: Geometry Transformation Engine, N64: Reality Signal Processor) and a graphics / triangle / texture processor. Of course there are the obvious differences too. The N64 is cartridge based, while the PSX is CD based. The PSX has a macroblock decoder for video decompression. The PSX GTE is integrated with the CPU (similar to the old 80x87 math coprocessors), while the N64 RSP has dedicated instruction & data RAM (like the SPEs in the PS3 Cell processor). The N64 has 4MB of main memory (500MB/s) while the PSX has 2MB of main memory (132MB/s) plus 1MB of memory dedicated to the GPU and 512K of memory dedicated to the sound processor. And even though the N64 had better "numbers" (e.g. CPU clock) than the PSX, Sony sold three times as many PlayStations as Nintendo sold N64s. And I have some theories why: First, Sony released the PlayStation 20 months before Nintendo released the N64, which gave them definite traction in the marketplace. The N64 launch library was also very thin (no matter how good SM64 was). Developers could already see the "virtuous cycle" starting with the PlayStation. Second, Sony's decision to use CDs (an easy decision for them given they helped invent CDs) and Nintendo's decision to stick with cartridges had a huge impact for multiple reasons CDs allowed developers to store more - more game content and/or prerecorded audio & video (which the built-in decoder enabled) lower manufacturing cost, it cost much less to press a CD than to manufacture a cartridge so higher profit per sale at a given price I heard that one of the reasons Nintendo stuck with cartridges is Nintendo did all of the manufacturing (charging publishers up front for runs of cartridges to boot), whereas the PlayStation CD could be replicated by nearly anyone who could press CDs. [*]Third, while Nintendo provided developers with C libraries, they didn't provide any low level details. And the provided graphics libraries were much slower than the "numbers" would suggest. So unless you were willing to spend a lot of time & effort reverse-engineering the libraries (e.g. Rare & Factor 5), it wasn't possible to fully exploit the N64 hardware and work around limitations. On the other hand, early third party developer Naughty Dog was able to leverage the PlayStation hardware at a very low level. [*]Finally, although the unified memory on the N64 allowed the CPU & RSP to update the frame buffer (which causes problems with emulators today), I suspect this caused bottlenecks in memory access (especially random access due to the latency of the Rambus memory).
  2. Back in 2009-ish when the transition to HDTV occurred, I built a high gain UHF antenna and used it for a while. But once I got a Rogers HDTV PVR* there hasn't been any point - unless I want to watch the US Superbowl commercials. (I already subscribed to cable to get the premium sports channels.) Unfortunately, there's a lot of misinformation about HDTV and antennas floating around out there and a lot of "HDTV antennas" are more style than substance (i.e. they are good looking junk). However, while the signal has changed from analog to digital, radio waves are still radio waves - so the basics of antennas haven't changed in 80+ years of television broadcasting. Reception follows some simple rules: 1. Height improves reception, outdoors is better than indoors 2. Bigger antennas have better reception, but are more directional 3. Better design, materials & build = better reception Also, a good preamp (mounted at the antenna) helps with long cable & splitter loss & noise but doesn’t actually improve reception. Some links to websites which help with getting more out of your antenna: Reception info: http://www.tvfool.com Map with antenna aiming: http://www.sjmillerconsultants.com/ota/ For all kinds of info on OTA, including building your own antenna visit http://www.digitalhome.ca/forum/forumdisplay.php?f=81 * I originally got the HD PVR as compensation when Rogers made my dual-tuner TiVo less useful by moving the majority of their SD channels to digital. Since then the majority of channels have moved to HD-only and I've bought three refurbished HD PVRs and added an external drive to one of them.
  3. Over Christmas we watched all of the Star Wars movies (in story order) before going to see Last Jedi. One of the things I liked about Last Jedi is how many of the plot points didn't take the easy & predictable ending. There were lots of times where I thought, "that isn't what I expected". Can someone explain why Vice Admiral Amilyn Holdo didn't reveal her escape plan to Poe? Not doing so makes it seem like she had no plan, which kicked off the whole Finn / Rose stoyline that ultimately resulted in the First Order learning of the plan. And while I could nit-pick the film to death, it was a decent addition to the Star Wars films - certainly better than it's immediate predecessor and in the top half of the list. It will be interesting to see where the story goes from here as the Rebel Alliance tries to recover from being effectively wiped out from a military perspective.
  4. (See previous entries for more info on the game.) It's surprising what a little motivation and enthusiasm can accomplish. One big help was I reached out to YouTuber Torogadude and asked if I could use his compositions as background music and he agreed. Bonus! I've also added sound effects and knocked a lot of other items off my to-do list, which leaves really only three big ones: Revise the embedded HTML "About" pages and try to fix the back navigation so it goes to the previous page rather than the back to the main menu. Also update slidetiltroll.walkerville123.ca to match Review the Apple Guidelines to make sure there isn't anything I need to do before I submit it. Do a code walkthrough and tweak / fix as required
  5. I'd disagree with that. Nearly all of my employer's corporate apps (e.g. the apps they tell me to use as part of my job) are browser based, or have browser versions. Yes, my corporate laptop runs Windows 10, but I could probably do my job just as well with a MacBook and possibly even with a tablet. Kinda like that iPad Pro commercial - is it a computer or something else and does it really matter?
  6. I'm back to working on my iOS game "Slide Tilt Roll" in preparation to using it for a presentation to some computer students at my son's high school. I updated the MacBook to High Sierra, updated to XCode 9, installed XCode 8 to upgrade the code base from Swift 2.2 to Swift 3.0, then used XCode 9 to bring it up to Swift 4.0. That worked for 90% of the code, then I needed to go through and manually fix a few errors and warnings (mostly confined to sqlite and CGPath functions). I've also tweaked the launch and main page backgrounds to display better on the iPhone X - I wonder if I can use one of them at the Apple Store for a quick test The next big thing is to add sound effects and music. I've found a paper for some algorithmically generated music which will I will hopefully be able to use. I'm still looking for anyone willing to create levels to supplement the ones I have created programatically. Interested? You need an iPhone, iPad or iPod Touch running iOS 9 or later (configured to send email) and a willingness to create levels gratis for my 100% free application. In order to install my app I need the UDID for your device. This can be obtained from iTunes by clicking on the Serial Number on the device Summary panel, then right clicking on the hex digit string, selecting copy, and sending it to me via PM. (If you don't have iTunes, you can get it by plugging into a computer and looking at the USB device information. Ask, and I'll provide instructions. Any other methods (websites, apps) are either outdated or extremely suspect.) After I get your UDID I will update my Apple Developer account device list and send you the link to download and install. Muchas gracias Merci beaucoup Vielen Dank
  7. Yep, I was about to give you that link, but you beat me to it. It really comes down to how much CPU time is available. While the 7800 GPU is capable of displaying more sprites (total and per line) than the NES PPU, each 7800 sprite requires a significant number of CPU cycles to move around the screen, whereas on the NES the CPU cycles are trivial. Then to make matters worse, because of the unified memory the 7800 CPU loses even more cycles for each sprite & tile displayed.
  8. One of the trickier parts of programming the 7800 is working through the 7800 graphics modes and how to map colors to sprite data, particularly for the 320 modes. Although I've given this info before (except for 320D), I'm hoping that the following will be useful to anyone wanting to program the 7800 or hack existing games. 2019-05-29 I have attached a spreadsheet which breaks down this data into a (hopefully) more usable form. 160A (WM=0,RM1=0,RM0=0) 2 bits per pixel, 3 colors + background/transparent from 8 palettes D7531 D6420 palette = P2 P1 P0 0 0 BG / transparent 0 1 C1 1 0 C2 1 1 C3 160B (WM=1,RM1=0,RM0=0) 4 bits per pixel, 12 colors + background/transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0-3, P2=1 : palette 4 -7 0 0 0 0 BG / transparent 0 1 0 0 P04 C1 1 0 0 0 P04 C2 1 1 0 0 P04 C3 0 0 0 1 BG / transparent 0 1 0 1 P15 C1 1 0 0 1 P15 C2 1 1 0 1 P15 C3 0 0 1 0 BG / transparent 0 1 1 0 P26 C1 1 0 1 0 P26 C2 1 1 1 0 P26 C3 0 0 1 1 BG / transparent 0 1 1 1 P37 C1 1 0 1 1 P37 C2 1 1 1 1 P37 C3 320A (WM=0,RM1=1,RM0=1) 1 bit per pixel, 1 color + background & transparent from 8 palettes D7531 D6420 palette = P2 P1 P0 0 0 BG + BG / transparent 0 1 BG + C2 1 0 C2 + BG 1 1 C2 + C2 320B (WM=1,RM1=1,RM0=0) 2 bits per pixel, 3 colors + background & transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0 P2=1 : palette 4 0 0 0 0 BG + BG / transparent 0 0 0 1 BG + C1 / transparent 0 1 0 0 BG + C2 0 1 0 1 BG + C3 0 0 1 0 C1 + BG / transparent 0 0 1 1 C1 + C1 / transparent 0 1 1 0 C1 + C2 0 1 1 1 C1 + C3 1 0 0 0 C2 + BG 1 0 0 1 C2 + C1 1 1 0 0 C2 + C2 1 1 0 1 C2 + C3 1 0 1 0 C3 + BG 1 0 1 1 C3 + C1 1 1 1 0 C3 + C2 1 1 1 1 C3 + C3 320C (WM=1,RM1=1,RM0=1) 2 bits per pixel, 4 colors + background & transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0-3, P2=1 : palette 4 -7 0 0 0 0 BG + BG / transparent 0 1 0 0 P04 BG + C2 1 0 0 0 P04 C2 + BG 1 1 0 0 P04 C2 + C2 0 0 0 1 BG + BG / transparent 0 1 0 1 P15 BG + C2 1 0 0 1 P15 C2 + BG 1 1 0 1 P15 C2 + C2 0 0 1 0 BG + BG / transparent 0 1 1 0 P26 BG + C2 1 0 1 0 P26 C2 + BG 1 1 1 0 P26 C2 + C2 0 0 1 1 BG + BG / transparent 0 1 1 1 P37 BG + C2 1 0 1 1 P37 C2 + BG 1 1 1 1 P37 C2 + C2 320D (WM=0,RM1=1,RM0=0) 1 bit per pixel, 3 colors + background & transparent from 2 palettes P1 P0 D7531 D6420 P2=0 : palette 0 P2=1 : palette 4 0 0 0 0 BG + BG / transparent 0 0 1 0 C2 + BG 0 0 0 1 BG + C2 0 0 1 1 C2 + C2 0 1 0 0 BG + C1 / transparent 0 1 0 1 BG + C3 0 1 1 0 C2 + C1 0 1 1 1 C2 + C3 1 0 0 0 C1 + BG / transparent 1 0 0 1 C1 + C2 1 0 1 0 C3 + BG 1 0 1 1 C3 + C2 1 1 0 0 C1 + C1 / transparent 1 1 0 1 C1 + C3 1 1 1 0 C3 + C1 1 1 1 1 C3 + C3 MARIA.zip
  9. Just a suggestion - don't put the cart (graphics) before the horse (code). In addition to the size of the sprites, the artist is going to need to know the graphics mode / palette. And for anything other than static sprites, they are going to want to know something about how the sprites move and need to be animated. ROM space might also be a factor. You can do a lot of coding with temporary sprites and be in a much better position to know what you need the artist to provide and the limitations they must work inside.
  10. Awesome Video Game Data 2017 Based on the data, I'd say console still has life for a couple more years. As long as there's money to be made, consoles will still exist.
  11. There's no problem using a POKEY (or any other chip which drives the cartridge audio pin) and the TIA at the same time. The problem is updating the TIA at a high enough frequency to make any sampled audio worth it. Updating the TIA once per frame (60Hz) is trivial, but after that it gets considerably harder. You could use the DLL NMI to update it once per zone, i.e. every 8 lines = 1967Hz or every 16 lines = 983Hz, but you will have to adjust for 23 lines of VBLANK. Similarly, you could bang on WSYNC and update the TIA every line (15,734 Hz), but that will waste a lot of CPU time and you'll still have to handle VBLANK (unless you're only playing music). Note: 2 or 4 bit won't make any difference except for how much ROM space the samples use. You will also need to consider how much CPU the update routine will require. I'd recommend seeing if the native TIA waveforms can provide any of the sound effects and update the TIA once per frame.
  12. Whether a games platform lives or dies depends on whether it can build and maintain what I call the "virtuous cycle". Developers want to create games for platforms where there are a large number of consumers who are likley to buy the game. Consumers buy game platforms which have games they want to buy and play. The more people who have the platform, the more developers are likely to create games for that platform and the more games for the platform, the more consumers are likely to buy into the platform. However, the mobile platforms, cross platform development and freemium pricing models has broken this idea. People no longer have to buy into a gaming platform because they already bought into it for other reasons. Freemium pricing models also drop the cost to consumers to play games, although developers suffer because more people playing doesn't mean more people paying. Consoles largely can't compete in this space. Why pay hundreds of dollars for a console instead of using the mobile device you already have? Why pay $60 for a game when there's a huge library of "free to play" games? Consoles can only compete by offering complex, big-screen games which mobile can't, i.e. competing with PC gaming. And as HoshiChiri notes, the one advantage consoles have over PCs is uniformity. Consumers can buy games knowing they will work and developers can develop for a single target. Developers also like that consoles are more locked down than PCs, which helps prevent privacy and cheating. Unfortunately, developing those complex, big-screen games has a very high up-front cost, which puts it out of reach of a lot of developers and increases the downside if a game doesn't sell well. Without enough developers creating possible system sellers, consumers aren't going to buy the consoles, and the "virtuous circle" collapses. Maybe consoles will become like iPhones - periodically Sony and Microsoft will release the next generation of the Playstation and XBox, like the PS4Pro and XBox One S&X, which maintains backwards & forwards software compatibility while providing more CPU & GPU power for games to tap into and graphics improvements like 4K & HDR. Or maybe consoles will move to the cloud, e.g. OnLive style gaming.
  13. And as someone who has programmed for both the 2600 & 7800, I agree with Kosmic Stardust - start from scratch. Have a look at your A8 code - how much of it is concerned with setting up the ANTIC display lists? Throw that out; MARIA display lists are radically different from ANTIC display lists. Next, how much of the remaining code is designed to make the code you just threw out easier / better? Throw that out too, you'll need to redo that code to make the code to set up the MARIA display lists easier . Sound? Throw it out, you only have a TIA (2 channels & half the frequency resolution). Controllers? Throw it out - different controllers and digital instead of analog. Graphics data? Throw it out; MARIA does 4+ colors per pixel. Collision detection? Throw it out, the 7800 doesn't have collision detection registers. Now, take a look, how much code is left? Is any of it worth saving or are you better off starting off with a clean page (and maybe even using 7800 Basic). At one point I did a write-up on the 7800 versus the 5200 : https://sites.google.com/site/atari7800wiki/atari-5200 which might help you as a starting point.
  14. You'd think at some point the lenders would start to question whether they were ever going to get paid and stop throwing good money after bad.
  15. Define "higher quality". The TIA (and POKEY for that matter) are simple LFSR based waveform generators. From a programming perspective there are three inputs for each of the two channels: AUDF, a 5 bit divisor of 2 * the horizontal retrace frequency AUDC, a 4 bit LFSR selector, which controls the AUDF frequency to waveform AUDV, is a 4 bit volume control of the waveform output The problem is these values are hard coded into the game ROM. So even if you added an extra bit into one of the registers, the games wouldn't be able to use it. What you could do is tap the output TIA audio output pins (12 & 13) and put them through a high quality amplifier / filter. This will also expose some "stereo" effects in some games.
  16. Two controllers work fine. My son and I played some 2 player Joust and Super Mario Kart (slow). As for it being underpowered, it really depends upon your expectations. Will it play a lot of games from the 8 & 16 bit generations - YES. Will it play every game perfectly - NO. Also, while Lakka tries to be easy to use, there are areas where it's not there yet. So expect to have to do some forum/doc/Google research and stuff from the command line.
  17. I now have MAME (2003 - 0.78) up and running, woot! I've loaded up "the best of" from pre-1986, now I need to figure out how to set the controls beyond the defaults. This also means I can play the originals rather than the console ports. I'm also working on getting Colecovision running. I've created a script which creates a playlist from a directory of zip'd ROMs, as Lakka doesn't seem to auto recognize them. Unfortunately, the CV emulator is also the MSX emulator, so I need to figure out how to put it into CV mode while not impacting the MSX ROMS. Hopefully I can use symbolic links to create a separate configuration. I've also discovered some additional ROM collections on the MAME DVD sets I have from back in the day. Lakka also includes a bunch of emulators which I haven't tried out yet, including SCUMM VM for playing various point & click adventure games. I wonder if I have Leisure Suit Larry on my historical backup drive.
  18. To blank the beam you set the intensity to zero - which is probably impossible for an O-scope if it doesn't have that as an input. Although if you move the beam really, really fast it might not show up as much.
  19. What you could do is have one of the bits select between two sample & hold circuits. So while X is passing through the DAC output, Y is holding the previous value & vice-versa. Then you would have 128 levels. Or instead of having the DAC drive the channels directly, you put them through an integrator. Then instead of X, Y you're generating dX/dY and potentially much higher resolution. dX/dY also requires some way of generating negative input to the integrator and it also helps to have a way to zero the integrators. If you're interested, try and find a document titled something like "the secret life of vector generators", or have a look at the Vectrex for how it generated a display.
  20. Other quirks: 1. Some settings require a clean shutdown to save and/or take effect. 2. Lakka uses circle for OK and cross for cancel - there's a option in Settings to reverse this. 3. The default core for SNES is snes9x-2002, which might be better for performance, but is bad for compatibility (graphics glitches with Super Mario RPG, controls don't work with Donkey Kong Country), changing to snes9x-2010 resolves them. 4. I'm still trying to get bluemsx working. A kind soul provided the files which bluemsx reuqires so I now have MSX & MSX2 working. I need to do some testing then update the Lakka wiki with a better how-to. Colecovision ROMs aren't being recognized.
  21. Ingredients: Bought: Raspberry Pi Zero W, Pro: cheap at C$13.50 (+tax & shipping, case C$6), tiny (65mmx30mm), low power (powered via USB on TV), WiFi & Bluetooth (for controllers). Con: can only handle 8 bit & 16 bit gen consoles, miniature connectors require special cables (C$6) On-Hand: 4GB micro-SD card, HDMI cable (dollar store), micro USB cable (for power), PS3 controller For initial set up: PC (downloads etc), USB keyboard (to set WiFi passphrase), mini USB cable (for PS3 controller pairing), I decided to use Lakka. The other popular option is RetroPie. However, both use RetroArch / libretro for the actual emulation (which is also used by a lot of other current non-PC emulator suites). Lakka is done by the same people as RetroArch and seems to have a minimalist ethos; which I tend to prefer. RetroPie can do more than just RetroArch, but I've read that makes configuraton more complex. Getting the system up and running was a little rocky because the battery on the PS3 controller was dead - which made me think it wasn't connecting via Bluetooth. Before I realized that I charged up my son's 8bitdo NES30 Pro controller and got it connected - although that required SSH-ing into the box. Then it was a simple matter of loading up some Vectrex ROMs (which are usable legally), clicking "Scan" and then playing some rasterized vector games. The scanning process uses the No-Intro ROM database and automatically determines which console each ROM is for then puts them into a single list by platform. While uber-simple it does cause some issues, IMHO. The No-Intro database limits itself to perfect images of the commercial releases. So while this does exclude the huge number of hacked ROM images which other ROM sets include, it also excludes homebrews. It may also cause frustration if the easiest to find ROMs for a game aren't in the database. It also lacks any kind of organization - a must when several consoles have over a thousand titles. I started by hauling out my external backup drive and started to search for the ROMs I snarfed from USENET 25 years ago. I then took the original yencoded messages, dumped them in almost 100 separate directories (to avoid possible name collison) and extracted the files. After clean-up, I had some 6000 archives with over 9000 files. Fortunately, I was able to use clrmamepro to load up the No-Intro database and use the Rebuild function to scan through those archives for any matching ROMs and re-archive them to files usable in Lakka. (Unfortunately this requires about an hour per platform.) Of course that still leaves me with several thousand ROMs (although I'm missing some notables as my collection is mostly pre-1993). My solution is to use Wikipedia's lists of best selling video games to pull out the most popular titles and do some additional pruning by language and to remove duplicates.
  22. Personally, I'm going to pick up a RPi Zero W and put Lakka or RetroPie on it and sync it up to a Bluetooth controller. It should handle any 2600, NES or SMS game.
  23. Unfortunately working on Tempest never seems to come to mind when I have free time. I have, however, hooked up a rotated LCD so it's easier to work with out the cabinet. I'm glad you enjoy Skeleton. It still ranks up there on my list of personal achievements.
  24. https://arstechnica.com/gaming/2017/06/sega-forever-emulation-performance-problems/ For some reason I've never gotten into Sega's consoles. Sure I've played Sonic, but that's about it. However, when I heard about Sega Forever, I thought I might give it a try - watch a few ads, play a few games. But now I probably won't bother. The question for me is why Sega would release anything less than perfect. I have to conclude the decision makers at Sega don't care about their games, only about making money. Not to say that making money isn't important for a company, but I suspect Sega Forever will make less money than if they spent more money to release a better product. Instead of engaging players so they play more, and thus watch more ads, this poor product (with apparently heavy advertising) is more likely to turn players off - resulting in higher short term gains, but very little long term returns. I also suspect the difficulty of emulating consoles is not appreciated. The primitive CPUs and GPUs were tightly coupled and many games exploited this via cycle counting techniques. Reproducing this relationship, especially in devices which can vary considerably. Plus there's no easy way to "scale down" for lower performance devices.
×
×
  • Create New...