Unicorns season: Prince of Persia for the A8!

[emkay]

2 hours ago, rensoup said:

To be fair, this interlude was started by someone who was never involved in the Atari side of retrogaming afaik.

I found it to be COMMOn....

[Wilheim]

Hi, all!

 

I was thinking about the RAM requirements to make PoP working on 64kbytes. Maybe a solution would be by using a Corina-like cartridge, using 512 Kbytes of Data on an eprom and 512 Kbytes of SRAM. That way we could use the eprom for data and the SRAM as an expansion area.

 

To do so, I would like to propose this design:

 

1. 8 kbytes per bank, using $A000-$BFFF

2. Banks $00-$3F as Flash ROM (29f040 or 39sf040), making 64 banks of 8 kbytes each.

3. Bank $40-$7F as SRAM (AS6C4008), having 64 banks of 8 kbytes each.

4. Bank $80-$FF as cartridge disabled.

5. Fit on @Sikor 's cartridge cases

 

If you like this idea, I will gladly design it and test it if it works. Of course, having support from emulators like Altirra would be a nice-to-have.

 

@rensoup what do you think?

Edited August 26, 2021 by Wilheim

[_The Doctor__]

is this not already AtariMax and AVG with provision for saving etc?

[Wilheim]

33 minutes ago, _The Doctor__ said:

is this not already AtariMax and AVG with provision for saving etc?

Not quite. On AtariMax you can flash and store data, but can't work as RAM for processing, for example, with sprite animation or masking. This design would allow it.

 

Besides, AFAIK, AVG uses SIO operations to save, but not for processing.

Edited August 26, 2021 by Wilheim

[_The Doctor__]

I wasn't aware that there was an issue with running out of the ability to process with POP, so far it been the best I've played, including what I played on the x86 and even t1000 machines at the time.

[Wilheim]

Progress so far. Trying to use glue logic with DIL components to make it easier to assemble.

Edited August 27, 2021 by Wilheim

[Mr Robot]

The!cart has 512k of sram that can be used as ram disk or memory expansion

[rensoup]

2 hours ago, Wilheim said:

I was thinking about the RAM requirements to make PoP working on 64kbytes. Maybe a solution would be by using a Corina-like cartridge, using 512 Kbytes of Data on an eprom and 512 Kbytes of SRAM. That way we could use the eprom for data and the SRAM as an expansion area.

It's a cool idea but I prefer to stick with vintage hardware...

 

It seems that you creating a RAM expansion that require a specific bank scheme ?

 

I'm really unqualified when it comes to electronics, so I'm going to ask a dumb question which has probably been answered already... is it not possible to simply create a memory expansion which would be 130XE compatible and also has a flashable ROM like you described, so that any cart can be put on it and take advantage of the extra mem? Similarly every software on floppy/tape could use it as well?

 

Regarding PoP running in 64KB, it's potentially doable (the C64 version proves it), but direct access means no compression, which would double space requirements (so a 512KB ROM) which I'm guessing nobody cares about.

 

Even though PoP requires a lot of RAM, it's less than 64KB overall I think but I added a bunch of code which self modifies all over the place ? so that would have to be changed or moved and it's not a very interesting challenge.

[Wilheim]

26 minutes ago, rensoup said:

It seems that you creating a RAM expansion that require a specific bank scheme ?

Yes. Instead of using PORTB,, you just store any value at $D5xx, where "xx" is the bank number as described above.

 

27 minutes ago, rensoup said:

is it not possible to simply create a memory expansion which would be 130XE compatible and also has a flashable ROM like you described, so that any cart can be put on it and take advantage of the extra mem? Similarly every software on floppy/tape could use it as well?

As a external device, that's only doable on XL/XEs machines with expansion port. There are plenty of 65XE without it and you can only expand them by using soldering techniques. In my opinion, is far more complicated.

 

29 minutes ago, rensoup said:

Regarding PoP running in 64KB, it's potentially doable (the C64 version proves it), but direct access means no compression, which would double space requirements (so a 512KB ROM) which I'm guessing nobody cares about.

 

