Jump to content
IGNORED

Load Data from disk in Assembly


Recommended Posts

1. easy way:

copy this: 43 58 41 55 54 4F 52 55 4E 20 20 20 D9 D8 E2 02 E0 02 00 00 00 00 FE 00 00 as xbios.cfg file

 

opt h-

.byte $43 ; for xB 4.3

.byte c’XAUTORUN ‚ ; autorun filename

.byte >$D900 ; xB adress

.byte >$D800 ; buffer adress

.word $02e2 ; INITAD adress

.word $02e0 ; RUNAD adress

.word $0000 ; I/O module adress – $0000 means xB build in SIO

.word $0000 ; I/O relocator adress - $0000 means xB build in

.byte $fe ; PORTB, without BASIC

.byte $00 ; NMIEN

.byte $00 ; IRQEN

 

and now xB is under ROM

 

my SlightSID Player use config like this (xB under ROM)

 

 

I was wondering if I could get some guidance on this. When put the above bytes into a file XBIOS.CFG on the xbios.atr and restart Altirra, it crashes. Are all those locations above, besides the prog and buffer, the standard defaults for xbios? Also I am using 4.3. I want to leave the buffer at $700 and move the main xbios anywhere under the ROM. I created this in MADS:

 

OPT h-f+ ; no bootable/headers, one segment
.byte $43 ; for xB 4.3
.byte c'XAUTORUN ' ; autorun filename
.byte >$D900 ; xB adress
.byte >$0700 ; buffer adress
.word $02e2 ; INITAD adress
.word $02e0 ; RUNAD adress
.word $0000 ; I/O module adress – $0000 means xB build in SIO
.word $0000 ; I/O relocator adress - $0000 means xB build in
.byte $fe ; PORTB, without BASIC
.byte $40 ; NMIEN
.byte $c0 ; IRQEN
which crashes, and then I copied verbatim the string above and that also crashes upon booting. Also, I think this would be set right, but I need DLI and VBI working, no basic.
Thank you, really enjoying this DOS alternative!
Link to comment
Share on other sites

 

which crashes, and then I copied verbatim the string above and that also crashes upon booting.

 

Sorry if this sounds flippant or ridiculous but I need to check, did you actually copy the string and paste it into a text (.cfg) file or did you copy the values in as binary values in a hex editor into the file?

 

If the former, that is the problem. I'm at work at the moment so I can't cross reference with my own code....

Link to comment
Share on other sites

 

Sorry if this sounds flippant or ridiculous but I need to check, did you actually copy the string and paste it into a text (.cfg) file or did you copy the values in as binary values in a hex editor into the file?

 

If the former, that is the problem. I'm at work at the moment so I can't cross reference with my own code....

yes, sorry, I meant when I copied "verbatim" the string above I meant the hex values string re:

 

1. easy way:

copy this: 43 58 41 55 54 4F 52 55 4E 20 20 20 D9 D8 E2 02 E0 02 00 00 00 00 FE 00 00 as xbios.cfg file

and then put that into a text file. Not literally a verbatim of the line above (ie I meant I just did the values verbatim). I even did it in MADS, assembled it to a raw file, verified all the values matched. The resulting XBIOS.CFG file was like 25 bytes in size (or however many values there are there).

Link to comment
Share on other sites

yes, sorry, I meant when I copied "verbatim" the string above I meant the hex values string re:

 

1. easy way:

copy this: 43 58 41 55 54 4F 52 55 4E 20 20 20 D9 D8 E2 02 E0 02 00 00 00 00 FE 00 00 as xbios.cfg file

and then put that into a text file. Not literally a verbatim of the line above (ie I meant I just did the values verbatim). I even did it in MADS, assembled it to a raw file, verified all the values matched. The resulting XBIOS.CFG file was like 25 bytes in size (or however many values there are there).

 

I'm home now. Although I wrote an XBIOS document a while ago, here https://atariwiki.org/wiki/Wiki.jsp?page=XBIOS, I am somewhat forgetful (hence why I wrote the doc, I got sick of relearning things)

 

Maybe you can just go with the text instead of the binary.... in the linked doc above, there is this:

 

opt h-

.byte $43 ; config for v4.3 version

.byte c'XAUTORUN ' ; autorun file fname

.byte >$0800 ; xB adress for relocator

.byte >$0700 ; xB buffer adress for relocator

.word $02e2 ; INITAD

.word $02e0 ; RUNAD

.word $0000 ; custom I/O module - $0000 means use internal xB SIO

.word $0000 ; relocator for custom I/O module

