Jump to content
IGNORED

Unicorns season: Prince of Persia for the A8!


rensoup

Recommended Posts

As if everyone has a "basic" set-up in 2021.
 
What _is_ a "basic set-up" ? Atari 600XL with 1010 cassette drive ? 


Clearly that wouldn’t cut it in 1986. It would be an Atari 130XE with 1050 Disk Drive since the game requires 128k.
Link to comment
Share on other sites

17 minutes ago, DrVenkman said:

That's only valid for people using RespeQt. It has no bearing on my situation, using FujiNet on all my ATR attempts lately. 

Just pointing out that respeqt's emulation may not be perfect...

7 minutes ago, DrVenkman said:

Blue (NO MOUSE) of Death again on the 800 after about an hour, even with the mouse off the screen completely to the right.

I think it may be worth having the respeqt people take a look a this at this point, they may perhaps help find who the culprit is 

Link to comment
Share on other sites

17 minutes ago, rensoup said:

Just pointing out that respeqt's emulation may not be perfect...

I think it may be worth having the respeqt people take a look a this at this point, they may perhaps help find who the culprit is 

These days there aren't any respeqt people as such - Joey Z was the lead developer several years ago but he's off living his real-world life now. ebiguy, themontezuma and a couple others did patches and fixes that have been incorporated into subsequent "unofficial" updates, but since none of those folks is interested in forking the open-source project and creating a new project and actively maintaining it, development is basically stalled.

 

All the real interesting SIO development in recent years has been with SDrive-MAX and more recently FujiNet, both self-contained (no modern computer required) SIO emulation devices. That said, I guess I can drag my SDrive-MAX out of storage and try to see how it handles these ATRs. I'd have to dig up my PSU for it though. Hmm ... wonder what I did with that? 

 

EDIT: Okay, I've loaded up the game via SDrive-MAX now and I'll see if it crashes.

  • Like 2
Link to comment
Share on other sites

1 hour ago, DrVenkman said:

I'm testing via FujiNet, which handles timing-sensitive copy-protected ATX files basically perfectly; such games can and do run for hours straight on any of my machines.

This is only true for ATX images. ATRs are always somehow accelerated with any of the disk emulators because at least track stepping happens immediately.

 

Therefore if you really want to test this "like a 1050" you need an ATX image of the disk which currently unfortunately works only in SD or ED but not DD. At least I do not know of any DD ATX file.

 

Since I don't know which version of PoP you are currently testing, I attached two images of freshly formatted disks with typical 1050 interleave and track skewing. You should be able to copy the needed PoP image onto these images with a sector copier inside Altirra and then save the result as an ATX for use on Fujinet.

 

_empty_skew-sd.atx _empty_skew-ed.atx

  • Like 1
Link to comment
Share on other sites

1 minute ago, DjayBee said:

This is only true for ATX images. ATRs are always somehow accelerated with any of the disk emulators because at least track stepping happens immediately.

 

Therefore if you really want to test this "like a 1050" you need an ATX image of the disk which currently unfortunately works only in SD or ED but not DD. At least I do not know of any DD ATX file.

 

Since I don't know which version of PoP you are currently testing, I attached two images of freshly formatted disks with typical 1050 interleave and track skewing. You should be able to copy the needed PoP image onto these images with a sector copier inside Altirra and then save the result as an ATX for use on Fujinet.

 

_empty_skew-sd.atx 97.86 kB · 2 downloads _empty_skew-ed.atx 140.36 kB · 2 downloads

Very interesting. Does @tschak909 know about the inaccurate emulated track stepping timing? Or @mozzwald? I'd be curious about their thoughts, given the work they've put into FujiNet over the last couple years.

 

As for tests with PoP. I've been testing the most recent test demos posted in the thread, all DD ATRs. They load substantially more quickly than the SD versions of the full release and don't require disk swapping. Since FujiNet is far and away the most popular SIO device being made these days, it would seem to be a big deal that PoP doesn't play nice with it for more than 30 - 60 minutes at a stretch. I know there are at least two US-based retailers who have sold many hundreds of these devices, each. And apparently sales are only increasing. 

Link to comment
Share on other sites

6 minutes ago, DrVenkman said:

