trackdisk.device after system takeover

[alpine9000]

I assume trackdisk.device off limits once you have taken over the system and almost certainly overwritten system data structures in chip ram ?

I am talking about a non system friendly, bootblock launched program here.

I am guessing this is why people use custom track loaders ?

If this is the case, any pointers to a good track loader ?

[jotd]

Rob northen track loader is very good. Can be ripped from most team 17, core design or renegade titles. Ex qwak

[Photon]

Trackdisk.device I remember I used it at the very start before I made my own. Should be no problem to use it after turning off the system tho? Just don't disable disk DMA or overwrite all chipmem down to $100.w obviously.

[Toni Wilen]

It isn't that simple. trackdisk.device needs interrupts, needs working timer.device and other parts of the system. Also track buffer is in low chip RAM (and not that low if system is chip ram only with multiple disk drives..)

Just don't do it

[Galahad/FLT]

Originally Posted by Toni Wilen

It isn't that simple. trackdisk.device needs interrupts, needs working timer.device and other parts of the system. Also track buffer is in low chip RAM (and not that low if system is chip ram only with multiple disk drives..)

Just don't do it

Too much drama Toni, its perfectly feasible and easy to use trackdisk.device in this way.

However, the main reason for not using it is simply down to memory usage.....it just eats up too much damn ram.

Everything has to be system friendly allocated, and then allocate programs on the fly and not have them hardcoded to specific addresses.

With system resources, any open libraries/devices, and trackbuffer for trackdisk.device, you simply lose to much ram if for instance you wish to make the game load on 512k machines, hence why people binned the system and were able to access all memory.

[Toni Wilen]

Originally Posted by Galahad/FLT

Too much drama Toni, its perfectly feasible and easy to use trackdisk.device in this way.

It was response to "Just don't disable disk DMA or overwrite all chipmem down to $100.w obviously". Yes, it is easy way but not very reliable

EDIT: I am just too annoyed with old demos and others that breaks if more than 1 floppy drive is enabled only because they used far too low absolute load or decrunch address. (I don't mind absolute addresses in old productions, as long as it isn't used too stupidly)

[Photon]

Originally Posted by Toni Wilen

trackdisk.device needs interrupts

Cowering as if expecting a hammer blow from above, I still ask: are you sure?

Well obviously as for a hardware loader you'd need the two disk interrupts on, but that's still OS off for me Reason is as you've said a lot of old prods do this and it seems to work fine for just loading parts sequentially if you don't overwrite low mem.

I still recommend a hardware trackloader, for the same reason as you, more memory usable for the good stuff. And much faster speed.

To soften the blow, since Amiga Future Magazine #116 is now sold out I guess it's OK to upload BootLoader.S to my repository.

It's just my old tested and true trackloader in a bootblock, nothing too special but fast and simple to use. Any include files it needs will be in the repository or in the first two articles on Coppershade.

[alpine9000]

Thanks everyone. And thanks Photon, that's exactly what I was looking for. Can't wait to give it a try.

Didn't want to try and re-invent the wheel. The few trackloaders I did try didn't seem to work on newer machines.

[alpine9000]

Originally Posted by Photon

Cowering as if expecting a hammer blow from above, I still ask: are you sure?

Well obviously as for a hardware loader you'd need the two disk interrupts on, but that's still OS off for me Reason is as you've said a lot of old prods do this and it seems to work fine for just loading parts sequentially if you don't overwrite low mem.

I still recommend a hardware trackloader, for the same reason as you, more memory usable for the good stuff. And much faster speed.

To soften the blow, since Amiga Future Magazine #116 is now sold out I guess it's OK to upload BootLoader.S to my repository.

It's just my old tested and true trackloader in a bootblock, nothing too special but fast and simple to use. Any include files it needs will be in the repository or in the first two articles on Coppershade.

Tried it out this evening. Works great. Everything was self contained, no includes needed.

[hooverphonique]

if you just need to load something from the boot block, trackdisk.device is already open. IIrc, the IO struct is pointed to by A1.

[alpine9000]

Originally Posted by hooverphonique

if you just need to load something from the boot block, trackdisk.device is already open. IIrc, the IO struct is pointed to by A1.

