Sounds now added. Just a mockup tune.
I tidied up various animations, and polished a few things.
The scoreline shows the number of "pills" and the number of box moves made.
At startup I show a haiku. Just because. Was testing the word overlay system... but I kinda like it.
Next up, I think I need to work on the data format for levels; I can grab this from the last sokoban I did.

Haha now I've seen everything.

For what it's worth, I now have permission to release an updated/new DEMO version with three different levels. I'm not quite motivated to go through all that again, but it is now a possibility/approved. Let's see how much interest/demand there is first.

I've spent some time cleaning up the code. Basically removing any remnants of anything copyrighted from previous incarnations. It's close. I'm also trying to make it easy to understand for anyone game enough to try building it and modifying for themselves.

In particular...

1) The ChronoColour/iCC display code
2) Auto-detect and full implementation of NTSC, PAL, SECAM
3) The character-graphics screen draw systems
4) Full alphanumeric character set for sprites and playfield
5) The fine horizontal/vertical scrolling system
6) The auto-animating character graphics system
7) Circle and star "swipe" screen transitions
Sokoban on top of all that as a "how to".

I'm happy enough at this stage to start releasing binaries, too.  First one is attached!
Feedback welcome. Remember it's rough and only just over a week old.

In my experience, the source/graphics often does NOT "travel" with the chain of ownership, and gets lost. An example is Boulder Dash - although First Star Software owned this for 30+ years, they did not have access to any source code from back then, nor did they have cave data. Thomas and I had to either recreate everything or find from online sources. Once we had found stuff, FSS asked us to provide it for them.
The chain of ownership of IP is often very convoluted - being bought by one company which then goes bankrupt and has assets divided into other companies which then themselves go bankrupt and no contact details available. Many IP/games have unknown ownership.  So, a commission to port a game - in my view if it's worth your while and you're protected in terms of financial terms from consequences of a cease & desist demand once/if it goes on sale... then I guess if it's enjoyable to do, why not.

My own approach has generally been to rigidly respect IP and always ask where possible. Sokoban is an interesting example; there are a gazillion copies out there, none of them licensed. I guess Boulder Dash has a ton of unlicensed versions too.  In the first case, I wrote to Sokoban's creator asking for permission to do a version and received no response. In the latter - Boulder Dash - I spent *many* months arranging for permission to release a version.

TL;DR I do not find it surprising that a modern rights-holder of a game from (say) 30+ years ago has no access to source code/graphics.

Quote from: alex_79 on 09 Jul 2025, 04:35 PM

Quote from: Andrew Davie on 09 Jul 2025, 01:42 AMIt looks pretty nice in this mode, too.

It does! The iCC mode tends to cause me a bit of eyestrain after a few minutes, especially if I'm close to the screen, so I usually prefer the plain CC mode.
Also, scrolling looks more crisp in CC mode, especially in the horizontal direction, and that, to me, compensates the less "solid" appearance compared to iCC (I always found the smooth full screen scrolling in Boulder Dash very impressive)

TY. My plan at this stage is to get a workable Sokoban done, with a few levels, and then release the source code for others to view/use. It's a good example of using the "character graphics" engine, with screen manipulation such as character changes and movement, and use of the automatic animation system (which here is doing the actual sliding of the boxes, and the pulsing of the dots).

Prior videos were using ICC (Interleaved ChronoColour).  Here's a video with ChronoColour, which of course does not flicker/shimmer at all. It looks pretty nice in this mode, too.

Hit me up if you'd like a binary to have a play with.
No game yet, but it's still fun just pushing boxes around.

I now have the "pills" (target markers) working, and you can push boxes on/off them.
It's quite smooth/nice, actually.  I might tackle the screen unpacking systems and then we'll have some playable levels. That would be good.

I did a quick what-if to see what Pengo-style graphics and gameplay might be like.


It looks OK. To make this happen I'd have to do a whole multiplex sprite system to allow multiple sprites. It's something I'd wanted to do for a while anyway. Maybe one day.

ChatGPT gave a number of reasonable suggestions for diagnosing. I know it's cut/paste, but hey you may not have tried all these...



If your legacy Intel-based macOS program can't communicate with a serial device — even though the system sees the device in System Report — here are some focused, systematic steps to troubleshoot:

⸻

✅ 1. Check the serial device's path

In System Information (Apple menu > About This Mac > System Report), look under:

Hardware > USB or Hardware > Serial

Take note of any /dev/cu.* or /dev/tty.* device nodes.

In Terminal, you can also list serial ports with:

ls /dev/cu.*

Look for something like:

/dev/cu.usbserial-1410

This is the name your program should use to open the port.

⸻

✅ 2. Permission to access the device

You may not have permission to access the serial port. Try:

sudo chmod 666 /dev/cu.usbserial-1410

