Bare loader for Atarimax cartridges?

[phaeron]

1 hour ago, Wrathchild said:

If you are only targeting XL/XE architecture and utilising the memory under the OS then you can handle the reset via the $FFFC vector.

So you'd need to swap to a SOFT/OS or maybe providing your own minimal OS.

You can't take over $FFFC -- all PIA registers get cleared on reset and that reverts port B to input. That banks the OS ROM back in, so the reset vector is always read from ROM.

[woj]

7 hours ago, Rybags said:

Even with a cartridge, the OS will often open E:

 

There's only 2 ways to stop the text screen appearing (disregarding using PBI Rom override)

1. have the cartridge run as a Diagnostic mode Rom.

2. normal mode cartridge - do not return from the INIT vector call.  This has indirect JSR before E: is opened.

Both cases mean you don't have a fully initialised system (1 actually means you have to do everything yourself)

 

The additional problem you'd have is that E: could open at $9C00 or $BC00 depending if the flash Rom is present or not.

Could you rework the game such that workspace or screen data is at those locations?

 

 

Yeah, that! Not as in this is the solution, but as in I tried something of this sort many different ways yesterday while studying the OS sources, and this is the part I did not want to dive into in the previous post. So, this confirms what I was suspecting, just yesterday it was a bit too much to make proper sense of it all and it was a good moment to get a second opinion. It seems any cart vector based solution to be out of question, the cart is disabled once the game properly starts. With this knowledge I see I have two options:

 

1. Move the E: conflicting part of my game elsewhere. With a couple of more quirks that I already know need attention, the game would just reset back to the beginning. However, I can only move things to the DOS reserved areas, so that would prevent me from stacking the cart on top of SDX for example, and still allowing the game to exit to that DOS, if it happens to be started with CAR for example. So, a "cartridge taking over solution - you will play the game until you turn off the machine".

 

2. Small dosvec / dosini hook-up routine (depending on the boot? flag to play nice along any potential DOS) that would re-enable the cart and kick back to another warm start cycle to start the cartridge from scratch. I could even save a flag saying "subsequent cart start" somewhere in my loader area and bypass some initialization / splash screens of the cart. 

 

Since one of my assumptions for the program is to "play nice" in all conditions, I am inclined towards solution number 2., also because it is simpler from the programming point of view (much less "started from cart" / "started from DOS" conditional code).  Let's see how it goes...

 

[Sheddy]

IMO it's not unreasonable for a cart based program to cold reset when reset is pushed, unless the program is totally expected to retain RAM

[Beeblebrox]

a possible no no, but if an Atarimax cart isn't an option, would an a8pico cart work for your game ( @woj )

[woj]

Just now, Beeblebrox said:

a possible no no, but if an Atarimax cart isn't an option, would an a8pico cart work for your game ( @woj )

it's definitely an option, the struggles I have are not because of the cart type itself, but mostly, as I see it, because I do not have enough RAM left to keep the cart plugged / connected at all times. Otherwise, you read my mind, the suitable Pico's are on the way to me too, just still need to order the PCBs and possibly get the cases printed somehow. In fact, it was a YT video about a8pico that triggered looking into cartridge support for me.

[Beeblebrox]

23 minutes ago, woj said:

it's definitely an option, the struggles I have are not because of the cart type itself, but mostly, as I see it, because I do not have enough RAM left to keep the cart plugged / connected at all times. Otherwise, you read my mind, the suitable Pico's are on the way to me too, just still need to order the PCBs and possibly get the cases printed somehow. In fact, it was a YT video about a8pico that triggered looking into cartridge support for me.

Cool.