.byte $ff ; PORTB - you can't swith off BASIC this way

.byte $40 ; NMIEN - config at start

.byte $c0 ; IRQEN - config at start

 

I noticed that PORTB is set to FF here rather than FE in your code, I am not sure if that crashes things or not. The above code was probably copy and pasted when I put the doc together, so I will need to trust what is written there.

 

[EDIT] One other thing to consider, are you using 'icl' or 'ins' for including the file? 'icl' works with MADS code and 'ins' works with binary data.

Edited by snicklin
Link to comment
Share on other sites

.byte c'XAUTORUN ' ; autorun file
.byte >$0800 ; xBIOS adress
.byte >$0700 ; buffer adress
.word INITAD ; INITAD vector adress
.word RUNAD ; RUNAD vector adress
.word AOSV ; I/O module adress (at run AtariOS; default xSIOV)
.word AOSV_RELOC ; relocate AtariOS I/O module variables
.byte $ff ; PORTB at start (can't switch off BASIC this way)
.byte $40 ; NMIEN at start
.byte $c0 ; IRQEN at start

 

 

 

> .byte $ff ; PORTB at start (can't switch off BASIC this way)

 

 

@RobS: Submit an example, I will check what the problem is.

Edited by xxl
Link to comment
Share on other sites

.byte c'XAUTORUN ' ; autorun file

.byte >$0800 ; xBIOS adress

.byte >$0700 ; buffer adress

.word INITAD ; INITAD vector adress

.word RUNAD ; RUNAD vector adress

.word AOSV ; I/O module adress (at run AtariOS; default xSIOV)

.word AOSV_RELOC ; relocate AtariOS I/O module variables

.byte $ff ; PORTB at start (can't switch off BASIC this way)

.byte $40 ; NMIEN at start

.byte $c0 ; IRQEN at start

 

 

 

> .byte $ff ; PORTB at start (can't switch off BASIC this way)

 

 

@RobS: Submit an example, I will check what the problem is.

Thank you xxxl. Before we get too far into this, let me see if I can clear up some questions, to make sure I am doing this right (or that it will work at all). 1) can/does xbios able to load these settings from a file? is that file supposed to be named "xbios.cfg" on the disk? 2) When you say that xBios "can be put in OS RAM" does that mean it can just be relocated (ie you are disabling the OS entirely, so the relocation is just using that space) or can it actually be put in the RAM under the OS and handle it's own OS switching? If not under the OS, then none of this matters for what I am trying to do. Also, as an aside, 2a) how can I get xBios set up on a 130k disk image? The one I downloaded is a 90k. Would I just sector-copy the boot sectors and file copy the main xbios file and that will work? Thank you all again for the suggestions and help!

Link to comment
Share on other sites

1) can/does xbios able to load these settings from a file? is that file supposed to be named "xbios.cfg" on the disk? 2) When you say that xBios "can be put in OS RAM" does that mean it can just be relocated (ie you are disabling the OS entirely, so the relocation is just using that space) or can it actually be put in the RAM under the OS and handle it's own OS switching? If not under the OS, then none of this matters for what I am trying to do. Also, as an aside, 2a) how can I get xBios set up on a 130k disk image? The one I downloaded is a 90k. Would I just sector-copy the boot sectors and file copy the main xbios file and that will work? Thank you all again for the suggestions and help!

 

1. yes, yes

2. xbios relocates itself under the OS

2a. for eample: dir2atr -m -B xboot.obx 1040 test.atr testdir... yes, copy boot sector and copy file xbios to new disk

 

 

look at the attachment

 

test program:

 

org $d800
start
lda vcount
sta wsync
sta colbak
jmp start
run start

 

config:

43 58 41 55 54 4F 52 55 4E 20 20 20 F0 F4 E2 02 E0 02 00 00 00 00 FE 00 00

 

f000 - xBIOS adress

f400 - buffer adress

test.atr

Edited by xxl
Link to comment
Share on other sites

eventually all of these methods and and tips for xbios need or should be put in as a guide for it's use, just as it is explained and discussed though out all of the different threads, slowly it is revealed just how and what all can be done with it's use.

  • Like 1
Link to comment
Share on other sites

eventually all of these methods and and tips for xbios need or should be put in as a guide for it's use, just as it is explained and discussed though out all of the different threads, slowly it is revealed just how and what all can be done with it's use.

 

I encourage everyone to update this document which I started for the precise reason of keeping things from multiple threads tracked:

https://atariwiki.org/wiki/Wiki.jsp?page=XBIOS

  • Like 2
Link to comment
Share on other sites

 

