Preload data to VBXE memory with Altirra?

[Thelen]

I've done some quick searching, but couldn't find out yet- maybe someone knows ? - I'm using Altirra with VBXE enabled with Mads assembler.

For the VBXE I'm loading 32 scanlines of 320 pixels, which is some of 10K bmp data. All have to be loaded from a .xex which I assemble with Mads -  from the atari memory threw memac- and 10K is a lot for a system which is 64K. Also if I want to get a complete 256 color 320x192 image, I need almost 64k bmp data to get in the VBXE memory. Off course it can be loaded from ATR - but I want to compile and test quickly - and not wait for it to load.

So, is there a way to get data preloaded into the VBXE memory with altirra (and not loading threw Mem a or b)?

Thanks, I hope my question is clear enough ?

Edited April 6, 2022 by Thelen

[phaeron]

There is no way to load directly to VBXE, but you should be able to map one of the MEMAC windows in an init segment and then load a segment directly into the MEMAC window without having the CPU copy it.

 

Alternatively, map the BMP file with the H: device and do a read from it into MEMAC through CIOV. This will also be instant as long as CIO burst transfers are enabled and MEMAC is below $C000.

 

[+Stephen]

Also, you can hold down the F1 key to keep the emulator running as fast as possible.  I do this when pulling in full screen 320*240 images.  Then when I resume testing on the real hardware, I miss that key!

[tebe]

https://github.com/tebe6502/Mad-Assembler/blob/master/examples/qlkee2_vbxe.asm

[Thelen]

11 hours ago, phaeron said:

There is no way to load directly to VBXE, but you should be able to map one of the MEMAC windows in an init segment and then load a segment directly into the MEMAC window without having the CPU copy it.

 

Indeed, right now I'm copying by CPU. Do you mean that a part of the Atari- ram is accessable by CPU and VBXE?

[+Philsan]

9 hours ago, Stephen said:

Also, you can hold down the F1 key to keep the emulator running as fast as possible.  I do this when pulling in full screen 320*240 images.  Then when I resume testing on the real hardware, I miss that key!

I miss that key when Atari Basic games read data... ?

[phaeron]

59 minutes ago, Thelen said:

Indeed, right now I'm copying by CPU. Do you mean that a part of the Atari- ram is accessable by CPU and VBXE?

No, VBXE has no ability to access main RAM. What you can do is flip it around and use VBXE memory through MEMAC in place of main memory instead, since any reads or writes to that address window will be redirected to VBXE -- even if they're from DOS or CIO/SIO. This means you can have DOS load 8K of data into a MEMAC window at $2000-3FFF and that data will be loaded directly into VBXE, without you needing to do an additional copy with the CPU.

 

In Altirra, executable loads and all acceleration paths use the CPU memory map, so any address space overlays like MEMAC will also affect executable loads and accelerated CIO/SIO reads.

 

For optimal speed, you would want to load data into VBXE memory in contiguous large blocks and then do any necessary rearrangement afterward using the blitter. The blitter can copy memory more than 10x as fast as the 6502 and can also run in parallel to it.

 

Note that $4000-7FFF should probably be avoided for this trick, because IIRC loading into that range can force SpartaDOS X to do an additional copy when it is running in BANKED mode. This is because it can have drivers using extended memory, which overlaps that same window.

 

[shanti77]

It loads pictures through the MEM-B window ($4000- $7fff). The easiest way to use the screen is 256 pixels, then each line is one page of memory.
Also note that if you are using a 256-color .bmp file, it has a header of $436 bytes that needs to be removed. The image data is additionally saved in the file from the last to the first line, i.e. upside down. It can be rotated later with a blitter, or when loading (data can be read into the $8000- $bfff area and then copied to the destination). The downloaded data must be divided into blocks (with a width of 256 pixels, it will be 4 files, 16KB each, with 320, probably 5 files).
In the header, the last $400 bytes (from position $36) is the color palette, written as Blue,Green,Red,00, you need to set the palette with them.

[Thelen]

14 minutes ago, phaeron said:

For optimal speed, you would want to load data into VBXE memory in contiguous large blocks and then do any necessary rearrangement afterward using the blitter. The blitter can copy memory more than 10x as fast as the 6502 and can also run in parallel to it.

 

 

 

Thanks, and smart to rearrange it later with blitter!

[Thelen]

44 minutes ago, shanti77 said:

It loads pictures through the MEM-B window ($4000- $7fff). The easiest way to use the screen is 256 pixels, then each line is one page of memory.
Also note that if you are using a 256-color .bmp file, it has a header of $436 bytes that needs to be removed. The image data is additionally saved in the file from the last to the first line, i.e. upside down. It can be rotated later with a blitter, or when loading (data can be read into the $8000- $bfff area and then copied to the destination). The downloaded data must be divided into blocks (with a width of 256 pixels, it will be 4 files, 16KB each, with 320, probably 5 files).
In the header, the last $400 bytes (from position $36) is the color palette, written as Blue,Green,Red,00, you need to set the palette with them.

Thanks for your good explanation!