Quote from: JetSetIlly on 13 Feb 2025, 08:01 AMSaw 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.Sprunki Retake.itch.io/apro

Any standout features that make it worth checking out?

Quote from: Andrew Davie on 19 Jan 2025, 06:06 AMMy "antagonist" is in quotes...

From critic to antagonist right off the bat, eh?  Hopefully I'm not walking into a lion's den here...

QuoteThe levels are not the same; they are unique to this version.

From what I've seen, 2 of the 3 caves in this new Boulder Dash ARE the same.  Having different placements of the rocks and diamonds doesn't make it a new cave, it's just a variation of the same cave.  As I already explained on Atari IO, the original Boulder Dash game does this as well.  Cave A the 2nd time around is a different LEVEL of cave A.  In other words, your new Boulder Dash has a new level of cave A.  I think we're getting tripped up on the terminology here.

QuoteThe game is named "Boulder Dash 2", as in the 2nd Boulder Dash I have written for the '2600. The released version is technically "Boulder Dash 2 DEMO", but for space reasons on the title screen it says "Boulder Dash DEMO". It has never been referred to by me or BBG as "Boulder Dash II", AFAIK... and if it was, then it should not have been.

Although the title screen in your new Boulder Dash simply says "Boulder Dash", you have referred to it as Boulder Dash #2: https://www.youtube.com/watch?v=-RzRmKDGisE
Others, such as those on Atari IO and ZeroPage, refer to it as "Boulder Dash 2".  I simply suggested calling it something else, because First Star Software released a legit Boulder Dash II.  And you wouldn't want to released a finished version of it under the same "Boulder Dash" name because that would only create confusion (and yes, you would need to change it should it have reached the point of being sold/released, because you already released a "Boulder Dash").

You had no interest in doing a conversion of that, and that's certainly your choice.  I'm only suggesting it would be easy to do and would no doubt be popular with VCS fans.  It's a 'low hanging fruit' thing for you to do because cart sales would be all but guaranteed.  If you're so adverse to selling carts and making money off them, you could always donate your profit from them.

QuoteFirstly, I think your idea of what is a "hack" is just wrong...

You're 100% correct in regards to your new Boulder Dash, and I'm sorry you interpreted it that way.  It's clearly a new engine.  By 'hack', I was referring to your creating new levels of the original caves and calling them new caves.  I should have been more specific in my meaning.

QuoteThe irony. I did create completely new caves. But also I wanted a "homage" to the first boulder dash so I used the same wall positions for cave A. But there are huge/significant differences in gameplay, and creatures in the cave. There are speed runs, amoeba, cavernous areas, tricky cascading blockages; all elements specifically added because I did not reuse the original cave data but instead designed a new cave format that allowed "additions/modifications" to base cave data. Each level is basically a common "theme" with per-level modifications on top.  So cave A has the basic wall layout shared, but then each level changes the rock density and positions, diamond density and positions, flags speed run or not, adds different structural changes (more walls, caverns), and creatures. For example, one of the caveA levels has an amoeba which quickly blocks one of the caverns. You have to plan very carefully how to mitigate the amoeba's expansion and not just collect diamonds in a set time. There are variations and although as I said it's a homage, it's actually just a "first impression" one. The levels are different; I know because I designed them all myself.

I *think* you understand what I'm saying in regards to differnce between new caves and new levels.  The caves are indeed the 'walls'.  What happens within those walls are the levels.  Creating more/less rocks and diamonds doesn't create a new cave.  However, if you're putting different enemies in caves where they never were, that's certainly a grey area as far as descriptions go   Cave A with amoeba would certainly constitute calling it a modified cave A (A1?).  But again, this isn't Boulder Dash as compared to the original, it's something else now.  Pole Position with new tracks isn't Pole Position, it's Pole Position II (even though PPII includes the original PP track).  Look, all these new cave and level variations you created are great, but simply calling it "Boulder Dash" is the issue, because you're selling it short.  It's more than Boulder Dash, it's Boulder Dash Deluxe.

QuoteInterestingly you're not the first person to call my working style "lazy".