Just out of interest (and forgive me if I've missed this in the thread), but your game will have no issues running off Side3 or AVG/SubAVG/Dumb cart/Ultimate cart presumably? On Side3 it would be able to use the cart's Ram?

Edited January 25 by Beeblebrox

[woj]

I got it to work fully as far as the emulator is considered, now I wait for actual carts to arrive to test the reality. The question that still remains is if the active erase write polling can be skipped altogether with the cartridge bank switched off and simply waiting some vb frames for it to finish. I'd prefer for it to work this way as keeping the bank on for a lengthier operation like this causes screen flickering due to my antic memory being in the A000-BFFF range, on the other hand I am not flashing a complete cart or even a sector, so I am in no hurry to start the actual write, I can easily wait for up to a second without any usability issues. I will find out soon enough, but if anyone knows and can direct me already that would be great. 

[phaeron]

22 hours ago, woj said:

I got it to work fully as far as the emulator is considered, now I wait for actual carts to arrive to test the reality. The question that still remains is if the active erase write polling can be skipped altogether with the cartridge bank switched off and simply waiting some vb frames for it to finish. I'd prefer for it to work this way as keeping the bank on for a lengthier operation like this causes screen flickering due to my antic memory being in the A000-BFFF range, on the other hand I am not flashing a complete cart or even a sector, so I am in no hurry to start the actual write, I can easily wait for up to a second without any usability issues. I will find out soon enough, but if anyone knows and can direct me already that would be great. 

Can't you check the erase status in the VBI? It doesn't matter to the flash chip whether the cart window is enabled or not, as it doesn't matter if the flash isn't being accessed.

[woj]

7 minutes ago, phaeron said:

Can't you check the erase status in the VBI? It doesn't matter to the flash chip whether the cart window is enabled or not, as it doesn't matter if the flash isn't being accessed.

Yes, that would be a good idea. I just do not know what is the proper check for this, it seems that the original AtariMax code I got access to (here and in the other threads) is doing a preliminary check to see the first byte of the sector erased and then just loops some fixed number of times to wait it out. Do I have the guarantee that the bytes are erased in a particular order, and I can check the last one, for example?

[phaeron]

Just now, woj said:

Yes, that would be a good idea. I just do not know what is the proper check for this, it seems that the original AtariMax code I got access to (here and in the other threads) is doing a preliminary check to see the first byte of the sector erased and then just loops some fixed number of times to wait it out. Do I have the guarantee that the bytes are erased in a particular order, and I can check the last one, for example?

It shouldn't matter, any address within the program/erase region should return toggle bits.

 

 

[woj]

OK, then I do not understand this polling method, why does it repeat 255 times:

 

poll_write      lda #$00
                sta pollsame
_poll_again     lda carbase
                cmp carbase
                bne poll_write
                cmp carbase
                bne poll_write
                cmp carbase
                bne poll_write
                inc pollsame
                bne _poll_again
                rts

 

EDIT: Honestly, the more I look at this code, the diagram you showed, and your Altirra sources for emulating the flash, the more I do not understand this. My next plan for this: check that in three consecutive frames / VBIs the read from an address is not changing and call it done, that should work, no? (I know it will on Altirra ;)).

Edited January 30 by woj

[phaeron]

6 hours ago, woj said:

OK, then I do not understand this polling method, why does it repeat 255 times:

 

poll_write      lda #$00
                sta pollsame
_poll_again     lda carbase
                cmp carbase
                bne poll_write
                cmp carbase
                bne poll_write
                cmp carbase
                bne poll_write
                inc pollsame
                bne _poll_again
                rts

 

EDIT: Honestly, the more I look at this code, the diagram you showed, and your Altirra sources for emulating the flash, the more I do not understand this. My next plan for this: check that in three consecutive frames / VBIs the read from an address is not changing and call it done, that should work, no? (I know it will on Altirra ;)).

Looks like it's a timeout, it waits until the address has been stable for 256 loop iterations and resets the counter every time it sees the address change. Which my guess is to wait for the ~50μs sector erase delay followed by the toggle bits during the erase operation. 50μs is about 90 cycles, so this is guaranteed to wait long enough even with an accelerator. Not sure why it would need to poll 3x per loop, though.

 

[woj]

2 hours ago, phaeron said:

Not sure why it would need to poll 3x per loop, though.

Have been asking myself the same question. What I forgot to say, this code is from a more universal library it seems that also handles the 8Mbit cart, so perhaps the timeouts are different there...

 

Anyhow, I worked out a solution that is my memory layout / screen memory friendly, takes an enormous number of 3 frames to clear, which for flashing whole carts would be unacceptable, but for saving 31 bytes of scores data in one sector is perfectly fine, the user is held at the score screen anyhow to allow admiring ones score. Tested fine on Altirra, will see if that works on the actual cart when it arrives. 

 

Barely almost done with this one, and I have another cart related thing popping into my head, having to do with the Pico cart, but I want to also make it writable  From the first glance at the A8PicoCart firmware it should be a piece of cake. Meaning it will take me another several weeks to sort out probably...