Superb! I'd be interested in giving my rough port of Adventureland full keyboard support

Follow up video. https://www.youtube.com/watch?v=egYoXwOTDYs

I'm very interested in emulating the FROB and running the software on an emulated AppleII. I think being able to experience an original development process would be very educational.

The FROB-26 working after some restoration. I think this is @thom.cherryhomes work

https://www.youtube.com/watch?v=IAefPk7WgJk

I never got very far with the vectrex but looking at my collection I see I have ParaJVE installed for emulation and lwtools (http://www.lwtools.ca/) for 6809 assembly.

ParaJVE doesn't seem to work any longer (probably incompatible with my current Java installation) but MAME should work if you have that installed.

https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.40.0-preview_2

Saw this on itch.io. It's a few years old but I've not seen it before. It's nicely done I think.

https://daddarulekonge.itch.io/apro

Quote from: Thomas Jentzsch on 28 Jan 2025, 09:13 PMYour findings about the different hues are interesting. I suppose the developers had configured their TVs quite badly. Without noticing!

I've been thinking about this and trying to understand the circumstances which resulted in the Krull we see today.

First off, I would imagine that developing in the 80s is very different to today. As far as I can tell, the development cycle would have been very slow by comparison. Today we can change the program, assemble it and boot it in an emulator very quickly. In the 80s, the time between a changing the program to seeing the results on screen would have been much longer.

So, when selecting the values to use for colour, surely the developers would use the reference table in the Stella Programmer's Guide (or equivalent). They wouldn't just blindly try different values until they got the result they wanted (which we might do today because the feedback is immediate).

But when the hue is shifted so that Krull more closely matches the images on the game box, the colour table in the guide is completely wrong. How could they have missed that?

I'm not ready to believe it was intentional but if it isn't, I'm struggling to understand how the development process allowed that to happen.

The other possibility, is that the person who prepared the box art had their TV hue aligned differently and which just so happened to be a setting that results in a better looking Krull (to my eyes at least).

For that we would have to accept that quality control when producing the final product was poor. We would also have to accept that the developers wanted the castle walls to be green.

I'd love to quiz the person who made the game.

The other possibility is that my colour calculations are wrong but I would need somebody else to check that because I can't see where the problem would be.

Quote from: Thomas Jentzsch on 29 Jan 2025, 03:42 AMYes, because no TV adapts to such settings automatically.

Fair.

But there's lots we do with emulators already that improve ease of use but aren't realistic. No console allows us to unplug a joystick and to plug in a paddle automatically but we set up emulators to effectively do that.

All that's happening with a hue adjustment is the automation of getting out of the armchair and moving the knob. If the user chooses to do that every time they launch a specific game then I don't see the harm in allowing the user to choose to automate that.

But I agree that it's a bad idea to allow this to happen without the user explicitly making the choice. I called it "palette abuse" in my post and it's likely to happen over time.

?? Which bit is not realistic? Saving the hue setting per game as per the user wishes, is faking reality?

Quote from: Thomas Jentzsch on 29 Jan 2025, 01:10 AMI don't know. There is a risk that this could be abused and a game would only look OK in an emulator.

Yes. I agree that is a concern for new games. It's open to abuse for sure.

I think a compromise is for the emulator to optionally save hue settings for each ROM. So it's something the user consciously does for any game that needs it. But once it's set for the ROM it doesn't have to be done again.

Quote from: Thomas Jentzsch on 29 Jan 2025, 01:10 AMAlso PAL conversions would become problematic, since the mappings would become very random.

That would depend on how the conversion is done I think.

Quote from: Thomas Jentzsch on 28 Jan 2025, 09:13 PMYour findings about the different hues are interesting. I suppose the developers had configured their TVs quite badly. Without noticing! But I don't think we should define color values per game, because I doubt any user would have adjusted these parameters per game back then.

Therefore people would only adjust the emulator color settings once to make them look like how they remember.

Hmm. That's a fair point.

However, I still think there's merit in making a note of what the optimal setting is for a game. I think it would be nice for emulators to give the option of automatically setting the hue/phase as required for the game.

Quote from: JetSetIlly on 26 Jan 2025, 01:03 AMNew blog post summarising what I know and think about this problem.

https://jetsetilly.github.io/Gopher2600-Blog/posts/the-ntsc-colour-problem/

Follow up article: https://jetsetilly.github.io/Gopher2600-Blog/posts/ntsc-colour-in-vintage-games/

Thomas: includes some more thoughts about a 2600 container file format that we've talked about previously.

Quote from: SpiceWare on 26 Jan 2025, 03:01 AMWell done.  Spotted a couple typos:

Updated. Thanks

New blog post summarising what I know and think about this problem.

https://jetsetilly.github.io/Gopher2600-Blog/posts/the-ntsc-colour-problem/

Quote from: alex_79 on 17 Jan 2025, 06:59 PMSo, maybe that could be the reference for the "intended" palette?

Yes! That would be brilliant.

Do we know anyone with a single chip 2600?