Unicorns season: Prince of Persia for the A8!

[+DrVenkman]

As a follow-up to my earlier posts, with FJC's latest SIDE3 Loader fixes posted this morning, all the versions of the .CAR posted by @rensoup on page 1 and the "DLI fixed" demo versions posted a couple days ago now load perfectly on my NTSC 1200XL+U1MB, as well as on my Incognito 800. So, too, does the "no KIL" test version posted by @Wrathchild. 

 

I don't have any other machines with >64K and a cartridge port to test with except my 1088XEL, but it's not set up ATM. 

[+CharlieChaplin]

Okay,

 

did some more POP tests with the disk versions and evil as I am, I also did some WAV recordings of my Speedy 1050 floppy loading noise. Warning: Since Pokey is switched off with Poke 65,0/LDA 65,0

I had to make the recording much louder, take care of your ears!

 

-----

 

old version (two days ago), SD, Side A (Girl): loads very slow and has lots of pauses / retries, you can clearly hear and see them in the WAV

 

old version (two days ago), SD, Side B (Mouse): loads normally, no pauses / no retries, clearly visible in the WAV

 

new version (yesterday, DLI...), SD, Side A (Girl): loads slow, with less pauses / less retries - but the pauses and retries are still there and visible in the WAV

 

new version (yesterday) SD, Side B: not possible to load (you already informed us, why)

 

-------

 

old version (two days ago), DD, (Girl): same as the SD version, think it loads even slower, not only because of DD, but there are many many more pauses / retries than in the SD version, take a look at the WAV

 

old version, DD, (Mouse): same as SD version, loads without pauses / retries - see the WAV

 

new version (yesterday, DLI...), DD, (Girl): same as SD and therefore less pauses / less retries, but the pauses and retries are still there

 

new version, DD, (Mouse): no pauses / no retries as it seems

 

-----

 

So, the dancing girl still makes loading much slower than the mouse (slower = appears slower than 1x SIO due to the pauses/retries). Hmmm, maybe you should get rid of the dancing girl and use the mouse during the whole loading process?  Or simply use the Faicuai method with screen=off during loading for better benchmarks, ermm, better loading speed...?!? Suggestion: The disk versions could load faster and show no loading animation (or just the mouse), while the cart versions could show one or both loading animations - just a thought or suggestion. And now listen to these awful WAVs...  

 

POP_loading_old.zip POP_loading_new.zip

[+DrVenkman]

Well, not being content to leave well enough alone, I decided to try the PoP .CAR files on my 1088XEL from the SIDE3. Unfortunately, they all freeze after 10-12 "hip bumps" from the dancing girl, always to the viewer's left (her right). I realized my XEL hadn't yet been updated to Jon's latest firmware so I flashed the U1MB XEL firmware and tried again but as expected it made no difference. 

 

As far as I can tell, the U1MB settings are generally the same across my devices, though I tried various combos. None of them allowed loading the .CAR files from my XEL using the SIDE3 even though the same SIDE3 works for loading them on my 1200XL and my Incognito 800. Weird. 

 

EDIT: Neither the SD nor DD versions of the DLI test ATRs posted the other day will load over FujiNet to my 1088XEL either, using the same FujiNet device that worked with my earlier tests on my 1200XL. Both versions freeze on every attempt at some point during loading, the SD version froze before getting to the disk swap prompt. 

[rensoup]

8 hours ago, globe said:

During the last minute countdown the timer blinks, in some rooms it's more noticeable than in others (timeout1.avi, timeout2.avi)

I'd never even tested that to be honest! 

 

My font plotter is pretty slow (proportional font) which isn't a problem most of the time because text is seldom plotted... except when the clock runs out... I'd need to double buffer that but that'd require 8*32 = 256 bytes for a very minor issue.

 

8 hours ago, globe said:

Level 5 - pillar base outlines started to blink as soon as I climbed down to get HP flask and didn't stop till I climbed back up (blinking pillar bases.avi)

Barely noticeable but strange.

That may be a bug in the original, the background restore procedure is pretty funky...

 

