Heaven/TQA Posted June 13, 2017 Share Posted June 13, 2017 (edited) I run into following issue and do not know if its my code or if it works "as designed". I set MEMAC A Window to $f000-$FFFF 4k Size $d65f - $FC $d65e - $80 ;bank 0, CPU access so I switched off OS put $FFFA-$FFFF desired NMI/IRQ handler vectors pointing to my NMI etc in XL RAM at $1xxx now knowing I will switch in at some point MEMAC A I put same vectors to $000ffa - $000fff but at some point those are zeroed out... and A8 crashes obviously pointing NMI to $0000 Question: $fffa-$ffff are those somehow hardwired to XL-ROM and RAM? can VBXE bank switched in as I thought it should work? If so (and no "bug" in emulation etc) it must be then my code corrupting those... I could set write breakpoints to them I think... Edited June 13, 2017 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 13, 2017 Share Posted June 13, 2017 The vectors should just work as normal, no different to an instruction or data read really... of course the RESET vector isn't redirectable since the Rom gets switched back in. But it is a sort of risky way of doing things. Change the address of the moving window in VRam and you need to have the same vectors replicated. Inadvertantly wipe by a blit, crash time. I assume that in emulation it does the right thing. Can't say I've done VBXE access at that high address. Couldn't you equally just put the window at $E000 or maybe $C000 ? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 13, 2017 Author Share Posted June 13, 2017 yeah. I suspect one of my blits whipes FFFx... but was not sure if those adresses are somehow hardwired to CPU (i mean it's always reading from XL RAM or ROM, not VBXE). I already started to use $cxxx but still headaches with all those bankswitching shit $c000 - mapped to $001000 etc Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 13, 2017 Share Posted June 13, 2017 (edited) You might have some luck using Altirra... not sure if the breakpoints for writes also consider those done by the blitter. The banking headache... just remember if you're running code from VRam that it's the CPU viewpoint that's important. It can get confusing though. I think there was one instance where I used both MEMAC types at once - it can be handy to have that fixed 16K window as well as the smaller one elsewhere. Edited June 13, 2017 by Rybags Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 13, 2017 Author Share Posted June 13, 2017 it helps to see if cpu writes to $xxxx range as breakpoint and then you can check with .vbxe where the window was set... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 13, 2017 Author Share Posted June 13, 2017 ok... interesting issue the "garbage on screen" comes from the XL ram ANTIC reads while VBXE Window is layed over... so... db r:$c000 shows ff 00 ff 00 ff 00 etc db $c000 shows 00 00 00 00 00 and db v:000000 shows 00 00 00 00 00 which fits to the other one i am double buffering and setting dlist LMS in my NMI... is there a critical phase where I need to switch in the VBXE bank so ANTIC reads it? or what could be the cause? one reason could be that my flip code is false state... so when my other buffer is at $e000 (memac window moved to $e000) antic reads $c000 base ram... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 13, 2017 Author Share Posted June 13, 2017 well... it can not work with double buffer in XL ram as soon as I switch away the window... obviously ANTIC can not find the processed ram.... as there is only XL ram... so only reason... use 8k bank... that might work... $e000-$ffff Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 13, 2017 Author Share Posted June 13, 2017 yeah... 8k works and both screen ram buffers inside that ram. Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 14, 2017 Share Posted June 14, 2017 Antic only needs it's video Ram at a few cycles before graphics/text are displayed. But if it's DList then it's needed from the beginning to end of the display area... they would be much more easily managed if just kept in a static area. And of course remembering the bitsettings that give the CPU and Antic access or not to a VRam window. Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 14, 2017 Share Posted June 14, 2017 Why on earth would you use an ANTIC display for a VBXE-based program? Just turn it off and use the VBXE overlay. ANTIC's display costs you CPU cycles, VBXE's doesn't. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 14, 2017 Author Share Posted June 14, 2017 Phaeron.... good question... simple I can... no I used old code of mine and added features to it... so no overlay but Blitter.... it was kind of quick win lesson... But next step is to move the stuff to VBXE "completely"... Now i got the stuff right with those memac windows. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 14, 2017 Author Share Posted June 14, 2017 I am using Blitter for clear vram and eor filler... nothing more... and this allows gives a speed boost. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.