-
Posts
1,259 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Everything posted by cubanismo
-
Yeah, if you can find a fast 16-bit 8MB/64Mbit flash like the Skunkboard uses, an 8mb bank switched cart makes more sense as long as you can implement cheap bank switching logic. Otherwise you usually end up wasting 2mb with common flash sizes, no? And 16bit at double the speed is as good or better than 32bit at normal ROM speeds in theory. Edit: Extra points if you can design a PCB where you can build it as either a 6MB cartridge or a 8MB cartridge using the same flash chip, just by changing which components you solder down.
-
Yup. What could you possibly want to save beyond the top 10 scores? That's how video games worked in the 80s, so that's how they should work in the mid 90s too, right?
-
-
Sorry, wasn't trying to imply you should do this at a loss, and didn't know you made controllers in the past. I just doubled what I've seen controllers going for to get a naive estimate. Overall, I'm not a box guy but thought it'd be an interesting way to amortize costs.
-
I'm having some trouble testing the '-e' option, and '-uxr'. I had assumed usage like this would allow me to run T2K with an EEPROM where I'd previously saved game data: jaggd -rd -e "Tempest 2000.e2p" -uxr "Tempest 2000.j64" but the above always just reboots to a red screen of death. "Tempest 2000.e2p" is a file in the root directory of the SD card, and "Tempest 2000.j64" is a local file on my computer. If I break it out like this: jaggd -rd jaggd -e "Tempest 2000.e2p" jaggd -uxr "Tempest 2000.j64" Or this: jaggd -rd jaggd -u "Tempest 2000.j64" jaggd -e "Tempest 2000.e2p" jaggd -xr The game usually starts (Not always, still red screens quite often), but I don't see my EEPROM data (No high scores, no "keys" to start from). The same .e2p file works fine if I launch from the GD's menu. Am I misunderstanding how the EEPROM option works? In general, running multi-part commands like: jaggd -rd -uxr <romname> fails very frequently, as in more often than it works. The upload appears to succeed, but it just launches to a red screen of death. This is similar to the experience I had with my work-around "reboot" ROM posted earlier. Is there some instability in the file transfers or a race somewhere between finishing a transfer and executing the next command or something? I see a "Sleep(1500)" was added in the main program after a reset-to-stub operation, and a "Sleep(500)" after an upload command, but things still seem generally unstable unless I manually space commands out, and even that doesn't always help, so I'm concerned there's a general issue with the transfer robustness, some buffer being unflushed, or something of that nature lurking somewhere deeper, like in the firmware. As-is, the "execute via reboot" functionality isn't usable for me, and I can't figure out how the EEPROM stuff is supposed to work. Note launching ROMs from the SD card using the menu works 100% of the time, so the card in general seems reliable. The issues seem specific to the command line tools/USB path, which unfortunately is my main use case for the GD (rapid iterations while developing).
-
What you need to do is partner with someone selling rotary controllers to ship them in these boxes. *Then* I'd go in for some $17 flat-rate shipping on a, say, $70-80 controller + box 😁
-
Wipeout Source Released. Would be fun to have on the Jag.
cubanismo replied to alucardX's topic in Atari Jaguar
Yeah, there are a lot of us that would love to do this just for the thrill of trying it, but day jobs, family, other hobbies, etc. take up time. There would be moral hazard beyond just the likelihood of eventual success to do something like a Kickstarter, because for hobbyists it's hard to even say you can devote X hours to the goal, which is sort of what the people would be paying for as it's proposed here: developers' time. It also takes some of the fun out when you're beholden to backers. People in the immediate community are pretty polite about deadlines slipping and have had their expectations set realistically over the years, but it only takes one jerk on Kickstarter complaining their build isn't as promised or there haven't been blog updates this week to make the whole thing not at all fun anymore, and if they paid money, I wouldn't even really blame them. -
As far as I'm concerned, everything Id did up through Quake was black magic. Also, the palette magic used to make Quake 2 work with SW rendering are in the same league. The point @agradeneuwas making stands. It's virtually impossible to compare two systems (PC or otherwise) based on spec listings. I just wanted to point out that it wasn't quite as skewed as his post implied. The NES and the 8088 were contemporary tech. One needed crazy tricks taking advantage of how most VGA cards were designed, and one needed dedicated HW to accomplish smooth scrolling. Regardless, throwing up MHz this and memory size that can't be used as valid input into comparisons of machines. Early consoles we're entirely dependent on custom accelerator HW. There was an era in PC history where everything depended on CPU speed and memory, but we have effectively come full circle to the point that the performance of a given console or PC depends more on the sum of its parts (CPU, storage tech, memory speed and size, GPU, etc.) than a spec table would imply. Comparing the theoretical performance of two machines is impossible without an intimate understanding of how computers work, regardless of what some marketing departments would have you believe.
-
I got my info here: https://www.pcgamingwiki.com/wiki/Commander_Keen_in_The_Armageddon_Machine Min required is 8088, 286 is recommended.
-
I'm well aware of the example you're trying to make. You just made it poorly. An 8088, not a 286. 8088 is like the Celeron version of an 8086. It had an 8-bit databus, with no video acceleration hardware and ran at 5MHz at the low end. It's no surprise it struggled with any NES-style graphics. It struggled with graphics period.
-
The Jaguar is probably the most interesting console I have come across
cubanismo replied to oky2000's topic in Atari Jaguar
Honestly, SNES, NES, and Genesis have some good games. Can't deny it. You make that many games for a system, many will be good. I play Mike Tyson's Punchout, Duck Hunt, and (on teh emuz) Virtua Racing (Have the real Saturn hardware, but Genesis and 32x versions are the only ones that handle like the original), Sonic, Star Fox, Mario World, Mario Kart (Original), and a few others semi-regularly. I also play mad Virtua Cop and Daytona on Saturn. But for some reason, I enjoy playing well above 50% of the entire Jag library, including some of the much-lambasted titles, and many a Homebrew. I've never even played a homebrew on anything else besides the Nuon and one or two on the Lynx. There is indeed something special about the big cat. -
Even the VLM is just firmware, so really the only HW feature the CD unit adds beyond being a CDROM is the ability to crash more often. The FMV support does indeed consist of a blob of code Atari provided that you load on Tom. You feed it data from the CD (Which incidentally requires another blob of code the CD BIOS loads on Tom to act like a sort of DMA engine) using the 68k, and it spits out decoded frames.
-
Glad it's working. I'll take a look at the patches. OT, but curious if you've tried my Mac Skunkboard/JCP installer package on your M1. They're built with ARM support, but I've no way to test it.
-
This was also on *very* early PC hardware though. Yes, the resulting engine was used for Commander Keen, which runs on an 8088 processor with 640K RAM. I.e., before x86 even required an "x" in its name. Not comparable to something contemporary with Jaguar like Doom running on a beefy 386 or ideally 486 with 4MB of RAM.
-
My Jaguar SDK environment is now on github
cubanismo replied to cubanismo's topic in Atari Jaguar Programming
Pushed another update. These should all be included now. Thanks again for the contributions. -
I considered suggesting that, but note it contains a lot of C code and stuff too, so you need to have a mildly complex environment set up to build it fully. If you just want RMAC tests though, you could pull out all the assembly files and verify they at least parse or do before/after object file comparisons.
-
My Jaguar SDK environment is now on github
cubanismo replied to cubanismo's topic in Atari Jaguar Programming
I've made some minor updates to the SDK: -Pulled in newer RMAC, RLN, jserve, and jag_utils code. -Merged some cleanups/improvements to maketools.sh (Thanks @dilinger!) -
Note this broke stuff. As @42bs noted, basic integer addition and subtraction work fine in this regard, and there's code that relies on this. Issue #218 filed. I think I can construct a patch that hides the error in this case, but it's really hacky. I initially started writing a patch that strictly fails arithmetic operations that don't work on undefined symbols when an external symbol is involved within the expression evaluator itself, but after perusing other uses of the expression evaluator to see if that would break anything, it looks like there are currently dozens of uses that just soldier on when performing unsupported arithmetic on undefined values. I don't have time to go and walk through them all to see if they should be fixed or left as-is, so I gave up. Unless someone else wants to tackle that, I'd suggest just reverting the new error, given it's likely a very partial fix anyway.
-
Yes, this. The reproductions look great and work fine for a game like Battlemorph, but I have trouble getting through more than a few minutes of play on something like Total Carnage or even something rather intense like Iron Soldier without popping them out of the controller while scrubbing my thumb around. Need something a little thicker and with embossing to hold them in place. People are going to hate this, but the best 3rd-party overlays I've used are those that come with games from @WAVE 1 GAMES. They're sturdy, have a good texture for sliding your thumb around on them, and nicely embossed. If anyone knows & cares to share how those are made, that'd probably be the best way to get some nice reproduction ones manufactured.
-
Atari Jaguar Cartridge Trays Now Available
cubanismo replied to MortoffGames's topic in Atari Jaguar
Also helpfully available here for a higher price: https://mortoffgames.com/index.php?route=product/category&path=297 -
Right. I know of plenty management types that don't let little things like verification of technical feasibility get in the way of inking sweet dealz, so I don't really see any evidence towards an equivalent game experience being possible either way from this.
-
I mean, we're talking the JagCD here.
-
Given the context, "memory" might have meant ROM space.
-
I assume the FMV was running on the GPU at least, likely using the existing Cinepak codec. Anyone have any more info on that? I doubt it would have been fast enough even on a 68020 otherwise, unless it's just streaming uncompressed or very lightly compressed frames. If that assumption is correct, there wouldn't be many cycles left over for other usage anyway. DSP could do some I guess, but meh. The remaining logic was probably simple enough using even a 68000 probably would have worked. That game was all about the FMV.