8 hours ago, globe said:

Level 7 - after getting knocked down by a guard, he didn't follow and stayed glued to the edge of upper platform knocking me down (without damage) each time I climbed back. Tried to reset his position by running around, leaving room, even going farther away but it didn't help. Not game breaking but slightly annoying because only way to proceed was suicide. This happens rarely, during several hours of play I only encountered it twice in the same place. (guard knockdown.avi)

Probably a gameplay bug as well... not going to attempt to fix ? (isn't that level 8?)

 

 

I'm going to try to fix that KIL but I'm hoping it's 100%

[rensoup]

2 hours ago, CharlieChaplin said:

So, the dancing girl still makes loading much slower than the mouse (slower = appears slower than 1x SIO due to the pauses/retries). Hmmm, maybe you should get rid of the dancing girl and use the mouse during the whole loading process?  Or simply use the Faicuai method with screen=off during loading for better benchmarks, ermm, better loading speed...?!? Suggestion: The disk versions could load faster and show no loading animation (or just the mouse), while the cart versions could show one or both loading animations - just a thought or suggestion. And now listen to these awful WAVs...  

Weird... seems my reply got lost...

 

XXL recomended that I use a different method to display the dancing girl... using DLis... that sounds annoying so I'm going to try a beautiful hack first ?

[rensoup]

2 hours ago, DrVenkman said:

As far as I can tell, the U1MB settings are generally the same across my devices, though I tried various combos. None of them allowed loading the .CAR files from my XEL using the SIDE3 even though the same SIDE3 works for loading them on my 1200XL and my Incognito 800. Weird. 

Hmm.. so how compatible is the XEL ? any other software that doesn't work with it ?

 

It's kind of strange that it seems to be happening in the middle of file loading (especially on carts where it's basically block copies)

[+DrVenkman]

19 minutes ago, rensoup said:

Hmm.. so how compatible is the XEL ? any other software that doesn't work with it ?

 

It's kind of strange that it seems to be happening in the middle of file loading (especially on carts where it's basically block copies)

The XEL is generally the most rock-solid and compatible machine I have, being a modern XE-based design with a nice, “quiet” ground plane, modern components throughout, and a clean, stable buffered Phi2 clock - much cleaner than any vintage A8. This is the very first program I’ve found that WILL load on a vintage NTSC machine that WON’T load on the XEL.

 

In addition to not loading with my SIDE3 cart, the ATRs don’t load via FujiNet either, not even the DLI fixed demos you posted. The full-game DD ATR you posted on June 10th loads and the game plays on my PAL 1088XLD, which is the same basic design as the XEL, but laid out to fit a vintage 1050 disk drive case. And the DLI fix versions load on my NTSC 1200XL too.

 

So … mysteries continue.

[+Eyvind Bernhardsen]

6 hours ago, rensoup said:

If you keep mentioning the same loading speed issue while ignoring the fact that there is a cart version, that's complaining.

 

That's like saying your regular Coke has too much sugar while there's a 0% next to it but you can't be bothered to extend your arm to get it.

Well, I haven’t been complaining about the loading speed, but my XEL doesn’t have an accessible cartridge slot (because I don’t want to cut a hole in the case I’m using), so it relies on the SIDE loader to run everything. Hasn’t been a problem until now.
 

In terms of your analogy, it’s not that I can’t be bothered, I’m just allergic to aspartame ?

[Mq.]

On 6/15/2021 at 4:40 AM, rensoup said:

Here's an Atarimax test...

 

I'm curious if it boots at all or still goes into self test ???

pop_atarimax_boot210614.zip 146.03 kB · 18 downloads

Ok. I just tested this Atarimax cartridge image, and it works for me properly in Altirra, and in my own project cartridge compatible with Atarimax too (on real machine).

But this version is not able to play the game. Game starts, intro works, every screens appears one by one as expected, and then it starts in demo mode (attract mode). Is it ok, was that version intentionaly made like this?

 

I suggest to do bank redirection inversely. Now you have code in bank 0 which redirect to bank 127, and then cartridge starts from 127 always. It is better to place starting code in bank 0 and in bank 127 do only redirect to bank 0. In Atarimax cartridge there are two memory chips, and your game entire fits in the first memory chip, so phisicaly second chip is unrequired at all. If initialise code would be in bank 0, then cartridge will work with one chip only.
There is no matter, when someone is useing original Atarimax cartridge or emulator, but when someone is building his own cartridge, or if you would like to produce and publish phisicaly your game then it lets use only one phisical memory chip instead of two memory chips (less soldering work, less electronic parts, lower cost).

 

And one more small note from me. It has no effect in properly working devices, but it is more consistent with proper electronic devices designing. Erased memory chips are filled by FF bytes, not by zeros. So when you create cartridge image, and a lot of space in that image is empty, then that empty area should be filled with FF instead zeros.
Advantages of this are a lot smaller atr programming images generated by Maxflash Cartridge Studio. Second, programming of cartridge device will finish in shorter time, because phisicaly to program memory chip it is necessery to erase it first. Next, programming of memory chip is processed only for bytes which are different then FF. FF's are ignored, because entire chip is filled by them first.
I write this only for expand knowledge ?

Edited June 16, 2021 by Mq.

[_The Doctor__]

this is becoming a mess that doesn't need to be,

please test each cartridge type on the real actual cartridge... not emulated on an a multi cart emulation cartridge device...

please test each on real Atari manufactured Machines only... lot's of homebrew Atari replacement pcb/remakes etc out there have their own issues...

 

if you use the latest maxflash studio to create the maxflash image... it will normally make an atr flasher that handles the bank 0 / 127 thing on it's own... using older tools usually fails to do this as do some newer third party creations that don't take this into account... additionally it's only sometimes will you need to change your actual projects code if it is not following the guidelines set out by Steve.

 

If software works on the real devices/carts/Atari machines... but fails on newer romcart emulation device or on some such mini Atari remade machine... then those devices and re-machines may very well need some work or fixes....

 

It would appear the SIDE 3 wasn't doing something correctly and new firmware fixed some of it... telling the developer all the cart types are failing or this or that type fails has them going in circles when there really isn't a problem with the cart type at all... it works on the real cart and real machine.

 

This may also explain why so many say it works across the board on the actual specific devices and machines while others claim it's all bad and doesn't work for the same list as the latter are not running the hardware on the list at all... it's emulated by another device or run on a homebrew machine.

 

Let make sure it works on all the direct and real hardware first and solve the problem an emulation device / remake board has later... since their issues have little to do with the program itself and more to do with their own firmware implementations and quirks. That normally ends up being a fix from their respective creators/and collaborators and not within the scope of the software developer. If it's not an issue on the real thing... the problem isn't in their code.

[Mazzspeed]

EDIT: Bugger it. Mods, feel free to delete this post.

 

 

Edited June 16, 2021 by Mazzspeed

[Jacques]

9 hours ago, rensoup said:

I don't erase everything that's not needed because I'd rather have the game load faster than have the attract mode load fast. How many times do you watch the attract mode vs how many times do you play the game ?

The SD version has the some of the sprites on Disk1,  if I erased those, the user would have to flip the disks constantly.

Probably most have DD-capable drives working with their 128KB(+) machines, but still there are stock 1050's out there and I understand it's impossible or too time-costing to handle it and maintain (if changes/fixes are needed in the future) differently for DD, SD and cart.

Got it. If there's no way, then there's no way. Thanks for explaining ?

Edited June 16, 2021 by Jacques

[Wrathchild]

What a depressing start to the day, many misleading ideas here:

2 hours ago, _The Doctor__ said:

if you use the latest maxflash studio to create the maxflash image...

This title would not need use of MfCS as it is assembled directly to the binary image, hence the programmer's responsibility to setup the cart vectors correctly.

MfCS is only needed to a) convert the binary to an ATR image for programming the cart on an A8 or b) program the image directly to a cart using the USB programmer.

