What is the Lowest Memory method of reading from disk?

[keith56]

I am developing a game in pure assembly, targeting both 64k and 128k systems.

Because I am aiming for the game to work on 64k systems, memory is pretty tight, and seeing that huge blob of temporary ram at &A600-&B900(I think) used by the Amsdos system is really annoying.

If I can somehow get that memory back, then I can probably have music on 64k, but otherwise, I will be lucky to have SFX, and my game could be relegated to the ranks of the silent CPC games :-(
The game is a multiloader, and loads between levels, so taking the block after loading isn't really an option

I'm currently using Amsdos ,and loading the files by name, but I can load by sector just as easily,
my data is all in chunks of 1k, so loading a fixed blocksize is not a problem, The game and music pause during loading so I don't need interrupt support,
Disk loading is all I am using the firmware for - I am disabling it during gameplay for some extra speed and to free up the extra registers so if a third party alternative is avaliable that has a smaller footprint, then I can disable the firmware altogether and claim the upper jump block as well.

Is there any way I can get the firmware to load a chunk of data from the disk, without the firmware using this block, or alternatively a non firmware disk loader that can do the job with less memory footprint?

Does anyone have any good suggestions?

Thanks,

Keith

[fano]

I'd say, use your own loading code to read/write sectors.Take a look to FDC tools by Targhan, there are routine that may make you day
I have disk lib if you need, just have to find where 

[roudoudou]

The french magazine Amstrad 100% release small fdc routines in last n° i can send a dsk with all routines AND a cool utility to make any disk format.


Or you can use FDC routines from Futurs http://quasar.cpcscene.net/lib/exe/fetch.php?id=assem%3Afdc&cache=cache&media=assem:fdc.asm


There is also a great article about FDC, with many explanations (in french)

[fano]

Found my FDC lib lying somewhere, not perfect but does the job (it did in R-Type).You just have to remove call to text write in error management to use as it.

[keith56]

Thanks, I hadn't seen either of these these look very promising.
They certainly look like they do the Job, both seem small .... and I really want to see the back of the firmware functions!

How did I miss FDC tools? I'm already using ArkosPlayer, and it's on the same page - silly me!

I will have a play with them and figure out how they work.My french is none too good! Will have to rely on google translate! ;-)

Thanks for the help - I've been struggling to work out a solution to this for weeks

Keith

[arnoldemu]

Unofficial Amstrad WWW Resource

This uses AMSDOS BIOS facilities.

Unofficial Amstrad WWW Resource

Alternatively you can go direct to the hardware with the other examples in this thread.

Unofficial Amstrad WWW Resource

[Joseman]

I'm very interested in this...

The hardware metods doesn't work with mass storage solutions... like acmedos and m4rom... isn't it?

what's the best solution (besides ram use) if you want mass storage compatibility too?

[fano]

what's the best solution (besides ram use) if you want mass storage compatibility too?

Using system vectors as some mass storage like X-Mass comes with acmedos.

[keith56]

Just tried fdcload.asm... very easy to use!

The arkos one is pretty good too, though it's using non standard disk format isn't it, Is that something to worry about?

I tried the FDC lib, but I think I'm doing something dumb, as its just returning without seeming to load a byte. its no matter as I can use the other two, but here is the code I used as I'm sure its a great prog if I was using it correctly!

call FDC_MotorOn
call FDC_DriveWaitReady
ld hl,&c000      ; Load to screen
ld b,10*9      ; Start Track 10 Sector 1
ld c,10*9+32      ; End after 32 tracks
ld de,32*512      ; 32 tracks * 512b = 16k
call FDC_read
call FDC_MotorOff
ret

The point about the Mass storage controllers is a good one - I suspected that anything I did that wasn't "Vanilla" would be problematic for more exotic hardware, but getting access to the ram owned by Amsdos and the high jumpblock is very tempting on 64k! I will have a look at some classic games, and see what they did, I'm assuming they were using their own code, but I have not checked.

Thanks for the help!

Keith

[fano]

I tried the FDC lib, but I think I'm doing something dumb, as its just returning without seeming to load a byte. its no matter as I can use the other two, but here is the code I used as I'm sure its a great prog if I was using it correctly!

call FDC_MotorOn
call FDC_DriveWaitReady
ld hl,&c000      ; Load to screen
ld b,10*9      ; Start Track 10 Sector 1
ld c,10*9+32      ; End after 32 tracks
ld de,32*512      ; 32 tracks * 512b = 16k
call FDC_read
call FDC_MotorOff
ret