(Replace the filename as appropriate.)

Also, ensure the app has Full Disk Access:
    1.    Go to System Settings > Privacy & Security > Full Disk Access
    2.    Add your legacy program manually if it's not listed.

For macOS Ventura or later, also try enabling:
    •    Developer Tools or
    •    Files and Folders > Removable Volumes (if relevant)

⸻

✅ 3. Rosetta compatibility

If your legacy app is Intel-only and you're on an Apple Silicon (M1/M2/M3) Mac:
    •    Make sure it is running under Rosetta 2.
    •    Right-click the app in Finder > Get Info > check "Open using Rosetta" if the option is available.
    •    If it's a command-line tool, you may need to launch Terminal under Rosetta:
    •    Find Terminal in /Applications/Utilities/
    •    Duplicate it
    •    Right-click > Get Info > check "Open using Rosetta"
    •    Launch that version to run the tool

⸻

✅ 4. Driver compatibility (for USB-Serial adapters)

If you're using a USB-to-serial adapter (e.g., FTDI, Prolific, CH340), you may need drivers — and old drivers might not work on newer macOS versions.

Check:
    •    Is the driver Apple-provided? (macOS supports FTDI natively now)
    •    Or did you install a 3rd-party kext? That may no longer work post-Catalina/Big Sur due to System Integrity Protection (SIP) and driver deprecation.

Uninstall old kexts and try new DEXTs (DriverKit extensions) if the vendor provides them.

⸻

✅ 5. Test port with screen or minicom

Open the port manually:

screen /dev/cu.usbserial-1410 9600

If you can connect and send data manually, the issue is likely with the legacy app itself.

You can also use:

brew install minicom
minicom -D /dev/cu.usbserial-1410


⸻

✅ 6. App may not be using correct serial port name

Legacy code might assume a device name like /dev/ttyS0 or /dev/tty.usbmodem — update or configure it to point to the actual device name shown in /dev/cu.*.

⸻

✅ 7. Console logs

Check macOS logs for permission issues or serial I/O failures:

log stream --predicate 'eventMessage contains "usb"' --info

Or use Console.app to watch live logs while you try to connect.

In this instalment, I have separated the animation system from the movement system. Sort of. Now the walk animation is handled as a stand-alone unit cycling through walk frames, and the player points to whatever animation sequence it wants. This gives continuity when moving across "squares", as the walk animation doesn't stop/start and it's no longer bound to the player movement distance/speed. It was a bit of a pain to write, and perhaps overkill... but that' sme.

Also, now everything is smooth as the game loop is 1 frame/loop. The joystick is now much more responsive. I got rid of the buffered joystick stuff which gave a "slippery/buttery" feel. Now it's good.

Can't help, but just a few musings.
1) If the USB tree shows the device, doesn't that imply the driver is there and working? Otherwise, how is the OS communicating with the device to get the info shown.
2) How is the Harmony software finding the correct USB device?  Does it iterate all USB items, or do you configure it somewhere?

The only experience I've had with MacOS and unusual USB devices is...

"If you want to get your AtariVox up and running quickly for MacOs....  If you use something like the YP-05 USB-serial converter, all you have to do is buy a male DB9 and connect the YP-05 GND to pin #8, VCC (5V) to pin #7, and TX to pin #1. It is not really necessary to worry about other pins. In a terminal window, do a ls /dev/cu*. - you should see the device appear/disapper as you plug in and remove.  Mine was "/dev/cu.usbserial-A50285BI". so that's the thing you put in "Avox serial port" under Input/Devices&Ports in Stella. And switch the Game Properties/Controllers/Right port to "Atari Vox" and you should be good to go."


So essentially, is there a "name" you have to enter for the Harmony software to find the cart to talk to?
Sorry I can't help - just trying to get some possibilities into your brain.

Quote from: TreatBucket on 06 Jul 2025, 11:38 AMSure I can give it a go.

TY, no need - I already have testers.

I realised, belatedly, that the Boulder Dash-type engine wasn't really a great match for Sokoban. The necessity of scanning the board limits the frame rate. But I really have zero reason to scan the board in Sokoban. So, I went about rewriting much of how the logic works in terms of starting box movement, triggering certain events, and overall game speed.

Now, for the most part, it runs in 1 frame (as it should!) and feels much smoother in terms of responsiveness. I'm part-way through reworking the boulder push code. The video shows lots of pushing (I did not push right, as that's borked at the moment).  As part of this, I consolidated movement code into fewer routines, essentially table-driven.

The annoying "walking in place" animations are just loose ends. I'll fix those shortly. I expect by next update the box pushing will look quite smooth and play well. There's glimpses of this towards the end of the video, where I push around a lot of boxes and it goes nice and smoothly and quickly.