snicklin Posted January 4, 2016 Share Posted January 4, 2016 I'm seeing some major differences between what a program I have running in Altirra and the same program on an Atari 65XE. I have the emulator set up as a 65XE and at the moment, I don't suspect the emulator to be at fault. I remember that there was a guide on here somewhere that someone wrote up on how to program for real hardware compared to assumptions that may be made when using an emulator. Does anyone know where it is? I can't find it. I've got the option on to randomise memory and that doesn't show the problem, so it's not that. It'll probably be something I've done. Quote Link to comment Share on other sites More sharing options...
Xuel Posted January 4, 2016 Share Posted January 4, 2016 JAC! has a great guide here. 2 Quote Link to comment Share on other sites More sharing options...
Xuel Posted January 4, 2016 Share Posted January 4, 2016 Try running your program from DOS on the emulator. This can highlight issues you might miss if you run an XEX directly. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 4, 2016 Share Posted January 4, 2016 Run Xex on some emulators will insert the segments to Ram even if Rom exists at the particular address - this doesn't happen on real hardware. Also with run Xex - I don't think RTCLOCK is updated in emulaton to reflect the delay that would occur on real hardware. SIO related DCB area at $300... not changed (?) Since loading is by external program, much more tolerant of sensitive areas being overwritten - e.g. where Dos or a loader would reside, z-page locations. Real hardware might reflect what emulation does in a multi-stage program but have problems at a later time. Examples of multi-load and execute - some demos, game "Ridiculous Reality", probably a good test candidate as each level is a binary segment. Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 4, 2016 Share Posted January 4, 2016 My favorite is the accidental LDA 0 instead of #0. Memory location 0 is not initialized by the OS, so it will usually contain 0 unless it's been modified since startup... assuming you have standard DRAM chips... and haven't run a loader like MyPicoDOS that uses it.... 2 Quote Link to comment Share on other sites More sharing options...
snicklin Posted January 5, 2016 Author Share Posted January 5, 2016 (edited) Thanks all. Jac's guide is the one that I was thinking about. My 65XE is standard, no memory changes etc. I am loading the game from a .atr file (which has a .xex inside) and the game uses xbios internally to load files. I'm loading from an SIO2SD. Do they require a certain area of memory to run or are they completely stand-alone? The error that I'm getting is that the 4x4 tiles which I am using are corrupt. They're using $6C00 to $6FFF (for the make-up of tile) and have 64 tiles in total. I suspect that it may be my code, though it works in the emulator. I'm using $BA00 to $BBFF for the map data. Those areas should be fine. SIO2SD ensures that BASIC is switched off (that is right isn't it?). I've done a RAM test on the 65XE and it comes up normal. Without seeing the code, does anything here sound like it could be problematic? Edited January 5, 2016 by snicklin Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 5, 2016 Share Posted January 5, 2016 Not sure what SIO2SD's loader does re Basic. I should think it doesn't do anything. Some loaders use parts of the stack. It's a neat way to hide away a not too big piece of temporary code but has it's dangers and potentially could be different in emulation. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2016 Share Posted January 5, 2016 Your program should disable BASIC itself. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 5, 2016 Share Posted January 5, 2016 The other thing with Basic - if you disable it via Option press, the Ram will be cleared and DList + screen @ $9C20. If you disable it via PORTB setting or rely on bootloader to do it, the Ram contents from $A000-$BFFF might be anything. Plenty of software on Atari assumes it's being loaded into Ram that's initialized with all zeros but it's not guaranteed and can be a source of problems. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2016 Share Posted January 5, 2016 If you disable BASIC via PORTB, you should close and reopen E: immediately afterwards. Quote Link to comment Share on other sites More sharing options...
snicklin Posted January 5, 2016 Author Share Posted January 5, 2016 Well, if I hold down option with SIO2SD and XBIOS, I end up getting the contents of the .atr listed to me rather than running XAUTORUN. I've used this code to disable BASIC.... portb equ 54017 LDA portb AND %11111101 STA portb I've not fiddled around with E: yet. Can I ask what this will do for me? (i.e. I know that I should do it, but don't know why) "If you disable it via PORTB setting or rely on bootloader to do it, the Ram contents from $A000-$BFFF might be anything." This isn't a problem for me as I copy blocks of data into here and don't rely on zeros. Thanks chaps! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2016 Share Posted January 5, 2016 (edited) You're enabling BASIC by clearing BIT 1. Try something like this: ICCOM = $342 ICBADR = $344 ICBLEN = $348 ICAUX1 = $34A ICAUX2 = $34B CIOV = $E456 PORTB = $D301 mva #$01 $3f8 ; set BASICF mva #$C0 $6A ; adjust RAMTOP lda portb ora #$02 sta portb ldx #0 lda #$0C sta iccom jsr ciov mwa #EName icbadr mva #$0C icaux1 mva #$00 icaux2 mva #$03 iccom jmp ciov EName .byte 'E:',$9B Adjusting RAMTOP and then re-opening the editor just puts the screen data where the OS expects it to be with the BASIC ROM disabled. Anyway, it looks like not disabling BASIC might be your problem here. Edited January 5, 2016 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 5, 2016 Share Posted January 5, 2016 A quick/dirty shortcut to CLOSE an IOCB is to just store a #$FF in ICHID. That tells CIO the IOCB is not in use so you can just OPEN something else with it. Don't use it though if dealing with files that are update/output to disk, network etc. otherwise you could lose data. 1 Quote Link to comment Share on other sites More sharing options...
xxl Posted January 5, 2016 Share Posted January 5, 2016 Well, if I hold down option with SIO2SD and XBIOS, I end up getting the contents of the .atr listed to me rather than running XAUTORUN. hold down OPTION during powerup not after load&run xB. Quote Link to comment Share on other sites More sharing options...
snicklin Posted January 5, 2016 Author Share Posted January 5, 2016 You're enabling BASIC by clearing BIT 1. Try something like this: ICCOM = $342 ICBADR = $344 ICBLEN = $348 ICAUX1 = $34A ICAUX2 = $34B CIOV = $E456 PORTB = $D301 mva #$01 $3f8 ; set BASICF mva #$C0 $6A ; adjust RAMTOP lda portb ora #$02 sta portb ldx #0 lda #$0C sta iccom jsr ciov mwa #EName icbadr mva #$0C icaux1 mva #$00 icaux2 mva #$03 iccom jmp ciov EName .byte 'E:',$9B Adjusting RAMTOP and then re-opening the editor just puts the screen data where the OS expects it to be with the BASIC ROM disabled. Anyway, it looks like not disabling BASIC might be your problem here. Ahh, must have misread an example with the accidental enabling of BASIC. Erm, my program is using custom display lists which use screen memory at $6000. I'm using memory before and after that for code / data. Could playing around with RAMTOP affect this? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2016 Share Posted January 5, 2016 (edited) If you're not actually using the screen editor then you can put it where you like and overwrite the screen RAM with your own data, but it's worth opening it at the start of your program since doing so will close down any VBXE 80 column display DOS might be running (with the S_VBXE driver). Edited January 5, 2016 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
MaPa Posted January 5, 2016 Share Posted January 5, 2016 I don't know what are you programming... but I assume that you use just your code (except of maybe OS VBI) so forget about RAMTOP, E: handler, IOCB, CIO etc. it does not affect your program. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 5, 2016 Share Posted January 5, 2016 $6000 is way out of reach for interference provided you didn't inadvertantly change RAMTOP to some bad value. Self-Test Rom maps in at $5000 though, so you need to take care not to inadvertantly enable that. Quote Link to comment Share on other sites More sharing options...
snicklin Posted January 5, 2016 Author Share Posted January 5, 2016 (edited) hold down OPTION during powerup not after load&run xB. Aggh, this is the correct answer. I was holding down Option for too long. When I used to load disks as a boy, I always held it down for a while to ensure I didn't get errors. When I hold it down for a short time, the game loads and works correctly. I feel somewhat daft now. Edited January 5, 2016 by snicklin Quote Link to comment Share on other sites More sharing options...
snicklin Posted January 5, 2016 Author Share Posted January 5, 2016 I don't know what are you programming... but I assume that you use just your code (except of maybe OS VBI) so forget about RAMTOP, E: handler, IOCB, CIO etc. it does not affect your program. It's my "Escape the Night Garden" game (take a look on YouTube if you've not seen it). I'm writing all my own code, yes. Thanks for the tip. Eventhough I now know not to hold down Option for so long, I'll still implement your code for switching off Basic. Quote Link to comment Share on other sites More sharing options...
snicklin Posted January 5, 2016 Author Share Posted January 5, 2016 $6000 is way out of reach for interference provided you didn't inadvertantly change RAMTOP to some bad value. Self-Test Rom maps in at $5000 though, so you need to take care not to inadvertantly enable that. Thanks for the help. No, I've never touched RAMTOP. I've never really understood the reason for it anyway if you're laying out your own memory. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 5, 2016 Share Posted January 5, 2016 The reasoning is so the screen handler knows where to stop clearing/moving data. It's a copy of the OS variable RAMSIZ at $2E4 which holds the highest contiguous Ram page, modifying it allows moving the screen elsewhere without impacting other areas of memory management. The often made mistake is people just bump RAMTOP ($6A) downwards based on what's already there. OK for once off programs like assembler games but not good for ones that can run multiple times like Basic programs - proper practice is base your Ram reservations on RAMSIZ (but only modify RAMTOP). Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2016 Share Posted January 5, 2016 Yes: going through the motions in the proper way using a few bytes of code does no harm and avoids unexpected glitches. As I wrote earlier, opening E: is the only driver-friendly way to be sure that any 80 column VBXE display is shut down before you set up your display. This may only prove to be an issue 0.001 per cent of the time, but it will eventually happen if your program can be started from the SDX command line (regardless of where you point the DL vector). In addition, should you allow for an exit to DOS (perhaps unlikely in a game), you should tidy up RAMTOP and open the editor before jumping through DOSVEC unless you want a lot of crap all over the screen. Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted January 5, 2016 Share Posted January 5, 2016 Hmmm, maybe you can add 57 Bytes to your code, so Basic gets disabled automatically ?!? Here is a Basic-off switch by Bill Wilkinson (appeared in Compute! magazine). It uses page 4 to switch off Atari Basic, but after that, page 4 is fully available again and can be used for other code... I have added this small tool to all my ML-files that do not require Atari Basic. If you don`t want to code a Basic off switch yourself, simply use this one from Bill... BASOFF.XEX Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 6, 2016 Share Posted January 6, 2016 If you don't mind the screen not being reopened or PortB being hit without consideration to what current banking state is, you could do a Basic off real cheaply. Segment to set PortB: 01,D3,01,D3,FF Optional segment to make change persistent over warmstarts: F8,03,F8,03,FF Optional segments to set RAMTOP and RAMSIZ: 6A,00,6A,00,C0 E4,02,E4,02,C0 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.