Unicorns season: Prince of Persia for the A8!

[Mazzspeed]

3 hours ago, rensoup said:

the C64 version uses 64KB of RAM and 512KB of ROM

As far as I'm aware, the C64 version utilizes Ultimax mode, it doesn't need the C64's inbuilt 64k of ram. You can't bank memory from the cart to system ram the way you do on the A8, you have to use DMA if the cart is used purely as storage which creates issues as the DMA pin on the expansion port halts the CPU as the DMA controller built into the REU transfers data at 1MB/sec to system ram - Which isn't ideal in this particular situation.

 

Using Ultimax mode you can tell the PLA to look purely to the cart's memory as opposed to the C64's memory, it's how the 1541 UII+ can switch into the loader/menu at any point while running software and then drop straight back to the running application like nothing had happened.

 

https://www.lemon64.com/forum/viewtopic.php?t=40157&start=0

 

2 hours ago, rensoup said:

No, I am saying some newer devices don't seem to emulate real drives properly.

I know exactly what you're claiming, I'd like to know who's provided evidence that sector retries aren't an issue using real FDD's, especially during the second phase of loading after the intro/title screen - Because I haven't seen anyone provide such evidence, and if they did it would be interesting to know how they did so as you'd need a scope to highlight such problems regarding real hardware as far as I'm aware.

 

2 hours ago, DrVenkman said:

With @DjayBee's tip the other day to use CopyMate 4.4, I wrote the full-game "bugfix" version to a double-density floppy disk (using one of my Happy 1050's) and ran it on two different NTSC machines for a couple hours without any obvious problems.

 

But I gotta say, the drive heads sure do grind around a lot in attract/demo mode. ?

All I can say is I can run the DD variant fine from either RespeQt or FujiNet at SIO 1x, but watching the log in real time you can see the sector retries that were previously really bad on the first part on the loading sequence but mostly rectified. So if they were rectified in the first part of the loading sequence, I fail to see how RespeQt is at fault during the second part of the loading sequence. Such an argument doesn't hold up to logical scrutiny.

Edited July 8, 2021 by Mazzspeed

[Mazzspeed]

3 hours ago, Faicuai said:

 

That's seems correct, based on all the testing (and burin-ins), since pretty early versions... and even with more exotic, timing-impacting features enabled on some of those drives. 

 

Don't like or don't want loading from an authentic, legacy SIO-device? No worries, switch to .any of the available CAR images. They work just fine. 

 

Anything else is just fantasizing "Alice-in-Wonderland" style. (I already learned my own lesson about Xbios and its true purpose, the hard-way, EONS ago... )  

 

To the above extent, a good multi-cart should be the very first plug-and-play companion device on anyone's arsenal, and capable of significantly augmenting the capabilities of an otherwise stock machine... and effortlessly. 

 

Good news is PoP will be great for AVG, SIDE3, Ultimate/SD and/or The!Cart sales !!!

 

 

Well Mr word salad, I never stated the game didn't load fine. Comprehension is important.

 

Furthermore, the .CAR version has been acknowledged. So if you don't have anything of value to add to the conversation, shut up.

 

2 hours ago, rensoup said:

SCR has less than 20 files on disc (which is ED) while PoP has more than 60 files and is using DD. I don't know how your device works regarding caching.

The fact that SCR has no retries could be linked to those differences or it could be the mouse loading icon isn't fast enough, still it shouldn't stop loading because it never does on real drives.

 

But sure let's see a video with a respeqt log, fastestmouse version, with the mouse on the side of the screen and its animation frozen 

OK.

 

With respect (should that be RespeQt!), I never stated the game stops loading, I implied that the real time logs under RespeQt are showing sector retries - Not anywhere near as bad as they were, but still enough that loading times would be impacted.

 

Now:

 

What's the fastmouse version? Because I'm using the PoP_DD_20210619_bugfix version. Is that the fastmouse version as I can't see any mention of the term 'fastmouse' on page 1? If so, I have a video ready.

Edited July 8, 2021 by Mazzspeed

[rensoup]

2 hours ago, DrVenkman said:

But I gotta say, the drive heads sure do grind around a lot in attract/demo mode. ?

Thanks for confirming that... remember though the bugfix version doesn't have the fast mouse so it will still cause retries... any chance you could try with the fastestmouse version ?

[Mazzspeed]

9 minutes ago, rensoup said:

Thanks for confirming that... remember though the bugfix version doesn't have the fast mouse so it will still cause retries... any chance you could try with the fastestmouse version ?

Could the possibility exist that you haven't updated the first page? Because I don't see a fastmouse version.

 

[Mazzspeed]

You might want to move the Fastmouse variant a little higher in the list when the list is in date order, people are going to miss is as it's assumed that all downloads down that low are outdated legacy variants.

 

Having said that, I'm mostly seeing sector retries in the second half of the loading stage after the intro/credits portion of the loader, which the fastmouse demo doesn't load - It simply loops the first part of the loading process.

[rensoup]

58 minutes ago, Mazzspeed said:

As far as I'm aware, the C64 version utilizes Ultimax mode, it doesn't need the C64's inbuilt 64k of ram. You can't bank memory from the cart to system ram the way you do on the A8, you have to use DMA if the cart is used purely as storage which creates issues as the DMA pin on the expansion port halts the CPU as the DMA controller built into the REU transfers data at 1MB/sec to system ram - Which isn't ideal in this particular situation.

 

Using Ultimax mode you can tell the PLA to look purely to the cart's memory as opposed to the C64's memory, it's how the 1541 UII+ can switch into the loader/menu at any point while running software and then drop straight back to the running application like nothing had happened.

I don't know anything about the C64 but at some point @mrsid seemed to be using regular RAM:

 

https://popc64.blogspot.com/2011/11/part-seven-hitting-memory-and.html#more

 

 

1 hour ago, Mazzspeed said:

I know exactly what you're claiming, I'd like to know who's provided evidence that sector retries aren't an issue using real FDD's, especially during the second phase of loading after the intro/title screen - Because I haven't seen anyone provide such evidence, and if they did it would be interesting to know how they did so as you'd need a scope to highlight such problems regarding real hardware as far as I'm aware.

Partial Mistake on my part, there may be 2 causes of retries (but they shouldn't never be fatal). 

 

1. due to slow icon anim (but shouldn't happen with fastest mouse)

2. hardware (slow network, conflict FJ + SIO2SD, ?)

 

51 minutes ago, Mazzspeed said:

What's the fastmouse version? Because I'm using the PoP_DD_20210619_bugfix version. Is that the fastmouse version as I can't see any mention of the term 'fastmouse' on page 1? If so, I have a video ready.

it is at the very bottom of the 1st post .

 

 

[rensoup]

7 minutes ago, Mazzspeed said:

You might want to move the Fastmouse variant a little higher in the list when the list is in date order, people are going to miss is as it's assumed that all downloads down that low are outdated legacy variants.

it is just a test so I didn't want to confuse people

 

8 minutes ago, Mazzspeed said:

Having said that, I'm mostly seeing sector retries in the second half of the loading stage after the intro/credits portion of the loader, which the fastmouse demo doesn't load - It simply loops the first part of the loading process.

not sure what you mean it should loop the full intro sequence

[rensoup]

2 hours ago, tschak909 said:

Is the latest build running with FujiNet? (I've been away working on other things).

 

If not, let's try doing an ATX version. That kicks in real disk drive timing.

I think it works with some configs?

 

Doing an ATX is only possible with the SD version ?

[Mazzspeed]

14 minutes ago, rensoup said:

I don't know anything about the C64 but at some point @mrsid seemed to be using regular RAM:

In the blog you linked he actually highlights the DMA issues I mentioned and states that his original idea of using the C64's inbuilt RAM just wasn't working. The fact that a .CRT variant has been released indicates the solution was to use Ultimax mode, that way you bank within the cart itself and just tell the PLA to look to the cart as system memory - I have no doubt the game is a full 128k Apple port.

 

12 minutes ago, rensoup said:

it is just a test so I didn't want to confuse people

As a very logical person, I find it odd that a vastly newer test is at the bottom of the screen. Don't worry, when my Wife cleans up she puts things at the bottom of a box, as a result I can never find anything as I assume that if it was just packed away it should be at the top of the heap.

 

12 minutes ago, rensoup said:

not sure what you mean it should loop the full intro sequence

That's the problem, it's only the intro sequence. I'm seeing retries as the game loads after the intro sequence. Here's a video, ignore the first half of the loading sequence (which has very few retries anyway after the last round of fixes):

 

https://youtu.be/Dv-sw1IjVjo

Edited July 8, 2021 by Mazzspeed

[Mazzspeed]

33 minutes ago, rensoup said:

2. hardware (slow network, conflict FJ + SIO2SD, ?)

That's definitely not the issue, if that was the case the logs under RespeQt would show speed polling and errors. RespeQt is definitely showing sector retries.

[zbyti]

Yeah… Now I've read it all and I have to say… Gosh… how difficult life is for A8 game developers.

 

Full of gratitude users waiting for a breakthrough game polish every detail with the hands of the single programmer

Edited July 8, 2021 by zbyti

[Mazzspeed]

4 minutes ago, zbyti said:

Yeah… Now I've read it all and I have to say… Gosh… how difficult life is for A8 game developers.

 

Full of gratitude users waiting for a breakthrough game polish every detail with the hands of the single programmer

I think the point you're missing is that the A8 isn't easy to port to due to the fact it is a very fragmented system running a number of ram configurations and operating systems, this has always been an issue regarding the A8 as a platform.

 

What's complicating things in this instance is the absolute nessecity to limit the game to 128k when only one A8 in the whole lineup actually comes standard with 128k. I don't see many people going to the trouble of expanding their machine by just 64k for a total of 128k, if most are going to go to the trouble of memory expansions they'll usually aim for 256 or 512k at minimum.

[+DjayBee]

3 hours ago, Mazzspeed said:

Could the possibility exist that you haven't updated the first page? Because I don't see a fastmouse version.

 

Could the possibility exist that prolific writers who have to comment on everything, not necessarily have to be prolific readers?

 

My somewhat uneducated guess is: Yes

Part of the fun for these people must be to rant on things they did not notice due to this. Afterwards they can complain that they had not been explicitly been pointed to the missed/ignored information.

 

It has been mentioned several(!) times in this very thread that this test release exists, that it later had been copied to the first post and that it is at the very end of that post.

[Mazzspeed]

21 minutes ago, xxl said:

do you even understand what is said to you? Where did I use RespeQt? Read with understanding.

There is nothing wrong with my SIO2PC adapter, the assumption is essentially laughable. If there is any problem, it's got to do with your xbios implementation as the systems showing issues are quite varied and not just based around SIO2PC adapters.

 

It's interesting how according to yourself everything else is at fault, and not your code at the center of the mess. What I've explained to you before, and something you really need to understand, is that because English is not your first language your replies are near impossible to decipher with correct context - Especially when you keep abbreviating words and adding words of no relevance whatsoever. Therefore I recommend growing up, dropping the attempt at sarcasm, and actually contributing to conversation minus the hyper inflated ego.

 

You're not doing yourself any favors. You have no respect from myself whatsoever, I don't care what you believe of yourself.

Edited July 8, 2021 by Mazzspeed

[+CyranoJ]

Thanks for the last few pages, gonna go back to the calm in the Jaguar forum now.

 

@rensoup thank you for your time, skill and dedication to bring this game to the a8.

@everyone else bitching.  Grow the f**k up before you scare away another dev.

@moderators - clean up in aisle three!

[zbyti]

3 hours ago, Mazzspeed said:

I think the point you're missing is that the A8 isn't easy to port to due to the fact it is a very fragmented system running a number of ram configurations and operating systems, this has always been an issue regarding the A8 as a platform.

 

What's complicating things in this instance is the absolute nessecity to limit the game to 128k when only one A8 in the whole lineup actually comes standard with 128k. I don't see many people going to the trouble of expanding their machine by just 64k for a total of 128k, if most are going to go to the trouble of memory expansions they'll usually aim for 256 or 512k at minimum.

I think that: After two years of my humble attempts to write something for that platform I'm quite aware about some difficulties. Like @xxl finally I decided to support only stock configurations. If my soft will works on moded hardware - fine, if not - no trouble for me.

Edited July 8, 2021 by zbyti

[+CyranoJ]

52 minutes ago, zbyti said:

I think that: After two years of my humble attempts to write something for that platform I'm quite aware about some difficulties. Like @xxl finally I decided to support only stock configurations. If my soft will works on moded hardware - fine, if not - no trouble for me.

Same attitude I have with the Jaguar and emulators. 

 

It's not for me to write code differently so it works on an emulator, it's for the emulator author to make the emulator behave accurately. 

[+DrVenkman]

7 hours ago, rensoup said:

Thanks for confirming that... remember though the bugfix version doesn't have the fast mouse so it will still cause retries... any chance you could try with the fastestmouse version ?

I’ll try to create a new test floppy tonight with the “fastestmouse” version and let you know. 

[Mr Robot]

13 hours ago, Mazzspeed said:

Semantics my friend, feel free to substitute .CAR as you please.

You mean substitute correct for incorrect? Sure.

[Faicuai]

6 hours ago, Mazzspeed said:

What's complicating things in this instance is the absolute nessecity to limit the game to 128k when only one A8 in the whole lineup actually comes standard with 128k.

This is not a complication, nor any other imaginary rationalization on this subject, as such requirement is a target design-premise, stated up-front an eternity ago, from the get-go.

 

On the Atari platform, there are multiple implications when choosing banked-rom vs. banked-ram, in spite of both being natural (and regularly used) configuration options. 

 

Atari PoP is a port of BBC MASTER PoP, and there, its coding team chose 128k as minimum requirement over the seemingly "impotent" (but more popular) 32KB BBC Micro config.

 

Normally, we justify HW expansions with SW that actually requires them. And just watching PoP unfolding on the screen is more than enough motivation to finally get that bit of extra RAM to break the 64KB barrier. There are several, affordable RAM expansions that will work plug-and-play via PBI on the 800XL, efforlessly.

 

 

[_The Doctor__]

13 hours ago, Mazzspeed said:

I'm sorry mate, but a rebuttal comprising of 'Bullshit' doesn't place you on the soap box in this regard. Such comments aren't really worthy of a reply TBH.

 

However, once again with all due respect, at least I have a working .CAR image. Thank you for your hard work, no sarcasm intended. This thread actually highlights the numerous issues developers faced in the day when considering ports to release on the A8 platform, and they had nothing to do with Jack Tramiel.

wtf does jack tramiel have to do with this, more sideshow crap... it's never clear where the conversation is going except that you come across poorly and it's always going to end up with a tramiel or some other machine reference for absolutely no reason.

 

-=>The game is great, one of the best ports on any retro platform!

-=>The game is going out in multi format and if you can pick whatever you want and enjoy it at whatever pace you like.

-=>The xbios has been key to us to having POP, as it affords us the means to get just about every byte of space we can for game code and allows for flourishes like animated loading sequences & depending on coders needs even sound. These are key nostalgia points and again, it's cool to see on the Atari.

-=>The 130XE memory requirement isn't a limitation, almost anyone in a club back in the day either had one or added a memory card/upgrade to their 800's and XL's. Compyshop, Newell, Rambo(w/Anticmod), and Qmeg... were the defacto standards before some other platforms even came along. Although that's what we all used/did- Many software devs caught on to that fact a little late, and it may have cost them.

 

[massiverobot]

14 hours ago, rensoup said:

I'm really getting fed up with people saying the game doesn't load reliably when their devices cause retry errors while real drives don't.

 

This has been going on for pages...  and to top it off FJC has only posted junk in here.

 

To reiterate: 

 

The game loads fine on real drives.

 

If it doesn't load under certain newer configs It's quite likely your config has issues emulating real drives timings.

 

 

Amazing job, thanks ren for the port.

 

It works great via FN and my TNFS server (I just copied up the bugfix atr to my own TNFS server on DigitalOcean) using the NUC+.

 

I would suggest that 128 is now clearly the standard for modern Atari8bit game play. Everyone that is doing interesting things with their Atari in 2021 has at least 128k, probally much more.

 

I applaud @rensoup for the work and using 128 to make the game playable and interesting.

 

[jaybird3rd]

7 hours ago, CyranoJ said:

@moderators - clean up in aisle three!

Time to break out the mop, I guess!

 

To those who insist on posting insulting and childish comments—and you know who you are—please stop it for everyone's sake or you'll get kicked out of the thread.

[ivop]

Just ignore the haters. Rensoup did a fantastic job! 128kB, so what? Everybody and their mom and her dog have at least one memory upgraded machine.

 

As for the C64 .CAR¹ version, if you need a 1541 UII+ for that, you first need to sell a kidney to afford that

 

BTW did I already say that Rensoup did a fantastic job!!

 

¹ Just semantics

Edited July 8, 2021 by ivop

[Faicuai]

26 minutes ago, ivop said:

Rensoup did a fantastic job!

...of course, and extensive to the rest of the WHOLE team.

 

Atari 8-bit PoP port already looks way better than the BBC-port it comes from!

 

Kudos!! ????