Fast memory load from RAM disk?

[SeaGtGruff]

Okay, keep in mind that I haven't done anything with my Atari 8-bit computers in a *long* time. Now I'm wanting to get back into the scene-- I've even bought a 130XE and US Doubler modified 1050 to replace my old nonfunctional hardware. So I have a few questions about an idea I've had, and I ask your forgiveness in advance if I'm being totally stupid!

 

(1) Can a RAM disk be set up on any 8-bit Atari? For example, could a RAM disk be set up on an unmodified 400, using an area of normal RAM? And where are some really good instructions for newbies (and not-so-newbies) on how to set up and use a RAM disk? (Okay, that's really two questions, but I'm counting it as one!)

 

(2) How fast is a routine to load something from a RAM disk? For example, let's say I have nine (9) bytes stored in a file on a RAM disk. Supposing that I've already set up the parameters in the IO control block that say what the name of the file is, and how many bytes I want to load, and the starting address of where I want to load it to, how quickly would those bytes be loaded, including the call to XIO or whatever (this would be from machine language, not BASIC)?

 

(3) This is what I have in mind... Does it sound feasible? (A) Create a file on a RAM disk, containing a series of color values in groups of nine-- say, 192 groups of nine colors. (B) Use a DLI to read nine color values from the file, storing them in the nine color registers. (C) Use this method to quickly change all nine color registers on each scan line of a GRAPHICS 10 display, such that each scan line has its own set of nine colors. This should be much, much faster than loading and storing the color values one at a time.

 