Very interesting. Does @tschak909 know about the inaccurate emulated track stepping timing? Or @mozzwald? I'd be curious about their thoughts, given the work they've put into FujiNet over the last couple years.

 

As for tests with PoP. I've been testing the most recent test demos posted in the thread, all DD ATRs. They load substantially more quickly than the SD versions of the full release and don't require disk swapping. Since FujiNet is far and away the most popular SIO device being made these days, it would seem to be a big deal that PoP doesn't play nice with it for more than 30 - 60 minutes at a stretch. I know there are at least two US-based retailers who have sold many hundreds of these devices, each. And apparently sales are only increasing. 

yeah, if there's something we need to address in the firmware, let's get it fixed! :)

 

-Thom

  • Like 3
Link to comment
Share on other sites

8 minutes ago, DrVenkman said:

Very interesting. Does @tschak909 know about the inaccurate emulated track stepping timing? Or @mozzwald? I'd be curious about their thoughts, given the work they've put into FujiNet over the last couple years.

 

As for tests with PoP. I've been testing the most recent test demos posted in the thread, all DD ATRs. They load substantially more quickly than the SD versions of the full release and don't require disk swapping. Since FujiNet is far and away the most popular SIO device being made these days, it would seem to be a big deal that PoP doesn't play nice with it for more than 30 - 60 minutes at a stretch. I know there are at least two US-based retailers who have sold many hundreds of these devices, each. And apparently sales are only increasing. 

DrVenkman,

 

Have you tried RespeQt at standard SIO or is that not an option?

Link to comment
Share on other sites

9 minutes ago, Mazzspeed said:

DrVenkman,

 

Have you tried RespeQt at standard SIO or is that not an option?

The only device I have capable of running RespeQt currently is my main Win10 PC and it's not generally close to my Atari stuff. 

 

In any case, the issue isn't LOADING the game, it's that it crashes eventually during file access with the Blue Mouse of Death, usually between 30 - 60 minutes after loading. And I'm not the only person experiencing this, just the one still obstinately testing every test build Rensoup provides on my various NTSC devices to see how they perform. Jon had similar problems with a prior build and I'm pretty sure he wasn't loading via FujiNet - the details are a page or two back by now.

 

EDIT: Jon was loading via RespeQt locked at 1X SIO speeds and got the same Blue Mouse of Death (plus bonus PMG corruption!) in this post from two days ago.

Link to comment
Share on other sites

1 minute ago, DrVenkman said:

The only device I have capable of running RespeQt currently is my main Win10 PC and it's not generally close to my Atari stuff. 

 

In any case, the issue isn't LOADING the game, it's that it crashes eventually during file access with the Blue Mouse of Death, usually between 30 - 60 minutes after loading. And I'm not the only person experiencing this, just the one still obstinately testing every test build Rensoup provides on my various NTSC devices to see how they perform. Jon had similar problems with a prior build and I'm pretty sure he wasn't loading via FujiNet - the details are a page or two back by now.

I honestly don't think Jon has a FujiNet. The fact the game crashed in a similar fashion for Jon is interesting as I'm sure all his machines would be PAL.

 

What's also interesting is the fact that Jon's machines both crashed on the DD version running RespeQt.

Link to comment
Share on other sites

1 hour ago, DjayBee said:

Since I don't know which version of PoP you are currently testing, I attached two images of freshly formatted disks with typical 1050 interleave and track skewing. You should be able to copy the needed PoP image onto these images with a sector copier inside Altirra and then save the result as an ATX for use on Fujinet.

this is the latest one:

 

 

 

Link to comment
Share on other sites

1 hour ago, Mazzspeed said:

I honestly don't think Jon has a FujiNet. The fact the game crashed in a similar fashion for Jon is interesting as I'm sure all his machines would be PAL.

 

What's also interesting is the fact that Jon's machines both crashed on the DD version running RespeQt.

he was probably still using the version with the loading icon that took too long to display 

  • Like 1
Link to comment
Share on other sites

1 hour ago, DjayBee said:

Since I don't know which version of PoP you are currently testing, I attached two images of freshly formatted disks with typical 1050 interleave and track skewing. You should be able to copy the needed PoP image onto these images with a sector copier inside Altirra and then save the result as an ATX for use on Fujinet.

btw you can make a SD version out of the DD one by just placing the right files on the disks (from the latest version of course)

Link to comment
Share on other sites

7 hours ago, DrVenkman said:

Very interesting. Does @tschak909 know about the inaccurate emulated track stepping timing? Or @mozzwald? I'd be curious about their thoughts, given the work they've put into FujiNet over the last couple years.

 

7 hours ago, tschak909 said:

yeah, if there's something we need to address in the firmware, let's get it fixed! :)

 

-Thom

Sorry to be rude but this is pure and utter nonsense.

The behaviour is identical to a trackbuffering Happy drive. And I guess that nobody is questioning these.

Also the difference in timing is only BETWEEN SIO accesses and not DURING these.

 

My point was that @rensoup somehow seems to overstretch the time available for interrupts during SIO accesses. Only for this particular edge case it might help to test with the somehow slower timing of a real 1050.

This seems to happen only on real hardware which most probably does not have exactly repeating timings for these interrupt due to "physics of real hardware" (compared to an emulator like Altirra).
 

Two sentences to the @xxl is guilty of all bad including bad weather and bad breath fraction here on the forum:

Doing interrupts during SIO transfers like PoP does is not possible with standard SIO which probably also rules out the use of PBI disks. It is similar to Lucasfilm's RoF and Ballblazer which have sound playing while loading the game.

 

Edited by DjayBee
sound instead of music
  • Like 2
Link to comment
Share on other sites

if I have more time, I will answer a few observations, a few of mine:
Does the connected device react to COMMAND lines at all?
I think not.

I wonder how many devices do not take into account the COMMAND line, probably all connected via USB and BT ;-)

there may also be a case of interruption of transmission in the command frame before "C" when the device starts sending data - this is the critical moment (results from several disadvantages that unfortunately the SIO protocol developed by atari has and later even further distorted UltraSpeed).
I wonder if the device will stop sending after the COMMAND setting ... there are more questions ...

and by the way, I hope there will be an element that will need to be improved in xB because I have a few elements that I would like to change / add and I do not have the opportunity heh.

also regarding communication: on atari standard transmission (IRQ interrupt) and with OS on, it is impossible to make a stable NMI - it annoys me very much and that's why I made a driver that provides 100% stable NMI during communication.

Edited by xxl
  • Like 1
Link to comment
Share on other sites

1 hour ago, xxl said:

if I have more time, I will answer a few observations, a few of mine:
Does the connected device react to COMMAND lines at all?
I think not.

I wonder how many devices do not take into account the COMMAND line, probably all connected via USB and BT ;-)

there may also be a case of interruption of transmission in the command frame before "C" when the device starts sending data - this is the critical moment (results from several disadvantages that unfortunately the SIO protocol developed by atari has and later even further distorted UltraSpeed).
I wonder if the device will stop sending after the COMMAND setting ... there are more questions ...

and by the way, I hope there will be an element that will need to be improved in xB because I have a few elements that I would like to change / add and I do not have the opportunity heh.

also regarding communication: on atari standard transmission (IRQ interrupt) and with OS on, it is impossible to make a stable NMI - it annoys me very much and that's why I made a driver that provides 100% stable NMI during communication.

Well if FujiNet doesn't respond to COMMMAND at all, they certainly went to great lengths to include it as a useless feature in the web GUI...

 

5cCxr8O.png

Link to comment
Share on other sites

what he was talking about was whether a device stops sending data when atari drops the command signal (goes to 1) during the data transfer...