1. yes, yes

2. xbios relocates itself under the OS

2a. for eample: dir2atr -m -B xboot.obx 1040 test.atr testdir... yes, copy boot sector and copy file xbios to new disk

 

 

look at the attachment

 

test program:

 

org $d800
start
lda vcount
sta wsync
sta colbak
jmp start
run start

 

config:

43 58 41 55 54 4F 52 55 4E 20 20 20 F0 F4 E2 02 E0 02 00 00 00 00 FE 00 00

 

f000 - xBIOS adress

f400 - buffer adress

Thank you xxl! I am beginning to understand. I will experiment with these settings and the CFG file, and thank you for the 130k image! One thing, when I do sector access the screen flashes on and off, is that a byproduct of having xbios under the OS? any way to prevent that (ie leave the screen static) until it is done?

Link to comment
Share on other sites

Thank you xxl! I am beginning to understand. I will experiment with these settings and the CFG file, and thank you for the 130k image! One thing, when I do sector access the screen flashes on and off, is that a byproduct of having xbios under the OS? any way to prevent that (ie leave the screen static) until it is done?

Also where does one get "xboot.obx" file from? I cannot make the .atr without it, and I cannot find any download of it anywhere.

Link to comment
Share on other sites

 

1. yes, yes

2. xbios relocates itself under the OS

2a. for eample: dir2atr -m -B xboot.obx 1040 test.atr testdir... yes, copy boot sector and copy file xbios to new disk

 

 

look at the attachment

 

test program:

 

org $d800
start
lda vcount
sta wsync
sta colbak
jmp start
run start

 

config:

43 58 41 55 54 4F 52 55 4E 20 20 20 F0 F4 E2 02 E0 02 00 00 00 00 FE 00 00

 

f000 - xBIOS adress

f400 - buffer adress

Well I cannot get this to work. The CFG file does work now, so at least it doesnt fail or lockup, so I must finally have the correct format for it. But if I change the relocator addr of xbios to anywhere above $c000, it locks, does weird things, or returns to the main xbios menu with a messed up screen (ie some other screen mode). I am using $ff (and tried $fe) for the portb setting, same results either way. I am running the OS (OS not disabled) but this does not seem to be putting itself under the ROM without crashing.

Link to comment
Share on other sites

Well I cannot get this to work. The CFG file does work now, so at least it doesnt fail or lockup, so I must finally have the correct format for it. But if I change the relocator addr of xbios to anywhere above $c000, it locks, does weird things, or returns to the main xbios menu with a messed up screen (ie some other screen mode). I am using $ff (and tried $fe) for the portb setting, same results either way. I am running the OS (OS not disabled) but this does not seem to be putting itself under the ROM without crashing.

give an example program

Link to comment
Share on other sites

Well I cannot get this to work. The CFG file does work now, so at least it doesnt fail or lockup, so I must finally have the correct format for it. But if I change the relocator addr of xbios to anywhere above $c000, it locks, does weird things, or returns to the main xbios menu with a messed up screen (ie some other screen mode). I am using $ff (and tried $fe) for the portb setting, same results either way. I am running the OS (OS not disabled) but this does not seem to be putting itself under the ROM without crashing.

 

Mapping the Atari states with regards to $C000 to $CBFF, "Os ROM. In the 400/800, the block between 49152 and 53247 was unused; now the area holds many of the interrupt handlers (vectored here from page two). " with respect to the XL/XE line.

 

It seems that you won't be able to use this area as the OS is already using it. Is there any reason that you need to go so high? I use $0800 as my starting location for XBIOS.

Link to comment
Share on other sites

 

Mapping the Atari states with regards to $C000 to $CBFF, "Os ROM. In the 400/800, the block between 49152 and 53247 was unused; now the area holds many of the interrupt handlers (vectored here from page two). " with respect to the XL/XE line.

 

It seems that you won't be able to use this area as the OS is already using it. Is there any reason that you need to go so high? I use $0800 as my starting location for XBIOS

I understand that, but I am not wanting to place it using the D000 range, just in c000-CFFF or above d800. The example above uses f000 but that fails as well. And as to "why", because then I could use the main memory down to $800 (instead of $c00 with xbios loaded low)

Link to comment
Share on other sites

give an example program

I used the same one as all the other examples on here. This is what I have in MADS and comiple:

 