(4) Am I crazy? (Well, I already know that I'm crazy... but am I crazy like a fox, or crazy like a loon?)

 

Michael

Edited May 24, 2008 by SeaGtGruff

[kenfused]

Okay, keep in mind that I haven't done anything with my Atari 8-bit computers in a *long* time. Now I'm wanting to get back into the scene-- I've even bought a 130XE and US Doubler modified 1050 to replace my old nonfunctional hardware. So I have a few questions about an idea I've had, and I ask your forgiveness in advance if I'm being totally stupid!

 

(1) Can a RAM disk be set up on any 8-bit Atari? For example, could a RAM disk be set up on an unmodified 400, using an area of normal RAM? And where are some really good instructions for newbies (and not-so-newbies) on how to set up and use a RAM disk? (Okay, that's really two questions, but I'm counting it as one!)

 

(2) How fast is a routine to load something from a RAM disk? For example, let's say I have nine (9) bytes stored in a file on a RAM disk. Supposing that I've already set up the parameters in the IO control block that say what the name of the file is, and how many bytes I want to load, and the starting address of where I want to load it to, how quickly would those bytes be loaded, including the call to XIO or whatever (this would be from machine language, not BASIC)?

 

(3) This is what I have in mind... Does it sound feasible? (A) Create a file on a RAM disk, containing a series of color values in groups of nine-- say, 192 groups of nine colors. (B) Use a DLI to read nine color values from the file, storing them in the nine color registers. (C) Use this method to quickly change all nine color registers on each scan line of a GRAPHICS 10 display, such that each scan line has its own set of nine colors. This should be much, much faster than loading and storing the color values one at a time.

 

(4) Am I crazy? (Well, I already know that I'm crazy... but am I crazy like a fox, or crazy like a loon?)

 

Michael

 

It you were doing it from basic and didnt want to do any ml at all, maybe that would be useful, but if your talking doing this in ML, copying 9 bytes would be almost instantaneous and many times faster than a ram disk and a lot less code. The ramdisk will effectively just be copying the bytes (maybe more than once) too but with a lot more setup overhead.

 

coltab1: .byte 24,42,0,36,92,100,200,232,111

 

ldx #8

@lp: lda coltab,x

sta 704,x (or the appropriate hardware address if for a dli)

dex

bpl @lp

 

or 9 load immediates and 9 stores if that isn't fast enough

 

--Ken

Edited May 24, 2008 by kenfused

[SeaGtGruff]

It you were doing it from basic and didnt want to do any ml at all, maybe that would be useful, but if your talking doing this in ML, copying 9 bytes would be almost instantaneous and many times faster than a ram disk and a lot less code. The ramdisk will effectively just be copying the bytes (maybe more than once) too but with a lot more setup overhead.

 

coltab1: .byte 24,42,0,36,92,100,200,232,111

 

ldx #8

@lp: lda coltab,x

sta 704,x

dex

bpl @lp

 

or 9 load immediates and 9 stores if that isn't fast enough

 

--Ken

I'm not worried about the overhead, everything would be set up ahead of time-- like during a VBI-- so the DLI would just be triggering the operation to load the specified number of bytes from the RAM disk file, beginning at the specified location. Are you saying that reading nine bytes out of a RAM disk file and moving them into nine consecutive addresses will take longer than doing nine consecutive LDA #immediate and STA absolute statements? I thought that loading from a RAM disk would be faster? What kind of numbers (speed) are we talking about? I already know the LDA/STA speeds-- 6 cycles for LDA #immediate and STA absolute, so 54 cycles for nine bytes-- but how many cycles does it take to load a nine-byte file into memory from a RAM disk? I'm not talking about nine individual GETs and PUTs, I'm talking about reading nine bytes.

 

Michael

[kenfused]

I'm not worried about the overhead, everything would be set up ahead of time-- like during a VBI-- so the DLI would just be triggering the operation to load the specified number of bytes from the RAM disk file, beginning at the specified location. Are you saying that reading nine bytes out of a RAM disk file and moving them into nine consecutive addresses will take longer than doing nine consecutive LDA #immediate and STA absolute statements? I thought that loading from a RAM disk would be faster? What kind of numbers (speed) are we talking about? I already know the LDA/STA speeds-- 6 cycles for LDA #immediate and STA absolute, so 54 cycles for nine bytes-- but how many cycles does it take to load a nine-byte file into memory from a RAM disk? I'm not talking about nine individual GETs and PUTs, I'm talking about reading nine bytes.

 

Michael

The RAMDISK driver won't just magically load all nine bytes at once. Somewhere it is going to have something similar to the loop above but on top of that there will be lots of other overhead. It is just software itself copying bytes around.

 

My guess is every 125* bytes read it will have to calculate the appropriate bank and address, switch banks, copy 128 bytes back to a sector buffer, bank back to original bank.

It will then be copying those 9 bytes from somewhere in the buffer similar to the above code but probably a little more complicated (stopping any time in the middle to copy 128 bytes more as necessary tracing the sector links in the file*).

 

* = dependent on DOS/RAMDISK driver

[Rybags]

CIO has way too much overhead for a RAMdisk to be viable for scanline critical colour changes.

 

Also, lots of device handlers use buffers, so the transfers aren't straight away.

 

Finally, you can't use CIO inside interrupts (normally). Actually, you can, but it is a service that isn't re-entrant. One request has to complete before another one is started.

 

All that aside, it's just 100 times easier (and faster) for a program to just access extended RAM itself. A RAMDisk is a good idea though for something like a mapped game that wants to access world data. AFAIK, games like AR: The Dungeon use any standard extended RAM beyond 48K like a kind of disk cache.

 

RAM disk inside the standard 48K map? Possible, sure - but not really convenient. Old 8-bit machines have pretty poor and simple memory management. I guess such a RAMdisk might be useful if you were working on several small programs at once and wanted to quickly swap between them.

[SeaGtGruff]

The RAMDISK driver won't just magically load all nine bytes at once. Somewhere it is going to have something similar to the loop above but on top of that there will be lots of other overhead. It is just software itself copying bytes around.

Yes I know it's just software itself, but somehow I had gotten the impression that it would be faster (using a RAM disk).

 

It will then be copying those 9 bytes from somewhere in the buffer

No no, the idea was that the buffer would be pointed to the nine consecutive memory addresses for the color registers-- *they* are the nine-byte buffer. Like a BLOAD directly into the color registers. Read a nine-byte record from RAM disk into the buffer, which is equal to the color registers.

 

Oh well, it seemed like an interesting idea at the time.

 

Michael

[kenfused]

I guess what I am saying, is no matter how the ram disk driver works, somewhere it is going to be doing 9 loads and 9 stores the same as doing it yourself, but it also has more work to do than that in trying to act like a normal disk drive.

[Heaven/TQA]

maybe explain little bit more why you want to use kind of ramdisk instead of array of colour changes? what was your intension? I know you are coming from 2600 so maybe that is what gives you this "no ram space" thinking?

 

it's like on every 8bit... if you want speed...never use OS or service routines...

[SeaGtGruff]

maybe explain little bit more why you want to use kind of ramdisk instead of array of colour changes? what was your intension? I know you are coming from 2600 so maybe that is what gives you this "no ram space" thinking?

 

it's like on every 8bit... if you want speed...never use OS or service routines...

No, I don't have a problem with RAM. I've programmed on the Atari 8-bit before, but not in many years.

 

I was just wondering if reading nine bytes directly into the color registers-- from a RAM disk, with the buffer pointed to the first of the nine color registers-- would be any faster. My reason for thinking of this in the first place is that when you move nine bytes by loading a register (be it A, X, or Y) and then storing it in an absolute address, you need to tell the computer where you want each value to be stored. Whereas I guess I had a mistaken idea that when you read a record from (RAM) disk, each byte of the record would get moved into the appropriate spot within the buffer without needing to take as much time, because the chip was keeping up with where the next byte should go. What I really need is to look at the code, but I don't have "Inside AtariDOS," and the online book doesn't include the code in it.

 

So my idea was a bust, and the fastest solution is to store the colors directly in the DLI code, so you can do LDA immediate and STA absolute-- 6 cycles per color register.

 

Michael

[Heaven/TQA]

Ah, now I see were you coming from... but you can try it (just a quick idea)...

 

you can pack different segments of data into one binary... so actually you can do this

 

.byte $ff,$ff,ad lo col register, ad hi col register

.byte colour value

.byte $ff,$ff,ad lo col register, ad hi col register

.byte colour value

.byte $ff,$ff,ad lo col register, ad hi col register

.byte colour value

 

 

some games do this so they are changing the screen plus colour value while dos is loading the file from disc... but not in a DLI as the DLI interfers with the disk io (at least from 1050) but not sure if from D8: