The Sinclair QL Forum

Tobias,

Thank you, I am getting more understanding.

Taking oportunity to pose another question.

How can we safely detect NO MEDIA present?
As QL just does that, when DIR'ed whithout any cart present in the slot,

mdv[1-2]_[label]
media changed / bad media

Currently my code gets spur of bytes onto channel #0, when there is no media.

Tomas

On a very high level, the only way to detect "no media" (note this also includes drives that are completely unformatted, i.e new, the difference cannot be detected) is to run the tape and see if you get gap interrupts. If not, you don't have a tape or it's not formatted. This is how QDOS detects it.

As your code does not seem to go so deep and register an interrupt handler, you need to look somewhere else - You could try and have a look at address $18022/$18023 (The microdrive track read registers) - They should change their value very frequently when a drive is running and a tape is inserted and not at all if not.

Tobias

I would think the easiest way would be to try to read a sector header (MD.SECTR) and if it does a 'normal' (bad medium) return rather than a 'normal+4' (OK) return. Then assume there is no cartridge present.

On the subject of the DEL_DEFB command. I may be completely wrong here, But I think the command only deletes definition blocks that have no files open. So if you had a file open on the mdv, then DEL_DEFB would not delete that definition block. Also I think another of the commands uses, is to get around the problem of only being able to have 16 (I think) directory device definition blocks at any one time.
i.e. if you had 8 microdrives, and 8 RAMdiscs. Then did a DIR on each one. You would not be able to access any other directory devices (flp_, win_ etc).

Martin Head

Martin_Head wrote: I would think the easiest way would be to try to read a sector header (MD.SECTR) and if it does a 'normal' (bad medium) return rather than a 'normal+4' (OK) return. Then assume there is no cartridge present.

This seems the best way indeed. I've taken a look at the MD.SECTR code and it does wait for a gap interrupt within a certain time period, if not it gives up and returns immediately.

On the subject of the DEL_DEFB command. I may be completely wrong here, But I think the command only deletes definition blocks that have no files open. So if you had a file open on the mdv, then DEL_DEFB would not delete that definition block. Also I think another of the commands uses, is to get around the problem of only being able to have 16 (I think) directory device definition blocks at any one time.
i.e. if you had 8 microdrives, and 8 RAMdiscs. Then did a DIR on each one. You would not be able to access any other directory devices (flp_, win_ etc).

There is indeed a limit of 16 directory devices in QDOS, since the device IDs are stored in the upper 4 bits of the first byte in a slave block table entry. Also the TK2 manual states that DEL_DEFB should be used with care, it does check if there are any files open but you should still avoid using it when there are still drives running (since there might be a physical I/O operation in progress under interrupts).

cheers, Jan.

I am not sure I like DEL_DEFB at all. That command assumes it can simply delete a physical definition block and remove the device from the QL - Just as if the device was not yet detected. The point is, in the meantime there are devices that want to see some sort of mount procedure in order to create the initial PDB at first. (QL-SD is an example, other hard disks could possibly work in a similar way in case they support more than one partition). Removing the PDB invalidates the mount without the device driver knowing it (I guess).

So DEL_DEFB is OK on a fairly standard QL, but might cause all sorts of trouble on more modern expansions that weren't there when TK2 was designed.

Tobias

Hi Tomas,

tcat wrote:Jan,

My Simple 512K RAM addon, completes this benchmark in 17secs.

Code: Select all

100 ram=RESPR(16): RESTORE 140
110 FOR p=ram TO ram+14 STEP 2: READ x: POKE_W p,x
125 t=DATE: CALL ram
130 PRINT "Test complete in ";DATE-t;" seconds."
140 DATA 28771,29439,20937,-2,20936,-8,28672,20085

Can it stand any good to Trump?

You have a very fast RAM addon . I got the following results:

• Internal RAM (128K): 33 s
  Trump Card: 24 s
  Gold Card: 5 s

Also try this on your machine after entering A=RESPR(512*1024), the next time you run this your code should get into internal RAM (below $40000) and you should get about 33 s.

That said, I think just altering the timing constants for waiting loops won't solve the issue. The problem is that internal RAM delay because of video RAM access is not constant, but varying since the 8301 will leave the RAM alone for a while during horizontal and vertical retrace, so it can run at full speed for a couple of hundred microseconds. Then the next frame begins and the 8301 has to read the RAM again for the next scan line, and so on. I've seen this while writing code for a cassette tape interface (seriously!) where the signals were generated by software (I'm only talking about a few kHz here, not the 100kHz at which the MDVs operate). Running this in video-accessed RAM produced only distorted signals, not just lower tones as would be the case with constant speed.

cheers, Jan.

Chaps,

Martin_Head wrote: I would think the easiest way would be to try to read a sector header (MD.SECTR) and if it does a 'normal' (bad medium) return rather than a 'normal+4' (OK) return. Then assume there is no cartridge present.

janbredenbeek wrote: This seems the best way indeed. I've taken a look at the MD.SECTR code and it does wait for a gap interrupt within a certain time period, if not it gives up and returns immediately.

This indeed catches NO MEDIA present, and pops up an error message #-$20, I was not noticing the message as it gets quickly overwritten with spur of bytes onto channel #0.

It looks as if some MDV buffers are emptied onto channel #0, could these be the slave blocks beeing cleared?

Many thanks so far.
Tomas

tcat wrote:Chaps,

It looks as if some MDV buffers are emptied onto channel #0, could these be the slave blocks beeing cleared?

If a physical MDV error occurs the medium name will be printed followed by 'bad or changed medium'. The medium name is stored in the physical definition block at offset $16 to $1F. If this contains garbage this will also get printed. However it cannot be more than 10 characters long. Are you running a plain JM/JS or an alternative ROM?

cheers, Jan.

Jan,

It is plain JS-ROM QDOS 1.10, TK2 version 2.20 burnt to CARE ROM Cartridge, plugged to external ROM port.

http://www.dilwyn.me.uk/pe/tkii220.zip


Actually I was mistaken, as ERR #-$20, does not get popped up, but the drive gets spinned down, so the exit routine works up to this point before RTS to SBASIC.

It is a common exit point, D3 carries ERR-NO, that is moved to D0 just before RTS to S*BASIC, tested on other conditions, e.g. when loop is exhausted and the Sector is NOT FOUND.

Tomas

janbredenbeek wrote: If a physical MDV error occurs the medium name will be printed followed by 'bad or changed medium'. The medium name is stored in the physical definition block at offset $16 to $1F. If this contains garbage this will also get printed. However it cannot be more than 10 characters long. Are you running a plain JM/JS or an alternative ROM?

cheers, Jan.

Does that still happen with the direct sector access routines? With direct sector access a physical definition block may not exist.

Martin Head