2 hours ago, Mq. said:

If initialise code would be in bank 0, then cartridge will work with one chip only.

Not true, the physical cart needs two chips present other wise, in your case here, the second chip would presumably return all 'FF' or '00' and so no vectors in bank 127 seen and hence the cart would not start.

So yes this would work in the bank 0 init model but not in the bank 127 model, the idea is to have an image that supports both.

2 hours ago, Mq. said:

Advantages of this are a lot smaller atr programming images generated by Maxflash Cartridge Studio.

Changing a BIN/CAR image into an ATR image for flashing the cart with does not strip out any data and so the ATR size will not be any smaller.

2 hours ago, Mq. said:

Second, programming of cartridge device will finish in shorter time, because physically to program memory chip it is necessary to erase it first. 

First half of the statement true but its not because of the latter, the flash chip will always need to be erased.

2 hours ago, Mq. said:

Next, programming of memory chip is processed only for bytes which are different then FF. FF's are ignored, because entire chip is filled by them first.

From the documentation I don't think the AM29F040B has a 'intelligent controller' that would skip bytes like this. 
The time saving occurs as there are less (i.e. none) bit transitions from 1 to 0 to be made within those bytes.

 

The AtariMax ATR image programming loop merely reads 8K blocks from the disk into memory at $2000 to $3FFF and after setting the cart to programming mode and the right bank these are copied to $A000->$BFFF.

[Mq.]

4 minutes ago, Wrathchild said:

Not true, the physical cart needs two chips present other wise, in your case here, the second chip would presumably return all 'FF' or '00' and so no vectors in bank 127 seen and hence the cart would not start.

So yes this would work in the bank 0 init model but not in the bank 127 model, the idea is to have an image that supports both.

I meant a situation when we build special cartridge compatible to Atarimax banking, but especially for one game. I don't know if the author would like to do that end the end of work on complete game, but I suggested this only. In my opinion the best solution is to allow cartridge starts independently both from bank 0 and bank 127 without redirection.
I mentioned it, because I'm building such cartridges, and I'm preparing to develope some new games, so I'm considering such things, and then sugest it to other people thinking about such way. Maybe someone will use my knowledge.

13 minutes ago, Wrathchild said:

Changing a BIN/CAR image into an ATR image for flashing the cart with does not strip out any data and so the ATR size will not be any smaller.

I tested it. If bin image contains full banks filled with FF's, then Maxflash Studio creates shorter atr. For example if second half or cartridge is filled by FF's, then atr will be about half size.

20 minutes ago, Wrathchild said:

From the documentation I don't think the AM29F040B has a 'intelligent controller' that would skip bytes like this.

No, this is not because of AM29F040B functionality. I agree. This is because of application for flashing which is generated by Maxflash Studio to the atr. That flashing program first erase entire chip, so it is filled by FF's. Then flashing application doesn't program sectors that not contains any data but FF's only. The application skips entire sectors, so if the game has for example 256kB of data, then Maxflash 8Mbit will be programmed in 1/4 of the entire chip programming time.

This is my observations from using Maxflash, I did'n analise any code of the application, but I'm electronic engineer, so it is logical for me, and I would write flashing application in the similar way.

 

But I tested it now, to check if I write proper knowledge ?

Test it to see by yourself if you want.
I created two 1MB files. One of them I filled with FF's, and the second of them I filled with the zeros. Then I created bin to atr by Maxflash Studio. Such generated atr filed with zeros is about 1MB (to program entire chip with zeros), but the second atr filled with FF's is about 2,5kB only, because entire sectors filled with FF's will not be programmed at all, and are skipped.
It is one more advantage of that: sometimes you can fit flashing application with cartridge image on the floppy disk. I think PoP will fit into 360kB disk for example if will be filled by FF's instead of zeros.

[Wrathchild]

Not quite a valid test, set the last byte of the all FF image to 0

Here's the programming loop:

Program8K:                ; CODE XREF: PerformReFlash+12�p
        JSR    ShowProgress
        LDA    #$D
        STA    StrOutLen
        LDA    #$54 ; 'T'
        LDY    #$17
        JSR    PutText        ; Program Flash
        LDA    #0
        STA    CopySrc+1
        LDA    #$20 ; ' '
        STA    CopySrc+2
        LDA    #0
        STA    CopyDst+1
        LDA    #$A0
        STA    CopyDst+2

loc_0_1137:                ; CODE XREF: seg000:117A�j
        JSR    chip_1
        BIT    CurBank
        BVC    cmd_program
        JSR    chip_2

cmd_program:                ; CODE XREF: seg000:113D�j
        JSR    cmd_unlock
        LDA    #$A0
        JSR    wr5555
        LDX    CurBank
        STA    $D500,X

CopySrc:                ; DATA XREF: seg000:1125�w seg000:1157�r ...
        LDA    $FFFF

CopyDst:                ; DATA XREF: seg000:112F�w seg000:1168�r ...
        STA    $FFFF
        CLC    
        LDA    CopySrc+1
        ADC    #1
        STA    CopySrc+1
        LDA    CopySrc+2
        ADC    #0
        STA    CopySrc+2
        CLC    
        LDA    CopyDst+1
        ADC    #1
        STA    CopyDst+1
        LDA    CopyDst+2
        ADC    #0
        STA    CopyDst+2
        CMP    #$C0
        BNE    loc_0_1137
        CLC    
        RTS    

 

[Wilheim]

9 hours ago, rensoup said:

Weird... seems my reply got lost...

 

XXL recomended that I use a different method to display the dancing girl... using DLis... that sounds annoying so I'm going to try a beautiful hack first ?

I suggest you to use DLIs as well. And by parts if necessary, so you can give enough time to bring back control to the SIO routine.

 

I remember doing something similar a long time ago. Making a somewhat unnecessarily complex scroll during SIO reading. I solved the issue by splitting the routine in two DLIs, so I could bring time to the SIO port.

[Mq.]

2 minutes ago, Wrathchild said:

Not quite a valid test, set the last byte of the all FF image to 0

If there will be 0 at the end of chip sector data, then Maxflash Studio will create such bank in atr for programming. If I take my 1MB file filed with FF's, and in the end of the file I change $FF to $00, then generated atr will contain last 8kB bank, because it is only one bank not entire filed with FF's. I tested it now, and atr is about 10,5kB.

 

Atr flasher skips banks entire filled with FF's. Or rather just there are no these banks in the atr at all.

 

15 minutes ago, Wrathchild said:

Here's the programming loop:

Don't analyse the code, before you did'n check how the applications work from user side ?

[Wrathchild]

Was going to write as had already concluded that the studio is stripping any 8K block that is all $FF in order to keep the effort down, so apologies there.

As the example, this image is all $FF's with the last byte of each bank set to zero and so the resulting ATR is the 1027KBdummy.bindummy.bin

[Faicuai]

16 hours ago, xxl said:

it turned out it's not my fault?

?

 

They just dropped their lollipop on the sand and got mad... Infantile to the core...

 

It never added-up from the beginning, and that´s the TRUTH. 

[Mazzspeed]

32 minutes ago, Faicuai said:

?

 

They just dropped their lollipop on the sand and got mad... Infantile to the core...

 

It never added-up from the beginning, and that´s the TRUTH. 

XXL made comments that made me question his motives. It was never directly implied that he had done anything malicious regarding the .CAR, it was his snide remarks that raised my suspicions and made me question the reason behind such comments based on XXL proven track record regarding compatibility under certain hardware. Furthermore, successful loading of the ATR is still hit and miss, even when comparing two identical machines at SIO 1x - Xbios could still be the cause of this issue.

 

The only person that can put a stop to the skepticism regarding XXL's character is himself. There's an obvious language barrier issue present (as there is with yourself), so I suggest friendly and straight to the point answers as to avoid any misinterpretation regarding context - As to others your posts do read like word salad when you try to use big words (to pinch a phrase from FJC).

 

[Mq.]