(not that it should matter, it's better if it does because it will recover faster from retries if the retry is being sent before the transfer is done (which is happening with xbios))

  • Like 1
Link to comment
Share on other sites

1 minute ago, tmp said:

what he was talking about was whether a device stops sending data when atari drops the command signal (goes to 1) during the data transfer...

(not that it should matter, it's better if it does because it will recover faster from retries if the retry is being sent before the transfer is done (which is happening with xbios))

Naturally I'd assume that if the devs went to the trouble of adding an option to set COMMAND correctly depending on the FTDI serial to USB board used, they'd also go to the trouble of making sure FujiNet actually makes use of it (actually, this is FujiNet-PC. But I doubt the actual device would be any different regarding it's COMMAND implementation, you just wouldn't get the option to change it's method of implementation via the web GUI).

 

Perhaps @tschak909 can provide more insight?

 

Judging from the snide remark regarding BT and USB, I get the impression a certain purist believes we should all be using floppy drives at SIO 1x.

  • Confused 1
Link to comment
Share on other sites

13 hours ago, rensoup said:

Just pointing out that respeqt's emulation may not be perfect...

Been long-testing DD image content (both in .ATR and magnetic-media format). I am still at version "bugs-fixed" with chubby-mouse progress-indicator.

 

It works perfectly on NUXX SDrive and Indus/GT (including RamCharger sector+track buffering). No problems I could find, even in close-to 120 mins. tests.

 

Now, my own tests on RespeQt have been failing one way or another (where above devices do perfectly), at multiple junctures. It smells to me there is a REAL problem with RespeQt SIO-emulation chain, as a whole, whether at its physical or logical layers, and we are chasing ghosts by just crippling that mouse at every iteration... like dividing sub-atomic particles... just to find even smaller ones right after... Don't have Fujinet yet (I've held off waiting patiently for HW maturity to meet my expectations), but if it fails as RespeQt, then there maybe a problem with it, too (no worries since Fujinet has solid support, anyway)

 

In the event that a SIO-implementation issue is confirmed on RespeQt (and/or Fujimet), well, we may have not been able to detect it unless X-Bios was part of the equation (and that is a GOOD thing, in my books).

 

One way or another, sooner-than-later we may have to stop the ghost-chasing... and call it a day, so we can move on.

 

 

  • Like 1
Link to comment
Share on other sites

there were days when game needed to run on 1050/810 and maybe with Happy... ;) then came SIO2SD and nowadays? I feel like being in Windows ecosystem and driver mania of Win 95....

I might be too manager like... but if it runs on 85% of all users hardware (cart/disk/IO emu) so wtf?

  • Like 1
Link to comment
Share on other sites

1 hour ago, tmp said:

i give up

Well so do I.

 

As stated, naturally the assumption is that if the web GUI has the option for COMMAND via the SIO2USB board, than the assumption is that the device stops data flow when command goes high. That was my implication in the posted screenshot, and here you are correcting me and telling me what a certain member was implying?! I'm not too sure why you're of the opinion such a fact needed explaining?

 

However, as stated, hopefuly a developer can clear up as to whether the web GUI option in FujiNet-PC does in fact mean that COMMAND is implemented correctly to Atari specifications.

 

At the end of the day, a lightweight DOS replacement is useless if it only works on a particular individuals 130XE with a floppy drive. Make no mistake, there are issues here that are apparent on nearly stock machines, there's no logical pattern to the fault using the DD ATR that I can see at all.

 

39 minutes ago, Faicuai said:

Been long-testing DD image content (both in .ATR and magnetic-media format). I am still at version "bugs-fixed" with chubby-mouse progress-indicator.

 

It works perfectly on NUXX SDrive and Indus/GT (including RamCharger sector+track buffering). No problems I could find, even in close-to 120 mins. tests.

 

Now, my own tests on RespeQt have been failing one way or another (where above devices do perfectly), at multiple junctures. It smells to me there is a REAL problem with RespeQt SIO-emulation chain, as a whole, whether at its physical or logical layers, and we are chasing ghosts by just crippling that mouse at every iteration... like dividing sub-atomic particles... just to find even smaller ones right after... Don't have Fujinet yet (I've held off waiting patiently for HW maturity to meet my expectations), but if it fails as RespeQt, then there maybe a problem with it, too (no worries since Fujinet has solid support, anyway)

 

In the event that a SIO-implementation issue is confirmed on RespeQt (and/or Fujimet), well, we may have not been able to detect it unless X-Bios was part of the equation (and that is a GOOD thing, in my books).

 

One way or another, sooner-than-later we may have to stop the ghost-chasing... and call it a day, so we can move on.

 

Well that's funny, because using RespeQt at SIO 1x, I've experienced no issues at all from the fixed loading animation release onwards. Even considering the earlier release pre animation fix, the game loaded fine at slower than insanely slow speed with no crashing at all.

 

So I'd say the 'ghost chase' is ongoing.

Edited by Mazzspeed
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...