Andrew, my 'lazy' comment wasn't referring to your working style/ethic but rather your naming style - calling the same caves 'new' caves.  Someone replied on Atari IO with screenshots of the 3 caves that are in your new Boulder Dash.  I remarked that 2 of the 3 were the same caves as the originals, and that calling those new caves is a lazy thing to do.  My only context is the 3-cave demo you released, and I certainly have no knowledge of the complete version you created and are describing here; how could I?

QuoteI'm generally happy to answer questions. A difference of opinion does not an argument make..."

Nor does it have to be antagonistic in nature.

QuoteDisingenuous, huh.  You're actually suggesting I was concealing my true intentions by not being honest and sincere. Do you really stand by that?  In any case, it's not true.

I'm glad it's not true.  Understand, from where I'm standing, that's the impression I get.  I have no doubt you had every intention of finishing and releasing everything you've worked on.  But when you start frequently posting screenshots and updates of your progress and how fast you can code things up, people get the impression what whatever you're working on will get out to them sooner rather than later.  Yes, you're an artist in the sense that you're not just creating new conversions, you're also creating new ways of generating graphics on the VCS.

It's like hearing about a pile of unreleased music from your favorite musicians... after they died.  You look at people like Edward Van Halen, Prince, Ric Ocasek.. who spent years in their studios amassing a mountain of material, only for them to not release it.  As a fan, I think, what was the point of all that effort?  If I spend a year or more of my life on something that was originally meant to be shared with others, I'd be pretty upset if I didn't get a chance to do that.  In their cases, they didn't share what they were working on until they released it.  In your case, you do share it, and as a video game fan, it's frustrating when it ultimately doesn't get released.  As a kid, if you read about or saw a game in a magazine or catalog, you didn't expect that it might end up being unreleased, or worse, vaporware.  Looking at some of your past game developments (that I mentioned on Atari IO), that's exactly the same feeling I get.  I see something you're actively working on... and then suddenly it stops... only to see you start working on something else.  When that pattern starts to keep repeating, it's like the story of the boy who cried wolf; at some point, you stop paying attention.  Unless you make people aware right from the start that, "Hey, there's a good chance this will never be completed or released", not saying that gives the assumption you have every intention of completing and releasing it.  Yes, life happens every day and your priorities can quickly change, or you lose interest, or get interested in doing something else.  But as I also mentioned, there was never any final word from you when a project got 'shelved' and why.

QuoteThe re-release of Boulder Dash came with a "trigger" that allowed any party (after an initial sales period) to stop continuation of the agreement. Because Atari purchased AtariAge, and that would mean I was in a business arrangement with Atari, my principles simply made it impossible for me to do anything but pull the trigger, so to speak. To do anything less would be hypocritical. It was nothing to do with money; well in fact I've lost out on any income so I'm hurting myself there. But as I said, matter of principle.

Thanks for the explanation.  I have to say, I'm not a fan of the latest version of Atari, and I don't agree with Atari's recent business decisions.  The new "plus" emulation boxes are just another degree of Flashback trash at twice the price, and the repackaging of old games like Haunted House for $100 each is nothing more than pure greed (that my friend is pure capitalism), especially when you see people like John Champeau selling new games for half as much.  Those are the people I'd rather support.

QuoteSince we've touched on my disapproval of resale at inflated prices, the best way I can explain this is that I do put a lot of work into my games/demos - way more work than I ever see in sales (or even thanks). Most people just take my work and I never hear a word from them again; not even a thank-you. But when I see people take my work and try to sell it for a 65000% mark-up (yes, 65000 percent) over what I received for that same copy... well, actually yes that feels disrespectful to me and the community. In capitalist USA that may very well be "Capitalism 101" but in some other parts of the world, artists are protected from such exploitation of their work. But that's another discussion and my view is apparently in the minority.

Because I don't do these things for money. I do them because I enjoy them and find intellectual satisfaction in the challenge. I don't write Atari software for others; rather I write software and share my enjoyment and achievements (for free) with those who care to come along for the ride. Releasing things as a final product often takes a huge amount of extra work that for me, at least, is sometimes not necessary as I may already have achieved my goals.

