Chuckie Egg 2023

[tnash]

Just downloaded both .ssd and .adl version of the game to try on my real Master, but on the point "Initializing" is on the screen it stops.
And this also happens on b2.
Any suggestions? Or did I miss something on the forum?

Cheers

Does the same for me but strangely enough works using either of the 65C816 copros, give them a try.

[SamSkivington]

Does seem a bit strange that the 816 ones work and not the 02's. I've PM'd you both a more diagnostic version of the loader program.

As for b2, the Tube ULA implementation needs a bit of work. It doesn't handle resetting the parasite CPU and sending H->P via R3 is what's breaking the game. Tom already has an item in Github to check R3. I'll add one re the reset shortly.

[strawberrytau]

]

Does the same for me but strangely enough works using either of the 65C816 copros, give them a try.

If it helps debug, I’m seeing exactly the same on a BeebFGPA Master running on a spectrum next!

Great enhancements to the game, BTW. I particularly love the music!

[SamSkivington]

Ok, I think I've got this. There is what appears to be a bug in some of the co-pro emulations in some versions of PiTubeDirect, wherein any read of $FFFC/D on the parasite reinstates the ROM, when only the Tube ULA reset signal should do that. (I'll check that assertion vs real hardware over the weekend)

Links are the same and here's my testing results with a previously breaking version of PiTubeDirect plugged into a Master 128 with MMFS 1.44.

https://samskivington.com/public/beeb-d ... gg2023.ssd

https://samskivington.com/public/beeb-d ... gg2023.adl

Chuckie Egg 2023 vs PiTubeDirect checklist
0 65C02 (fast) - works
1 65C02 (3MHz, for games compatibility) - works
2 65C102 (fast) - works
3 65C102 (4MHz, for games compatibility) - works

16 LIB65C02 64K - works
17 LIB65C02 256K Turbo - works
18 65C816 (Dossy) - works
19 65C816 (ReCo) - hangs at BL point 5

24 65C02 (JIT) - works

I'll keep trying to work out why ReCo fails for me but not other people with this combination.

strawberrytau could you give this new version a quick twirl on your BeebFPGA please?

[hoglet]

I'll keep trying to work out why ReCo fails for me but not other people with this combination.

strawberrytau could you give this new version a quick twirl on your BeebFPGA please?

Just to say I'm now tracking this issue as well (thanks BigEd) in case there is something to fix in PiTubeDirect.

Can people say what version of PiTubeDirect they are running?

(I'm currently testing with the latest PiTubeDirect Indigo Alpha 4 release)

Sam, can you be more specific about which Co Processors you are seeing a *read* of FFFC/D trigger a ROM switch. This really should not happen, nor can I think of any mechism that would make it happen.

I also see the hang on Co Pro 19, but depending on what your game is doing, that might be expected. Co Pro 19 is emulating John Kortink's ReCo 65816 which has some very funky bank and ROM switching logic. Has anyone tested this against a real ReCo 65816?

Dave

[SamSkivington]

Hey Dave.

This list is ever so slightly different (ReCo doesn't work for me) from what I had in mine before I updated it when they were starting to work after my recent change:

0. 6502 FAST FAILS
1. 65C02 3MHZ FAILS
2. 65C102 FAST FAILS
3. 65C102 4MHZ FAILS
16. LIB65C02 64K PASSES
17. LIB65C02 256 TURBO PASSES
18. 65C816 DOSSY PASSES
19. 65C816 RECO PASSES
24. 65C02 JIT FAILS

ReCo is indeed quite a different beast from the rest. I'll need more of a play with that to work out what's causing the failure.

The difference I had to make in the loader code (parasite side) was from

jmp (RESETV)

to

jmp LOCATION_POINTED_TO_BY_RESETV

Hmmm. Sure I read it somewhere earlier - how do I find the current running version of PiTubeDirect?

[hoglet]

Hmmm. Sure I read it somewhere earlier - how do I find the current running version of PiTubeDirect?

After power up, just do OLD then LIST ,10

When you say FAIL, do they all fail in the same manner?

Dave

[SamSkivington]

Ah, yes. That was it. Thanks!

In all cases apart from ReCo all the 'failing' ones were failing in the same way. ReCo fails with something else, earlier in the process so I suspect there may be something different going on with banking too, although I don't write anything between $fee0 and $feff. I'll do some deeper digging at the weekend with some simpler examples to prove or disprove the reinstating of the ROM.

Sam

[SamSkivington]

I've worked out why ReCo hangs and the others don't. It has a 'feature' where the first program it is told to execute after BREAK, even the case of after transferring the host language ROM over being told to start that, it ignores the execute command. Instead, it installs and starts its own version of BASIC.

To see what I mean, remove BASIC from the host and plug VIEW in instead. You'll see this:

Code: Select all

ReCo6502 65C816 512K (14.7 MHz)

Acorn ADFS

VIEW

>

and BASIC commands will work.

The fastest solution to this is to update my disc images to be *OPT 4 3 and add an EXECable !Boot file, which I have now done.

[hoglet]

0. 6502 FAST FAILS
1. 65C02 3MHZ FAILS
2. 65C102 FAST FAILS
3. 65C102 4MHZ FAILS
24. 65C02 JIT FAILS

How obvious are these FAILS?

I'm testing on a Master with the latest PiTubeDirect and I'm able to start the game successfully.

What version of PiTubeDirect are you running?

Dave

[SamSkivington]

Hey Dave.

Those failures were prior to the disc images I replaced the originals with yesterday. My list above (pasted here for convenience) was the current state of play last night, and the disc images have been updated this morning to hopefully resolve the ReCo issue (haven't tested on PiTubeDirect yet). They were all hanging at "Initialising", which, apart from ReCo, was as a result of the parasite seemingly not running the code that had just been put in place over the top of the Tube client when jmp ($fffc) was encountered. That jmp was replaced with an absolute addressing one, to the location that is pointed to in $fffc/d, set at build time, not run time, so no reads of $fffc/d are involved.

I won't be able to get to my Master 128 until later today so I can't tell you the version number until then. I'll also revert that jmp instruction back to indirect and, if it breaks them all again, I'll give you a link to a disc image containing that, and the relevant address to set a breakpoint at on the parasite.

Chuckie Egg 2023 vs PiTubeDirect checklist
0 65C02 (fast) - works
1 65C02 (3MHz, for games compatibility) - works
2 65C102 (fast) - works
3 65C102 (4MHz, for games compatibility) - works
16 LIB65C02 64K - works
17 LIB65C02 256K Turbo - works
18 65C816 (Dossy) - works
19 65C816 (ReCo) - hangs at BL point 5
24 65C02 (JIT) - works

[SamSkivington]

Current PiTubeDirect version: Gecko (dc67fd8)

ReCo now runs the game on PiTubeDirect with the most recent disc image (updated again this morning with a small logic tweak in the level editor).

Chuckie Egg 2023 vs PiTubeDirect checklist
0 65C02 (fast) -
1 65C02 (3MHz, for games compatibility) -
2 65C102 (fast) -
3 65C102 (4MHz, for games compatibility) -
16 LIB65C02 64K -
17 LIB65C02 256K Turbo -
18 65C816 (Dossy) -
19 65C816 (ReCo) -
24 65C02 (JIT) -

Interestingly, I can no longer replicate the hang in the loader when jmp ($fffc) is used after rewriting the Tube client which is, of course, very good news but I'm at a loss to explain what I was seeing previously.

Anyway, thanks all for your input with this.

[tom_seddon]

The player moves slightly faster in Chuckie Egg than in Chuckie Egg 2023! Is this expected? Video here: https://youtu.be/dGnjVaX4dXQ

Left is a Master 128 running original (as far as I'm aware) Chuckie Egg. Right is a Master Turbo running Chuckie Egg 2023.

--Tom

[SamSkivington]

Hey Tom

Interesting experiment. Thanks!

It's been a while but I do now recall tweaking the system clock ever so slightly at one point because the movement sound seemed a bit odd in whichever emulator I was using at the time. It's possible I didn't remove that tweak because it was such a small adjustment and I had moved on to other parts of the program. The player definitely isn't moving any slower in relation to everything else. If that were the case a large percentage of telemetry tests would have failed. None did.

I'll take a look over the weekend to see whether that timer tweak is still there, and whether the sound is still fine without it.