VBXE Exercise - Popeye WIP

[drac030]

1 hour ago, woj said:

This still does not allow S_VBXE.SYS to "wake up" after exit to DOS, but I do get a working SDX prompt.

Maybe, instead of using fancy XIOs, it would be enough just to reopen the screen in the console mode, i.e. do an equivalent of GR.0?

 

CLOSE #0:OPEN #0,12,0,"E:", or http://atariki.krap.pl/index.php/Otwarcie_ekranu_w_trybie_konsoli_(GRAPHICS_0)

 

This should automatically reset all the internal settings of the driver, reestablish XDL and such.

[woj]

8 minutes ago, drac030 said:

Maybe, instead of using fancy XIOs, it would be enough just to reopen the screen in the console mode, i.e. do an equivalent of GR.0?

But that is exactly what a warm reset jump through $e474 (was it?) does anyhow, no? That's what I do. The driver seems to be dead, doing "con 80" doesn't do anything. I just tried to see how the VBXE SDX demos (the purple scull, cute girl, or rainbow dog) behave. When started in 80 column mode they crap the console where normally the messages appear, but load and work, after exiting the screen is blank, but both blind executing con or reset bring the correct screen back.

 

So I either still do destroy something of the driver, or change some VBXE register that it does not reinitialize, I will have to investigate, it is probably something I still do wrong.

 

BTW, it seems those demos do not work right with VBXE base set to $D740, at least I had to change the U1MB setting (on Altirra) back to $D640 🤔

[+Stephen]

3 hours ago, woj said:

I just tried to see how the VBXE SDX demos (the purple scull, cute girl, or rainbow dog) behave. When started in 80 column mode they crap the console where normally the messages appear, but load and work, after exiting the screen is blank, but both blind executing con or reset bring the correct screen back.

 

So I either still do destroy something of the driver, or change some VBXE register that it does not reinitialize, I will have to investigate, it is probably something I still do wrong.

 

BTW, it seems those demos do not work right with VBXE base set to $D740, at least I had to change the U1MB setting (on Altirra) back to $D640 🤔

I did those, very quickly, and using code from the source directory included with the initial VBXE install stuff.  I believe someone had discovered that the selectable  D640/D740 code did not work.  I also make sure to not clear out VBXE RAM in the last bank, knowing that's where S_VBXE driver lives.  That being said, I am not requiring that driver be used, nor am I using any of the features in those demos.  It's my feeble attempt at learning 6502 coding. MADS, and VBXE stuff all at the same time.  Definitely not something that should be used as example code.

[woj]

6 hours ago, Stephen said:

I also make sure to not clear out VBXE RAM in the last bank, knowing that's where S_VBXE driver lives.  That being said, I am not requiring that driver be used, nor am I using any of the features in those demos.

So that's how it should be and ideally my target. I think that's what I currently have and it should be OK, but clearly I am still missing something. Once I did trip over being in the $4000-$7FFF area with my code and interfering with SDX banking, perhaps it's something of this sort.

[woj]

So, @drac030, I'd need a bit more guidance here. First, my staying off page $07 of VBXE needed fixing, I missed one small bit, but now I am certain (verified with Altirra memory dump) that I do not touch anything in $7xxxx in VBXE.

 

Then I also verified that none of my VBXE pre-loading code interferes, namely, I stopped loading of my program after I initialize VBXE for my purposes, but not yet use it in any way, reset the system, and S_VBXE / CON woke up nicely. So far so good.

 

Then I allowed the code of my program to load after that from $2000 to around $6C00 of regular RAM, and stopped there. Resetting then caused the S_VBXE driver not to wake up. Note, I only loaded stuff there, did not call any init functions, the difference is just that I overwrote RAM contents from $2000 to $6C00. In particular, anything of VBXE, be it registers or VRAM, was not touched.

 

Then, to check a bit more, without loading my code at all, I first dumped $2000-$6C00 memory of vanilla booted SDX, then loaded S_VBXE.SYS and dumped memory again. Compared the two, S_VBXE loads a lot of stuff starting from $4800 all the way up to $63xx. Or, to be more precise, leaves stuff there after loading.

 

I am bit lame with Altirra, so can't be 100% sure there was no banking of some sort active, but I also dumped using r:xxxx addressing and got the same thing. Nevertheless, surely when I start loading my code that loads from $2000 all the way to $6C00 then it overwrites whatever S_VBXE left there for itself. Of course, this memory contents could be just a leftover from S_VBXE initialization (it actually does look a bit like this), but the point is, that me just overwriting this region destroys the driver functionality. 

 

This is as far as I got diagnosing it. My next action will be creating a "blank" program that just loads to $2000-$6C00 and warm resets to see if I get the same thing.

 