Yeah that's what I have been using and as you say, it's very easy. But now I'm at a stage where I want to load more data from the main program.

Also I like the way with Photon's boot loader that now I am in complete control of all ram.

[alpine9000]

In case anyone reading this uses Photon's bootloader with vasm, there is a small catch.

MFMchk:         dc.l 0
                dc.w 0 ;reserved for your use.

LoadVector:     bra.w LoadMFMB ;for external calls, JSR ($11c).w

LoadScript:     ;At $120, sysinfo in 4 regs, a6=$dff002
                lea CPUinfo(PC),a3 ;Use this for PC-rel in a pinch.

LoadScript needs to be at $120, but by default (at least for me) vasm will optimise the bra.w LoadMFMB to a bra.b, moving LoadScript. Easy to fix by adding another "reserved for your use" word.

[phx]

Originally Posted by alpine9000

ILoadScript needs to be at $120, but by default (at least for me) vasm will optimise the bra.w LoadMFMB to a bra.b

This is most likely your fault to select bad options.
By default vasm will never optimize a branch when a size-extension was specified. Either you are using the -phxass compatibility flag, or -opt-allbra.

[Photon]

Auto-optimization isn't a bad option per se (nor is manually invoked branch optimization), it's just that for jump tables (that use relative branches, to get 0 relocs), you want an assembler directive to not optimize the table. It's the same with any decrunch routines, music players, etc. You just have to look out for it.

[phx]

Right. The developer should always have the full control about which sequences may be optimized and which not.
With vasmm68k you can control it by explicitely writing the instruction's size-extension, which you did, so everything is fine.

[alpine9000]

Yes - my fault. I am/was using -phxass as I was originally using vbcc then copied it's options when I switched to vasmm68k.

[alpine9000]

Wow, what a ride I just went on.

After incorporating Photon's trackloader into my bootblock, I moved onto using it to load data in my main application. Everything was working nicely (I still need to ask what the "step0" thing it all about ). I was loading image data from various places on the disk and displaying it.

However there was one group of sectors on the disk that always showed corrupt or missing data (About 10 interlaced HAM scan lines worth).

I obviously assumed it was something I was doing wrong, so spent quite a while double checking things, but while I found lots of things I was doing wrong, none of them caused that problem.

This was using FS-UAE on a mac. I was about to start debugging the trackloader to help work out what I was doing wrong and I switched to WinUAE on a PC, and all of a sudden no problem. Then I tried FS-UAE on the same PC and no problem. Then I nuked my "FS-UAE" folder on my mac, and loaded it fresh and no problem.

Strangely on the bad FS-UAE config, it also worked fine as an A1200 or A4000.

Still no idea what caused that weirdness. I have a copy of the bad config folders, so will probably look into it again one day. Might have been related to trying a development version of FS-UAE.

[phx]

Originally Posted by alpine9000

This was using FS-UAE on a mac. I was about to start debugging the trackloader to help work out what I was doing wrong and I switched to WinUAE on a PC, and all of a sudden no problem.

Sounds like a perfect simulation of 25 years old DD disks...

When I'm preparing DD disks for real hardware tests then I have to format them two or three times before they keep the data without read/write errors.

[alpine9000]

Originally Posted by phx

Sounds like a perfect simulation of 25 years old DD disks...

When I'm preparing DD disks for real hardware tests then I have to format them two or three times before they keep the data without read/write errors.

Probably punishment for me abandoning the amiga for so long. Hopefully the punishment doesn't last 25 years

[Toni Wilen]

Probably not reason for this problem but it can make testing in emulator tricky because emulators in accurate modes are usually designed to not be "random" (for easier debugging).

Starting same program twice (by stopping and starting emulator and having disk in drive when starting) will make 100% identical runs.

If program has some timing bug that for example can happen only every 1000th run on real hardware but if it happens in emulator, it will also happen every time! (and vice versa). In worst case you can have bug that happens every second run on real hardware but never in emulator..

Fortunately it is easy to confirm: boot without disk in drive and insert it only after "insert disk" screen appears or use keyboard reset (not GUI reset button). This changes timing/disk initial rotational position. Do the reset few times to be sure.