Even though PoP requires a lot of RAM, it's less than 64KB overall I think but I added a bunch of code which self modifies all over the place ? so that would have to be changed or moved and it's not a very interesting challenge.

That's even a better idea! I think unrolling data will make the game faster, and we have plenty of space if needed.

 

On the other hand, maybe you don't have to modify that much. You just use the expanded ram provided by the SRAM portion, using 8kbytes bank size.

 

Of course, it's just an idea that came to my mind.

[Wilheim]

2 hours ago, _The Doctor__ said:

I wasn't aware that there was an issue with running out of the ability to process with POP, so far it been the best I've played, including what I played on the x86 and even t1000 machines at the time.

The thing is that at the moment it needs 128kbytes RAM, so I'm proposing something that would work with 64k, and so bring a chance to get to a broader computer line.

[rensoup]

19 hours ago, Wilheim said:

On the other hand, maybe you don't have to modify that much. You just use the expanded ram provided by the SRAM portion, using 8kbytes bank size.

Maybe, maybe not... Potential issues are:

 

-both ROM & RAM windows are located at the same spot. It means that code located in extended 130XE RAM needs to be reOrg at $a000 instead of $4000. What if the code that was originally at $4xxx (and is now at $axxx) needs to access RAM at $axxx in a bank 0 ?