EDIT: Attached is an "empty" xex file, it just loads from $2000-$6C00 with zeros and does a jump to $e474, S_VBXE is no more after this. Does not matter if loaded directly or with X.  

 

[flashjazzcat]

For me, empty.xex loads and calls warmstart, returns to DOS and the S_VBXE.SYS 80 column display (which I set up with CON 80 before loading the XEX) is reinstated, and DOS works. But if I then press the reset key, the system locks up.

[woj]

7 hours ago, flashjazzcat said:

For me, empty.xex loads and calls warmstart, returns to DOS and the S_VBXE.SYS 80 column display (which I set up with CON 80 before loading the XEX) is reinstated, and DOS works. But if I then press the reset key, the system locks up.

Interesting, I wonder where the differentiating point is, I run SDX beta from 2022-01-09 and load both S_VBXE.SYS and CON.SYS (directly with /E) through CONFIG.SYS.

 

There is more: for test I replaced "jmp $e474" with "rts" (alternatively "jmp ($a)", results in the same), the program loads and nicely returns to the prompt. First RESET gets the prompt back, but in 40 column mode (but with front yellow color like the 80 mode has), and "CON 80" does not work anymore. Second RESET locks down the system, on Altirra with an illegal opcode (at $74CE, the history shows it tried to execute a long block of no-code data).

 

 

[woj]

@drac030 so I definitely think there is a bug in the VBXE driver, it essentially commits suicide on re-initialization. I debugged a bit with Altirra, this is during one of those warm RESET crashes. It first sets VBXE memac_b to $9F to access the last page of VBXE through $4000-$7FFF, see the first screenshot. It then jumps into a reinitliazation / clearing loop for y=$27..$0. Once below $20 with y index, it starts wiping out VBXE registers to zero, and surely enough, rather quickly it clears $D65D to zero closing the MEMAC_B window, next instruction jumps to a BRK in the main RAM, see the second screenshot. I patched the $20 constant to $1D (see the attached files), and everything now seems to work (also with my game), but then for the values of Y=$1F, $1E, and $1D something else than the VBXE register set gets updated in another part of the  branch, probably leaving some undesired effect. 

 

Since this more serious than a some weird corner case bug, I kindly ask you to look at it properly and fix it professionally  I am really unsure how something like this could go unnoticed. And it might be a bit deeper than just this. 

 

 

S_VBXE.SYS S_VBXE_FIX.SYS

Edited August 28, 2023 by woj

[flashjazzcat]

Tested the 'fix' driver here with 'empty.xex' and the undesirable effects have indeed vanished.

[woj]

6 minutes ago, flashjazzcat said:

Tested the 'fix' driver here with 'empty.xex' and the undesirable effects have indeed vanished.

Great! But the problem is it is an extremely blunt fix and surely it has some side effect, and perhaps also the whole thing needs a totally different (re-)initialization approach.

[drac030]

On 8/28/2023 at 3:49 PM, woj said:

Great! But the problem is it is an extremely blunt fix and surely it has some side effect, and perhaps also the whole thing needs a totally different (re-)initialization approach.

Well, no, that's it. I just sat at it like a half an hour ago and traced it down to the exact same issue (not reading the forum beforehand, it would have saved me the 30 minutes).

 

The routine in question initializes the VBXE registers as well as the shadow registers (VBXEFXS). This routine was first in the main RAM, but wanting to lower the memlo I moved it to the VBXE RAM not noticing that it disables itself in the process. During init time it worked, because the "leftovers" of the driver were still in the main RAM, and later, well, just lo and behold, how often I use the reset key, if this crash was unnoticed for so long...

 

Thanks for finding this bug, in any case, it has nothing to do with your code.

 

s_vbxe.sys rc_vbxe.sys

[woj]

7 hours ago, drac030 said:

Thanks for finding this bug

 

That's what I (unfortunately) do, you are welcome! It's the third on my list (this, one in Altirra (wait.. technically two), and one in the Sophia plugin, though the last one Jon found first, I just didn't know) during this game development. And I didn't even get to sound / music yet  

 

7 hours ago, drac030 said:

it has nothing to do with your code

 

I was already able to establish that with my quick fix. Then I had another aha moment, reviewed my VBXE init code, realized I do several things totally unnecessarily (in fact, for the loading I just need a memac-a window), and it turns out that I don't need to bother with XIO-s, checking for the presence of S_VBXE (which I did already by now too :/), turning it off or anything. Just leave it at peace, the 80 column console works just fine during loading and message displaying, and reinitializes nicely upon RESET. Just a quick hook-up to DOSINI to clean-up after myself (most notably revert and Sophia settings I might have changed and reset VBXE palette 0 colors) and I do not even need any "clean-exit" keys, RESET does just fine.

 

7 hours ago, drac030 said:

if this crash was unnoticed for so long...

 

I would speculate that this is because 90% of your users still have the bad habit of torturing the computer with the on-off switch ("I will just power-cycle it to make sure it really has no garbage left in there") instead of RESET. Had the use-the-RESET community been larger, you would know much sooner

 

Anyhow, big big thanks for the fix! I am yet to try it out (you know, the actual work and all that ;)).  

[drac030]

On 8/30/2023 at 7:31 AM, woj said:

That's what I (unfortunately) do, you are welcome! It's the third on my list (this, one in Altirra (wait.. technically two), and one in the Sophia plugin, though the last one Jon found first, I just didn't know) during this game development.

This is actually normal when someone, khm, uses the software.

 

Noone knows what enormous number of bugs we found in SpartaDOS X 4.2x once we started to actually stress it. My favourite bug of all time was probably OPEN #1,0,0,"D:FOO.BAR" - this created a file and opened it for writes, as if the icax1 was 8, but that file could not be closed later. The reason (from memory): the OPEN routine tested if the read-access bit was cleared, then if so, it was assuming that the write-access bit was set (hence $00 was opening a file for writes). But CLOSE tested the write-access bit and, if this one was cleared, it assumed read-only file, and, whatever it was doing later, it was not sufficient to close the file properly (flush buffers, update directory etc).

 

On 8/30/2023 at 7:31 AM, woj said:

RESET does just fine

I just wonder what you need the warm reset for. It is pretty brutal way to terminate a program (we are not CP/M), it for example forces all possible PBI devices to get reinitialized, on HDDs it forces the partition tables to be re-read, in SDX it forces all device drivers to be reset, which for example, when XEP80 is connected, involves sending some crap via joystick port and so on.

 

Is not just GR.0 and jmp ($0a) enough?

 

On 8/30/2023 at 7:31 AM, woj said:

I would speculate that this is because 90% of your users still have the bad habit of torturing the computer with the on-off switch ("I will just power-cycle it to make sure it really has no garbage left in there") instead of RESET.

Even if so, here is the exact reverse: I usually power-up my Atari once per day and power it down many hours later. I surely sometimes just reboot it, either by the CP command or SELECT/RESET or IDE+ menu.

[woj]

21 minutes ago, drac030 said:

Is not just GR.0 and jmp ($0a) enough?

Good question, I will have to revisit this, I did have some problems with the screen coming back up again with S_VBXE on, but then again, now I cannot recall if I tested it with your fixed driver. Nevertheless, being RESET prepared is not a bad thing, people will use it to exit the game, I am sure. 

[woj]

6 hours ago, drac030 said:

Is not just GR.0 and jmp ($0a) enough?

So indeed it is, my own stupidity sometimes baffles me. What I was trying to do is to re-initialize E: *before* cleaning up my other stuff. Don't ask my why, I have no idea, but when the E: re-open is the last thing (as it should be) before jmp (dosvec) then everything just works fine. Good there is some learning behind all this.

 

I did, however, hit another snag, for a moment there I thought rather serious, and it has nothing to do with 6502 or Atari OS. I still use xa65 for the code (and I will stick with it if I can, got too comfortable, I am not with MADS, though I do appreciate its capabilities), and today doing those dosvec experiments after adding one more lda / sta pair to my code I got "Our of memory" error message from xa65. WTF? The vision of rewriting my code for MADS (or something else) made me weak, but I took a deep breath, found xa65 git repo, quick code browse indicated the limit is rather artificial (one of the data structures is defined to be of size 200000 bytes), redefined that, it recompiles quick and clean, and problem was solved. Just that I am now left with a source that does not compile with the "stock" toolset.

[woj]

Though I still do not have Bluto and visually the game has not really changed, it's Sunday and an update is due  Most of the work was to implement a clean exit to DOS functionality, one that gives back control to whatever started the game and one that reverts VBXE palette changes. Another thing was to make it play along with SDX with the S_VBXE loaded (see the conversation above), and it does (but you need the fixed driver posted earlier). This all required some internal restructuring and some bugs were discovered (some which have been sitting there since day one). To exit to DOS press Ctrl-X, alternatively you can RESET the game, but that takes a slightly longer route. From the "visible" things, the high score initials entering now has auto-repeat for stick left and right moves, so you can just hold it to speed scroll through letters. This was not yet sufficiently tested, but so far so good. 

 

The importance of the attached photo of my RetroPie box is that now I have the 130XE fully hooked up to it, including the joysticks, so that now I can have a one-to-one comparison with the original that runs on my MiSTer. 

 

In the process of doing small things I also managed to totally screw up my WINE installation, that was after an attempt to enable some DirectX things and improve the performance after I noticed that with my old settings Altirra could not handle NTSC speed (it never reached anywhere close to 60fps). Doing that I made Altirra simply crash instead, took me a while to sort it out, and I am still totally not happy with the result (though now at least I get the speed and the host CPU is not overloaded). In any case, a good tutorial from someone knowledgeable how to optimally configure WINE for Altirra would appreciated (what I found on the forum did not work out that well so far). 

 

[woj]

Bluto (Brutus) makes his first appearance! He can't yet chase Popeye, but he (a) takes full part in the first round intro, (b) kills Popeye (very "touchy" at the moment, this will be fixed, proper infrastructure for this is already in place), (c) can be punched out when on-spinach, (d) takes a water dive then, and (e) gets out of the water. I did have a bug I could not put my finger on, when the collision with Bluto kicked in out of nowhere right at the entry of the round, I think I fixed it (I painted over a not yet erased intro screen, which made Bluto collide with a stale "GET READY" sign), but I think I did get it one more time at a later stage, but now cannot reproduce it (I might have as well pressed L sometime during the intro). Also, all Bluto sprites are now loaded in, so now I am certain I have enough of VBXE space (which was not so obvious, out of 512KB it has, taking into account that S_VBXE may reside there too, I have around 60K left). Due to this the XEX file also grew substantially. 

 

Next on the todo list, small things: one more internal refactoring I know I will need, auto spinach punch when Bluto is in range, and Bluto's collision with barrel. Then the other Bluto animations and some sort of decision making for him...

 

[+darryl1970]

This looks great! This tempts me to go VBXE on one of my A8s.

[+ZeroPage Homebrew]

ZeroPage Homebrew is playing Popeye on tonight's ZPH stream LIVE on Twitch, hope you can join us!

 

Tue Sep 12, 2023 | LIVE @ 6PM PT | 9PM ET | 1AM GMT+1Day

WATCH LIVE: https://www.twitch.tv/zeropagehomebrew/
WATCH LATER: https://youtube.com/zeropagehomebrew/

 

Games:

• Community Built Atari 2600 Console Reveal from Al Nafuur @Al_Nafuur, Thomas Jentzsch @Thomas Jentzsch and Marco Johannes @MarcoJ
• Tenebra (2023 A8) by Haplo @H4plo
• Popeye (2023 WIP Update A8) by woj @woj
• Commando (2023 WIP Update A8) by Janusz Chabowski @shanti77
• Gacek (2023 A8) by Janusz Chabowski @shanti77

 WATCH AT 1080P60 FOR BEST QUALITY

 

 

[MARIO130XE]

Any news, any progress ??? Please don't say, the project ist canceled. Popeye, the most underrated arcade game ever.

 

[woj]

I was wondering how much time is needed before someone notices the silence I stopped posting binaries purposely, the project started to get a bit too much (unwanted by me) attention outside of this forum (I totally underestimated the size and liveliness of the retro community), I simply wanted to cool things down. I also still did not get any reply from @Albert on something related to this, seems pm-s are not a very popular communication channel with him ;).

 

