English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Asm / Hardware (http://eab.abime.net/forumdisplay.php?f=112)
-   -   Library calls after Ministartup (http://eab.abime.net/showthread.php?t=100129)

sparhawk 23 December 2019 12:25

Library calls after Ministartup
 
I was wondering which library calls can be done, after Ministartup has been used. I would assume that you should still be able to call functions like Alloc-/FreeMem, and I assume that it wouldn't make sense to use functions from the graphics library. But what about dos.library? I should still be able to i.e. load/write files on disk, or is this also a problem since interrupts are disabled?

hooverphonique 23 December 2019 14:58

you can't use dos.library without multitasking enabled, so yes, interrupt(s) need to be on during dos I/O. Either INT2 or 6 is generally sufficient, I can't remember which of the two.

phx 23 December 2019 19:20

Either take over the system and write your own disk routines or let AmigaOS running and use it. Everything in between is hackish.

sparhawk 23 December 2019 23:28

Are there any working samples? I would not rather like to start writing a full OS.

Asman 23 December 2019 23:55

@sparhawk - In The Zone you will find an asm example of System Overtake + loading files. It works in following way.
1. Disable OS
2. Wait for LMB
3. Enable OS for loading
4. Load testfile
5. Disable OS
6. Wait for LMB
7 Enable Os --> Back To OS

If you have any question - just ask.

phx 24 December 2019 00:24

Quote:

Originally Posted by sparhawk (Post 1367061)
Are there any working samples? I would not rather like to start writing a full OS.

In a game there are not many OS functions you need. Usually you want a simple memory allocator, which is trivial if you always deallocate the memory which you last allocated, and routines for loading data from mass storage.

It also depends on the type of game. Does it have to run from hard disk or do you aim for a classical floppy-disk game (ADF). In the last case I would always suggest to use a trackloader and kill the OS completely. Otherwise do it like Asman said.

Yes, there are working trackloader samples. I released the full source for all my games. :)

sparhawk 24 December 2019 00:57

Thanks! I was also thinking along the lines of switching off takeover for loading. Since I seem to have now a stable takeover routine, this would be one way to go. Since this is my first game, and I have to learn all from scratch, I would rather like to focus on the game, instead of the OS stuff. :) So I write what I need as I go along, and I guess writing a disc loader would be cool, but detracts from the main goal. :)
I nevertheless check the zone for @asman's file. :great

Currently I fight with such basic stuff as a simple copper list, so this will take a long time anyway. I have "Data Becker Intern" book, but I already found some things in the samples they provide, which appear to be wrong, when I debug it and compare it with online information. Fortunately tommorrow is finally Christmas Eve and I will get the RKM Hardware book, which I've been waiting for. :D

StingRay 24 December 2019 10:05

Quote:

Originally Posted by hooverphonique (Post 1366998)
you can't use dos.library without multitasking enabled, so yes, interrupt(s) need to be on during dos I/O. Either INT2 or 6 is generally sufficient, I can't remember which of the two.


Level 2 interrupt needs to be enabled, disk DMA and (on 1.x Kickstarts only I think) blitter DMA need to be turned on as well.

sparhawk 24 December 2019 11:07

From the docs I would have assumed that this should be sufficient. :) I was going to test it that way, but it's good to have it confirmed. Haven't thought of the blitter, though, as I thought that disk interrupt should be enough.

I wonder why the blitter is involved though. Can I not load data directly into Fast RAM?

ross 24 December 2019 12:26

Quote:

Originally Posted by sparhawk (Post 1367106)
I wonder why the blitter is involved though. Can I not load data directly into Fast RAM?

Not from floppy devices (or any device that use DMA memory and destination is outside this space).

Blitter can be used (and is on KS1.x) to decode the raw MFM data read by the disk DMA (then buffered data are CPU copied in final destination RAM).

kamelito 24 December 2019 14:03

Quote:

Originally Posted by sparhawk (Post 1367061)
Are there any working samples? I would not rather like to start writing a full OS.

https://github.com/flynn-nrg/tornado-amiga

Auscoder 25 December 2019 11:03

Code:

INTENASET_DISK      = %1001000000001010
INTENACLR_DISK      = %0001000000001010
DMASET_DSKEN        = %1000000000010000
DMACLR_DSKEN        = %0000000000010000

*****************************************************************************************
ENABLE_DISK_IO:
        move.w        #INTENASET_DISK,$dff09a ;INTENA
        move.w        #DMASET_DSKEN,$dff096 ;DMACON
        rts
       
*****************************************************************************************
DISABLE_DISK_IO:
        move.w        #INTENACLR_DISK,$dff09a ;INTENA
        move.w        #DMACLR_DSKEN,$dff096 ;DMACON
        rts

I use these helpers before and after any disk io (Once the system has been taken over)

I have blitter enabled as well.
I open Dos library prior to system takeover
Close dos library after system restored - So it remains open for life of program.

Code:

OPEN_FILE:
        movem.l        d1-d7/a0-a6,-(sp)
                bsr ENABLE_DISK_IO
                move.l _DOSBASE,a6
                jsr _LVOOpen(a6)
                bsr DISABLE_DISK_IO
        movem.l        (sp)+,d1-d7/a0-a6
                rts

READ_FILE:
        movem.l        d1-d7/a0-a6,-(sp)
                bsr ENABLE_DISK_IO
                move.l _DOSBASE,a6
                jsr _LVORead(a6)
                bsr DISABLE_DISK_IO
        movem.l        (sp)+,d1-d7/a0-a6
                rts

I am definitely not an expert, but after some trial and error, these flags seemed to work. Note the overkill push/pop of the registers.


All times are GMT +2. The time now is 00:39.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.04447 seconds with 11 queries