Not saying it does currently (I don't remember really), but for easily supporting that cart, the extended RAM window should be at $4000 and the ROM one at $8000.

 

-8KB bank size vs the 130XE's 16KB size. Larger banks seem to make more practical sense.

One of the cart scheme supported in PoP has a 8KB window as well but it's ok because I'm just streaming the data. If I had to try to make the game fit in 64KB RAM, I would almost certainly drop that 8KB scheme because while it may be possible to make the whole game code fit in a 16KB ROM bank, a nasty jump table would be required for a 8KB scheme.

The data is currently organized for 16KB banks. it would be impossible to load the level graphics in a single 8KB bank, nor would it be possible to have some PMG code in another 16KB bank bundled with the PMG graphics.

All the banks are full, if you suddenly split them in the middle, it would require more than twice the 4 original banks.

 

19 hours ago, Wilheim said:

As a external device, that's only doable on XL/XEs machines with expansion port. There are plenty of 65XE without it and you can only expand them by using soldering techniques. In my opinion, is far more complicated.

What I don't understand, is how software loaded from disk couldn't use a RAM cartridge plugged into the cartridge port but software on a ROM cart plugged into the cartridge port could use the RAM portion on that same cart ?

Edited August 27, 2021 by rensoup
window

[tmp]

22 minutes ago, rensoup said:

Not saying it does currently (I don't remember really), but for easily supporting that cart, the extended RAM window should be at $4000 and the ROM one at $8000.

atari cart port design allows access only to $8000-$9fff, $a000-$bfff (and $d5xx)

 

22 minutes ago, rensoup said:

What I don't understand, is how software loaded from disk couldn't use a RAM cartridge plugged into the cartridge port but software on a ROM cart plugged into the cartridge port could use the RAM portion on that same cart ?

by external port he means pbi (or eci+cart) that allows to expand memory externally using $4000 window (and as he says, some 65xe don't have eci)

with cart port only, you're limited to the ranges above

[rensoup]

32 minutes ago, tmp said:

atari cart port design allows access only to $8000-$9fff, $a000-$bfff (and $d5xx)

 

ok, I didn't realize it was a design limitation. I thought if you created your cart scheme, you were free to bankswitch any range of adresses.

[+MrFish]

On 8/26/2021 at 7:04 PM, _The Doctor__ said:

is this not already AtariMax and AVG with provision for saving etc?

 

Maybe you're thinking of MyIDE II cart, which has 512 KB of SRAM.

 

[Wrathchild]

There are 16k bank models, e.g. MegaCart, so effectively you'd be swapping the $4000-$7fff range with $8000-$bfff

[Wilheim]

3 hours ago, Wrathchild said:

There are 16k bank models, e.g. MegaCart, so effectively you'd be swapping the $4000-$7fff range with $8000-$bfff

It’s doable, but it requires an additional glue logic chip. I tried to avoid that, in order to simplicity and space . Making a cartridge that can be programmed on any Atari computer.

One alternative is using a GAL programmable logic, but they are getting scarce and it will require additional hardware to store a new logic on there.

[Wrathchild]

If the cart was read only (i.e. no flash writing in A8) then couldn't the address handling be done without a GAL? E.g. flash an 040 chip and then pop onto the board.

[Wilheim]

6 hours ago, Wrathchild said:

If the cart was read only (i.e. no flash writing in A8) then couldn't the address handling be done without a GAL? E.g. flash an 040 chip and then pop onto the board.

Could be an alternative to free a gate. I’ll look into it. Anyway, I prefer to maintain flash properties on the atari computer, so you can update any bugs, improvements or even stuff like high scores, save states, etc.

[Wilheim]

So, after thinking about @rensoup observations and @Wrathchild suggestions, I'm working on a new design.

 

I decided to make a 16 kbytes bank-switching method, using two diodes and a resistor to make the additional gate needed. It's similar to the Megacart scheme, but using the address bus to switch instead of the data bus.

 

Prior to make the pcbs, I decided to make another pcb to make prototypes. That way, I would be able to test any configuration on a protoboard.

 

I'm temporarily naming the cartridge as "FlashSRAM cartridge". The bank will be selected by storing any value at $D5xx, where xx is the bank number.

 

It's bank scheme would be:

 

1. Banks $00-$1F: Flash ROM (32 banks 16kbytes each)

2. Banks $20-$3F: SRAM (32 banks 16kbytes each)

3. Banks $40-$7F: unused.

4. Banks $80-$FF: turn cartridge off.

 

 

I hope to have some news anytime soon with the testing.

 

 

 

[Level42]

I demand it to work on my 400 with it's 4k RAM. 

 

Yeah it had 16K when I got it, but I felt the extra 12 kBytes of RAM was not factory original enough for my taste so I removed it.............

 

 

ANYWAY.....

 

I'm not sure if it's already been reported but I played a bit again today and ran into a bug (or a feature if the "original" version is like this): 

At level 2 I was fighting a guard....normally I win pretty easy but I was not really focussed. It happened on this screen:

 

 

The guard drove me back so I fell into the pit on the right AND he killed me at the same time.... following this both the guard and I "dropped down" the screen, never to return again:
 

 

After this there was nothing I could do but reload the game.

I managed to reproduce the exact same thing happening on the next run.

I might be able to film it if necessary....

 

I haven't kept up if there were any updates, but I ran the PoP_SIC_20210619_bugfix.car version.

 

 

[rensoup]

7 hours ago, Wilheim said:

So, after thinking about @rensoup observations and @Wrathchild suggestions, I'm working on a new design.

The thing is, with the extended RAM window overlapping the ROM one, I don't see how this would work without changes... and if doing changes, then might as well make it work with existing schemes.

 

The background graphics use extended RAM bank 0 at $4000 for instance and get plotted to the screen at $Bxxx so with your scheme that doesn't work anymore.

 

[rensoup]

3 hours ago, Level42 said:

I managed to reproduce the exact same thing happening on the next run.

I might be able to film it if necessary....

 

I haven't kept up if there were any updates, but I ran the PoP_SIC_20210619_bugfix.car version.

That's the latest update indeed...

 

The fact that you were able to do this easily is a little worrying (might indicate that it's not in the other versions). it would be interesting to check if this happens on any of the other platforms (A2, BBC, C64)

 

 

[Luke210]

Yup, i've also experienced this bug

 

[Level42]

12 hours ago, rensoup said:

That's the latest update indeed...

 

The fact that you were able to do this easily is a little worrying (might indicate that it's not in the other versions). it would be interesting to check if this happens on any of the other platforms (A2, BBC, C64)

 

 

Sadly I have neither of those machines....and I lack the time to install emulators etc.

[Level42]

By the way, this looks f-ing amazing on my Bang & Olufsen MX8000 CRT television through Sophia RGB…..