| |
Mixer
Registered: Apr 2008
Posts: 422 |
Drive access time
So, I want to read a random block from 1541 disk. Is it possible to make the access time somewhat constant or predictable? For example to make sure that the desired block or chunk of data can be loaded during the next second or shorter time.
Would the access time be any different if there is one huge data file which is optimized on disk for fastest reading?
Would such a loader/file system be compatible with other drives? |
|
| |
tlr
Registered: Sep 2003
Posts: 1717 |
Quoting MixerSo, I want to read a random block from 1541 disk. Is it possible to make the access time somewhat constant or predictable? For example to make sure that the desired block or chunk of data can be loaded during the next second or shorter time.
A quick calculation using conservative timings. I'm sure someone will provide the fastest figures here later.
Spinning up the motor takes 500ms (the rom uses 1 s). You should be able to step while spinning up.
Assuming you stand on track 18, a maximum of 17 tracks need to be stepped.
Each track takes maybe 10 (step half), 10 (step half), and at the end 10 ms extra (settle)?
(the rom uses 15 + 15, 75 here).
Searching a full track to find and read a sector takes 200 ms.
So it will take less than: max(17*20+10, 500) + 200 = 700 ms (550 ms with 350 ms spinup) to read a random sector.
Using ROM timing max(17*30+75, 1 s) + 200 = 1200 s (875 ms with 675 ms spin up)
Quoting MixerWould the access time be any different if there is one huge data file which is optimized on disk for fastest reading
Not really as it depends on physical distance. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
With fully random block access, we need to assume the worst case.
And if you're continuously reading random blocks, the motor should be kept spinning.
So going from track 1 to 35 or back, with the conservative amount of time ROM takes being 58 bycles per half-track step, would come out at 58 * 34 * 2 = 3,944 bycles, which is approximately 1.01 seconds.
Once arrived on the destination track, at most one revolution (200 ms) to arrive at the desired block, then reading and transfer (maybe 40 ms).
So worst case (without errors) would be somewhere around 1.25 seconds.
On average, you can expect half of that time for a random block to arrive. |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
Thanks tlr,krill. So, keep your motor runnin (head out on the high way) -> born to be wild demo. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Leaves the XY problem question. What do you actually want to do, and why do you want fully random block access? Demos load blocks in linear order most of the time, even when loading random files. |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
@Krill: XY indeed.
Lets say that there is some sort of XY scroller, where user controls the direction, thus it cannot be predicted. The screen buffers must be updated with new data to the direction of the scroll from disk, and the question is how much data can be updated from disk in what amount of time to figure out how fast the scroll can be, and what the best way to organize the data on disk would be. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11126 |
i'd try something like this:
- tracks equal moving in X
- sectors equal moving in Y
now every step in X or Y is maximum ~220 ms (or 11 frames) away (plus what it takes to actually transfer it). sounds a bit slow :)
to improve the access time, you'd have to duplicate data on tracks. and to make sure it actually works for everyone on real hardware, it'd probably be a good idea to provide a formatter that formats the disk in the exact layout you expect it to be.
i actually thought about using such scheme for a game that has a huge map... curious to see what comes out of it |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
If it's really just for an XY scroller, how complex can the data be?
One would expect to have a comfy amount of time to calculate the data in the same time they'd roll in from disk otherwise.
Or do you have different scrolltexts depending on direction? (Which is actually just an angle, so one degree of freedom, not two for XY.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11126 |
Should indeed be possible to just buffer enough of the (all) edges that stepping/loading/depacking isnt a big problem |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
What to load or transfer is the same problem as when we're masking out two overlapping rectangles from a bigger rectangle. One small rectangle is the screen and the overlap is what we need.
Like this:
0 is the data on disk
1 is what we need
2 is what we have
I hope CSDB shows this right
00000
01100
01220
00220
00000
Groepaz suggested tracks and sectors, but lets say that we have 170kb disk as a large bitmap, it is about 20x8kB, so it is 20 bitmaps, or a screen of 20000 characters, or a square with 141x141 unique characters, and obviously we pack the data to make things more complicated, just because hey. a block of data is about 32 characters of bitmap, so that might be the smallest grain we load at a time. So we now need to map the tracks and sectors on the screen. But as Krill pointed out, the next data up/down/left/right is not necessarily on the other end of the disk. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Oh, a large BITMAP scroller. You should have said that earlier, i was thinking of, well, scrolling text.
Quoting Mixerand obviously we pack the data to make things more complicated, just because hey Rather because the serial bus is the bottleneck. Highly packed data is preferred. =)
Quoting Mixerthe next data up/down/left/right is not necessarily on the other end of the disk Not only that, it's also ordered. Just that you have 2 axes instead of 1. So you'd maybe do something like divide a track in 2 (differently-sized) parts, one being the centre (visible part) and the other the surroundings in the 4 (or 8) directions. But better not overthink it... until running into actual problems. =) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
The Ourobous-scrolller in The Elder Scrollers was all in bitmap, using a tricky AGSP-scheme, compressed data and predictable scrolling and I was almost out of bandwidth. So a random based scroller using bitmap will be a beast to code if possible at all or scroll very slowly. |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
As you all know, using the repeat line-mode one can build a character set based bitmap, where every character line bitmap is from a different character bank, and the first character line defines the character pointers, which repeat over the rest of the screen. It works, but the timing is a bitch.
This is a very cool artificial mode, as one can change the bitmap gfx just by rewriting the top character line, and bank/char set every 8th line. To scroll up and down we allow the y-bitmap ptr to increment normally on one of the char lines, to get another set of repeatable characters, which then is the top line of the bottom screen.
The mode sees a 255 characters wide and 25 characters high bitmap, which can be addressed by writing only 80 characters on screen memory. 40 for the top row and 40 for the split row. And even that writing is only necessary when 8 pixels are scrolled to any direction. Most of the time, that mode only takes the 25 raster interrupts to manage the repeat-line and changing bank/char set.
So, one can show any screen sized rectangle on a 6 screens sized bitmap, without any memory copying.
Rest of the cycles are free for something else, such as loading stuff.
The amount of data to be loaded is about the same as with a bitmap mode gfx, but this version does not have to do any bitmap memory copying, so it might be a bit faster. All we need is to know what to load and where to.
Perhaps we should set up a programming compo to get this done? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
Ahh, scrolling through maps. That takes me back to working on Driv3r, where we had square tiles one or two hundred meters to a side full of instance data, and three sets of model data for the current and a couple of nearby neighbourhoods. Jeanette and I had to design a set of rules for the artists to stick to about how close together different neighbourhoods could be, given seek times on DVDs, and the time it took to load X many MB of models and textures..
IIRC the grid of instance data was just stored linearly on the disk, one row of tiles at a time. As long as the player car stayed below 88mph all was fine :D |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
@ChristopherJam: Over 88 mph and -> future? |
| |
Pex Mahoney Tufvesson
Registered: Sep 2003
Posts: 50 |
ChristopherJam, that Reminds me of Crazy Taxi on Dreamcast when played from a downloaded and burned CD-RW when not adding empty files at the inner part of the disc. CDRom drives read slower on the inner tracks, and a copied Dreamcast disc would read too slow on the inner tracks. Fortunately, the collision map was already in memory, so the game ran fine, but the texture loading and 3d-models were loaded a couple of seconds too late when you were driving fast through the neighbourhoods, creating a lot of ugly pop-up effects. Filling the inner tracks with empty files solved the loading lag problem in that case! |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: As you all know, using the repeat line-mode one can build a character set based bitmap, where every character line bitmap is from a different character bank, and the first character line defines the character pointers, which repeat over the rest of the screen. It works, but the timing is a bitch.
This is a very cool artificial mode, as one can change the bitmap gfx just by rewriting the top character line, and bank/char set every 8th line. To scroll up and down we allow the y-bitmap ptr to increment normally on one of the char lines, to get another set of repeatable characters, which then is the top line of the bottom screen.
The mode sees a 255 characters wide and 25 characters high bitmap, which can be addressed by writing only 80 characters on screen memory. 40 for the top row and 40 for the split row. And even that writing is only necessary when 8 pixels are scrolled to any direction. Most of the time, that mode only takes the 25 raster interrupts to manage the repeat-line and changing bank/char set.
So, one can show any screen sized rectangle on a 6 screens sized bitmap, without any memory copying.
Rest of the cycles are free for something else, such as loading stuff.
The amount of data to be loaded is about the same as with a bitmap mode gfx, but this version does not have to do any bitmap memory copying, so it might be a bit faster. All we need is to know what to load and where to.
Perhaps we should set up a programming compo to get this done?
Yes ofc... but that is char mode still and very limited colors. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11126 |
Quote:Reminds me of Crazy Taxi on Dreamcast
also sonic adventure and... the third game in the same engine :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
Quote: @ChristopherJam: Over 88 mph and -> future?
The actual number we got back from "this many bytes per second and this many bytes per region with a tile size of X" was so very close to 88mph it would've been criminal not to round it ever so slightly :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
Quoting Pex Mahoney TufvessonChristopherJam, that Reminds me of Crazy Taxi on Dreamcast when played from a downloaded and burned CD-RW when not adding empty files at the inner part of the disc...
Oh, nice. But yes, I think we did have to be a little careful about file placement on some of the Drivers. The same could well apply on c64 of course - some loaders will give you throughput dependent on which of the four speed zones you're in.
A slight clarification to my earlier comment btw - while driver 1 and 2 only had one "superregion" loaded at once (with long boring stretches between the neighbourhoods), Driv3r had three buffers to have up to three neighbourhoods loaded at once, with a three-colourable map of around a dozen or so neighbourhoods per city with no gaps between them.
Again, similar techniques could well be adapted to a c64 bitmap scroller, given that the tilesets are implemented entirely in software. |
