Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

leech

Members
 View Profile  See their activity

  • Content Count

    3,640

  • Joined

  • Last visited

Posts posted by leech

  2. Posted

    12 hours ago, tf_hh said:

     

    Simply why I want to prevent the user from drilling holes into his machine anywhere. Before I made the first version, I ask several people about their opinion. Most of them say: "My 800 is a holy grail, I never drill anything!"

     

    The first protoype has had the color pot at the same place like the genuine cards:

     

    SCCC_Proto.thumb.jpg.a34bfad4b18fa75fb12d17238727faba.jpg

     

    But then there´s no space to outbreak the shielded video cable and drilling is needed. Later, when Bryan allowed me to use his UAV circuit, I must arrange the parts a different way to seperate all video traces from the system´s buss the get the best quality possible, so the color pot must went to the left side.

     

    So I think it was decided that maybe it's the UAV circuit that is changing the color palette to XL type vs 800?  That's kind of what it looks like to me.  Ultima IV comes with a built in color swap, to change green/blue around.  Which seems to work on the XLs if your POT is adjusted right.  Ultima III as far as we know does not.  Ha, maybe I can have some luck with Disk Wizard.

  3. Posted

    1 hour ago, Faicuai said:

    This one seems like a much more desirable arrangement... 

     

    I know it is impossible for you to predict future events (no HW designer can, in fact), but this layout seems to allow a direct, drop-in install of SOPHIA-2 in CTIA/GTIA which is perfectly placed for a quick-and-simple exit route through the expansion bay, for instance.

     

    On the latest SCCC, and assuming PIN #1 of chipset goes up-left, I could not see space between GTIA and ANTIC chips for Sophia's integrated header (it is pre-soldered for 800 users).

     

    All-in-all SCCC is a solid upgrade for the 800 and, as FPGA re-implementations advance, it is the future of the 800 expansion of GFX and CPU power. And all of it essentially plug-and-play, leveraging the 800's architectural strengths.

    Ha, yeah I skipped doing the cable out the back, and wired up the SCCC to the original monitor port.  Seems much neater that way.

    • Like 1

  4. Posted

    1 hour ago, retrobits said:

    This is interesting discussion on artifacting output of the Super Color CPU Card with the UAV circuit.  I've yet to install mine, but am preparing to do so.  I really appreciate the detailed findings from Krenath and Faicuai and others.

     

    Pretty much I use an original 800 and Ultima III is one of those games I still play, and I was surprised by the sample output.  I did spend some time today in Altirra with the game and was impressed how thorough Phaeron was in emulating the colors.  Under the view menu, you can choose "Adjust Colors..." and then set the preset to many choices, including NTSC, PAL, XE or XL or 800.  I've attached screenshots of the 3 different presets for XE, XL, and 800.  Based on this, I can see why there is so much confusion about which are the "correct colors".  It really depends on the machine you use. 

     

    XE Artifacting: 

    U3_XE.PNG

     

    XL Artifacting:

    U3_XL.PNG

     

    800 Artifacting:

    U3_800.PNG

    Yeah so the my XE probably needs adjusting, but it's Blue / Orange vs Cyan / Red. 

    my unmodified 800 looks like yours, Blue / Green.  But my 800 with SCCC and Incognito looks more like the XL line.  Kind of seems to me that we just need to find the games such as these and create a patch.  My 800XLs all seem to have the swapped colors (Green borders / Blue title).  Not sure where to do the color inversion on those.  So does the UAV / SCCC actually change the NTSC artifacting palettes somehow?  That's the only reason I can think of the modified 800 is doing that.

     

    Fun side note, I bought Ultima III and IV on cartridge from the atarimax store, and neither of them will run on 48k, so I can't actually test those on the unmodified 800, only on the SCCC/Incognito equipped one.

    • Like 1

  5. Posted

    37 minutes ago, tf_hh said:

     

    Simply why I want to prevent the user from drilling holes into his machine anywhere. Before I made the first version, I ask several people about their opinion. Most of them say: "My 800 is a holy grail, I never drill anything!"

     

    The first protoype has had the color pot at the same place like the genuine cards:

     

    SCCC_Proto.thumb.jpg.a34bfad4b18fa75fb12d17238727faba.jpg

     

    But then there´s no space to outbreak the shielded video cable and drilling is needed. Later, when Bryan allowed me to use his UAV circuit, I must arrange the parts a different way to seperate all video traces from the system´s buss the get the best quality possible, so the color pot must went to the left side.

     

    Makes sense.  I still can't seem to find the right tool for like say the 800xl to be able to adjust the pot from the bottom of the case, only seems to work after taking it apart and adjusting through the shield.

  6. Posted

    Well here's something fun.  I've tested multiple copies of Ultima III and IV on multiple systems.  800 with SCCC and Incognito, 800 Stock, and three different 800XLs (three different keyboards), and one of my 1200xls. 

    Only the Stock 800 presents the correct colors, and that was only after fiddling with the POT so that the blue with white cursor became purple.  But the fun thing with that one is I tweaked it back and the correct colors remained, and the blue memo pad screen came back.  This may legit be due to the old girl needing some warm up time.  On that note, it sadly did something weird where it wouldn't turn on until I put it all back together, but when it did, it will no longer power the Fujinet by itself, or the SDrive Max :(  Will have to figure that one out later.  I've messed with the POT on two of the 800XLs and couldn't get the correct color mix.

     

    @tf_hh

    Curious, when you designed the SCCC (awesome card!) was there a particular design reason why you didn't put the POT for adjustment in the whole where the 800 has a spot for it already?  It was super convenient for messing with it without taking the whole thing apart again!

  7. Posted

    2 minutes ago, David_P said:

    Only three?  My current tally: One stock 800; one stock 800xl (boxed, serial numbers match); U1MB 800xl; 256K RAMBO 800xl with Sophia 2 and soon PokeyMax Quad; Antonia (4Mb, 65816 CMP) 800xl with Sophia 2 and soon PokeyMax Quad; stock 130xe (boxed, NoS from MyAtari with no serial numbers); and XEGM with TransKey and an old indestructible AT keyboard.

     

    But if my wife asks, it's only the ones she can see at the moment when she's looking...

    Ha, only 3 800xls... I didn't want to list the 2x 1200xls, 2x 800s, 3x 130xes, 2 600xls... i think the only ones I don't have are 400s or like 65 XEs... don't really see the point in those.   Then I don't have a wife either, so don't need to hide them, just need a spot to hook them up!

    • Like 1

  9. Posted · Edited by leech

    3 hours ago, Krenath said:

    On all three machines I have, two 800s and a 130XE, the title and the trees are green and the water is blue.   It's always been that way.  
     
    E1A34630-ED4A-408F-A4BD-8FFEF67AA002.thumb.jpeg.46cd76785b93abd56d386e5b825a70a5.jpeg
    545E7F67-4681-4D14-8348-5CBEE0A10DA1.thumb.jpeg.6f8aa4148d48c58f45bb721cdc10a741.jpeg

    F84AB6B8-6114-4BC9-B511-E07BC6A3065D.thumb.jpeg.2abd3fc89099f4465804096636347196.jpeg

    The above colors have always been the normal colors on my machines. 
     

    if you look at screenshots of other types of machines, Apples, Commodores, Amigas, PCs, they all also have blue water and green trees.  Even the later adaptations for machines that had the luxury of more colors to choose from.

    I have never seen an unmodified Atari before that had any artifact colors other than blue and green. 

    0398F303-A477-4ECC-8613-B6C7F3F5ECEF.jpeg.8d6ac193307b4850d996877c4ad5da5c.jpeg238B58AA-410E-4C70-BFDD-3E73680CB40C.png.d5313ec9c23aabc48460629b133c44eb.png0398F303-A477-4ECC-8613-B6C7F3F5ECEF.jpeg.8d6ac193307b4850d996877c4ad5da5c.jpegC22F77F1-31A2-436A-BDB5-7DAAF3673C46.png.6df532f55019a40db66158f508c746cd.png

     

    I still don't see why I would want to change that.  
     


     

    And certainly not just because one single game has one single control that might be that color on a different platform

     

    It's much less believable that Ultima should be correct with alien colors on only Atari machines while every other platform has the same colors that my unmodified machines get than the idea that FSII users should have to deal with an artificial horizon ball that's not orange.  

     

     

    Can you please share the images you are using for these?

    When I originally played Ultima III on the 8bit, the water was red, never understood why back then.  I can only get all of my machines, including the 800 with SCCC to show like my screenshots at best, or the colirs flip if I change the pot the other way.

  10. Posted

    3 hours ago, Krenath said:

    Right.  I was just illustrating that Ultima's colors are entirely artifact-based.  

    On my unmodified machine as well as on every other machine Ultima III was ported to, water is blue and grass is green. 

    On my SCCC-equipped machine, water is green and grass is purple until I invert the colors to get purple water and green grass.  But while plenty of posts on the forums seem to think this is correct, it's definitely not.

    And if I set my machine up to play Flight Simulator II as Faiquai described, Ultima would display red grass and cyan trees.  This is *definitely* not what the author intended.  I even have cloth maps to prove it. :)

    So here's the fun thing about Ultima III.  It was created on the Apple II, like the rest of Ultima 1-5.  I have no idea why they chose the 4 colors that they did for U3, but the EXODUS title is the same color as the trees, basically you're stuck with either blue water and red trees (maybe it's permanently in Fall?) or you get red water / blue trees.  I found on my 800xl, that there is a slight area on the pot between complete lack of color, and very bright / vibrant blue outline / red Exodus title.  Then if I turn it just slightly more, it dims more.  This results in this;

    Screenshot from 2021-02-20 07-14-10.png

    Screenshot from 2021-02-20 07-15-36.png

    Screenshot from 2021-02-20 07-16-32.png

  14. Posted · Edited by leech

    25 minutes ago, Krenath said:

    The one thing that I find confusing and annoying about this mod is that it drastically changes the artifact colors when viewed in composite mode.  

    On the same monitor with the same machine, the original composite output  would show blue and green as artifact colors.  Games like Ultima III: Exodus used those colors to create blue water and green plants.

    With the Super Color CPU Card, those colors change to green water and red plants.  And it doesn't seem like any amount of adjustment to the pots on the card or the Inverse Color jumper can get it back to the original colors.    It makes games I've played for years look ...wrong.  

    Everything else about it is incredible.  in S-Video mode, everything is sharp and clean like I've wished for since 1982.  Although games like Ultima III end up entirely in monochrome since S-Video doesn't have artifact colors.
     

    Try pressing Control-X on bootup to change color pallette.  It works for Ultima IV, not sure about 3.

     

    I specifically refuse to use S-Video for most things due to lack of artifacting.  What we need to get over this limitation is for some mega skilled coders to rebuild the games using better graphic modes somehow.  Usually they have been bad Apple II ports that cause this.  At least from my understanding, as the Atari can definitely display more colors without it. 

    Though I have a VBXE so really would love an upgraded version ha

  15. Posted

    37 minutes ago, mr_me said:

    You only need 8GB ram in a raspberry pi if you're doing 4k video, otherwise 4GB is huge for a lightweight os like raspbian.  Even windows is fine with 4GB ram, so 2GB might be plenty for raspbian.  The faster cpu in the raspberry pi 4 will make more emulators work properly, it might even be okay for modern mame.

    I am used to Gnome, or KDE.  LXDE for me has always felt clunky, so maybe that is why I feel the Pi isn't great as a desktop PC.  But then it is still more usable than Win95.  😀

  19. Posted

    7 minutes ago, zzip said:

    I've created USB sticks that do just this.   Boots into an emulator front-end.   It could go straight to Stella too.   My opinion is it's best to put it on a lean Linux distribution to minimize boot time, but I know VCS has that signed kernel restriction that limits what distros can be used.

    Well, it is possible to turn off, but AtariOS won't load.

    My suggestion started with the idea of being able basically to 'put up or shut up' for the people bashing Atari.  Basically a 'let's see you do better'.

    Also the idea of other companies to have an ability to sell a USB key that you can boit to a game / emulator.  Like the olden days when you would put in a floppy disk and boot straight up. 

    I may have a play with the seed list to make a Debian liveusb for such a thing. 

    • Like 1

  21. Posted

    12 minutes ago, x=usr(1536) said:

    Which is a good point, and one worth mentioning.  MAME has only three official build targets: Windows, Linux, and macOS.  Windows and macOS are pretty self-explanatory, but Linux opens up an interesting set of cases due to the source's high portability between hardware architectures: the same source that builds on x64 will also build on ARM, RISC, and others.  This has led to a lot of complaints about MAME's performance on low-end hardware, which overlooks the 'just because you can doesn't mean you should' aspect of running on those platforms.

    I still want to know MAME performance levels on a RISC-V.  Was actually thinking as the community SBC build that a RISC-V board may be an interesting target!

    • Like 1

  23. Posted

    5 minutes ago, Matt_B said:

    I'd think that if MAME were started from scratch now, they'd take the same model as RetroArch/LibRetro in that you'd have a common front end and just could just download the individual emulation cores you need.

     

    Even as things stand now, the monolithic MAME LibRetro cores are no bigger than a relatively modest indie game, so not that much of a pain to download. You just have to resist that gotta-have-everything impulse that'll mean you'll spend more time setting it up than you'd actually get to spend playing anything.

    Ha, that's my problem with everything these days.  When you have scores of retro stuff, and even close to 3k games on steam, you end up sitting there thinking 'I want to play a game' and then not being able to decide what game you want to play, or even what kind... and then end up watching something on Netflix :P

  24. Posted

    1 hour ago, x=usr(1536) said:

    Ehhh... We may be getting into hair-splitting territory on this one.  I'd argue that it does qualify as an emulator, just one where the machine being emulated can be defined by its driver rather than the emulator as whole.  Think LKMs vs. monolithic kernels as a parallel.  Still, I get what you're saying.

    Ha, yeah.  Like it's more a blob/front end that then uses all the little bits and pieces to emulate stuff.  So you can update say the z80.c file and it'll effect whatever systems use the z80, but not things that use m68k emulation.

    1 hour ago, x=usr(1536) said:

    Part of that is just down to the fact that it now supports over 35000 different machines - and that's an arcade-only build.  But that brings us back to the question of, "what is bloat?", which still needs a decent answer before trying to see if there's a problem that needs to or can be solved.  I don't know that there's necessarily a good answer to that question simply because 'bloat' may mean something different to different people: one may consider the UI wasteful, or another advocates ripping out support for all of the mahjongg, hanafuda, and fruit machines.  To someone else, it may be an inefficient or redundant routine in <insert emulator element here>. 🤷‍♂️

    Ha ha, yeah a large majority of the games are unplayable unless you use a keyboard, or somehow have one of those weird mahjongg controllers.  There are various forks out there that I think do clean all that stuff out.  The beauty of open source! 

     

    1 hour ago, zzip said:

    I've always struggled to understand the MAME development philosophy.   I seem to recall that Mame started out as a set of emulators that ran different families of arcade games.   But then it all got rolled into one thing.

     

    But why do all those disparate systems need to get rolled into a single monolithic binary?  Couldn't the various emulators been turned into shared libraries or plugins, with a single loading program that only loads the plugins needed at the time?   Does emulating Space Invaders and the Simpson's arcade game really share that much code?

     

    The scope of what it does always seems to expand, it didn't stop with arcade game, it re-merged with MESS, even though MESS is full of many sub-par emulation implementations, that no-one can actually use, it gets rolled into the binary anyway.   This is why it has a reputation for bloat.

     

    I think the solutions for the bloat problem

    1) less monolithic binary, load shared objects/modules for what is actually needed

    2) slimmer builds - it's great that it supports 35,000 systems, however the average user probably needs less than 200 of them.   Make it easier to make builds that eliminate the stuff you will never use.

    What would be nice is a modification to the build system so it works like the modern one for the Linux kernel.  So you could for example include just Atari games, or Atari games from 1977 to 1995.  Select which non-arcade systems too, etc. 

     

    I mean there definitely is a separation between say Space Invaders and the Simpson's Arcade, but like Space Invaders and... something else I can't remember at the moment, share the same hardware.  But all of that gets built into the binary making it bigger.  An approach like RetroArch where you can install individual cores is more along the lines of what you're asking.  There are advantages to both methods, along with disadvantages. 

  25. Posted

    5 minutes ago, x=usr(1536) said:

    The point that seems to be being overlooked is that MAME doesn't target a specific performance goal.  If a system has the beef to run a particular game at 100%, great, but if it can't, it'll need to be upgraded and/or stand by for driver improvements.  And while everyone talks about 'bloat', the reality is that nobody (in the wider picture, not specifically here) has defined that term in such a way as it would permit a solution to the perceived problem being forumlated - yet the emulator continues to work in its present state just fine on not-up-to-date hardware.

     

    Additionally, one of the problems with specifically targetting low-end hardware is that it makes it difficult to break with the past.  MAME running on a 486 is an excellent example of this, and one that I have experience with so can remember how well it performed.  But that was at a time when the demands of the drivers were much lower due to the far lesser complexity of the emulated systems: there was a time when Galaga was believed to be unemulatable because it had - *gasp* - two Z-80s.  There were also a lot of inaccuracies not just in drivers, but also in things like CPU cores and discrete audio, and improving accuracy over time in some cases required more cycles.  There's a reason why 32-bit builds are no longer distributed and are generally discouraged.

    Yeah, MAME is at it's core, simply a set of drivers for different chips.  It's not even an emulator in the traditional meaning of the word.  Like it doesn't emulate a single system/board.  It has various drivers for each 'chip' or sometimes they bundle system boards together.  Like the aforementioned Congo Bongo issue is because they updated the Zaxxon board, which uses the same setup, but it broke the music of Congo Bongo.  Crazy how big of a project MAME is.  Getting a nice setup of MESS was always a pain, still sort of is, but MAME at least now has a decent native front end, before it was a CLI program and everyone else made front ends for it.  So that might also be where the 'bloat' is from.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...