Why bytecopy?

You can discus menu disks by all those classic ST hack & pack teams. If you have questions, requests or remarks about hackers, packers, screens or just menu disks in general, this is the place to be!

Moderators: bodkinz, Mug UK, Moderator Team

Post Reply
User avatar
prog99
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 122
Joined: Thu Jun 19, 2003 8:08 pm
Location: Edinburgh
Contact:

Why bytecopy?

Post by prog99 »

I'm sure Lawrence has some reason why he's doing a byte copy of the file but isnt it a bit slow or am I missing something incredibly obvious here?
All my real skills are undervalued
Showaddywaddy
Atari Super Hero
Atari Super Hero
Posts: 676
Joined: Thu Jun 06, 2002 12:01 pm
Location: Montreal, Quebec
Contact:

Post by Showaddywaddy »

Do you mean the moving of the loaded data ?

Might be to do with odd addresses ;)

I must admit I was thinking of coding a much faster copy routine which used a combination of movem,l,w,b depending on length of data (size and src/dest addresses been odd or even). Maybe in the next version :)

Shw
User avatar
Cyrano Jones
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Wed May 28, 2003 8:28 pm

Post by Cyrano Jones »

Yes, "Mike" you are...

odd length files.. odd loading addresses...
User avatar
prog99
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 122
Joined: Thu Jun 19, 2003 8:08 pm
Location: Edinburgh
Contact:

Post by prog99 »

Cyrano Jones wrote:Yes, "Mike" you are...

odd length files.. odd loading addresses...
Obviously, not quite forgotten everything 68k related yet.

I'd have thought someone of your talents would have come up with a cunning plan to do most of the copy with movem and do the odd bytes separately?
All my real skills are undervalued
ijor
Hardware Guru
Hardware Guru
Posts: 4029
Joined: Sat May 29, 2004 7:52 pm
Contact:

Post by ijor »

xerud wrote:I'd have thought someone of your talents would have come up with a cunning plan to do most of the copy with movem and do the odd bytes separately?
It is usually not worth the hassle of using MOVEM. Movem is better left for specialized applications like games, demos, etc.

A flexible optimized routine is not trivial. You have to contemplate all the possibilities:

Odd length, even length, length multiple of four (or more if you are going to use movem).
Odd address.
Unaligned address (src odd and dest even or viceversa).
Many of the combinations of the above.
Plus if overlapping is possible, the direction might need to be reversed.

Making this with movem is quite complicated, and with the whole preparation before and after it might be not worth. When you tipically use Movem, you don’t need a flexible routine, you usually know beforehand the conditions.

I have one routine that I’m using in the Pasti imaging tool, but it doesn’t cover all the possibilities because I don’t need them. I can share it if you want. But the best option might be to grab a “memcpy” (or memmove, if overlap) implementation from some 68000 compiler, which they are usually highly optimized.
User avatar
prog99
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 122
Joined: Thu Jun 19, 2003 8:08 pm
Location: Edinburgh
Contact:

Post by prog99 »

ijor wrote: It is usually not worth the hassle of using MOVEM. Movem is better left for specialized applications like games, demos, etc.
Understood, I've not touched this stuff for a while so my memory is fading rapidly!
All my real skills are undervalued
User avatar
Cyrano Jones
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Wed May 28, 2003 8:28 pm

Post by Cyrano Jones »

If we were dealing with "pure" DMA sector loaded games then probably, yes it could be as all sectors are 512 bytes and there for even...

However, some of the files are odd lengths and dont quite fill their sectors (Andy's loader, for instance, process the final sector to return the exact number ot bytes)

Sure, I could movem.l all bar the last 512 bytes and then vyte copy, but the file loads are trivial ammounts of data that is hardly noticable.

The "big" delay is banking GEM in and out - this could possibly use some work, but isnt really an issue as it seems quick enough.

Originally all moves were LongWord moves, but after several bug hunts trying to find out what was wrong when it was an odd address being used, I decided to make it bytemove to just simply avoid frustration.
Showaddywaddy
Atari Super Hero
Atari Super Hero
Posts: 676
Joined: Thu Jun 06, 2002 12:01 pm
Location: Montreal, Quebec
Contact:

Post by Showaddywaddy »

Well ULS is now open source. If someone would like to code a faster memory mover then please feel free :)

I'm too busy with the next menu.

Shw
User avatar
prog99
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 122
Joined: Thu Jun 19, 2003 8:08 pm
Location: Edinburgh
Contact:

Post by prog99 »

Showaddywaddy wrote:Well ULS is now open source. If someone would like to code a faster memory mover then please feel free :)

I'm too busy with the next menu.

Shw
15 years ago maybe!

I do still remember trying to work out how lawrences file generator code worked (the recursive one he wrote in college).

Too many other distractions now!
All my real skills are undervalued
1536
Atari User
Atari User
Posts: 31
Joined: Wed Apr 12, 2006 2:27 am

Post by 1536 »

Cyrano Jones wrote:If we were dealing with "pure" DMA sector loaded games then probably, yes it could be as all sectors are 512 bytes and there for even...

However, some of the files are odd lengths and dont quite fill their sectors (Andy's loader, for instance, process the final sector to return the exact number ot bytes)
very correct. i'm having trouble doing something at the moment. i could always rip the file load code out.... in fact, i think i will. :D
Post Reply

Return to “Menu Disks”