OPT h-f+ ; no bootable/no headers, one segment
.byte $43 ; for xB 4.3
.byte c'XAUTORUN ' ; autorun filename
.byte >$F000 ; xB adress
.byte >$0700 ; buffer adress
.word $02e2 ; INITAD adress
.word $02e0 ; RUNAD adress
.word $0000 ; I/O module adress – $0000 means xB build in SIO
.word $0000 ; I/O relocator adress - $0000 means xB build in
.byte $ff ; PORTB, without BASIC
.byte $40 ; NMIEN
.byte $c0 ; IRQEN
Link to comment
Share on other sites

 

use:

.byte $fe

.byte $00

.byte $00

 

as in example...

Still no joy, get a hard lock. I may have to just give up on this as I am only working on Altirra right now and dont have a SDSIO device yet so I can see how this stuff runs on real hardware.

 

2 quick questions for now:

 

1) The screen blanks during disk access, is this normal? Any way to prevent it?

2) Where might I find the location or equate to call to to get the "status" of a drive as in this example:

 

da #device_number

sta xDEVICE

jsr status

I get the first 2 lines of this, but what "status" address are we calling to validate the existence of the drive? Is that a function within xbios?

Link to comment
Share on other sites

  • 4 weeks later...

 

 

there is no point in going further if it does not work here.
attach an example that I could check where the problem is.

 

 

Ok I have done some experimenting, and have it working except for placing xBIOS in the upper memory area. This is the exact config I compile and use:

 

OPT h-f+ ; no bootable/no headers, one segment

.byte $43 ; for xB 4.3

.byte c'LDR ' ; autorun filename

.byte >$0800 ; xB adress

.byte >$b000 ; buffer adress

.word $02e2 ; INITAD adress

.word $02e0 ; RUNAD adress

.word $0000 ; I/O module adress – $0000 means xB build in SIO

.word $0000 ; I/O relocator adress - $0000 means xB build in

.byte $ff ; PORTB, without BASIC

.byte $40 ; NMIEN

.byte $c0 ; IRQEN

 

This moves the buffer so I can use the entire page 6 and 7 block. This works fine, but if I alter the XB address to any memory ref above c000, it hard locks the emulator. Don't know if that is supposed to automatically work just making it, say, d800, or if something else is needed.

 

I would also like to get an answer on if there is any way to prevent xBIOS from flashing/blanking the screen on disk reads. When my game tries to load a file or get sectors, the screen blanks out intermittently (flashes black) during the data xfer. This one is perhaps more important, as I can work around the first problem (or just not relocate xBIOS) but having the screen display stay up when getting map sectors from disk would make everything look a lot more professional.

 

Thank you.

Link to comment
Share on other sites

  • 1 month later...

 

Ok I have done some experimenting, and have it working except for placing xBIOS in the upper memory area. This is the exact config I compile and use:

 

OPT h-f+ ; no bootable/no headers, one segment

.byte $43 ; for xB 4.3

.byte c'LDR ' ; autorun filename

.byte >$0800 ; xB adress

.byte >$b000 ; buffer adress

.word $02e2 ; INITAD adress

.word $02e0 ; RUNAD adress

.word $0000 ; I/O module adress – $0000 means xB build in SIO

.word $0000 ; I/O relocator adress - $0000 means xB build in

.byte $ff ; PORTB, without BASIC

.byte $40 ; NMIEN

.byte $c0 ; IRQEN

 

This moves the buffer so I can use the entire page 6 and 7 block. This works fine, but if I alter the XB address to any memory ref above c000, it hard locks the emulator. Don't know if that is supposed to automatically work just making it, say, d800, or if something else is needed.

 

I would also like to get an answer on if there is any way to prevent xBIOS from flashing/blanking the screen on disk reads. When my game tries to load a file or get sectors, the screen blanks out intermittently (flashes black) during the data xfer. This one is perhaps more important, as I can work around the first problem (or just not relocate xBIOS) but having the screen display stay up when getting map sectors from disk would make everything look a lot more professional.

 

Thank you.

To follow on a bit, I finally got a SIO2SD so I can try some of this on a real Atari. I have a 65XE and an 800xl, but the XL doesnt power on the SIO2SD, so working with the 65XE for now. The behavior I have found so far is this: xbios will boot but does NOT use the .cfg file when run on a real Atari (at least via an .atr image). I can manually run the loader program for my game, but the CFG has a custom place for the sector buffer and that isnt getting picked up. Any ideas on why that might happen, but work fine otherwise in an emulator? Everything else in the game works, including loading sectors and running other files. Also the screen just goes blank instead of flickering when doing disk access, which I guess is better but I still would wonder if it couldnt be made to work without turning it all off. Other times when I compiled this game from the original basic code in MMG, the screen always stayed on when accessing the disks.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...