The USA doesn't have an exclusive on greed by any means, but it's certainly a prominent factor.  And how money is used can be either positive or negative.  But people reselling items for higher prices is the foundation of collecting, and it's been that way long before the days of the Internet and Ebay.  Anybody selling something just has to accept that, because it's not going away, especially if what you're selling is limited, be it games, guns, cars, wax figurines, etc.  Sure, you can remove yourself from the equation and not sell anything, and end up a starving artist (and look at how many famous painters and artists ended up like that).  But again, wouldn't you prefer seeing your work being enjoyed and appreciated by others?  With all the people I've interviewed over the (30+) years, most everyone is happy to hear something I worked on that never got released back then was finally recovered and released.  For them, that one game represents months of work in their life.  Sure, they were paid a salary to create it, and might have received some royalties from it had it been released, but in most cases they loved working on creating games and money was not a driving factor, but rather a side benefit.  Some have said they would have worked on them for free, as their passion for creating them was that great.  Personally I would say remove money from the mental equation of whether or not to work on them, and disregard whatever happens afterwards as far as resellers (because people are going to do what they're going to do).  And Champ Games offers digital copies of games, so you wouldn't have to deal with selling physical copies (or you could go through Champ Games to handle that side of it).  Atariage isn't the only option to sell games through; there were options to sell physical carts years before Atariage existed.

QuoteQuite the itemised list of my work, presented as an implicit criticism.

The list of your unfinished titles is simply that - a list of known, public facts that I'm aware of.  And yes, I posted the list to show just how many times this history of working on something and then abandoning it has happened.  It's a criticism as far as I wanted to see most of these get completed, and I'm sure I'm far from the only person who feels that way.  You're also not the only person to start something and get very far long with it, only to stop.  There was a very promising version of Ballblazer being worked on, as well as a version of Donkey Kong, to name but 2.  I'm not a programmer, I'm a player, and I just want to play them

QuoteBut you do touch on lack of motivation. Some of us "creative types" suffer from this - mood swings and depression.

That's hardly specifically related to 'creative types'.  People of all types suffer with that.

QuoteYou seem to have researched quite a timeline and have more details than even I recall. But the above is not quite correct. I started writing a Boulder Dash engine in CDFJ...

I could only go by the information that's publicly available.  Incomplete or incorrect info often leads to incorrect conclusions

But what do I know (right TJ?), I'm just a "troublemaker"...

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

I'm thrilled to introduce a new project I've been working on: an Atari 2600 Keyboard and Joystick Interface! This project aims to bring keyboard input to the Atari 2600 while allowing parallel connection of joysticks and other input devices, opening up exciting possibilities for games, utilities, and creative experiments. I've already discussed the idea with Thomas Jentzsch, who has been incredibly helpful in getting this project off the ground by contributing some great ideas for the protocol. Now, I'm looking for testers, developers, and feedback to help bring this project to life.
Project Overview
The goal is to create a hardware interface that allows a PS/2 or USB keyboard and other input devices like joysticks and paddles to be connected to the Atari 2600 in parallel. This interface will enable developers to create games and applications that use both keyboard and joystick input simultaneously. Here are some key features:

• Keyboard Support: The board will include a PS/2 and a USB connector, but only USB keyboards that support the PS/2 protocol over USB will work (most keyboards should do, but I haven't tested).
• Parallel Connection of Input Devices: You can connect joysticks, paddles and keypads in parallel with the keyboard, allowing for versatile input options.
• No PlusCart Required: This project is designed to work with a normal ROM cartridge, so you don't need a PlusCart to use it.
• Free Test Boards: Thanks to a JLCPCB sponsorship, we will have some free boards available for testers and developers involved in the project!

One Limitation

• SaveKey and AtariVox Compatibility: Unfortunately, the SaveKey and AtariVox and other devices that need the RIOT in output mode will most likely not work with this interface due to hardware and protocol conflicts. This is something to keep in mind for developers and users.

How It Works
The project is built around an ATmega328P microcontroller that manages communication between the joysticks, keyboard, and the Atari 2600's RIOT (6532) chip. Here's a breakdown of the system:

• ATmega328P and Bus Transceiver:
  
  • The ATmega328P controls the communication between the joysticks and the RIOT via an 8-bit bus transceiver (SN74LVC245AN).
  • The SN74LVC245AN acts as a bidirectional buffer, allowing the ATmega328P to selectively "block" or "enable" the joysticks and keyboard.
• Direct TIA Connections:
  
  • The TIA connections on the Atari 2600 joystick ports (e.g., trigger buttons and paddle potentiometers) are wired directly to the joystick ports of the device. These connections are not controlled by the ATmega328P and remain active at all times.
• Keyboard Input Handling:
  
  • When a key on the keyboard is pressed, the ATmega328P:
    
    • Blocks the joysticks by disabling their communication with the RIOT.
    • Sets the RIOT's data bus to the corresponding keycode value (8-bit, allowing for 255 different keys; $ff represents "no key pressed").
  • When the key is released, the ATmega328P:
    
    • Disconnects itself from the data bus.
    • Re-enables the joysticks, allowing them to communicate with the RIOT again.
• Reading Keycodes on the 2600:
  
  • On the Atari 2600 side, reading the keycode is as simple as reading the RIOT's SWCHA register.
  • Here's an example of the code used to handle key presses in my demo:

   lda SWCHA         ; Load the value from SWCHA (keyboard input)
   cmp #$ff          ; Compare to $FF (no key pressed)
   beq skipNewChar   ; If no key is pressed, skip
   cmp last_char     ; Compare to the last key pressed
   beq skipNewChar   ; If the key hasn't changed, skip
   ldx ActiveChar    ; Load the index for the active character
   sta w000,x        ; Store the keycode in memory
   inx               ; Increment the index
   stx ActiveChar    ; Store the updated index
skipNewChar
   sta last_char     ; Store the current keycode as the last key pressed

 

• In this example, the keycode sent by the ATmega328P directly corresponds to the value needed by the 24-character display kernel I'm using. This simplifies the process of displaying characters on the screen.

• Future Protocol Improvements:
  
  • The current implementation uses a simple keycode system, but we're open to exploring other protocols in the future, such as:
    
    • ASCII: For better compatibility with text-based applications.
    • Real PS/2 Keycodes: To support a wider range of keyboards and key combinations.
    • Custom Protocol: To allow simultaneous use of keyboard and joystick inputs (e.g., using arrow keys as joystick directions).

Things to Discuss and To-Do
There are still some open questions and decisions to make, and I'd love your input:
Protocol

• Should we use ASCII, keycodes, or a custom protocol to allow simultaneous use of the keyboard and joystick in the same kernel?
  
  • For example, could we use the arrow keys as a joystick? (Diagonals are still unclear.)
  • We'll need to decide which ASCII codes to omit to avoid conflicts with joystick inputs.

Hardware

• Keyboard Layout Selection: Should this be done via DIP switches on the board or configured in the 2600 software?
• Power Supply: Should the keyboard have a separate power supply, or can it share power with the Atari 2600?
• Capacitors: Do we need additional capacitors for the SN74LVC245AN buffer to ensure stable operation?

Miscellaneous

• Project Name: We need a cool name for the project/board! Any suggestions?

 
How You Can Help

• Testers: If you're interested in testing the hardware and providing feedback, let me know!
• Developers: If you're a developer interested in creating software (games, utilities, etc.) for this interface, your input will be invaluable.
• Feedback: Share your thoughts on the protocol, hardware design, and any other ideas you have.

 
Next Steps

• I'll be finalizing the hardware design and ordering test boards soon.
• Once the boards are ready, I'll distribute them to testers and developers.
• We'll work together to refine the design and create some awesome software for the Atari 2600!

 
 
YouTube Videos

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.

I've always been fascinated by these devices. It's cool  to finally see it in action.
Thanks for sharing!

Quote from: JetSetIlly on 20 Dec 2023, 05:08 AMhttps://www.youtube.com/watch?v=5HSjJU562e8dordle

Instruct them to inquire with me, since I initiated the cancellation clause.

Pretty cool, thanks for letting us know.

That's just super-awesome. I tried to collect a few '2600 development systems but realised I'd be unlikely to get the super-rare ones. I do have most of the cart-based ones, though!

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

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