Otherwise, it is going slowly forward, though programming Bluto keeps leaving the code in a bit of a mess and constant refactoring. Nevertheless, soon I should have the complete game without the sound, I did complete putting all the hard parts of the puzzle together, some light coding is needed to finish this part up. There will be a video coming up at some point at least.

[Albert]

Just now, woj said:

I also still did not get any reply from @Albert on something related to this, seems pm-s are not a very popular communication channel with him ;).

Let me look for that.

 

 ..AL

[milan83131]

Program some sampling music for it, let it be even better than on the arcade machines.😊

[woj]

I promised the video, so here it is. This is where I am at the moment, complete game with many fixes (one thing I totally missed until now, @darryl1970 pointed out many things to me, and this was the moment I realized I had it wrong - Popeye can turn around while punching, this gave the game the final arcade like feel), what is missing is sound and attract mode. For sound, I have around 5+K of RAM left if I want to stick to the 64K machines. This should be enough for a nice RMT soundtrack, however, if I want to go stereo (which I do), I may have to sit in the extended memory with it. 

 

(There is a split-frame display glitch when round 4 gets drawn for the first time, I am not yet sure if this is a bug or the way this was recorded. I do know I have one bug in Bluto code somewhere, I have seen it once but could never reproduce it, looking at the associated code did not bring any aha moments, unfortunately. Now it is a good time to start weeding all these out.)

 

 

Edited November 5, 2023 by woj

[+davidcalgary29]

Incredible!