51 minutes ago, Wrathchild said:

Was going to write as had already concluded that the studio is stripping any 8K block that is all $FF in order to keep the effort down, so apologies there.

As the example, this image is all $FF's with the last byte of each bank set to zero and so the resulting ATR is the 1027KBdummy.bindummy.bin

Yes, exactly. I think we are both right.
I'm from Poland, and my English is not quite good, so maybe my first description with suggestions to the PoP cartridge image construction is not as perfect as it should be to understand by native speaker. But every thing I wrote, are supported by tests I did before.
I have my own design of cartridge with banking same as Atarimax. I designed it for publishing some games this year, bacause i would like to publish these games for free in popular format, and paralely on phisical cartridges with printed stickers, boxes etc. Sorry, it's off topic... But, my cartridge starts from bank 0, and then everything is working good, and when I populate only one chip on it, then even Maxflash Studio flashing application still works good.
I'm sorry for off topic, but I thought that author of PoP maybe want to know how eventually he may publish the game in the future. It's example way only.

[Wrathchild]

agreed. I was wanting to clarify that even an 8K bank with 8K-1 byte of FFs would still be written to the cart. My own background was writing the emulation code for flash writing back in 2007 so not unfamilar with the concepts, in the back of my mind I recalled the skipping of redundant banks but failed to confirm it when reviewing the code.

 

If you can do alternative version of your board with support for the XEGS Switchable model then I'd take some of those as that's a physical board model that's currently missing aside for hacking your own I believe.

[Mq.]

@Wrathchild: there is XEGS compatible open source project. Here is description of it with full documentation etc. (unfortunately in Polish): link

My own 4/8Mbit cartridge was based on this project: link, but I finished it with 8Mbit and read/write compatibility, and PLCC chips. I didn't publish it, because I use it for my own purposes, and for now I'm busy with preparing cartridges for new excelent game which will be published in july, but it's not a topic for this thread.

Edited June 16, 2021 by Mq.

[Beeblebrox]

Bit of a delay in testing again (real life, work and all that), but I can confirm the following, testing on my 65XE 320K A8 after flashing my SIDE3 with FJC's latest 0.39 firmware (thanks FJC):

 

2021/06/10 release

 

Disk Versions:

2 SD disks:PoP_SD_20210610.rar - No Go.

 

I loaded up the 1st ATR disk A.

Initially I get the A8 blue screen with cursor for 2 or so minutes then a black screen for a further 1 minute, then the XB4.3 menu appears:

I select 1 and this choice is indicated onscreen but nothing happens. Tried the hitting the typical return key, start button, etc. Gave up.

 

1 DD disk:PoP_DD_20210610.rar - No Go

Same as above.

 

Cart Versions:

 

Atarimax:PoP_Atarimax_20210610.rar - N/A as don't have a 1MB setup to test on

 

Megacart:PoP_Megacart_20210610.rar - - Boots to dancing girl then mouse in a few seconds then few more and jumps to title text, then game 

 

SIC:PoP_SIC_20210610.rar - Woohoo! Same as the megacart - Boots to dancing girl then mouse in a few seconds then few more and jumps to title text, then game 

 

Honestly ...the intro animation - a joy to watch!  I love the Sultan's cape animation as he turns to leave! Animation is great. Can't wait to see more colours coming into the cut scene in future releases, (I'm sure I read somewhere there this is the plan for the final release.)

 

Music is atmospheric, minimal and works really well. I like the title story intro text screens too. Whilst I am running a PAL A8 setup, it seems the upscaler I am using, (connected via DIN to SVideo/into DELL 2007fpb monitor), is outputting 60hz, so I get no flickering with the latter. (I think that is what some reported). 

 

Amazing achievement all round.

 

thanks

 

 

 

Edited June 16, 2021 by Beeblebrox

[Jacques]

Today I ran PoP DD version attract mode in a loop on 130XE with real disk drive and it froze during one of loadings (mouse) on 3rd iteration, iirc. 

I think similiar issues were reported already, just want to confirm it happening on my hardware.