This is logical , it is only a trackloader, there is no file system so it reads track per track, you need to go on the correct track and after to read sectors specificying sector range.Btw, that's not an obligation but you can call FDC_Track0 to put calibrate before processing 

Code: [Select]

call FDC_MotorOn
call FDC_DriveWaitReady

ld A,track_to_start
call FDC_Track

for each track {

ld HL,buffer
ld DE,data_count ;(512 bytes per sector)
ld B,first sector  ;(e.g #C1)
ld C,last_sector  ;(e.g #C9)
call FDC_read
;check here if you have errors


}


call FDC_MotorOff



[TFM]

I'm very interested in this...

The hardware metods doesn't work with mass storage solutions... like acmedos and m4rom... isn't it?

what's the best solution (besides ram use) if you want mass storage compatibility too?

Use an OS which provides all needed drivers and has a small memory foodprint. At the moment this is Amsdos.


Alternative: Create your own set of drivers. You will end up having your own DOS soon. 

[Joseman]

Use an OS which provides all needed drivers and has a small memory foodprint. At the moment this is Amsdos.

I agree, but, it's possible to use amsdos without firmware?

perhaps copying the amsdos routines inside our program?

[keith56]

In my programs case, the use of the firmware was not really the problem, it was the memory being used  by the firmware at &a600-BF00. Disabling the firmware to use the shadow registers and save CPU power with my own interrupt handler, but I can back up and resore all that with ease - its the memory I needed for the 64k version of the game.

If I was only supporting 128k, it would not be such an issue, as I would page the area the A600-BF00 area  to one of the other banks if I needed that memory area, and bring it back before loading.

I have never used one but I assume that any special drives will have their own "Amsdos compatible" BIOS, that functions the same to the user, but internally works differently, so I would assume that copying and modify bits of the default firmware would not help, as it would not work with alternative hardware.

Maybe I am wrong?

[Duke]

I have never used one but I assume that any special drives will have their own "Amsdos compatible" BIOS, that functions the same to the user, but internally works differently, so I would assume that copying and modify bits of the default firmware would not help, as it would not work with alternative hardware.

Maybe I am wrong?

In the case of M4 board, you are correct.

[TFM]

Consider one idea: You always can copy parts of the memory in the screen RAM temporarily. 

[Nich]

If you reinitialise AMSDOS, you can use the memory from &0040 to &ABFB for your own programs - assuming that you're not using BASIC at all:

Code: [Select]

ld hl,(&be7d) ; get address where current drive number is held
ld a,(hl) ; get drive number
push af ; store it

ld de,&40 ; first usable byte of memory
ld hl,&b0ff ; last usable byte of memory
ld c,7 ; number of AMSDOS ROM
call &bcce ; initialise AMSDOS ROM; this also resets drive number to 0 (drive A)

pop af ; get previous drive number
ld hl,(&be7d) ; get address where current drive number is held
ld (hl),a ; set drive number to previous value

OK, AMSDOS and the firmware still reserve a relatively large chunk of memory, but the above code will enable you to gain a bit more.

[keith56]

Some great info on here!

I will have a play with the "Restore amsdos" code - it looks promising.
Depending on how the rest of the game coding goes, that may be enough memory for the music to fit! I did some music on ArkosTracker yesterday, and it ended up smaller than I was expecting, If I can make sure my game code doesn't go up by more than 600 bytes before it's done, then I think I will be OK.

The "Load to screen memory" suggestion is also a good one, it's not something I had considered, but its a good one so I will bear it in mind! The game uses two buffers during play at &C000 and &4000, swapping between them each frame, so I am already using the &4000 one as temp space during loading, its during the game loop memory gets real tight!
 
At the moment I am still using the Amsdos loader and reading by filename,
however I have renamed all the files to Txx_Syy.dat - with xx being a track number and yy being a sector number, and I have written my file loader routine to take the same parameters as a Sector loader would, so that I can switch between file and sector loading as required - I'm edging my bets so to speak, as I haven't worked out exactly how much memory the game will need so I don't know if I need to ditch the Amsdos or not.

Its a lot of fun trying to work out solutions to the limitations on these old systems!
Keith

[PulkoMandy]

If you use the "restore AMSDOS" trick, it would be a good idea to also save and restore the USER number, just in case someone has the strange idea of using it.

[keith56]

I'm going to revive this thread if that's OK, as I am having to look at this again.

Basically my game currently works on 128k with the A500-BF00 range untouched, but I need to claw back as much of that as possible to get the game working on 64K

I'm using a version of this:
http://cpctech.cpc-live.com/source/firmsave.html

However I am now using KL_WALK_ROM to restore all the roms not just the disk one

I'm experimenting with flushing out the rom data area, and upper jump block and generally my game works fine - but if PARADOS has it's drive parameters reconfigured then they are lost when the rom is rewalked
This isn't a problem, as I have found the documentation that describes the 6 bytes that parados uses for its settings, so I can back these up - but I want to try to keep things as compatible as possible for every rom out there, not just Amsdos and Parados

What I am really asking is this: is there any way I can tell the difference between temp data, and important settings in the A500-BFFF range that will be compatible with 'all' roms?
I have spare ram to back up 100 bytes or so, but I have no space to move it out the way - some of it has to go!

I'm probably asking the impossible with that one, but it's worth a shot!

>>> Addition in case anyone tries to follow this thread:
call &08bd   - this only works on Basic 1.1 - it crashes a 464

I replaced it with
Rst #8
defw &08bd :FirmJumpLoc_Plus2                  ;initialise firmware jumpblock entries

This need to be configured before flushing the firmware with:
ld hl,(&bd37+1)
ld (FirmJumpLoc_Plus2-2),hl

This will fill in the correct commands for the firmware being used and seems to work on 464 and 6128 machines

[andycadley]

The simple answer is no. Even if you looked up every version of DOS out there and carefully worked out all the "important" bits, I could release another tomorrow that adds some more. And the firmware itself provides no way of determining "important" from "scratch" memory. At some point you have to go with what works mostly and let people who want to use it with something more esoteric just hack the loader to work for themselves.

[keith56]

Thanks for the clear answer! - that confirms what I suspected.

[rpalmer]

Keith56,

Sometime you have to accept that some games are 128k (or more) only as they have room for more.
To get a 128K+ game to work on 64K is probably going the wrong way about it. It is better to get it working in 64K first and then extending it for those with more memory.
You can sort of get an extra 16K by using the screen memory as temp space with all pens set to a single color so the screen is essentially one color no matter what data is present. Its not ideal , but can be used as an interim solution to memory issues.

rpalmer

[rpalmer]

My comment was of course only for when the game is loading and not during game play.

[keith56]

To get a 128K+ game to work on 64K is probably going the wrong way about it. It is better to get it working in 64K first and then extending it for those with more memory.

Agreed, but I designed this game from the start to work with 64k... all the stuff in the extra banks is 'optional extras' - that said, the more memory I can squeeze out of the system, the more optional stuff the 64k people get!

The current release is 128k only because I did not have time to write (and more importantly.. debug!) the 'alternate' codepaths for 64k, which will have to reload the 'bootstrap' every level rather than just bankswitching , and use a 'firmware font' rather than the sprite one

You have to remember this was my first game, so I was more worried about never releasing anything than having the first release 128k only - the learning curve has been huge to get where I am with this!

The game code is structured like this

Bank1: Levelcode and sprite frame 1
Bank2: Screenbuffer 2 (temp space during loading / extra space during intro
Bank3: game core and Amsdos
Bank4: Screenbuffer 1

Bank5: Loadingscreen and continue graphics
Bank6: Bootstrap (Level loader - also handles continue/gameover)
Bank7: Music, CPC Plus sprites
Bank8: sprite frame 2, sprite font

on 64k
The bootstrap can be reloaded into the Screenbuffer 2 , the font will need subsituting and the sprites will have no animation, but it *should* work!
I just really want to get that music working on 64k, so I'm trying to force down that firmware!

It's also a good learning experience, I want to upgrade and redesign the game engine for the next game, and more control and understanding I have over that firmware code the better!

[Targhan]

I didn't follow the whole thread, but what about getting rid of the system? It seems you only need it for the loading. If that's the case, you can use, for example, my trackload code (available on the Arkos website) and that's it. A little more work is needed to put your files raw on the disc (using Ramlaid CPCTools (Windows only), also available on Arkos website). There might be some alternative ways on other system, I guess.


Edit: Oh it seems Fano did the same suggestion on the first reply on this thread . Anyway, if you need help about it, don't hesitate to ask.